販売管理システムと在庫引当の連携：多拠点のズレ・二重引当を防ぐ設計の考え方

◆監修・編集責任者　小園 将隆　2026年10月2日

B2B EC-COLUMN

出荷直前に在庫が足りなくなるのは、在庫の「数え方」がずれているから

受注した時点では在庫があったのに、出荷指示を出す段になって足りない。
別の拠点の受注が、同じ在庫をすでに押さえていた。
販売管理システムと在庫側の数を見比べても、どちらが正しいのか分からない。
こうした食い違いの多くは、現物の在庫、引当済みの在庫、販売できる在庫という3つの数を、システムごとに別々に扱っているところから起きます。
まず、引当を確定するシステムを1つに決めます。
そのうえで、同時更新の検出、再送を無害にするキー、定期的な照合を連携に組み込みます。
リアルタイムかバッチかは、許容できるズレと障害時の戻しやすさで選びます。

現物・引当済み・販売可能を分けて見る

販売管理システムの画面に「在庫あり」と表示されていたので受注を確定し、拠点へ出荷指示を送ったとします。
拠点の担当者から「棚にはあるが、別の注文の分としてすでに押さえてある」と返ってきました。
このとき、どちらかが数を数え間違えたわけではありません。
販売管理が見ていたのは棚にある数で、拠点側が見ていたのは、押さえ済みの分を差し引いた数でした。
同じ「在庫」という言葉で、別の数を見ていたことになります。

この食い違いを解くには、在庫を3つの数に分けて考えます。
1つ目は現物の在庫で、拠点の棚に物理的にある総数です。
2つ目は引当済みの在庫で、受注などのために押さえられ、まだ出荷されていない数です。
3つ目は販売可能な在庫で、新しい受注に回せる数です。
考え方としては、現物から引当済みと、売れない理由のある分を差し引いた残りが販売可能になります。

実際の製品も、この区別を項目として持っています。
ShopifyのAPIでは、在庫の状態として available、on_hand、committed、reserved、damaged、safety_stock、quality_control、incoming を定義しています⁶。
on_hand は拠点に物理的にある総数、committed は注文や下書き注文で引き当てられた数で、committed はShopifyが自動で管理します⁶。
引当済み以外にも、破損品、安全在庫、検品中、入荷予定といった状態が分けられている点に注目してください。
販売可能な数は、引当だけでなくこうした状態の扱い方でも変わります。

Microsoft Dynamics 365 Supply Chain Management の倉庫管理でも、在庫を階層の各レベルについて available physical、available ordered、reserved physical、reserved ordered に分けて保持しています²。
物理的な数と注文ベースの数のそれぞれについて、販売可能と引当済みを別々に持つ構造です。
ただし、この説明は倉庫管理の対象品目に関するもので、対象外の倉庫では挙動が異なります²。

この3つの数が連携の中でどれを指すのかが曖昧だと、2通りのズレが起きます。
1つは、在庫側がすでに引当分を差し引いた数を渡しているのに、販売管理側がそこからさらに自分の引当分を差し引く場合です。
実際より少なく見えるので欠品にはなりにくいものの、売れたはずの受注を断ることになります。
もう1つは、在庫側が現物の総数を渡しているのに、販売管理側がそれを販売可能な数として扱う場合です。
他の受注で押さえ済みの分まで売れることになり、出荷直前に足りないと分かるのはこちらです。

自社システムの項目名との対応づけ

ShopifyやDynamics 365の状態名は、分け方の例として挙げたものです。
お使いの販売管理システムが同じ名前、同じ分け方を持つとは限りません。
「在庫数」「有効在庫」「引当可能数」といった項目が3つの数のどれに当たるかは、自社のシステムで対応づける必要があります。

迷いやすいのは、名前が似ていても中身が違う項目です。
同じ「有効在庫」でも、入荷予定を含めるのか、安全在庫を除くのかは製品によって異なり得ます。
そのため、項目名や画面のラベルだけで判断せず、数の動きで確かめるのが確実です。
たとえば、テスト用の商品で受注を1件登録したときにどの項目が減るのか、出荷を確定したときにどの項目が減るのかを見ます。
受注で減る項目は引当済みか販売可能に関わる数で、出荷で減る項目は現物に関わる数だと見当がつきます。

確かめた結果は、販売管理側の項目、連携先の項目、3つの数のどれに当たるか、の3列で一覧にしておくと、次の判断に使えます。
連携ファイルやAPIの項目と画面の項目が別名になっていることもあるので、両方を並べます。
どの数にも当てはまらない項目や、両システムで定義が食い違う項目が見つかれば、そこがズレの起きやすい場所です。
次の節で扱う「どちらが引当を確定するか」も、この一覧があると具体的に決めやすくなります。

引当を持つのは販売管理か在庫管理か。決め方は「いつ確定したいか」で変わる

受注確定時・手動・納期前の3つの引当タイミング

引当済みの在庫が現物とは別の数だと整理できたら、次は、受注のどの時点で在庫を引当済みへ移すかを決めます。
このタイミングによって、販売可能な数が実際の状況をどこまで反映するかが変わるためです。

OdooのInventory 19.0では、予約方法として3種類を用意しています³。
受注の確認時に引き当てる方法（在庫がすでにある場合のみ）、担当者が手動で引き当てる方法、配送予定日の指定日数前に引き当てる方法です³。
これらは操作の種類ごとに選べます³。
他の製品でも同じ選択肢があるとは限りませんが、引当のタイミングを考える整理としては使えます。

それぞれの方式で起きる困りごとは、仕組みからたどれます。
受注確定時に引き当てる方式は、販売可能な数と実際に回せる数がもっとも近くなります。
その代わり、先に入った受注が在庫を押さえるので、あとから入った得意先の急ぎの受注に回す余地がありません。
手動の方式は、担当者が優先順位を判断できます。
ただし判断を待つ間、その在庫は販売可能に見え続けるため、別の受注が同じ在庫を当てにしてしまいます。
納期前に引き当てる方式は、納期の遠い受注が在庫を長く抱え込まずに済みます。
一方で、引当の前は販売可能な数が多めに見え、納期が近づいてから不足に気づくことがあります。

どれを選ぶかは、在庫が逼迫しているか、優先したい受注があるかで変わります。
在庫に余裕があり、受注間の優先順位を付ける必要がなければ、受注確定時の引当がもっとも単純で、食い違いも起きにくい形です。
品薄の商品で特定の得意先を優先したいなら、手動や納期前の方式を組み合わせる余地があります。
ただし、その場合は販売可能な数が実態とずれる時間帯が生まれる、と理解したうえで選ぶことになります。

タイミングと並んでもう1つ決めることがあります。
どの粒度で引き当てるかです。
Dynamics 365では、引当を予約階層（拠点、倉庫、在庫状態、場所、ライセンスプレートなど）の各レベルで行え、場所などの詳細の決定を後に回せます²。
受注や移動オーダーでは、場所より上の次元で引き当て、場所の決定は倉庫作業に任せる戦略があります²。
この戦略は固定で、ユーザーが設定を変えることはできません²。
つまり引当には、「いつ確定するか」と「どの粒度で確定するか」の2つの軸があり、両方を決めておく必要があります。
粒度は拠点が複数ある場合に特に効いてくるため、後の節で改めて扱います。

引当を一本化する考え方

販売管理システムにも在庫側の仕組みにも引当機能がある場合、両方を使うと何が起きるでしょうか。
販売管理が押さえた数と在庫側が押さえた数が、それぞれ別に存在することになります。
受注をキャンセルして販売管理側の引当を外しても、在庫側の引当が残っていれば、その在庫は売れないままです。
逆に、在庫側で別の出荷に回された在庫を、販売管理側はまだ押さえているつもりでいることもあります。
前の節で触れた「二重に差し引く」「差し引かない」というズレは、こうした二重管理からも生まれます。

そこで提案したいのが、引当を確定するシステムを1つに決め、もう片方はその結果を受け取って表示するだけにする形です。
どちらに置くかは、引当の判断を誰がしているかで考えると決めやすくなります。
受注間の優先順位を営業や受注担当が判断しているなら、販売管理側に置くと判断と確定が同じ場所にそろいます。
棚の場所やロットまで踏み込んで押さえる必要があるなら、在庫側に置くほうが自然です。
Dynamics 365の例のように、受注側は上位のレベルで押さえ、場所は倉庫作業で決めるという分担もあります²。
この場合も、どのレベルの引当をどちらが確定するかは一方に決まっています。

どちらに置くべきかという決まった答えがあるわけではありません。
また、一本化するには、使わない側の引当機能を止めるか、参照専用にできることが前提になります。
これは製品の設定次第なので、まず両システムで引当を無効にできるかを確かめます。
止められない場合は、どちらの値を正とするかを決め、最後の節で扱う定期照合でそろえる運用になります。

在庫数の同期は、リアルタイムかバッチかより「欠落と重複への備え」で決まる

イベント通知で起きる欠落・重複・順序の入れ替わり

引当を確定するシステムが決まったら、その結果を相手側へ伝える手段を選びます。
よく比べられるのは、必要なたびにAPIで相手に問い合わせたり更新したりするリアルタイムの連携、変化が起きたときに相手から知らせてもらうイベント通知、一定の間隔でまとめて取得する定期バッチの3つです。
イベント通知は、Webhook（変更が起きたときに相手のシステムへ自動で送られる通知）として提供されることが多い方式です。

リアルタイムかバッチかという速さの比較に目が行きがちですが、在庫のズレに効くのは、届かなかった更新と二重に届いた更新への備えです。
Shopifyは開発者向けの資料で、Webhookの配信は保証されないと明記しています⁷。
重複はWebhookごとのIDで排除し、順序はヘッダーの発生時刻やデータ内の更新時刻で整理し、欠落には定期的にデータを取得する照合ジョブで備えるよう推奨しています⁷。
つまり、通知は届かないことも、2回届くことも、順番が入れ替わって届くこともある、という前提で設計することになります。

在庫に置き換えると、次のような場面です。
ある受注で在庫を引き当てて通知が送られ、その直後に受注がキャンセルされて2通目の通知が送られたとします。
2通目が先に届き、1通目があとから届くと、受け取った側には引当だけが残ります。
1通目が2回届けば、同じ受注で2回差し引かれます。
1通目が届かなければ、受け取った側では販売可能な数が多く見え、すでに押さえられた在庫を別の受注に回してしまいます。

ここで挙げた配信の性質はShopifyの仕様であり、他の製品のイベント通知が同じ保証水準とは限りません。
ただ、連携先の仕様書に配信の保証、重複、順序についての記述が見当たらない場合は、同じ前提で備えておくほうが安全だと考えます。

条件別の比較表（許容ズレ・再実行のしやすさ・欠落時の影響）

表で判断が分かれるのは、ズレが残る時間と、ズレたあとの戻しやすさが逆向きになる点です。
リアルタイムやイベント通知は反映が早い代わりに、1件ずつの失敗を拾う仕組みが別に要ります。
定期バッチはズレが残る時間が長い代わりに、障害が起きても同じ範囲を取り直せば元に戻せます。
どの方式を選んでも、欠落と重複への備えを省けるわけではありません。

そのため、どれか1つに絞るより、組み合わせるほうが筋が通ります。
Shopifyの推奨も、イベント通知を主に使い、定期的なデータ取得で欠落を補う構成です⁷。
在庫でいえば、在庫が少なく売れ足が速い商品や拠点は、ズレがすぐ欠品や売り越しにつながるので、通知やAPIで早く反映します。
在庫に余裕がある商品は、定期バッチでの反映でも困らないことがあります。
そのうえで、全体を定期的に照合して取りこぼしを拾います。

受注が何件を超えたらリアルタイム、拠点がいくつ以上ならイベント通知、といった線引きを示せる資料は見当たりません。
判断の材料になるのは、1回のズレで何が起きるかと、障害のあとにどの範囲を取り直せるかです。
ズレが出荷の遅れや得意先への謝罪につながるなら、早く反映する方式に寄せます。
ズレても次の照合で直せば済むなら、戻しやすさを優先して定期バッチの比重を上げる考え方もあります。
定期バッチを使う場合は、前回の取得以降に更新されたデータを更新時刻で取り出すようにすると、取得範囲の抜けや重なりを管理しやすくなります⁷。

二重引当は「同時更新」と「再送」で起きる。検出と無害化を連携に組み込む

更新前の数量を指定して競合を検出する

同期の方式を整えても、二重引当につながる場面が2つ残ります。
1つ目は、2つの処理が同じ在庫をほぼ同時に更新する場面です。

たとえば、ある拠点の在庫が残りわずかなときに、販売管理の受注処理と拠点側の出荷確定処理が、ほぼ同時に同じ在庫数を読み込んだとします。
それぞれが読み込んだ数から自分の分を差し引き、その結果で在庫数を書き換えます。
すると、あとから書き込んだ処理の結果が、先に書き込んだ処理の結果を消してしまいます。
帳簿上は1回分しか減っていないのに、現物は2回分出ていく、という食い違いがこうして生まれます。

これを防ぐ仕組みの例が、ShopifyのAPIにあります。
在庫を調整するときに changeFromQuantity として「更新前はこの数のはず」という値を一緒に送ると、現在の値と一致しない場合は CHANGE_FROM_QUANTITY_STALE というエラーで更新が失敗します⁶。
失敗した側は、最新の数を読み直してから計算し直します。
他の処理の更新を上書きする代わりに、競合が起きたことを検出できるわけです。

同じAPIでは、自分のシステムが在庫数の唯一の情報源である場合に、この値に null を渡すこともできます⁶。
裏返せば、競合の検出を省いてよいのは、他に在庫を書き換える処理が無いと言い切れる場合に限られます。
販売管理と拠点側の両方が在庫数を書き換える構成なら、検出は外せません。
前の節で引当の確定先を一本化しておくと、この判断がしやすくなります。

製品によって、この仕組みの呼び名は異なります。
連携先の仕様書では、更新時に現在の値や版番号を指定できるか、楽観的ロックと書かれた項目があるか、といった観点で探します。
Shopifyの仕組みはあくまで同社の在庫調整APIのものなので、連携先が同等の仕組みを備えているかは個別に確かめる必要があります。

一意のキーで再送を無害にする

2つ目は、同じ要求が再送される場面です。
販売管理が在庫側へ引当の要求を送り、通信エラーで応答が返ってこなかったとします。
要求が届いていないのか、処理は済んだのに応答だけが失われたのか、送った側には分かりません。
再送すれば二重に引き当てるおそれがあり、再送しなければ引当が漏れるおそれがあります。

この迷いを無くすのが冪等性（何度実行しても1回実行したのと同じ結果になる性質）です。
AWSの設計資料では、冪等な操作を、再送されても追加の副作用がない操作として説明しています¹。
重複を見分けるために、呼び出す側が一意のトークンを付けて送り、受ける側は同じトークンの要求を重複として扱います¹。
ShopifyのAPIでも、@idempotent(key) という指定により、同じキーの重複リクエストに初回と同じ結果を返します⁶。

AWSの資料は、トークンの記録と更新の処理を、ACIDの性質（途中で失敗しても中途半端な状態を残さないことなど）を満たす1つの処理として行う必要があると述べています¹。
在庫に当てはめると理由が見えてきます。
キーだけ記録して引当が失敗すると、次の再送は処理済みとして扱われ、引当が漏れます。
引当だけ済んでキーの記録が失敗すると、次の再送でもう一度引き当て、二重引当になります。

キーの付け方にも注意が要ります。
再送のたびに新しいキーを作り直すと、受ける側からは別の要求に見え、仕組みが働きません。
受注番号と明細、操作の種類を組み合わせるなど、同じ業務の操作なら同じ値になるキーを使うのが考え方の基本です。

ここで引いたAWSの資料は自社APIの設計原則として書かれたもので、在庫システムの実装を直接示したものではありません。
連携先がキーを受け付けない場合は、連携部分の側で受注ごとに処理済みかどうかを記録し、再送前に確かめる仕組みを持たせる方法も考えられます。
競合の検出と再送の無害化を組み込むことで、二重引当の主な入り口をふさげますが、それだけですべてのズレが無くなるとは言えません。
残るズレを見つけて直す手順は、最後の節で扱います。

複数拠点では、引当の粒度と拠点の決め方を先に決める

拠点・倉庫・場所のどこで引き当てるか

ここまでは、1つの在庫をどう数え、どう更新するかの話でした。
拠点が複数あると、どのレベルで引き当てるか、どの拠点から引き当てるか、拠点間で在庫をどう動かすか、という論点が加わります。
まず、引当の粒度から考えます。

第2節でも触れたとおり、Dynamics 365では引当を予約階層の各レベルで行え、場所などの詳細を後から決められます²。
上位のレベル、たとえば拠点や倉庫で押さえれば、受注の時点で棚の場所まで決める必要はありません。
どの棚から出すかは倉庫の作業で決められるので、作業の柔軟さが残ります。
その代わり、拠点全体の数は足りていても、検品中や破損で出荷できない在庫を除くと足りない、ということが出荷の段階で分かる場合があります。

下位のレベル、たとえば場所まで押さえると、出荷時の想定外は減ります。
ただし、受注処理が棚の配置まで知っている必要があり、棚の移動があるたびに引当を付け替える手間が生じます。
販売管理システムと連携する場合、販売管理は拠点や倉庫のレベルまでを押さえ、場所は在庫側が決める、という分担が1つの形です。
Dynamics 365が受注で場所より上の次元で引き当て、場所を倉庫作業に任せる戦略を持つのも、この分担に近い考え方です²。
ただし、これは同製品の倉庫管理の対象品目での設計例であり、業界の標準を示すものではありません。

粒度を決めるときは、第1節の3つの数をどのレベルで持つかも合わせて決めます。
販売管理が拠点ごとの販売可能数で受注を判断しているのに、在庫側が倉庫や場所ごとにしか数を返さないと、集計の仕方でまたズレが生まれるからです。

複数拠点の在庫で1受注を満たす構成

次は、1つの受注をどの拠点の在庫で満たすかです。
Odoo 15.0の文書では、仮想の倉庫が複数の物理倉庫の在庫を集約し、1つの受注を複数の倉庫の在庫で満たせる構成を説明しています⁵。
同じ文書には、出荷や梱包のゾーンの表示に誤りがあること、2段階・3段階の配送には対応しないことが注意書きとして記されています⁵。
これは古い版の文書なので、現行の版で同じ挙動とは限りません。

集約の考え方を取ると、販売管理からは拠点をまたいだ1つの在庫として見られるので、受注の判断は単純になります。
一方、実際の出荷作業は拠点ごとに分かれます。
1つの受注が2つの拠点から別々に出荷されることを、得意先や配送の手配が受け入れられるかを先に考える必要があります。
また、どの拠点を優先して引き当てるか、足りないときに分納にするか待つかを、システムが自動で判断できるかどうかは製品によって異なります。
この判断を人が行うのか、システムに任せるのかで、引当を確定する場所の選び方にも影響します。

拠点間補充の起点

拠点が複数あれば、在庫の多い拠点から少ない拠点へ移す場面も出てきます。
Odoo 19.0では、各拠点を別の倉庫として設定し、補充元の倉庫を指定して拠点間補充を行います⁴。
補充の起点は、受注をきっかけに移動を作る方式（MTO）か、最小在庫を下回ったときに移動を作る補充ルールのどちらかです⁴。
どちらを使う場合も、製品側で拠点間のルートを有効にしておく必要があります⁴。

起点の違いは、引当の扱いに関わります。
受注をきっかけに移動を作る方式なら、移動中の在庫がどの受注のためのものかがはっきりしています。
ただし、移動が終わるまで出荷はできません。
最小在庫を下回ったときに補充する方式なら、受注より前に在庫が移っていきます。
このとき、移動中の在庫を販売可能に含めるのか含めないのかを決めておかないと、送り出した拠点と受け取る拠点の両方で同じ在庫が数えられたり、どちらでも数えられなかったりします。
Shopifyが入荷予定を incoming という別の状態として持っているように⁶、移動中の在庫を独立した数として扱えるかを確かめておくと、第1節で見た数え方のズレを拠点間で繰り返さずに済みます。

連携を始める前の確認項目と、ズレを見つけて直す運用

連携前の確認項目

ここまでの論点を、連携先の仕様書や設定画面で確かめる順に並べ直すと、次のようになります。
上から順に決めていくと、あとの項目の判断が前の項目の結果に沿ってそろいます。

<ol><li>引当を確定するのはどちらのシステムか。
もう片方の引当機能を止めるか、参照専用にできるか</li><li>連携でやりとりする在庫数が、現物・引当済み・販売可能のどれに当たるか。
項目の定義が両システムで一致しているか</li><li>引当のタイミング（受注確定時・手動・納期前など）と、粒度（拠点・倉庫・場所）</li><li>更新前の値を指定するなど、同時更新を検出する仕組みがあるか</li><li>再送を無害にする一意のキーを受け付けるか。
受け付けない場合、連携部分で処理済みを記録できるか</li><li>イベント通知の配信の保証、重複、順序の扱い。
欠落したときに更新時刻で取り直す手段があるか</li><li>キャンセルや返品のとき、引当がどう戻り、その変化が相手側へどう伝わるか</li></ol>

すべての項目が満たされなくても、連携を諦める必要はありません。
連携先に同時更新の検出が無ければ、更新する処理を1つに絞ることで競合の余地を減らせます。
再送のキーが使えなければ、連携部分で受注ごとの処理済みを記録できます。
どこを製品の機能で守り、どこを連携部分や運用で補うのかが見えていれば、ズレが出たときに原因を探す範囲も絞り込めます。

定期照合と再同期の手順

どれだけ備えても、ズレがまったく出ないとは言えません。
通知の欠落、連携の停止、手作業での修正など、ズレの入り口は残ります。
そこで、ズレを見つけて直す手順を、連携を始める前に決めておきます。
Shopifyも、前回以降に更新されたデータを更新時刻で定期的に取得する照合ジョブで、整合性を保つよう推奨しています⁷。

突き合わせは、在庫の合計だけでなく、状態ごとに行います。
現物と引当済みが別の数として分かれていれば、ズレが現物の差なのか引当の差なのかを切り分けられます。
現物の差であれば、入出荷の記録漏れや棚の数え間違いが疑われ、拠点での実数の確認が必要になります。
引当の差であれば、通知の欠落、キャンセルの反映漏れ、二重の引当といった連携側の原因を順に疑えます。

差異が見つかったときに、どちらの値を正とするかも先に決めておきます。
引当済みの数は、引当を確定するシステムの値を正とするのが筋です。
現物の数は、拠点で実際に数えた値が基準になります。
再同期の最中にも受注は入ってくるので、再同期の更新にも同時更新の検出を使い、照合中に変わった数を上書きしないようにします。
この手順に決まった標準があるわけではないので、担当者が替わっても同じ判断ができるよう、自社の手順として書き残しておきます。

照合の周期は、許容できるズレから逆算して決めることを提案します。
たとえば「当日の受注は当日中に正しい在庫で判断したい」のであれば、少なくとも当日の受注処理に間に合う時点で照合が終わっている必要があります。
決めた周期が合っているかは、照合ごとの差異件数の推移で確かめます。
差異が減っていかないなら、周期を縮めるより先に、分類した原因のうち多いものを連携の側で直すほうが効きます。
照合は、ズレを無くす仕組みというより、ズレを小さいうちに見つけ、どの備えが足りないかを教えてくれる仕組みとして位置づけるとよいでしょう。

在庫の項目が現物・引当済み・販売可能のどれに当たるか、どちらのシステムで引当を確定できるかは、製品の設定や連携仕様を読み合わせないと決めにくい部分です。

現在お使いの販売管理システムと連携先の項目を並べ、どの数がずれやすいか、引当の確定先をどちらに置けるかを一緒に整理できます。無料相談で要件を整理する

要点の整理

軸	基準
在庫の数え方	現物・引当済み・販売可能を分け、連携でやりとりする数がどれかを数の動きで確かめる
引当の確定先	確定するシステムを1つに決め、もう片方は結果を受け取るだけにする
引当のタイミング	在庫の逼迫と優先したい受注の有無で、受注確定時・手動・納期前から選ぶ
同期の方式	許容できるズレと障害時の戻しやすさで選び、通知と定期取得を組み合わせる
同時更新	更新前の値を指定し、現在の値と違えば失敗させて読み直す
再送	同じ操作には同じ一意のキーを付け、キーの記録と更新を1つの処理にする
複数拠点	引当の粒度、拠点の選び方、移動中の在庫の数え方を先に決める
照合	状態ごとに突き合わせ、許容ズレから周期を決め、差異件数の推移で見直す

同時更新の検出や再送のキー、通知の欠落への備えは、連携先が備えていない場合に連携部分や運用でどう補うかの判断が必要になります。 連携前の確認項目に沿って、製品の機能で守れる部分と、連携部分や定期照合で補う部分の切り分けを確かめられます。

よくある質問

販売管理システム側と在庫管理側の両方に引当機能がある場合、どちらを使うべきですか。

どちらが正しいという決まりはありませんが、確定するのはどちらか一方にそろえるのが安全です。
両方で引き当てると、片方の取り消しがもう片方に伝わらず、二重に差し引いたり引当が残ったりします。
受注間の優先順位を営業や受注担当が判断しているなら販売管理側、棚の場所やロットまで押さえる必要があるなら在庫側に置くと、判断と確定が同じ場所にそろいます。
使わない側の引当機能を止めるか参照専用にできるかを、先に設定で確かめてください。

リアルタイム連携が止まったとき、在庫のズレはどう戻せばよいですか。

止まっていた間の更新を、更新時刻を手掛かりに取り直し、両システムの在庫を状態ごとに突き合わせます。
差異が見つかったら、引当済みの数は引当を確定するシステムの値、現物の数は拠点で数えた値を正として再同期します。
停止中に送れなかった要求を再送する場合は、一意のキーを付けておかないと二重に引き当てるおそれがあります。
再同期の最中にも受注は入るため、更新前の値を指定するなどの同時更新の検出も合わせて使います。

キャンセルや返品は、引当済み在庫の戻しにどう反映させればよいですか。

キャンセルは、引当済みの数を販売可能へ戻す操作として、引当を確定するシステムで行い、その結果を相手側へ伝えます。
イベント通知で伝える場合、引当の通知とキャンセルの通知の順序が入れ替わると引当だけが残るので、時刻による順序の整理が必要です。
返品は現物が戻ってくる操作で、すぐに販売可能にするか、検品中のような状態を経てから戻すかを決めておきます。
Shopifyのように検品中や破損を別の状態として持てる製品もありますが、お使いのシステムでどう扱えるかは確かめる必要があります。

拠点ごとに在庫を持たず、1つの在庫として扱うことはできますか。

複数の拠点の在庫を集約して、1つの在庫のように扱う構成はあります。
Odoo 15.0の文書では、仮想の倉庫で複数の物理倉庫の在庫を集約し、1つの受注を複数の倉庫の在庫で満たす方法を説明していますが、2段階・3段階の配送に対応しないといった注意書きもあり、現行の版で同じとは限りません。
集約すると受注の判断は単純になりますが、出荷作業は拠点ごとに分かれるため、1つの受注が別々に出荷されることを受け入れられるかが判断の分かれ目になります。

連携先の仕様書では、最初にどの項目を見ればよいですか。

まず、やりとりする在庫数の定義です。
渡される数が現物なのか、引当済みを差し引いた数なのか、安全在庫や入荷予定を含むのかが分からないと、その後の設計がすべて揺らぎます。
次に、引当をどちらで確定できるか、更新前の値を指定して同時更新を検出できるか、再送を無害にする一意のキーを受け付けるか、イベント通知に配信の保証や重複・順序の扱いの記述があるかを順に見ます。

1. 1　出典：Amazon Web Services「Making retries safe with idempotent APIs（Amazon Builders’ Library）」（2026年確認）
2. 2　出典：Microsoft「Reservations in Warehouse management（Dynamics 365 Supply Chain Management）」（2026年）
3. 3　出典：Odoo S.A.「Reservation methods（Odoo 19.0 documentation）」（2026年確認）
4. 4　出典：Odoo S.A.「Inter-warehouse replenishment（Odoo 19.0 documentation）」（2026年確認）
5. 5　出典：Odoo S.A.「Sell stock from multiple warehouses using virtual locations（Odoo 15.0 documentation）」（2026年確認）
6. 6　出典：Shopify「Manage inventory quantities and states（Shopify developer docs）」（2026年確認）
7. 7　出典：Shopify「Webhook best practices（Shopify developer docs）」（2026年確認）