販売管理と在庫の連携で受注側の在庫引当を決める：引当タイミング・連携方式・例外処理の選び方

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

B2B EC-COLUMN

受注を入れたのに在庫が合わない原因は、引当と実在庫が別々に動くこと

取引先から注文の電話が入り、販売管理の画面では在庫があるのに、倉庫に聞くと出せる数が足りない。
納期をその場で答えられず、出荷の段になって欠品が分かる。
こうしたずれの多くは、受注で押さえた数量（引当）と実在庫が別々のタイミングで更新され、ECや電話など複数の受注窓口が同じ在庫を見ていることから生じます。
判断の物差しは、実在庫から引当分を差し引いた有効在庫です。
そのうえで、いつ押さえるか、即時連携かバッチか、引当不足や取消のときに誰が戻すか、ロットや期限で自動引当が効くかを、受注量と窓口の数に合わせて選びます。

実在庫と有効在庫の違い

在庫の数には、少なくとも二つの意味があります。
一つは倉庫の棚に物として置かれている実在庫、もう一つはそこから受注で押さえた分を差し引いた有効在庫です。
在庫引当とは、現在ある在庫数から受注した分を差し引いておくことで、手元の在庫から引当分を引いた残りが有効在庫数だと説明されています⁶。
同じ解説では、在庫が100個あっても有効在庫は60個という例が挙げられています⁶。

この二つが別の数になるのは、減るタイミングが違うからです。
受注を登録して引当が走った時点で有効在庫は減りますが、棚の商品はまだ動いていないので実在庫は減りません。
実在庫が減るのは、出荷指示を経て実際に商品が出ていったときです。
受注から出荷までのあいだ、実在庫と有効在庫の差は「すでに約束したが、まだ出ていない分」を表しています。

受注担当者が取引先から「あと何個出せますか」と聞かれたときに答えるべきなのは、有効在庫のほうです。
先の例でいえば、棚に100個あっても、新しい注文に回せるのは60個までです⁶。
販売管理の画面が実在庫だけを表示していたり、在庫側の引当結果が販売管理へ戻ってくる前の数字を見ていたりすると、答えた数量と出せる数量が食い違います。
出荷の段になって欠品が見つかったときは、この食い違いが受注時点で見えていなかった可能性を最初に疑います。

なお、この解説はEC向けの一般的な説明で、引当をどの時点で行うかまでは定めていません。
受注登録の瞬間に引き当てるのか、承認後か、出荷指示の直前かは、システムと運用によって変わります。
この時点の違いが、引当設計の中心になる判断です。

複数の受注窓口があるとなぜずれるのか

受注の入口が一つなら、有効在庫を一か所で減らしていけば済みます。
ずれが大きくなりやすいのは、自社のECサイト、電話やFAXを受けて販売管理へ入力する窓口、取引先専用の発注画面など、入口が複数ある場合です。
それぞれの窓口が同じ品目の在庫を見て注文を受けますが、ある窓口で押さえた数量が、ほかの窓口の画面に届くまでには時間差があります。

たとえば、ECで受けた注文が在庫側で押さえられた直後に、電話を受けた担当者が販売管理の画面を開いたとします。
その時点で販売管理がまだECの引当を受け取っていなければ、画面には押さえられる前の在庫が表示され、担当者はその数を前提に納期を答えてしまいます。
同じ在庫を二つの窓口が別々に約束する二重引当は、こうした時間差の中で起きます。

Microsoft Dynamics 365 Supply Chain Managementの資料は、複数の受注システムが同時に注文を受ける構成について、各システムが即時のAPI呼び出しで在庫の単一の情報源を参照することで二重売りを防ぐ考え方を示しています¹。
これは同製品の在庫可視化サービスを前提にした説明で、ほかの販売管理システムで同じ仕組みが使えるとは限りません。
ただ、論点そのものは製品を問いません。
窓口が複数あるなら、どの窓口も同じ有効在庫を見て押さえるのか、それぞれが自分の画面の数字で押さえるのかで、二重引当の起きやすさが大きく変わります。

▼ 図の内容を文字で読む

1. 在庫がある状態：実在庫と有効在庫が同じ
2. 受注を登録して引当：有効在庫が減る。実在庫は変わらない
3. 出荷指示：押さえた在庫を出荷作業へ回す
4. 出荷：実在庫が減る

受注から引当まで、販売管理と在庫の間で何を渡し、何が戻るのか

販売側から渡す項目と戻る項目

受注担当者が納期を即答できるかどうかは、販売管理から在庫側へ何を問い合わせ、何が返ってくるかで決まります。
受注担当者が知りたいのは「この品目を、この数量、この日までに出せるか」です。
問い合わせる側が品目と数量しか渡さず、在庫側が「ある・ない」だけを返す連携なら、納期の答えは担当者の推測に頼ることになります。

大規模なERPの例として、SAPのATP（Available-to-Promise、約束可能な在庫を照会する機能）があります。
英語版の公式ヘルプでは、ATPは販売や生産計画からの照会に応答する機能で、現在の在庫状況に加えて将来の入荷予定や並行する受注を考慮し、数量と日付を含む確定案を返すと説明されています³。
注目したいのは、返ってくるのが単なる在庫数ではなく、「いつ、何個なら約束できるか」という組み合わせだという点です。
これはSAP ERP向けのヘルプの記述で、画面名や設定の方法は製品ごとに異なります。

中小企業の販売管理と在庫管理を連携する場合、ここまでの判定を備えていない構成もありえます。
その場合でも、往復の中身を次のように分けて考えると、自社の連携で何が欠けているかが見えてきます。

<ul><li>販売管理から渡すもの：品目、数量、希望日、どこの倉庫の在庫を見るかの指定</li><li>在庫側で照らし合わせるもの：現在の在庫、入荷予定、ほかの受注ですでに押さえられた数量</li><li>販売管理へ戻すもの：押さえられた数量、押さえられなかった数量、約束できる日付</li></ul>

戻る項目に「押さえられなかった数量」と「日付」が含まれていれば、受注担当者はその場で、一部だけ先に出すか、全量そろってから出すかを取引先と相談できます。
逆に、戻るのが「引当成功・失敗」だけなら、失敗したときに何個足りないのか、いつ入るのかを、担当者が在庫の画面や倉庫への問い合わせで調べ直すことになります。
連携の項目を一つ増やすかどうかは、この調べ直しがどれだけ発生しているかで判断できます。

引当の単位（品目・倉庫・次元）の決め方

往復の中身と同じくらい結果を左右するのが、どの単位で在庫を押さえるかです。
同じ品目でも倉庫が二つあれば、どちらの倉庫の在庫を押さえたかが分からないと、出荷する倉庫で足りないことがあります。
色やサイズで在庫が分かれる商品なら、品目コードだけで押さえても、実際に出せる色・サイズが残っているとは限りません。
こうした区分を、ここでは在庫の次元と呼びます。

引当の単位を細かくするほど、受注時に答えた内容と出荷時の現物は一致しやすくなります。
一方で、受注を入力する時点で倉庫や色・サイズまで決まっていなければ、その単位での引当そのものができません。
電話で受けた注文の出荷元を担当者がその場で決められない運用なら、受注時は品目単位で押さえ、倉庫の割り当ては出荷指示の段で決めるという分け方もあります。
その場合、品目全体の有効在庫は足りていても、特定の倉庫では足りないという状況が、出荷指示のときに初めて見つかります。

どの単位を選ぶかは、受注担当者が受注時点で何を決められるかと、倉庫の数や商品の分かれ方によります。
倉庫が一つで色・サイズの区分もない商品が中心なら、品目単位の引当で足りる場面が多いでしょう。
複数倉庫から出荷し、取引先ごとに出荷元が決まっているなら、倉庫まで含めて押さえておかないと、販売管理の画面の有効在庫と出荷元の現物が食い違い続けます。
ロットや期限が絡む場合の単位は、後の節で改めて扱います。

▼ 図の内容を文字で読む

1. 販売管理から渡すもの：品目、数量、希望日、見る倉庫
2. 在庫側で照らし合わせるもの：現在の在庫、入荷予定、ほかの受注ですでに押さえられた数量
3. 販売管理へ戻すもの：押さえられた数量、押さえられなかった数量、約束できる日付

引当はいつ確定させるか：受注時・出荷指示時と、仮押さえの考え方

受注時に押さえる型と、出荷指示時に引き当てる型

引当のタイミングは、欠品を防ぐことと、在庫を寝かせないことの綱引きです。
受注登録の時点で押さえれば、その在庫はほかの注文に回らなくなり、受注担当者が答えた納期を守りやすくなります。
その代わり、出荷日が先の注文が多いと、まだ出ない注文のために在庫が長く拘束され、目の前の別の注文に「在庫なし」と答えることが増えます。

出荷指示の直前まで引当を待つ型では、拘束期間は短くなります。
出荷する日に在庫を押さえるので、先の注文が在庫を抱え込むことはありません。
しかし受注時点では何も押さえていないため、受注担当者が答えた納期は「その時点で在庫があった」という事実にすぎず、出荷日までに別の注文が先に在庫を使えば欠品になります。

この二つを組み合わせる考え方もあります。
受注時には軽く押さえて二重引当を避け、出荷指示の段階で改めて正式に引き当てる型です。
ただし、軽く押さえた状態と正式な引当とのあいだに差が生じたとき、それを誰が見て直すのかを決めておかないと、二段階に分けた意味が薄れます。

型を選ぶときの手掛かりは三つです。

<ul><li>欠品の許容度：一部だけ遅れて届くことを取引先が受け入れるか</li><li>納期の約束の強さ：受注時に答えた日付を、取引上どこまで守る必要があるか</li><li>在庫を拘束できる期間：受注から出荷までの日数と、品目の回転の速さ</li></ul>

欠品の許容度が低く、受注時の回答がそのまま取引先の予定に組み込まれるなら、受注時に押さえる型か、両方を使う型が向きます。
受注から出荷までが短く、在庫の回転が速い品目なら、出荷指示時に引き当てる型でも欠品の不安は小さくなります。
これは判断の筋道を示す編集部としての整理で、どの型で欠品がどれだけ減るかを測った結果ではありません。

仮引当・本引当という言葉を自社のシステムで読み替える

社内で「仮引当」「本引当」という言葉を使っていても、それが何を指すかは製品によって違い、製品をまたいで通じる共通の定義があるわけではありません。
他社の説明やベンダーの資料を読むときは、言葉そのものより、「その引当がほかの注文から在庫を守るか」「出荷指示に進む条件になるか」で読み替えるほうが確実です。

Microsoftの例では、受注時に在庫可視化サービスへ送る軽い予約（ソフト予約）と、販売管理側で行う物理的な引当を分けています。
ソフト予約は在庫サービス側で可否が検証され、注文行が物理引当の状態になると自動で相殺されます¹。
ソフト予約をしないまま物理引当に進めた場合に、止めるか、警告を出すか、そのまま通すかも設定できます¹。
対象はDynamics 365 Supply Chain Managementの在庫可視化連携で、既定の設定は版によって異なります。

出荷管理のクラウドサービスであるロジクラは、出荷予定の段階で在庫を引き当てたうえで出荷を保留する機能を提供しています⁴。
一部の商品だけが引き当てられた状態で保留されることもあります⁴。
注意したいのは、保留していた出荷を開始すると改めて引当が走り、ロットや期限の結果が変わることがある点です⁴。
保留の時点で押さえた中身が、そのまま出荷の中身になるとは限りません。
また、この出荷保留機能は外部連携には対応していないと案内されており、販売管理から連携して使う前提の機能ではありません⁴。

二つを比べると、同じ「先に押さえる」でも、Microsoftは軽い予約が正式な引当に置き換わる仕組み、ロジクラは出荷を開始するときに引当をやり直す仕組みです。
自社のシステムで「仮引当」と呼んでいるものがどちらに近いかを見極めておくと、受注時に答えた内容が出荷時に変わりうるかどうかが分かります。
販売管理のマニュアルやベンダーへの問い合わせで確かめたいのは、仮の引当がほかの窓口からの注文をブロックするか、正式な引当へ進むときに数量やロットが再計算されるか、仮の引当が残ったまま放置されたときに誰が気付けるか、の三点です。

▼ 図の内容を文字で読む

• 受注時に押さえる
  • 答えた納期を守りやすい
  • 出荷日が先の注文が在庫を長く拘束する
• 出荷指示時に引き当てる
  • 拘束期間が短い
  • 出荷日までに別の注文が使えば欠品になる
• 両方を使う
  • 受注時に軽く押さえ、出荷指示で正式に引き当てる
  • 二段階の差を誰が見て直すかを決める

即時連携と定期連携で、引当の正確さと運用負担はどう変わるか

即時連携の前提と効果

引当のタイミングを決めても、販売管理と在庫側の数字がいつ一致するかは、連携の方式で決まります。
受注のたびに在庫側へ問い合わせて結果を受け取る即時連携なら、受注担当者が見る有効在庫は、ほかの窓口で押さえた分を反映した数字になります。
一定間隔でまとめてやり取りする定期連携（バッチ）では、次の同期まで、ほかの窓口の受注が画面に表れません。

Microsoftの資料では、注文全体を即時のAPI呼び出しで予約する方式と、バッチで予約する方式を選べます¹。
複数窓口の二重売りを防ぐ説明は、窓口ごとに即時の呼び出しで同じ在庫を見る構成を前提にしています¹。
言い換えると、窓口が複数あって二重引当を避けたいなら、どの窓口も受注の瞬間に共通の在庫へ問い合わせられることが条件になります。

即時連携にも前提があります。
受注入力のたびに在庫側への問い合わせが発生するため、在庫側のシステムが応答しないときに受注入力をどうするかを決めておかなければなりません。
問い合わせに失敗したら受注を止めるのか、受注だけ登録して後で引き当てるのかで、窓口の担当者の動き方が変わります。
Microsoftの例でソフト予約なしの扱いを止める・警告・通すから選べるのは、この判断を設定として持たせたものと読めます¹。

バッチ連携で増える確認作業

Microsoftの資料では、バッチによる予約は、Supply Chain Managementと在庫可視化サービスをおよそ1分に1回同期する処理として説明されています¹。
1分は短く感じますが、ECのセールや取引先からのまとまった発注で受注が集中すると、その間に複数の窓口から同じ品目への注文が入る可能性があります。
受注の山がどれくらい急か、同じ品目に複数の窓口から注文が重なるかが、バッチで足りるかどうかの分かれ目です。
なお、この間隔は同製品のバッチ予約の仕様で、他製品やCSVファイルでの連携に当てはまる値ではありません。

バッチ連携では、反映の遅れに加えて、失敗の確認という作業が増えます。
Microsoftの例では、失敗した予約や失敗した相殺を確認画面で見る運用になっています¹。
即時連携なら受注入力の場で「押さえられなかった」ことが担当者に分かりますが、バッチでは受注を入力し終えた後で失敗が起きます。
失敗に気付く人が受注担当者でない場合、取引先にはすでに納期を伝えているかもしれません。

他製品やCSV連携でどれだけ遅れが出るかは製品と設定によって異なり、一律の目安は示せません。
自社の連携がバッチなら、少なくとも次の点を運用で決めておくと、ずれに気付くまでの時間を縮められます。

<ul><li>同期の間隔と、受注担当者がその間隔を知っているか</li><li>引当に失敗した受注を誰が、いつ確認するか</li><li>失敗した受注について、取引先へ納期を訂正する役割を誰が持つか</li><li>受注が集中する時間帯に、同期を待たずに在庫を確かめる手段があるか</li></ul>

これらを決めても、遅れそのものは消えません。
減るのは、ずれに気付くまでの時間と、気付いた後に誰が何をするかの迷いです。
同じ品目に窓口をまたいだ注文が重なりやすい商材なら、即時連携への切り替えや、窓口ごとに在庫の配分を分けるといった構成の見直しも選択肢になります。

▼ 図の内容を文字で読む

• 即時連携
  • 受注のたびに在庫側へ問い合わせる
  • ほかの窓口で押さえた分が有効在庫に反映される
  • 在庫側が応答しないときの受注入力を決めておく
• 定期連携（バッチ）
  • 次の同期まで、ほかの窓口の受注が画面に表れない
  • ある製品の例では約1分に1回同期する
  • 失敗した予約は受注入力のあとで確認する
• 定期連携で運用に決めておくこと
  • 同期の間隔を受注担当者が知っているか
  • 引当に失敗した受注を誰がいつ確認するか
  • 取引先へ納期を訂正する役割を誰が持つか

受注の変更・取消・分納・引当不足のとき、引当をどう戻し、再引当するか

取消・変更のときの引当解除

引当の設計で見落とされやすいのは、押さえた在庫を戻す側の手順です。
取引先から注文の取消や数量変更の連絡を受けた受注担当者は、販売管理の受注を修正します。
このとき在庫側で押さえていた数量も一緒に戻らなければ、有効在庫は減ったままになり、実際には出せる在庫を「ない」と答えることになります。
欠品とは逆向きの、見えにくい機会損失です。

戻し方も製品で違います。
Microsoftの在庫可視化サービスでは、元の注文行が取消・削除された場合、同じ内容の負数の予約を送るか、予約IDを指定して予約を解除する方法が示されています¹。
ロジクラでは、引当済みの出荷を出荷予定の状態へ戻すと、引当が解除されます⁴。
前者は連携の仕組みとして戻す操作を送る必要があり、後者は画面上で出荷の状態を戻す操作です。

受注を取り消したときに在庫側の引当が自動で戻るかどうかは製品によって扱いが違い、どの販売管理でも自動で戻るとは言えません。
自社の連携では、取消・数量減・行の削除のそれぞれについて、販売管理の操作が在庫側の解除まで届くかを試しておく必要があります。
特に数量を減らす変更は取消ほど目立たないため、差分だけを戻す処理になっているかどうかで、有効在庫の正確さが変わります。

一部引当で出荷指示に進めるか止めるか

受注の一部だけ在庫が足りないとき、受注担当者は「ある分だけ先に出すか、全部そろうまで待つか」を決めなければなりません。
分納を受け入れる取引先なら先に出すほうが助かる場合もあり、受け入れの手間を嫌う取引先なら、まとめて届けるほうが望まれます。

Microsoftでは、この判断を倉庫ごとのルールとして設定できます。
一部でも引当済みなら出荷指示へ進める「Allow partial reservation」と、全量が引き当てられるまで出荷指示を出せない「Require full reservation」を選び、全量必須にした倉庫では未引当の行がある注文を出荷指示に回すとエラーになります²。
この設定は高度な倉庫管理を有効にした倉庫でのみ使え、機能管理で倉庫出荷ルールの機能を有効にしておく必要があります²。

ロジクラの出荷保留では、全量が引き当てられた出荷だけが作業中へ進み、一部しか引き当てられていない出荷は欠品エラーになります⁴。
同社の出荷保留では、欠けた分がそろうまで出荷作業には進まない作りです。

どちらの仕組みでも、システムが判定するのは「進めるか止めるか」までで、取引先に分納を提案するかどうかは受注側が決めることです。
倉庫ごと・取引先ごとに分納の可否が違うなら、その違いを設定に持たせられるのか、受注ごとに担当者が判断して出荷指示を分けるのかを、連携を組む段階で決めておくと、欠品が出たときの取引先への連絡が早くなります。

入荷後の再引当を誰が行うか

一部だけ引き当てて保留した受注は、足りない商品が入荷したときに、改めて引き当てなければなりません。
ロジクラのヘルプでは、一部引当済みの出荷について、未引当の商品は入荷後に再度引当の操作が必要で、自動での引当には対応していないと案内されています⁴。
入荷を受けた倉庫の担当者と、取引先に納期を約束した受注担当者が別の人なら、入荷の事実が受注担当者に伝わるまで、保留中の受注は動きません。

ここで起こりうるのは、入荷した在庫を、保留中の受注より先に新しい受注が押さえてしまうことです。
新しい受注は通常の流れで引当が走りますが、保留中の受注は誰かが操作するまで待っているからです。
先に約束した取引先への出荷が後回しになるのを防ぐには、入荷のたびに保留中の受注を確認する担当と、その確認を新規受注の引当より先に行う順番を決めておく必要があります。

再引当を自動で行う設定がある場合でも、どの受注を優先するかの規則、たとえば受注日の古い順か納期の近い順かを把握しておくと、取引先に答えた順番と実際の出荷順がずれたときに理由を説明できます。

▼ 図の内容を文字で読む

1. 引当不足が分かる：押さえられた数量と足りない数量を把握する
2. 分納の可否を判断：取引先の受け入れ条件と倉庫のルールを照らし合わせる
3. 保留して入荷を待つ：足りない商品が入荷するまで出荷指示に進めない
4. 入荷後に再引当：自動で行われない製品では担当者の操作が要る
5. 出荷指示：引当の済んだ受注を出荷作業へ回す

ロット・期限・複数倉庫がある場合、引当設計をどう選ぶか

期限・ロットで自動引当が止まる場面

食品のように賞味期限や製造ロットで在庫を区別する商品では、「品目の在庫があるか」だけでは出せるかどうかが決まりません。
取引先が期限まで一定の日数が残っているものを求めていれば、期限の近いロットは数量があっても引当に使えないからです。

ロジクラの期限管理の案内には、自動引当の限界が書かれています⁵。

<ul><li>当日が期限の在庫は引き当てられない</li><li>出荷可能な残り日数の判定は出荷指示の引当でのみ行われ、出荷実績の登録では判定されない</li><li>自動引当は複数の期限ロットを扱わない</li></ul>

期限管理の機能自体も、同社のスタッフによる有効化が必要です⁵。
三つ目の点は、受注側にとって影響が大きいところです。
注文数量が一つの期限ロットの残りより多いと、別のロットを組み合わせれば数量は足りていても、自動引当だけでは押さえきれず、担当者が引き当て直す作業が残る可能性があります。
二つ目の点からは、引当を経ずに出荷実績を直接登録する運用では、期限の条件が確かめられないまま出荷が記録されることが分かります。
また、保留していた出荷を開始すると引当がやり直され、ロットや期限の結果が変わることもあります⁴。

これらはロジクラの仕様で、ほかの製品に同じ制約があるとは限りません。
ただ、期限やロットを条件にした引当が「どの段階で」「どの単位で」判定されるかは、どの製品でも確かめるべき点です。
受注時点では品目の数量だけを見て押さえ、期限の条件は出荷指示で初めて判定される構成なら、受注担当者が答えた納期は、期限の条件を満たす在庫があることまでは保証していません。

複数倉庫も同じ構造です。
Microsoftの倉庫出荷ルールは倉庫ごとに一部引当の可否を選ぶ仕組みで、しかも高度な倉庫管理を有効にした倉庫でしか選べません²。
倉庫ごとに管理の水準が違えば、同じ受注でも出荷元の倉庫によって引当の扱いが変わります。
受注担当者が出荷元を選べる運用なら、倉庫ごとのルールの違いを知っていないと、分納になるかどうかを取引先に正しく伝えられません。

導入前に確認する項目

ここまで見てきた製品の仕様を並べると、同じ論点でも答え方がかなり違います。
次の表は、Microsoft Dynamics 365 Supply Chain Managementとロジクラについて、引当設計の四つの論点を並べたものです。
前者は大規模なERP、後者は出荷管理のクラウドサービスで、どちらも中小企業向けの販売管理システムそのものではありません。
優劣を比べる表ではなく、論点ごとに答え方の違いがあることを見るための表です。

表から読み取れるのは、二つの製品で「押さえた後にもう一度判定する」場面が違うことです。
Microsoftでは軽い予約が正式な引当に置き換わり、ロジクラでは保留から出荷を開始するときに引当がやり直されます。
自社のシステムがどちらに近いかで、受注時に答えた数量・ロット・期限が出荷時までどこまで保たれるかが変わります。

導入や連携の見直しの前に、ベンダーへの問い合わせや試験環境での操作で確かめておきたいことを、受注から出荷までの順に並べます。
これは編集部の提案で、すべての製品に当てはまる確認手順として定められたものではありません。

<ol><li>受注を入力したとき、どの単位（品目・倉庫・色やサイズ・ロット）で在庫が押さえられるか</li><li>押さえた結果が販売管理へ戻るまでの時間と、そのあいだにほかの窓口から同じ在庫が見えるか</li><li>仮の引当と正式な引当があるなら、正式な引当で数量やロットが再計算されるか</li><li>引当が一部しか取れないとき、出荷指示へ進めるか止めるかを倉庫や取引先ごとに設定できるか</li><li>受注の取消・数量減・行の削除で、在庫側の引当が解除されるか</li><li>入荷後に保留中の受注を再引当するのは自動か手作業か、手作業なら誰が気付ける仕組みか</li><li>期限・ロットの条件が判定されるのは受注時か出荷指示時か、複数ロットにまたがる数量を扱えるか</li></ol>

項目の多くは、受注担当者が日々の入力では直接触れないところです。
システムを選ぶ部門と受注を入力する担当者が別なら、選ぶ側がこの一覧で仕様を確かめ、入力する側が実際の注文の形で試す、という分担にすると、導入後に「思っていた引当と違う」と分かる場面を減らせます。

▼ 図の内容を文字で読む

• 受注を入力するとき
  • どの単位（品目・倉庫・色やサイズ・ロット）で押さえられるか
  • 結果が戻るまでの時間と、ほかの窓口から見えるか
• 一部引当と出荷指示
  • 仮の引当と正式な引当で数量やロットが再計算されるか
  • 出荷指示へ進めるか止めるかを倉庫や取引先ごとに設定できるか
• 取消・入荷後・ロット期限
  • 取消・数量減・行の削除で引当が解除されるか
  • 入荷後の再引当は自動か手作業か
  • 期限・ロットの判定が受注時か出荷指示時か

受注窓口の数や取引先ごとの分納条件が自社でどう分かれているかは、製品の資料だけでは当てはめにくく、引当の時点と連携方式の組み合わせを決める前に整理しておくと後戻りが減ります。

いまの受注の流れと窓口を伺いながら、どの段階で在庫を押さえていて、どこで販売管理と在庫の数字がずれているのかを一緒に洗い出せます。無料相談で要件を整理する

受注側の条件から見た、引当設計の検討の起点

受注窓口の数、受注から出荷までの期間、分納の可否、ロット・期限の有無という受注側の条件ごとに、検討の起点となる設計を整理した

• 受注窓口が複数あり、同じ品目に注文が重なる：どの窓口も受注の瞬間に同じ有効在庫を見る構成を起点に考える

• 受注から出荷までが長く、答えた納期を守る必要が強い：受注時に押さえる型か、軽く押さえて出荷指示で正式に引き当てる型

• 受注から出荷までが短く、在庫の回転が速い：出荷指示時に引き当てる型でも欠品の不安は小さい

• 分納を受け入れる取引先と受け入れない取引先が混在する：一部引当で進めるか止めるかを倉庫・取引先単位で持てるかを確かめる

• 期限・ロットの指定がある：自動引当の判定時点と、複数ロットにまたがる数量の扱いを先に確かめる

同じ品目に窓口をまたいだ注文が重なる、バッチで失敗した予約の確認が追いつかないといった状況が出てきたら、即時連携や引当の単位の見直しを検討する

要点の整理

軸	基準
納期回答の物差し	実在庫ではなく有効在庫（実在庫−引当分）で答える
引当の時点	欠品の許容度、納期の約束の強さ、在庫を拘束できる期間で選ぶ
引当の単位	受注時点で決められる範囲（品目・倉庫・色やサイズ・ロット）
連携方式	受注窓口の数と、同じ品目に注文が重なる度合い
一部引当	分納の可否を倉庫・取引先ごとに持てるか
取消・再引当	解除と入荷後の再引当を誰がいつ行うか
ロット・期限	判定が受注時か出荷指示時か、複数ロットを扱えるか

取消・再引当・期限やロットのように例外で残る作業は、導入後に気付くと運用の組み直しが必要になります。 導入前の確認項目を自社の注文の形に当てはめ、どの例外で手作業が残り、誰が担うことになるかを整理できます。

よくある質問

仮引当と本引当の違いは、どのシステムでも同じですか。

同じではありません。
製品をまたいで通じる共通の定義はなく、製品ごとに仕組みが違います。
たとえばMicrosoft Dynamics 365 Supply Chain Managementでは、軽いソフト予約が販売管理側の物理引当になった時点で自動で相殺されます¹。
ロジクラの出荷保留では、保留中の出荷を開始すると引当がやり直され、ロットや期限の結果が変わることがあります⁴。
自社のシステムでは、仮の引当がほかの注文をブロックするか、正式な引当で再計算されるかを基準に読み替えると判断しやすくなります。

受注窓口がECと電話で分かれているとき、二重引当を防ぐには何が必要ですか。

どちらの窓口も、受注の瞬間に同じ有効在庫へ問い合わせて押さえられることが前提になります。
Microsoftの資料では、複数の受注システムが即時のAPI呼び出しで在庫の単一の情報源を見ることで二重売りを防ぐ構成が説明されています¹。
同期に時間差がある連携では、その間に別の窓口が同じ在庫を約束する可能性が残るため、失敗した引当を誰が確認し、納期を訂正するかを決めておく必要があります。

一部だけ在庫がある受注は、先に出荷指示へ進めてよいですか。

取引先が分納を受け入れるかどうかと、システムの設定の両方で決まります。
Microsoftでは倉庫ごとに一部引当でも出荷指示に進めるか、全量引当まで止めるかを選べますが、高度な倉庫管理を有効にした倉庫に限られます²。
ロジクラの出荷保留では、全量引当済みの出荷だけが作業中へ進み、一部引当は欠品エラーになります⁴。
先に出す場合は、残りの分を入荷後に誰が引き当てるかも合わせて決めておきます。

受注を取り消したとき、引当した在庫は自動で戻りますか。

製品によって扱いが違い、どの販売管理でも自動で戻るとは言えません。
Microsoftの在庫可視化サービスでは、同じ内容の負数の予約を送るか、予約IDを指定して解除します¹。
ロジクラでは、出荷を出荷予定の状態に戻すと引当が解除されます⁴。
自社の連携では、取消だけでなく数量を減らす変更や行の削除でも、在庫側の引当が解除されるかを試しておくと安心です。

賞味期限・ロットがある商品は、自動引当に任せられますか。

商品の条件と製品の仕様次第です。
ロジクラの例では、当日が期限の在庫は引き当てられず、出荷可能日数の判定は出荷指示の引当でのみ行われ、自動引当は複数の期限ロットを扱いません⁵。
注文数量が一つのロットの残りを超えやすい商品や、取引先が期限の残り日数を指定する商品では、手作業の引き当て直しが残る可能性があります。
これはロジクラの仕様で、他製品に同じ制約があるとは限りません。

連携がバッチの場合、ずれを減らすために運用で何を決めておくべきですか。

同期の間隔を受注担当者が知っていること、引当に失敗した受注を誰がいつ確認するか、取引先への納期訂正を誰が担うか、受注が集中する時間帯に同期を待たずに在庫を確かめる手段があるか、の四点です。
Microsoftのバッチ予約はおよそ1分に1回の同期で、失敗した予約や相殺は確認画面で見る運用です¹。
他製品やCSV連携の遅れは製品と設定で異なるため、自社の連携の間隔を確かめたうえで決めます。

1. 1　出典：Microsoft「Inventory Visibility reservations（Dynamics 365 Supply Chain Management）」（2026）
2. 2　出典：Microsoft「Release to warehouse rule（Dynamics 365 Supply Chain Management）」（2026）
3. 3　出典：SAP「Available-to-Promise (ATP)（SAP Help Portal）」（2016）
4. 4　出典：ロジクラ（ヘルプセンター）「出荷を保留する／出荷保留機能の追加」（2025）
5. 5　出典：ロジクラ（ヘルプセンター）「有効期限管理をするにはどうしたらいいですか」（2025）
6. 6　出典：ECのミカタ編集部「在庫引当とは？重要性や方法、在庫管理システムを導入するメリット」（2023）