この記事の要約
WMSと基幹システムの連携では、つなぎ方より先に、受注・在庫・出荷実績ごとに、業務上の確定記録と更新責任をどちらが持つか（正本）を決めます。受け渡す向き・きっかけ・方法、コードと単位の対応、更新のタイミング、照合・訂正・取消・再送の担当も決めます。つなげられるかは、相手の仕様を確かめてから判断します。
WMS（倉庫管理システム）と基幹システムをつなぐ前に、受注・在庫・出荷実績のそれぞれについて、どちらのシステムが確定記録と更新責任を持つか（正本）を決めます。あわせて、いつ・何を・どの形で渡すか、ずれたときに誰がどう直すかも決めます。APIを使うかファイルを受け渡すか、CSVなどの形式やEDIの取り決めをどうするかは、相手の仕様とあわせて選びます。
この記事は、WMSの導入や入れ替えで、販売管理などの基幹システムや荷主のシステムとつなぐことになった発注者向けの確認メモです。技術的な手順ではなく、開発会社や相手の担当者と決めておきたいことを、独自の整理例として紹介します。倉庫の中でのハンディ端末の操作ではなく、システムどうしのやり取りに絞ります。
受け渡すデータを書き出す
最初に、システムの間で受け渡すデータを並べます。データごとに、どちらからどちらへ渡すか（向き）、何をきっかけに渡すか、どの方法と形式で渡すかを書き出します。次の表は、向きときっかけの整理例です。実際の分け方は、会社や相手のシステムによって変わります。
データ | 向きの例 | きっかけの例 |
|---|---|---|
商品などのマスタ | 基幹→WMS | 登録や変更をしたとき |
受注（出荷指示） | 基幹や荷主のシステム→WMS | 受注が確定したとき、決まった時刻 |
入荷予定 | 基幹→WMS | 発注が確定したとき |
入荷実績 | WMS→基幹 | 検品を終えて確定したとき |
出荷実績 | WMS→基幹や荷主のシステム | 出荷を確定したとき、締めの後 |
在庫 | WMS→基幹 | 決まった時刻、求められたとき |
参考として、Oracle社が公開している倉庫管理製品の資料（25D版、2026年11月11日確認）でも、WMSに入ってくる情報、WMSから出ていく情報、求めに応じて取り出す情報を分けています。つなぐ方法やデータの形式も、分けて説明しています。これは一つの製品の例で、すべてのWMSに共通する決まりではありません。それでも、向き・きっかけ・方法を分けて確かめる考え方は参考になります。
方法と形式は、この表ができてから、相手の仕様を見て決めます。OuverのWMS開発で扱う連携（API・CSV・EDIなど）の範囲も、あわせてご覧ください。
正本をどちらに置くか決める
ここでいう正本とは、その情報について業務上の確定した記録を持ち、更新する責任を持つ側として、関係者で合意したものです。正本だからといって、その数がいつも倉庫の実物と同じだと保証されるわけではありません。食い違ったときに、どちらの記録をもとに確かめて直すかを決めておくための約束です。
分け方の一例として、受注は基幹システムを正本とし、棚ごとの在庫や出荷実績はWMSで確定してから基幹システムへ渡す、という形があります。物流受託では、荷主のシステムが受注の正本になることもあります。どれが正解ということはなく、業務の流れと責任の分け方で決めます。
在庫は特に注意が必要です。「在庫」という言葉が、棚にある実際の数、引当済みの数、出荷できる数、会計で使う数など、違う意味で使われていることがあるためです。どの意味の在庫を、どの時点の数として受け渡すかを、先にそろえます。
また、数が食い違ったときに、原因を確かめないまま、どちらかの数でもう一方を上書きしない、という約束も決めておきます。上書きすると、ずれた原因が分からなくなるためです。
コードと単位の対応を決める
商品コード、荷主コード、倉庫や棚の場所のコード、取引先のコードは、WMSと基幹システムで同じとは限りません。同じ商品でも、片方は荷主ごとに別のコードで持ち、もう片方は1つのコードで持つ、ということもあります。
そこで、コードの対応表をどちらで持つか、新しい商品・廃番・内容の変更をどちらで先に登録し、いつ相手に渡すかを決めます。順番が決まっていないと、WMSに受注が届いたのに商品が登録されていない、といったずれが起きることがあります。
単位と入数も同じです。基幹システムはケース、WMSはバラで数えている場合、どちらで換算するか、入数が変わったときにどちらを先に直すかを決めます。
この対応は、最初の一回だけのデータ移行とは違い、稼働した後もずっと続く作業です。Excelなどから最初にデータを移すときの注意点は、次の記事で整理しています。
コラムExcelからシステムへのデータ移行：移す前のデータクレンジングと、隠れたルールの見つけ方
渡すタイミングと、差分か残高か
次に、いつ渡すかを決めます。確定したらそのつど渡す、決まった時刻にまとめて渡す、締めの後に一日分を渡す、などの選び方があります。速く渡すほど良いとは限りません。受け取る側の業務が、その情報をいつ使うかで決めます。
出荷の締めと受注の受付の境目にも注意します。締めの後に入った受注を当日と翌日のどちらの分として扱うか、出荷実績をどの日付の実績として渡すかを、両方のシステムで同じ決まりにしておきます。
渡し方には、差分と残高があります。差分は変わった分だけを送る方法で、残高はその時点の数を送る方法です。差分は変化のあった分を対象にできますが、受信漏れや二重反映があると、ずれが残り続けます。残高はその時点の全体の数を比べやすい一方、送った時点と実際の物の動きとの時間差に気を付ける必要があります。受け取った残高で数を置き換えるのか、比べるだけにするのかも決めておきます。
どちらが良いかは、業務と相手の仕様によって変わります。差分で日々の動きを渡し、決まった時点の残高で照合する、という組み合わせもあります。次の節の照合とセットで決めましょう。
照合・訂正・取消・再送を決める
つないだ後も、WMSと基幹システムの数がずれることはあります。ずれを見つけて直す手順を、稼働前に決めておきます。次の表は、決めておきたいことと担当の整理例です。
場面 | 決めること | 担当の例 |
|---|---|---|
毎日の照合 | 何を、どの単位（件数・数量など）で、いつ比べるか | 業務担当、情報システム担当 |
出荷後の取消・訂正 | どちらのシステムで入力し、相手にどう伝え、元の記録をどう残すか | 業務担当、開発会社 |
届いたか分からないときの再送 | 再送前に送信記録と相手の受付・反映記録を照合する手順と、二重反映を防ぐ見分け方 | 開発会社、相手システムの担当 |
相手のシステムが止まったとき | 待つか、手作業で進めて後で合わせるか | 業務担当、相手システムの担当 |
出荷後の取消では、実際の物の動きと、記録の訂正を分けて考えます。荷物が倉庫に戻ってくるなら、返品として受け入れる作業が要ります。荷物は出ていて、数量の入力だけが違っていたなら、記録の訂正です。どちらに当たるかで、WMSでの作業も、基幹システムに渡す内容も変わります。
表の担当は一例です。業務担当、情報システム担当、開発会社、相手システムの担当（荷主やベンダー）のうち、誰がずれを見つけ、誰が直すかを、会社ごとに決めてください。
ハンディ端末の通信が切れたときや、同じ商品を二度読み取ったときの扱いは、倉庫の中の操作として次の記事で整理しています。
コラムWMSとハンディ端末の導入前に決めること｜読み取りの単位と例外の扱い方
確認メモにまとめる
ここまでの内容を、データごとに確認メモにまとめます。項目の例は、データの種類、正本、向き、きっかけ、差分か残高か、照合の方法、訂正の入れ方、担当です。決まっていない項目は「未確認」と書いて残します。
つなげられるかどうかは、製品名だけでは判断できません。相手システムの仕様、使える権限、データの形式、受け渡しの頻度を確かめてから判断します。確認メモがあると、相手の担当者に何を聞けばよいかがはっきりします。
稼働の日に、今の仕組みから新しい仕組みへどう切り替えるかは、次の記事で説明しています。
連携の相談前に整理しておくこと
Ouverは、WMSの個別設計や既存WMSの改修とあわせて、API・CSV・EDIなどによるほかのシステムとの連携も扱っています。つなげられるかは、相手システムの仕様・利用権限・形式・頻度を確かめてから判断します。くわしくはWMS開発のページの連携の項目を、費用の考え方と最新の条件は同じページの費用の項目をご覧ください。
ご相談のときは、分かる範囲で次のことを教えてください。
- つなぎたい相手（基幹システムや荷主のシステムなど。製品名が分かれば）
- 今のやり取りの方法（手入力・CSV・紙など）
- 受け渡したいデータ
- 困っているずれや手作業
- 導入したい時期の目安
出典・参考資料
- 株式会社Ouver 倉庫管理システム（WMS）開発（確認日：2026年11月11日）
- Oracle公式資料（25D）倉庫管理 Overview of Integration Types（確認日：2026年11月11日）
