iDempiere 請求照合伝票の使い方|購買管理 操作マニュアル・技術仕様
This content is not available in your language yet.
📖 購買管理の全体像: 購買管理の全体図 も合わせてご覧ください。
請求照合伝票(Matched Invoices)は、仕入請求伝票の明細行と入荷伝票の明細行がどの数量で結び付いたかを記録する照合レコードを照会する画面です。レコードは仕入請求伝票や入荷伝票の完了処理に伴って自動生成されるため、この画面は基本的に「結果を確認する」ための画面です。
📌 ポイント: 請求照合伝票は手作業で作るものではなく、入荷と請求の突合結果が自動的に積み上がる台帳です。数量の食い違いを調べるときは、まずこの画面で「入荷明細に対して何件・何数量の請求が当たっているか」を確認します。
請求照合伝票でできること
Section titled “請求照合伝票でできること”- 仕入請求伝票明細(
C_InvoiceLine)と入荷明細(M_InOutLine)の照合結果の照会 - 照合された数量(
Qty)と品目・属性セットインスタンスの確認 - 取引日付(
DateTrx)・転記日付(DateAcct)による照合時点の把握 - 転記状態(
Posted)の確認 - 誤った照合レコードの削除(「削除」ボタン=
Processing) - 参照元照合レコード(
Ref_MatchInv_ID)による取消(リバース)関係の追跡
請求照合伝票は 1 タブ構成のシンプルな照会ウィンドウです。
| タブ名 | テーブル | 項目数 | 役割 |
|---|---|---|---|
| 請求照合伝票 | M_MatchInv | 16項目 | 請求明細と入荷明細の照合結果の照会・削除 |
💡 ヒント: このウィンドウには明細タブがありません。1 レコード=「請求明細 1 行 × 入荷明細 1 行 × 数量」の 1 組の照合を表します。1 本の請求明細が複数の入荷に分かれて照合された場合、その分だけレコードが増えます。
基本操作手順
Section titled “基本操作手順”graph TD
A["📥 入荷伝票を完了<br/>(入荷明細が確定)"] --> C["🔗 照合レコードが<br/>自動生成<br/>M_MatchInv"]
B["🧾 仕入請求伝票を完了<br/>(発注・入荷を参照)"] --> C
C --> D["🔍 請求照合伝票ウィンドウで<br/>照合結果を照会"]
D --> E{数量は妥当か}
E -->|正しい| F["✅ 転記状態を確認<br/>(Posted)"]
E -->|誤っている| G["🗑 削除ボタンで<br/>照合レコードを取消"]
G --> H["🔁 請求伝票・入荷伝票を<br/>修正して再照合"]
⚠️ 注意: 照合レコードを削除すると、その請求明細は「未照合」の状態に戻ります。会計上の突合結果に直接影響するため、削除は原因を特定したうえで実施してください。
アクセス方法(メニューパス)
Section titled “アクセス方法(メニューパス)”メニューから「購買管理 > 請求照合伝票」を開きます。
- メニューから「請求照合伝票」を開く
- 検索(虫めがね)で対象を絞り込む
- 仕入請求伝票明細: 特定の請求明細に紐づく照合を調べる場合
- 入荷明細: 特定の入荷明細に紐づく照合を調べる場合
- 品目: 品目単位で照合状況を俯瞰する場合
- 取引日付 / 転記日付: 期間で絞り込む場合
- 数量列で、照合済み数量が想定どおりか確認する
誤った照合の削除
Section titled “誤った照合の削除”- 対象の照合レコードを選択
- 「削除」ボタン(カラム名
Processing、説明は “Delete Invoice Matching Record”)を実行 - 元の仕入請求伝票・入荷伝票の内容を修正し、再度照合を行う
📌 ポイント: 「削除」ボタンは通常のレコード削除とは別に用意された処理ボタンです。照合レコードの整合性を保った形で取り消すため、削除はこのボタンから実施してください。
項目リファレンス
Section titled “項目リファレンス”請求照合伝票タブ(主要項目)
Section titled “請求照合伝票タブ(主要項目)”| 項目名 | 必須 | 型 | 説明 |
|---|---|---|---|
| クライアント | 必須 | 選択 | テナント |
| 組織 | 必須 | 選択 | 組織 |
| 伝票番号 | - | 文字列 | 照合レコードの伝票番号 |
| 取引日付 | 必須 | 日付 | 照合が行われた取引日 |
| 転記日付 | 必須 | 日付 | 会計計上日 |
| 説明 | - | 文字列 | 任意の説明 |
| 仕入請求伝票明細 | 必須 | 検索 | 照合対象の請求明細 |
| 入荷明細 | - | 検索 | 照合対象の入荷明細 |
| 品目 | 必須 | 検索 | 照合対象の品目 |
| 属性セットインスタンス | - | 品目属性 | ロット・シリアル等の属性 |
| 数量 | 必須 | 数量 | 照合された数量 |
| Referenced Match Invoice | - | 検索 | 参照元の照合レコード(取消時に使用) |
| 処理済み | 必須 | チェック | 処理済みフラグ |
| 転記 | 必須 | ボタン | 転記状態の確認 |
| 削除 | 必須 | ボタン | 照合レコードの削除処理 |
よくある質問(FAQ)
Section titled “よくある質問(FAQ)”Q. 「Total matched qty > movement qty」というエラーが出ます
Section titled “Q. 「Total matched qty > movement qty」というエラーが出ます”入荷明細に対して照合された数量の合計が、その入荷明細の移動数量(MovementQty)を超えています。MMatchInv.afterSave() は保存のたびに M_MatchInv の数量合計と入荷明細の移動数量を突き合わせ、超過した場合に例外を送出します。重複した照合レコードが残っていないかを確認し、余分な照合を削除してください。
Q. 転記日付(DateAcct)はどう決まりますか?
Section titled “Q. 転記日付(DateAcct)はどう決まりますか?”MMatchInv.beforeSave() で自動設定されます。未設定の場合は getNewerDateAcct()(関連する請求/入荷側の新しい方の転記日付)を採用し、それも取得できない場合は取引日付(DateTrx)が設定されます。取引日付自体も未設定であれば当日日付がセットされます。
Q. 属性セットインスタンスが自動で入るのはなぜですか?
Section titled “Q. 属性セットインスタンスが自動で入るのはなぜですか?”beforeSave() において、属性セットインスタンスが未設定かつ入荷明細が指定されている場合、入荷明細(M_InOutLine)の属性セットインスタンスがコピーされます。ロット・シリアル管理品目でも入荷側の属性がそのまま引き継がれます。
Q. 請求照合伝票と発注照合伝票の違いは?
Section titled “Q. 請求照合伝票と発注照合伝票の違いは?”請求照合伝票(M_MatchInv)は仕入請求伝票明細と入荷明細の照合、発注照合伝票(M_MatchPO)は発注伝票明細と入荷明細/仕入請求伝票明細の照合を記録します。三者照合(発注・入荷・請求)を追う場合は両方の画面を併用します。
Q. 照合レコードを直接新規作成できますか?
Section titled “Q. 照合レコードを直接新規作成できますか?”このウィンドウはあくまで照合結果の照会・削除を目的としています。照合レコードは請求伝票・入荷伝票の処理を通じて生成されるため、業務上は元伝票側を正しく処理することで照合を成立させてください。
- 発注照合伝票(Matched Purchase Orders)の使い方
- 仕入請求伝票(Purchase Invoice)の使い方
- 入荷伝票(Material Receipt)の使い方
- 発注伝票(Purchase Order)の使い方
- 画面リファレンス: 請求照合伝票
🛠 技術仕様(開発者向け)
請求照合伝票は M_MatchInv テーブルに格納されます。テーブル説明は “Match Shipment/Receipt to Invoice”、アクセスレベルは 3(クライアント+組織)、削除可能(IsDeleteable=Y)です。モデルクラスは MMatchInv(479行)で、X_M_MatchInv を継承します。Document 型(DocAction/DocStatus)ではありませんが、Posted / DateAcct を持つ転記対象レコードです。
アーキテクチャ概要
Section titled “アーキテクチャ概要”classDiagram
class MMatchInv {
+get(ctx, M_InOutLine_ID, C_InvoiceLine_ID, trxName) MMatchInv[]
+getInvoiceLine(ctx, C_InvoiceLine_ID, trxName) MMatchInv[]
+getInOut(ctx, M_InOut_ID, trxName) MMatchInv[]
+getInvoice(ctx, ...) MMatchInv[]
+getInvoiceByDateAcct(ctx, C_Invoice_ID, DateAcct, trxName) MMatchInv[]
+getInOutLine(ctx, ...) MMatchInv[]
+getNewerDateAcct() Timestamp
+reverse(Timestamp) boolean
+isReversal() boolean
#beforeSave(boolean) boolean
#afterSave(boolean, boolean) boolean
#beforeDelete() boolean
#afterDelete(boolean) boolean
}
class X_M_MatchInv {
<<generated>>
}
class PO {
<<abstract>>
}
MMatchInv --|> X_M_MatchInv
X_M_MatchInv --|> PO
MMatchInv --> MInvoiceLine : matches
MMatchInv --> MInOutLine : matches
パッケージ: org.compiere.model
ソースファイル: org.adempiere.base/src/org/compiere/model/MMatchInv.java
関連DBテーブル
Section titled “関連DBテーブル”M_MatchInv(請求照合伝票)
Section titled “M_MatchInv(請求照合伝票)”| カラム名 | 型 | 必須 | 説明 | 備考 |
|---|---|---|---|---|
| M_MatchInv_ID | ID | PK | 照合ID | 主キー |
| AD_Client_ID | Table Direct | Y | クライアント | default @#AD_Client_ID@ |
| AD_Org_ID | Table Direct | Y | 組織 | default @#AD_Org_ID@ |
| DocumentNo | String | N | 伝票番号 | 更新可 |
| DateTrx | Date | Y | 取引日付 | 未設定時は beforeSave で当日 |
| DateAcct | Date | Y | 転記日付 | 未設定時は getNewerDateAcct() |
| C_InvoiceLine_ID | Search | Y | 仕入請求伝票明細 | 照合対象 |
| M_InOutLine_ID | Search | N | 入荷明細 | 照合対象 |
| M_Product_ID | Search | Y | 品目 | |
| M_AttributeSetInstance_ID | Product Attribute | N | 属性セットインスタンス | 入荷明細から自動コピー |
| Qty | Quantity | Y | 数量 | 照合数量 |
| Ref_MatchInv_ID | Search | N | 参照元照合レコード | 取消(リバース)用 |
| Reversal_ID | Search | N | 取消ID | |
| Processed | Yes-No | Y | 処理済み | |
| ProcessedOn | Number | N | 処理日時 | |
| Processing | Button | Y | 削除処理ボタン | Delete Invoice Matching Record |
| Posted | Button | Y | 転記状態 | |
| Description | String | N | 説明 |
erDiagram
C_InvoiceLine ||--o{ M_MatchInv : "matched by"
M_InOutLine ||--o{ M_MatchInv : "matched by"
M_Product ||--o{ M_MatchInv : "product"
M_MatchInv ||--o| M_MatchInv : "Ref_MatchInv_ID reversal"
C_Invoice ||--o{ C_InvoiceLine : "lines"
M_InOut ||--o{ M_InOutLine : "lines"
ビジネスロジック
Section titled “ビジネスロジック”beforeSave() の処理
Section titled “beforeSave() の処理”MMatchInv.beforeSave() は 3 つの既定値補完を行います。
- 取引日付の補完:
DateTrxが null の場合、システム日時をセット - 転記日付の補完:
DateAcctが null の場合、getNewerDateAcct()の戻り値を、null ならDateTrxをセット - 属性セットインスタンスの継承:
M_AttributeSetInstance_ID = 0かつM_InOutLine_ID != 0の場合、入荷明細(MInOutLine)の属性セットインスタンスをコピー
afterSave() の数量検証
Section titled “afterSave() の数量検証”保存成功後、照合数量の超過を検証します。
flowchart TD
A[afterSave 成功] --> B{M_InOutLine_ID > 0?}
B -->|Yes| C["SELECT SUM(Qty) FROM M_MatchInv<br/>WHERE M_InOutLine_ID=?"]
C --> D{"matchedQty > MovementQty?"}
D -->|Yes| E["IllegalStateException<br/>Total matched qty > movement qty"]
D -->|No| F{C_InvoiceLine_ID > 0?}
B -->|No| F
F -->|Yes| G[請求明細側も同様に検証]
F -->|No| H[正常終了]
G --> H
移動数量が負(返品入荷等)の場合は、比較前に移動数量と照合数量の符号を反転させたうえで大小比較を行います。
取消(リバース)
Section titled “取消(リバース)”reverse(Timestamp reversalDate) により、照合レコードの取消が可能です。取消後のレコードは isReversal() で判定でき、Ref_MatchInv_ID / Reversal_ID により元レコードとの関係を追跡できます。
検索用ユーティリティ
Section titled “検索用ユーティリティ”MMatchInv は用途別の静的検索メソッドを備えています。
| メソッド | 用途 |
|---|---|
get(ctx, M_InOutLine_ID, C_InvoiceLine_ID, trxName) | 入荷明細と請求明細の組で取得 |
getInvoiceLine(ctx, C_InvoiceLine_ID, trxName) | 請求明細に紐づく照合を取得 |
getInOutLine(ctx, ...) | 入荷明細に紐づく照合を取得 |
getInOut(ctx, M_InOut_ID, trxName) | 入荷伝票単位で取得 |
getInvoice(ctx, ...) | 請求伝票単位で取得 |
getInvoiceByDateAcct(ctx, C_Invoice_ID, DateAcct, trxName) | 請求伝票+転記日付で取得 |
拡張ポイント(カスタマイズ箇所)
Section titled “拡張ポイント(カスタマイズ箇所)”OSGi Model Validator(推奨)
Section titled “OSGi Model Validator(推奨)”M_MatchInv は Document 型ではないため、docValidate() ではなく modelChange() で制御します。
public class CustomMatchInvValidator implements ModelValidator { @Override public int modelChange(PO po, int type) throws Exception { if (po instanceof MMatchInv && (type == TYPE_BEFORE_NEW || type == TYPE_BEFORE_CHANGE)) { MMatchInv mi = (MMatchInv) po; // 例: 照合数量ゼロの登録を禁止する if (mi.getQty() != null && mi.getQty().signum() == 0) { throw new AdempiereException("照合数量が0の請求照合は登録できません"); } } return null; }}Callout
Section titled “Callout”M_MatchInv の各カラムには標準の Callout(AD_Column.Callout)が設定されていません。入力補助を追加する場合は独自 Callout を AD_Column に登録するか、Model Validator 側で値を補完します。
照合ロジックの拡張
Section titled “照合ロジックの拡張”照合レコードは請求伝票・入荷伝票の処理経路から生成されるため、生成条件そのものを変えたい場合は C_Invoice / M_InOut の docValidate()(TIMING_AFTER_COMPLETE)でフックし、MMatchInv の生成・削除を制御します。
関連ドキュメント
Section titled “関連ドキュメント”iDempiereカスタマイズのご相談
Section titled “iDempiereカスタマイズのご相談”請求照合の数量検証ルールや、照合レコードの自動生成タイミングは、Model Validator によってコアを改変せずに調整できます。 三者照合(発注・入荷・請求)を自社の検収ルールに合わせて厳格化する要件にも対応可能です。
As-Link株式会社では、OSGiプラグインによる安全なカスタマイズを提供しています。