iDempiere 既知課題の使い方｜取引先管理 操作マニュアル・技術仕様
📖 取引先管理の全体像: 取引先管理の全体図 も合わせてご覧ください。
既知課題は、システムで発生することが判明している不具合・エラーを台帳化するウィンドウです。ログエンジン名・クラス名・メソッド名・行番号という発生箇所の座標を保持し、同じエラーが再発したときに「既知の課題」として識別できるようにします。
📌 ポイント: このウィンドウは iDempiere 13 標準では無効化されています（AD_Window_ID: 369、標準メニュー未登録）。旧 Compiere の自動課題レポート（Issue Reporting）基盤の一部で、レポート送信を担う
MIssue.report()は iDempiere 13 で@Deprecated(since="13", forRemoval=true)かつ未実装（常にnullを返す）となっています。新規の業務設計では リクエスト（Request） をご利用ください。
既知課題でできること
Section titled “既知課題でできること”- 判明済みの不具合をリリース番号（ReleaseNo）単位で台帳化
- 課題要約（IssueSummary）による一覧上の識別
- ログエンジン・クラス・メソッド・行番号による発生箇所の特定情報の記録
- 課題ステータスマスタ（
R_IssueStatus）による進捗区分の付与 - 「現在ステータス」欄（2000文字）への調査経過の自由記述
- 推奨対処（
R_IssueRecommendation）および リクエスト との紐づけ
⚠️ 注意: 「リリースNo」と「課題要約」は必須項目です。発生箇所（クラス・メソッド・行番号）はすべて任意のため、空欄でも保存できます。
既知課題は単一タブの台帳型ウィンドウです。
| タブ名 | テーブル | 項目数 | 役割 |
|---|---|---|---|
| 既知課題 | R_IssueKnown | 15項目 | 課題の要約・発生箇所・ステータス・関連レコード |
基本操作手順
Section titled “基本操作手順”graph TD
A["🐞 エラー発生<br/>ログにクラス・メソッド・行番号が出力"] --> B["🔎 既知課題を検索<br/>（クラス名・メソッド名で照合）"]
B --> C{既に登録済み?}
C -->|あり| D["📝 現在ステータスを更新<br/>（調査経過を追記）"]
C -->|なし| E["➕ 新規登録<br/>リリースNo・課題要約を入力"]
E --> F["🧭 発生箇所を記録<br/>ログエンジン / クラス / メソッド / 行番号"]
F --> G["🏷 課題ステータスを選択<br/>（R_IssueStatus マスタ）"]
G --> H["🔗 推奨対処・リクエストを紐づけ"]
D --> I["💾 保存"]
H --> I
アクセス方法（メニューパス）
Section titled “アクセス方法（メニューパス）”iDempiere 13 標準ではメニューに登録されていません。参照が必要な場合は、システム管理者が「システム管理 > 一般ルール > システムルール > メニュー」で AD_Window_ID 369（Known Issue）のメニュー項目を追加し、ロールにウィンドウアクセス権を付与します。
💡 ヒント: 先に 課題ステータス で進捗区分を登録しておくと、既知課題の「課題ステータス」項目から選択できるようになります。
- ツールバーの「新規」ボタンをクリック
- 必須項目を入力:
- リリースNo: 対象リリースの内部リリース番号（10文字まで。例:
13） - 課題要約: 課題の1行要約（255文字まで）
- リリースNo: 対象リリースの内部リリース番号（10文字まで。例:
- 発生箇所を記録（任意・いずれも60文字、行番号は整数）:
- ログエンジン:
CLoggerのロガー名 - クラス: 例外が発生したクラス名
- メソッド: 例外が発生したメソッド名
- 行番号: スタックトレース上の行番号
- ログエンジン:
- 課題ステータスを選択し、必要に応じて 現在ステータス（2000文字）に経過を記述
- 推奨課題（
R_IssueRecommendation）や リクエスト を紐づけ - 「保存」をクリック
📌 ポイント: 発生箇所の4項目（ログエンジン・クラス・メソッド・行番号）は、自動収集された課題（
AD_Issue）と突き合わせるためのキー情報です。エラーログからそのまま転記してください。
項目リファレンス
Section titled “項目リファレンス”既知課題 タブ（主要項目）
Section titled “既知課題 タブ（主要項目）”| 項目名 | 必須 | 型 | 説明 |
|---|---|---|---|
| クライアント | 必須 | Table Direct | 対象クライアント（テナント） |
| 組織 | 必須 | Table Direct | 対象組織 |
| リリースNo | 必須 | 文字列(10) | 内部リリース番号 |
| 課題要約 | 必須 | 文字列(255) | 課題の要約（一覧の識別子） |
| 説明 | - | 文字列(255) | 補足説明 |
| ログエンジン | - | 文字列(60) | ロガー名（CLogger のロガー） |
| クラス | - | 文字列(60) | 発生元クラス名 |
| メソッド | - | 文字列(60) | 発生元メソッド名 |
| 行番号 | - | 整数 | 発生行 |
| 課題ステータス | - | Table Direct | R_IssueStatus への参照 |
| 現在ステータス | - | テキスト(2000) | 現況の自由記述 |
| 課題推薦 | - | Search | R_IssueRecommendation への参照 |
| リクエスト | - | Search | R_Request への参照 |
| 処理中 | - | チェック | 処理中フラグ |
| 有効 | 必須 | チェック | レコードが有効かどうか |
よくある質問（FAQ）
Section titled “よくある質問（FAQ）”Q. 既知課題は自動で登録されますか？
Section titled “Q. 既知課題は自動で登録されますか？”iDempiere 13 標準では自動登録されません。課題の自動レポート送信を担っていた MIssue.report() は 13 で非推奨（forRemoval=true）となり、実装が空（常に null を返す）になっています。既知課題は手入力での台帳運用が前提です。
Q. 必須項目は何ですか？
Section titled “Q. 必須項目は何ですか？”「クライアント」「組織」「リリースNo」「課題要約」「有効」の5つです。発生箇所（ログエンジン・クラス・メソッド・行番号）とステータス系はすべて任意のため、要約だけでも登録できます。
Q. 「課題ステータス」と「現在ステータス」の違いは何ですか？
Section titled “Q. 「課題ステータス」と「現在ステータス」の違いは何ですか？”「課題ステータス」（R_IssueStatus_ID）は 課題ステータスマスタ を参照する選択項目で、集計・絞り込みに使えます。「現在ステータス」（IssueStatus）は 2000 文字のテキスト項目で、調査経過を自由に書くための欄です。両者は別カラムのため、併用してください。
Q. 登録件数が増えても大丈夫ですか？
Section titled “Q. 登録件数が増えても大丈夫ですか？”R_IssueKnown は大量データテーブル（IsHighVolume=Y）として定義されています。そのため一覧を開いた際は、iDempiere が自動で検索ダイアログを先に表示します。リリースNo やクラス名で絞り込んでから開いてください。
Q. 既知課題を削除できますか？
Section titled “Q. 既知課題を削除できますか？”R_IssueKnown は削除可能テーブル（IsDeleteable=Y）です。ただし過去の調査履歴が失われるため、通常は「有効」チェックを外して無効化する運用を推奨します。
- 課題ステータス（Issue Status）の使い方
- 課題システム（Issue System）の使い方
- 課題プロジェクト（Issue Project）の使い方
- リクエスト（Request）の使い方
- 画面リファレンス: 既知課題
🛠 技術仕様（開発者向け）
既知課題は R_IssueKnown テーブルに格納されます。専用のビジネスロジッククラス（M クラス）は存在せず、AD から自動生成された X_R_IssueKnown（395行）のみが提供されます。自動収集側の課題本体は別テーブル AD_Issue（MIssue・476行）で、既知課題はその参照先カタログという位置づけです。
| 項目 | 値 |
|---|---|
| テーブル | R_IssueKnown |
| ウィンドウ | AD_Window_ID: 369（Known Issue、iDempiere 13 では無効化） |
| モデルクラス | X_R_IssueKnown（生成クラスのみ・395行） |
| インターフェース | I_R_IssueKnown |
| アクセスレベル | 6（システム＋クライアント） |
| 削除可否 | 可（IsDeleteable=Y） |
| 大量データ | はい（IsHighVolume=Y） |
アーキテクチャ概要
Section titled “アーキテクチャ概要”classDiagram
class X_R_IssueKnown {
<<generated>>
+getIssueSummary() String
+getReleaseNo() String
+getSourceClassName() String
+getSourceMethodName() String
+getLineNo() int
+getR_IssueStatus_ID() int
}
class MIssue {
+create(LogRecord) MIssue
+process() String
+createAnswer() String
+getSystemStatus() String
+report() String
}
class PO {
<<abstract>>
}
X_R_IssueKnown --|> PO
MIssue --|> X_AD_Issue
X_AD_Issue --|> PO
MIssue --> X_R_IssueKnown : refers known issue
X_R_IssueKnown --> X_R_IssueStatus : R_IssueStatus_ID
パッケージ: org.compiere.model
ソースファイル: org.adempiere.base/src/org/compiere/model/X_R_IssueKnown.java
関連DBテーブル
Section titled “関連DBテーブル”R_IssueKnown（既知課題）
Section titled “R_IssueKnown（既知課題）”| カラム名 | 型 | 必須 | 説明 | 備考 |
|---|---|---|---|---|
| R_IssueKnown_ID | ID(10) | PK | 既知課題ID | 主キー |
| R_IssueKnown_UU | UUID(36) | N | UUID | |
| AD_Client_ID | Table Direct | Y | クライアント | |
| AD_Org_ID | Table Direct | Y | 組織 | |
| ReleaseNo | String(10) | Y | リリースNo | 識別子 |
| IssueSummary | String(255) | Y | 課題要約 | 識別子 |
| Description | String(255) | N | 説明 | |
| LoggerName | String(60) | N | ログエンジン名 | |
| SourceClassName | String(60) | N | 発生元クラス | |
| SourceMethodName | String(60) | N | 発生元メソッド | |
| LineNo | Integer(10) | N | 行番号 | |
| R_IssueStatus_ID | Table Direct | N | 課題ステータス | R_IssueStatus 参照 |
| IssueStatus | Text(2000) | N | 現在ステータス | 自由記述 |
| R_IssueRecommendation_ID | Search | N | 課題推薦 | R_IssueRecommendation 参照 |
| R_Request_ID | Search | N | リクエスト | R_Request 参照 |
| Processing | Yes-No(1) | N | 処理中 | |
| IsActive | Yes-No(1) | Y | 有効 |
erDiagram
R_IssueKnown ||--o| R_IssueStatus : "status"
R_IssueKnown ||--o| R_IssueRecommendation : "recommendation"
R_IssueKnown ||--o| R_Request : "linked request"
AD_Issue ||--o| R_IssueKnown : "matched known issue"
AD_Issue ||--o| R_IssueSystem : "reporting system"
AD_Issue ||--o| R_IssueProject : "reporting project"
AD_Issue ||--o| R_IssueUser : "reporting user"
ビジネスロジック
Section titled “ビジネスロジック”R_IssueKnown 自体には M クラスが無く、保存時のロジックは基底クラス PO の標準処理のみです。関連する課題本体 MIssue 側には次のメソッドが定義されています（MIssue.java・476行）。
| メソッド | 役割 |
|---|---|
create(LogRecord) | Java の LogRecord から課題レコードを生成 |
create(Properties, String hexInput) | HEX エンコードされた入力から課題を復元 |
setIssueSummary(String) / setStackTrace(String) / setErrorTrace(String) | 要約・スタックトレースの設定 |
addComments(String) / setComments(String) | コメントの追記・設定 |
process() / createAnswer() | 課題の処理・回答文の生成 |
getRequest() / getRequestDocumentNo() | 紐づくリクエストの取得 |
getSystemStatus() | 未設定時は SYSTEMSTATUS_Evaluation（"E"）を返す |
report() | 非推奨・未実装（@Deprecated(since="13", forRemoval=true)、常に null） |
report() が空実装であることが、この一連の課題レポート機能が iDempiere 13 で無効化されている技術的な根拠です。
拡張ポイント
Section titled “拡張ポイント”このテーブルにはカラム単位の Callout は定義されていません。既知課題の照合を自動化したい場合は、OSGi プラグインの Model Validator でエラー捕捉時に突き合わせる実装が有効です。
public class KnownIssueMatcher implements ModelValidator { @Override public String modelChange(PO po, int type) throws Exception { if (po instanceof MIssue && type == TYPE_BEFORE_NEW) { MIssue issue = (MIssue) po; // 例: クラス名・メソッド名で既知課題を照合し、既知なら通知を抑止 String sql = "SELECT R_IssueKnown_ID FROM R_IssueKnown" + " WHERE SourceClassName=? AND SourceMethodName=? AND IsActive='Y'"; int knownId = DB.getSQLValue(po.get_TrxName(), sql, issue.getSourceClassName(), issue.getSourceMethodName()); if (knownId > 0) { // 既知課題として扱う処理 } } return null; }
@Override public String docValidate(PO po, int timing) { return null; // R_IssueKnown は伝票型ではないため不要 }}関連プロセス
Section titled “関連プロセス”このウィンドウに紐づく標準プロセス・レポートはありません（標準メニュー未登録）。
関連ドキュメント
Section titled “関連ドキュメント”iDempiereカスタマイズのご相談
Section titled “iDempiereカスタマイズのご相談”既知課題の台帳は、エラーログ監視や社内チケットシステムと連携させることで初めて価値が出ます。 Ａｓ－Ｌｉｎｋ株式会社では、Model Validator によるエラー捕捉と外部チケット連携の実装をご支援します。
Ａｓ－Ｌｉｎｋ株式会社では、OSGiプラグインによる安全なカスタマイズを提供しています。