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

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

リクエスト決定（Resolution）は、リクエストが「どのように決着したか」を表す解決区分のマスタです。標準の説明にある例は「修正済（Fixed）」「却下（Rejected）」で、対応の結末を分類するために使います。

📌 ポイント: ステータス（進行状態）と決定（結末の種類）は別物です。「クローズ」というステータスに至った理由が、修正なのか、却下なのか、重複なのかを記録するのが決定の役割です。集計・分析の軸になるため、最初に少数の区分で設計するのが定石です。

リクエスト決定でできること

• 解決区分の定義（修正済、却下、重複、仕様どおり など）
• 説明・コメントによる各区分の適用基準の明文化
• リクエスト画面からの決定の選択
• 有効／無効フラグによる区分の世代管理
• 決定別のリクエスト集計・分析の軸づくり

画面構成

リクエスト決定は単一タブのシンプルなマスタです。

タブ名	テーブル	項目数	役割
リクエスト決定	R_Resolution	6項目	解決区分の基本情報（名称・説明・コメント）

💡 ヒント: 決定は分析の軸になります。区分を増やしすぎると集計が読みにくくなるため、まずは5〜7区分程度から始め、必要に応じて追加してください。

基本操作手順

graph TD
    A["🚀 メニューから開く<br/>取引先管理 > リクエスト管理 > リクエスト決定"] --> B["➕ 新規で決定を作成<br/>（名称は必須）"]
    B --> C["📝 説明・コメントに<br/>適用基準を記載"]
    C --> D["💾 保存"]
    D --> E["🔁 必要な区分を<br/>繰り返し登録"]
    E --> F["🔗 リクエスト画面の<br/>決定欄で選択可能に"]
    F --> G["📊 決定別の集計・<br/>傾向分析に活用"]

メニューから開く 取引先管理 > リクエスト管理 > リクエスト決定 新規で決定を作成 （名称は必須） 説明・コメントに 適用基準を記載 保存 必要な区分を 繰り返し登録 リクエスト画面の 決定欄で選択可能に 決定別の集計・ 傾向分析に活用

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

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

新規登録

1. ツールバーの「新規」ボタンをクリック
2. 基本情報を入力:
   • 名称（必須）: 決定の名称（例: 修正済、却下、重複、仕様どおり）
   • 説明: 短い説明（255文字まで）
   • コメント: どの場合にこの区分を選ぶかの判断基準（2,000文字まで）
3. 「保存」をクリック
4. 必要な区分の数だけ 1〜3 を繰り返します

⚠️ 注意: 決定はクライアント横断（アクセスレベル6＝システム＋クライアント）で定義できるテーブルです。システム管理者がシステムレベルで登録した区分は全テナントから参照されます。テナント固有の区分はテナントにログインした状態で登録してください。

代表的な決定区分の設計例

決定名	想定する場面	備考
修正済	障害・不具合を修正して解決	標準説明の例（Fixed）
却下	対応しないと判断	標準説明の例（Rejected）
重複	既存リクエストと同一内容	元のリクエストを説明欄に記載
仕様どおり	仕様上の正しい挙動	問い合わせ対応で頻出
再現不可	事象を再現できず終了	一定期間後に再オープン可

項目リファレンス

リクエスト決定タブ

項目名	必須	型	説明
クライアント	必須	選択	テナント（既定値は自動セット）
組織	必須	選択	組織（既定値は自動セット）
名称	必須	文字列（60）	決定の名称。識別子として使用
説明	-	文字列（255）	短い説明
コメント	-	テキスト（2000）	適用基準などのヒント
有効	-	チェック	既定値はY。外すと新規選択の対象外

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

よくある質問（FAQ）

Q. ステータスと決定はどう違いますか？

ステータス（R_Status）はリクエストの進行状態で、オープン／クローズ／最終クローズの属性やタイムアウトによる自動遷移を持ちます。決定（R_Resolution）は結末の種類を表す単純な分類マスタで、遷移や自動処理のロジックは持ちません。MRequest は両者を R_Status_ID と R_Resolution_ID という別々のフィールドで保持します。

Q. 決定は必須入力ですか？

R_Resolution_ID はリクエスト側の任意項目です。MRequest.getResolution() は R_Resolution_ID が 0 のとき null を返す実装になっており、未設定でもリクエストは成立します。クローズ時に決定を必須にしたい場合は Model Validator での追加チェックが必要です。

Q. 決定を削除できますか？

R_Resolution テーブルは削除可能（IsDeleteable=Y）ですが、リクエストから参照されている区分は外部キー制約で削除できません。使わなくなった区分は「有効」チェックを外して無効化してください。過去のリクエストの表示は保持されます。

Q. 名称を後から変更しても大丈夫ですか？

Name はリクエスト画面での表示名（識別子）です。名称を変更すると過去のリクエストの表示も変わります。区分の意味そのものが変わる場合は、名称変更ではなく新規区分の追加と旧区分の無効化を推奨します。

関連機能

• リクエスト（Request）の使い方
• リクエストステータスの使い方
• リクエストカテゴリの使い方
• リクエスト標準回答の使い方
• 画面リファレンス: リクエスト決定

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

概要

リクエスト決定はマスタデータ型のウィンドウで、R_Resolution テーブルに格納されます。モデルクラスは MResolution（159行）で、X_R_Resolution を継承し ImmutablePOSupport を実装しています。Document 型ではなく DocAction / DocStatus は持ちません。

テーブル	アクセスレベル	削除可	大量データ	ビュー
R_Resolution	6（システム＋クライアント）	Y	N	N

アーキテクチャ概要

classDiagram
    class MResolution {
        +get(ctx, R_Resolution_ID) MResolution
        +getCopy(ctx, R_Resolution_ID, trxName) MResolution
        +markImmutable() MResolution
    }
    class X_R_Resolution {
        <<generated>>
    }
    class PO {
        <<abstract>>
    }
    class ImmutablePOSupport {
        <<interface>>
    }
    MResolution --|> X_R_Resolution
    X_R_Resolution --|> PO
    MResolution ..|> ImmutablePOSupport
    MRequest --> MResolution : getResolution()

+get(ctx, R_Resolution_ID) MResolution +getCopy(ctx, R_Resolution_ID, trxName) MResolution +markImmutable() MResolution <> <> <> > X_R_Resolution X_R_Resolution --

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

関連DBテーブル

R_Resolution（リクエスト決定）

カラム名	型	必須	説明	備考
R_Resolution_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	コメント／ヒント
IsActive	Yes-No	Y	有効	既定値 Y
R_Resolution_UU	UUID	N	UUID

ER図

erDiagram
    R_Resolution ||--o{ R_Request : "resolution of"
    R_Request }o--|| R_Status : "status"
    R_Request }o--o| R_Category : "category"
    R_Request }o--o| R_Group : "group"

resolution of

ビジネスロジック

MResolution は beforeSave() / afterSave() をオーバーライドしていない薄いマスタクラスです。提供するのは以下のアクセサのみで、バリデーションは AD 定義（Name 必須）とDB制約に委ねられています。

メソッド	役割
get(ctx, R_Resolution_ID)	キャッシュ経由の読み取り専用インスタンス取得
getCopy(ctx, R_Resolution_ID, trxName)	更新可能なコピーの取得
markImmutable()	イミュータブル化（キャッシュ格納用）

リクエスト側からの参照

MRequest には決定を扱う2つのメソッドがあります。

• getResolution(): R_Resolution_ID が 0 なら null、それ以外は MResolution.getCopy() を返す
• getResolutionName(): 決定名を返す（未設定時は空）

決定の選択自体に副作用はなく、ステータス遷移とは独立しています。

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

OSGi Model Validator（推奨）

クローズ時の決定必須化は、R_Request 側の Model Validator で実装します。

public class CustomRequestResolutionValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MRequest && (type == TYPE_BEFORE_CHANGE)) {
            MRequest r = (MRequest) po;
            MStatus status = MStatus.get(r.getCtx(), r.getR_Status_ID());
            // 例: クローズ状態へ遷移するときは決定を必須にする
            if (status != null && status.isClosed() && r.getR_Resolution_ID() == 0) {
                throw new AdempiereException("クローズするには決定（Resolution）を選択してください");
            }
        }
        return null;
    }
}

Callout

R_Resolution のカラムには標準 Callout が設定されていません。決定選択時に結果テキストを自動補完したい場合は、R_Request 側に独自 Callout を追加します（標準では R_StandardResponse_ID に同種の Callout CalloutRequest.copyResponse があり、実装の参考になります）。

関連ドキュメント

• 操作マニュアル: リクエスト
• リクエストステータスの技術仕様
• リクエスト標準回答の技術仕様
• 画面リファレンス: リクエスト決定

---

iDempiereカスタマイズのご相談

解決区分は、サポート品質を数値で語るための基礎データです。決定必須化やクローズ理由の統計レポートは、Model Validator とカスタムレポートで無理なく実現できます。

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

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