Web受発注システムの在庫公開機能｜見せ方・連携・引当の選び方

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

B2B EC-COLUMN

Web受発注システムの在庫公開で変わる受注の流れ｜問い合わせと欠品連絡はどこで起きるか

取引先から「この品番、在庫ありますか」「いつ届きますか」と電話やFAXで何度も聞かれ、そのたびに在庫を確かめて折り返す。
受けた注文が欠品で、後から取引先へ連絡し直すこともある。
Web受発注システムの在庫公開機能で発注画面に在庫を出せば、こうした確認の往復を注文の前へ移せる可能性があります。
ただし、画面の在庫が実在庫とずれていれば欠品連絡は残ります。
見せ方（実数か〇△×か）、取引先ごとの出し分け、基幹の在庫を正とする連携、引当のタイミングを順に決めることが、在庫公開を役立てる近道です。

在庫確認の電話・FAXと欠品の連絡し直しが起きる場面

取引先の購買担当者が発注前に在庫を知りたいのは、自社の生産計画や納品予定を組むためです。
在庫を見られる画面がなければ、電話・FAX・メールで尋ねるしかありません。
問い合わせを受けた担当者は、基幹システム（販売・在庫・会計などを管理する社内の中心的なシステム）や倉庫で在庫を確かめ、すでに受けている注文の分を差し引いてから回答します。
一件ずつ人が間に入るので、問い合わせが重なる時間帯ほど回答が遅れ、取引先の発注も待たされます。

欠品の連絡し直しは、この往復の後ろで起きます。
午前に「あります」と答えた品目でも、別の取引先の注文が先に入れば、午後に注文書が届いた時点では足りないことがあります。
受注側は注文を受けてから在庫不足に気づき、取引先へ数量の変更や納期の延長を相談し直すことになります。
取引先から見ると、確認したはずの在庫がなかったことになり、次の注文でも念押しの確認をしたくなります。

困りごとは、注文前の在庫確認と、注文後に分かる在庫の不一致という二つの場面に分かれます。
在庫公開機能が直接置き換えるのは前者です。
後者がなくなるかどうかは、画面に出す在庫がどれだけ実在庫に近いか、注文を受けた時点でその在庫を押さえられるかで決まります。

在庫公開が置き換える範囲と置き換えない範囲

在庫公開の基本的な形は、受注側が登録した在庫情報を取引先の発注画面に表示するものです。
たとえばMOSの在庫表示オプションでは、受注者が受注者画面で商品マスタに在庫情報を含めて登録すると、発注者画面に在庫情報が表示されます¹。
取引先は品目を選ぶ画面で在庫の状況を見られるので、在庫を尋ねる電話をかける前に、注文するか、数量を減らすか、別の品目にするかを判断できます。
受注側にとっては、問い合わせへの回答作業の一部が、取引先自身の画面確認に置き換わる形です。

一方で、画面の在庫は誰かが登録し、取り込んだ時点の値です。
MOSの製品ページでは、在庫の元データは商品マスタへの登録として説明されており、基幹システムとの自動連携の方式は書かれていません¹。
登録した後に倉庫から出荷があり、その分が反映されていなければ、取引先は実在庫より多い数を見て注文します。
このとき欠品連絡は、問い合わせの段階から注文受付の後ろへ移るだけで、なくなりはしません。

在庫の設計について、在庫の正（最終的に正しいとみなす値）は基幹側に置き、EC（受発注システムの発注画面）は在庫の表示と仮引当（注文確定前に在庫を一時的に押さえること）にとどめるのが基本だとする解説があります²。
この考え方に立つと、受発注システムは在庫を決める場所ではなく、基幹の在庫を取引先に見せる窓口です。
在庫公開で減らせるのは在庫を尋ねる往復で、どの注文にどの在庫を割り当てるか、足りない品目の納期をどう答えるかは、基幹側の在庫と受注側の運用に残ります。

問い合わせや欠品連絡がどの程度減るかは、取引先の発注の仕方、品目の数、在庫の動き方で変わります。
効果の大きさを一律に示せる調査結果は確認できておらず、導入前に削減量を数字で見込めるものではありません。
効果を左右するのは、取引先にどう見せるかと、画面の在庫を実在庫に近づける仕組みの二つです。

▼ 図の内容を文字で読む

1. 取引先が在庫を問い合わせる
2. 担当者が基幹や倉庫で確かめて回答する
3. 注文が届いた時点で欠品が分かる
4. 取引先へ数量や納期を連絡し直す
5. 取引先が念押しの確認をする

在庫の見せ方を選ぶ｜実数・記号表示・取引先別の出し分け

実数と〇△×表示の違い

在庫の見せ方は、大きく実数を出すか、記号で段階を示すかに分かれます。
MOSの在庫表示オプションでは、表示形式を「数字」「〇」「△」「×」などから選べます¹。
同じ在庫情報でも、どの形で出すかによって、取引先が画面から読み取れることと、在庫がずれたときの影響が変わります。

実数を出すと、取引先は必要な数に足りるかを自分で判断できます。
分納でよいか、一部を別の品目に回すかまで画面を見て決められるので、数量の相談まで含めた問い合わせを前倒しにしやすい形です。
その分、表示された数がずれていたときの影響は大きくなります。
取引先はその数を前提に注文し、社内の計画まで組むため、数が合わなかったときの連絡は相手の段取りを崩します。
また、実数は自社の在庫の厚みや売れ行きを推し量る材料にもなるので、どの取引先にも同じように見せてよいかは別に考える必要があります。

〇△×のような記号は、多少のずれを吸収します。
実在庫が登録値より少し減っていても、〇の範囲に収まっていれば表示は変わらず、取引先の判断も変わりません。
ただし、どの残数から△にするか、△の品目を取引先はどう扱えばよいかを決めておかないと、△を見た取引先は結局電話で確かめます。
記号の境目をどう設定するかは製品ページに書かれていないため¹、品目ごとに変えられるかも含めて製品に確かめる項目になります。
△を「注文は受け付けるが、確定前に受注側が在庫を確認する」という意味にそろえるなど、記号に運用上の意味を持たせると、問い合わせの残り方が変わります。

どちらが欠品連絡を減らしやすいかは、表示形式だけでは決まりません。
在庫がこまめに更新され実在庫に近いなら実数の利点が生き、更新に間が空くなら記号のほうがずれの影響を抑えやすくなります。
見せ方は、在庫をどう写して更新するかとあわせて選ぶものです。

取引先ごとの出し分けで制御できること

見せ方とは別に、誰に何を見せるかという軸があります。
EC-Rider B2Bでは、取引先毎・サプライヤー毎に商流、つまり「見せる(売る)」か「見せない(売らない)」かを設定でき、これは標準機能です⁴。
ここでいうサプライヤーは、倉庫や仕入先を登録した在庫の持ち主の単位で、同じ倉庫の中でも下層の在庫として分けて管理できます⁴。

この制御が役立つのは、特定の取引先にだけ扱わせたい商品や、特定の倉庫・仕入先の在庫からだけ出荷したい取引がある場合です。
たとえば、ある取引先向けに確保している在庫を他の取引先の画面に出さない、仕入先から直送する品目を直送に対応できる取引先にだけ売る、といった線引きを商品と在庫の単位で持てます。
他の取引先の注文で専用の在庫が減ってしまい、本来の取引先に欠品を連絡する、という事態を避けるための仕組みとして使えます。

注意したいのは、この出し分けが表示形式の切り替えとは別物だという点です。
EC-Rider B2Bの取引先別の設定は、商品や在庫を見せるか・売るかの制御で、取引先Aには実数、取引先Bには記号といった表示形式を取引先ごとに変える機能は、公開されている機能説明からは確認できません⁴。
MOSでも、表示形式を取引先ごとに切り替えられるかは製品ページに記載がありません¹。
また、EC-Rider B2Bでサプライヤー毎の在庫数をまとめて表示するのはカスタマイズの扱いです⁴。
取引先によって数量の見せ方まで変えたい場合は、標準でできるのか、追加の開発が要るのかを個別に確かめることになります。

見せる情報と守る情報の整理

ここまでの二つの軸を使って、見せる情報と守る情報を分けておくと、表示の設定を決めやすくなります。
以下は製品の仕様ではなく、判断の進め方の一例です。

見せたい情報の中心は、注文前に欠品が分かることです。
取引先が画面で確かめたいことの一つは「今回の数量で注文が通るか」であり、そこが分かれば実数でも記号でも目的は果たせます。
守りたい情報は、正確な在庫数、仕入先や倉庫ごとの内訳、他の取引先のために押さえている在庫です。
これらは取引先の注文判断に必ずしも要らない一方で、見えると価格交渉や発注の振り分けに影響することがあります。

取引先ごとに当てはめると、発注計画を共有し長く取引している相手には実数を、スポットの取引や新しい取引先には記号を、扱わせない商品は商流で見せない、という分け方が考えられます。
ただし、取引先ごとに表示形式を変えられるかは製品によって確認が要ります。
切り替えられない場合は、全取引先に共通の形式を一つ選び、出し分けは商品・在庫を見せるかどうかで行う、という組み立てになります。
仕入先別の内訳については、そもそも取引先に見せる必要があるかを先に決めると、まとめ表示のカスタマイズが要るかどうかも同時に決まります。

▼ 図の内容を文字で読む

• 実数
  • 必要な数に足りるかを取引先が自分で判断できる
  • ずれたときの影響が大きい
  • 在庫の厚みを推し量る材料になる
• 〇△×の記号
  • 多少のずれを吸収する
  • 境目と△の扱いを決めないと電話で確かめられる
• 取引先ごとの出し分け
  • 商品・在庫を見せる／見せないで分ける
  • 表示形式の取引先別の切り替えは製品ごとに確かめる

公開在庫を実在庫からずらさない設計｜基幹連携・更新頻度・引当のタイミング

在庫の正を基幹に置く考え方

見せ方を決めても、画面の在庫が実在庫から離れれば、欠品連絡は注文の後ろに残ります。
ずれを抑える出発点は、在庫の正をどこに置くかです。
引当の設計を扱う解説記事では、在庫の正は基幹側に置き、ECは在庫の表示と仮引当にとどめる役割とされています²。

正を一か所にする理由は、増減を記録する場所が二つあると照合が欠かせなくなるからです。
たとえば、電話やFAXで受けた注文と倉庫からの出荷は基幹で在庫を減らし、Webの注文は受発注システム側で在庫を減らす運用だとします。
このとき両方の在庫は別々に減り、どちらの数が正しいのかを誰かが突き合わせない限り、画面の在庫はずれ続けます。
基幹を正とし、受発注システムは基幹の値を写して表示する形にすれば、ずれの原因は「写すまでの間」に絞られます。

MOSのように受注者が商品マスタに在庫情報を登録する形では¹、基幹の在庫を誰が、いつ、どの方法で登録し直すかが運用の中身になります。
基幹から自動で取り込めるのか、担当者が手で入れ直すのかは製品ページから読み取れないため、導入時に確かめる事項です。

CSV・バッチ・APIの連携方式と標準・カスタマイズの区分

写す方法の一例として、EC-Rider B2Bの標準の在庫連携は、基幹システムから在庫情報をCSV（項目を区切って並べたデータファイル）で出力し、受発注システムに取り込む手動の方式です³。
定型フォーマットでの出力・取込は標準で、定時バッチ（決めた時刻に自動で処理を走らせる仕組み）による自動化や独自フォーマットへの対応はカスタマイズとされています³。
事例として、ネクストエンジンとのAPI連携やHULFT連携の実績も紹介されています³。
これはEC-Rider B2Bの区分で、他の製品で何が標準かは製品ごとに異なります。

三つの方式は、画面の在庫がどれだけ古くなるかと、誰の手を要するかで違います。
手動のCSVでは、担当者が出力と取込を行った時点で在庫がそろい、次の取込まで画面は止まります。
担当者が不在の日や作業が遅れた日は、そのまま古い在庫が出続けます。
定時バッチは人手の抜けをなくしますが、処理と処理の間に動いた在庫は次の処理まで反映されません。
API（システム同士が直接データをやり取りする接続）は取込の間隔をさらに詰められる方式ですが、どこまで速く反映されるかは連携の設計次第で、方式の名前だけで決まるものではありません。

在庫の更新のしかたにも二通りあります。
EC-Rider B2Bでは、在庫の更新を入庫・出庫で行うか、棚卸による洗い替えで行うとされています³。
入庫・出庫の都度に数を足し引きする方法は動きを細かく追えますが、取込の漏れがあるとずれが残ります。
洗い替えは基幹の在庫数で丸ごと置き換えるので、取り込んだ時点で数がそろいます。

では、どの間隔で更新すればよいのか。
引当の設計を扱う解説記事でも更新頻度は対象外とされており²、一律の目安は示せません。
決め手になるのは、一日のうちに在庫がどれだけ動くかと、欠品の注文を受けたときに何が起きるかです。
動きの少ない品目なら手動の取込でも画面と実在庫は離れにくく、売れ行きが速い品目や、欠品で取引先の生産が止まるような品目ほど、自動化や記号表示で影響を抑える理由が強くなります。
品目を在庫の動きで分け、動きの大きいものから連携の自動化を検討すると、カスタマイズの範囲も絞り込めます。

仮引当と確定引当、減算タイミングの違い

在庫を写す仕組みと並んで、注文を受けたときに在庫をいつ押さえるかが、ずれの残り方を左右します。
引当とは、受けた注文に出荷する在庫を割り当て、他の注文が使えないように確保することです²。
出荷が先になる注文について在庫を先に確保する扱いは、予約（取り置き・バックオーダー）として区別されています²。

解説記事では、引当を三つの段階に分けています²。
仮引当はカートへの投入、見積の提示、承認待ちの段階で期限付きに在庫を押さえ、期限が切れれば解除します。
確定引当は注文の確定や承諾通知が届いた時点で行い、原則として取り消しません。
出荷引当は出荷指示のときに、ロットや保管場所まで割り付けます。
これは一般的な設計の整理で、各製品がこの三段階をそのまま備えているとは限りません。

MOSでは、発注ボタンをクリックした時点で在庫情報が減算されます¹。
取引先が発注した時点で画面の在庫が減るので、同じ在庫を別の取引先が続けて注文する場面を画面上で防ぎやすい形です。
一方、承認待ちなどの仮の状態をどう扱うかは製品ページに書かれていません¹。
受注側が注文を確認してから受けるかどうかを決める取引では、減算した在庫を断ったときにどう戻すかを確かめておく必要があります。

どちらの考え方が合うかは、取引の進め方で分かれます。
取引先の注文をそのまま受ける取引が中心なら、発注時点で減らす単純な形でも在庫の取り合いは起きにくくなります。
見積を出してから注文を受ける、取引先の社内承認を待つ、受注側が与信や納期を見てから承諾する、といった工程を挟む取引では、その間の在庫を期限付きで押さえ、確定と分けて扱える設計のほうが、押さえたまま放置される在庫や、承認の間に他の注文へ回ってしまう在庫を防ぎやすくなります。
自社の受注にどの工程があるかを並べてみると、仮引当と確定引当を分ける設計が要るかどうかが見えてきます。

▼ 図の内容を文字で読む

1. 仮引当
   • カート投入・見積の提示・承認待ちで期限付きに押さえる
   • 期限が切れれば解除する
2. 確定引当
   • 注文の確定や承諾通知が届いた時点で行う
   • 原則として取り消さない
3. 出荷引当
   • 出荷指示のときに行う
   • ロットや保管場所まで割り付ける

基幹と連携できない・在庫が大きく動くときの在庫公開と運用

手動連携のときの粗い表示と更新時刻の明示

基幹との自動連携をすぐには組めない場合でも、在庫公開を見送る必要があるとは限りません。
標準の在庫連携が手動のCSV取込である製品もあり³、その場合は「画面の在庫は取り込んだ時点の値で、次の取込まで止まる」ことを前提に運用を組み立てます。
取込から次の取込までの間に、電話やFAXで受けた注文が出荷されたり、入荷が遅れたりすれば、画面と実在庫は離れていきます。

このずれへの備えとして、三つの運用が考えられます。
いずれも確認済みの機能を組み合わせた提案で、欠品連絡がどれだけ減るかを測ったものではありません。

一つ目は、実数を出さず、〇△×のような記号で見せることです。
MOSのように表示形式を選べる製品であれば¹、取込の間に多少在庫が動いても表示が変わりにくく、取引先が古い数字を信じて細かな数量で注文する場面を避けられます。
ただ、在庫が尽きたのに〇のまま残ることは起こり得るので、記号にしたからずれがなくなるわけではありません。

二つ目は、在庫をいつの時点で更新したかを画面に示すことです。
取引先が「朝の時点の在庫」と分かれば、急ぎの品や数量の多い注文だけは事前に確かめる、といった判断を取引先自身ができます。
更新時刻を画面に出せるかは製品ごとに確かめる必要があり、出せない場合は取込の時刻を取引先に案内しておく方法もあります。

三つ目は、確定引当の前に受注側が基幹の在庫と照らし合わせることです。
注文を受けたら確定させる前に基幹の在庫を確認し、足りなければその段階で取引先に連絡します。
欠品の連絡そのものは残りますが、出荷の直前ではなく受注を確定させる前に移るので、取引先が代わりの手配をする時間を取りやすくなります。

在庫を細かな単位で正確に保つのが難しい場合は、管理の単位を粗くする選択もあります。
EC-Rider B2Bでは、SKU（色やサイズなど、在庫を数える最小の単位）ごとに在庫を管理しない運用も可能とされています³。
色違いやサイズ違いの在庫を一つずつ正確に追えないのに、画面だけSKU単位で数を出すと、ずれた数が細かく並ぶことになります。
どの品目をSKU単位で見せ、どの品目はまとめて扱うかを分けておくと、正確に保てる範囲だけを細かく公開できます。

連携停止時の扱い

自動連携を組んだ後も、連携が止まる場面は想定しておく必要があります。
引当の設計を扱う解説記事では、基幹連携が止まった場合は確定引当を取れないため、仮引当のまま止めて復旧を待つ方針が示されています²。
在庫の正が基幹にある以上、基幹の在庫を確かめられないまま注文を確定させると、実在庫のない注文を受けてしまうおそれがあるからです。

この方針を運用に移すと、取引先の画面では注文が届いているのに、受注側では確定できない状態が続きます。
取引先には「注文は受け付けたが、確定は復旧後になる」ことを伝える必要があり、誰がどの手段で知らせるかを決めておかないと、取引先からの問い合わせが一度に集まります。
仮引当には期限があるため、復旧が長引いたときに期限を延ばすのか、いったん解除して取引先に再注文を頼むのかも、あらかじめ決めておく項目です。
製品が仮引当の期限や連携停止時の扱いをどう設定できるかは、引当のタイミングとあわせて確かめます。

▼ 図の内容を文字で読む

1. 手動のCSV取込で次の取込まで画面の在庫が止まる
   • 〇△×の記号で見せてずれの影響を抑える
   • 更新時刻を画面か案内で示す
2. 電話・FAXの注文や入出庫で実在庫が動く
   • 確定引当の前に基幹の在庫と照らし合わせる
3. 基幹連携が止まり在庫を確かめられない
   • 確定せず仮引当のまま復旧を待つ
   • 取引先への連絡と仮引当の期限を決めておく
4. SKU単位では在庫を正確に保てない
   • SKU単位で管理しない品目を分ける

導入前に確認する機能要件と運用ルール

製品に確認する5つの項目

ここまでの論点のうち、製品の仕様で決まるものは導入前に製品へ質問し、自社で決めるものは社内のルールにします。
製品への質問は、次の5つにまとまります。

• 表示形式：実数と〇△×などの記号のどれを選べるか、記号の境目をどう設定するか
• 取引先別の制御：商品や在庫を取引先ごとに見せる・見せないで分けられるか、表示形式も取引先ごとに変えられるか
• 在庫の元データ：商品マスタへの登録か、基幹からの取込か
• 連携方式と提供区分：手動の取込・定時バッチ・API連携のどれが標準で、どれがオプションやカスタマイズか
• 引当のタイミング：在庫をいつ減らすか、仮引当の有無と期限、連携停止時の扱い

これらを聞く際は、機能の有無だけでなく、標準で使える範囲と追加の対応になる範囲を分けて聞くと、製品同士を同じ物差しで比べられます。
たとえばMOSの在庫表示はオプション機能として提供され、ページには具体的な制約が書かれていないため、詳細は問い合わせて確かめることになります¹。
EC-Rider B2Bは機能ごとに標準とカスタマイズの区分を示しています⁴。
同じ「在庫連携ができる」という説明でも、手動の取込が標準で自動化は追加の対応なのか、最初から自動なのかで、導入後に誰がどれだけ手を動かすかが変わります。

優先順位は、自社の連携力から決めると迷いにくくなります。
基幹から自動で在庫を渡せないなら、まず手動の取込で回る表示形式と更新の運用を固め、引当のタイミングがその運用と食い違わないかを見ます。
基幹から自動で渡せるなら、実数を見せる取引先の範囲や、仮引当と確定引当を分けるかどうかへ判断の重心が移ります。

社内で決める更新・欠品連絡のルール

製品の機能が決まっても、運用のルールがなければ公開した在庫の正確さは保てません。
社内で決めておきたいのは次の三点です。

• 在庫の更新：誰が、いつ、どの方法で在庫を取り込むか。
  担当者の不在日や休日の扱いも含める
• 欠品時の連絡：欠品の注文が入ったとき、誰が、どの手段で、代わりの品目や入荷予定を添えて取引先に知らせるか
• 実数を見せる範囲：どの取引先に実数を見せ、どの取引先には記号や非表示にするか

更新のルールは、手動の取込を選んだ場合ほど重みを持ちます。
取込の担当と時刻が決まっていれば、画面の在庫がいつの値かを社内でも取引先にも説明でき、更新時刻を示す運用ともつながります。
欠品連絡のルールは、在庫公開でなくなるものではなく、注文の後に残る連絡を早く、迷わず出すためのものです。
連絡の担当と文面の型を決めておけば、取引先は欠品を知った時点で次の手配に移れます。
実数を見せる範囲は、取引先との関係が変われば見直すものなので、商流の設定とあわせて定期的に見直す前提で決めておくと、設定が古いまま残ることを防げます。

取引先にどの商品と在庫を見せるか、基幹からどの形で在庫を渡せるかは、製品の標準機能の範囲と組み合わせて考えないと決めにくいためです。

自社の基幹から出せる在庫データで標準のCSV取込が回るか、自動化が必要か、取引先別・サプライヤー別の見せる／見せないの設定で希望する出し分けを収められるかを確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
見せ方	在庫がこまめに更新されるなら実数、間が空くなら〇△×などの記号
誰に見せるか	商品・在庫の見せる／見せないと、表示形式の取引先別切替は別の機能として確かめる
在庫の正	基幹の在庫を正とし、受発注画面は基幹の値を写して表示する
連携方式	手動CSV・定時バッチ・APIのどれが標準で、どれが追加対応かを製品ごとに確かめる
引当	見積や承認を挟む取引は、仮引当と確定引当を分けられるかを確かめる
連携停止時	確定せず仮引当のまま待つ間の取引先への連絡と期限を決めておく

表示形式・出し分け・連携方式・引当のタイミングは互いに関係し、自社の取引の進め方に当てはめると優先順位が変わるためです。 手動の取込から始めた場合の運用と、定時バッチやAPIによる自動化をカスタマイズで加える範囲を、自社の品目と取引先に当てはめて確かめられます。

よくある質問

在庫を実数で見せるのと〇△×で見せるのとでは、どちらが欠品連絡を減らしやすいですか。

表示形式だけで決まるものではありません。
画面の在庫がこまめに更新され実在庫に近いなら、実数は取引先が必要数に足りるかを自分で判断できる分、数量の相談を前倒しにできます。
更新に間が空く場合は、記号のほうが多少のずれで表示が変わらず、古い数を信じた注文を避けやすくなります。
どちらも欠品連絡の減り方を測った結果に基づくものではないため、在庫の更新方法とあわせて選ぶのが現実的です。

取引先によって在庫の見せ方を変えることはできますか。

製品によります。
EC-Rider B2Bでは、取引先毎・サプライヤー毎に商品や在庫を見せる(売る)か見せない(売らない)かを標準で設定できます⁴。
ただしこれは見せるかどうかの制御で、取引先ごとに実数と記号を切り替える機能とは別です。
MOSでは表示形式を数字や〇△×などから選べますが¹、取引先ごとに切り替えられるかは製品ページに書かれていないため、導入前に確かめる必要があります。

基幹システムがなくても在庫公開は始められますか。

始められる場合はあります。
MOSの在庫表示は、受注者が商品マスタに在庫情報を含めて登録すると発注者画面に表示される仕組みです¹。
この場合、登録した在庫を誰がいつ更新するかがそのまま在庫の正確さを決めるため、更新の担当と時刻を先に決めておくことが前提になります。
更新に間が空くなら、記号で見せる、更新時刻を伝えるといった運用で、古い在庫による欠品注文の影響を抑えます。

注文を受けた時点で在庫を減らすのと、承認後に確定するのとでは何が違いますか。

発注の時点で在庫を減らすと、同じ在庫を別の取引先が続けて注文する場面を防ぎやすくなります。
MOSでは発注ボタンをクリックした時点で在庫情報が減算されます¹。
承認後に確定させる設計では、承認待ちの間は期限付きの仮引当で押さえ、注文確定や承諾通知の到達時に確定引当とし、確定後は原則として取り消さない、という整理が示されています²。
見積や承認を挟む取引では後者のほうが、承認待ちの在庫が放置されたり他の注文に回ったりするのを防ぎやすくなります。

在庫の更新が遅れて欠品注文が入ったときの連絡と対応は、どう決めておくべきですか。

誰が、どの手段で、何を添えて連絡するかを先に決めておきます。
欠品の数量に加えて、入荷の見込みや代わりの品目を伝えられると、取引先は次の手配に移りやすく、問い合わせの往復も短くなります。
確定引当の前に受注側が基幹の在庫と照らし合わせる運用にしておけば、連絡は出荷の直前ではなく受注確定の前に出せます。
連携が止まっている間は、確定させずに仮引当のまま待つという考え方も示されています²。

在庫を持たない商品や取り寄せ品は、画面上でどう扱えばよいですか。

在庫数をそのまま出すと、在庫なしの表示になって取引先が注文をためらったり、反対に手元にあるように見えたりします。
出荷が先になる注文の在庫を先に確保する扱いは、予約（取り置き・バックオーダー）として通常の引当とは分けて説明されています²。
どの商品を在庫表示の対象にし、どの商品を取り寄せとして別に扱うかを品目ごとに決め、それを製品の設定で実現できるかを確かめます。
EC-Rider B2Bのように、仕入先をサプライヤーとして登録し、取引先ごとに見せる・見せないを設定できる製品もあります⁴。

1. 1　出典：ACROSS Solutions, inc.「BtoBモバイルWeb受発注システム「MOS」在庫表示オプション機能」（2026年閲覧）
2. 2　出典：株式会社フライトソリューションズ「BtoB ECの在庫引当と予約｜仕組みと設計」（2026年閲覧）
3. 3　出典：株式会社フライトソリューションズ「「EC-RiderB2B」の外部システム連携①～在庫連携編～」（2026年閲覧）
4. 4　出典：株式会社フライトソリューションズ「EC-Rider B2B マルチサプライヤー機能」（2026年閲覧）