本部が商品をまとめて発注し、各店舗や現場へ分けて納品したい。卸売サイトでこうした注文を受けるなら、最初に一つの発注と、納品先ごとの指示をどう対応させるかを示します。「複数の住所を入力できます」だけでは、どの商品をどこへ何個届けるのか、送料・納期・請求がどう扱われるのか分かりません。
一括で受けるか、納品先ごとに注文を分けるか
まず現行の受注手順を確認します。一つの注文書で複数の納品先を扱えるのか、納品先ごとに別の注文が必要なのかを、営業と受注担当でそろえます。前者なら「一括発注後、品目と数量を納品先別に指定する」、後者なら「納品先ごとに注文を作成する」と、注文に進む前に案内します。サイトが実際に対応していない方法を、便利そうな見出しだけで約束しないようにします。
一括発注を受ける場合は、注文者と請求先の情報を注文全体に置き、届け先と品目・数量・希望日は納品先ごとに対応させます。例えば同じ商品を二つの店舗へ送るなら、注文全体の数量と、各店舗へ割り当てた数量が合うか確認できる形です。Oracle Commerceの複数配送の説明にも、同一注文の品目を別の住所へ割り当て、送付先ごとに配送方法や費用を確認する例があります。これは機能設計の参考であり、卸売会社の現行システムが同じ操作に対応するという意味ではありません。
送料と納期は、どの単位で確定するかを書く
商品代金が一括でも、配送は納品先ごとに手配する場合があります。送料を一注文でまとめて算定するのか、納品先ごとに算定するのか、地域・荷姿・数量で個別見積りになるのかを、実際の取引条件から確かめます。未確定なら「送料は注文後に確認」のように、確定する段階を明記します。複数納品先があるだけで送料が必ず増える、または無料になるとは書けません。
納期も一つにまとめて約束せず、在庫、加工、配送先、希望日を受注担当がどの単位で確認するか示します。「発注全体を同じ日に発送する」「納品先ごとに回答する」などの決まりは、会社の実運用に合わせます。サイト上では、希望日を入力できることと、その日に納品できることを区別してください。確定前の表示なら、回答予定と変更が必要な場合の連絡方法が分かるようにします。
請求先と請求書の単位は、納品先から推測させない
各店舗へ届けても請求は本部へ一括、という取引もあれば、納品先別の請求書が必要な取引もあります。請求先は誰か、請求書を注文単位・納品先単位のどちらで発行するか、締め日や支払条件を誰が確認するかを、画面の説明と受注処理で一致させます。Microsoft Dynamics 365の請求設定資料でも、受注をまとめる方法と、納品先ごとに請求を分ける方法が別々に示されています。配送先の数から請求書の数を自動的に決めつけないための参考です。
注文確認画面で、受け付けた内容を照合する
注文前の確認には、発注者、各納品先、納品先ごとの商品・数量、未確定の送料・納期、請求先を分けて表示します。納品先を追加・削除したときに数量の割り当てが残っていないかも見ます。受注後のメールや管理画面にも同じ区分を使えば、営業・倉庫・経理が一つの注文を別の意味で読みにくくなります。複数納品先の実際の注文書例が共有されていない段階では、架空の数量や請求条件を見本として公開せず、注文書と担当者の確認で表示項目を確定します。
一括資料請求の記事は複数サービスの比較、卸売のサンプル請求の記事は見本から本注文への進め方が中心です。本稿は、本注文で複数納品先をどう扱うかの案内です。Bämの卸売・商社向けの制作相談では、実際の受注方法を原稿と画面の流れに整理します。複数配送の入力機能や受注システム連携を実装する場合は、別途範囲を確認します。
参考資料
資料確認日：2026年9月26日。個別企業の注文書と配送・請求条件は未提示のため、特定の運用や機能を実施済みとはしていません。
