製造業の受注残管理システム導入｜部分出荷と確約納期を揃える

製造業で受注残管理システムを導入する目的は、受注一覧をきれいに表示することではありません。一つの受注行を複数回に分けて出荷した後も、残数量、確約納期、在庫引当、生産指図、顧客への回答が同じ事実を示すようにすることです。タイ工場では営業がExcelで残を管理し、ERPは伝票単位、MESは指図単位、WMSは出荷単位で動くことがあります。本稿では、受注残を壊さない状態設計からRFP、FAT/SATまで、発注できる仕様に落とします。

受注残の核は受注行ごとの数量保存則

最初に合意したい式は、受注行の注文数量＝出荷確定数量＋取消数量＋未出荷残です。「出荷確定」はピッキング開始や出荷予定ではなく、会社が定義した出荷確定イベントに限定します。返品、値引き、請求調整は別のイベントとして扱い、過去の出荷を無言で減らしません。受注変更によって注文数量そのものを改訂するなら、旧版と新版を残し、どの時点の式かを表示します。これが曖昧だと、見かけの受注残が減った理由を説明できません。

以下の数量は説明用の仮定であり実績値ではありません。 顧客が1,000個を注文し、600個を出荷確定、100個を正式に取消したなら、未出荷残は300個です。倉庫でさらに200個をピッキング済みでも、それを「出荷確定」として数えていなければ残は300個のままです。ただし画面では「残300個のうち200個は出荷準備中」と内訳を出します。準備中を残から引くと、荷物が戻ったときに差分が分からなくなります。

数量は品目の基準単位で保存し、受注単位への換算と丸めを明示します。箱と個、kgとg、切断品の長さと本数を混ぜる場合、画面の合計だけが合っても実物は合いません。端数、代替品、無償予備品、セット品は受注行へ紐づく明細を残します。「出荷確定」を倉庫の出庫、運送会社の引取、顧客への引渡しのどこに置くかは、契約・貿易条件・社内会計との整合で決めます。本稿の式は案件用の設計原則であり、各ERPの内部データ構造を定義するものではありません。

残数量と約束数量を別の数字として見せる

未出荷残300個のすべてが明日納品できるとは限りません。システムは少なくとも「未出荷残」「在庫から引当済み」「生産予定に紐づく」「未確約」「出荷準備中」を別に表示します。確約数量は顧客へ通知した時点の約束であり、物理在庫とは異なります。引当は顧客や受注のために在庫を確保する処理で、システムの設定によって現物と入荷予定の扱いが変わります。Microsoftの在庫予約ガイドも、手動・自動予約、物理在庫と発注済み在庫、ロットの扱いを分けています。[2]

受注残の各単位には、要求納期、回答済み確約納期、最新の見込み納期、出荷予定日、実際の出荷確定日を別項目で置きます。要求と確約を同じ列に上書きすると、顧客への回答履歴と納期遵守の評価が消えます。「見込み」が更新されても、顧客へ通知して承認されたかは別状態です。営業、計画、倉庫が別々のExcelを持つ場合、どれを正本として顧客へ答えるかを定めます。

受注残管理の守備範囲は、顧客がまだ受け取っていない受注行と、その残に対する確約・実行状態です。数量、納期、仕様を改訂する手続そのものは製造業の受注変更管理で詳述しています。また、全工場の納期管理RFPやKPI設計は納期管理システムの導入ガイドを参照してください。本稿では、部分出荷後にも残が正しく存続することに焦点を絞ります。

部分出荷を「一件の受注に複数の履行行」で表す

一つの受注行を二回以上に分けて納めるなら、受注行を無理に複製するより、親の商流上の受注行と複数の納入予定行・出荷明細の関係を表現します。Microsoft Dynamics 365の配送スケジュールでは、元の受注行の数量を複数の配送行へ分け、配送日、数量、配送方法、倉庫などを個別に持ちます。[1] Microsoftの直送処理資料では、既に一部を納品した受注で残数量を直送する場合、残を別行へ分割することが説明されています。[3] 特定製品に合わせるのではなく、共通の業務意味を設計します。

例えば前節の未出荷残300個を「200個は10月12日、100個は10月20日」と顧客に確約したとします。二つの確約行の合計は300個で、既に出荷確定した600個と取消100個はその予定行に入れません。10月12日分を150個だけ出荷したら、その行の未出荷分50個を残し、顧客と合意した新しい日付へ再確約します。10月20日分100個を無断で前倒しして表示上の不足を埋めるのは避けます。いつ誰が約束を変えたかを残します。

納入予定行には、受注行ID、行番号、改訂版、予定数量、要求日、確約日、出荷先、倉庫、輸送条件、優先順位、承認状態を置きます。出荷明細には実際の数量、ロット、出荷確定イベントIDを置きます。複数納入先や複数通貨が一行に混ざる場合は、そもそも受注行を分けるべきか業務側で判断します。表示画面が親行と子行の数量を二重集計しないことも受入条件です。

図1は一つの受注行が二つの納入予定行と複数の出荷実績へ分かれ、未出荷残へ戻る構造を示します。数字は前述の説明用例です。

ERP・MES・WMSの正本とイベント境界を決める

ERPは受注と商流の正本、MESは生産指図と製造実績、WMSは引当・ピッキング・出荷確定を担う構成が一例です。実際には機能が重なるので、製品名ではなく、どのイベントをどのシステムが最初に確定するかを決めます。ISA-95は企業側の業務と製造オペレーションの情報交換を整理する参照枠です。[6] WMSまで自動的に標準の特定階層へ割り振るための図ではありません。

ERPの出荷伝票とWMSの出荷実績を両方残に加算してはいけません。WMSからのイベントをERPで会計伝票化する場合、一つの出荷に共通IDを付け、どちらが「唯一の出荷確定」を発行するかを決めます。MESの完成数量は出荷可能在庫の候補であり、検査保留なら引当可能とは限りません。返品が発生したとき、元の受注残を再開するのか、新しい代替受注を作るのかも業務ルールとして決めます。

バックオーダーを忘れず、誤って消さない

部分出荷後の未出荷残をバックオーダーとして扱う場合、「未出荷残がある」ことと「次の出荷手配がある」ことを分けます。Oracleの部分出荷の例では、注文10に対して6を出荷した後、残4のために別の移動・出荷計画を作る流れが示されています。システム間にバックオーダーイベントが渡らない場合の手動補完も明記されています。[4] これは、出荷実績だけを受けて残の次の手配を作らない連携が危険だと示す実例です。

Oracle Order Managementの製品ガイドでも、部分出荷後の残をバックオーダーとして扱う例が説明されています。[5] ただし、製品ごとの設定やオプションをタイ工場のシステムにそのまま適用しません。要件は「部分出荷、保留、取消、残の再計画が一意の受注行へ紐づく」「残を誰がいつ次回確約するか見える」「未確約が放置されない」です。

「未出荷残」と「バックオーダー」は同義ではありません。顧客が複数回納入を最初から承認していれば、後続の納入予定行は計画どおりの未出荷残です。供給不足などで当初の履行ができず、残を後日に再手配するときにバックオーダーとして扱う場合があります。一方、約束日を過ぎた未出荷残は遅延です。優先順位のダッシュボードでは、残数量に加えて、最古の未履行確約日、次の計画日、顧客通知状態を示します。「残がある受注数」だけをKPIにすると、正常な分納契約も異常として数えます。

引当と生産指図を残の分割単位へ結び付ける

引当は受注行全体に対して行うのか、納入予定行ごとに行うのかを明記します。600個を既に出荷し、残300個のうち200個を確保したなら、表示は「残300、引当済み200、未引当100」です。引当済み200を残から引いて「残100」と表示すると、顧客がまだ受け取っていない200を見落とします。引当後に品質保留、棚卸差、ロット失効が起きたら、引当を解除し、確約日を再評価するイベントが必要です。

受注生産では、残の各納入予定行を生産指図に紐付けます。一つの指図が複数受注をまとめる場合、配賦表を持ちます。指図が計画済み、着手、完了、検査待ち、入庫のどの段階かで「供給可能」の確度は違います。計画数量をそのまま出荷可能数量にしないでください。設備停止や不良率を反映した見込みは変わりうるため、顧客への確約は責任者の承認を通します。

見込生産と受注生産が混ざる工場では、在庫と将来完成品を同じ画面で示しても、物理在庫、発注済み材料、仕掛、完成予定の区分を明確にします。代替ラインや外注へ振り替えたとき、古い指図との二重引当を検知することが重要です。確約を変えたら計画と引当が自動的に追従するか、承認待ちのタスクを出すかも仕様で定義します。

顧客回答に必要な一画面を設計する

営業担当が電話中に答えるのは「受注残はいくつか」だけではありません。「何個を何日に確約済みか」「その根拠は在庫か製造予定か」「前回の回答から何が変わったか」です。一画面に、顧客・注文番号・受注行、品目、受注数量、出荷確定累計、取消累計、未出荷残、出荷準備中、引当済み、未引当、確約数量と日付、見込み日、最終更新時刻、通知状態、例外理由を並べます。必要な列は役割ごとに絞り、クリックで出荷・指図・引当の明細へ降りられるようにします。

回答履歴には、相手、日時、言語、伝えた数量と日付、根拠版、承認者、通知手段を残します。タイ語・日本語・英語で日付の形式やタイムゾーンが異なる場合、内部では同じタイムスタンプを保持し表示を変えます。日付だけの確約なら「工場現地日付」と明示し、時刻まで約束していないのに深夜のシステム時刻で日付がずれないようにします。顧客指定の納入先や便を変えた場合も、以前の回答との違いを見せます。

図2はERP受注行、MES生産指図、WMS引当・出荷のイベントが一つの受注残画面へ集まる構成を示します。数字の二重計上を防ぐため、各イベントの正本は一つです。

連携で守るのは再送の冪等性と順序

現場ネットワークが一時停止してWMSの「出荷確定200個」が再送された場合、二回受け取って出荷400個としてはいけません。受注残システムはイベントID、発行元、伝票ID、明細ID、改訂番号を使って同一イベントを一回だけ反映します。通信の「送信成功」は相手側の業務反映成功と同義ではないため、応答、再送、隔離、手動再処理、照合を設計します。重複イベントを捨てた記録も残します。

順序も重要です。受注取消が先に届き、後から古い受注版の出荷予定が届く場合、単純な最終受信勝ちでは取消が消えます。イベントには元の受注行IDと版、発生時刻、送信時刻を付け、版が古い更新は隔離します。出荷確定が取消と同時進行したときは、すでに現物が出たかどうかを確認し、形式的な数式合わせだけで履歴を上書きしません。

連携仕様書には、項目名だけでなく、業務イベント、発行条件、キー、単位、正本、受信確認、タイムアウト、再送条件、順序保証、エラーキュー、再処理権限、日次照合、監査ログを記します。バッチ連携なら「前夜の受注残」と「今朝の出荷」のタイムラグを画面上に表示します。リアルタイムのように見せて実際は遅延している画面ほど、顧客への誤回答につながります。

差異を毎日照合して翌朝までに説明する

日次照合では、受注行ごとの数量保存則に加え、出荷確定イベント件数とERP伝票、WMS出庫、請求対象の整合を確認します。ただし請求は出荷と同日とは限らないので、同じ日付の件数一致を無理に求めません。時間差を考慮した滞留一覧で、未反映、二重反映、隔離中、承認待ちを分けます。差異の責任者、調査期限、再実行の可否も表示します。

上表のしきい値は工場と契約条件に合わせます。数字だけの「正常」ランプより、どの受注に何が起き、顧客回答に影響するかを示す方が現場で使えます。週末や連休前は、確約日が近い受注残とエラーキューを優先して点検します。差異の手修正には元イベントと理由、承認者を残し、翌日の自動連携で元に戻されないようにします。

分割、取消、返品を一つの「残」へ混ぜない

受注残を長く正しく保つには、数量が減った理由をイベント別に記録する必要があります。部分出荷は履行、取消は顧客または社内承認に基づく義務の消滅、返品は一度履行した商品の逆流です。この三つをすべて「マイナス伝票」で処理すると、残が同じ数値でも顧客に何を約束しているかが違ってしまいます。画面には残数量に加えて、前日からの変化を「追加受注」「改訂」「出荷確定」「取消」「返品」「再開」に分解して示します。担当者は合計値だけでなく、変化の根拠伝票と承認を確認できます。

例えば説明用に、注文100個のうち60個を出荷し、残40個があるとします。このあと顧客が10個を取消せば、出荷60、取消10、残30です。一方、出荷済み60個のうち10個が返品されても、顧客が再納入を求めるか、返金で完了するかで処理は分かれます。再納入なら新たな履行義務を発生させ、その根拠を元の注文と返品に結びます。返金で完了なら、元の受注行の未出荷残を機械的に10増やすべきではありません。返品処理は品質判定、在庫への再受入可否、請求訂正とも関係するため、誰が受注残を再開するかを事前に決めます。

分割した予定行に一意の識別子を与える

予定行の番号を画面の並び順だけで管理すると、営業が納期を入れ替えたときに連携先が別の予定行と誤認します。親の受注行IDに、変わらない予定行IDと版を付けます。200個の予定行を150個と50個へ分割した場合、元行をどう閉じ、二つの新行をどう参照するかを履歴で表します。IDを使い回さず、旧行を削除して痕跡を消さないことが重要です。出荷実績は、その時点で有効だった予定行IDへ結び、後から予定を変えても実績の出所が変わらないようにします。

複数工場が同じ受注行の残を供給するなら、工場別の供給割当と顧客向けの確約を分けます。タイ工場で120個、別拠点で80個を製造する計画でも、顧客への確約200個を二重に表示してはいけません。片方が50個遅れたら、残全体と顧客確約を再評価します。工場別の製造指図を削除しただけでは受注残は消えません。受注行、予定行、供給割当、出荷明細をそれぞれ別の粒度で保存する理由はここにあります。

データ移行時にも未出荷残を再計算する

旧Excelから新システムへ「現在の残」だけを移すと、出荷や取消の根拠が切れます。最低限、オープン受注行の注文数量、正式取消、出荷確定累計、未出荷残、予定行と確約版、引当・指図への参照を照合します。移行時点の残を入力値として信じるのではなく、可能な範囲でイベントから再計算し、差分を顧客・営業・倉庫で確認します。旧側が訂正を上書きして履歴がない場合は「検証不能」と明記し、現物、伝票、顧客確認のどれで開始値を承認したか記録します。

切替当日は旧環境で受注改訂と出荷確定を止める時刻を分けて決めます。倉庫がまだ荷物を出しているのに営業だけ先に凍結すると、移行後の出荷累計が古くなります。最終抽出、差分取込、数量保存則の照合、代表顧客への回答試験まで終えてから新環境を正本にします。切替中に緊急出荷が必要な場合の紙伝票、二重登録防止ID、後日再入力の責任者も用意します。こうした移行境界をRFPに書いておけば、ベンダーは単なるマスタ取込ではなく、稼働初日の正しい残を見積もれます。

同じ残数量でも判断が異なる三つの例

説明用に未出荷残がいずれも50個の受注を三件考えます。Aは来月の分納予定が確約済みで在庫も引当済み、Bは本日が確約日なのに部材不足で生産指図が未着手、Cは倉庫で50個をピッキング済みですが品質保留で出荷できません。三件を単に「残50」と並べる画面では、営業が誰へ先に連絡すべきか分かりません。Aは通常監視、Bは計画の再調整と顧客連絡、Cは品質判定と代替ロットの確認が必要です。各行に未履行の理由、次の行動、所有者、期限、顧客通知状態を持たせます。

受注残の優先順位付けでは、残数量の大きさだけでなく、確約日までの時間、顧客との合意、代替供給の有無、契約上の影響を見ます。ただしシステムが自動的に重要顧客へ在庫を移すと、別顧客の確約を破る可能性があります。再引当を提案することと実行することを分け、変更前後の影響を承認者に見せます。アラートの閾値は工場ごとに調整し、毎日大量の通知が出て重要な遅延が埋もれないよう、未処理件数と処理時間も確認します。

RFPには状態遷移と実データ例を付ける

「受注残が見えること」という一行ではベンダーごとに実装が変わります。RFPには受注行、納入予定行、引当、生産指図、出荷明細のサンプルと、正常・例外の状態遷移を添えます。顧客の一注文が複数工場、複数倉庫、複数出荷へ広がる場合も示します。デモでは、受注1,000個→600個出荷→100個取消→残300個→200個引当→150個部分出荷、という一連の操作を同じデータで再現させます。ここで最終残は150個です。これはあくまで試験用の仮定値です。

RFPの回答欄には、標準機能、設定、追加開発、外部連携、現場運用のどこで要件を満たすかを書かせます。「可能」と答えたら、画面、API、帳票、監査ログ、テスト証拠のどれで確認できるかまで記載します。製造現場の負荷を考え、例外発生時に営業、計画、倉庫のどこが次の作業を持つかも明確にします。価格比較はライセンスだけでなく、データ整備、連携、試験、現地教育、初期安定化、将来の変更費まで含めます。

RFPにそのまま入れられる十の質問

1. 受注行の数量保存則をどのイベントで更新し、訂正履歴をどう保持しますか。
2. 部分出荷後の残を、親受注行と納入予定行でどう表現しますか。
3. 顧客要求日、確約日、見込み日、出荷予定日を別に保てますか。
4. 在庫引当と生産指図を残の分割単位へどう紐付けますか。
5. 品質保留や設備停止で確約が危うくなったとき誰に通知しますか。
6. ERP、MES、WMSの出荷確定をどこで一意に決めますか。
7. 再送、重複、逆順、通信断をどう隔離・再処理・照合しますか。
8. タイ語・日本語・英語の顧客回答履歴と承認をどう残しますか。
9. 返品、取消、代替品、分納先変更をどの取引として扱いますか。
10. FAT/SATと稼働後にどの証拠で残の正しさを示しますか。

FAT/SATで試すべき受注残の境界値

FATではテスト環境で数量保存則と状態遷移を確認します。受注0、少量、桁上限、単位換算、部分出荷、超過出荷の拒否、取消、戻し、返品、重複イベント、古い版、逆順イベントを試します。新しい残が負数にならないだけでなく、なぜ拒否・保留されたかを担当者が追えることが重要です。計画数量、引当数量、出荷確定数量をわざと食い違わせ、画面が誤った「出荷可能」を出さないかを確認します。

SATではタイ工場の実端末と担当者を使い、ERP受注、MES指図、WMSピッキング・出荷、営業回答まで通します。夜勤・日勤の引継ぎ、通信断後の再送、ラベル読み取り、複数倉庫、顧客からの急な問い合わせを含めます。テスト用の顧客データでも本番の権限と画面に近い環境を使い、個人情報や機密情報の扱いに注意します。合否票には期待残、実残、差異、イベントID、証拠、確認者、未解決課題の優先度を書きます。

表の数字はすべて説明用の試験値で、合格率の一般基準ではありません。重大な境界ケースは「何%通過」ではなく、すべて通過するまで稼働判断を保留します。軽微な表示不具合を持ち越す場合も、顧客回答を誤らせないことを確認し、所有者と修正日を明記します。

図3は部分出荷と通信断のFAT/SAT試験です。WMSの再送イベントがERP受注残へ一度だけ反映され、残数量と顧客回答が一致することを見せます。

段階導入と初期安定化の出口を決める

対象を全顧客・全工場に一度に広げる前に、部分出荷が頻繁で、関係者を集めやすい一つの製品群と工場でパイロットを行います。ただし、例外を避けた「簡単な受注だけ」では本番の課題が見えません。分納、取消、在庫不足、品質保留、計画遅れ、再送の各シナリオを含めます。初期のExcel並行表を残す場合は、比較期間、正本、入力責任、廃止条件を決め、永久に二重運用しないようにします。

稼働後は、残数量の差異件数、期限超過の未確約残、顧客への再回答、連携エラー滞留時間、手修正件数を日次で追います。これらは「導入したから自動的に改善する」数字ではなく、原因を見つけるための観測点です。月末や棚卸しを経て初めて出る差もあるため、引渡し判定を初日の画面表示だけで終えません。現地担当者が差異を調査し、再処理と顧客通知を行える状態を出口条件にします。

まとめ：残を消さず、約束と実行を一つの受注行へ戻す

製造業の受注残管理システムは、受注数量、出荷確定、取消、未出荷残の関係を守る基盤です。部分出荷のたびに残を再計算し、確約日、引当、生産指図、次の出荷手配を追えるようにします。ERP・MES・WMSの境界とイベントIDを決め、再送や通信断でも二重計上を防ぎ、顧客への回答履歴まで確認できれば、現場で使える状態になります。最初の一歩は、部分出荷した実際の受注を一件選び、営業Excel、ERP、MES、WMSの数字と日付がどこで違うかを図にすることです。

TOMAS TECHでは、タイ工場の受注残・分納・確約納期の現状整理、ERP/MES/WMSのイベント境界、RFPとFAT/SATの設計を支援します。システム製品を決める前の段階でも、受注残管理の導入について相談するから、受注と出荷の流れをお知らせください。

よくある質問

受注残管理は納期管理システムと何が違いますか？

納期管理は調達、生産、出荷を含む納期全体を扱います。受注残管理は、まだ履行していない受注行の数量と確約を、部分出荷や取消後も正しく保持することに焦点を当てます。両者は連携しますが、残数量の正本が曖昧なまま納期ダッシュボードを作っても信頼できません。

部分出荷したら受注残はいくつになりますか？

注文数量から出荷確定数量と正式取消数量を差し引いた数量です。出荷予定、ピッキング、引当、生産完了は残の内訳や供給見込みを変えますが、それだけで未出荷残を減らしません。出荷確定の業務時点を社内で一つに決めてください。

バックオーダーは遅延受注だけですか？

いいえ。計画済み分納の後続行は未出荷残や納入予定行であり、それだけでバックオーダーとは呼びません。供給不足などで残を後日に再手配するときにバックオーダーとして扱う場合があります。確約日を過ぎた残は遅延として別に区分します。未確約、計画どおり、遅延を同じ色で表示しないことが重要です。

受注残のERP・MES・WMS連携で一番重要なのは何ですか？

出荷確定イベントの正本を一つにし、イベントIDと受注行IDで重複・逆順を検知することです。MESの生産完了やWMSのピッキングを出荷確定として二重に加算しない設計が必要です。日次照合と隔離行の再処理も一緒に求めます。

受注残管理システムのFAT/SATでは何を検証しますか？

一件の受注から部分出荷、取消、確約変更、引当変更、通信断、再送まで操作し、数量保存則と顧客回答が整合するかを確認します。FATではロジックと連携の境界値を、SATでは実際の端末・担当者・夜勤・倉庫を含む運用を試します。

参考情報

1. Microsoft Learn, Delivery schedules。受注行を複数の納入予定行へ分ける製品機能の例。
2. Microsoft Learn, Reserve inventory quantities。在庫引当の方法と対象。
3. Microsoft Learn, Direct deliveries。一部納品済み受注の残数量を分割して直送する製品例。
4. Oracle Help Center, Backorder/Partial Ship。部分出荷後の残手配の製品例。
5. Oracle, Ship Order Lines in Shipment Sets。部分出荷と残の扱いを含む製品ガイド。
6. ISA, ISA-95 Standard。企業側と製造側の情報交換の参照枠。

参照元は2026年10月8日に確認しました。本文の数量・日付・試験値は説明用であり、特定製品での実績、法令上の基準、導入効果を示しません。