iDempiere 入出荷確認伝票の使い方｜在庫管理 操作マニュアル・技術仕様

📖 在庫管理の全体像: 在庫管理の業務フロー全体図 も合わせてご覧ください。

入出荷確認伝票は、出荷伝票・入荷伝票に対する検品・確認プロセスを記録する伝票です。伝票タイプで確認が必要と設定された出荷/入荷から自動的に作成され、確認伝票を完了しない限り元の出荷/入荷伝票は完了できません。ピッキング確認・品質検査（QA）確認・入出荷確認など複数の確認タイプに対応します。

📌 ポイント: 明細の「目標数量」と「確認済(正常品)数量」が一致しない明細が1件でもあると、伝票は自動的に「検討中（In Dispute）」となります。差異数量・欠陥品数量を入力して完了すると、クレジットメモ（仕入側）や棚卸伝票が自動生成され、数量差異が帳簿に反映されます。

入出荷確認伝票でできること

• 出荷・入荷伝票に対する検品結果（確認済数量）の記録
• ピッキング確認 / QA確認 / 入出荷確認など確認タイプ別の運用
• 差異数量（Difference）・欠陥品数量（Scrapped）の記録
• 入荷差異に対する仕入クレジットメモの自動生成
• 欠陥品数量に対する棚卸伝票（Physical Inventory）の自動生成
• 差異発生時の出荷伝票分割（伝票タイプ設定による）

画面構成

入出荷確認伝票はヘッダー＋明細の2タブ構成です。

タブ名	テーブル	項目数	役割
入出荷確認伝票	M_InOutConfirm	約16項目	元の入出荷伝票・確認タイプ・伝票状態の管理
入出荷確認伝票明細	M_InOutLineConfirm	約12項目	明細ごとの目標数量・確認済数量・差異・欠陥品数量

💡 ヒント: 明細タブの数量はすべて**在庫保管単位（storage UOM）**で表示されます。受発注単位と異なる場合は換算後の数量で確認してください。

基本操作手順

graph TD
    A["📦 出荷/入荷伝票を準備<br/>（確認要の伝票タイプ）"] --> B["🧾 入出荷確認伝票が<br/>明細付きで自動作成される"]
    B --> C["🔍 現物を検品し<br/>確認済(正常品)数量を入力"]
    C --> D{目標数量と一致?}
    D -->|一致| E["✅ 確認プロセス > 完了"]
    D -->|不一致| F["⚠️ 差異数量・欠陥品数量を入力<br/>（伝票は検討中フラグON）"]
    F --> G["✅ 確認プロセス > 完了<br/>クレジットメモ/棚卸伝票を自動生成"]
    E --> H["📤 元の出荷/入荷伝票を完了"]
    G --> H

出荷/入荷伝票を準備 （確認要の伝票タイプ） 入出荷確認伝票が 明細付きで自動作成される 現物を検品し 確認済(正常品)数量を入力 確認プロセス > 完了 差異数量・欠陥品数量を入力 （伝票は検討中フラグON） 確認プロセス > 完了 クレジットメモ/棚卸伝票を自動生成 元の出荷/入荷伝票を完了 目標数量と一致? 一致 不一致

⚠️ 注意: 確認伝票が未完了のままでは、元の出荷/入荷伝票の完了はブロックされます。検品が終わったら必ず確認伝票を先に完了してください。

アクセス方法

メニューから「在庫管理 > 入出荷確認伝票」を開きます。

確認伝票の作成（自動作成）

入出荷確認伝票は手入力で新規作成するのではなく、出荷/入荷伝票の準備処理時に自動作成されます（MInOutConfirm.create()）。

1. 伝票タイプに確認（ピッキング/QA確認、入出荷確認）が設定された出荷/入荷伝票を作成・準備
2. 元伝票の全明細がコピーされた確認伝票が自動生成される
3. 「入出荷確認伝票」ウィンドウで対象伝票を開く

検品結果の入力と完了

1. 明細タブで各行の「確認済(正常品)数量」を実際の検品数量に修正
2. 数量が合わない場合:
   • 差異数量: 目標数量に対して不足・過剰となった数量
   • 欠陥品数量: 品質不良で受け入れられない数量
3. ヘッダーに戻り「確認プロセス」ボタンから「完了」を実行
4. 差異があった場合、処理メッセージにクレジットメモ番号・棚卸伝票番号が表示される

伝票処理（DocAction / DocStatus）

stateDiagram-v2
    [*] --> DR : 自動作成（既定値 DR）
    DR --> IP : 準備（prepareIt）
    IP --> CO : 完了（completeIt）
    DR --> CO : 完了（内部で準備を実行）
    CO --> CL : クローズ
    DR --> VO : 無効化
    IP --> VO : 無効化

*

処理	メソッド	動作
準備	prepareIt()	明細0件なら @NoLines@ でエラー。目標数量≠確認済数量の明細があると「検討中」をONにする
完了	completeIt()	明細ごとに元の入出荷明細へ数量を書き戻し。差異・欠陥品があればクレジットメモ / 棚卸伝票を自動生成
無効化	voidIt()	確認伝票を無効化する
クローズ	closeIt()	完了後の伝票をクローズする

DocStatus の初期値は DR（ドラフト）、DocAction の初期値は CO（完了）です。

項目リファレンス

入出荷確認伝票タブ（ヘッダー）

項目名	必須	型	説明
伝票番号	必須	文字列	確認伝票の伝票番号
確認No	-	文字列	外部の確認番号（納品書番号等）
入出荷伝票	必須	検索	確認対象の出荷/入荷伝票
確認タイプ	必須	リスト	ピッキング/QA確認、入出荷確認、得意先確認、仕入先確認、直送確認
伝票状態	必須	リスト	初期値はドラフト（DR）
確認プロセス	必須	ボタン	伝票処理の実行（初期値: 完了）
検討中	自動	チェック	未確認数量がある場合に準備処理で自動ON
キャンセル	-	チェック	取引がキャンセルされたことを示す
棚卸伝票	自動	検索	欠陥品数量から自動生成された棚卸伝票への参照
売上請求伝票	自動	検索	差異数量から自動生成されたクレジットメモへの参照
パッケージ作成	-	ボタン	出荷用パッケージの作成

入出荷確認伝票明細タブ

項目名	必須	型	説明
入出荷明細	必須	検索	元の出荷/入荷伝票の明細行
目標数量	必須	数量	元伝票の予定移動数量
確認済(正常品)数量	必須	数量	検品で確認できた正常品の数量
差異数量	-	数量	目標との差異（不足分等）
欠陥品数量	-	数量	品質問題で廃棄対象となる数量
棚卸伝票明細	自動	検索	生成された棚卸伝票明細への参照
請求伝票明細	自動	検索	生成されたクレジットメモ明細への参照

全項目の一覧は 画面リファレンス を参照してください。

よくある質問（FAQ）

Q. 「検討中（In Dispute）」フラグが勝手にONになるのはなぜですか？

準備処理（prepareIt）で全明細がチェックされ、目標数量と確認済数量が一致しない明細が1件でもあると自動的に「検討中」がONになります。全明細を一致させて再度準備するか、差異として処理してください。

Q. 完了時にクレジットメモが作成されるのはどんな場合ですか？

ソース上の条件は「差異数量が0でない、かつ入荷（仕入側）伝票で、かつ発注に紐づく参照入出荷がある」場合です（createDifferenceDoc）。仕入クレジットメモ（AP Credit Memo）が1枚作成され、確認伝票ヘッダーの「売上請求伝票」欄と明細の「請求伝票明細」欄にリンクされます。

Q. 欠陥品数量を入力するとどうなりますか？

完了時に対象倉庫の棚卸伝票（Physical Inventory）が自動作成され、欠陥品数量分の棚卸明細が追加されます。生成された伝票はヘッダーの「棚卸伝票」欄から参照できます。棚卸伝票の処理は 実地棚卸 の手順に従ってください。

Q. 明細が0件のまま完了しようとするとどうなりますか？

準備処理で @NoLines@ エラーとなり、伝票状態は「無効（Invalid）」になります。確認伝票は元伝票から明細ごと自動作成されるため、通常この状態にはなりませんが、明細を削除した場合は発生します。

Q. 確認タイプによって処理は変わりますか？

変わります。「ピッキング/QA確認」「入出荷確認」では確認済数量が元明細の移動数量（MovementQty）に書き戻されますが、「得意先確認」「仕入先確認」では確認済数量の記録のみで移動数量は変更されません（MInOutLineConfirm.processLine()）。

関連機能

• 出荷伝票（Shipment）の使い方
• 入荷伝票（Material Receipt）の使い方
• 実地棚卸（Physical Inventory）の使い方
• 画面リファレンス: 入出荷確認伝票

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

概要

入出荷確認伝票は Document 型のウィンドウで、ヘッダー M_InOutConfirm・明細 M_InOutLineConfirm に格納されます。MInOutConfirm クラス（895行）が DocAction を実装し、確認プロセス・差異伝票（クレジットメモ/棚卸）の生成・出荷分割を担います。明細側は MInOutLineConfirm クラス（210行）です。

アーキテクチャ概要

classDiagram
    class MInOutConfirm {
        +create(MInOut, confirmType, checkExisting)$ MInOutConfirm
        +getLines(boolean) MInOutLineConfirm[]
        +processIt(String) boolean
        +prepareIt() String
        +completeIt() String
        +voidIt() boolean
        -splitInOut(MInOut, int, MInOutLineConfirm[])
        -createDifferenceDoc(MInOut, MInOutLineConfirm) boolean
    }
    class MInOutLineConfirm {
        +setInOutLine(MInOutLine)
        +processLine(boolean, String) boolean
        +isFullyConfirmed() boolean
    }
    class X_M_InOutConfirm {
        <<generated>>
    }
    class DocAction {
        <<interface>>
    }
    MInOutConfirm --|> X_M_InOutConfirm
    MInOutConfirm ..|> DocAction
    MInOutConfirm --> MInOutLineConfirm : has many
    MInOutConfirm --> MInvoice : creates credit memo
    MInOutConfirm --> MInventory : creates phys. inventory

+create(MInOut, confirmType, checkExisting)$ MInOutConfirm +getLines(boolean) MInOutLineConfirm[] +processIt(String) boolean +prepareIt() String +completeIt() String +voidIt() boolean -splitInOut(MInOut, int, MInOutLineConfirm[]) -createDifferenceDoc(MInOut, MInOutLineConfirm) boolean +setInOutLine(MInOutLine) +processLine(boolean, String) boolean +isFullyConfirmed() boolean <> <> > X_M_InOutConfirm MInOutConfirm ..

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

関連DBテーブル

M_InOutConfirm（入出荷確認伝票）

カラム名	型	必須	説明	備考
M_InOutConfirm_ID	ID	PK	確認伝票ID	主キー
DocumentNo	String	Y	伝票番号	識別子
M_InOut_ID	Search	Y	入出荷伝票FK
ConfirmType	List	Y	確認タイプ	下記5種
ConfirmationNo	String	N	確認No	20桁
DocStatus	List	Y	伝票状態	デフォルト DR
DocAction	Button	Y	伝票アクション	デフォルト CO
IsApproved	YesNo	Y	承認済み
ApprovalAmt	Amount	N	承認金額
IsInDispute	YesNo	Y	検討中	デフォルト N、prepareIt で自動設定
IsCancelled	YesNo	Y	キャンセル
M_Inventory_ID	Search	N	棚卸伝票FK	欠陥品数量から自動生成
C_Invoice_ID	Search	N	請求伝票FK	差異のクレジットメモ
Processed	YesNo	Y	処理済み

M_InOutLineConfirm（入出荷確認伝票明細）

カラム名	型	必須	説明	備考
M_InOutLineConfirm_ID	ID	PK	明細ID	主キー
M_InOutConfirm_ID	Search	Y	ヘッダーFK	親リンク
M_InOutLine_ID	Search	Y	入出荷明細FK	識別子
TargetQty	Quantity	Y	目標数量	元明細の MovementQty
ConfirmedQty	Quantity	Y	確認済数量
DifferenceQty	Quantity	N	差異数量
ScrappedQty	Quantity	N	欠陥品数量
M_InventoryLine_ID	Search	N	棚卸明細FK	自動リンク
C_InvoiceLine_ID	Search	N	請求明細FK	自動リンク
Processed	YesNo	Y	処理済み

ビジネスロジック

確認伝票の生成（create）

MInOutConfirm.create(MInOut ship, String confirmType, boolean checkExisting) は、同一確認タイプの既存確認があればそれを返し、なければ新規作成して出荷/入荷の全明細を MInOutLineConfirm にコピーします。

prepareIt()

1. 明細0件なら @NoLines@ で STATUS_Invalid
2. 各明細の isFullyConfirmed()（TargetQty == ConfirmedQty）を判定し、未確認明細があれば IsInDispute=true
3. DocAction を Complete にセットし STATUS_InProgress を返却

completeIt()

flowchart TD
    A[completeIt] --> B{IsInDispute かつ<br/>伝票タイプ IsSplitWhenDifference?}
    B -->|Yes| C[splitInOut で差異分を<br/>別出荷伝票へ分割<br/>C_DocTypeDifference_ID 必須]
    B -->|No| D[全明細ループ]
    C --> D
    D --> E[processLine: 元明細へ数量書戻し]
    E --> F{isFullyConfirmed?}
    F -->|Yes| G[Processed=Y]
    F -->|No| H[createDifferenceDoc]
    H --> I{DifferenceQty≠0 かつ 仕入側<br/>かつ Ref_InOut あり?}
    I -->|Yes| J[AP Credit Memo 生成<br/>C_Invoice_ID リンク]
    H --> K{ScrappedQty≠0?}
    K -->|Yes| L[棚卸伝票 生成<br/>M_Inventory_ID リンク]
    G --> M[DocAction=Close<br/>STATUS_Completed]
    J --> M
    L --> M

IsInDispute かつ 伝票タイプ IsSplitWhenDifference? isFullyConfirmed? DifferenceQty≠0 かつ 仕入側 かつ Ref_InOut あり? ScrappedQty≠0? splitInOut で差異分を 別出荷伝票へ分割 C_DocTypeDifference_ID 必須 全明細ループ processLine: 元明細へ数量書戻し Processed=Y AP Credit Memo 生成 C_Invoice_ID リンク 棚卸伝票 生成 M_Inventory_ID リンク DocAction=Close STATUS_Completed

• 差異分割は伝票タイプの IsSplitWhenDifference フラグで制御され、分割先伝票タイプ C_DocTypeDifference_ID が未設定の場合はエラーになります
• 棚卸伝票の伝票タイプは DocBaseType=棚卸・DocSubTypeInv=Physical Inventory のものが自動選択されます（setInventoryDocType）

processLine の確認タイプ別動作（MInOutLineConfirm）

確認タイプ	元明細への書き戻し
得意先確認（CustomerConfirmation）	ConfirmedQty のみ
仕入先確認（VendorConfirmation）	ConfirmedQty のみ
直送確認（DropShipConfirm）	なし
ピッキング/QA確認（PickQAConfirm）	TargetQty / MovementQty=ConfirmedQty / PickedQty / ScrappedQty
入出荷確認（ShipReceiptConfirm）	TargetQty / MovementQty=ConfirmedQty（仕入側は +ScrappedQty） / ScrappedQty

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

Document 型のため、ModelValidator.docValidate() の TIMING_BEFORE_PREPARE / TIMING_AFTER_PREPARE / TIMING_BEFORE_COMPLETE / TIMING_AFTER_COMPLETE の各タイミングフックがソース上で発火します。確認数量の妥当性チェックや、差異発生時の通知処理は TIMING_AFTER_COMPLETE で IsInDispute を参照して実装できます。gw_column 上、本テーブルのカラムに標準 Callout の設定はありません。

public class ConfirmValidator implements ModelValidator {
    @Override
    public String docValidate(PO po, int timing) {
        if (po instanceof MInOutConfirm && timing == TIMING_BEFORE_COMPLETE) {
            MInOutConfirm confirm = (MInOutConfirm) po;
            // 例: 差異がある場合は承認者のみ完了可能にする
            if (confirm.isInDispute() && !confirm.isApproved())
                return "差異がある確認伝票は承認後に完了してください";
        }
        return null;
    }
}

関連プロセス

プロセス名	説明
確認プロセス（DocAction）	ヘッダーの伝票処理ボタン
パッケージ作成（CreatePackage）	出荷用パッケージの作成ボタン

関連ドキュメント

• 画面リファレンス: 入出荷確認伝票
• 出荷伝票の使い方
• 入荷伝票の使い方
• 実地棚卸の使い方

---

iDempiereカスタマイズのご相談

入出荷確認伝票は、検品プロセスの厳格化（ダブルチェック・承認フロー）や差異発生時の自動通知など、Model Validator でコア改変なしに拡張できます。

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

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