Skip to content
As-Link Docs

iDempiere サービスレベルの使い方｜取引先管理 操作マニュアル・技術仕様

This content is not available in your language yet.

📖 取引先管理の全体像: 取引先管理の全体図 も合わせてご覧ください。

サービスレベルは、収益認識（Revenue Recognition）をサービス提供実績に基づいて行う場合に、請求済みの数量と実際に提供した数量を突き合わせるための記録です。レコードは請求書の作成時に自動生成され、利用者は提供実績を明細行として追加していきます。

📌 ポイント: iDempiere 13 標準では、このウィンドウは無効化されており標準メニューに登録されていません（旧バージョンからの互換用）。新規の業務設計での利用は推奨されません。サービスの期間按分は収益認識の「期間ベース」方式で扱うのが一般的です。

サービスレベルでできること

Section titled “サービスレベルでできること”
  • 収益認識計画に紐づくサービスレベルの照会
  • 品目ごとの請求数量（請求数量）と提供数量（提供数量）の確認
  • サービス提供実績の追加登録（サービスレベル詳細タブ）
  • 提供日（サービス日付）単位での実績の記録
  • 提供実績に基づく収益認識金額の更新

画面構成

Section titled “画面構成”

サービスレベルは2タブ構成です。

タブ名テーブル項目数役割
サービスレベルC_ServiceLevel9項目収益認識計画・品目・請求数量／提供数量（自動生成）
サービスレベル詳細C_ServiceLevelLine7項目提供実績の明細（利用者が追加）

💡 ヒント: ヘッダの 提供数量 は直接編集するのではなく、詳細タブに行を追加することで積み上げるのが本来の使い方です（AD の説明にも “Add new service level lines to change the recognized amount” と明記されています）。

基本操作手順

Section titled “基本操作手順”
graph TD
    A["📄 収益認識付き品目で<br/>請求書を作成・完了"] --> B["⚙️ サービスレベルが<br/>自動生成される"]
    B --> C["🔍 サービスレベル画面で<br/>対象レコードを検索"]
    C --> D["📊 請求数量と提供数量を確認"]
    D --> E["➕ サービスレベル詳細タブで<br/>新規行を追加"]
    E --> F["📅 サービス日付と<br/>提供数量を入力"]
    F --> G["💾 保存"]
    G --> H["💰 収益認識処理で<br/>認識額が更新される"]

収益認識付き品目で 請求書を作成・完了 サービスレベルが 自動生成される サービスレベル画面で 対象レコードを検索 請求数量と提供数量を確認 サービスレベル詳細タブで 新規行を追加 サービス日付と 提供数量を入力 保存 収益認識処理で 認識額が更新される

アクセス方法（メニューパス）

Section titled “アクセス方法（メニューパス）”

iDempiere 13 標準ではこのウィンドウはメニューに登録されていません。参照する場合は、システム管理者がロールのウィンドウアクセス権とメニュー項目を追加する必要があります。

⚠️ 注意: サービスレベルのレコードは手動では作成しません。収益認識ルールを設定した品目を含む請求書を作成した時点で自動生成されます。画面から新規作成しようとすると、必須項目である 収益認識計画 を手で選ぶ必要があり、整合性が崩れる原因になります。

提供実績の追加（サービスレベル詳細）

Section titled “提供実績の追加（サービスレベル詳細）”
  1. 対象のサービスレベルレコードを選択
  2. 「サービスレベル詳細」タブに移動
  3. 「新規」で行を追加し、必須項目を入力:
    • サービス日付: サービスを提供した日
    • 提供数量: この日に提供した数量
    • 説明: 実績の補足（任意）
  4. 「保存」をクリック

項目リファレンス

Section titled “項目リファレンス”

サービスレベルタブ

Section titled “サービスレベルタブ”
項目名必須型説明
クライアント必須選択テナント
組織必須選択組織
収益認識計画必須選択紐づく収益認識計画
品目必須検索対象の品目・サービス
請求数量必須数値請求済みの数量
提供数量必須数値提供済みの数量
説明-文字列(255)補足説明
処理中-ボタン処理実行ボタン
有効必須チェックレコードが有効か（既定 Y）

サービスレベル詳細タブ

Section titled “サービスレベル詳細タブ”
項目名必須型説明
サービスレベル必須選択親のサービスレベル
サービス日付必須日付サービス提供日
提供数量必須数値当該行で提供した数量
説明-文字列(255)補足説明
有効必須チェックレコードが有効か

全項目一覧はリファレンス参照

よくある質問（FAQ）

Section titled “よくある質問（FAQ）”

Q. サービスレベルのレコードが作られません

Section titled “Q. サービスレベルのレコードが作られません”

サービスレベルは、収益認識ルール（サービスレベル方式）を設定した品目を含む請求書を作成したときにのみ生成されます。品目マスタの「収益認識方法」と収益認識の設定を確認してください。

Q. ヘッダの「提供数量」を直接書き換えてもよいですか？

Section titled “Q. ヘッダの「提供数量」を直接書き換えてもよいですか？”

推奨されません。AD の説明でも詳細行の追加によって認識額を変えるとされています。ヘッダの 提供数量（ServiceLevelProvided）は IsUpdateable=N（更新不可）として定義されており、画面から直接編集する想定になっていません。

Q. 「請求数量」より多い「提供数量」を登録できますか？

Section titled “Q. 「請求数量」より多い「提供数量」を登録できますか？”

C_ServiceLevel / C_ServiceLevelLine には専用の M クラスが存在せず（生成クラス X_C_ServiceLevel / X_C_ServiceLevelLine のみ）、コア側に数量の上限チェックはありません。過剰な提供実績の入力を防ぎたい場合は Model Validator による検証追加が必要です。

Q. なぜこの画面は非推奨なのですか？

Section titled “Q. なぜこの画面は非推奨なのですか？”

iDempiere 13 標準ではウィンドウ自体が無効化されており、標準メニューにも未登録です。ロジックを持つ M クラスも用意されていないため、サービス提供実績に基づく収益認識を実運用するには追加開発が前提になります。

関連機能

Section titled “関連機能”
🛠 技術仕様（開発者向け）

概要

Section titled “概要”

サービスレベルは C_ServiceLevel（ヘッダ）と C_ServiceLevelLine（明細）に格納されます。両テーブルともアクセスレベル 1（システムのみ）・削除可で、専用の M クラスは存在しません。提供されるのは AD から自動生成された X_C_ServiceLevel（322行）と X_C_ServiceLevelLine（265行）のみで、beforeSave() / afterSave() によるコア検証は実装されていません。Document 型ではありませんが、Processed と Processing（ボタン）カラムを持ちます。

アーキテクチャ概要

Section titled “アーキテクチャ概要”
classDiagram
    class X_C_ServiceLevel {
        <<generated>>
        +getC_RevenueRecognition_Plan_ID() int
        +getM_Product_ID() int
        +getServiceLevelInvoiced() BigDecimal
        +getServiceLevelProvided() BigDecimal
        +isProcessed() boolean
    }
    class X_C_ServiceLevelLine {
        <<generated>>
        +getC_ServiceLevel_ID() int
        +getServiceDate() Timestamp
        +getServiceLevelProvided() BigDecimal
    }
    class I_C_ServiceLevel {
        <<interface>>
    }
    class PO {
        <<abstract>>
    }
    X_C_ServiceLevel --|> PO
    X_C_ServiceLevelLine --|> PO
    X_C_ServiceLevel ..|> I_C_ServiceLevel
    X_C_ServiceLevel --> X_C_ServiceLevelLine : has many

<> +getC_RevenueRecognition_Plan_ID() int +getM_Product_ID() int +getServiceLevelInvoiced() BigDecimal +getServiceLevelProvided() BigDecimal +isProcessed() boolean <> +getC_ServiceLevel_ID() int +getServiceDate() Timestamp +getServiceLevelProvided() BigDecimal <> <> > PO X_C_ServiceLevelLine --

パッケージ: org.compiere.model ソースファイル: org.adempiere.base/src/org/compiere/model/X_C_ServiceLevel.java、X_C_ServiceLevelLine.java

関連DBテーブル

Section titled “関連DBテーブル”

C_ServiceLevel（サービスレベル）

Section titled “C_ServiceLevel（サービスレベル）”
カラム名型必須説明備考
C_ServiceLevel_IDIDPKサービスレベルID主キー
C_ServiceLevel_UUUUID(36)NUUID
AD_Client_IDTable DirectYクライアント既定 @#AD_Client_ID@
AD_Org_IDTable DirectY組織既定 @#AD_Org_ID@
C_RevenueRecognition_Plan_IDTable DirectY収益認識計画更新不可
M_Product_IDSearchY品目更新不可
ServiceLevelInvoicedNumberY請求数量更新不可
ServiceLevelProvidedNumberY提供数量更新不可・明細から積み上げ
DescriptionString(255)N説明
ProcessedYes-NoN処理済み
ProcessingButtonN処理中処理実行ボタン
IsActiveYes-NoY有効既定 Y

C_ServiceLevelLine（サービスレベル詳細）

Section titled “C_ServiceLevelLine（サービスレベル詳細）”
カラム名型必須説明備考
C_ServiceLevelLine_IDIDPK明細ID主キー
C_ServiceLevel_IDTable DirectYサービスレベルFK更新不可
ServiceDateDateYサービス日付更新不可
ServiceLevelProvidedNumberY提供数量更新不可
DescriptionString(255)N説明
ProcessedYes-NoN処理済み
IsActiveYes-NoY有効既定 Y

📌 ポイント: 主要カラムがいずれも IsUpdateable=N（更新不可）で定義されています。これは「実績は追記していく」設計思想を表しており、誤登録の訂正は行の削除＋再登録で行います。

ER図

Section titled “ER図”
erDiagram
    C_ServiceLevel ||--o{ C_ServiceLevelLine : "actual delivery lines"
    C_ServiceLevel }o--|| C_RevenueRecognition_Plan : "plan"
    C_ServiceLevel }o--|| M_Product : "service product"
    C_RevenueRecognition_Plan }o--|| C_RevenueRecognition : "rule"
    C_RevenueRecognition_Plan }o--|| C_InvoiceLine : "from invoice line"

actual delivery lines service product from invoice line

ビジネスロジック

Section titled “ビジネスロジック”

C_ServiceLevel / C_ServiceLevelLine には M クラスが存在しないため、コア側にビジネスロジックはありません。生成クラスが提供するのは各カラムのアクセサと getKeyNamePair() のみです。

したがって次の挙動はコアでは保証されません。

  • 明細の 提供数量 合計をヘッダへ集計する処理
  • 請求数量 と 提供数量 の整合チェック
  • Processing ボタン押下時の処理内容

サービスレベルのレコード自体は、収益認識ルールを持つ品目を含む請求書の処理時に生成されます（AD の説明: Service Levels are generated when an invoice with products based on revenue recognition rules are generated）。

拡張ポイント（カスタマイズ箇所）

Section titled “拡張ポイント（カスタマイズ箇所）”

Callout

Section titled “Callout”

C_ServiceLevel / C_ServiceLevelLine のカラムには Callout の登録がありません。

OSGi Model Validator（推奨）

Section titled “OSGi Model Validator（推奨）”

M クラスが無いため、テーブル名で判定する Model Validator が実装の中心になります。

public class CustomServiceLevelValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if ("C_ServiceLevelLine".equals(po.get_TableName()) && type == TYPE_AFTER_NEW) {
            // 例: 明細の提供数量をヘッダへ集計する
            int serviceLevelId = po.get_ValueAsInt("C_ServiceLevel_ID");
            // C_ServiceLevel.ServiceLevelProvided を SUM で更新するなど
        }
        return null;
    }
}

独自 M クラスの登録

Section titled “独自 M クラスの登録”

集計・検証をモデル層に集約したい場合は、X_C_ServiceLevel を継承したクラスを作成し、OSGi の IModelFactory サービスとして登録します。これによりコアの MTable.getPO() から独自クラスが返るようになります。

代替設計の検討

Section titled “代替設計の検討”

サービス提供実績に応じた収益按分が目的であれば、この非推奨ウィンドウを有効化するより、収益認識の期間ベース方式や、プロジェクト管理の進捗ベース計上を検討するほうが保守しやすい構成になります。

関連ドキュメント

Section titled “関連ドキュメント”

iDempiereカスタマイズのご相談

Section titled “iDempiereカスタマイズのご相談”

サービスレベルはコアにロジックを持たないため、実績連動の収益認識を行うには集計・検証の実装が必要です。要件に合う方式（サービスレベル方式か期間按分か）の選定からご相談いただけます。

Ａｓ－Ｌｉｎｋ株式会社では、OSGiプラグインによる安全なカスタマイズを提供しています。

OSS ERP導入・カスタマイズサービスの詳細はこちら