iDempiere リクエストグループの使い方｜取引先管理 操作マニュアル・技術仕様

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

リクエストグループは、リクエストを「バージョン番号」「責任区分」といった括りでまとめるためのマスタです。カテゴリが話題の分類であるのに対し、グループは対応の単位・まとまりを表します。部品表（BOM）を参照するグループを作ると、設計変更依頼（BOM Change Request）との連携が可能になります。

📌 ポイント: グループに部品表を設定しておくと、リクエストのグループを変更したときに、紐付いた設計変更依頼（M_ChangeRequest）の部品表・変更通知が自動的に追従します。製造業の設計変更管理と問い合わせ管理をつなぐ要のマスタです。

リクエストグループでできること

• リリースバージョン・責任区分などによるリクエストのグルーピング
• グループごとの更新通知受信者（ユーザー）の登録
• 受信者ごとのセルフサービス可否の設定
• 部品表（PP_Product_BOM_ID）との紐付けによる設計変更管理との連携
• 変更通知（M_ChangeNotice_ID）との紐付け
• 説明・コメントによるグループ運用ルールの明文化

画面構成

リクエストグループは2タブ構成です。

タブ名	テーブル	項目数	役割
リクエストグループ	R_Group	7項目	グループの基本情報（名称・説明・部品表）
リクエスト更新	R_GroupUpdates	6項目	このグループの更新を受け取るユーザーの一覧

💡 ヒント: 一般的な問い合わせ管理では部品表の設定は不要です。製造業で設計変更（ECR/ECN）とリクエストを連携させたい場合にのみ設定してください。

基本操作手順

graph TD
    A["🚀 メニューから開く<br/>取引先管理 > リクエスト管理 > リクエストグループ"] --> B["➕ 新規でグループを作成<br/>（名称は必須）"]
    B --> C{用途}
    C -->|一般の問い合わせ管理| D["📝 説明・コメントを入力<br/>（例: v1.7 リリース分）"]
    C -->|設計変更と連携| E["🧩 部品表を選択<br/>必要なら変更通知も設定"]
    D --> F["💾 保存"]
    E --> F
    F --> G{更新通知を出す?}
    G -->|はい| H["👥 リクエスト更新タブで<br/>受信ユーザーを登録"]
    G -->|いいえ| I["✅ 登録完了"]
    H --> I
    I --> J["🔗 リクエスト画面の<br/>グループ欄で選択可能に"]

メニューから開く 取引先管理 > リクエスト管理 > リクエストグループ 新規でグループを作成 （名称は必須） 説明・コメントを入力 （例: v1.7 リリース分） 部品表を選択 必要なら変更通知も設定 保存 リクエスト更新タブで 受信ユーザーを登録 登録完了 リクエスト画面の グループ欄で選択可能に 用途 更新通知を出す? 一般の問い合わせ管理 設計変更と連携 はい いいえ

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

メニューから「取引先管理 > リクエスト管理 > リクエストグループ」を開きます（AD_Window_ID: 346）。

新規登録

1. ツールバーの「新規」ボタンをクリック
2. 基本情報を入力:
   • 名称（必須）: グループ名（例: v1.7リリース、品質保証部対応）
   • 説明: 短い説明（255文字まで）
   • コメント: 運用上のヒント（2,000文字まで）
   • 部品表(BOM & Formula): 設計変更と連携する場合に選択
3. 「保存」をクリック

更新通知の受信者を登録する

1. グループを保存後、「リクエスト更新」タブに移動
2. 「新規」で受信者を追加:
   • ユーザー（必須）: 通知を受け取るユーザー／連絡先
   • セルフサービス: セルフサービス経由で扱えるエントリの場合にチェック
3. 「保存」をクリック

⚠️ 注意: 部品表を後から変更すると、そのグループに紐付く未処理の設計変更依頼の部品表・変更通知が自動更新されます（MRequest.afterSave() のロジック）。処理済みかつ修正変更通知が設定済みの依頼は更新されません。

項目リファレンス

リクエストグループタブ

項目名	必須	型	説明
クライアント	必須	選択	テナント（既定値は自動セット）
組織	必須	選択	組織（既定値は自動セット）
名称	必須	文字列（60）	グループ名。識別子として使用
説明	-	文字列（255）	短い説明
コメント	-	テキスト（2000）	運用上のヒント
有効	-	チェック	既定値はY
部品表(BOM & Formula)	-	検索	設計変更と連携する部品表

リクエスト更新タブ

項目名	必須	型	説明
グループ	必須	選択	親グループ（自動セット）
ユーザー	必須	検索	更新を受け取るユーザー／連絡先
セルフサービス	必須	チェック	セルフサービスで変更可能なエントリか
有効	-	チェック	既定値はY

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

よくある質問（FAQ）

Q. カテゴリとグループはどう使い分けますか？

カテゴリ（R_Category）は「何についての問い合わせか」という話題の分類、グループ（R_Group）は「どのまとまりで対応するか」という括りです。標準の説明でもグループの例として「バージョン番号、責任区分」が挙げられています。両者は独立したフィールドなので、カテゴリ×グループの組み合わせで管理できます。

Q. 部品表を設定するとBOM変更依頼が自動作成されますか？

AD 上のグループの説明には「リクエストタイプで部品表が参照され有効化されている場合、BOM変更依頼が自動作成される」と記載されています。実際の連携ロジックは MRequest.afterSave() にあり、リクエストに設計変更依頼（M_ChangeRequest_ID）が既に存在する状態でグループを変更すると、新しいグループの PP_Product_BOM_ID と M_ChangeNotice_ID が設計変更依頼側へ反映されます。

Q. グループを削除できますか？

R_Group テーブルは削除可能（IsDeleteable=Y）ですが、リクエストから参照されている場合は外部キー制約で削除できません。運用中のグループは「有効」チェックを外して無効化してください。

Q. 更新通知タブに登録したユーザーには自動でメールが飛びますか？

R_GroupUpdates は受信者の一覧を保持するテーブルです（AD 上の説明は「リクエスト更新を受け取る受信者の一覧」）。実際の送信可否・送信経路はリクエストタイプやユーザー側の通知設定に依存するため、導入時に実環境での動作確認を行ってください。

関連機能

• リクエスト（Request）の使い方
• リクエストカテゴリの使い方
• リクエストステータスの使い方
• リクエスト決定の使い方
• 画面リファレンス: リクエストグループ

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

概要

リクエストグループはマスタデータ型のウィンドウで、R_Group テーブルに格納されます。モデルクラスは MGroup（159行）で、X_R_Group を継承し ImmutablePOSupport を実装しています。Document 型ではありません。子タブの R_GroupUpdates には専用 M クラスがなく、生成クラス X_R_GroupUpdates のみが提供されます。

テーブル	アクセスレベル	削除可	大量データ
R_Group	6（システム＋クライアント）	Y	N
R_GroupUpdates	7（すべて）	Y	N

アーキテクチャ概要

classDiagram
    class MGroup {
        +get(ctx, R_Group_ID) MGroup
        +getCopy(ctx, R_Group_ID, trxName) MGroup
        +markImmutable() MGroup
    }
    class X_R_Group {
        <<generated>>
    }
    class X_R_GroupUpdates {
        <<generated>>
    }
    class PO {
        <<abstract>>
    }
    class ImmutablePOSupport {
        <<interface>>
    }
    MGroup --|> X_R_Group
    X_R_Group --|> PO
    X_R_GroupUpdates --|> PO
    MGroup ..|> ImmutablePOSupport
    MRequest --> MGroup : getGroup()
    MGroup --> MChangeRequest : BOM & ChangeNotice

+get(ctx, R_Group_ID) MGroup +getCopy(ctx, R_Group_ID, trxName) MGroup +markImmutable() MGroup <> <> <> > X_R_Group X_R_Group -- > PO MGroup ..

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

関連DBテーブル

R_Group（リクエストグループ）

カラム名	型	必須	説明	備考
R_Group_ID	ID	PK	グループID	主キー
AD_Client_ID	Table Direct	Y	テナント	既定値 @#AD_Client_ID@
AD_Org_ID	Table Direct	Y	組織	既定値 @#AD_Org_ID@
Name	String(60)	Y	名称	識別子（IsIdentifier=Y）
Description	String(255)	N	説明
Help	Text(2000)	N	コメント／ヒント
PP_Product_BOM_ID	Search	N	部品表	設計変更連携用
M_ChangeNotice_ID	Table Direct	N	変更通知	設計変更通知（版）
IsActive	Yes-No	Y	有効	既定値 Y
R_Group_UU	UUID	N	UUID

R_GroupUpdates（更新通知の受信者）

カラム名	型	必須	説明
R_Group_ID	Table Direct	Y	親グループFK（IsParent=Y）
AD_User_ID	Search	Y	受信ユーザーFK（IsParent=Y）
IsSelfService	Yes-No	Y	セルフサービスエントリ
IsActive	Yes-No	Y	有効
R_GroupUpdates_UU	UUID	N	UUID

ER図

erDiagram
    R_Group ||--o{ R_GroupUpdates : "notification recipients"
    R_Group ||--o{ R_Request : "groups"
    R_GroupUpdates }o--|| AD_User : "recipient"
    R_Group }o--o| PP_Product_BOM : "BOM link"
    R_Group }o--o| M_ChangeNotice : "change notice"
    R_Request }o--o| M_ChangeRequest : "ECR"

notification recipients BOM link change notice

ビジネスロジック

MGroup 自体は beforeSave() / afterSave() をオーバーライドしておらず、キャッシュ取得（get）・コピー取得（getCopy）・イミュータブル化（markImmutable）を提供する薄いマスタクラスです。グループの業務的な意味づけは MRequest 側に実装されています。

設計変更依頼への追従（MRequest.afterSave）

flowchart TD
    A["リクエスト保存 afterSave"] --> B{"M_ChangeRequest_ID != 0 かつ<br/>R_Group_ID が変更された?"}
    B -->|いいえ| Z["何もしない"]
    B -->|はい| C{"新しい R_Group_ID = 0?"}
    C -->|はい| D["M_ChangeRequest_ID を 0 にする"]
    C -->|いいえ| E["旧グループと新グループを取得"]
    E --> F{"PP_Product_BOM_ID または<br/>M_ChangeNotice_ID が異なる?"}
    F -->|いいえ| Z
    F -->|はい| G{"ECR が未処理 または<br/>修正変更通知が未設定?"}
    G -->|いいえ| Z
    G -->|はい| H["ECR の PP_Product_BOM_ID と<br/>M_ChangeNotice_ID を更新して保存"]

リクエスト保存 afterSave M_ChangeRequest_ID != 0 かつ R_Group_ID が変更された? 何もしない 新しい R_Group_ID = 0? M_ChangeRequest_ID を 0 にする 旧グループと新グループを取得 PP_Product_BOM_ID または M_ChangeNotice_ID が異なる? ECR が未処理 または 修正変更通知が未設定? ECR の PP_Product_BOM_ID と M_ChangeNotice_ID を更新して保存 いいえ はい

このロジックにより、リクエストのグループ付け替えが設計変更依頼（M_ChangeRequest）へ伝播します。

リクエスト側からの参照

MRequest.getGroup() は R_Group_ID が 0 のとき null を返し、それ以外は MGroup.getCopy() を返します。表示名は getGroupName() で取得します。

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

OSGi Model Validator（推奨）

public class CustomRequestGroupValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MGroup) {
            MGroup group = (MGroup) po;
            if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
                // 例: 設計変更連携グループは部品表と変更通知の両方を必須にする
                if (group.getPP_Product_BOM_ID() > 0 && group.getM_ChangeNotice_ID() == 0) {
                    throw new AdempiereException("部品表を設定したグループには変更通知も設定してください");
                }
            }
        }
        return null;
    }
}

Callout

R_Group / R_GroupUpdates のカラムには標準 Callout が設定されていません。部品表選択時に変更通知を自動セットするなどの連動が必要な場合は、独自 Callout を OSGi サービスとして登録します。

設計変更フローの拡張

MRequest.afterSave() の ECR 追従ロジックを拡張したい場合は、コアを改変せず R_Request の modelChange イベント（TYPE_AFTER_CHANGE）で M_ChangeRequest を操作する実装が安全です。

関連ドキュメント

• 操作マニュアル: リクエスト
• リクエストカテゴリの技術仕様
• リクエストステータスの技術仕様
• 画面リファレンス: リクエストグループ

---

iDempiereカスタマイズのご相談

リクエストグループは、問い合わせ管理と設計変更管理（ECR/ECN）をつなぐ数少ない接点です。製造業での不具合報告から設計変更までを一気通貫で回す運用は、OSGiプラグインによる拡張で実現できます。

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

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