受注管理システムと出荷を連携させると、注文から出荷指示までが自動で流れます。ただし止まるときは、たいてい設定ではなく運用側の理由で止まります。
商品コードが揃っていない
モールごとに違うコードを使っていたり、同じ商品に複数のコードが振られていたりすると、出荷側でどれを引き当てるか決まりません。連携の設定より前に、コード体系を1つに寄せる作業が必要です。
セット品やバリエーション商品は特に注意が要ります。単品と同じコードで登録されていると、在庫が合わなくなります。
締め時間が現場と合っていない
受注データが流れてくる時刻と、倉庫が当日出荷を確定させる時刻。この2つがずれていると、間に合ったはずの注文が翌日出荷になります。
販売側は「15時までの注文は当日出荷」と表示し、倉庫側は「12時取込分まで」で運用している。こうした食い違いは、連携そのものは正常に動いていても発生します。
例外注文の扱いが決まっていない
同梱依頼、熨斗、分割出荷、住所の後追い修正。自動で流す前提を作ると、これらは全部止まります。止まった注文を誰がどう処理するかが決まっていないと、滞留します。
例外を自動化に含めるのか、別ルートで人が処理するのか。最初に決めておけば、運用は回ります。
連携前にすり合わせたい3点
商品コードの一元化／販売側の表示と倉庫側の締め時間の一致／例外注文の処理ルート。この3つが決まっていれば、連携作業そのものは大きな山になりません。
自動化の範囲を最初から広げすぎない
受注から出荷指示まで、まずはこの区間だけを自動化する。顧客対応や返品処理は手動のまま残す。この形で始めると、問題が起きたときの切り分けが簡単です。
どこから連携するかの考え方は、API連携の「最初のひとつ」を選ぶコツで整理しています。
関連するサービス
本記事のテーマに関わる業務は、フルフィルメント／EC支援のページでご案内しています。個別のご相談も承っております。