「受注残」とは、受注側企業が1件の受注で注文された商品を、一括で全部発送することができなかった場合の未発送分の商品のことです。例えば、ある商品の在庫数が30個の時点で新たに50個の注文を受注した際に、先行して在庫分の30個を発送することにした場合、残り20個の未発送分の商品を「受注残」と呼びます。
受注残は、発注側では「発注残」と呼ばれます。ちなみに、「注残」（「注文残高」の略）も同じ状況を意味する用語で、こちらは受注側と発注側のどちらの立場でも使えます。
BtoB向けEC事業者がECシステムを導入またはリニューアルする際、「受注残管理機能」をECシステム側に組み込むか、あるいは、従来通り基幹システム側に残すかを検討するケースもありますが、一般には、BtoBの受注残管理はECサイトではなく基幹システムで行います。
受注残管理機能は複雑な処理が必要なため開発費用も高額になります。ECシステムに受注残管理機能を実装してしまうと、導入時だけでなく、ECサイトのリニューアルや機能追加のたびに、受注残管理機能の実装や他に影響がないことを担保するためのコストが発生することになります。そのため、頻繁な変更が想定されるECシステムと受注残管理機能は切り離して構築しているケースがほとんどです。
この記事では、インターファクトリーでマーケティングを担当している筆者が、BtoB向けECの受注残管理について解説します。
受注残の発生～ゼロまでのシステム管理項目の変化
下表は、EC、在庫管理、受注管理の3つのシステム管理項目に焦点を当てて、受注残の発生～ゼロになる（発送完了）までの変化を、注文受付日を起点とした時間軸で示した表です。
今回は基本の流れがイメージしやすいように「取引ステータス」と「受注残数」の変化に焦点を当てて、「自社工場で商品を生産しているEC事業者（受注側企業）が受注残の生じる1件の注文を受け付けた」というシンプルなケースで解説していきます。
◆BtoB向けECで受注残の発生～ゼロになるまでの各システム項目の変化
受注した6月1日時点は、商品50個の注文に対し、商品の「在庫数」（在庫管理）が30個しかありません。そこで、受注側企業は在庫分30個を先行納品し、不足している20個の追加生産を生産ラインに指示します。
生産が完了した商品20個が工場から倉庫に到着した時点で、在庫管理の「在庫数」が「0」から「20」に変化します。その後、倉庫から商品が発送された時点で「受注残数」（受注残管理）が「0」に変わります。
上表で注目してほしいのがECシステムの「取引ステータス」です。ECシステムでは受注受け付けと発送のステータスのみ管理しており、倉庫からすべての商品を発送し終えた時点で「発送済み」に変化しています。
上表の例のように、ECシステムでは「受注残」に関する情報を使用しなくても問題がありません。そのためBtoB向けECでは、受注残情報の管理は従来通り基幹システムで行うのが一般的です。
BtoBでは受注残対応は担当営業がフォロー
上述したように、ECサイトでは受注残の状況を確認することができませんが、BtoBの場合、受注残が発生する取引については受注側企業の営業担当者が、発注側（取引先）企業の担当者に、即納できる在庫数と、後送となる不足分の納期などを連絡して納品までの調整とスケジュール管理を行っている、というケースも多いでしょう。
営業担当者は、取引先企業の担当者と調整したスケジュール通りに商品が複数回に分けて納品（分納）されるよう管理します。また、取引先企業の担当者は、営業担当者から提示されたスケジュールに沿って、ECサイトの取引ステータスやECサイトから自動送信される発送メールなどを参照して発送状況を確認します。
このような運用では、注文受付日から商品がすべて発送された後、取引先企業での検収および支払いが完了するまでの取引全体を、担当営業は営業支援システムや基幹システムのデータを利用しながら手作業で管理することになります。
ECシステムに受注残管理機能を実装すべきでない理由
もちろん、ECシステムに受注残管理機能を実装することもできますが、受注残管理では既存の基幹システムの受注明細等のデータを使用することもあり、これらのデータをECシステムにも取り込むことは、ECシステムを複雑にするだけでなく、企業システム全体のデータ管理やセキュリティの観点からも好ましくありません。
経済産業省のDXレポートでも提唱されているように、更新や機能追加など「頻繁に変更が発生し、ビジネス・モデルの変化に活用すべき」ECサイトと、「更新があまり発生しないと見込まれる」受注残管理のような機能はシステムを切り離し、ECサイトは、集客効果やユーザーの利便性を追求するための実装に集中させるべきでしょう。
BtoB向けECでは、ECシステムで受注残管理を行わず、営業担当者の作業を自動化する場合も「受注残ステータス」の受け渡しにとどめるなど、各システムの役割を明確に分けることで、システムの効率化とコストダウンにもつながります。
売上計上は受注残がゼロになった時点
BtoB向けECの売上はすべての商品が発送された時点で計上します。これは受注残の取引でも同様です。
◆受注残を翌月に分納した場合の例（商品の受注数50個、在庫数30個の場合）
6月3日：後送分として残りの20個を発送
＝＝＞売上月は「6月」
分納の場合は最終納品日（最終的にすべての商品が発送された日）を売上日とするため、上記の例では売上月は「6月」として計上します。
そのため、取引先企業から「請求は5月と6月の2回に分けてほしい」という要望があった場合には、ECシステムでいったん商品50個の注文をキャンセルし、改めて2件の注文（例の場合「5月納品・請求の30個」と「6月納品・請求の20個」）として入力し直す必要があります。
BtoB機能と豊富な実績のあるECシステムを採用して、スムーズなシステム連携を実現しよう
BtoB向けECシステムでは、特に以下の要素が求められます。
◆ECシステムに求められる要素
・拡張性
・最新性
既存の基幹システムとECシステムとを連携させる場合には、カスタマイズが可能な「柔軟性」と「拡張性」が不可欠です。また、ECシステムは変更が頻繁に発生しやすいシステムなので、サービスを陳腐化させないためにも、安全性が担保され、最新機能が提供されるクラウドサービスを利用すべきでしょう。
「ebisumart(エビスマート)」は、柔軟性、拡張性、最新性を備えたフルカスタマイズ可能な中・大規模向けECプラットフォームサービスで、BtoB向けECサイトの構築と基幹システム連携の豊富な実績も有しています。
BtoB向けECシステムの導入またはリニューアルをご検討の方はぜひ「ebisumart」もご確認ください。
セミナー情報
