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

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

リクエスト(すべて)は、担当者による絞り込みを行わずに組織内のすべてのリクエストを横断して照会・対応する管理者向けウィンドウです。扱うテーブルはリクエストウィンドウと同じ R_Request で、対応履歴・更新通知の受取人までを1画面で確認できます。

📌 ポイント: 通常の「リクエスト」ウィンドウが自分に割り当てられた案件だけを表示するのに対し、こちらは全件が対象です。未割当・放置されている案件や、他部署が抱えている案件の棚卸しにはこのウィンドウを使います。

リクエスト(すべて)でできること

• 担当者を問わない全リクエストの照会・編集
• リクエストタイプ・カテゴリ・グループ・ステータス・結果による分類管理
• 優先度（システム側 優先度 とユーザー側 ユーザー優先度）の二重管理とエスカレーション
• 対応経過の記録（更新タブ）と変更履歴の追跡（履歴タブ）
• 更新通知の受取人管理（更新通知タブ）と、実際に通知が飛ぶ相手の確認（受取人更新タブ）
• 機密レベル（機密レベル / エントリ機密レベル）による情報公開範囲の制御
• 取引先・受注伝票・請求伝票・資産・プロジェクトなど業務オブジェクトとの紐付け
• 作業時間（開始時間 / 終了時間）と使用製品・使用数量の記録、請求への連携

画面構成

リクエスト(すべて)は5タブ構成です。

タブ名	テーブル	項目数	役割
リクエスト	R_Request	55項目	案件本体（分類・優先度・関連オブジェクト）
更新	R_RequestUpdate	10項目	対応経過の追記（結果・使用数量）
履歴	R_RequestAction	32項目	変更前の値を保持する変更履歴
更新通知	R_RequestUpdates	6項目	更新通知を受け取るユーザーの登録
受取人更新	RV_RequestUpdates	8項目	実際に通知される受取人の一覧（ビュー・読取専用）

graph TD
    T1["📋 リクエスト<br/>R_Request<br/>55項目"]
    T2["✍️ 更新<br/>R_RequestUpdate<br/>10項目"]
    T3["🕘 履歴<br/>R_RequestAction<br/>32項目"]
    T4["🔔 更新通知<br/>R_RequestUpdates<br/>6項目"]
    T5["👥 受取人更新<br/>RV_RequestUpdates<br/>8項目・ビュー"]
    T1 --> T2
    T1 --> T3
    T1 --> T4
    T1 --> T5

リクエスト R_Request 55項目 更新 R_RequestUpdate 10項目 履歴 R_RequestAction 32項目 更新通知 R_RequestUpdates 6項目 受取人更新 RV_RequestUpdates 8項目・ビュー

💡 ヒント: 「履歴」タブに表示されるのは変更前（OLD）の値です。現在値はヘッダ側にあります。「いつ誰が何を変えたか」を追う場合は、履歴タブの 作成日 / 作成者 と各カラムを見比べてください。

基本操作手順

graph TD
    A["🚀 メニューから開く<br/>取引先管理 > リクエスト管理 > リクエスト(すべて)"] --> B["🔍 条件で絞り込み<br/>（ステータス・期限タイプ・担当者）"]
    B --> C{対応方針}
    C -->|担当を割り当てる| D["👤 社内担当者・ロールを設定"]
    C -->|経過を記録する| E["✍️ 更新タブで<br/>対応結果を追記"]
    C -->|優先度を上げる| F["⬆️ 優先度・ユーザー優先度を変更"]
    C -->|通知先を増やす| G["🔔 更新通知タブに<br/>ユーザーを追加"]
    D --> H["💾 保存"]
    E --> H
    F --> H
    G --> H
    H --> I["🕘 履歴タブで<br/>変更内容を確認"]
    I --> J{完了したか}
    J -->|はい| K["✅ ステータスをクローズ系に変更<br/>（クローズ日付が自動セット）"]
    J -->|いいえ| B

メニューから開く 取引先管理 > リクエスト管理 > リクエスト(すべて) 条件で絞り込み （ステータス・期限タイプ・担当者） 社内担当者・ロールを設定 更新タブで 対応結果を追記 優先度・ユーザー優先度を変更 更新通知タブに ユーザーを追加 保存 履歴タブで 変更内容を確認 ステータスをクローズ系に変更 （クローズ日付が自動セット） 対応方針 完了したか 担当を割り当てる 経過を記録する 優先度を上げる 通知先を増やす はい いいえ

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

メニューから「取引先管理 > リクエスト管理 > リクエスト(すべて)」を開きます。

新規登録（必須項目ベースの手順）

1. ツールバーの「新規」ボタンをクリック
2. 必須項目を入力:
   • 伝票番号: 伝票順序から自動採番されます
   • リクエストタイプ: 問い合わせ・クレームなどの種別（必須）
   • サマリ: 案件の要約（必須）
   • 優先度: 既定は 5（中）
   • 期限タイプ: 既定は 5。保存時に次回対応日付から自動再計算されます
   • 機密レベル / エントリ機密レベル: 既定は C
   • リクエスト金額: 必須項目
3. 任意で関連情報を設定:
   • 取引先 / ユーザー: 問い合わせ元
   • 社内担当者: 既定はログインユーザー（@#AD_User_ID@）
   • 受注伝票 / 売上請求伝票 / 資産 / プロジェクト など関連オブジェクト
   • 次回対応日付: 期限管理の基準日
4. 「保存」をクリック

⚠️ 注意: リクエストタイプを選ぶと Callout（CalloutRequest.type）が動作し、タイプに応じた既定値が反映されます。また保存時に、選択中のステータスがリクエストタイプのステータスカテゴリと一致しない場合、ステータスが既定値へ自動リセットされます。

対応経過の記録

1. 「更新」タブに移動して「新規」
2. 対応結果（Result）に対応内容を記入
3. 必要に応じて 使用製品 / 使用数量 / 請求済数量 を入力
4. 保存すると、エントリ機密レベル が未設定の場合は自動的に「公開情報」がセットされます

ステータスとクローズ

ステータス（R_Status）は「オープン」「クローズ」「最終クローズ」の属性を持ちます。保存時の挙動は次のとおりです。

ステータス属性	保存時の自動処理
オープン	開始日付 が未設定なら現在日時をセット。クローズ日付 をクリア
クローズ	クローズ日付 が未設定なら現在日時をセット
最終クローズ	処理済み（Processed）を Y にセット

項目リファレンス

リクエストタブ（主要項目）

項目名	必須	型	説明
伝票番号	必須	文字列	伝票順序による採番
リクエストタイプ	必須	選択	問い合わせ・クレーム等の種別
サマリ	必須	テキスト	案件の要約
優先度	必須	リスト	システム側の優先度（既定 5）
ユーザー優先度	-	リスト	利用者から見た重要度（既定 5）
期限タイプ	必須	リスト	予定／期限到来／期限超過（既定 5）
ステータス	-	選択	対応状況
結果	-	選択	解決区分
グループ	-	選択	リクエストグループ
カテゴリ	-	選択	リクエストカテゴリ
機密レベル	必須	リスト	案件全体の公開範囲（既定 C）
エントリ機密レベル	必須	リスト	個別エントリの公開範囲（既定 C）
社内担当者	-	選択	担当者（既定はログインユーザー）
ロール	-	選択	担当ロール（既定 -1）
次回対応日付	-	日時	次に対応すべき日
取引先	-	検索	問い合わせ元の取引先
ユーザー	-	選択	問い合わせ元の担当者（既定 -1）
標準回答	-	選択	定型回答（選択時に本文が複写される）
メールテンプレート	-	選択	送信用テンプレート（選択時に本文が複写される）
対応結果	-	テキスト	対応内容
リクエスト金額	必須	金額	案件に紐づく金額
エスカレート済	必須	チェック	エスカレーション済みか
セルフサービス	必須	チェック	セルフサービス経由か（既定 N）
処理済み	必須	チェック	最終クローズ時に自動セット

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

よくある質問（FAQ）

Q. 「リクエスト」ウィンドウとの違いは何ですか？

対象データの絞り込みが違うだけで、テーブル・項目は同一です。リクエストは自分に割り当てられた案件を、リクエスト(すべて)は全案件を表示します。管理者による棚卸しや未割当案件の発見に使います。

Q. 「期限タイプ」を手で変えても保存すると戻ってしまいます

MRequest.beforeSave() が毎回 setDueType() を呼び、次回対応日付 とリクエストタイプの許容日数（DueDateTolerance）から自動判定するためです。判定ロジックは次のとおりです。

条件	設定される期限タイプ
現在日時 < 次回対応日付	予定（Scheduled）
次回対応日付 ≦ 現在日時 ≦ 次回対応日付 + 許容日数	期限到来（Due）
現在日時 > 次回対応日付 + 許容日数	期限超過（Overdue）

次回対応日付 が未設定の場合は判定が行われず、既存値が維持されます。

Q. 優先度が勝手に変わります

MRequest.setPriority() が、取引先の所属する取引先グループの 優先度（PriorityBase）を参照して優先度を補正するためです。Lower なら2段階下げ、それ以外（Same 以外）なら2段階上げた値が計算され、High〜Low の範囲にクランプされます。既存の優先度より高い（数値が小さい）場合のみ上書きされます。

Q. 社内担当者を空にできません

MRequest.setSalesRep_ID() は 0 を渡す操作を無視します（警告ログのみ出力）。一度担当者を設定したリクエストから担当者を外すことはできない仕様です。別の担当者に付け替えてください。

Q. 更新通知タブと受取人更新タブの違いは？

「更新通知」（R_RequestUpdates）は手動で登録する購読者です。「受取人更新」（RV_RequestUpdates）は実際に通知が届く相手を算出したビューで、直接購読者（社内担当者・ユーザー・購読登録者）に加え、ロール経由・カテゴリ／タイプ／グループ経由の間接的な受取人も含まれます。読取専用です。

Q. 機密レベルを「公開情報」にしたのに個別エントリが公開になりません

MRequest.setConfidentialTypeEntry() が、案件全体の機密レベルより緩いエントリ機密レベルを許可しません。案件が「社内限定」ならエントリも強制的に「社内限定」に、「非公開」なら「社内限定」か「非公開」のみが許容されます。まず案件側の 機密レベル を緩めてください。

Q. リクエストの変更履歴が残らないケースはありますか？

履歴（R_RequestAction）は変更前の値を保持する仕組みです。MRequestAction は MRequestAction(MRequest request, boolean newRecord) コンストラクタで生成され、addNullColumn() により NULL だったカラムを ヌルカラム（NullColumns）に記録します。履歴の生成タイミングは呼び出し側の処理に依存します。

関連機能

• リクエストの使い方
• 取引先マスタ（Business Partner）の使い方
• 取引先グループの使い方
• メールテンプレートの使い方
• 画面リファレンス: リクエスト(すべて)

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

概要

リクエストは R_Request テーブル（アクセスレベル 7 = システム／クライアント／組織、削除可）に格納されます。モデルクラスは MRequest（1,208行）で、ステータス・優先度・期限タイプ・機密レベルの整合処理と、更新レコードの自動生成を担います。子テーブルはそれぞれ MRequestUpdate（129行）、MRequestAction（182行）が対応し、R_RequestUpdates は生成クラス X_R_RequestUpdates のみ、RV_RequestUpdates はビュー（IsView=Y）です。Document 型ではありませんが、Processed フラグとワークフロー的なステータス遷移を持ちます。

アーキテクチャ概要

classDiagram
    class MRequest {
        +beforeSave(boolean) boolean
        +afterSave(boolean, boolean) boolean
        +setDueType() void
        +setR_Status_ID() void
        +setConfidentialTypeEntry(String) void
        +doClose() void
        +doEscalate(boolean user) void
        +webUpdate(String) boolean
        +isWebCanUpdate() boolean
        +getActions() MRequestAction[]
        +getUpdates(String) MRequestUpdate[]
        -setPriority() void
    }
    class X_R_Request {
        <<generated>>
    }
    class MRequestUpdate {
        +beforeSave(boolean) boolean
        +isNewInfo() boolean
    }
    class MRequestAction {
        +addNullColumn(String) void
        +getChangesHTML() String
    }
    class PO {
        <<abstract>>
    }
    MRequest --|> X_R_Request
    X_R_Request --|> PO
    MRequest --> MRequestUpdate : creates
    MRequest --> MRequestAction : history
    MRequest --> MRequestType : type rules
    MRequest --> MStatus : status rules

+beforeSave(boolean) boolean +afterSave(boolean, boolean) boolean +setDueType() void +setR_Status_ID() void +setConfidentialTypeEntry(String) void +doClose() void +doEscalate(boolean user) void +webUpdate(String) boolean +isWebCanUpdate() boolean +getActions() MRequestAction[] +getUpdates(String) MRequestUpdate[] -setPriority() void <> +beforeSave(boolean) boolean +isNewInfo() boolean +addNullColumn(String) void +getChangesHTML() String <> > X_R_Request X_R_Request --

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

関連DBテーブル

R_Request（リクエスト）※主要カラム

カラム名	型	必須	説明	備考
R_Request_ID	ID	PK	リクエストID	主キー
DocumentNo	String	Y	伝票番号	伝票順序で採番
R_RequestType_ID	Table Direct	Y	リクエストタイプ	Callout CalloutRequest.type
R_Status_ID	Table Direct	N	ステータス	未設定時は既定へ
R_Resolution_ID	Table Direct	N	結果
R_Group_ID / R_Category_ID	Table Direct	N	グループ／カテゴリ
Priority	List	Y	優先度	既定 5
PriorityUser	List	N	ユーザー優先度	既定 5
DueType	List	Y	期限タイプ	既定 5・保存時に再計算
Summary	Text	Y	サマリ
ConfidentialType	List	Y	機密レベル	既定 C
ConfidentialTypeEntry	List	Y	エントリ機密レベル	既定 C・階層検証あり
SalesRep_ID	Table	N	社内担当者	既定 @#AD_User_ID@・0 設定不可
AD_Role_ID	Table Direct	N	ロール	既定 -1
AD_User_ID	Table Direct	N	ユーザー	既定 -1
DateNextAction	Date+Time	N	次回対応日付	期限判定の基準
StartDate / CloseDate	Date+Time	N	開始日付／クローズ日付	ステータス属性で自動セット
R_MailText_ID	Table Direct	N	メールテンプレート	Callout CalloutRequest.copyMail
R_StandardResponse_ID	Table Direct	N	標準回答	Callout CalloutRequest.copyResponse
RequestAmt	Amount	Y	リクエスト金額
IsSelfService	Yes-No	Y	セルフサービス	既定 N
IsEscalated	Yes-No	Y	エスカレート済
Processed	Yes-No	Y	処理済み	最終クローズで Y
AD_Table_ID / Record_ID / Record_UU	-	N	関連レコード参照	Record_UU は保存時に補完

R_RequestUpdate（更新）／R_RequestAction（履歴）

テーブル	主なカラム	役割
R_RequestUpdate	R_Request_ID / Result / QtySpent / QtyInvoiced / ConfidentialTypeEntry	対応経過の追記
R_RequestAction	R_Request_ID / 各業務カラムの旧値 / NullColumns	変更前の値のスナップショット

ER図

erDiagram
    R_Request ||--o{ R_RequestUpdate : "progress notes"
    R_Request ||--o{ R_RequestAction : "change history"
    R_Request ||--o{ R_RequestUpdates : "subscribers"
    R_Request }o--|| R_RequestType : "type"
    R_Request }o--o| R_Status : "status"
    R_Request }o--o| C_BPartner : "requester"
    R_Request }o--o| R_MailText : "mail template"
    R_RequestType }o--|| R_StatusCategory : "status category"

progress notes change history mail template status category

ビジネスロジック

beforeSave() の処理順序

flowchart TD
    A["beforeSave"] --> B{"新規 or リクエストタイプ変更?"}
    B -->|Yes| C["タイプから 請求済み と<br/>次回対応日付 の既定を反映"]
    C --> D{"ステータスのカテゴリが<br/>タイプと一致?"}
    D -->|No| E["ステータスを既定へリセット"]
    D -->|Yes| F["維持"]
    B -->|No| F
    E --> G["ステータス未設定なら既定をセット"]
    F --> G
    G --> H["setDueType で期限タイプを再計算"]
    H --> I{"ステータス属性"}
    I -->|オープン| J["開始日付をセット<br/>クローズ日付をクリア"]
    I -->|クローズ| K["クローズ日付をセット"]
    I -->|最終クローズ| L["Processed = Y"]
    J --> M["機密レベルの既定と階層検証"]
    K --> M
    L --> M
    M --> N["setPriority で優先度を補正"]
    N --> O["Record_ID から Record_UU を補完"]

新規 or リクエストタイプ変更? タイプから 請求済み と 次回対応日付 の既定を反映 ステータスのカテゴリが タイプと一致? ステータスを既定へリセット 維持 ステータス未設定なら既定をセット setDueType で期限タイプを再計算 ステータス属性 開始日付をセット クローズ日付をクリア クローズ日付をセット Processed = Y 機密レベルの既定と階層検証 setPriority で優先度を補正 Record_ID から Record_UU を補完 オープン クローズ 最終クローズ

主要ポイント:

1. リクエストタイプ変更時、IsInvoiced をタイプの設定に合わせ、DateNextAction が未設定かつ AutoDueDateDays > 0 なら「現在日時 + 自動期日日数」をセット
2. ステータスの整合性: MStatus.getR_StatusCategory_ID() とリクエストタイプの R_StatusCategory_ID が異なる場合、setR_Status_ID()（既定値）へリセット
3. 機密レベル: ConfidentialType 未設定ならリクエストタイプの値、それも無ければ「公開情報」
4. Record_UU の補完: Record_ID > 0 かつ AD_Table_ID > 0 で Record_UU が空なら、対象 PO の UUID を取得してセット

afterSave() の処理

//  Create Request Update record
if (newRecord && getResult() != null)
{
    MRequestUpdate update = new MRequestUpdate(this);
    update.saveEx();
}

• 新規かつ 対応結果 が入力済みの場合、R_RequestUpdate レコードを自動生成します
• M_ChangeRequest_ID が設定されたリクエストで R_Group_ID が変更された場合、変更要求（MChangeRequest）の BOM／変更通知を追随更新します（製造モジュール連携）

優先度の補正（setPriority）

MBPGroup bpg = MBPGroup.get(getCtx(), getBPartner().getC_BP_Group_ID());
String prioBase = bpg.getPriorityBase();
if (prioBase != null && !prioBase.equals(X_C_BP_Group.PRIORITYBASE_Same)) {
    char targetPrio = getPriorityUser().charAt(0);
    if (prioBase.equals(X_C_BP_Group.PRIORITYBASE_Lower)) targetPrio += 2;
    else                                                  targetPrio -= 2;
    // High(1)〜Low(9) にクランプし、既存より高い場合のみ上書き
}

PriorityUser が未設定なら Low がセットされます。取引先が未設定の場合は Priority = PriorityUser になります。

エスカレーションとクローズ

メソッド	処理内容
doEscalate(boolean user)	user=true なら PriorityUser を、false なら Priority を1段階引き上げる（Minor→Low→Medium→High→Urgent、Urgent は据え置き）
doClose()	現在のステータスがクローズ属性でなければ、最終クローズではないクローズ系ステータスを探して適用。見つからなければ先頭のクローズ系を適用
webUpdate(String result)	ステータスが IsWebCanUpdate の場合のみ、Update_Status_ID へ遷移し結果を記録
isWebCanUpdate()	Processed=Y なら常に false

機密レベルの階層検証

setConfidentialTypeEntry() は、案件の ConfidentialType を上限としてエントリ側の値を丸めます。

案件の機密レベル	許可されるエントリ機密レベル
社内限定（Internal）	社内限定のみ（強制）
非公開（Private）	社内限定・非公開
取引先限定（Partner Confidential）	社内限定・非公開・取引先限定
公開情報（Public）	すべて許可

MRequestUpdate / MRequestAction

• MRequestUpdate.beforeSave() は ConfidentialTypeEntry が未設定なら「公開情報」をセットします
• MRequestAction は MRequestAction(MRequest, boolean newRecord) で旧値を取り込み、addNullColumn() で NULL だったカラム名を NullColumns に蓄積、getChangesHTML() で変更差分を HTML 化します

関連レコードからのリクエスト件数取得

MRequest.getRequestCount(AD_Table_ID, Record_ID, ...) の各オーバーロードは、任意の業務レコードに紐づくリクエスト件数を返します。newRequest(GridTab, AD_Table_ID, Record_ID, C_BPartner_ID) は、他ウィンドウから「このレコードに対するリクエストを作る」導線で使われます。

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

Callout（このテーブル固有）

カラム	Callout クラス	動作
R_RequestType_ID	org.compiere.model.CalloutRequest.type	タイプ選択時に関連既定値を反映
R_MailText_ID	org.compiere.model.CalloutRequest.copyMail	メールテンプレートの本文を複写
R_StandardResponse_ID	org.compiere.model.CalloutRequest.copyResponse	標準回答の本文を複写

子テーブル（R_RequestUpdate / R_RequestAction / R_RequestUpdates）には Callout の登録がありません。

OSGi Model Validator（推奨）

public class CustomRequestValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MRequest && (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE)) {
            MRequest req = (MRequest) po;
            // 例: 緊急案件は担当者必須
            if (MRequest.PRIORITY_Urgent.equals(req.getPriority()) && req.getSalesRep_ID() == 0) {
                throw new AdempiereException("緊急のリクエストには社内担当者の割当が必要です");
            }
        }
        return null;
    }
}

🔧 カスタマイズ: beforeSave() がステータス・期限タイプ・優先度を毎回上書きするため、独自ロジックを TYPE_BEFORE_CHANGE で書いても MRequest 側の再計算に打ち消される場合があります。優先度・期限の独自制御が必要なときは TYPE_AFTER_CHANGE での補正、または MRequest を継承した独自 M クラスを IModelFactory で登録する方式を検討してください。

リクエストプロセッサとの連携

MRequestProcessor / MRequestProcessorRoute / MRequestProcessorLog が、期限超過リクエストの自動エスカレーションと通知メール送信を担います。通知先の算出には RV_RequestUpdates ビューが使われます。

関連プロセス

プロセス名	説明
リクエストプロセッサ	期限超過の検出・エスカレーション・更新通知メールの送信（MRequestProcessor）

関連ドキュメント

• 画面リファレンス: リクエスト(すべて)
• リクエストの技術仕様
• 取引先グループの技術仕様
• メールテンプレートの技術仕様

---

iDempiereカスタマイズのご相談

リクエストはステータス・優先度・機密レベルがコアで自動制御されるため、自社の運用ルールに合わせるには適切な拡張ポイントの選択が重要です。SLA 管理や外部ヘルプデスクとの連携もご相談いただけます。

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

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