製造業の余剰部材返却管理システム導入｜指図残を安全に倉庫へ戻す

製造業で余剰部材返却管理システムを導入するとき、現場から倉庫へ箱を運ぶだけでは在庫は戻らない。製造指図に払出済みの未使用材について、誰が返却を申請し、現品の品番・ロット・数量・状態を誰が確かめ、品質保留をどう判断し、どの棚に置き、ERP/MES/WMSへどの順で記録するかを一つの業務として設計する必要がある。ここを曖昧にすると、現品だけ戻って帳簿に残らない、あるいは帳簿だけ先に戻って使用不可の材が再引当に使われる。本稿はタイ工場の離散製造を想定し、RFPからFAT/SATまでの具体的な導入条件を整理する。

余剰部材返却とは何か：対象と境界を最初に固定する

本稿の対象は、製造指図のために倉庫からラインへ払出したが、指図の生産・段取り替え・中止の後で使わずに残った原材料や購入部品である。未開封の箱、開封して一部を使用したリール、切断後の残材などは外見が似ても、再使用の判定条件が違う。返却要求は指図、工程、払い出し取引、品目、元ロット、元の保管区分と結ぶ。どの部材が「余った」かという現場の口頭説明だけでは、次の指図に利用できる数量は決まらない。

顧客から戻る完成品の返品は顧客・出荷・保証の取引であり、仕入先への返品は購買・買掛・契約の取引である。一般的な過剰在庫の圧縮は需要と調達の判断で、キッティングは生産前の部材準備、払出しは倉庫からラインへの前進移動を扱う。ここではその後段、つまり払出済みの未使用材をラインから倉庫へ戻すことだけを扱う。この境界をRFPに書かないと、提案された「返品管理」機能が顧客返品用だったというすれ違いが起きる。

Microsoft Dynamics 365の公開資料では、製造指図のReleased状態が現場実行と倉庫プロセスの起点であり、引当済み材料のピッキング作業が生成される。BOM・配合行の倉庫リリースは、製造投入場所に材料があるかを見て、必要なら倉庫から投入場所へ動かす。これは前方向の流れの説明であって、残材を品質判定して棚へ戻す手順を自動的に保証するものではない。したがって返却業務は、既存の払出し設定に付随する例外ではなく、別の状態遷移として設計する。

部品在庫と製造指図を含む在庫管理システム比較は対象システムの選び方を扱う。本稿はその中でもラインから戻る現品の照合に絞る。また、仕掛品管理の実務は工程途中の半製品の数量と滞留を扱う。未使用部材の返却を仕掛品の完成・移動と混ぜないことが、双方の残高を守る。

返却の失敗は「数量差異」だけではない

典型的な失敗は、現品は返ったのにERPでは指図に消費されたままになることだ。逆に、先にシステムで返品取引を立て、現品がまだラインの台車に残る場合もある。後者で在庫が再引当に見えると、倉庫は存在しない棚在庫を探し、次の指図が止まる。返却の成否は、品目・数量・場所に加え、ロットの同一性、再使用可否、取引の時点を見なければ分からない。

開封済みの電子部品リールでは湿度管理や開封時刻が問題になる場合がある。金属材は切断後の長さ、端面、錆、異物、保管容器が変わる。樹脂や化学材料では有効期限、再封止、配合や混合の履歴が効く。再使用の判断は材種・顧客要求・品質規格で異なるため、「余ったものは戻して次回使う」という一律のルールは危険である。返却登録と利用可能在庫への昇格の間に、必要なら品質保留を置く。

工場内の帳簿では返却が指図原価の減額、原材料在庫の増加、ロット残高の更新に影響しうる。ただし会計仕訳や原価処理はERP設定と企業の会計方針による。現場システムで勝手に負の払出しを作る設計を採用せず、対象ERPの正規の「Return」取引と仕訳結果を会計担当と確認する。Oracle Fusion Cloud Manufacturingの製造向け資料は、指図・工程に対するIssueとReturnを別のmaterial transactionとして説明している。導入時は採用するERPの版・設定で同じ意味になるかを実機で確かめる。

返却フローを七つの状態で定義する

第一は「返却候補」である。現場で指図終了または工程変更が起き、未使用材が特定される。第二は「返却申請」。担当者が指図・払出し元・品番・ロット・容器・申告数量・開封状態を記録し、搬送容器に一意の返却IDを貼る。第三は「受入待ち」。まだ倉庫在庫に足さず、ラインまたは受け渡し場所の管理下とする。第四は「現品照合」。倉庫担当がバーコードまたはラベルと実物を読み、重量・個数・残長など品目に合う単位で測る。第五は「品質保留または使用可判定」。規定外の開封、傷、期限、混載、ラベル欠落は隔離する。第六は「棚入れ」。承認された保管区分・棚番に物理移動する。第七は「計上完了」。ERPの返却取引とWMSの場所更新を、対応する返却IDで照合して閉じる。

この順序はシステムの書込順を常に一つに固定するという意味ではない。ERPへ返却取引を登録した時点で在庫が即時利用可能になる製品もあれば、品質ステータスや倉庫ロケーションで引当可否を制御できる製品もある。RFPには「現品未到着」「品質未承認」「棚入れ未完了」の各段階で、利用可能数量と保留数量が各システムにどう見えるべきかを書く。結果として、業務上の公開時点と技術上の書込順を両立させる。

「誰が最後に押すか」も状態ごとに分ける。申請者が自分の申告量をそのまま承認できる設定では、差異が見逃される。すべての少量返却に品質管理者の承認を要求すれば現場が滞る。材種、開封有無、差異率、ロット管理区分、顧客指定などの条件で自動通過と人の承認を分け、権限表に落とす。夜勤と休日の代行者も決める。

現品ロット、数量、状態をどう照合するか

返却IDは事務書類の番号ではなく、現品容器とシステムイベントを結ぶ鍵である。一つの返却容器に異なるロットを混ぜるなら、ロット別の明細行と現物区画を必須にする。混在禁止の品目では容器そのものを分ける。申請画面に「前に使ったロット」を自動表示しても、現品ラベルのスキャンと照合を省かない。元の払出しが間違っていた可能性もある。

数量は単位を明確にする。「1箱」を数量として登録しても、箱内にいくつ残っているかは分からない。購入単位と払出し単位、在庫基本単位、重量や長さによる実測単位の換算表を版付きで維持する。開封後に部分数量を返す場合は、実測の方法と誤差、丸め、最低返却単位を定める。重量換算の係数がロットごとに変わる材料なら、品目マスタの固定係数だけで換算しない。Oracleの製造向け資料は二重単位の材料取引にも触れているが、どの品目で使えるかは実装設定で決める。

数量照合には少なくとも三つの上限がある。申告量は現品実測量を超えないこと、指図からの正味払出し残を超えないこと、同じロット・容器について既に返却済みの数量を重複して含まないことである。ただし、追加払出し、工程間の材料移動、代替材、スクラップ、棚卸調整があると単純な「払出量−消費量」だけでは残量を決められない。RFPには、それぞれをどの取引に含め、どの例外なら承認者が補正できるかを明記する。

状態検査は品目群ごとのチェックリストにする。未開封・開封済み、元包装の有無、ロットラベルの読取、傷・汚れ・錆、期限、温湿度暴露、異物混入、数量の測定方法、写真を最低限検討する。全品目に写真を義務づけると撮影負荷が増え、写真のないときだけ高リスクになる。撮影が必要な材種と判定理由を決める。写真だけで「再使用可能」を断定せず、検査基準と責任者を別に持つ。

ラベル不明品を推測で元ロットに戻さない。ロット不明・品番不明・混載・開封時刻不明をそれぞれ別の例外コードにする。再ラベルは品質と在庫の承認記録が残る場合に限定する。許容できない場合は廃棄、再検査、別用途、仕入先相談などの処置へ分岐し、棚に置いたまま「後で調べる」を常態化させない。

品質保留と利用可能在庫を分ける

倉庫へ運ばれた時点で「戻った在庫」と見ると、品質判定前に次の指図が引き当ててしまう。したがって現品の受領、帳簿上の保有、使用可否を三つの別属性として表す。保留棚に物理保管できても、予約・ピッキングの対象から除外する。逆に合格していてもロケーション未登録ならピッキング対象にしない。ERPとWMSでそれぞれ別の状態を持つなら、どちらが引当可否の正本かを決める。

再使用期限も状態とセットで扱う。開封後の残材の使用期限が元ロットの有効期限より短くなる品目では、戻した日を新しい期限の起算日にしてよいとは限らない。品質部門が製品仕様、保管条件、顧客要求に沿って残余期限を定める。ロットを分割したり新しい容器IDを発行したりしても、元ロットと元指図への参照を失わない。GS1のGlobal Traceability StandardとEPCISは、識別子・イベント・場所・時間・業務文脈をつなぐ考え方を提供する。ただしこれらの標準を採用するだけで、その工場の品質合否が自動判定されるわけではない。

保留は期限を持つ。判定待ちの残材が何日も棚に積まれると、返却をシステム化しても実質的には隠れ在庫が増える。保留理由、担当者、判定予定日、次の処置を記録し、期限超過を一覧に出す。遅れをすべて倉庫の責任にせず、品質検査待ち、ロット調査待ち、原価承認待ちなど原因別に分ける。処置が廃棄となった場合、返却取引を遡って消すのではなく、承認済みの廃棄取引を別イベントとして残す設計を原則とする。

ERP・MES・WMSの記録を一つの返却IDで結ぶ

MESは指図・工程・消費実績を知り、WMSは容器・棚番・移動作業を知り、ERPは在庫残高と原価取引を知ることが多い。しかし実際の責任分担は導入済み製品と設定による。最初に三つの質問を決める。「返却可能な正味数量の正本はどこか」「利用可能在庫を増やす権限はどこか」「物理棚番の正本はどこか」。システム名だけで答えず、項目と取引単位で所有者を表にする。

連携イベントには、返却ID、指図ID、工程ID、元払出しID、品目、元ロット、必要ならシリアル、容器ID、申告量、実測量、単位、状態、保留理由、受領時刻、品質判定、棚番、ERP取引IDを含める。元払出しIDが取れない旧データでは、指図・工程・品目・ロットの組合せで候補を表示し、人が確認する。その例外を通常フローに隠さない。GS1 EPCISのイベント設計を参照する場合も、全社のシステムに無理に同じデータ形式を要求するのではなく、何がいつどこでなぜ起きたかを失わないことを優先する。

システム連携は「成功したか」だけでなく、部分成功を定義する。MESで返却申請が成功したがWMSへの作業生成に失敗した場合、同じ返却IDで再送する。WMSで棚入れが済んだがERPがタイムアウトした場合、ERP照会で取引の有無を確認し、無いときだけ同じ冪等キーで再送する。通信応答が失われただけでERP側は成功しているケースに備え、無条件の再登録を避ける。拒否されたときは理由を現場語で表示し、取引ログに技術エラーを残す。

照合は少なくとも「申請量・受入量・品質承認量・ERP戻し量・WMS棚入れ量」の五つを比較する。これらが一致しない状態を全て障害と呼ぶ必要はない。受入検査中、部分合格、廃棄への振替など正当な不一致もある。ただし差異の行き先と責任者を必ず説明できるようにする。日次の突合では未完了期間が長い返却ID、返却取引だけあるID、現品だけあるIDを別々に出す。月末の一括差額調整だけでは原因が消える。

二重返却をどう防ぐか

同じ容器を二度スキャンしても返却量を二重計上しない。容器IDと返却明細IDの組合せで一意性を持たせ、確定後の数量変更は元イベントの上書きではなく取消・再計上または差異調整として履歴を残す。部分受入を許す場合、同じ申請に複数の受入明細を付けても合計が申告量を超えないようにする。複数ラインで同じ指図とロットの残材が出る場合は、申請者と容器が異なる正当な二件として扱う。

端末のオフライン運用もここで決める。通信断中に現品を搬送してよいか、暫定ラベルの採番衝突をどう避けるか、復旧時に何を正本としてマージするかを定義する。オフライン記録を無制限に許すと、復旧したときに既に別指図で使われた在庫に重複して戻すリスクがある。危険度の高いロットは通信断中は保留棚へ置き、利用可能在庫へは昇格させない方針が必要である。

RFPで比較すべき要求を業務シナリオで書く

ベンダーに「返品機能あり」「バーコード対応」と尋ねても、ライン残材の返却ができるかは分からない。RFPの冒頭に、対象工場、対象ライン、品目群、指図数、ロット管理の有無、ERP/MES/WMSの製品と版、現場端末、倉庫レイアウト、承認権限を記載する。次に、代表的な指図が終了した後、開封済み部材がどの容器で、どの棚へ戻るかを、画面・イベント・帳簿の順で要求する。回答には標準機能、設定、追加開発、運用回避の別を付けさせる。

必須シナリオは、未開封の同一ロットを全量戻す、開封済み容器の一部だけ戻す、二つのロットが現場にある、申告量と実測量が違う、ラベルが読めない、期限が近い、品質不合格、同じ返却IDを再送する、ERP接続が切れる、返品直後に次の指図が引き当てようとする、の十例程度から始める。品目特性に合わせ、切断材、リール材、シリアル管理品などを追加する。それぞれ「画面に何が見えるか」「現品はどこに置くか」「どの残高が増えるか」「誰が承認するか」「どう復旧するか」を記入する。

費用比較はライセンスや開発費だけでなく、現場ラベル、ハンディ端末、秤、ネットワーク、既存ERPのインターフェース改修、マスタ整備、現品棚、教育、保守を含める。作業時間の短縮だけで投資を正当化せず、返却漏れ、二重在庫、廃棄、再発注、棚卸差異にどの程度効いたかをパイロットで測る。数字は自社実績と試験条件が揃ってから示す。以下の金額や率は実在工場の実績ではない仮定例である。

仮定例で見る数量突合と投資判断

仮定例として、ある指図へ同一ロットの部材を100個払い出し、良品への正味使用が72個、工程スクラップが3個、未使用現品が25個とする。100=72+3+25が物理的な説明である。ただしERP上の消費が自動バックフラッシュで75個と記録されているなら、現品25個をそのまま「負の消費」として入れてよいかは設定で異なる。追加払出しや仕損の取引が別なら、それらを含めた正味量に照合する。倉庫が24個しか数えられなければ、25個を先に計上せず1個差異を保留して原因を調べる。

さらに仮定例として、25個のうち20個が未開封で合格、5個が開封済みで品質保留になったとする。この時点の利用可能返却量は20個で、保留量は5個である。後日5個のうち3個が合格、2個が廃棄と判定されたなら、最終的な利用可能返却量23個、廃棄2個という履歴を残す。最初の25個申請を23個に書き換えると、開封材の品質判断が見えなくなる。会計計上の順序はERPの仕様と会社の方針に合わせ、現品・保留・使用可の数量が一致するように設計する。

投資試算も仮定例に限る。月に返却申請300件、現行の照合作業が一件当たり12分、導入後8分なら、月の短縮は1,200分、すなわち20時間である。人件費に換算する前に、短縮した時間が実際に別作業へ振り向けられるか確認する。月間の返却差異件数が20件から8件に減ったとしても、別の品目構成や生産量の変化があればシステムだけの効果とは言えない。同じ対象ライン、品目群、期間、測定方法で比較する。廃棄額と欠品回避額は重複計上しない。

FATとSATは正常処理より例外で差が出る

FATでは、ベンダー環境で代表データと境界値を使って機能を確認する。正しいロット・正しい数量の一件だけでは足りない。元払出しが見つからない、払出済みより多い数量、別ロット、読み取れないラベル、同じ返却IDの再送、品質保留からの不合格、連携タイムアウト後の応答喪失を再現する。確認するのは画面表示だけでなく、ERPの取引ID、WMSの棚番、MESの指図残、監査ログである。期待値をテストケースに書き、合否を人の印象で決めない。

SATでは実工場のネットワーク、実際のハンディ、秤、プリンタ、棚、夜勤の権限、手袋・油・照明下で検査する。箱を閉じた後でもラベルを読めるか、切断材の長さを安全に測れるか、容器の荷姿が棚に収まるか、保留棚と合格棚が混ざらないかを見る。受入数が多い時間帯に一つの端末で詰まらないかも確認する。FATで通ったAPIが実運用のタイムアウトや端末スリープで止まることはある。現場の作業動線を含めて検収する。

合格基準は「全件正しく動く」という抽象文ではなく、シナリオ別の期待状態とログを指定する。たとえば「品質保留の容器を未承認のままピッキングしようとすると、画面に保留理由が出て作業を止め、ERPで利用可能数量が増えず、監査ログに試行が残る」。これは設計例であり、どのシステムが引当制御の正本かによって実装は変わる。試験の合格基準、障害時復旧、再試験範囲、データ移行の責任を契約前に合意する。

稼働後も返却完了までの時間、申請と実測の差異率、品質保留の滞留、元払出し不明率、連携再送件数、二重取引件数、倉庫棚での現品差異を監視する。返却件数が減っただけで改善と判断しない。生産量が減った、現場が申請を避けている、あるいはキッティング量が変わった可能性がある。分母に指図数または払出し件数を置き、理由コードと共に見る。

小さく始める導入手順

最初の範囲は、戻しが頻繁で、ロット追跡が必要だが品目ルールが整理できる一つのラインと一つの倉庫に絞る。過去一か月の返却伝票、棚卸差異、廃棄・品質保留の実例を集め、現物がどこで止まるか歩いて確かめる。次に現物容器と元払出しを結ぶIDを設計し、各システムの項目・取引の正本を決める。画面開発の前に状態図と例外コードを合意する。これがないまま端末だけ配ると、スキャン件数が増えても在庫差異は減らない。

パイロットでは紙の現行手順と新システムの差を一定期間突合し、返却漏れ、誤ロット、保留未解除、計上タイミングのズレを数える。最初は利用可能在庫への自動昇格を広げすぎず、品質保留の経路を確実にする。実績が安定したら品目群、ライン、倉庫を増やす。変更時はマスタ、品質ルール、棚番、端末設定、FAT/SATの試験例を一緒に更新し、前回の合格を無条件に横展開しない。

経営への報告では「返品登録をデジタル化した」では弱い。返却申請から再利用可能在庫への平均時間、説明できない現品差異、品質保留の年齢、急ぎの再発注、棚卸調整を、導入前後で同じ定義で示す。差異が一時的に増えることもある。従来見えなかった差異が見えるようになったなら、初期の増加だけを失敗と解釈せず、解消までの時間と再発率を見る。

余剰部材返却管理システムはERP標準機能だけで足りるか？

ERPにReturn取引があっても、現品受入・開封状態・品質保留・棚入れ・端末オフライン・二重登録防止まで標準で実現できるとは限らない。逆に既存ERPとWMSの設定で足りる工場もある。RFPでは製品名で先に結論を出さず、代表シナリオを実機で通し、設定と追加開発の境界を見積もる。

返却後、すぐに次の指図へ引き当ててよいか？

未開封で状態が明らかな品目でも、少なくともロット・数量・場所の受入確認が必要である。開封や保管条件の影響を受ける品目は品質判定まで保留する。引当可能になった理由と時刻を記録し、物理棚入れ前に帳簿だけを使わせない。

元の払出しロットが分からない部材はどう扱うか？

推測で返却取引を作らず、ロット不明の隔離容器へ置く。現品ラベル、指図履歴、搬送履歴、在庫イベントを照合し、品質・在庫責任者が再識別の可否を決める。再識別できなければ廃棄または別の承認済み処置に分け、通常の返却とは別記録にする。

RFPとFAT/SATの最小セットは何か？

対象の指図・元払出し・ロット・部分数量・状態・保留・棚番・ERP取引IDを要求し、正常返却だけでなく、差異、ラベル不明、品質不合格、通信断、再送、二重スキャンを試験する。検収は画面と現物に加え、ERP/MES/WMSの最終残高と履歴で判定する。

なお、返却率そのものを目標にしない。返却が多いのは過大キッティングや計画変更の兆候かもしれず、返却が少ないのは正確な供給の結果かもしれない。返却管理のKPIと、払出し量を適正化するKPIを分けて見る。返却データから不要な払い出しを減らせれば、ラインと倉庫を往復する搬送も減る。ただし生産変動に備える安全余裕は別途必要であり、余剰ゼロを現場へ一律に強制しない。材料の種類ごとに供給方式と返却頻度を検証し、在庫精度とライン停止の両方を観察する。

工程変更と指図取消では、どの数量を戻すか

指図が予定どおり完了した場合と、工程途中で仕様変更・中止になった場合では返却の出発点が違う。完了時には確定した良品・不良・使用実績から未使用分を説明しやすい。一方、途中中止では現場で使用中の材料、機械に装着したままのリール、別工程へ移した未記録品が残りうる。申請画面が「予定払出量−予定使用量」を自動で返却候補にしても、それを確定量にしてはいけない。ライン責任者が装置内と搬送中の残材を確認し、工程別の保管場所を記録する。仕様変更で旧部材が再使用不可になった場合は、返却可能な現品であっても利用可能在庫に戻さず、品質・設計の処置待ちにする。

製造指図をシステムで閉じる前に未完了返却をゼロにする設計は分かりやすいが、現物検査が翌日になる工場では締め処理を不必要に止める。指図の生産実績確定と返却の品質・倉庫処理を別の完了条件として持ち、未完了返却IDを指図から辿れるようにする方が実務に合う場合がある。逆に、返却差異が原価確定へ重大な影響を与える品目なら、会計側が締めの保留を必要とする。どちらにするかは原価部門と品質部門が品目群別に決め、RFPの例外フローと月末締め試験に落とし込む。

移行データと初回棚卸しを混同しない

本番切替日にライン脇にある残材は、過去の払出し取引が追えるものと追えないものに分かれる。追えるものは既存指図に結び、現品照合して新しい返却IDを発行する。追えないものを新システムの正常な返却として一括投入すると、導入直後からロット由来が不明な在庫が「正常」に見えてしまう。切替前棚卸しで品目・ロット・状態・場所を確認し、由来不明品は移行時例外として隔離し、承認済みの初期残高または調整取引で処理する。新規返却のKPIと移行時例外の解消件数も別に集計する。

現場画面では次の一手を示す

返却が失敗したとき、端末に「エラーコード 409」だけを出しても作業者は現品をどこへ置くか決められない。たとえば「元払出しに存在しないロット」「申告量が返却可能残を超過」「品質判定待ち」「ERP応答不明」を別々に表示し、スキャンし直す、差異棚へ置く、品質担当を呼ぶ、再送を待つといった次の行動まで示す。例外が出た時点で容器IDを印刷し、棚へ置く場所を指定できれば、システム上の未完了と現物の所在が離れにくい。現場の使用言語と単位表記を揃え、タイ語画面でも品番・ロット・数量が日本語管理画面と同じ値を指すかSATで確認する。説明文の翻訳だけでなく、ボタンの意味と承認権限も一致させる。端末で再送した後は、同じ容器の未完了画面が消えたことを確認し、倉庫側の受入履歴と指図側の返却履歴の双方から同じ返却IDを検索できるか検査する。

まとめ

余剰部材の返却は、製造指図に結び付いた未使用材を「申請→現品照合→品質判定→棚入れ→記帳照合」する業務である。重要なのは返却を早く入力することだけではなく、次の指図が安心して使える在庫に変わった時点を説明できることだ。RFPには現物と三つのシステムの責任分担を書き、FAT/SATでは差異と通信失敗を含む実際の返却を再現する。こうして、見えない残材を、由来・数量・状態・場所が追える在庫に変える。

タイ工場でライン残材の返却ルール、ERP/MES/WMS連携、品質保留の範囲を整理している場合は、TOMAS TECHへご相談ください。一つのラインと品目群の現品フローを確認する段階から、RFPと試験項目の整理をお手伝いできます。

参考資料

• Microsoft Dynamics 365: Release production orders：指図Released状態と倉庫ピッキングの関係。
• Microsoft Dynamics 365: Release BOM and formula lines to the warehouse：製造投入場所への材料リリース。
• Oracle Fusion Cloud Manufacturing: How You Report Material Transactions：製造指図・工程へのIssueとReturn、ロット制約、二重単位。
• GS1 EPCIS standard：識別子を伴うイベントデータの考え方。
• GS1 Global Traceability Standard：トレーサビリティの枠組み。