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

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

リクエストタイプ（Request Type）は、問い合わせ・クレーム・保証対応といったリクエストの種類を定義するマスタです。タイプごとにステータスの遷移体系（ステータスカテゴリ）、期限までの日数、督促メールの送信要否、機密レベルを設定でき、リクエスト管理の運用ルールを決める土台になります。

📌 ポイント: リクエストタイプは必ずステータスカテゴリ（R_StatusCategory_ID）と紐付きます。未指定で保存すると MRequestType.beforeSave() が既定のステータスカテゴリを自動セットします。意図しないカテゴリが割り当たらないよう、業務ごとのステータス体系を先に設計しておいてください。

リクエストタイプでできること

• 問い合わせ・クレーム・保証対応などリクエストの分類体系を定義する
• タイプごとに使用するステータスカテゴリ（ステータス遷移の体系）を指定する
• 処理待ち日数（DueDateTolerance）で「期限超過」と判定するまでの猶予を設定する
• 期限接近時・期限超過時の自動メール通知（IsEMailWhenDue / IsEMailWhenOverdue）を有効化する
• 機密レベル（ConfidentialType）と機密情報入力可否を制御する
• セルフサービス（Web からの登録・変更）の可否を制御する
• 更新通知タブで、リクエスト更新時に通知を受け取るユーザーを登録する
• カレンダー Dashlet 上の表示色（HeaderColor / ContentColor）を指定する

画面構成

親子2タブのシンプルな構成です。

タブ名	テーブル	項目数	役割
リクエストタイプ	R_RequestType	18項目	タイプの基本設定（ステータスカテゴリ・期限・通知・機密）
更新通知	R_RequestTypeUpdates	6項目	このタイプの更新を受け取る通知先ユーザーの一覧

💡 ヒント: 更新通知タブに登録したユーザーには、当該タイプのリクエストが更新された際に通知が届きます。担当者個人ではなく**タイプ単位の関係者（監督者・品質管理担当等）**を登録する用途に向いています。

基本操作手順

graph TD
    A["🚀 メニューから開く<br/>取引先管理 > リクエスト管理 > リクエストタイプ"] --> B["➕ 新規でタイプを作成<br/>（名称・説明）"]
    B --> C["🔀 ステータスカテゴリを選択<br/>（ステータス遷移の体系）"]
    C --> D["⏱ 処理待ち日数<br/>DueDateTolerance を設定"]
    D --> E{"メール通知を使うか"}
    E -->|使う| F["📧 督促メール / 期限切れメール<br/>にチェック"]
    E -->|使わない| G["🔒 機密レベルを設定"]
    F --> G
    G --> H["💾 保存"]
    H --> I["👥 更新通知タブで<br/>通知先ユーザーを登録"]
    I --> J["✅ リクエスト登録時に<br/>このタイプを選択可能に"]

メニューから開く 取引先管理 > リクエスト管理 > リクエストタイプ 新規でタイプを作成 （名称・説明） ステータスカテゴリを選択 （ステータス遷移の体系） ⏱ 処理待ち日数 DueDateTolerance を設定 メール通知を使うか 督促メール / 期限切れメール にチェック 機密レベルを設定 保存 更新通知タブで 通知先ユーザーを登録 リクエスト登録時に このタイプを選択可能に 使う 使わない

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

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

新規登録の手順

1. ツールバーの「新規」ボタンをクリックします
2. 基本情報を入力します
   • 名称: リクエストタイプ名（例: お問い合わせ、クレーム、保証対応）— 必須、最大60文字
   • 説明: 用途の補足
   • ステータスカテゴリ: 使用するステータス遷移体系 — 必須
3. 期限・通知を設定します
   • 処理待ち日数（DueDateTolerance）: 次回対応日を過ぎてから「期限超過」とみなすまでの猶予日数（既定 7）
   • 自動処理待ち日数（AutoDueDateDays）: 次回対応日を自動設定する日数（既定 0）
   • 督促メール: 期限到来時にメール通知する場合にチェック
   • 期限切れメール: 期限超過時にメール通知する場合にチェック
4. 公開・機密設定を行います
   • セルフサービス: Web からの登録・変更を許可する場合にチェック（既定 ON）
   • 機密レベル（ConfidentialType）: 既定は C
   • 機密情報: 機密情報の入力を許可する場合にチェック（既定 OFF）
5. デフォルト: 新規リクエストの初期値にする場合にチェック（既定 OFF）
6. 「保存」をクリックします

更新通知先の登録

1. 「更新通知」タブに移動します
2. 「新規」をクリックし、ユーザー（AD_User_ID）を選択します
3. 必要に応じてセルフサービスフラグを設定します
4. 「保存」をクリックします

⚠️ 注意: メール通知（督促メール・期限切れメール）を実際に飛ばすには、クライアント側のメール設定と、リクエストプロセッサ（R_RequestProcessor）のスケジュール実行が有効になっている必要があります。フラグを立てただけでは送信されません。

項目リファレンス

リクエストタイプタブ

項目名	必須	型	説明
名称	必須	文字列(60)	リクエストタイプの名称
説明	-	文字列(255)	用途の補足説明
ステータスカテゴリ	必須	選択	使用するステータス遷移体系
デフォルト	必須	チェック	既定のリクエストタイプとして使用（既定 N）
セルフサービス	必須	チェック	Web からの登録・変更を許可（既定 Y）
督促メール	必須	チェック	期限到来時にメール通知
期限切れメール	必須	チェック	期限超過時にメール通知
処理待ち日数	必須	整数	期限超過と判定するまでの猶予日数（既定 7）
自動処理待ち日数	-	整数	次回対応日の自動設定日数（既定 0）
機密レベル	必須	リスト	機密度の区分（既定 C）
機密情報	必須	チェック	機密情報の入力可否（既定 N）
リクエスト変更作成	必須	チェック	BOM 変更リクエストを自動作成
請求済み	-	チェック	請求対象として扱うか（既定 N）
Header Color	-	文字列(7)	カレンダー Dashlet のヘッダー色
Content Color	-	文字列(7)	カレンダー Dashlet の本文色
有効	必須	チェック	レコードが有効か（既定 Y）

更新通知タブ

項目名	必須	型	説明
リクエストタイプ	必須	選択	親のリクエストタイプ
ユーザー	必須	検索	通知を受け取るユーザー
セルフサービス	必須	チェック	セルフサービス経由の変更対象か
有効	必須	チェック	レコードが有効か（既定 Y）

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

リクエスト管理の中での位置づけ

graph TD
    A["リクエストタイプ<br/>R_RequestType"] --> B["ステータスカテゴリ<br/>R_StatusCategory"]
    B --> C["ステータス<br/>R_Status"]
    A --> D["リクエスト<br/>R_Request"]
    C --> D
    A --> E["更新通知先<br/>R_RequestTypeUpdates"]
    D --> F["リクエスト履歴<br/>R_RequestUpdate"]
    D --> G["リクエストプロセッサ<br/>（期限判定・メール送信）"]
    E --> G

リクエストタイプ R_RequestType ステータスカテゴリ R_StatusCategory ステータス R_Status リクエスト R_Request 更新通知先 R_RequestTypeUpdates リクエスト履歴 R_RequestUpdate リクエストプロセッサ （期限判定・メール送信）

設定例

タイプ名	処理待ち日数	督促メール	機密情報	セルフサービス	想定用途
お問い合わせ	7	OFF	OFF	ON	Web からの一般問い合わせ
クレーム	1	ON	OFF	OFF	即応が必要な苦情対応
保証対応	3	ON	OFF	ON	製品保証の申請受付
社内相談	14	OFF	ON	OFF	機密を含む社内案件

よくある質問（FAQ）

Q. ステータスカテゴリを指定せずに保存するとどうなりますか？

MRequestType.beforeSave() が動作し、R_StatusCategory_ID が 0（未設定）の場合は MStatusCategory.getDefault() で取得した既定のステータスカテゴリを自動的にセットして保存します。エラーにはなりませんが、意図しない体系が割り当たる可能性があるため、明示的に選択することを推奨します。

Q. リクエストの初期ステータスはどう決まりますか？

MRequestType.getDefaultR_Status_ID() が、紐付くステータスカテゴリの既定ステータスを返します。このメソッドはステータスカテゴリが未設定の場合、既定カテゴリを取得し、それも存在しなければ MStatusCategory.createDefault() で新規作成してからセットします。

Q. 「デフォルト」にチェックしたタイプはどう使われますか？

MRequestType.getDefault(Properties ctx) で取得され、リクエスト新規作成時の初期値として使用されます。デフォルトは 1 タイプのみにしておくのが運用上わかりやすくなります。

Q. 「処理待ち日数」と「自動処理待ち日数」の違いは何ですか？

**処理待ち日数（DueDateTolerance）は、次回対応日（DateNextAction）を過ぎてから「期限超過（Overdue）」と判定するまでの猶予日数です（既定 7 日）。一方自動処理待ち日数（AutoDueDateDays）**は、リクエスト作成時に次回対応日を自動設定するための日数です（既定 0 = 自動設定しない）。

Q. タイプ別のリクエスト件数を確認できますか？

MRequestType は集計メソッドを備えており、getTotalNo()（総数）、getOpenNo()（未クローズ数）、getClosed30No()（直近30日のクローズ数）、getNew30No()（直近30日の新規数）を返します。パフォーマンス指標（Performance Goal）の測定でも利用されます。

Q. リクエストタイプは削除できますか？

R_RequestType は削除可能テーブルですが、既存のリクエストから参照されている場合は外部キー制約で削除できません。運用を止める場合は「有効」チェックを外して無効化してください。

関連機能

• リクエスト（Request）の使い方
• 取引先マスタの使い方
• 関心トピックの使い方
• 画面リファレンス: リクエストタイプ

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

概要

リクエストタイプはマスタデータ型のウィンドウ（AD_Window_ID: 244）で、R_RequestType テーブルに格納されます。ロジックは MRequestType クラス（585行）が担い、既定ステータスカテゴリの補完、リクエストの取得・集計、パフォーマンス指標用の SQL 生成を行います。markImmutable() を実装しており、キャッシュされた不変インスタンスとしての利用に対応します。Document 型ではありません。子テーブルの R_RequestTypeUpdates には専用の M クラスがなく、生成クラス（X_ クラス）のみで扱われます。

アーキテクチャ概要

classDiagram
    class MRequestType {
        +get(ctx, R_RequestType_ID)$ MRequestType
        +getDefault(ctx)$ MRequestType
        +getCopy(ctx, id, trxName)$ MRequestType
        +getRequests(boolean, int) MRequest[]
        +getDefaultR_Status_ID() int
        +getTotalNo() int
        +getOpenNo() int
        +getClosed30No() int
        +getNew30No() int
        +getSqlPI(...) String
        +getSqlBarChart(...) String
        +getQuery(...) MQuery
        +markImmutable() MRequestType
        #beforeSave(boolean) boolean
    }
    class X_R_RequestType {
        <<generated>>
    }
    class PO {
        <<abstract>>
    }
    MRequestType --|> X_R_RequestType
    X_R_RequestType --|> PO
    MRequestType --> MStatusCategory : resolves default
    MRequestType --> MRequest : has many
    MRequestType --> MGoalRestriction : uses for PI

+get(ctx, R_RequestType_ID)$ MRequestType +getDefault(ctx)$ MRequestType +getCopy(ctx, id, trxName)$ MRequestType +getRequests(boolean, int) MRequest[] +getDefaultR_Status_ID() int +getTotalNo() int +getOpenNo() int +getClosed30No() int +getNew30No() int +getSqlPI(...) String +getSqlBarChart(...) String +getQuery(...) MQuery +markImmutable() MRequestType #beforeSave(boolean) boolean <> <> > X_R_RequestType X_R_RequestType --

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

関連DBテーブル

R_RequestType（リクエストタイプ）

アクセスレベル 6（クライアント+組織）、削除可能テーブルです。

カラム名	型	必須	説明	備考
R_RequestType_ID	ID	PK	リクエストタイプID	主キー
AD_Client_ID	TableDirect	Y	クライアント	既定 @#AD_Client_ID@
AD_Org_ID	TableDirect	Y	組織	既定 @#AD_Org_ID@
Name	String(60)	Y	名称
Description	String(255)	N	説明
R_StatusCategory_ID	TableDirect	Y	ステータスカテゴリ	未設定なら beforeSave で補完
IsDefault	YesNo	Y	デフォルト	既定 N
IsSelfService	YesNo	Y	セルフサービス	既定 Y
IsEMailWhenDue	YesNo	Y	督促メール
IsEMailWhenOverdue	YesNo	Y	期限切れメール
DueDateTolerance	Integer	Y	処理待ち日数	既定 7
AutoDueDateDays	Integer	N	自動処理待ち日数	既定 0
ConfidentialType	List(1)	Y	機密レベル	既定 C
IsConfidentialInfo	YesNo	Y	機密情報	既定 N
IsAutoChangeRequest	YesNo	Y	リクエスト変更作成
IsInvoiced	YesNo	N	請求済み	既定 N
IsIndexed	YesNo	Y	インデックス対象	全文検索用
HeaderColor	String(7)	N	ヘッダー色	カレンダー Dashlet
ContentColor	String(7)	N	本文色	カレンダー Dashlet
IsActive	YesNo	Y	有効	既定 Y
R_RequestType_UU	UUID(36)	N	UUID

R_RequestTypeUpdates（更新通知先）

アクセスレベル 7、R_RequestType_ID + AD_User_ID の組み合わせで通知先を定義します。M クラスは存在せず、生成クラス X_R_RequestTypeUpdates のみです。

カラム名	型	必須	説明
R_RequestType_ID	TableDirect	Y	リクエストタイプFK
AD_User_ID	Search	Y	通知先ユーザー
IsSelfService	YesNo	Y	セルフサービス対象
IsActive	YesNo	Y	有効（既定 Y）
R_RequestTypeUpdates_UU	UUID(36)	N	UUID

ER図

erDiagram
    R_RequestType ||--o{ R_RequestTypeUpdates : "notify users"
    R_RequestType }o--|| R_StatusCategory : "status scheme"
    R_StatusCategory ||--o{ R_Status : "statuses"
    R_RequestType ||--o{ R_Request : "classifies"
    R_Request ||--o{ R_RequestUpdate : "history"
    R_RequestTypeUpdates }o--|| AD_User : "recipient"

notify users status scheme

ビジネスロジック

beforeSave() — 既定ステータスカテゴリの補完

protected boolean beforeSave (boolean newRecord)
{
    // Set default request status category
    if (getR_StatusCategory_ID() == 0)
    {
        MStatusCategory sc = MStatusCategory.getDefault(getCtx());
        if (sc != null && sc.getR_StatusCategory_ID() != 0)
            setR_StatusCategory_ID(sc.getR_StatusCategory_ID());
    }
    return true;
}

処理はこれだけで、その他の検証は行いません。ステータスカテゴリの整合性は、この自動補完に依存します。

getDefaultR_Status_ID() — 初期ステータスの解決

flowchart TD
    A["getDefaultR_Status_ID"] --> B{"R_StatusCategory_ID = 0?"}
    B -->|Yes| C["MStatusCategory.getDefault"]
    C --> D{"取得できたか"}
    D -->|No| E["MStatusCategory.createDefault<br/>で既定カテゴリを新規作成"]
    D -->|Yes| F["setR_StatusCategory_ID"]
    E --> F
    B -->|No| G
    F --> G{"R_StatusCategory_ID != 0?"}
    G -->|Yes| H["sc.getDefaultR_Status_ID を返す"]
    G -->|No| I["0 を返す"]

R_StatusCategory_ID = 0? MStatusCategory.getDefault 取得できたか MStatusCategory.createDefault で既定カテゴリを新規作成 R_StatusCategory_ID != 0? sc.getDefaultR_Status_ID を返す 0 を返す

リクエストの取得と集計

• getRequests(boolean selfService, int C_BPartner_ID): セルフサービス条件・取引先条件でリクエストを絞り込んで取得
• getRequests(): 当該タイプの全リクエストを取得
• getTotalNo() / getOpenNo() / getClosed30No() / getNew30No(): いずれも synchronized メソッドで、件数を遅延評価してキャッシュします

パフォーマンス指標（Performance Indicator）連携

getSqlPI(MGoalRestriction[], ...) と getSqlBarChart(MGoalRestriction[], ...)、getQuery(...) は、パフォーマンス測定（PA_Measure / PA_Goal）からリクエスト件数を指標として取り込むための SQL・クエリを組み立てます。ダッシュボードで「未クローズのクレーム件数」といった指標を出す際に使われます。

不変オブジェクト対応

markImmutable() を実装しており、キャッシュに保持された MRequestType インスタンスは変更不可としてマークされます。変更を伴う処理では getCopy(ctx, R_RequestType_ID, trxName) で可変コピーを取得してください。

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

Callout

R_RequestType および R_RequestTypeUpdates には、AD_Column に登録された Callout はありません。入力時の自動セットが必要な場合は独自 Callout を追加するか、Model Validator で対応します。

OSGi Model Validator（推奨）

public class CustomRequestTypeValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MRequestType) {
            MRequestType rt = (MRequestType) po;
            if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
                // 例: メール通知を使うタイプは処理待ち日数を必須にする
                if ((rt.isEMailWhenDue() || rt.isEMailWhenOverdue())
                        && rt.getDueDateTolerance() <= 0) {
                    throw new AdempiereException("メール通知を有効にする場合は処理待ち日数を1以上にしてください");
                }
            }
        }
        return null;
    }

    @Override
    public String docValidate(PO po, int timing) {
        return null; // R_RequestType は Document 型ではない
    }
}

通知処理の拡張

期限判定とメール送信は MRequestProcessor（リクエストプロセッサ）がスケジュール実行します。通知先や本文を独自化する場合は、R_RequestTypeUpdates の通知先を参照する独自プロセスを OSGi プラグインとして追加し、スケジューラから起動する方式が安全です。

関連プロセス

プロセス名	説明
リクエストプロセッサ	リクエストの期限判定・エスカレーション・メール通知をスケジュール実行

関連ドキュメント

• 操作マニュアル: リクエスト
• 操作マニュアル: 関心トピック
• 画面リファレンス: リクエストタイプ

---

iDempiereカスタマイズのご相談

リクエストタイプは、問い合わせ管理の分類体系と SLA（期限・エスカレーション）を決める要のマスタです。 Model Validator と独自プロセッサを組み合わせれば、自社の対応フローに沿った通知・集計をコア改変なしで実現できます。

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

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