製造業で工程間在庫の管理システム導入を検討するとき、「前工程は100個を完了、次工程は92個を受領した。残る8個はどこにあるか」に即答できるかが出発点です。生産進捗の画面に100個と表示されても、バッファの棚にある現物、品質保留中の箱、搬送中の台車は区別されないことがあります。本稿はタイ工場の発注者向けに、工程・置場・状態別の仕掛在庫（WIP）を数える設計と、RFPからFAT・SATまでの受入条件を整理します。
製造業の工程間在庫管理システム導入で最初に決めること
最初に決めるのは製品名ではなく、何を「工程間在庫の1個」と数えるかです。工程Aの加工が終わった瞬間なのか、検査に合格した瞬間なのか、工程Bの受入担当が現物を確認した瞬間なのか。これらの出来事を同じ「完成」ボタンにまとめると、数値は合っていても所在と使用可否が分からなくなります。工程間在庫の可視化は、製造指図の進捗表を細かくするだけでは成立しません。現物を置くバッファ、容器、保留場所、工程の受渡し責任をデータとして定義する必要があります。
例えばプレス工程が120個を生産し、うち3個を不良廃棄、2個を品質確認待ちにした場合、次工程へ渡せる数量は115個とは限りません。工程の途中にある検査、先行移動、戻し、箱単位の端数を考慮します。システム上は「良品117個」と見えても、2個の保留が良品の範囲に含まれているのか、既に控除されたのかを定めなければ、次工程の投入可能数は決まりません。導入時の基本要件は、同じ指図・品目・ロットについて、現在の所在と状態ごとの数量を再現できることです。
このテーマは搬送指示を誰に出すかという工程間運搬の話と接しますが、主眼は移動指示そのものではありません。工程間搬送指示システムで扱う搬送イベントの前後に、現物が何個存在し、どの置場と状態に属するかを示すことです。また、ロットの分割・統合履歴を追うトレーサビリティは重要な隣接要件ですが、本稿は系譜を主題とせず、日々の引渡し差異と滞留を解くための数量台帳に焦点を当てます。委託先が管理するVMIや所有権の判定も別論点です。自社工程内の仕掛品について、物理的な保管場所と使用可能な数量を確定する範囲から始めます。仕掛品管理の実務にある全体的な在庫・リードタイムの改善論とは切り分け、ここではシステム実装と受入試験を扱います。
なぜ進捗数だけでは足りないのか
Microsoftの製造実行資料では、作業者が工程ごとの良品数量を報告する操作と、最終工程の完成報告によって在庫を更新する操作が区別されています。工程の進捗報告数量が、そのまま在庫の現物数量になると仮定してはいけないことを示す実装例です。工場ごとのERP設定は異なりますが、少なくとも「報告された工程数量」「物理的な仕掛数量」「ERPの在庫計上数量」を同一列に置かず、各値の定義と突合点を決めるべきです。製造実行とERPの基本的な境界は生産管理システムとはも参照してください。
工程間在庫の可視化に必要な数量モデル
設計の最小単位は、品目、製造指図、工程、ロット、置場、状態、数量、単位、容器ID、時刻です。全工場で全てを必須にする必要はありません。しかし「どのキーで別の在庫と見なすか」を決めずに画面から作ると、同じロットが工程Aの出口、工程Bの入口、隔離棚に重複して出ます。数量は原則として増減イベントの積み上げと、棚卸時に確認した物理数量の両方を保持します。残高だけを上書きすると差異の発生点が消え、イベントだけを記録して現物検証をしなければ誤スキャンが積み上がります。
バッファは単なる場所コードではありません。工程Aからの出口待ち、搬送中、工程Bの受入待ち、工程Bでの投入待ちを同じ「工程間」に一括すると、誰が現物を探すべきか決まりません。置場マスタには、建屋、ライン、工程、バッファ、棚または床番地を必要な粒度で持たせます。現場のラベルと画面の名称を一致させ、移動元と移動先を同じID体系で表します。可動台車や通い箱を場所として扱うか容器として扱うかも決めます。容器を一時的な所在の手掛かりとして扱う場合は、容器の現在位置と内容物の関係を更新します。
状態は少なくとも「投入可能」「受入待ち」「品質保留」「再作業待ち」「廃棄確定」を区別します。保留中の箱が工程Bのバッファに物理的に置かれていても、投入可能在庫へ混ぜてはいけません。逆に、品質判定が終わっているのに保留のまま残ると、計画上の欠品が見かけ上発生します。状態変更には権限、理由、対象数量、前後の状態、時刻を残し、保留解除の承認者を明確にします。品質システムとMESのどちらが判定を持つかは製品構成によりますが、二つの画面で独立に解除できる設計は避けます。
単位も数量差異の原因です。プレス後は個、塗装前はトレー、組立前はセットと表示しても、計算の基準単位を決めなければ途中の端数が丸められます。容器の標準入数をマスタに登録しつつ、実入数の差を許すか、端数容器を識別するかを現場で決めます。箱のラベルを読めば必ず標準入数が入っていると仮定するのは危険です。現物確認を省略できる条件と、開封後に実数を再登録する条件を分けます。
数量保存式を業務用語で示す
一つの工程間バッファについて、「期首の物理数量＋前工程から受領した数量＋戻入数量−次工程へ払い出した数量−廃棄数量−他置場へ移した数量＝期末の物理数量」を基本式にします。品質保留は数量が消えることではなく状態の振替です。再作業先へ送る場合は移動として記録し、元の置場から引いて受け側へ足します。この式に合わない場合は、差異の原因を不明のまま調整伝票で消さず、最後に一致した時点からイベントを追います。
製造指図が複数日にまたがるなら、日付で集計する画面とイベント時刻で追跡する台帳を分けます。タイ現地時刻と本社の時刻、夜勤の業務日付、月末締めの時刻が一致するとは限りません。業務日付を後から変更してもイベント発生時刻は書き換えず、締め期間に影響する修正は承認を要する設計にします。「昨日の終了時点でどこに何個あったか」を再現できることが、滞留分析と会計側の照合に効きます。
仕掛在庫の滞留をどの時刻から測るか
「滞留3日」という表示だけでは対策につながりません。時計の起点が、前工程の完了、バッファへの着荷、品質判定の開始、次工程の投入待ち開始のどれかを決めます。前工程完了から着荷までが長いなら搬送の問題、着荷から受領承認までが長いなら引渡しの問題、投入可能になってから消費されないなら計画や段取りの問題かもしれません。品質保留の時間を通常の投入待ちと混ぜると、現場の改善先を誤ります。
滞留一覧には、単なる古い順だけでなく、指図の納期、次工程の予定投入、状態、数量、置場、最後のイベント、責任部署を並べます。しきい値は品目一律ではなく、工程のサイクル、洗浄や乾燥の必要時間、品質判定のリードタイムを考慮します。アラートを増やし過ぎると現場は見なくなります。最初は一つのラインと一つのバッファで、放置された箱を翌シフトで発見できる表示から始める方がよいでしょう。
先入先出を採る製品でも、工程間の滞留と倉庫のFIFOは同じではありません。品質保留品や再作業戻り品を「古いから」という理由だけで投入順に混ぜることはできません。投入可能状態に変わった時刻、元の加工時刻、品質条件をどの優先順位で使うか、現場責任者が承認する運用を決めます。倉庫側のFIFO設計は先入先出管理システムを参照し、工程間の受入と使用可否は別の受入条件として定義します。
滞留の根本原因を切り分ける
可視化された箱が残る理由は複数あります。次工程の能力不足、材料欠品による組立待ち、品質検査の判定待ち、品目ラベルの誤り、帳票だけ先に完了したこと、現物は移ったのに端末処理を忘れたことです。全てを「在庫過多」にまとめると、発注削減で解けない問題まで購買の責任になります。ダッシュボードの集計値から元のイベントと現物置場へ戻れる導線を設け、現場が一件ずつ原因を確定できるようにします。
日次の確認では、金額換算より先に数量と所在の信頼度を確認します。所在不明をゼロに見せるより、未照合として分ける方が安全です。改善会議では、滞留総数だけでなく、「前工程完了後に未受領」「受領済みだが未投入」「保留解除待ち」「差異調査中」の件数と、前日から解消した件数を見ると、責任を割り振れます。これらは導入後の運用指標の例であり、特定の削減率を保証するものではありません。
工程間の引渡し照合を設計する
前工程の「出した」と次工程の「受け取った」は同じ出来事ではありません。送出時刻、容器ID、品目・ロット、予定数量、実数量、送出担当、受入担当を結び、引渡し単位ごとに照合します。一方が操作していない時は、在庫を一方の場所に確定させず「搬送中」または「受入待ち」として残す設計が考えられます。どの時点で所有責任が移るかは、現場の作業標準と一致させます。単なるボタンの追加では、実際の現物確認が行われたか検証できません。
例えば10トレー送出し、受入側で9トレーしか見つからないとき、送出側の記録を勝手に9へ書き換えないことです。差異1トレーを未照合として保持し、場所・時刻・容器・担当者を追って再確認します。内容物が不足している場合は容器数と個数の差を分けます。現場で再計数した結果と、システムで許された訂正の履歴を両方残せば、欠品、二重スキャン、誤置きの再発を調べられます。訂正権限をシフト責任者に集中させるか、送出・受入の双方承認にするかは、差異の頻度とリスクで決めます。
移動イベントには重複防止のため一意のイベントIDを付けます。端末が通信断から復旧したとき同じ送信を再試行しても、在庫が二回減らないことが必要です。送信順が逆転した場合、例えば受入が先に届き送出が遅れて届いた場合の保留処理も決めます。取消は元イベントを消すのではなく、取り消した人と理由を持つ逆仕訳的なイベントにします。夜勤明けに同期する端末があるなら、事象発生時刻とサーバ受信時刻を別々に保存します。
スキャンができない例外を先に扱う
ラベルが汚れた、箱を開封して端数が生じた、臨時の床置場に移した、ネットワークが落ちた。これらを「運用で対応」とだけ書いたRFPは、現場で手書きメモと後入力を増やします。手入力の条件、写真添付の要否、再ラベル発行、仮置場、オフライン登録、復旧後の照合を例外フローとして示します。後入力は誰が何を見て入力したかを区別し、通常のスキャンイベントと同じ信頼度で扱わない方がよい場合があります。
容器ラベルは常に製品ロット番号そのものではありません。容器が再利用されるなら容器IDのライフサイクルと内容物の割当を分けます。ロットが複数容器に分かれる場合も、一つの容器に複数ロットを入れられる場合も、今回の対象工程で許す組合せを明示します。ロット分割・統合の系譜管理は別要件として詳細化しつつ、工程間の数量照合には少なくともロット別残高が必要かを決めます。管理粒度を細かくするほどスキャン負担とマスタ維持が増えるため、製品の品質リスクと探索時間に見合う粒度を選びます。
MES・ERP・WMSのどこが仕掛在庫を持つか
一つの数量に三つの「正解」を作らないことが重要です。ERPは原価と会計に関係する在庫・製造指図の基準、MESは工程実行と現場イベント、WMSは倉庫や管理対象置場の実在庫を担う構成が一般的な出発点ですが、実際の責任境界は既存システムと運用で決まります。工程間の全バッファをERPの倉庫ロケーションとして持つのか、MESの現場台帳として持ってERPへ節目で集約するのかを決めます。名前だけで「MESが管理」と書いても、入力と訂正の権限は定まりません。
境界表は少なくとも、製造指図とルーティングの正本、工程完了数量、良品・不良品の実績、バッファ残高、容器とロケーション、品質保留・解除、完成品入庫、在庫評価を行で並べます。各行に記録するシステム、参照するシステム、更新権限、同期時点、失敗時の再処理、照合担当を記載します。同じ「仕掛在庫」でも、現場の物理数量と会計上の仕掛評価は同じデータではありません。物理数量を正しく把握した上で、ERPにいつ、どの単位で反映するかを会計・生産・ITで合意します。
Microsoftの資料では、最終工程の完成報告が在庫数量へどう反映されるかを設定する例が示されています。工程途中の進捗数量が常に在庫トランザクションになるわけではありません。この点は製品ごとに設定が異なるため、ベンダーには自社の工程を使って画面と台帳の変化をデモさせます。SAPの生産供給エリアに関する資料も、工場・保管場所・供給エリアという位置関係を扱っています。これらは「どの製品を選ぶべき」という根拠ではなく、工程と置場の境界を確認するための一次資料です。
設計の具体例として、工程Aの完了はMESに記録し、MESが容器単位のバッファ残高を更新する。工程B受入時にもMESで数量と状態を照合する。WMSがそのバッファを管理対象とするなら、位置移動イベントを連携する。ERPへは完成品入庫と定めた節目で確定数量を送る。これは一例であり、既存ERPが工程別在庫を直接持つ工場では別の境界になるでしょう。大切なのは、イベントの一回性と日次照合の責任をRFPに書き、二重計上と更新漏れを検出できることです。ERPと生産管理の連携ではデータ契約を詳しく扱っています。
マスタと識別子の責任
品目名を日本語・タイ語・英語で表示しても、連携キーは言語に依存しない不変IDにします。工程コード、ラインコード、置場コード、状態コード、単位換算、容器種別についても、誰が追加・変更し、いつから有効かを決めます。工程変更で旧コードを消すと、過去の滞留履歴が読めなくなるため、版と有効期間を保持します。マスタの承認前に現場が臨時ラベルを発行できるなら、その後で正式コードへ統合する手順が必要です。
GS1のトレーサビリティ標準は、出来事を記録する際の「誰が、何を、どこで、いつ、なぜ」というデータ要素を整理します。この考え方は、工程間の受渡しイベントの必須項目を検討する助けになります。ただしGS1標準を採用しただけで工程別仕掛数量が自動的に正しくなるわけではありません。自社のバッファと品質状態、数量変更の承認を業務要件に落とす必要があります。
RFPで問うべき実装と見積の範囲
RFPには「仕掛在庫を可視化できる」とだけ書かず、代表的な一つの品目と二つの工程で、シナリオを示します。投入120、良品117、不良3、良品のうち2を保留、10箱に分けて送出、受入で1箱不足、翌日に発見して照合、という一連の例です。ベンダーには、各イベント後の画面残高、台帳、ERPへ送る数量、エラー時の訂正手順を提示してもらいます。比較するのは機能名ではなく、このシナリオを標準機能、設定、追加開発のどれで実現するかです。
見積の範囲には、端末とスキャナー、ラベルプリンター、無線LANの死角調査、置場表示、マスタ整備、既存ERP・WMS・QMS連携、データ移行、現場教育、夜勤立会い、運用保守を含めます。ソフトウェアの画面だけで価格比較すると、現物確認を成立させる周辺作業が後から追加になります。再利用可能な既存端末がある場合も、読み取り性能、手袋での操作、汚れたラベル、通信断、充電場所を現場で試します。導入方式と総費用の比較は別途行い、根拠のない一律の費用相場を工程間在庫の要件に持ち込みません。
画面要件では、棚・容器・ロットのどれから検索するか、タイ語表示が必要か、現場の画面で保留を色だけに依存せず文字でも示すか、権限によって訂正ボタンを出すかを決めます。管理者向けには、工程×置場×状態の残高、滞留の起点別一覧、未照合の受渡し、日次の差異、訂正ログを要求します。CSVが出せることだけでは十分ではありません。CSVの各列がどのイベントとマスタから来るか説明でき、同じ条件で再抽出したとき同じ結果になる必要があります。
契約条件では、データの持出し形式、イベント履歴の保持、追加拠点時の費用、障害時の復旧目標、サポート時間、アップデート時の連携互換性も確認します。稼働後に工場側が置場や状態を増やせる範囲と、ベンダー改修が必要な範囲を分けます。発注側の責任も明記します。現物棚卸、品目・工程マスタの正規化、受入担当の割当が未完なら、システム納入だけでは正しい残高は生まれません。
FAT・SATで工程間在庫差異をどう試験するか
初期棚卸とデータ移行を受入条件に含める
新システムの最初の残高は、旧システムの数字をコピーするだけでは確定できません。切替日を決め、その時点で各バッファを止めて、品目・ロット・状態・置場・容器ごとに現物を数えます。数える前に、工程Aが完了として報告したがまだ運んでいない箱、搬送中の箱、工程Bに届いたが未受領の箱を分けます。区別しないまま旧台帳と新台帳へ同じ箱を登録すると、移行初日から二重計上が起きます。棚卸票には計数者と確認者、時刻、現物ラベル、システム移行キー、差異理由を残し、未確定の箱は「未照合」の状態で引き継ぎます。未照合のまま投入可能にしてはいけません。
旧Excelや既存MESのデータを移すときは、旧コードと新コードの対応表を事前に承認します。品目名だけで突合せず、旧品目ID、製造指図ID、工程、ロット、置場、単位を明示します。廃止された置場の残高を現行の代表置場へまとめるなら、その判断を記録し、後から元の場所を追えるようにします。旧システムで品質保留が文字メモだけに入っていた場合は、自動変換が可能か現物を確認します。保留理由が読めないものを自動で「投入可能」に変えてはいけません。移行対象は残高だけでなく、稼働中の未完了送受、未処理の差異、保留品、再作業中の箱も含めます。
切替リハーサルでは、同じ手順で二回移行して同じ結果になるかを確かめます。移行の途中で端末が新規イベントを送った場合、どちらのシステムを正本にするかを決めておきます。切替後の最初のシフトで、新台帳の場所別合計と現物が一致するか、未照合の箱がどこへ表示されるかを確認します。差異がある場合は開始残高を密かに修正せず、移行差異として残して担当者と期限を付けます。この工程を見積とSATに含めないと、ソフトウェアの機能試験が通っても現場の在庫検索は初日から信用されません。
インターフェースの契約に含める六つの項目
ERP・MES・WMSを結ぶ際は、API名の一覧より、各イベントの契約を決める方が重要です。第一に一意のイベントIDと元イベントへの参照。第二に品目・指図・工程・置場・状態を表す不変ID。第三に基準単位と換算値。第四に発生時刻、送信時刻、受信時刻、業務日付。第五に成功、保留、再送待ち、拒否の結果と理由。第六に取消や訂正を相手システムへ伝える方法です。これらを一つのサンプル電文に書き、同じ電文を二回送った場合、順番が逆になった場合、受信側で品目コードが見つからない場合の期待結果を添えます。
連携が停止したとき、現場作業を続けるのか、出庫・投入を止めるのかは商品のリスクで決まります。停止中に現場端末で処理したイベントをキューに残すなら、復旧時の再送順、重複排除、件数照合、オペレーターへの表示を定めます。受信側のERPが会計期間を閉じていて拒否した場合も、MESだけ成功として表示してはいけません。現場の物理残高とERP計上の未反映差を別画面で示し、例外の責任者が処理するまでクローズしないことです。インターフェース監視はITだけの仕事ではありません。生産管理、倉庫、品質、会計のどの担当が差異を承認するかを、エラー種類ごとに決めます。
運用に入った後、測定するのは「在庫が何％減ったか」だけではありません。画面から現物を見つけるまでの所要時間、未受領容器の件数と経過時間、状態未確定の数量、差異の発生から解決までの時間、訂正イベントの理由別件数、端末のオフライン再送件数を見ます。これらは成果を保証する数値ではなく、仕組みが機能しているか確かめる観測点です。導入前に現状を同じ定義で測っておけば、稼働後に「画面はできたが現物が探せない」という事態を検出できます。指標の担当者、集計周期、アラートを受けた時の作業まで決めてから本番判定をします。
FATでは代表データを使い、数量保存式とイベントの整合を机上ではなく実操作で確認します。通常の完了、部分完了、品質保留、保留解除、廃棄、再作業戻り、誤スキャンの取消、重複送信、通信断後の再送、日付跨ぎを含めます。各ケースで入力、期待残高、ERP・WMSへの送信内容、例外表示、監査ログを事前に表にしておきます。画面の数字だけが合っても、後から誰がいつ変更したか分からなければ受け入れません。
SATでは実際の箱、トレー、台車、ラベル、棚、端末、ネットワークを使います。前工程が箱を出した直後、搬送中、次工程が受けた直後の各時点で、画面を見た担当者が現物を見つけられるか確認します。夜勤と日勤の引継ぎ、複数品目が同じ棚にある場合、汚れたラベルと端数箱、品質隔離場所を必ず試します。現場では作業順が入れ替わり得るので、ベンダーのきれいなデモ経路だけで合格にしません。
合格基準は「100%正確」など曖昧な宣言ではなく、試験データと現物で再現できる条件にします。例えば、定義済みの10ケースで数量保存式が全て成立する、同じイベントIDの再送で残高が変わらない、未受領容器を投入可能数に含めない、権限のない利用者が保留解除できない、差異の発生と解消の両方が履歴に残る、といった形です。性能はピーク時間のスキャン件数と許容待ち時間を工場側が決めて測ります。試験で出た差異を「導入後の改善」として先送りするなら、その影響と暫定運用を記録して責任者が承認します。
稼働後の最初の運用会議
初期稼働では、毎シフトの終了時に未受領容器、数量差異、品質保留の未処理、訂正件数を確認します。現物がないのにデータだけ残るケースと、現物があるのにデータがないケースを別々に扱います。原因分類は画面の入力ミスだけにせず、置場表示、ラベル、端末位置、搬送経路、担当境界も含めます。改善したフローは作業標準と教育資料に反映し、属人的な口頭ルールのままにしないことが重要です。
並行稼働をするなら、Excel側と新システム側の両方を無期限に更新し続けないよう、終了条件を先に決めます。どのラインで、何シフト連続して差異が解消され、どの帳票を新システムへ一本化するかを明示します。差異が残る場合は原因と対処期限を持つ課題票にし、日々の残高を黙って調整して合わせない。稼働後の改善を積み上げるためには、最初の受入で定めた数量定義を変えるとき、旧定義と新定義の対応を記録する必要があります。
よくある質問
工程間在庫の可視化はExcelでもできますか？
一つのラインで一日一回の棚卸だけなら、Excelでも現状把握はできます。ただし、複数シフト・複数置場で受渡しと状態変更が頻繁に起きると、同時更新、履歴、誤入力の訂正、オフライン復旧を表計算で管理する負担が増えます。まず現物の数え方と置場コードを小さく決め、Excelで差異原因を把握してからシステム化する方法もあります。ツール選択より、どの出来事を誰が記録するかが先です。
仕掛在庫の滞留は何日からアラートにすべきですか？
一律の日数はありません。工程の標準待機、品質判定、次工程の計画投入時刻を踏まえ、滞留時計の起点を定義します。初期設定は過去の実績分布と現場が処理できる件数を見て調整します。保留品と投入可能品を同じ閾値で扱わず、理由と責任部署が分かる一覧にする方が改善につながります。
WIP在庫管理はMESとWMSのどちらで行いますか？
工程内の進捗と状態をMES、倉庫管理対象の置場と容器をWMSで扱う構成が考えられますが、正解は既存システムの機能と物理的な管理範囲で変わります。境界にあるバッファについて、どちらが数量の正本を持ち、どのイベントで相手へ同期するかを一行ずつ決めます。ERPの在庫評価や完成品入庫とも混同しないことが重要です。
工程間の在庫差異が発生したら、どう修正しますか？
まず現物を再計数し、最後に一致した時点から送出・受入・移動・保留・廃棄のイベントを確認します。原因不明のまま残高を上書きせず、差異として記録し、権限者が理由付きで修正します。二重スキャン、未受領、容器入数違いなど原因ごとに作業標準を直します。修正後の残高だけでなく、差異がどう解消したかを追える履歴が必要です。
導入時に全工程を一括で対象にすべきですか？
最初は現物を数えやすく、差異が業務へ効いている一つの工程間バッファが適しています。数量定義、ラベル、受渡し、保留、日次照合がその範囲で閉じるかを確かめてから横展開します。ただし、ERP連携、識別子、置場コード、権限の設計は後の工程追加を見越して統一しておきます。
まとめ
工程間在庫管理システムの導入では、進捗報告を増やすより先に、現物を工程・置場・状態別に数える定義を作ります。引渡しの送出と受入を照合し、滞留の時計と品質保留を分け、MES・ERP・WMSの正本を決めます。RFPでは実際の箱と数量差異を使ったシナリオを示し、FAT・SATでは通常時だけでなく通信断、重複、端数、保留解除まで試します。この順番なら、画面上の在庫が現場で探せる現物につながります。
タイ工場で工程間の仕掛品が「帳票上はあるのに見つからない」状態なら、まず一つのバッファの現物・記録・責任境界を整理するところから相談できます。TOMAS TECHへのお問い合わせをご利用ください。
参照資料
- Microsoft Learn: How workers use the production floor execution interface — 工程ごとの進捗数量報告。
- Microsoft Learn: Report production orders as finished — 最終完成報告と在庫計上。
- Microsoft Learn: Production feedback — 工程・作業別の数量実績。
- SAP Help Portal: Production Supply Area — 工場、保管場所、供給エリアの関係。
- SAP Help Portal: Calculate Physical Stock at Production Supply Area — 供給エリアの物理在庫。
- GS1 Global Traceability Standard — 出来事とデータ要素の考え方。
