製造業の完成品入庫管理システム導入｜完工・検査・倉庫確定をつなぐ

製造業の完成品入庫管理システムを導入するとき、最後の工程で「完了」を押せば在庫も出荷可能になる、と考えると事故が起きます。現場の完工報告、品質部門の合否判定、倉庫での現物受領、ERPの在庫計上は、同じ製品について起きる別々の出来事です。これらの時刻、数量、ロット、保管場所、責任者をつないで初めて、営業が約束できる在庫が確定します。本記事はタイの製造拠点でMES、QMS、WMS、ERPを連携する担当者に向け、要件定義からRFP、FAT/SATまでの実務を整理します。

完成品入庫管理で最初に決めるべき「四つの完了」

工程の最終作業が終わったことを作業完了、生産指図に対して良品・不良品の数量を報告したことを完工報告、品質担当が出荷可否を決めたことを品質判定、倉庫が棚または保留場所へ実物を受け入れたことを入庫確定と呼び分けます。この区別は特定のソフトの画面名ではなく、導入時に合意する業務上の定義です。工程完了時にどの時点で在庫が増えるかは製品設定と運用によって変わります。たとえばMicrosoft Dynamics 365は「Report as finished」により生産指図から在庫へ数量を移し、設定次第で品質オーダーと棚入れ作業も生成できます。SAP S/4HANAも生産からの入庫と検査在庫を扱います。したがって「完工＝即出荷可能」とする一律の説明は適切ではありません。Microsoftの完工報告、SAPの入庫時検査

実務では、次の四つを別列にした状態台帳を最初に作ります。

表の最後の列は自社のルールとして決めるもので、どのERPでも自動的に同じになるわけではありません。検査前でも会計上の在庫数量を認識する構成はあり得ます。その場合は「帳簿上存在する」と「販売可能」を異なる在庫属性にしてください。SAPの公式資料は、入庫時に検査ロットを作り、検査在庫からの払出を使用決定で制御する例を示しています。ここから導く設計上の要点は、数を一つに合わせるだけでは足りず、状態別の数量を一致させることです。

なぜ「製造実績収集」や「部材払出」とは別のシステム要件なのか

仕掛品管理では工程間の滞留、部材払出管理では生産指図へ投入する部材の引当・消費を扱います。完成品入庫はその後段です。作ったと報告された製品が、いつ、どの状態で、どの倉庫に現物として届き、どの時点から出荷や次工程に使えるかを確定する取引です。部材払出の逆仕訳を機械的に作るだけでは、品質保留、部分完工、容器の分割、誤ラベルの貼り替えを扱えません。

例えば100個を生産指図に対して開始し、最終工程で96個が良品候補、4個が不良と報告されたとします。良品候補96個のうち20個を検査保留、76個を合格とし、さらに合格品のうち70個だけが倉庫の所定棚に格納されたなら、少なくとも「完工報告96」「検査保留20」「品質合格76」「棚入れ済70」という異なる数が存在します。ここで96個を営業の即納可能在庫にしてしまうと、現物が見つからないか、未判定品を出荷する危険があります。逆に70個だけを生産実績として計上すると、工程能力と歩留まりを正しく見られません。この100・96・4・20・76・70は説明用の架空値であり、業界平均値ではありません。

ISA-95は製造オペレーションとERP側の事業・物流活動の境界で、何の情報を交換するかを定義する枠組みを提供します。実装時には特定製品の画面を先に選ぶのではなく、「どのシステムがどのイベントの正本か」を決める順番が重要です。ISA-95の公式概要

完成品入庫の標準フロー：生産指図から販売可能在庫まで

1. 指図と品目を照合する

完工報告の入口では、生産指図番号、完成品品目、仕様版、製造拠点、予定数量、単位、ロット採番規則を照合します。品目名の自由入力だけで入庫先を決めてはいけません。品番の改訂や包装単位が変わる場合、旧版のまま棚へ入れると、在庫の数が正しくても顧客の注文仕様に合わなくなります。指図の版と出荷用ラベルの版を同じマスタIDで引けるようにします。指図が途中で変更されるなら、変更後に再確認が必要な項目を明示します。

2. 良品候補・不良・副産物を別に報告する

完工報告の入力欄を単なる「完成数」にしないことが大切です。良品候補、工程不良、スクラップ、再作業待ち、必要なら副産物を分けます。Microsoftの公式手順でも良品数量とエラー数量を別入力し、エラー理由を関連付けます。Oracleの製造機能は工程取引の検査結果や出力を扱い、製造の種類によって追加出力を在庫に報告します。こうした製品例は要件の可能性を示す資料として使い、自社に必要な状態を要件表で固定します。Microsoftの操作手順、Oracle Manufacturing概要

3. ロット・シリアル・容器IDを紐付ける

完成品がロット管理品なら、同じ指図から複数ロットへ分割した際に各ロットの数量と原材料の対応を追えるようにします。シリアル管理品なら同じ番号を二重に完工できない検証が必要です。パレットや箱に入れる場合は、商品識別子と物流単位識別子を混同しないでください。GS1ではGTINが取引単位の商品識別、SSCCが物流単位の識別に使われ、ロット番号にも別のアプリケーション識別子があります。自社内ラベルを使う場合でも、品目・ロット・容器を別フィールドにしておくと連携と再梱包が容易です。GS1 General Specifications

4. 品質保留と合格を分ける

検査を要する品目では、完工の直後に自動で販売可能へ移してはいけません。検査対象、抜取単位、検査結果、判定者、判定時刻、部分合格の扱いを決めます。SAPの倉庫・品質連携例は、生産または購買からの入庫時に検査ロットを作り、品質在庫に置き、判定後に合格品を棚へ移す流れを示しています。部分ロット判定を扱える場合もあります。運用設計では不合格品の隔離場所と再作業への戻し先まで決めます。SAP Quality Management in Warehousing、リワーク管理の実務

5. 倉庫で現物受領と棚入れを確定する

生産側の完工報告は、倉庫側の実物受領と一致しないことがあります。容器を生産側の出荷口でスキャンし、倉庫の受入場所で再スキャンして、同じ容器ID・数量であることを照合します。数が違えば自動で差異ケースを作り、理由を選び、誰が修正できるかを定義します。棚入れ先のロケーションまで記録すれば、在庫は「帳簿上ある」から「探せる」に変わります。Microsoft Dynamics 365の完工報告は設定により出力ロケーションから最終格納先への棚入れ作業を生成します。ここでも、完工と棚入れを同一イベントにまとめない設計が重要です。

6. ERPの在庫・原価と突合する

完成品入庫は数量だけでなく評価額にも影響します。原価計算のタイミングと方式は企業ごとに異なるため、導入時には「物理在庫の増加」「会計伝票」「製造指図の終了」を別に照合します。Microsoftの公式資料は、完工報告で在庫を更新し、設定に応じて仕掛勘定と完成品在庫の仕訳が生じること、指図終了時に財務的な更新が行われることを説明します。自社のERPで同じタイミングになるとは仮定せず、経理担当の承認を受けて仕訳テストを作ります。Microsoftの生産転記

製造業の完成品入庫管理システムで必要なデータ項目

RFPでは「MES・WMS連携可能」とだけ書いても比較できません。最低限、以下のデータ辞書を添えてください。

すべての品目に全項目を強制する必要はありません。非ロット品、シリアル品、重量品で分岐を定義します。ただし、空欄の意味は統一します。「未取得」と「対象外」が同じ空欄だと、監査時に判別できません。また、時刻は端末のローカル表示時刻とサーバー保存時刻、タイムゾーンを区別します。タイ・日本・ベトナムの拠点を横断するなら、検索画面で日付境界を誤らないためにUTC記録と現地表示の方針を決めます。

MES・QMS・WMS・ERPの連携責任をどう分けるか

推奨する出発点は、MESを工程と完工実績の正本、QMSを検査と判定の正本、WMSを容器・場所・棚入れの正本、ERPを品目・指図・評価在庫・会計の正本と仮置きし、既存システムの機能と現場の責任に合わせて調整することです。どの製品名を採用するかより、同じ事実を二重に確定しないことが重要です。ERPが品質判定も持つ企業なら、QMSを別システムに分ける必然性はありません。小規模工場では一つのERPモジュールで複数責任を担うこともできます。

連携仕様は「完工イベント送信」「ERP在庫更新」といった抽象名だけで終わらせず、起点、宛先、受領応答、再送期限、重複検知キー、失敗時の保留画面まで書きます。例えばMESからERPへ完工イベントが届き、ERP側の転記に成功した応答が戻る前にネットワークが切れた場合、MESは失敗と誤認して再送します。ERPがイベントIDを保存せず二度転記すれば、現物は一箱でも在庫は二箱になります。したがって同じイベントIDの再送は一回目の結果を返す、という冪等の受入条件を定めます。これは特定ベンダーの標準機能を断定する話ではなく、複数システム間に必要な設計条件です。

一方、品質判定後にWMSが販売可能ロケーションへ移動しても、ERPへ合格状態が届かなければ営業在庫は増えません。逆にERPだけ先に利用可能にすると、保管場所が未確定の在庫を引き当てます。この時間差を「許容する遅延」「通知対象」「日次突合」で管理します。リアルタイム連携という単語だけでは、秒単位を要求しているのか、数分の遅延を認めるのか分かりません。

タイ工場で起こりやすい例外を先に設計する

部分完工・分割入庫

一つの指図で全数量を一度に完成させない場合、同じ指図を複数回完工できます。各回のイベントID、ロット、容器、品質状態を別に記録し、累積完工量が指図の予定量を超える場合の承認条件を決めます。日付をまたぐ生産では製造日と入庫日が異なります。週末の残業で完工し、月曜に棚入れするなら、月次締めの境界がずれることもあります。日付の定義を経理・製造・倉庫で合意し、月末の例外テストに入れます。

数量差・単位換算

生産側が「箱」、倉庫側が「個」を入力する場合、1箱の入り数と端数箱の扱いが必要です。重量品なら秤量値、許容差、風袋重量、校正の扱いを定義します。生産で100個を完工、倉庫が99個受領した例では、自動で99へ書き換えるのではなく、1個の差異を誰が調査し、どの在庫状態に置くかを決めます。差異が見つからなければ、どの伝票を訂正するのか承認履歴を残します。単位換算を画面ごとに持つと別の答えになるため、品目マスタの換算を共通に参照します。

品質保留・部分合格・再作業

同じロットの一部だけ合格した場合、合格数量と保留数量を分けて容器を再ラベルするか、ロットを分割するかを決めます。保留場所に残した現品を出荷ピック対象から外すテストが欠かせません。不適合品は原因調査後に廃棄、特採、再作業などの処置へ進む可能性があります。この処置フローはリワーク管理と接続させ、再作業後に新しい完工報告を作るか、既存報告に紐付く再検査とするかを明確にします。

ラベル不一致とオフライン端末

現物ラベルの品番・ロットとシステムの予定値が違うとき、端末が警告だけ出して先へ進めるのか、管理者の解除まで止めるのかを決めます。オフラインの倉庫端末が復帰後に同じ受領データを二度送るケースも試してください。再送の順序が逆でも、元イベントと訂正イベントを時系列に再現できるようにします。ラベルの印字不能時は手書き運用をただ許すのでなく、代替ラベル、後追い照合、保留場所を決めておきます。

取消・逆転記・月次締め

誤った完工や入庫を削除するのではなく、元伝票を参照した取消・訂正の取引にします。指図の終了後、月次締め後、すでに一部を出荷した後では取消可能範囲が異なります。ロールバック時にMES、WMS、ERPの片方だけを戻すと整合しません。取消権限と順序、後続取引がある場合のエラー、経理承認を受入試験に含めてください。

RFPでベンダーへ確認する10の質問

1. 作業完了、完工報告、品質判定、入庫確定、販売可能化を別状態で管理できるか。どの画面とAPIで確認できるか。
2. 部分完工、同一指図の複数ロット、箱・個・kgの単位換算をどう処理するか。
3. 良品、不良、再作業、保留、スクラップをどのデータ項目と伝票で区別するか。
4. 検査ロットの作成、部分合格、使用決定、出荷ピック禁止をどこで制御するか。
5. 容器ID、パレットID、ロット、シリアル、棚ロケーションをどう紐付けるか。
6. MESからの再送で在庫を二重計上しないキーと処理は何か。
7. 生産側と倉庫側の受領数量差をどの画面で調査し、誰が確定・訂正するか。
8. オフライン端末、ラベル再印刷、スキャン失敗時の代替操作と証跡はどうなるか。
9. 完工、入庫、原価計上、指図終了の転記日と会計伝票をどう照合するか。
10. 取消、指図終了、月次締め、出荷後訂正をどこまで標準機能で扱い、追加開発が必要な範囲はどこか。

各質問への回答は「可能／不可」だけでは不十分です。標準画面の操作、設定項目、APIサンプル、例外時の画面、監査ログをデモしてもらいます。異なるソフトの組み合わせでは、ベンダーの責任分界表と障害時の一次窓口まで提案書に入れてもらうと、稼働後のたらい回しを減らせます。ライセンス費だけで比較せず、ラベルプリンタ、スキャナ、ネットワーク、マスタ整備、検査計画の設定、会計テスト、教育、保守も見積り範囲を揃えてください。

FAT/SATの受入試験：正常系より境界値を重視する

工場出荷前のFATではベンダーの検証環境で連携と状態遷移を試し、現地据付後のSATでは実端末・実ラベル・実倉庫で再現します。名称や試験範囲は契約によって異なるため、RFP時点で合格条件を明記します。次の試験番号は雛形です。

上記数量も試験用の架空値です。自社の製品ではロット、シリアル、重量、複数倉庫、複数拠点の組み合わせに入れ替えてください。FATでAPIの成功応答だけを確認しても、SATの実ラベル読取や電波の弱い保管棚、プリンタ故障までは検証できません。現場で使う端末と権限を使い、夜勤担当も含めて操作を確認します。試験不合格は「回避手順があるからOK」とせず、出荷可能在庫に影響する欠陥かどうかで稼働判定をします。

導入費用と効果はどう見積もるか

このテーマに単一の市場価格を置くのは危険です。既存ERPに完工入庫機能がある場合と、MES・QMS・WMSを新規に統合する場合では範囲が違います。見積は少なくとも①業務設計、②マスタ整備、③連携開発、④端末・ラベル、⑤試験、⑥教育・切替、⑦保守に分けます。比較対象の提案でどの項目が別費用かを揃え、初年度費用と継続費用を分けてください。利用者数や倉庫数だけでなく、イベント件数、ラベル種類、オフライン範囲、会計連携の数が工数に効きます。

効果は「入庫入力時間が何分減るか」だけでなく、未判定品の誤出荷防止、棚探し時間、月末の差異調査、仕掛と完成品の会計差異、顧客への納期回答の正確さを測ります。金額換算が難しいリスクは、発生件数と封じ込め時間で管理します。PoC開始前の4週間で、完工から棚入れまでの中央値と90パーセンタイル、未解決差異件数、品質保留の誤ピック件数を採っておくと、稼働後に改善を評価できます。4週間は提案する観測期間であり、外部統計の引用ではありません。件数の少ない品目はより長く観察します。

失敗を避ける導入順序とデータ移行

初日から全品目・全ライン・全倉庫を切り替えると、状態定義の違いが一度に噴き出します。まず一つの製品群と一つの倉庫を選び、完工から入庫までの現行伝票を実際に追います。現場、品質、倉庫、経理が同じ現品についてどの時点で「完成」「合格」「入庫」と呼んでいるかを記録します。次に、目標の状態表とデータ辞書を承認し、画面やAPIの設定に進みます。この順序なら、システム画面に業務を無理に合わせて例外を紙へ戻すリスクを減らせます。

移行対象は完成品の残高だけではありません。未完了の生産指図、品質判定待ちの容器、入庫待ちの完工品、棚入れ作業中のパレット、月末に訂正予定の差異もあります。切替日に旧システムの「完成品100個」を新システムの「販売可能100個」に置き換えると、保留品が混ざる可能性があります。切替直前にロット・容器・場所・品質状態ごとの実地確認を行い、旧伝票と新取引IDの対応表を残します。完工済みで倉庫未受領の取引を旧側で締めるか新側へ引き継ぐかも一件ずつ決めます。特に日付をまたぐ夜勤では、両システムへ同じ現品を入力しない運用を明確にしてください。

並行稼働を行うなら、どちらを在庫計上の正本にするかを一つだけ選びます。両方で本番転記すると、照合のための複写が実在庫増加に見えてしまいます。試験側では「照合用・会計転記なし」として扱い、差異を日次で原因分類します。切替判定は単なる「入力件数が一致」ではなく、品質保留品の出荷不可、受領差異の未解決一覧、返品や取消の追跡、会計仕訳の再現、現場での棚探しまで確認します。障害で元の運用へ戻す条件と判断者、ロールバックできる最終時点も稼働前に決めておきます。

教育では、通常のスキャン手順より例外時の判断を重点にします。ラベルが読めない、数量が違う、保留品が混じった、端末がオフライン、指図の品番と箱の品番が違うとき、作業者がどの画面で止まり誰を呼ぶかを一枚の手順表にします。管理者だけが知っている解除コードが夜勤中に使えない、という状態を避けるため、代理承認者と連絡方法も設定します。初週は倉庫と品質の担当者が毎日未処理一覧を確認し、原因をマスタ、手順、端末、連携のいずれかに分類すると、短期の修正がしやすくなります。

稼働後の運用会議では、差異件数だけを成果指標にしないでください。差異を見つける仕組みが機能し始めると、導入直後には検出件数が一時的に増えることがあります。大切なのは、発生した差異が何時間で担当者に届き、何日で原因が確定し、同じ理由の再発が減っているかです。品質保留のスキャン拒否も「現場が間違えた回数」として罰するのでなく、危険な操作を出荷前に止めた記録として分析します。週次で発生場所と理由を確認し、品目マスタやラベル配置を直して、現場が同じエラーに繰り返し遭遇しないようにします。この改善を続けるため、管理者画面には件数だけでなく未解決期間、担当者、次の処置を表示させます。

よくある質問

完成品入庫管理システムとWMSの違いは？

WMSは倉庫内の容器、ロケーション、受領、棚入れ、ピッキングを担うことが多く、完成品入庫管理は生産指図の完工・品質判定・倉庫受領・ERP在庫までの横断取引を指します。WMS単体で全体を担えるかは製品とERP/MES構成によります。RFPでは製品名で線引きするのではなく、各イベントの正本と連携先で分けてください。

完工報告をした時点で販売可能在庫にしてよいですか？

品目に検査が不要で、倉庫受領と場所の確認も同時に完了し、自社の規定が許す場合はあり得ます。しかし検査待ち、ラベル未確定、未受領の状態がある品目では自動的に販売可能へ移さない方が安全です。SAPとMicrosoftの公式資料でも、完工後の検査や棚入れは設定次第で別の処理です。品目・工場・顧客要求ごとに条件を定めます。

部分完工や部分合格はどう扱いますか？

同じ生産指図に複数の完工イベントを許し、各イベントの数量・ロット・容器を独立して保存します。品質判定が分かれたら合格と保留を別状態にし、移動・出荷の可否をそれぞれ制御します。累計数量は指図の予定量、実績、不良、取消と突合します。単純に最後の入力で全体を上書きしないでください。

バーコードは品番だけで十分ですか？

ロット・シリアル・容器単位で品質や保管場所を追うなら、品番だけでは不足します。品目、ロットまたはシリアル、容器IDの役割を分けます。GS1識別子を使うか自社コードを使うかは、取引先要件とラベル運用、既存マスタに合わせて決めます。

既存ERPがあれば新しいソフトは不要ですか？

既存ERPに必要な状態、品質判定、容器・棚情報、端末連携、監査ログがあり、現場で使えるなら追加ソフトは不要な場合があります。画面で一回の入庫登録はできても、品質保留やネットワーク断の再送を扱えないなら拡張が必要です。まず実際の例外を使ってギャップテストを行い、標準設定で埋まる部分と追加開発を分けて判断します。

まとめ

完成品入庫の導入で守るべき軸は、作業完了、完工報告、品質判定、現物受領・棚入れ、ERPの在庫・会計更新を、同じ事実として雑にまとめないことです。各段階の数量と状態、ロット・容器、時刻、責任者をつなぎ、再送・取消・部分合格・数量差まで受入試験で確かめます。そうすれば「在庫はあるはずなのに出荷できない」「未判定品が引き当てられた」という問題を、現場の注意力だけに任せず仕組みで防げます。

タイ工場で完工報告から品質判定、倉庫入庫、ERP在庫までの流れを整理したい段階なら、現行の伝票・ラベル・システム構成を基にお問い合わせください。導入範囲やRFPの検討段階でも、どの状態をどこで確定するか一緒に整理できます。

参考資料

• Microsoft Learn: Report production orders as finished
• Microsoft Learn: Production order posting
• SAP Help: Inspection for a Goods Receipt
• SAP Help: Quality Management in Warehousing
• Oracle: Overview of Oracle Manufacturing
• ISA: ISA-95 Standard
• GS1: General Specifications