OMS–WMS連携：注文送信と例外処理のためのフィールドマッピング

率直に言います。OMS–WMS連携がうまくいっているセラーを、私はほとんど知りません。注文がOMSを出るのに、倉庫は「届いていない」と言う。倉庫は「出荷した」と言うのに、バイヤーは「何も届いていない」と言う。両方のシステムは緑色で、セラーは悪いレビューと返金と送料を全部被る。

私は越境ECを5年やってきました。最初の3年は小さな自社倉庫を運営し、物量が追いつかなくなったのでSeptember 2024にロサンゼルスの3PLに移しました。OMSは同じ、新しいWMS——そして最初の1週間で、リアルマネーで払った授業料分の教訓を得ました。

最初の1つはSKUマッピングでした。

800+のSKU。稼働前にリストをエクスポートして、3PLにWMSで商品マスタを作ってもらいました。簡単そう。1週目：100+件の注文が「pending」のまま詰まる——送信自体は成功なのに、WMSでSKUが見つからない。700件ほどは作られていて、残りの100+件は直近2か月で増えた新商品で、私のエクスポートに入っていなかった。例外レポートで気づくまで注文が2日間放置、ちょうど秋冬SKUが伸び始めるタイミング。100+件の注文が2日遅れで出荷、カスタマーサービスは1週間ずっと怒鳴られっぱなし。

厳しい教訓：SKUマッピングテーブルは99%ではなく100%突合が必要。OMSから全SKUをエクスポートしてWMSの品目コードとvlookup——1行でも欠けたら稼働なし。そして鉄則：WMSにSKUマッピングができるまで、その商品の販売ページは絶対に公開しない。マッピングが先、販売ページが後。

OMS WMS連携はフィールドマッピングテーブルから始まる

OMSからWMSへの注文送信は、本質的にはフィールドマッピングテーブルであり、連携障害の90%はそこに住んでいます。OMS WMS連携のフィールドマッピングに関するガイドの多くはテーブルで終わります。テーブルは簡単な部分で、セラーがお金を失うのは例外処理です。こちらが現在のバージョンで、最後の列は私が自腹で痛い目を見た箇所をマークしたものです：

OMSフィールド	WMSフィールド	壊れる箇所
マーケットプレイス注文番号	外部注文参照番号	両システムで注文番号が異なる——両方送る。WMSは外部参照番号で重複排除すること
OMS注文番号	出庫注文番号	ここにマーケットプレイス注文番号を使うな——1人のバイヤーが1日に2回注文したら衝突する
SKU	品目コード	マッピングテーブルは先に存在すること。「マッピング作成」は新商品ローンチの必須ステップ
数量	ピッキング数量	単位！ケース売りと単品売りはWMS内で単一単位に解決しなければならない
受取人／住所／市／州／郵便番号／電話	出荷先情報	住所2行目（部屋番号・棟・スイート）は必ず送る——連携の多くは1行目しか送っていない
出荷方法	運送会社＋サービスコード	「Standard」のような表示名は送るな——事前に合意したコードを送る
バイヤーメモ	梱包メモ	独立したフィールド——住所行に詰めると住所検証が失敗する
店舗／出店者	出店者コード	複数店舗が1つのWMSを共有する場合は必須。さもないと在庫が違うオーナーから引き落とされる

一番ズルいのは数量の単位です。うちのバラエティパックはケース売り——1ケース12個。OMSは「ケース」で送り、WMSのマスタは「個」になっていて、最初の20件の注文が20ケースではなく20個をピッキング。バイヤーは1個受け取ってケース全部だと思い込み、あちこちで紛争を開く。「単位変換」列を追加してバラエティパック全部にフラグを立てました。以来、起きていません。

出荷方法名は送らず、コードだけ。最初は「standard」と「expedited」で始めた——3PLは運送会社を5社使い、各社が独自の「standard」を持ち、WMSはどれを指すか判別できなかった。今は両者がコードテーブルを共有し、OMSはGROUND_HOMEのようなコードを送る。言い争いは90%減りました。

梱包ステーションでタブレットで注文を確認する倉庫作業員

OMS WMS連携で毎週見る4つの例外

この表をピン留めしています——症状、自動処理、人が入るタイミング。4種類でほぼ全部カバー：

例外	症状	自動処理	人が入るタイミング
未マッピングSKU	WMSで注文がpendingのまま詰まる	保留＋例外レポートに追加	当日：マッピングを追加、手動で再送信
在庫不足	履行に足りる在庫がない	注文全体を保留、またはルールに従い確保分だけ出荷	4時間経っても未解決——CSがバイヤーに連絡
住所不良	検証失敗／荷物の返送	保留	手動で住所を確認、修正、再送信
重複送信	同じ外部参照番号が2回来る	WMSが外部参照番号で重複排除して破棄	対応不要——ただし破棄件数はレポートに表示すること

重複送信は専用の話がある——Black Friday 2024。うちの送信はリアルタイムAPI。ネットワークが一瞬詰まり、OMSがタイムアウトしてリトライ。外部注文番号で重複排除していなかったので、WMSは出庫注文を2件作り、夜勤が両方出荷。1人のバイヤーは2個口受け取って1個返品——送料＋商品代でその注文に$40近くかかった。その夜は十数件の重複。今でも心が痛い。

そこから2つの鉄則が生まれた。1つ目：WMSはマーケットプレイス注文番号で重複排除する——冪等性は契約に入れる、握手だけにしない。2つ目：稼働前に自分でテストする、同じ注文を10回再送信。出庫注文が1件なら合格、2件なら3PLに戻して直してもらう。

住所不良についても一言。米国の住所2行目——apt、unit、suite——は、マッピングが1行目しか送らないため常に落ちる。アパート向けの一括出荷が部屋番号なしで出て、配送失敗で返送：往復7日、一つ星レビュー一直線。今は4つ全部が揃わないとOMSが送信をブロックする——受取人、住所行（2行目含む）、郵便番号、電話。

直感に反する結論：フィールドが少ないほど、問題も少ない

多くの人は、フィールドが多いほど連携が良くなると思って、クーポンコードまで全部送ろうとする。私もそう思っていた、痛い目を見るまでは。追加のフィールド1つが新たな障害点になる。

WMSは実行する側。必要なのは受取人、中身、数量、出荷方法、梱包メモだけ。クーポン情報や広告ソース——WMSは使えず、1つの不正なフィールドで注文全体が失敗しうる。ペイロードを30+フィールドから18に削減したら、例外率は半分になった。

関連するトレードオフ：リアルタイム送信vs.定期バッチ。リアルタイムは気持ちいい——数秒で注文が倉庫に届く——でもネットワークが一瞬詰まると注文が失われたり重複したりする、だいたい深夜2時、誰も見ていない時間帯に。バッチ（15分ごとのファイル）は地味だが、リプレイも突合もできる。壊れたらファイルを実行し直す。私の設定：リアルタイム送信＋両システムの注文番号を照合する突合ジョブを15分ごと。OMSにあるのにWMSにない注文は自動再送信。両方のメリットが欲しければ、両方やればいい。