作成：Uptech · 更新日: 2026-10-20

注文情報の照合点

注文番号、明細SKU、配送先、支払状況を指定の情報源で確認します。住所変更や二重注文の疑いはそのまま出荷処理へ流さず、止める条件と確認先を決めます。複数チャネルの同じ番号も区別します。

返品から返金までの引継ぎ

返品理由、対象明細、写真など必要な資料を記録します。受付済み、商品受領、検品待ち、返金承認済みを分け、受付だけで返金を約束しません。承認済み操作は結果と実行者を残します。

受注から完了までの状態一覧、返品規定、システム構成、日別件数を準備してください。販売施策によるピークと倉庫側の締切も確認し、連携する作業と体制を個別に見積ります。

ECの受注状態、倉庫管理システムの出荷状態、決済の状態は同じ意味ではありません。「注文受付済み」でも未決済の場合や、EC画面が未発送でも倉庫で出荷準備が進んでいる場合があります。注文ID、出荷ID、決済参照を関連付け、各システムで何を正とするかを決めます。

委託範囲は状態の照合、例外抽出、連絡案、承認済みの更新などへ分けます。在庫引当、出荷停止、取消し、返金は商取引と資金に影響するため、発注側の判断と実行権限を明示します。画面に操作ボタンがあるだけで、実行が許可されたとは扱いません。

以下は架空の注文O-41を使った説明例です。顧客から取消し依頼が届き、EC側では未発送、WMS側では梱包済み、決済は売上確定という想定です。委託先は各状態と取得時刻をそろえ、取消し可否を判断する担当者へ渡します。

発注側が倉庫へ出荷停止を確認し、取消しと返金の範囲を承認した後に、合意した操作または連絡を実施します。出荷停止の確認前に顧客へ取消し完了を約束しません。成果物は注文の更新履歴、承認参照、顧客回答、未完了の返金確認を含みます。

返品では注文、対象商品、数量、理由、受領予定、返送情報を記録し、現物確認や可否判断の担当へ渡します。受付しただけで返金確定にせず、検品結果、返金対象額、方法、承認者を確認します。交換、部分返品、送料の扱いも別の例外として定義します。

返金の操作を含める場合は、重複実行を防ぐ参照IDと実行済み記録を必須にします。操作後の成功、失敗、処理中を確認し、処理中の案件を再実行しないルールを設けます。金額や条件が未確定なら、委託先が顧客の要望から推定して処理しません。

受注、変更依頼、返品、返金の各キューで、新規、完了、取消し、保留の残高を合わせます。市場ごとに締切や状態名が違う場合は共通の状態へ対応付けつつ、元の状態も保持します。日本時間の出荷締切と担当者の確認可能時間を明示し、時刻の取り違えを防ぎます。

検収では注文と商品行の対応、数量、根拠となる状態、承認履歴、顧客への連絡内容を確認します。商品情報の更新や販促設定は別の作業範囲として扱い、受注処理のついでに価格を変更しません。利用するEC、WMS、決済のアカウントは必要な操作権限へ限定します。