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

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

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

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

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

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

画面構成

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

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

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

基本操作手順

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

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

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

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

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

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

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

項目リファレンス

サービスレベルタブ

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

サービスレベル詳細タブ

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

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

よくある質問（FAQ）

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

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

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

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

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

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

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

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

関連機能

• 収益認識（Revenue Recognition）の使い方
• 品目マスタの使い方
• 売上請求（Sales Invoice）の使い方
• 画面リファレンス: サービスレベル

🛠 技術仕様（開発者向け）

概要

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

アーキテクチャ概要

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テーブル

C_ServiceLevel（サービスレベル）

カラム名	型	必須	説明	備考
C_ServiceLevel_ID	ID	PK	サービスレベルID	主キー
C_ServiceLevel_UU	UUID(36)	N	UUID
AD_Client_ID	Table Direct	Y	クライアント	既定 @#AD_Client_ID@
AD_Org_ID	Table Direct	Y	組織	既定 @#AD_Org_ID@
C_RevenueRecognition_Plan_ID	Table Direct	Y	収益認識計画	更新不可
M_Product_ID	Search	Y	品目	更新不可
ServiceLevelInvoiced	Number	Y	請求数量	更新不可
ServiceLevelProvided	Number	Y	提供数量	更新不可・明細から積み上げ
Description	String(255)	N	説明
Processed	Yes-No	N	処理済み
Processing	Button	N	処理中	処理実行ボタン
IsActive	Yes-No	Y	有効	既定 Y

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

カラム名	型	必須	説明	備考
C_ServiceLevelLine_ID	ID	PK	明細ID	主キー
C_ServiceLevel_ID	Table Direct	Y	サービスレベルFK	更新不可
ServiceDate	Date	Y	サービス日付	更新不可
ServiceLevelProvided	Number	Y	提供数量	更新不可
Description	String(255)	N	説明
Processed	Yes-No	N	処理済み
IsActive	Yes-No	Y	有効	既定 Y

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

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

ビジネスロジック

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

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

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

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

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

Callout

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

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 クラスの登録

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

代替設計の検討

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

関連ドキュメント

• 画面リファレンス: サービスレベル
• 収益認識の技術仕様
• 品目マスタの技術仕様

---

iDempiereカスタマイズのご相談

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

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

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