ECと基幹システムの連携設計｜データ管理・注文変更・エラー対応の確認点

「受注データは取り込めたのに、価格や数量を毎回確認している」「注文変更が片方のシステムにしか反映されない」。連携の設計では、通常の注文だけでなく、変更や失敗が起きたときの処理も確認する必要があります。

本記事では、連携方式の比較よりも、実装前に整理する業務ルールに重点を置きます。CSV・API・RPAの違いは、方式比較の記事へ分けて案内します。

ECと基幹システムの連携では、業務と技術の両方を確認する

連携には、データを受け渡す技術的な仕組みと、そのデータを業務でどう扱うかという取り決めが必要です。APIやCSVなどの方式を選んでも、価格の管理元や注文変更の扱いが自動的に決まるわけではありません。

一方、手作業が残る理由がすべて設計不足とは限りません。既存システムの制約や予算、承認の必要性から、人の確認を残す場合もあります。何を自動化し、何を担当者が処理するかを明確にすることが大切です。

• どのデータを、どちらのシステムで管理するか
• どのタイミングまでに反映されれば、出荷や請求に間に合うか
• 同じ注文の再送と、新しい注文をどう区別するか
• 処理が止まった場合、誰が状況を確認して再開するか

連携の設計で決める6つのこと

以下を確認表にまとめ、受注・出荷・経理の担当者と、EC・基幹それぞれの開発担当者で共有します。未決定の項目には、確認する担当者と期限を付けておきます。

BtoB受注で確認したい3つの設計ポイント

① 商品コード・得意先コード・数量の単位を対応付ける

ECの商品コードと基幹の品番が異なる場合は、対応表や変換処理が必要です。同じ商品でも、バラとケース、セット品と構成品などでは、コードを置き換えるだけでは処理できない場合があります。

たとえば、ECで「1ケース」を注文し、基幹では個数で管理する場合、入数に応じた数量変換が必要です。単価の単位も合わせて確認し、数量だけを変換して金額がずれないようにします。

• 商品・取引先のコードを対応付けられるか
• セット品や入数違いをどの明細として渡すか
• 対応表にないコードを受け取ったとき、処理を止める範囲と確認先
• 商品追加・入数変更の際、誰が対応表を更新するか

② 電話・FAX・メールの注文も含めて管理先を決める

ECとほかの受付経路を併用する場合、受注全体をどこで管理するかを決めます。たとえば基幹に集約するなら、ECの注文を取り込む流れと、電話・FAX注文を担当者が登録する流れを整理します。EC外の注文があるだけで、必ず二重管理になるわけではありません。

注意したいのは、取引先が同じ注文をECとFAXの両方で送る場合です。取引先の注文番号、受付経路、担当者の確認方法などを決め、同じ商品・数量という理由だけで別の注文を重複と判断しないようにします。

• 各受付経路の注文を登録するシステムと担当者
• 取引先の注文番号を保存・照合する方法
• 同じ注文が別経路で届いたときの確認手順
• 注文をまとめて出荷・請求する場合の集計条件

③ 注文変更・追加・返品を、処理状況に応じて整理する

注文受付直後と、出荷指示後・請求後では、変更できる内容が異なります。「数量変更はECから」「出荷指示後は受注担当へ連絡」など、受付窓口と処理先を状態ごとに決めます。

どちらでも自由に修正できる構成では、後から届いた古いデータが変更内容を上書きすることも考えられます。変更の順序や処理済みの状態を確認し、修正内容を反映する条件を設計します。

• 出荷指示の前後で、注文変更を受け付ける範囲
• 追加注文を既存注文へまとめるか、新規注文として扱うか
• 返品時に在庫・売上・請求をどのシステムで処理するか
• 変更を受け付けたことと、連携が完了したことを誰が確認するか

二重取込とエラーに備える運用を決める

連携が途中で止まった場合、単純に同じデータを再送すると、すでに登録済みの注文をもう一度作成するおそれがあります。EC注文番号や明細の識別番号と、基幹側で作成された番号を対応付け、どこまで処理できたかを確認する方法を用意します。

たとえば、送信後に応答が返らなかった場合、登録が失敗したとは限りません。相手側の登録状況を調べたうえで、再送するか、人が確認するかを判断できるようにします。

• 成功・失敗・結果不明を区別し、注文単位で処理状況を残す
• 一部の明細だけ失敗した場合の、注文全体の扱いを決める
• 業務上の修正が必要なエラーと、一時的な通信失敗を分ける
• 通知を受け取る担当者、不在時の連絡先、再処理の担当者を決める
• 再処理後に注文数・数量・金額などを確認する手順を用意する

管理画面や記録には、担当者が原因と対象の注文を特定できる情報を残します。すべてを自動復旧させることを前提にせず、人の判断が必要な状態も整理します。

業務ルールと既存システムの仕様を照らして方式を選ぶ

業務の希望を整理しながら、基幹システムのCSV入出力やAPIの対応範囲も確認します。すべてのルールを固めてから仕様を調べるのではなく、実現できる範囲と業務側の調整を行き来しながら決めます。

方式を選ぶ際は、必要な項目・処理に対応するか、反映期限に間に合うか、エラー対応を含めて運用できるかを比較します。APIなら即時、CSVなら手動、RPAなら短期利用のみと、一律に判断しないようにします。

相談事例に見る、連携前に整理したこと

事例1：CSVの自動取込に先立ち、コードの対応を整理

CSVで手作業運用していた受注データを、自動で基幹へ取り込みたいという相談で、ECと基幹の品番・得意先コードが一致していないことが分かりました。

そこでコードの変換テーブルを用意し、対応しきれない例外は基幹側で処理する設計に変更しました。人が読み替えていた内容を整理し、自動処理できる範囲と例外の扱いを分けた事例です。

事例2：EC外の受注を含めて、管理先を整理

電話・FAX・メールの受注を併用していた案件では、EC内外の注文を担当者が締め時に突き合わせて合算していました。

基幹を受注の集約先とし、ECを受付経路の一つとして連携する設計に変更しました。この案件では、それまで担当者が行っていた合算作業が不要になりました。同じ構成であっても、別経路から届く重複注文の確認などが必要かは、各社の運用に合わせて判断します。

公開前に確認するテストと担当範囲

通常の注文が1件取り込めることに加え、例外と再処理の確認を行います。以下をたたき台に、実際の取引条件に合わせてテスト項目を用意します。

• 取引先別の価格、数量単位、税・送料が想定どおりに反映される
• 未登録の品番や取引先コードで、処理状況と確認先が分かる
• 同じデータを再送しても、注文が二重に登録されない
• 数量変更・キャンセル・返品が、決めた状態と条件で処理される
• 通信の中断や一部明細の失敗を検知し、手順に沿って再処理できる
• 繁忙時の件数でも、出荷や請求の期限に間に合う

結果はEC側・基幹側の両方で確認します。公開可否の判断者、問い合わせ先、停止時に手作業へ切り替える範囲も決めておきましょう。

サンクユーの対応範囲や構築事例、相談から公開までの進め方は、卸売・BtoB-ECサイト構築サービスをご覧ください。取引先別価格や基幹連携を含め、自社の受注業務に合わせた構築をご相談いただけます。

関連する記事

ECと基幹システムの連携設計に関するよくある質問