製造業で顧客支給材の受入・消費・返却管理システムを導入するとき、最初に決めるべきことは在庫画面の見た目ではありません。顧客が所有する材料を自社工場が預かり、どの受注・製造指図に何個使い、不良や残材をどう返したかを、両社が同じ証拠で照合できることです。タイ工場の生産管理、倉庫、品質、経理、ITの担当者向けに、データ設計、現場操作、RFP、受入試験まで整理します。
結論：顧客支給材は「顧客別在庫」だけでは管理できない
顧客支給材には、少なくとも所有者、実際の保管者、支給元の参照番号、材料品番とロット、預かった数量、使用可能状態、充当先の注文・製造指図、消費数量、不良・損傷・廃棄数量、返却数量を持たせます。帳簿上は同じ材料が100個あっても、自社購入材50個と顧客Aの支給材50個を合算して「使える100個」と表示すれば、誤使用の原因になります。同じ顧客の材料でも、注文A専用のロットを注文Bに回してよいとは限りません。
設計の中心は、物が動いた出来事と、所有権・費用・顧客への報告に影響する出来事を分けることです。受入、検査保留、保管場所移動、ラインへの払出、実消費、不良発生、良品の戻入、顧客への返却をそれぞれ別のイベントとして記録します。移動だけで消費とみなさず、顧客に返すべき残高を製造指図とロットごとに再計算できる状態にします。
SAPの公式資料は、外部所有の特別在庫が自社拠点に保管される場合を扱い、所有者や在庫種別を区別しています。Oracleの受託製造フロー資料では、委託元が供給した部品の消費と製造進捗を受託先が報告し、委託元側でも記録する流れが示されています。これらは各製品の実装例です。自社の契約、会計、税務上の扱いまで自動的に決める規則ではありません。システム導入時には契約書と経理方針を確認し、処理点を合意してください。
まず対象を定義する：支給、預かり、委託在庫の違い
「支給材」は現場で幅広く使われます。顧客が自社の部品を無償で渡し加工だけを発注する場合、一定数量を預けて使用分だけ精算する場合、顧客指定の購買品を加工会社が代わりに購入する場合では、所有権と請求の境界が異なります。RFPの最初のページに、今回扱う契約類型を記します。本稿は、顧客が材料を所有し、受託工場が現物を受け取って製造に使うケースを主対象にします。材料を有償で買い取る契約や、原価を相殺する取引は別の設計が必要です。
所有者と保管者を一つの「仕入先」欄に押し込めないでください。顧客が所有者で、工場の倉庫が保管者、ラインが一時保管場所という状態は自然に発生します。SAPの在庫転記資料も所有者を在庫の区分属性として示しています。ただし「所有者」だけでは使用権限を決められません。支給契約、顧客注文、品番版数、ロット制限、有効期限、品質判定を併せて引当可能性を判定します。
通常の受入と記録時点の整理には入出庫管理システムの記録タイミング設計が役立ちます。本稿ではさらに、他社所有材を預かることに伴う顧客別残高、支給元証憑、使用承認、返却、顧客との月次照合を掘り下げます。より広いシステム選定手順はタイ工場の在庫管理システム導入ガイドを参照してください。
受入前に顧客と合意する七つの項目
契約と業務手順で、①所有権が移るか、②不足・破損の責任境界、③代替材の使用可否、④余剰材の返却期限、⑤不良・端材・サンプルの扱い、⑥棚卸しと照合の頻度、⑦報告書の単位と承認者を確認します。品番の呼称が顧客と工場で異なる場合は対応表を作り、版数と適用開始日を管理します。後から「返すべき端材だった」「破損品も報告対象だった」と分かると、スキャン履歴があっても精算はできません。
受入イベントを支給通知と現物に結び付ける
顧客から届く支給通知、配送伝票、ASNなどを受入予定の正本候補にします。通知番号、注文番号、顧客品番、自社品番、ロット、数量、単位、容器数、期待到着日を照合します。ただし通知の数量をそのまま入庫確定数にしてはいけません。受入時には現物ラベルを読み、実数と状態を記録し、過不足、破損、ラベル不明を別の例外に分けます。写真を添付する運用なら、撮影者、時刻、対象容器IDが追えるようにします。
ラベルの識別子は「ロット」だけで十分とは限りません。同一ロットを複数の箱に分け、別の日に受け取るなら、箱・パレット単位の一意なIDが必要です。分割と統合を行ったときは旧容器と新容器の親子関係を残します。GS1のGlobal Traceability Standardは、受入や変換などの重要な追跡イベントと、それぞれを説明するデータ要素を整理しています。GS1 EPCISは何を、いつ、どこで、なぜ扱ったかというイベントの枠組みです。GS1識別子やEPCIS採用が必須という意味ではありませんが、顧客とデータ交換する際の設計参考になります。
受入後すぐに使用可能にするかは品質側の判断です。検査待ち、合格、保留、返品待ちを在庫状態で分け、検査待ちの品を誤って引当しない制御を入れます。顧客が検査成績書を送る場合でも、自社で現物の数量と梱包状態を確認する手順は残します。サンプル抜き取りで消費した数量も、単なる在庫差異ではなくサンプル採取イベントとして記録します。
「払出」と「実消費」を別の取引にする
倉庫からラインに30個渡した時点で、30個すべてが製品に組み込まれたわけではありません。ラインで20個使用し、2個を不良として隔離し、8個を未使用で戻すことがあります。Oracle NetSuiteの公式資料は、製造指図への部品払出を材料消費の記録として説明していますが、どの業務時点を消費とするかはシステム設定や運用で異なります。自社のRFPでは「払出」という語だけに頼らず、倉庫位置の減少、ライン位置の増加、原価・顧客残高への反映をイベントごとに書き分けます。
通常の在庫移動なら、倉庫からラインへ30個移したとき、工場内の預かり総量は30個減りません。実消費20個を製造指図と顧客注文に結び付けたとき、未使用残高を20個減らします。不良2個は「製品に使った」のか「加工中に破損した」のかにより、顧客への報告と費用負担が変わります。戻入8個は再使用可能な状態か、開封により品質保留が必要かを判定します。
自動バックフラッシュを使う場合は、完成品の良品数とBOMから理論消費を算出します。ただし端数、歩留まり、材料の取り違え、試作、段取り中の使用、再加工があると理論値と実績値はずれます。理論値を黙って確定値にしないことが大切です。品目別に許容差を設け、差異が出たときは作業者が理由と実数量を入力し、必要なら承認を経て確定するようにします。製造実績と材料消費を同じ端末から入力する場合も、それぞれ独立した訂正履歴を残します。
所有者・注文・ロット・容器の四軸で残高を持つ
最低限の残高キーは、所有者、材料品番、ロット、場所、品質状態です。注文専用の支給材なら注文・製造指図も加えます。容器ごとの数量とラベルを管理する場合は容器IDを加えます。画面に出す「総在庫」だけでなく、引当可能残高、ライン渡し済み、検査保留、返品待ち、顧客返却済みを区分します。顧客Aのロットを顧客Bの指図にスキャンしたとき、単なる警告にするか入力を止めるかは契約とリスクに合わせて決めます。
見かけ上の同一品番は危険です。顧客品番は同じでも仕様版数が変わることがあり、包装単位が箱と個で混在することもあります。品目マスタには顧客品番、自社品番、版数、基本単位、換算率、有効期間を記録し、変換時は元の単位と数量も履歴に保存します。1箱を「100個」と換算するなら、開封後に97個となった箱を再スキャンしたとき旧換算値で上書きしないようにします。計量材なら総重量、風袋、正味重量、計量機ID、校正状態も必要です。
注文間の移し替えは通常の棚移動ではありません。顧客の使用許可、管理者承認、元注文と先注文、対象ロット、数量、時刻を残す「注文間振替」として扱います。品番が同じだから使ってよいという判断を端末に委ねないことです。注文変更で仕掛途中の材料が残ったら、ラインにあるもの、未開封のもの、半端容器を分けて処理します。
残高照合の式をイベント表から再現する
月末に顧客と数字が合わないのは、在庫差異だけが原因ではありません。計上日、単位、注文の締め日、不良や端材の定義、返却中の所在が異なると、両社が正しい処理をしていても報告値がずれます。まず「預かり残高」と「返却義務残高」を定義し、集計単位を顧客、支給通知、注文、品番、ロットに分けます。下記の式は業務設計用の例です。契約上の精算式とは別途照合してください。
工場内の預かり残高 = 前期繰越 + 当期実受入 − 実消費 − 顧客返却 − 承認済み廃棄 ± 承認済み訂正。 受入済みだが検査中の材も工場内には存在します。輸送中返却材をいつ残高から外すかは、顧客と合意した受渡点で決めます。未使用材のライン戻入は場所の移動なので、工場内総残高には加減しません。製造指図別の割当残高では、引当と解除を別に集計します。
以下は説明用の仮想例です。顧客AからロットLを100個受け取り、注文Pに60個、注文Qに30個を引き当て、10個を未引当とします。Pのラインへ50個移し、実消費40個、破損2個、未使用8個を倉庫へ戻しました。Qで20個を実消費し、顧客へ未使用10個を返却したとします。破損2個を顧客へ現物返却するのか、承認済み廃棄として計上するのかが未確定なら、残高を確定できません。画面は一時的に「破損保留2個」を示し、承認後に返却または廃棄へ振り替えます。20個と40個だけを消費、10個を返却済みとした時点の工場内残高は30個です。これは契約や実績を示す数字ではありません。
| イベント | 物理場所 | 工場内預かり総量 | 顧客報告で必要な記録 |
|---|---|---|---|
| 実受入 | 入荷場・検査待ち | 増加 | 支給通知、実数、ロット、容器、差異 |
| 倉庫からラインへ移動 | 倉庫→ライン | 変わらない | 元・先場所、指図、担当者 |
| 実消費 | ライン→製品・工程 | 減少 | 指図、完成品ロット、実数量、時刻 |
| 破損・スクラップ保留 | 隔離場所 | まだ確定しない | 理由、写真、責任、承認待ち |
| 未使用材の戻入 | ライン→倉庫・保留 | 変わらない | 元の払出ID、品質判定 |
| 顧客への返却 | 返却場→顧客 | 合意した受渡点で減少 | 返却承認、出荷・受領証憑 |
不良、端材、試作、代替材を先に決める
不良品や端材を「消費」にまとめると歩留まりはきれいに見えますが、顧客に説明できません。破損原因が支給前、保管中、加工中のどこにあるか、誰が判定し、誰が負担するかを記録します。廃棄とするなら顧客の承認要否、証拠写真、廃棄証明、引取業者の記録を契約で決めます。返すなら不良材のラベルと良品材の棚を分けます。スクラップ量をkg、支給量を個数で持つ場合は換算根拠も必要です。
試作、初品、検査サンプルは量産の消費から分けます。顧客が別枠で供給した材を量産指図へ充当するなら、承認付きの振替が必要です。代替材はさらに危険です。型番が似ていても、顧客図面と承認工程が違えば勝手に置き換えられません。端末では代替候補を自動表示する前に、承認番号と有効期間を照合します。材料不足のときに「在庫あり」と誤表示しないため、可用数量の計算から未承認代替、検査保留、返却待ちを除外します。
顧客から「同じロットを複数注文に使ってよい」と連絡が来ても、口頭やメール一通だけでマスタを恒久変更するべきではありません。どの注文間で、どの数量まで、いつまで有効かを承認記録にします。後から顧客監査で理由を説明できることが、操作の速さと同じくらい重要です。
作業途中で生じる数量差を誰が確定するか
製造途中で材料が不足したとき、倉庫は「渡した数」を、製造は「使った数」を、品質は「不良と判定した数」を、顧客は「支給した数」をそれぞれ正しく記録している場合があります。それでも四つの数字を直接比較すれば一致しません。受入予定、実受入、ラインへの移動、実消費、検査サンプル、不良保留、返却済みのどの時点を比較しているかを、同じ画面と報告書で確認できるようにします。差異を見つけた担当者が、ただちに数量修正をするのではなく、欠けているイベントを探せることが大切です。
たとえばラインが支給材の小袋を開封した後、設備停止で製造が翌日に延期されたとします。倉庫の「出庫」は正しく、MESの「消費なし」も正しい状態です。小袋を戻すときに使用可能在庫へ自動的に加算すると、開封後の品質判定を飛ばしてしまいます。戻入は元の払出にひも付け、開封状態と保管条件を記録し、品質担当が再使用可否を判定します。担当者がいない夜勤なら保留のままにし、次のシフトが引き継げる一覧を用意します。
数量差の承認権限も原因で分けます。単純な数え直しによる受入訂正、材料の付着や歩留まりによる工程差異、破損による廃棄、顧客へ請求する損耗は同じ「調整」ではありません。前者は倉庫責任者、工程差異は製造と品質、契約上の負担が変わる処理は顧客窓口と経理を含める、といった承認経路を決めます。管理者がすべてを一括承認できる設計は導入時には速く見えても、後で誰が何を判断したか分からなくなります。
逆引きできる状態を検収基準に入れる
「この完成品ロットにどの顧客支給材ロットが入ったか」という前方・後方の追跡だけでは十分ではありません。「この支給通知で届いた材料のうち、まだ工場にあるもの、製品に使ったもの、破損保留のもの、顧客へ返したもの」を一画面または一報告書で答えられることも必要です。材料を容器分割し、二つの製造指図へ渡し、一部を戻してから再度別指図へ使った場合でも、元の支給通知まで辿れるかを試験します。ここが途切れると、顧客との残高差異が出るたびに担当者が紙伝票を探すことになります。
追跡結果には「物理的な場所」と「帳簿上の状態」を並べます。たとえば返却承認済みの容器がまだ工場の返却置場にある場合、物理的には工場内、業務状態は返却待ちです。逆に発送済みでも顧客が受領していないなら、輸送中として表示します。契約上の受渡点を境に残高を減らす設計なら、発送と受領のどちらを採用したかが履歴から分かるようにします。この二軸の表示があれば、倉庫と経理が同じ「在庫」という言葉で違う数字を話す混乱を減らせます。
顧客から支給通知の取消や数量変更が来た場合も、受入済みの現物を帳簿から消してはいけません。通知の版数と適用時刻を残し、まだ入荷していない予定数量だけを変更するのか、既に受け取った現物を返却対象へ振り替えるのかを分けます。注文自体が取り消された場合は、引当済みの箱を無条件に他注文へ開放せず、ラインにあるものと倉庫にあるものを洗い出し、品質状態と顧客の指示を確認します。受入予定と実受入の差を「通知を直せば消える」と扱うと、納品時に不足していた事実が失われます。
複数顧客の支給材を同じ棚に置く工場では、画面上の区分に加え、棚札や容器ラベル、保留エリアの物理的な見分け方も決めます。システムが正しく誤使用を止めても、作業者が間違った容器をラインまで運べば、引き返す作業と納期遅延が発生します。ピッキング指示に所有者と注文を表示し、棚と容器の識別子を二段階で読み合わせると、誤りを工程投入の前に検知できます。混載が避けられない場所では、同一品番でも所有者が違う容器を隣接配置しないなど、現場の配置ルールを併用します。
経理が月次締めをした後で、現場から前月の使用実績が届くこともあります。そのとき過去のイベントを上書きすると、既に顧客へ送った残高表とシステムの履歴が一致しなくなります。発生時刻と計上時刻を分け、締め後訂正として元イベントに紐付けてください。顧客へ訂正版を出すか翌月調整にするかは契約で決めます。どちらを選んでも、最初に送った報告書、差異発見日、修正承認者、再送した版を保存すれば、後の問い合わせに対して経緯を説明できます。
権限は「画面を開ける人」と「数量を確定できる人」を分けます。倉庫担当者は現物の受入と場所移動を記録し、品質担当者は使用可否を判定し、製造担当者は指図に対する実消費を入力し、顧客窓口は返却条件を確認する、という役割を基本にします。小規模工場で一人が複数の役割を兼ねることはありますが、同じ人が差異を起票して自分で承認できるかは、金額と顧客との契約条件に応じて制限します。代行承認が必要な場合は、代行者、理由、期間を残します。
また、顧客別残高を外部へ送る前に、未承認の破損、未同期の端末取引、返却中の箱、月末日付の訂正を一覧で確認できるようにします。報告書の作成ボタンが押せることと、その数字を顧客へ確定報告できることは別です。締めの担当者が未解決件数を確認し、必要なら注記を付け、承認後の版だけを送ります。月次報告を後から再生成して数字が変わった場合、どのイベントが追加されたのか差分を示せるようにしておくと、双方の担当者が短時間で原因を特定できます。
ERP・MES・WMSの境界と正本を決める
ERPには顧客、受注、契約、品目、会計上の処理を置くことが多く、WMSには入庫、棚、容器、移動、出荷という現場の位置情報を置き、MESには製造指図、工程、投入ロット、良否、実消費を置くことが多いでしょう。ただし製品名だけで責任境界は決まりません。すでにERPの在庫機能でロットと場所を管理している工場もあります。RFPでは「どのシステムがどのイベントの正本か」を一件ずつ指定します。
たとえば支給通知はERP、現物受入と容器IDはWMS、検査判定はQMS、製造指図と実消費はMES、顧客別残高報告はERPが正本、という組み合わせです。この場合、WMSの受入確定は一回だけERPへ送られ、ERPが返した伝票番号をWMSに保存します。MESの実消費をWMSとERPの両方へ独立に送るなら、どちらが先に失敗しても再送できるようイベントIDで冪等化します。二重送信した結果、顧客残高が二回減る設計は受入れません。
取引の正本と表示用のコピーを区別します。ライン端末に「残り30個」と表示するためにERPの残高をコピーしても、端末が独自に残高を修正できるなら二つの正本が生まれます。データ連携には、送信元、イベントID、発生時刻、登録時刻、元取引ID、版数、単位、数量、エラーコード、再送回数、最後の確認応答を残します。更新順が逆転したとき、元の受入が未到着なのに返却が先に来たとき、誰がどう保留を解消するかも仕様に書きます。
一つのイベントで二つの残高を変えない
受入時にWMSとERPが両方「在庫を増やす」と表現しても、それぞれの在庫台帳の役割が異なれば問題はありません。問題は同じ台帳への二重計上です。スキャンの再タップ、通信タイムアウト後の再送、バッチの再実行で同じイベントが届いても、イベントIDに対する処理結果を再返却し、数量を再加算しない仕組みを要求します。顧客支給材では数量差がそのまま顧客への説明責任になるため、技術的な重複防止は業務統制の一部です。
現場の画面は「人が判断する例外」から設計する
正常系のデモは、支給通知どおりの箱を一回スキャンして終わります。現場では、ラベルが読めない、箱が二つに分かれている、顧客品番と工場品番が違う、入荷伝票がまだない、箱の中身が不足している、といった例外が起きます。各例外で作業を止めるのか、仮受入して隔離するのか、誰に通知するのかを決めます。エラーを隠して受入確定する操作は、後の月次照合を難しくします。
スキャン画面は、容器IDを読めば所有者、支給通知、ロット、予定数量、品質状態、使用可能な注文をすぐ表示する構成がよいでしょう。入力は必要最小限にし、数量の手修正、ラベル再発行、注文間振替、廃棄確定などリスクの高い操作にだけ権限と理由入力を要求します。手袋をした作業者が狭い入荷場やラインで使うなら、画面サイズ、反射、Wi-Fiの切替、スキャナーの読み取り距離までSATで確認します。
ネットワーク断では、端末が未送信イベントを保持できるか、それとも受入や消費を一時停止するかを品目リスク別に決めます。オフラインで複数端末が同じ容器を更新すると衝突するため、「オフラインでも全部できる」と無条件に約束しないことです。再接続後には端末時刻とサーバー登録時刻を両方残し、競合イベントを自動上書きせず確認待ちにします。紙の緊急運用を残す場合も、誰がいつどのIDで事後登録し、二重登録をどう検出するかを訓練します。
顧客との月次照合と返却業務を閉じる
返却の開始点は「倉庫に戻った」ではありません。返却候補の抽出、品質と数量の確認、顧客の返却承認、荷姿・ラベル、出荷、輸送、顧客受領の段階を分けます。返却予定の箱を通常の引当可能在庫に戻すと、翌日の別指図で使ってしまうことがあります。返却ロックをかけ、解除には理由と権限を必要とします。複数の元受入から一つの返却パレットを作る場合は、親パレットから元容器・ロット・支給通知へ逆引きできるようにします。
月次報告には、期首、受入、消費、承認済み廃棄、返却、期末を顧客・品番・ロット・注文別に示します。数字の根拠となるイベント一覧へドリルダウンできること、報告書の版数と承認日を残すことが重要です。顧客の台帳との差異があれば、数量だけを合わせる調整伝票を先に切らず、支給通知の未受領、ロットの読み替え、月末跨ぎ、単位換算、破損処理、返却輸送中を順に調べます。訂正が必要なら元イベントと訂正イベントを結び、過去の履歴を消さない設計にします。
顧客がExcelで残高表を送るなら、最初の段階ではCSV交換でも構いません。ただし列の定義と時点を固定しないと、毎月の手作業照合が残ります。顧客側の項目をそのまま自社マスタに混ぜるのではなく、変換表、例外一覧、照合結果、承認の履歴を持たせます。将来APIやEDIへ切り替えても、同じイベントIDと支給通知参照を維持できれば、業務の再設計を抑えられます。
導入前に用意するデータと役割分担
最初の調査では、実際の一か月分から代表的な支給通知、入荷伝票、容器ラベル、製造指図、良否実績、返却伝票、顧客との残高表を集めます。机上の理想フローだけでは、注文変更や部分返却の処理が漏れます。データの所有者を顧客窓口、倉庫、製造、品質、経理、ITごとに決め、同じ項目が複数帳票にある場合はどれが正本か確認します。
| データ・規則 | 主な確認点 | 決定する担当 |
|---|---|---|
| 顧客・契約 | 所有権、損耗、返却、請求の境界 | 営業・経理・顧客窓口 |
| 支給通知 | 参照番号、品番、ロット、予定数、取消 | 顧客窓口・倉庫 |
| 品目と単位 | 顧客品番、自社品番、版数、換算、代替 | 技術・生産管理 |
| 容器と場所 | 一意ID、分割統合、保留場所 | 倉庫・品質 |
| 製造指図 | 注文との紐付け、BOM、工程、変更 | 生産管理・製造 |
| 消費・不良 | 実数量、理由、責任、承認、訂正 | 製造・品質・経理 |
| 返却・照合 | 出荷点、受領証憑、締め日、報告単位 | 倉庫・顧客窓口・経理 |
既存データの品質も計測します。顧客品番と自社品番の対応が一対一でない件数、ロット欠損率、単位換算が不明な件数、注文番号を持たない消費実績、返却伝票から元受入へ遡れない件数を数えます。導入時に全履歴を完全移行する必要があるとは限りません。まず切替時点の顧客別・ロット別現物を棚卸しし、期首残高として顧客と承認する方法もあります。ただし期首残高の根拠と旧帳票の保存先を残します。
RFPでは操作、帳票、統制、連携を一組で要求する
「支給材管理に対応」とだけ書いた提案依頼では、候補製品の比較ができません。ベンダーへ渡すサンプルは、顧客二社、同一品番の自社材と支給材、同一ロットの分割容器、二つの注文、部分消費、不良、戻入、返却、月末跨ぎを含めます。全件を匿名化し、数量は説明用の仮想値であることを明記します。ベンダーには、画面の実演だけでなく、各イベント後の台帳と出力CSVを提出してもらいます。
機能要件には、所有者・注文を含む在庫区分、容器ID、ロット、品質保留、代替承認、注文間振替、未使用戻入、破損処理、返却承認、顧客別残高、履歴検索を入れます。連携要件には、ERP/MES/WMS/QMSの正本、APIまたはCSVの方向、頻度、失敗時の再送、重複防止、時刻と単位を入れます。非機能要件には、オフライン時の動作、権限、監査ログ、バックアップ、保守体制、言語表示、データエクスポートを入れます。
費用比較はライセンスだけでなく、スキャナー、ラベルプリンタ、Wi-Fi、既存ERP改修、マスタ清掃、データ移行、教育、保守、顧客ごとの帳票差分を分けます。顧客の契約条件が複数ある場合、将来の顧客追加を設定だけで行えるか、その都度改修が要るかを質問します。経済効果は「全工場で必ず何％削減」と断定せず、現状の照合時間、差異件数、誤使用件数、返却遅延日数を測ってから試算します。
PoCとFAT/SATで何を合格とするか
PoCは最も単純な一箱だけで行わず、顧客支給材特有の例外を入れます。候補システムへ、支給通知100個、実受入98個、二容器への分割、うち一容器の検査保留、注文Pへの部分引当、ラインへの払出、実消費、破損、戻入、返却を順に投入します。これは仮想テストデータで、実際の業績ではありません。各段階で、所有者、場所、使用可能数、指図別残高、顧客向け残高が期待値と一致するかを比較します。
FATではベンダー環境で取引と連携を再現し、SATではタイ工場の実際の棚、ラベル、端末、無線、シフト、現場作業者で検査します。成功条件は「スキャンができた」ではなく、「不適切な注文への使用を止め、許可された消費だけが一度計上され、返却と顧客残高まで追える」です。通信断、再タップ、バーコード破損、月末締め後の訂正、同時作業も含めます。
| 試験ケース | FATで確認する証拠 | SATで追加する条件 | 合格条件 |
|---|---|---|---|
| 他顧客材の誤スキャン | 所有者・注文の不一致警告と拒否ログ | 実容器ラベルを使用 | 誤消費ゼロ、理由が残る |
| 数量不足の受入 | 予定数と実数の差異、保留処理 | 入荷場で箱を再計数 | 差異を消さず顧客へ報告できる |
| 部分消費と戻入 | 指図、ロット、元払出ID | 開封容器と品質判定 | 総残高と場所別残高が一致 |
| 破損・スクラップ | 保留、承認、廃棄または返却 | 物理隔離場所と写真 | 未承認数を勝手に消さない |
| 再送と二重スキャン | 同一イベントIDの再実行 | Wi-Fi切替と端末再起動 | 一回だけ計上、未送信を検知 |
| 月末照合と訂正 | 顧客別・注文別の式と明細 | 実際の帳票形式 | 双方の差異を追跡し承認できる |
受入判定では、残高の一致だけでなく、差異の理由と訂正権限、現場が同じ手順で再現できるかを見ます。顧客Aに属する在庫を顧客Bの注文に使用できてしまう欠陥や、再送で二重消費される欠陥は、稼働後の運用手順だけでは補えません。修正して再試験します。顧客ごとの月次照合に担当者が必要なら、その担当者もSATに参加させ、実際に出せる帳票で確認します。
段階導入は一顧客・一材料群から始める
全顧客の全支給材を同時に切り替えると、契約差、ラベル差、注文の持ち方の違いが重なります。まず支給量が多いか差異の影響が大きい一顧客、代表的な一材料群、一倉庫・一工程を選びます。ただし試験範囲には受入から返却・照合までの端から端を含めます。受入だけをデジタル化して消費と返却をExcelに残すと、最も知りたい残高が依然として確定しません。
移行日は、旧台帳の締め、実地棚卸し、顧客承認済み期首、端末ラベルの貼り替え、未完了指図の扱いを一つの切替計画にします。並行運用の期間を決め、二つの台帳に入力するなら入力順と照合担当を明示します。月末をまたぐ案件、まだ顧客受領が確認できない返却、品質保留中の容器は、通常在庫へ混ぜず移行例外リストで追います。
稼働後は、顧客別照合差異件数、未解消の保留数量、消費未登録のライン在庫、返却承認から発送までの時間、誤スキャン拒否件数を定期的に見ます。初期に拒否件数が増えることは、以前見えなかった誤使用候補を検知した結果かもしれません。数字の上下だけで判断せず、原因別に作業手順とマスタを改善します。顧客との会議で使う報告書が、現場イベントから再現可能であることを最終的な運用目標にします。
FAQ：顧客支給材の受入・消費・返却管理システム
Q1. 自社購入材と顧客支給材を同じ在庫システムで管理できますか？
できます。ただし所有者、使用可能な注文、評価・会計上の扱い、返却義務を区別できることが条件です。同じ品番・ロットでも在庫区分を合算して引当しない設計を試験してください。既存ERPに必要な区分があるなら、その機能を使う選択肢もあります。
Q2. 顧客支給材は受入時点で原価に入れますか？
一律には決められません。顧客が所有したままの無償支給か、有償譲渡か、加工賃と相殺するかで会計処理が異なります。システムは契約と経理方針で決めた処理を実行し、数量と証憑を残す役割です。経理担当と必要に応じ専門家の確認を得てください。
Q3. バーコードがあればロットトレースは完成しますか？
ラベルは識別の入口です。受入容器、工程投入、完成品ロット、破損、返却をイベントで結び付けなければ、コードを読み取っても履歴はつながりません。分割・統合と手入力訂正も試験します。
Q4. 導入費用はどのくらいですか？
顧客数、契約ルール、既存ERP/MES/WMS、容器ラベル、スキャナー台数、顧客向け帳票、連携方式で大きく変わります。総額を先に断定せず、対象フローと例外をRFPに固定し、初期費・運用費・顧客追加費を分けて比較します。
Q5. 既存の外注加工支給材管理と何が違いますか？
外注加工で自社が材料を協力会社へ出す場合は、自社が支給元です。本稿の主対象は、自社工場が顧客所有の材料を受け取る側です。鏡像に見えても、顧客から受け取る通知、預かり残高、使用承認、返却証憑、月次照合の責任者が変わります。既存の外注精算フローをそのまま反転させず、受託側の現場イベントを確認します。
まとめ
顧客支給材管理の導入は、顧客別の在庫欄を追加する作業ではなく、他社所有材の受入から実消費、破損、未使用戻入、返却までを、注文とロットに結び付けて説明できるようにする仕事です。最初に契約と正本を決め、現場の例外を含むイベント表と残高式を作り、RFPとFAT/SATで確かめてください。顧客と工場の双方が同じ取引履歴に基づいて残高を確認できれば、月末の調整だけに頼らない運用へ進めます。
タイ工場で顧客支給材の受入、実消費、返却、顧客別照合のどこから整えるか検討中なら、既存のERP・MES・WMSと帳票を前提にTOMAS TECHへご相談ください。要件を整理する段階でも対応できます。
