コンテンツにスキップ
As-Link Docs

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

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

リクエストカテゴリは、リクエスト（問い合わせ・要望・障害報告）を「どの話題についてのものか」で分類するためのマスタです。カテゴリごとに更新通知の受信者を登録できるため、担当分野の担当者へ自動的に情報を届ける仕組みの土台になります。

📌 ポイント: カテゴリは単なる分類名ではありません。「更新通知」タブに登録したユーザーが、そのカテゴリのリクエスト更新を受け取る対象になります。分類設計と通知先設計をセットで考えてください。

リクエストカテゴリでできること

Section titled “リクエストカテゴリでできること”
  • 問い合わせ・要望・障害報告の話題別分類（例: 製品不具合、請求について、機能要望）
  • カテゴリごとの更新通知受信者（ユーザー）の登録
  • 受信者ごとのセルフサービス可否の設定
  • 品目（M_Product_ID）との紐付けによる、製品単位のサポート分類
  • 説明・コメントによる運用ルールの明文化
  • 有効／無効フラグによるカテゴリの世代管理

画面構成

Section titled “画面構成”

リクエストカテゴリはシンプルな2タブ構成です。

タブ名テーブル項目数役割
リクエストカテゴリR_Category7項目カテゴリの基本情報（名称・説明・品目）
更新通知R_CategoryUpdates6項目このカテゴリの更新を受け取るユーザーの一覧

💡 ヒント: 更新通知タブは必須ではありません。まずカテゴリだけを登録し、運用が固まってから通知先を追加する進め方でも問題ありません。

基本操作手順

Section titled “基本操作手順”
graph TD
    A["🚀 メニューから開く<br/>取引先管理 > リクエスト管理 > リクエストカテゴリ"] --> B["➕ 新規でカテゴリを作成<br/>（名称は必須）"]
    B --> C["📝 説明・コメントに<br/>分類の判断基準を記載"]
    C --> D{製品サポート用?}
    D -->|はい| E["📦 品目を選択<br/>（対象製品を特定）"]
    D -->|いいえ| F["💾 保存"]
    E --> F
    F --> G{更新通知を出す?}
    G -->|はい| H["👥 更新通知タブで<br/>受信ユーザーを登録"]
    G -->|いいえ| I["✅ 登録完了"]
    H --> I
    I --> J["🔗 リクエスト画面の<br/>カテゴリ欄で選択可能に"]

メニューから開く 取引先管理 > リクエスト管理 > リクエストカテゴリ 新規でカテゴリを作成 （名称は必須） 説明・コメントに 分類の判断基準を記載 品目を選択 （対象製品を特定） 保存 更新通知タブで 受信ユーザーを登録 登録完了 リクエスト画面の カテゴリ欄で選択可能に 製品サポート用? 更新通知を出す? はい いいえ

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

Section titled “アクセス方法（メニューパス）”

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

新規登録

Section titled “新規登録”
  1. ツールバーの「新規」ボタンをクリック
  2. 基本情報を入力:
    • 名称（必須）: カテゴリ名（例: 製品不具合、請求に関する問い合わせ）
    • 説明: 用途の短い説明（255文字まで）
    • コメント: 分類の判断基準など運用者向けのヒント（2,000文字まで）
    • 品目: 特定の製品に関するカテゴリの場合に選択
  3. 「保存」をクリック

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

Section titled “更新通知の受信者を登録する”
  1. カテゴリを保存後、「更新通知」タブに移動
  2. 「新規」で受信者を追加:
    • ユーザー（必須）: 通知を受け取るユーザー／連絡先
    • セルフサービス: セルフサービス経由で扱えるエントリの場合にチェック
  3. 「保存」をクリック。複数名を登録する場合は行を追加します

⚠️ 注意: カテゴリの「名称」はリクエスト画面での識別子として使われます。運用開始後に名称を変えると過去のリクエストの表示名も変わるため、分類の意味自体が変わる場合は名称変更ではなく新規カテゴリの追加＋旧カテゴリの無効化を推奨します。

項目リファレンス

Section titled “項目リファレンス”

リクエストカテゴリタブ

Section titled “リクエストカテゴリタブ”
項目名必須型説明
クライアント必須選択テナント（既定値は自動セット）
組織必須選択組織（既定値は自動セット）
名称必須文字列（60）カテゴリ名。識別子として使用
説明-文字列（255）短い説明
コメント-テキスト（2000）運用上のヒント・判断基準
有効-チェック既定値はY。外すと新規選択の対象外
品目-検索関連する品目・サービス

更新通知タブ

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

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

よくある質問（FAQ）

Section titled “よくある質問（FAQ）”

Q. カテゴリとリクエストタイプの違いは何ですか？

Section titled “Q. カテゴリとリクエストタイプの違いは何ですか？”

リクエストタイプは処理の枠組み（対応期限や既定ステータスなど、リクエストの取り扱いルール）を決めるものです。これに対しカテゴリは「話題・対象」の分類です。MRequest クラスは両者を別々のフィールド（R_RequestType_ID と R_Category_ID）として保持しており、役割が明確に分かれています。

Q. 名称以外に必須項目はありますか？

Section titled “Q. 名称以外に必須項目はありますか？”

ユーザーが入力する項目のうち必須なのは名称のみです（クライアント・組織は既定値が自動セットされます）。品目・説明・コメントはすべて任意です。

Q. カテゴリを削除できますか？

Section titled “Q. カテゴリを削除できますか？”

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

Q. 品目を設定すると何が変わりますか？

Section titled “Q. 品目を設定すると何が変わりますか？”

カテゴリと品目（M_Product_ID）の紐付けが記録されます。製品別サポートを行う場合に、どの製品に関する問い合わせ分類かを明示できます。品目の設定は任意で、未設定でもカテゴリは正常に機能します。

関連機能

Section titled “関連機能”
🛠 技術仕様（開発者向け）

概要

Section titled “概要”

リクエストカテゴリはマスタデータ型のウィンドウで、R_Category テーブルに格納されます。モデルクラスは MRequestCategory（160行）で、X_R_Category を継承し ImmutablePOSupport を実装しています。Document 型ではなく DocAction / DocStatus は持ちません。子タブの R_CategoryUpdates には専用の M クラスが存在せず、生成クラス X_R_CategoryUpdates のみが提供されます。

テーブルアクセスレベル削除可大量データ
R_Category6（システム＋クライアント）YN
R_CategoryUpdates7（すべて）YN

アーキテクチャ概要

Section titled “アーキテクチャ概要”
classDiagram
    class MRequestCategory {
        +get(ctx, R_Category_ID) MRequestCategory
        +getCopy(ctx, R_Category_ID, trxName) MRequestCategory
        +markImmutable() MRequestCategory
    }
    class X_R_Category {
        <<generated>>
    }
    class X_R_CategoryUpdates {
        <<generated>>
    }
    class PO {
        <<abstract>>
    }
    class ImmutablePOSupport {
        <<interface>>
    }
    MRequestCategory --|> X_R_Category
    X_R_Category --|> PO
    X_R_CategoryUpdates --|> PO
    MRequestCategory ..|> ImmutablePOSupport
    MRequest --> MRequestCategory : getCategory()

+get(ctx, R_Category_ID) MRequestCategory +getCopy(ctx, R_Category_ID, trxName) MRequestCategory +markImmutable() MRequestCategory <> <> <> > X_R_Category X_R_Category -- > PO MRequestCategory ..

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

関連DBテーブル

Section titled “関連DBテーブル”

R_Category（リクエストカテゴリ）

Section titled “R_Category（リクエストカテゴリ）”
カラム名型必須説明備考
R_Category_IDIDPKカテゴリID主キー
AD_Client_IDTable DirectYテナント既定値 @#AD_Client_ID@
AD_Org_IDTable DirectY組織既定値 @#AD_Org_ID@
NameString(60)Y名称識別子（IsIdentifier=Y）
DescriptionString(255)N説明
HelpText(2000)Nコメント／ヒント
M_Product_IDSearchN品目任意の製品紐付け
IsActiveYes-NoY有効既定値 Y
R_Category_UUUUIDNUUID

R_CategoryUpdates（更新通知の受信者）

Section titled “R_CategoryUpdates（更新通知の受信者）”
カラム名型必須説明
R_Category_IDTable DirectY親カテゴリFK（IsParent=Y）
AD_User_IDSearchY受信ユーザーFK（IsParent=Y）
IsSelfServiceYes-NoYセルフサービスエントリ
IsActiveYes-NoY有効
R_CategoryUpdates_UUUUIDNUUID

📌 ポイント: R_CategoryUpdates は R_Category_ID と AD_User_ID の両方が IsParent=Y の連関テーブルです。カテゴリとユーザーの多対多関係を表現しています。

ER図

Section titled “ER図”
erDiagram
    R_Category ||--o{ R_CategoryUpdates : "notification recipients"
    R_Category ||--o{ R_Request : "categorizes"
    R_CategoryUpdates }o--|| AD_User : "recipient"
    R_Category }o--o| M_Product : "related product"

notification recipients related product

ビジネスロジック

Section titled “ビジネスロジック”

MRequestCategory は beforeSave() / afterSave() をオーバーライドしていません。バリデーションは AD 定義の必須制約（Name 必須）とデータベース制約のみです。

主要メソッドは以下の3系統です。

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

リクエスト側からは MRequest.getCategory() が MRequestCategory.getCopy() を呼び出し、getCategoryName() でカテゴリ名を取得します。R_Category_ID が 0 の場合は null を返します。

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

Section titled “拡張ポイント（カスタマイズ箇所）”

OSGi Model Validator（推奨）

Section titled “OSGi Model Validator（推奨）”

カテゴリの命名規則や品目必須化などの独自ルールは Model Validator で追加します。

public class CustomRequestCategoryValidator implements ModelValidator {
    @Override
    public int modelChange(PO po, int type) throws Exception {
        if (po instanceof MRequestCategory) {
            MRequestCategory cat = (MRequestCategory) po;
            if (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE) {
                // 例: 製品サポート用カテゴリは品目必須
                if (cat.getName().startsWith("PRD-") && cat.getM_Product_ID() == 0) {
                    throw new AdempiereException("製品サポート用カテゴリには品目を設定してください");
                }
            }
        }
        return null;
    }
}

Callout

Section titled “Callout”

R_Category / R_CategoryUpdates の各カラムには標準の Callout が設定されていません（AD_Column.Callout はすべて未設定）。入力時の相互連動が必要な場合は独自 Callout を OSGi サービスとして追加します。

通知連携の拡張

Section titled “通知連携の拡張”

R_CategoryUpdates は生成クラスのみを持つ連関テーブルです。カテゴリ別の通知ロジックを独自実装する場合は、R_Request の変更イベント（RequestEventHandler が扱う IEventTopics の modelChange 系イベント）を購読し、R_CategoryUpdates から受信者を引く実装が一般的です。

関連ドキュメント

Section titled “関連ドキュメント”

iDempiereカスタマイズのご相談

Section titled “iDempiereカスタマイズのご相談”

リクエストカテゴリは、問い合わせ分類と通知先設計を結び付ける起点になるマスタです。カテゴリ別の自動通知やエスカレーションルールは、コア改変なしに Model Validator とイベントハンドラで実装できます。

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

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