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

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

リクエストステータスは、問い合わせ・要望・障害報告の進行状態（受付中、調査中、完了など）を定義するマスタです。ステータスカテゴリという親の括りを持ち、リクエストの種類ごとに別々のステータス体系を用意できます。タイムアウト日数を設定すれば、一定期間動きのないリクエストを次のステータスへ自動遷移させることもできます。

📌 ポイント: このウィンドウは親タブが「ステータスカテゴリ」、子タブが「リクエストステータス」です。個々のステータスを登録する前に、必ずカテゴリ（ステータス体系の名前）を作成してください。

リクエストステータスでできること

• リクエストの進行状態（受付中・調査中・保留・完了 など）の定義
• ステータスカテゴリによる複数のステータス体系の並行運用
• 表示順（シーケンスNo）の制御
• オープン／クローズ／最終クローズの属性設定
• タイムアウト日数による次ステータスへの自動遷移
• Web（セルフサービス）からの更新可否と、更新後ステータスの自動変更
• カテゴリ単位・体系単位のデフォルトステータスの指定

画面構成

リクエストステータスは、カテゴリを親とする2階層構成です。

タブ名	テーブル	項目数	役割
ステータスカテゴリ	R_StatusCategory	7項目	ステータス体系の定義（名称・デフォルト）
リクエストステータス	R_Status	18項目	個々のステータス（順序・開閉属性・自動遷移）

graph TD
    subgraph "リクエストステータス（Window ID: 349）"
        T1["🗂 ステータスカテゴリ<br/>R_StatusCategory<br/>7項目"]
        T2["&nbsp;&nbsp;└ リクエストステータス<br/>&nbsp;&nbsp;&nbsp;&nbsp;R_Status<br/>&nbsp;&nbsp;&nbsp;&nbsp;18項目"]
    end
    T1 --> T2

リクエストステータス（Window ID: 349） ステータスカテゴリ R_StatusCategory 7項目   └ リクエストステータス     R_Status     18項目

💡 ヒント: 標準のステータス体系が未整備の環境では、システムが「Standard」という名前のデフォルトカテゴリを自動生成し、カテゴリ未設定のステータスをそこに割り当てる仕組みがあります（MStatusCategory.createDefault()）。

基本操作手順

graph TD
    A["🚀 メニューから開く<br/>取引先管理 > リクエスト管理 > リクエストステータス"] --> B["➕ ステータスカテゴリを作成<br/>（名称・デフォルト）"]
    B --> C["➕ 子タブでステータスを登録<br/>（検索キー・名称・シーケンスNo）"]
    C --> D{ステータスの性質}
    D -->|進行中| E["🟢 オープンステータスに<br/>チェック"]
    D -->|完了| F["🔴 クローズステータスに<br/>チェック"]
    F --> G{再オープン禁止?}
    G -->|はい| H["🔒 最終クローズにチェック"]
    G -->|いいえ| I["💾 保存"]
    E --> J{放置時に自動遷移?}
    J -->|はい| K["⏱ タイムアウト日数と<br/>次のステータスを設定"]
    J -->|いいえ| I
    K --> I
    H --> I
    I --> L["✅ リクエスト画面で<br/>ステータスとして選択可能に"]

メニューから開く 取引先管理 > リクエスト管理 > リクエストステータス ステータスカテゴリを作成 （名称・デフォルト） 子タブでステータスを登録 （検索キー・名称・シーケンスNo） オープンステータスに チェック クローズステータスに チェック 最終クローズにチェック 保存 ⏱ タイムアウト日数と 次のステータスを設定 リクエスト画面で ステータスとして選択可能に ステータスの性質 再オープン禁止? 放置時に自動遷移? 進行中 完了 はい いいえ

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

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

新規登録（ステータスカテゴリ）

1. ツールバーの「新規」ボタンをクリック
2. 基本情報を入力:
   • 名称（必須）: ステータス体系の名称（例: 標準サポート、社内改善要望）
   • 説明 / コメント: 用途の説明
   • デフォルト: 既定の体系として使う場合にチェック
3. 「保存」をクリック

新規登録（リクエストステータス）

1. カテゴリを選択した状態で「リクエストステータス」タブへ移動
2. 「新規」で個々のステータスを登録:
   • 検索キー（必須）: ステータスコード（例: OPEN、INVESTIGATING、CLOSED）
   • 名称（必須）: 表示名（例: 受付中）
   • シーケンスNo（必須）: 表示順（小さい値が先）
   • オープンステータス / クローズステータス: 状態属性
   • 最終クローズ: 再オープンを禁止する場合にチェック
   • デフォルト: このカテゴリの初期ステータスにする場合にチェック
3. 必要に応じて自動化項目を設定:
   • ウェブ更新可能: Web からの更新を許可
   • ステータス変更: Web から更新された後に自動で変わる先のステータス
   • タイムアウト日数: 何日間動きがなければ遷移するか
   • 次のステータス: タイムアウト後の遷移先
4. 「保存」をクリック

⚠️ 注意: 保存時に整合性の自動補正が働きます。オープンとクローズの両方にチェックするとクローズが外れ、クローズでないのに最終クローズにするとその指定が外れます。またウェブ更新可能でない場合の「ステータス変更」、タイムアウト日数が0の場合の「次のステータス」は自動的にクリアされます。

項目リファレンス

ステータスカテゴリタブ

項目名	必須	型	説明
名称	必須	文字列（60）	ステータス体系の名称
説明	-	文字列（255）	短い説明
コメント	-	テキスト（2000）	運用上のヒント
デフォルト	必須	チェック	既定の体系として使用
有効	必須	チェック	有効フラグ

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

項目名	必須	型	説明
ステータスカテゴリ	必須	選択	親カテゴリ（自動セット）
シーケンスNo	必須	整数	表示順。小さい値が先
検索キー	必須	文字列（40）	ステータスコード。一意
名称	必須	文字列（60）	表示名
説明	-	文字列（255）	短い説明
コメント	-	テキスト（2000）	運用ヒント
デフォルト	必須	チェック	このカテゴリの初期ステータス
オープンステータス	必須	チェック	進行中を表す
クローズステータス	必須	チェック	完了を表す（既定値 N）
最終クローズ	必須	チェック	再オープン禁止（既定値 N）
ウェブ更新可能	必須	チェック	Web からの更新を許可
ステータス変更	-	選択	Web 更新後に自動で変わる先
タイムアウト日数	-	整数	自動遷移までの日数（既定値 0）
次のステータス	-	選択	タイムアウト後の遷移先

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

ステータス遷移の全体像

graph TD
    A["リクエスト作成"] --> B["デフォルトステータス<br/>（IsDefault=Y）"]
    B --> C["担当者が手動で変更"]
    B --> D["Web から更新<br/>→ ステータス変更で自動遷移"]
    B --> E["放置<br/>→ タイムアウト日数経過"]
    E --> F["リクエストプロセッサが<br/>次のステータスへ自動遷移"]
    C --> G["クローズステータス"]
    D --> G
    F --> G
    G --> H{"最終クローズ?"}
    H -->|はい| I["再オープン不可"]
    H -->|いいえ| C

リクエスト作成 デフォルトステータス （IsDefault=Y） 担当者が手動で変更 Web から更新 → ステータス変更で自動遷移 放置 → タイムアウト日数経過 リクエストプロセッサが 次のステータスへ自動遷移 クローズステータス 最終クローズ? 再オープン不可 はい いいえ

よくある質問（FAQ）

Q. オープンとクローズの両方にチェックできますか？

できません。MStatus.beforeSave() に「オープンかつクローズの場合はクローズを false にする」という補正処理があり、保存時に自動的にクローズが外れます。エラーにはならず黙って補正されるため、保存後の状態を必ず確認してください。

Q. 最終クローズにチェックしたのに外れてしまいます

「最終クローズ」は「クローズステータス」であることが前提です。beforeSave() は最終クローズがチェックされていてクローズがチェックされていない場合、最終クローズを false に戻します。まずクローズステータスにチェックしてから最終クローズを設定してください。

Q. タイムアウトによる自動遷移はどう動きますか？

サーバー側のリクエストプロセッサが定期的に処理します。対象は「タイムアウト日数が0より大きく」「次のステータスが設定されている」ステータスのリクエストで、最終アクション日 + タイムアウト日数 < 現在日 を満たすものです。該当したリクエストは結果欄に遷移内容が記録され、ステータスが次のステータスへ更新されます。

Q. 「次のステータス」や「ステータス変更」を設定したのに消えます

beforeSave() の補正によるものです。タイムアウト日数が0のときは「次のステータス」がクリアされ、ウェブ更新可能でないときは「ステータス変更」がクリアされます。先にタイムアウト日数やウェブ更新可能を設定してから、遷移先を指定してください。

Q. デフォルトステータスはどう決まりますか？

カテゴリ配下のステータスのうち、有効かつ「デフォルト」がチェックされた最初のものが選ばれます（MStatusCategory.getDefaultR_Status_ID()）。該当がない場合は、有効なステータスの先頭が使われ、それもなければ 0（未設定）となります。

Q. ステータスカテゴリは削除できますか？

R_StatusCategory は IsDeleteable=N のテーブルで、標準では削除できません。使わなくなった体系は「有効」チェックを外して無効化してください。

関連機能

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

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

概要

リクエストステータスは2階層のマスタウィンドウで、親が R_StatusCategory、子が R_Status です。モデルクラスは MStatusCategory（302行）と MStatus（306行）で、いずれも ImmutablePOSupport を実装しキャッシュ参照に対応します。Document 型ではありませんが、MStatus は beforeSave() にフラグ整合性の補正ロジックを持ちます。

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

アーキテクチャ概要

classDiagram
    class MStatusCategory {
        +getDefault(ctx) MStatusCategory
        +createDefault(ctx) MStatusCategory
        +get(ctx, R_StatusCategory_ID) MStatusCategory
        +getStatus(boolean reload) MStatus[]
        +getDefaultR_Status_ID() int
        +markImmutable() MStatusCategory
    }
    class MStatus {
        +getDefault(ctx, R_RequestType_ID) MStatus
        +getClosed(ctx) MStatus[]
        +get(ctx, R_Status_ID) MStatus
        #beforeSave(boolean newRecord) boolean
        +markImmutable() MStatus
    }
    class X_R_StatusCategory {
        <<generated>>
    }
    class X_R_Status {
        <<generated>>
    }
    class PO {
        <<abstract>>
    }
    MStatusCategory --|> X_R_StatusCategory
    MStatus --|> X_R_Status
    X_R_StatusCategory --|> PO
    X_R_Status --|> PO
    MStatusCategory --> MStatus : has many
    MRequest --> MStatus : getStatus()

+getDefault(ctx) MStatusCategory +createDefault(ctx) MStatusCategory +get(ctx, R_StatusCategory_ID) MStatusCategory +getStatus(boolean reload) MStatus[] +getDefaultR_Status_ID() int +markImmutable() MStatusCategory +getDefault(ctx, R_RequestType_ID) MStatus +getClosed(ctx) MStatus[] +get(ctx, R_Status_ID) MStatus #beforeSave(boolean newRecord) boolean +markImmutable() MStatus <> <> > X_R_StatusCategory MStatus -- > PO X_R_Status --

パッケージ: org.compiere.model ソースファイル: org.adempiere.base/src/org/compiere/model/MStatus.java / MStatusCategory.java 関連サーバー処理: org.adempiere.server/src/main/server/org/compiere/server/RequestProcessor.java

関連DBテーブル

R_StatusCategory（ステータスカテゴリ）

カラム名	型	必須	説明	備考
R_StatusCategory_ID	ID	PK	カテゴリID	主キー
AD_Client_ID	Table Direct	Y	テナント
AD_Org_ID	Table Direct	Y	組織
Name	String(60)	Y	名称	識別子（IsIdentifier=Y）
Description	String(255)	N	説明
Help	Text(2000)	N	コメント／ヒント
IsDefault	Yes-No	Y	デフォルト	既定体系の判定に使用
IsActive	Yes-No	Y	有効
R_StatusCategory_UU	UUID	N	UUID

R_Status（リクエストステータス）

カラム名	型	必須	説明	備考
R_Status_ID	ID	PK	ステータスID	主キー
R_StatusCategory_ID	Table Direct	Y	ステータスカテゴリFK	IsParent=Y
Value	String(40)	Y	検索キー	一意
Name	String(60)	Y	名称	識別子
SeqNo	Integer	Y	シーケンスNo	識別子。小さい順
Description	String(255)	N	説明
Help	Text(2000)	N	コメント／ヒント
IsDefault	Yes-No	Y	デフォルト
IsOpen	Yes-No	Y	オープンステータス
IsClosed	Yes-No	Y	クローズステータス	既定値 N
IsFinalClose	Yes-No	Y	最終クローズ	既定値 N。再オープン不可
IsWebCanUpdate	Yes-No	Y	ウェブ更新可能
Update_Status_ID	Table	N	ステータス変更	Web更新後の自動遷移先
TimeoutDays	Integer	N	タイムアウト日数	既定値 0
Next_Status_ID	Table	N	次のステータス	タイムアウト後の遷移先
IsActive	Yes-No	Y	有効

ER図

erDiagram
    R_StatusCategory ||--o{ R_Status : "contains"
    R_Status ||--o{ R_Request : "current status"
    R_Status }o--o| R_Status : "Next_Status_ID"
    R_Status }o--o| R_Status : "Update_Status_ID"
    R_Request ||--o{ R_RequestUpdate : "update history"

current status update history

ビジネスロジック

MStatus.beforeSave() のフラグ補正

保存前に4つの補正が行われます。例外は投げず、値を書き換える設計です。

条件	補正内容
isOpen() かつ isClosed()	IsClosed = false
isFinalClose() かつ !isClosed()	IsFinalClose = false
!isWebCanUpdate() かつ Update_Status_ID != 0	Update_Status_ID = 0
TimeoutDays == 0 かつ Next_Status_ID != 0	Next_Status_ID = 0

デフォルトカテゴリの取得と自動生成

MStatusCategory.getDefault(ctx) は次の SQL でデフォルト体系を取得します。

SELECT * FROM R_StatusCategory
WHERE AD_Client_ID in (0, ?) AND IsDefault='Y'
ORDER BY AD_Client_ID DESC

AD_Client_ID DESC の並び順により、テナント固有の定義がシステム定義（AD_Client_ID=0）より優先されます。

createDefault(ctx) は「Standard」という翻訳メッセージ名でカテゴリを作成し、さらにカテゴリ未設定（R_StatusCategory_ID IS NULL）のステータスを一括で新カテゴリへ割り当てます。

デフォルトステータスの決定

MStatusCategory.getDefaultR_Status_ID() の優先順位:

1. カテゴリ配下で有効かつ IsDefault=Y の最初のステータス
2. 該当なしの場合、有効なステータスの先頭
3. それもなければ 0

タイムアウト自動遷移（RequestProcessor）

flowchart TD
    A["RequestProcessor 起動"] --> B["対象リクエスト抽出<br/>TimeoutDays > 0 かつ<br/>Next_Status_ID > 0 かつ<br/>DateLastAction + TimeoutDays < 現在日"]
    B --> C["ステータスと次ステータスを取得"]
    C --> D["結果欄に<br/>RequestStatusTimeout メッセージを記録<br/>（旧ステータス → 新ステータス）"]
    D --> E["R_Status_ID を Next_Status_ID に更新"]
    E --> F["保存・件数カウント"]

RequestProcessor 起動 対象リクエスト抽出 TimeoutDays > 0 かつ Next_Status_ID > 0 かつ DateLastAction + TimeoutDays < 現在日 ステータスと次ステータスを取得 結果欄に RequestStatusTimeout メッセージを記録 （旧ステータス → 新ステータス） R_Status_ID を Next_Status_ID に更新 保存・件数カウント

Web 更新後の自動遷移

MRequest の Web 更新処理では、現在ステータスの Update_Status_ID が 0 より大きい場合に、リクエストのステータスをその値へ設定します。セルフサービスからの返信で自動的に「顧客回答待ち」から「対応中」へ戻す、といった運用が可能です。

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

OSGi Model Validator（推奨）

public class CustomRequestStatusValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MStatus) {
            MStatus st = (MStatus) po;
            if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
                // 例: タイムアウト日数の上限を制限する
                if (st.getTimeoutDays() > 90) {
                    throw new AdempiereException("タイムアウト日数は90日以内にしてください");
                }
            }
        }
        return null;
    }
}

ステータス遷移の制約追加

「特定のステータスから特定のステータスへしか遷移できない」といった遷移制御は標準にありません。R_Request の TYPE_BEFORE_CHANGE で is_ValueChanged(COLUMNNAME_R_Status_ID) を判定し、旧値と新値の組み合わせを検証する Model Validator を実装します。

Callout

R_Status / R_StatusCategory のカラムには標準 Callout が設定されていません。フラグ整合性はモデル層の beforeSave() で担保されています。

関連プロセス

プロセス／サーバー処理	説明
リクエストプロセッサ	タイムアウト日数に基づくステータス自動遷移、通知処理を担うサーバープロセス

関連ドキュメント

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

---

iDempiereカスタマイズのご相談

ステータス設計はサポート業務のSLAそのものです。遷移制約・エスカレーション通知・SLA違反レポートなどは、コアを改変せず Model Validator とカスタムプロセスで実装できます。

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

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