製造業で部材払出管理システムを導入するなら、倉庫の出庫を記録するだけでは足りません。リリース済みの生産指図に対し、どの部材ロットを何個引き当て、どこからピッキングし、どの工程の投入場所へ運び、いつ実消費として在庫・原価に反映したかを一続きで追える必要があります。未使用品の返却と破損・廃棄を同じ「戻し」として処理すれば、実績も原価も狂います。本稿はタイの工場でERP、MES、WMSの役割を整理し、現場スキャン、差異処理、RFP、FAT/SATを設計する担当者向けの導入ガイドです。
資材管理システムの全体像は購買・在庫を含む広い管理を扱います。製造在庫の引当設計は将来の生産需要に在庫を約束する段階が中心です。ここでは引当後に現物を動かし、実際の消費を確定する取引に絞ります。指図が存在しても、引当、ピッキング、投入場所への移動、払出仕訳は同じ出来事ではありません。この区別がシステム選定の起点です。
「部材払出」の範囲と取引の境界を先に決める
対象となる流れは、①生産指図のリリース、②BOMまたは配合表に基づく必要数量の確定、③在庫の引当、④倉庫ピッキング、⑤生産投入場所への移動・受領、⑥実消費の登録、⑦未使用品の返却またはスクラップ、⑧差異の承認と締め、です。工場によって「払出」は④を指すことも⑥を指すこともあります。RFPでは口頭の「出庫」で済ませず、各イベントで在庫の場所、所有、利用可能数量、原価がどう変わるかを表にします。
Microsoft Dynamics 365 Supply Chain Managementの公式資料では、リリース済み製造指図は現場実行と倉庫作業に利用でき、物理的に引当済みの材料についてピッキング作業が生成されます。BOM行の倉庫へのリリースは指図リリースと同時、バッチ、自動、手動の方式を選べます。投入場所に既に材料があれば倉庫からの移動を要しない場合もあります。これは特定製品の仕様例ですが、どの製品を選んでも注文状態・倉庫作業・実消費を別の業務イベントとして記述する参考になります。Microsoftの指図リリース説明とBOM行の倉庫リリース説明を確認してください。
| 業務イベント | 現物・状態 | 主な確認項目 | 二重処理時の問題 |
|---|---|---|---|
| 引当 | 特定指図に在庫を約束 | 指図、品目、必要数、ロット条件 | 他指図と同じ在庫を約束 |
| ピッキング | 保管場所から取り出す | 元ロケーション、現品、実ピック数 | 倉庫在庫を二重に減らす |
| ステージング | 投入場所へ移す | 移動先、受領者、容器単位 | 所在不明の在庫が残る |
| 実消費 | 工程で使用量を確定 | 指図、工程、ロット、実量、時刻 | WIP・原価を二重計上 |
| 返却・廃棄 | 未使用品と不良を分ける | 状態、数量、理由、承認 | 使用量や良品在庫が誤る |
この表の「実消費」をどのシステムが確定するかは重要です。Microsoftの生産転記資料では、生産ピッキングリストの仕訳を転記した時点で材料消費の出庫取引が発生し、手持在庫が減ります。現場で容器を移したことと会計上の消費計上を同一視すると、未開封の余剰材料まで使った扱いになり得ます。逆に、実消費を登録したのに仕訳が転記されなければ、現場記録とERP残高が乖離します。Microsoftの生産転記資料を、採用製品の実際の設定と照合してください。
生産指図からピッキングまで：何をいつ払出可能にするか
まず指図ステータスを起点にします。計画中、確定、リリース、開始、完了、取消のどの状態で払出を認めるかを決めます。未承認の指図に払出せば、計画変更時に現物と帳簿を戻す仕事が増えます。一方で、現場に必要な直前までリリースしない運用は、倉庫の準備時間を失います。指図の変更、数量減、BOM改訂、代替部材、緊急指図の承認経路を先に可視化します。
BOMの計算数量はピック数量の参考ですが、常に同じではありません。歩留まり、固定使用量、端数、包装単位、工程別投入、実際の仕掛数量で差が出ます。たとえば100個分の指図を出しても、今シフトは25個分のみを生産するなら、全量を一度に投入場所へ出さない設計が適切な場合があります。MicrosoftのBOM行リリースでは、工程番号や完成品の部分数量を指定して材料をリリースできます。自社RFPには「全量・工程単位・シフト単位・部分数量」のどれを許可するかを書きます。
同じ品目が複数のロット、保管場所、容器に分かれていると、引当の結果だけでは作業指示になりません。ピッキングタスクには指図番号、BOM行、品目、要求数量と単位、候補ロット、元ロケーション、投入先、期限、優先度を含めます。代替ロットや不足時の判断権限も定めます。倉庫側が現品のラベルを読み、棚位置とロットを照合し、実ピック数量を記録した後、投入場所で再度受領確認する方式なら、搬送中の取り違えを発見できます。
倉庫のピック完了を即「消費」とみなす設計も製品設定によっては可能です。ただし、投入場所で待機する時間が長い材料、部分使用、残材返却、ロット単位の実投入時刻が必要な品目には向きません。Microsoftの製造実行パラメータ資料は、自動BOM消費を開始時、工程完了時、製造完了時などに設定でき、設定の組合せを誤ると材料が二重に控除されたり全く控除されなかったりすると明記しています。RFPでは自動引落しを「便利機能」として一括評価せず、品目群・工程・ロット追跡要件ごとの消費時点を指定します。設定資料がその検討の参考になります。
バーコードで確認する対象は「品目」だけではない
原材料の払出をバーコード化するとき、スキャナーが読めれば正しい取引になるわけではありません。容器ラベルに品目コードだけがあっても、どのロットか、包装単位が何か、同じ品目の別容器かは判別できません。最低限、工場で識別すべき単位を決めます。候補は品目、ロット、シリアル、容器・パレット、保管場所、指図、工程、作業者、実数量です。すべてを一つのコードに詰め込むのではなく、現場で読み取る順序とシステムから補完する情報を設計します。
GS1 General Specificationsはアプリケーション識別子(10)をバッチ・ロット番号のデータ項目として定義します。ただしGS1形式を採用しても、工場内の指図番号や工程、計量値との関連付けは別途必要です。サプライヤーラベルの読み取りと社内容器IDの発行を分け、同一ロットの分割容器に別々の容器IDを付けられるようにします。原材料の受入ラベルが破損していた場合の再印刷、手入力権限、元ラベルとの対応も運用に含めます。GS1の仕様はデータ項目の確認に使えます。
現場画面では、最初に指図またはタスクを選び、次に棚・容器・ロットを読み、数量と投入先を確認させます。順序を逆にすると、近くにある別指図の材料を誤って払出す恐れがあります。投入場所でスキャンする場合は「倉庫からの移動確認」なのか「実消費登録」なのかを画面の動詞と色で区別します。スキャン後の成功表示だけでなく、サーバーが受け付けた取引IDを表示し、通信断後の再送でも照会できるようにします。
単位換算にも注意します。購買はkg、倉庫は袋、工程はgで扱うと、バーコードの数量と作業者の計量値の単位が違います。換算係数、丸め、容器の風袋、許容差をマスタと画面の両方で明示します。25kg袋を一部使用して残りを返すなら、開封後重量をどの秤で測り、誰が残量を承認するかまで決めます。食品・化学・医薬などロット管理が厳しい工程では、実投入時点のロットと数量を記録する設計を優先すべき場合があります。Microsoftのハンディ端末による消費登録例は、指図、投入場所、品目、バッチ、数量を登録し、作業後に仕訳を転記する流れを示しています。公式例で画面項目の粒度を確認できます。
ERP・MES・WMSの役割を「正本と取引ID」で分ける
製品名だけで「ERPが在庫、MESが現場、WMSが倉庫」と三分割すると、境界の失敗が残ります。指図・BOM・品目・ロット・保管場所・在庫残高・作業タスク・消費仕訳について、どのシステムが正本を持ち、どのイベントを発行し、どのシステムがそれを確定するかをデータごとに決めます。たとえばERPが正式な指図と原価を管理し、WMSが倉庫ピックを実行し、MESが工程実投入を収集する構成はあります。ただし自社の製品設定や既存設備により正解は変わります。
連携では、指図番号だけを共通キーにしないでください。同じ指図の同じ部材を複数回・複数工程で払出す可能性があります。取引ID、指図行ID、工程、品目、ロット、容器ID、元・先ロケーション、数量、単位、イベント時刻、送信元、状態、訂正元IDを含むイベント契約を設計します。指図改訂番号とBOM版も保存すると、旧版でピック済みの現物と新版の所要量を比較できます。インターフェース表には「受信したら何を更新するか」と「返すACKの意味」を書きます。
最重要の試験は再送です。Wi-Fiが切れた端末が成功応答を受け取れず同じスキャンを再送したとき、受信側が同じ取引IDを既処理として返し、在庫・仕訳は一回しか動かないことを確認します。異なる内容に同じ取引IDが使われたら拒否して監査ログを残します。順序逆転にも備え、ピック完了より先に消費イベントが着いた場合の保留・再試行・人手処理を定義します。自動リトライの回数だけを増やしても、重複防止、監視、例外キューがなければ整合性は戻りません。
連携障害時は「現場を止める条件」と「紙・オフライン入力を許す条件」を品目リスクで分けます。ロット取り違えの影響が大きい品目は、サーバー照合なしで工程投入を続けない方針が必要かもしれません。続行を認めるなら、暫定記録の番号、容器の隔離、復旧時の照合、二重転記防止、責任者承認を定めます。作業者が単に「後で入力する」だけの運用は監査可能な例外処理ではありません。
差異、返却、スクラップを一つのボタンにしない
所要量と実ピック量、実ピック量と投入場所受領量、受領量と実消費量はそれぞれ別の差異です。差異が生じた境界を残さないと、倉庫が足りなかったのか、搬送中に紛失したのか、現場で余分に使ったのか分かりません。各段階の数量、単位、ロット、容器、時刻、担当者と承認者を並べて確認できる画面を用意します。小さな差異でも毎回手入力の理由を求めると形骸化するため、品目リスクと金額・数量に応じて承認閾値を設定します。ただし閾値は工場ごとの判断であり、本稿に一律の数字は置きません。
未使用部材の返却では、未開封か開封済みか、元の保管条件を保ったか、ラベルとロットが読めるかを確認します。使用済み材料を「返品」で良品在庫へ戻してはいけません。品質保留、再検査、再包装、廃棄の状態を分け、良品在庫へ再投入できる条件を決めます。逆仕訳は元取引への参照を持たせ、同じ指図・ロットに紐付けます。数量だけをマイナス入力して元イベントを消すと、監査と原因分析が難しくなります。
スクラップは返却と別の理由コード・勘定処理を持ちます。工程に投入された後の歩留まりロス、投入前の破損、容器破損、品質不合格では責任箇所が違います。Microsoftの生産転記資料も、エラー数量の価値を良品に配賦するか専用スクラップ勘定へ計上するかを設定できると説明しています。実際の会計方針は自社ERP設定と経理の承認に合わせます。システム要件では「差異を入力できる」では足りず、差異をどのイベントで見つけ、誰が承認し、どの取引で補正し、どの帳票に現れるかを書きます。
現場の役割分担と例外承認を業務画面に落とす
技術的な連携が正しくても、誰が次の作業を引き受けるか決まっていなければ残件が積み上がります。倉庫担当は指図とピックタスクを見て棚から材料を取り、現場担当は投入場所でロットと数量を受け取り、工程担当は使用時に実量を登録し、生産管理は指図変更を通知します。品質担当は隔離品の使用可否を判定し、経理は消費とスクラップの転記結果を確認します。システムに表示される作業待ちキューをこの役割に合わせ、代理者、引継ぎ、承認権限の範囲を定義します。
たとえば倉庫が20個をピックし現場が19個しか受領しなかった場合、その1個を「どこかにある」として受領を完了させてはいけません。移動中の未解決数量として保留し、元棚、容器、搬送単位、時刻を調査する作業を起票します。調査後に倉庫側の誤ピック、現場側の未スキャン、現物紛失のどれかを選び、証跡を添えて補正します。紙の伝票に赤字を書くだけではシステムの未解決残は消えません。
指図が取り消された場合も、既にピック済みの容器と未ピックのタスクを別々に扱います。未ピックタスクは中止できますが、現場投入場所にある材料は現物確認と返却・再引当が必要です。指図変更をERPから一方向に配信するだけの連携では、進行中のWMSタスクやMES実績を消してしまう恐れがあります。変更要求を受けた側が受理、拒否、保留のどれを返すかを決め、保留案件を責任者に見せる画面を用意します。
マスタデータの点検を導入前の作業に含める
払出システムはBOMと品目マスタの誤りを自動的に直しません。まず代表品目について、BOM行の代替可否、標準使用量、工程番号、単位換算、ロット管理区分、在庫状態、棚ロケーション、投入場所を確認します。旧品目コードと新コードの対応が曖昧なままスキャンを導入すると、現場で一致しないバーコードを手入力で通す運用が常態化します。ラベルに印字されたコードがERP品目、サプライヤー品目、社内容器IDのどれかを識別できるようにします。
データ移行時は残高だけを持ち込むのではなく、リリース済み指図、引当済み材料、ピック途中のタスク、投入場所の容器、未転記の消費仕訳を棚卸します。切替日の前後で同じ消費を旧システムと新システムに二重登録しない境界時刻を決めます。旧端末を停止する時刻、通信遅延で後から届くイベントの扱い、新システム側での受入番号、照合担当者を切替計画に明記します。切替直後の最初の指図は、品目・ロット・数量を現物、WMS、MES、ERPで突き合わせてから締めます。
運用で使う帳票も先に設計します。「何個払出したか」だけでなく、指図別の未ピック、搬送中、投入場所残、未転記、返却待ち、承認待ちの一覧が必要です。管理者が日次で例外を消せる粒度にし、月末に大量の手作業補正を残さないようにします。記録保存期間、アクセス権限、時刻同期は自社の契約と品質要求に合わせます。特定の保存年数を一律に想定せず、顧客監査で求められる追跡経路を実データで再現できるか確認します。
RFPで比較すべき機能・費用・責任範囲
RFPには現行プロセス図と実データを付けます。代表的な指図、複数ロットの部材、部分ピック、工程変更、残材返却、スクラップ、指図取消、通信断の事例を準備します。各社に同じシナリオを渡し、標準機能、設定、開発、外部製品のどれで実現するかを回答させます。画面の見た目だけで比較せず、在庫・WIP・原価・ロット追跡の結果までデモで確認します。
| RFP項目 | 必ず求める回答 | デモで見る結果 |
|---|---|---|
| 指図・BOM同期 | 正本、版、変更・取消の伝搬 | 旧版ピック済み案件の扱い |
| ロット・容器照合 | バーコード規格、分割・混載、手入力権限 | 誤ロットを拒否できるか |
| 部分払出 | 工程別・シフト別、端数・単位 | 残所要と残引当が正しいか |
| 消費時点 | 手動・自動引落しの品目別設定 | 二重控除が起きないか |
| 返却・廃棄 | 元取引参照、品質状態、承認 | 良品在庫と原価の反映 |
| 連携 | 取引ID、再送、順序逆転、監視 | 重複・欠落の再現試験 |
| 運用 | オフライン、権限、監査、バックアップ | 障害復旧後の照合 |
費用はライセンスだけでなく、端末、スキャナー、秤、ラベルプリンター、無線網、マスタ整備、既存ERP/MES/WMS連携、データ移行、現場教育、タイ語画面、保守、追加工程・品目の変更費を分けて見積もります。ベンダーによってはハンディ端末の画面改修とERP側仕訳連携が別契約です。境界ごとに責任者と障害一次切分け先を書かせます。価格の一律相場を提示するより、同じ業務ケースの範囲で複数提案を比較する方が実務に有効です。
導入対象はすべての品目を一度に広げず、ロット追跡が必要で払出頻度の高い一工程から検証できます。ただしPoCで扱うロット・容器・単位・返却は本番の難しいケースを代表していなければなりません。容易な単一ロット・全量使用だけで合格としても、実稼働の差異処理は評価できません。選定段階で本番の例外件数や入力時間を測り、導入後に比較できるベースラインを保存します。
FAT・SATで「画面が動く」以上を検証する
FATはベンダー環境で合意済みの業務シナリオを再現し、データと取引を検証します。SATはタイ工場の実際の棚、投入場所、ラベル、無線網、秤、端末、ERP/MES/WMS設定、作業者で確認します。FATで成功したAPIが、現場でロットの読めないラベルや不安定なWi-Fiに耐えるとは限りません。受入基準は後から「問題なく動く」と書き換えず、RFP時点で証跡と合否を決めます。
| 試験ケース | FATの確認 | SATで加える条件 | 合格証跡 |
|---|---|---|---|
| 指図リリース・部分払出 | 指図版と必要量、二回目の残量 | 現場の工程・シフト変更 | 指図行とタスク履歴 |
| ロット違い・数量超過 | 誤スキャン拒否、権限例外 | 実ラベル・計量器・手袋 | 画面と監査ログ |
| ピック→投入場所→消費 | 三段階の状態遷移 | 実棚・搬送・受領者 | 在庫・WIP・ロット履歴 |
| 未使用品返却・スクラップ | 元取引への逆参照 | 開封品・品質保留 | 良品在庫と会計仕訳 |
| 通信断・再送・二重タップ | 同一IDで一回だけ転記 | Wi-Fi切替、端末再起動 | リクエスト、ACK、残高 |
| 指図変更・取消 | ピック済み品の保留 | 現場にある容器の回収 | 承認と差異解消記録 |
試験データは一つの「理想的な指図」だけにしません。同じ品目の複数ロット、複数容器、部分数量、異なる単位、別指図、開封後返却、通信断を組み合わせます。二重タップを人の不注意として除外せず、現場端末で起きる入力として試します。合格は画面の緑表示だけでなく、各システムに一つずつ整合する取引があり、手持在庫、引当残、投入場所残、実消費、WIP・原価が業務定義どおり一致することです。
SAT中に残った不具合は、重篤度、暫定運用、担当、期限、再試験、稼働開始を許す条件を記録します。ロット取り違えや二重消費のような核心的な不具合を「後で修正」のまま通常運転に入れないでください。現場の操作手順はタイ語で確認し、実際の作業者が指図選択、誤スキャンからの復帰、返却、通信断後の照合を自分で実施できることを確かめます。ベンダーのデモ担当が操作できることと、工場が運用できることは別です。
受入試験の具体例：部分払出、返却、再送を一本の指図で追う
以下の数量は説明用の仮定であり、業界標準値や推奨許容差ではありません。完成品100台の製造指図がリリースされ、部材Aを1台当たり2個必要とするBOMを想定します。合計所要量は200個です。今シフトは40台だけ着手するため、倉庫には80個の部分払出を指示します。部材Aの在庫にはロットL1とL2があり、今回はL1から60個、L2から20個を二つの容器でピックします。製品や工程によって許されるロット混用条件は異なるため、この例では両ロットが承認済みであると仮定します。受入試験ではこの前提を指図、BOM、在庫状態に設定してから開始します。
まずWMS側で二つのピックタスクが完了し、元棚の利用可能数量と引当残が正しく変わることを確認します。MESまたは現場端末では、投入場所で各容器をスキャンし、L1の60個とL2の20個を受領します。この時点では材料を工程で使っていないという運用を仮定します。そのため、画面上の投入場所残は80個、実消費は0個でなければなりません。ERPの消費仕訳がこの段階で既に転記される設定なら、現場の言葉と会計の意味が一致していない可能性があります。採用する製品の設定に合わせ、事前に決めた転記時点と比較します。
次に工程がL1を50個、L2を18個使用したと登録します。実消費は68個、投入場所に残る未使用品はL1が10個、L2が2個です。端末から送ったL2の使用イベントは、サーバーで受理した直後にWi-Fiが切れて端末へ成功応答が戻らなかったと仮定します。端末が同じ取引IDを再送しても、MESの実績とERPの消費仕訳は18個を一度だけ反映し、受信側は既処理と回答することを確認します。端末が別IDで再登録しようとした場合は、少なくとも同一指図・工程・ロット・容器・作業時刻の疑わしい重複を現場へ警告できるかを評価します。取引IDの一意性だけで、誤って作られた別IDまで自動で防げるとは限りません。
作業終了後、未開封で状態が維持されたL1の10個は承認を受けて倉庫へ返却し、開封済みのL2の2個は品質確認待ちに置くと仮定します。返却済み10個は元の良品在庫に戻りますが、保留中2個は良品として再引当しません。後に品質が使用可能と判断すれば所定の再入庫手順を使い、不適合ならスクラップ取引を起こします。どちらも元の払出取引を参照します。この部分払出取引の受入判定では、今回ピックした80個が実消費68個＋良品返却10個＋品質保留2個に一致することを確認します。これは今回の部分払出分の照合であり、指図全体の未払出所要120個を「消費」や「差異」に混ぜません。
このシナリオの合格証跡は、WMSの元棚・ピック・返却記録、MESの受領・ロット別実使用・通信再送ログ、ERPの在庫・WIPまたは原価仕訳、品質保留と承認履歴です。各画面のスクリーンショットだけでは不十分で、共通の指図行IDと取引IDで各記録を結べる必要があります。試験担当者は同じ手順を別端末でも再現し、再送前後で残高と仕訳件数が増えていないことを比較します。合格しない場合は、どの境界で数量が変わったかを特定してから修正・再試験します。
稼働後のKPIと変更管理
導入後は「払出処理時間」だけでなく、誤ロットスキャンの拒否、ピック差異、投入場所での未受領、実消費の未転記、返却待ち、指図締め時の差異、再送イベントを追います。数字を集めるだけでなく、どの段階で起きたかを工程・品目・ロット・シフト別に見ます。アラートが多すぎれば現場は無視します。真の誤りとマスタ設定ミスを区別し、理由コードと承認フローを定期的に見直します。
BOM改訂、新品目、新規サプライヤーラベル、ロット規則、包装単位、設備・工程変更は払出フローの変更です。変更時に、指図とBOMの版、現場端末の画面、印字ラベル、ERP仕訳、WMSタスク、MES実績のどこを再試験するかを一覧化します。現場改善でスキャン順序を変えた場合も、同じ取引ID・重複防止規則と監査証跡が維持されるか確認します。
棚卸で残高が合っていても、消費時点やロット帰属が誤っていれば、この仕組みの目的は満たせません。月末の一括補正に頼らず、指図の締め前に「引当した数量、ピックした数量、投入場所に残る数量、消費した数量、返却・廃棄した数量」が説明できる状態を目指します。これが生産実績と原価、トレーサビリティを同じデータで支える条件です。
よくある質問
引当と払出は同じですか？
違います。引当は特定の需要に在庫を約束する状態、払出は現物のピックや工程への移動・消費を含む作業です。採用システムごとに用語は異なるため、RFPではイベントごとの在庫・会計効果を定義してください。
WMSがあればMESの払出機能は不要ですか？
WMSは倉庫内のピックと移動を担えても、工程で実際にどのロットを何量使ったかまで記録するとは限りません。MESを使うかERP現場画面を使うかは構成次第ですが、実消費の正本とERPへの転記を決める必要があります。
バーコードには品目コードだけを印字すればよいですか？
ロット追跡や容器分割があるなら不足します。品目、ロット、容器の識別と指図・工程への関連付けを設計してください。表示する数量と単位も現場で確認できるようにします。
自動バックフラッシュと実投入スキャンはどちらがよいですか？
一律には決められません。使用量が安定しロット追跡の要件が低い品目では自動引落しが適する場合があります。実投入の時刻・量・ロットが重要なら現場で登録します。両方式が同じ品目で重複発火しない設定を受入試験で確認してください。
返却数量を消費のマイナス入力で処理できますか？
元の消費取引と品目・ロット・品質状態を追える逆仕訳が必要です。未開封品、開封品、破損品を同じ良品在庫へ戻す運用は避けます。会計処理は自社方針に合わせて承認してください。
どの範囲から導入すべきですか？
一工程から始めても、部分払出、複数ロット、残材返却、通信断のような本番の難所を含めて試してください。指図のリリースから消費・締めまで、一連の取引と残高が検証できる範囲を最小単位にします。
まとめ：取引境界を仕様にすれば、見積りと受入が比較できる
部材払出管理システムの導入では、生産指図→引当→ピック→投入場所→実消費→返却・廃棄を分け、各段階の正本、取引ID、数量・単位、ロット、承認、会計効果を定義することが先決です。バーコードは現物と取引を結ぶ入口であり、重複防止、差異処理、ERP・MES・WMSの整合まで仕様に入れて初めて運用できます。RFPには実データの例外シナリオを添え、FATとSATで現場まで同じ結果になるか確かめてください。
タイ工場の既存ERP・MES・WMSを踏まえて払出フローを整理したい場合は、TOMAS TECHにお問い合わせください。指図から実消費までの現状図、取引境界、RFPシナリオ、FAT/SATの合格証跡を一緒に具体化します。
参考資料
- Microsoft Learn: Release production orders
- Microsoft Learn: Release BOM and formula lines to the warehouse
- Microsoft Learn: Register material consumption using a mobile device
- Microsoft Learn: Production parameters for manufacturing execution
- Microsoft Learn: Production posting
- GS1 General Specifications: AI (10) batch/lot
