Web-EDIとBtoB ECの違い：受注側が入口を選ぶための確認項目と段階導入の進め方

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

B2B EC-COLUMN

電話・FAX注文の転記が続くとき、Web-EDIとBtoB ECは何で分かれるのか

取引先ごとに電話・FAX・メールで届く注文を基幹システムへ手で入力し直していると、転記の手間と入力ミスはなかなか減りません。
受注の入口をWeb-EDIにするかBtoB ECにするかは、機能の多さで比べると決めにくくなります。
取引先が決まった形式で発注してくるのか、受注側の商品ページで商品を選んで注文するのかで分けると、判断しやすくなります。
取引先を発注の仕方で分け、併用も視野に入れながら、1社ずつ段階的に切り替えるのが現実的な進め方です。

転記と入力ミスが起きている場所を確かめる

受注担当者の手元で起きていることを順に追うと、転記がどこで発生しているかが見えてきます。
FAXで届いた注文書を読み取り、取引先の品番を自社の品番に置き換えます。
そのうえで、数量・納品日・単価を基幹システムの受注画面へ入力します。
メールの注文でも、本文や添付ファイルから同じ項目を拾い直している点は変わりません。
電話の注文なら、聞き取ったメモがもう一つの転記元になります。

入力ミスが起きやすいのは、人が読み替えて打ち直す箇所です。
手書き文字の読み違い、取引先品番と自社品番の対応の取り違え、取引先ごとに異なる単価の打ち間違いなどがこれに当たります。
受注の入口を変えるとは、この読み替えと打ち直しのうち、どれを取引先側の入力やデータのやり取りに置き換えるかを決めることだと言えます。

一方で、入口を変えても残る仕事があります。
在庫を引き当てられるか、指定の納品日に間に合うかを確かめるのは、どの入口で受けても受注側の役目です。
何が減り、何が残るかを先に分けておけば、Web-EDIとBtoB ECを比べるときに、どちらかの仕組みに期待しすぎずに済みます。

Web-EDIと標準EDIの位置づけ

EDIは、企業間で受発注などの取引データを、あらかじめ取り決めた形式で電子的にやり取りする仕組みです。
このうちWeb-EDIは、インターネットを使い、Webブラウザーの操作で受発注をやり取りするEDIを指します。
使われる通信の手順（プロトコル）は一つではないと説明されています¹。
専用の通信ソフトを用意しなくても、ブラウザーで画面を開き、注文を確認したりデータを受け取ったりできる形です。

一方、流通BMSは、取引でやり取りする電子文書（メッセージ）と、通信プロトコル・セキュリティについて定めたEDIの標準仕様です。
消費財流通業界の標準を目指しています²。
対象は、現段階では卸売・メーカーと小売の間の取引とされています²。
基本形のVer.1.0は2007年に公開されました²。
2018年には、軽減税率の区分記載請求書等保存方式に対応したVer.2.0が公開されています²。
それ以降の改訂は、公開元の最新の掲載で確かめる必要があります。

二つは別々の話に見えますが、流通BMSの標準仕様の構成には、次の項目が並んでいます³。
メッセージと運用ガイドライン、通信基盤関連の標準、導入ガイドライン、そして「流通BMSにおけるWeb-EDI」です³。
つまり、標準EDIで受ける話とWeb-EDIで受ける話は、流通BMSの範囲では同じ枠組みの中に置かれています。
ただし、Web-EDIという言葉は特定の規格の名前ではありません。
取引先から「Web-EDIで」と言われたときは、それが流通BMSに沿ったものか、取引先独自の画面かを確かめる必要があります。
どちらかによって、受注側の準備が変わるからです。

なお、流通BMSは消費財の卸・メーカーと小売の間を対象にした標準です。
工業用資材や部品など別の業種で取引先から注文を受けている場合は、この標準がそのまま当てはまるとは限りません。

「誰の画面・誰の規格で受けるか」という軸

ここまでを受注側の立場から見直すと、Web-EDIとBtoB ECの違いは「注文を誰の画面・誰の規格で受けるか」に表れます。
違いが表れるのは機能の多さではありません。
Web-EDIや標準EDIで受ける場合、注文データの項目やコード、送り方は、取引先と取り決めた規格に従います。
小売側が規格を決めて卸・メーカーに対応を求める取引では、受注側は合わせる側に立ちます。

これに対して本記事では、BtoB ECを、受注側が商品ページと注文画面を用意する入口として扱います。
取引先はその画面で商品を選んで注文します。
注文の形式を決めるのは受注側で、取引先は自社が用意した画面を操作する利用者になります。
商品検索や取引先別の価格表示などの機能は製品ごとに異なるため、個別の機能の有無は提供者の資料で確かめる前提です。

たとえば、取引先に次の二つのタイプがあるとします。
一つは、毎週ほぼ同じ品目を補充のために発注してくるスーパーです。
もう一つは、新商品や季節品をカタログで探してFAXしてくる小規模な専門店です。
前者は取引先側の発注の仕組みから注文が出てくるので、その形式のまま受け取れれば、受注側の打ち直しが減ります。
後者は、品番を調べて書き写す作業が取引先側で起きています。
受注側の商品情報を見ながら選べる画面があれば、書き間違いの元そのものを減らせる可能性があります。
同じ「受注の入口を変える」でも、減らしたい転記の場所が違うのです。

▼ 図の内容を文字で読む

• 電話・FAX・メールで受ける（現状）
  • 取引先の品番を自社の品番に置き換える
  • 数量・納品日・単価を基幹システムへ入力し直す
• 取引先の規格で受ける（Web-EDI・標準EDI）
  • 項目やコード、送り方は取引先と取り決めた規格に従う
  • 受注側は合わせる側に立つ
• 自社の注文画面で受ける（BtoB EC）
  • 受注側が商品ページと注文画面を用意する
  • 取引先は画面で商品を選んで注文する

標準EDI（流通BMS）やWeb-EDIで受ける場合、受注側に何が求められるのか

流通BMSが扱う業務の範囲

取引先が標準EDIで発注してくる場合、受注側がやり取りするのは注文だけではありません。
流通BMSは、スーパー・グロサリー業界の基本形として、8種類の標準メッセージを定めています²。
これらは、発注・出荷・受領・返品・請求・支払の6業務に対応しています²。
取引の形はターンアラウンド型とされ²、発注に応じて出荷や請求のやり取りが続いていきます。
百貨店向けには、別に26種類のメッセージがあります²。

受注側から見ると、受注の入口を標準EDIにするという判断は、その取引先との関係全体に及びます。
出荷の連絡から請求までが、同じ規格でつながることになるからです。
注文を受け取る画面だけを替えるつもりでいても、出荷の段階で何を返すか、請求をどの形で送るかまで決める必要が出てきます。
そのため、範囲の確認は受注担当者だけで進めず、出荷・請求を担う部署と一緒に行うほうが安全です。
後で手作業が残る場所を見落としにくくなります。

Web-EDIで受ける場合も、転記の減り方は受け取り方によって大きく変わります。
ブラウザーの画面で注文を確認するだけで終わるのか、受注データをファイルとして取り出して基幹システムへ取り込めるのかで違うのです。
画面に表示された注文を見ながら基幹へ打ち直すなら、FAXを読み取る作業が画面を読み取る作業に変わっただけです。
打ち直しは残ります。
取引先のWeb-EDIを利用する場合は、次の2点を最初に取引先へ確かめる項目に入れておくとよいでしょう。
受注データの取り出し方と、出荷・請求の入力をその画面で行うのかどうかです。

取引先1社ずつの切替にかかる手間

もう一つ見落としやすいのが、取引先の数だけ調整が必要になる点です。
日経クロステックの記事では、約500弱の小売店とEDIで取引する受注側の企業が紹介されています¹。
この企業は、旧来の通信手順（JCA手順・全銀手順・全銀TCP/IP手順）から、IP網に対応した手順への切替を迫られていました¹。
切替は小売店1社ずつ日程を調整して進め、事前の調整から利用開始までに約1カ月かかるとしています¹。

この話から読み取れるのは、切替の手間が取引先の数に応じて積み上がるということです。
相手の都合に合わせて日程を組み、事前の調整を済ませ、利用を開始する。
1社あたりの作業が小さくても、この段取りは社数分だけ繰り返されます。
受注側は自社の都合だけで一斉に切り替えることができず、取引先の準備に合わせて進めることになります。

ただし、これは2016年時点での1社の発言で、旧来の通信手順から新しい手順へ移る場面の話です。
新たにEDIで受注を始める場合の所要期間や、業界一般の目安としては使えません。
自社で見積もるときは、対象になる取引先の数と、それぞれの取引先が切替にどれだけ対応できるかを、取引先ごとに聞き取っていくことになります。

▼ 図の内容を文字で読む

1. 発注
   • 注文を受け取る
2. 出荷
   • 出荷の段階で何を返すか決める
3. 受領
4. 返品
   • 発生した場合
5. 請求
   • 請求をどの形で送るか決める
6. 支払

出典：流通BMSの基本形（スーパー・グロサリー業界、8種類の標準メッセージ）。百貨店向けは別に26種類のメッセージがある

取引先の発注の仕方と商品点数で、どちらを主にするかを選ぶ

定型・反復発注の取引先

ここからは、自社の取引先をどちらの入口に寄せるかを考えます。
出発点は、取引先がどのように発注しているかです。
決まった品目を、決まった周期で、似た数量で繰り返し発注してくる取引先がいます。
こうした取引先では、発注の仕組みや手順が取引先側ですでに固まっている場合があります。

こうした取引先が標準EDIやWeb-EDIで発注できる、あるいは対応を求めてくるなら、その形式で受け取れるように整えるのが自然な方向です。
取引先にとっては、今の発注のやり方を変えずに済みます。
受注側にとっては、FAXを読み取って打ち直す作業を減らせます。
反対に、こうした取引先にBtoB ECの画面から改めて商品を選んで注文してもらうとどうなるでしょうか。
取引先の発注担当者は、自社の仕組みと受注側の画面とで二度入力することになりかねません。

どの取引先がこの型に当たるかは、印象ではなく自社の受注履歴で確かめられます。
過去数カ月分の受注データを取引先別に並べ、次の点を見てみます。
注文の回数、品目の顔ぶれがどれだけ毎回同じか、1回の注文の行数です。
これらを見ると、定型的な取引先とそうでない取引先が分かれてきます。
担当者の感覚では「いつも同じ注文」と思っていた取引先が、実際には品目が頻繁に入れ替わっていることもあります。

商品を探して選ぶ取引先

注文のたびに品目が入れ替わる取引先や、カタログを見て品番を書き写してくる取引先では、事情が違います。
転記ミスの元は、受注側の打ち直しだけではありません。
取引先が品番を調べて書く段階にもあります。
受注側が用意する注文画面で、商品名や規格、入数を確かめながら選んでもらえたとします。
そうすれば、品番の書き間違いや、似た商品の取り違えが起きる場所を、受注の手前で減らせる見込みがあります。

ここで考えておきたいのが商品点数です。
自社の注文画面で選んでもらうには、商品の情報を受注側が登録し、改廃のたびに更新し続ける必要があります。
扱う品目が多く、入れ替わりも激しい場合、転記の作業は減っても、商品情報を整える作業が新たに生まれます。
受注担当者の手から作業が消えるのではなく、一部は商品マスタを管理する担当者へ移ります。
このことを入口を選ぶ段階で見込んでおけば、導入後に負担の所在で揉めにくくなります。

一方で、取引先ごとに扱う品目が限られているなら、その取引先に見せる商品の範囲を絞って、更新の手間を抑える考え方もあります。
どこまで絞れるかは、使う仕組みの設定次第です。
候補の仕組みで取引先ごとに表示範囲を分けられるかは、提供者の資料や説明で確かめることになります。

取引先の習熟度と規格の指定

発注の仕方とは別に、取引先側の事情で入口が決まる場合があります。
一つは、小売側がEDIの規格を決め、取引する卸・メーカーにその規格での対応を求めている場合です。
このとき受注側に選ぶ余地は多くなく、求められた規格で受けることが取引の条件になります。
Web-EDIかBtoB ECかを比べる前に、規格を指定してくる取引先がどこかをまず洗い出しておくとよいでしょう。
そうすると、自社で選べる範囲がはっきりします。

もう一つは、取引先の担当者がパソコンでの操作に慣れていない場合です。
長年FAXで発注してきた取引先に、新しい画面を案内したとします。
操作が分からずに結局電話で確認が来れば、受注側の手間はかえって増えます。
こうした取引先には、無理に入口を変えずにFAXや電話を残し、受注側の入力方法のほうを整える選択もあります。
どの入口を残すかは取引先の負担を見て決め、全社を同じ入口へそろえることを目標にしないほうが、移行は進めやすくなります。

こう見ていくと、取引先はおおよそ次のように分かれます。
取引先の規格に合わせて受ける先、自社の注文画面へ案内する先、当面は電話・FAXのまま受ける先です。
一つの取引先の中で入口を使い分けることも考えられます。
たとえば、定番品は取引先のEDIで受け、新商品の追加注文は自社の画面で受ける、という形です。
入口が複数になるほど、価格や在庫の情報をどこで持つかが問題になってきます。

▼ 図の内容を文字で読む

• 定型・反復発注の取引先
  • 取引先の規格（標準EDI・Web-EDI）で受ける
  • 受注履歴の注文回数・品目の顔ぶれ・行数で確かめる
• 商品を探して選ぶ取引先
  • 自社の注文画面へ案内する
  • 商品情報の登録・更新の負担を見込む
• 規格を指定してくる取引先
  • 求められた規格で受けることが取引の条件になる
  • 比べる前に、該当する取引先を洗い出す
• 操作に不慣れな取引先
  • 電話・FAXを残す
  • 受注側の入力方法を整える

取引先ごとの価格・掛率・在庫・納期は、入口ごとにどこで扱うのか

導入前に確認する項目の一覧

入口の候補が見えてきたら、次に気になるのは、取引先ごとに違う価格や掛率、在庫、納期をどこで扱うかです。
電話やFAXで受けている間は、担当者がこれらを補っています。
取引先ごとの単価表を見ながら入力し、在庫や納期は問い合わせがあれば答える、という形です。
入口を変えるときは、この補っていた部分をどの仕組みが受け持つのかを決め直すことになります。

標準EDIの場合、流通BMSの標準メッセージが扱う業務は、発注・出荷・受領・返品・請求・支払です²。
ここから取引の流れの範囲は分かります。
ただし、取引先別の掛率の持ち方や、在庫を取引先へ見せる方法まで読み取れるわけではありません。
BtoB ECでも、取引先別の価格や在庫の表示ができるかは製品によって違います。
どちらの入口でも、機能があることを前提にしないことが大切です。
自社のどこに情報を持ち、どう取引先へ伝えるかを、項目ごとに決めていく必要があります。

表のうち、判断が分かれやすいのは取引先別価格の保持場所です。
基幹システムの単価マスタに取引先別の単価を持ったうえで、入口側にも同じ価格を登録すると、同じ情報を二か所で管理することになります。
どちらかを更新し忘れると、注文画面に出ていた価格と請求の価格が食い違います。
そうなれば、取引先への説明と訂正の作業が発生します。
基幹側を正として入口側へ渡すのか、入口側で持つのかを先に決めておけば、価格改定のたびに迷わずに済みます。

在庫の見せ方は、見せるかどうか自体が判断になります。
実在庫をそのまま見せると、他の取引先向けに引き当て済みの分まで「ある」と見えてしまうことがあります。
選択肢は、引き当て可能な数を見せる、「在庫あり・残りわずか」程度の目安にとどめる、見せずに受注後に回答する、などです。
どれを選ぶかで、取引先の期待と受注側の確認作業が変わります。

納期回答も同じで、注文の時点で納期を示すのか、受注後に確かめてから返すのかを決めておく必要があります。
標準EDIで受ける取引では、出荷の段階で返すデータの扱いと合わせて考えることになります。
BtoB ECでは、注文画面の表示と受注後の連絡の両方が候補になります。
どちらにしても、これまで電話で納期を答えていた担当者の判断を、どこまで画面やデータに置き換えるかを決める作業です。

価格改定時の反映手順

取引先別の価格は、一度決めれば終わりではありません。
改定のたびに、入口へ反映し直す必要があります。
たとえば、ある時期から一部の商品の単価を改める場合を考えてみます。
まず、基幹システムの単価マスタを改定日に合わせて更新します。
BtoB ECの注文画面に価格を持っているなら、同じ日に切り替えます。
最後に、改定日の前後に届いた注文に正しい単価が付いているかを照らし合わせます。

取引先のEDIで受ける場合、発注データに単価が入って届く取引では、もう一つ確かめる作業が加わります。
取引先側の単価が、改定後のものに更新されているかどうかです。
受注側が単価を改めても、取引先側の発注の仕組みに旧単価が残っていれば、届いた注文の単価と自社の単価がずれます。
改定の案内を出す時点で取引先側の反映日を確かめておけば、ずれた注文を後から一件ずつ訂正する手間を減らせます。

併用している場合は、入口の数だけ反映の作業があります。
改定のたびに、どの入口に、誰が、いつ反映するかの段取りを書き出しておきましょう。
担当者が替わっても、反映漏れに気づきやすくなります。
価格の扱いが入口ごとにばらばらになるのを防ぐには、基幹システムへの取り込みの形をそろえておくことが土台になります。

▼ 図の内容を文字で読む

1. 基幹システムの単価マスタを改定日に合わせて更新する
2. 入口へ反映する
   • BtoB ECの注文画面に価格を持っているなら同じ日に切り替える
   • 取引先のEDIで単価が載る場合は取引先側の反映日を確かめる
3. 改定日の前後に届いた注文の単価を照らし合わせる

基幹システム連携と取引先の負担から、併用・段階導入を考える

取込形式をそろえる

入口を増やすと、受注データは複数の形で届くようになります。
取引先のEDIから届くデータ、BtoB ECの注文データ、そして残した電話・FAXの注文です。
これらを別々の手順で基幹システムへ入れていると、入口ごとに担当者の作業が分かれます。
どの注文がどこから来たのかを追うだけでも手間がかかります。

そこで、入口が違っても、基幹システムへ取り込む手前で同じ項目にそろえるという考え方をとります。
そろえる項目は、受注として基幹に登録するのに必要なものです。
取引先コード、自社品番、数量、単価、納品日、入口の区別などがこれに当たります。
入口ごとの手当ては違って構いません。
EDIのデータは変換し、ECの注文データは出力し、FAXの注文は同じ項目の入力画面へ打ち込みます。
大事なのは、行き着く形を一つにしておくことです。

こうすると、取引先品番から自社品番への読み替えや、取引先別単価との照合を、入口ごとに別々に作り込まずに済みます。
減るのは、入口ごとに異なる画面や手順を使い分ける手間と、そのたびに起きる読み替えの手作業です。
一方で、データの形がそろっても、中身の確認は受注側に残ります。
指定の納品日に出せるか、数量が普段と大きく違わないか、といった確認です。
形をそろえることと中身を確かめることを分けて考えておけば、導入後に何を見ればよいかがはっきりします。

移行件数を平準化する順番

取り込みの形が決まったら、どの取引先から入口を切り替えるかを決めます。
前に挙げた事例の企業では、2016年時点で、約500弱の取引先のうち10％強がすでに移行していました¹。
移行先は、IP網に対応した流通BMSやWeb-EDIなどです¹。
同社は、残りの切替が期限の直前に集中すると間に合わなくなるおそれがあると述べています¹。
そのため、移行する件数を平準化する必要があるという見方を示しています¹。

この割合は1社の当時の状況で、業界全体の普及の度合いを示すものではありません。
それでも、この考え方は新しい入口を取引先に広げていく場面にも当てはめられます。
1社ずつ調整が要る切替を、期限や繁忙期に寄せずに分散させるという考え方です。
一度にすべての取引先を切り替えようとすると、問い合わせや不具合への対応が同じ時期に重なります。
そうなると、受注業務そのものが滞るおそれがあります。

順番の決め方に正解があるわけではありませんが、いくつかの考え方があります。
一つは、注文件数が多く、品目が定型的で、手入力の負担が大きい取引先から始める方法です。
転記が減ったかどうかを、早い段階で確かめやすくなります。
もう一つは、新しい入口に前向きな取引先で運用を固めてから、慎重な取引先へ広げる方法です。
規格を指定してくる取引先については、取引先側の予定に合わせる必要があります。
自社で順番を決める前に、まず予定を聞いておくことになります。

導入前に決めておく4項目

切替を始める前に、少なくとも次の4項目は決めて、社内で共有しておくと進めやすくなります。

対象取引先：どの取引先を、どの入口へ、どの順番で移すか。
取引先ごとに、今の入口、移す先の入口、切替の予定時期を一覧にしておきます。
進み具合と残りの件数が見えるようになります。

データ項目：基幹システムへ取り込む受注データに、どの項目を持たせるか。
取引先コード、自社品番、数量、単価、納品日に加え、どの入口から来た注文かを区別する項目を入れておきます。
後から入口ごとの件数や誤りの傾向を追えるようになります。

取込ルール：品番の読み替え、単価の照合、取り込めなかったデータの扱いを、誰がどう処理するか。
取引先品番が対応表にない場合や、単価が自社のものと違う場合にどうするかを決めておきます。
自動で取り込むのか、担当者の確認に回すのか、という判断です。

二重運用の期間：新しい入口に切り替えた後も、しばらく電話・FAXでの注文を受け付けるかどうか。
期間を決めずに両方を受け続けると、同じ注文が二つの入口から届き、二重に登録されるおそれがあります。
受け付ける期間と、その間に二重登録を見つける方法を、取引先にも伝えておくと混乱を抑えられます。

取引先ごとの注文の届き方や、規格を指定してくる取引先の有無は、社内の受注履歴を見るだけでは整理しきれないことがあります。

今の受注の入口を取引先別に棚卸しし、どの取引先をどの入口へ寄せるかの振り分けを一緒に確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
入口を分ける軸	注文を誰の画面・誰の規格で受けるか
定型・反復発注の取引先	取引先の規格（標準EDI・Web-EDI）に合わせて受ける
商品を探して選ぶ取引先	自社の注文画面へ案内し、商品情報の更新負担を見込む
操作に不慣れな取引先	電話・FAXを残し、受注側の入力項目をそろえる
価格・在庫・納期	保持場所と伝え方を入口ごとに決め、基幹を起点に反映する
切替の進め方	取引先1社ずつ、時期を分散させて段階的に

入口を増やすほど、基幹システムへの取込形式や二重運用の決め方が複雑になり、社内だけでは抜けに気づきにくくなります。 対象取引先・データ項目・取込ルール・二重運用の期間について、自社の状況で先に決めるべき点を洗い出せます。

よくある質問

Web-EDIと流通BMSは同じものですか。

同じものではありません。
Web-EDIは、インターネットを使い、Webブラウザーの操作で受発注をやり取りするEDIを指し、通信の手順は複数あります¹。
流通BMSは、消費財流通の卸・メーカーと小売の間を対象に、メッセージと通信プロトコル・セキュリティを定めた標準仕様です²。
流通BMSの標準仕様の構成には「流通BMSにおけるWeb-EDI」という項目があります³。
ただし、取引先のWeb-EDIがこの標準に沿ったものか、独自の画面かは、取引先に確かめる必要があります。

取引先から指定されたEDIと、自社で用意するBtoB ECは両方使えますか。

取引先の発注の仕方に合わせて入口を分ける形で、併用することは考えられます。
たとえば、定型的に発注してくる取引先は指定のEDIで受け、商品を探して選ぶ取引先は自社の注文画面へ案内する、という分け方です。
その際は、どの入口から来た注文も、基幹システムへ取り込む手前で同じ項目にそろえておくことが前提になります。
入口ごとに価格を別々に持つと更新漏れが起きやすいため、価格の保持場所も合わせて決めておきます。

取引先がITに不慣れな場合、どの入口を残せばよいですか。

無理に新しい画面へ移さず、FAXや電話の入口を残す選択があります。
操作が分からずに電話での確認が増えれば、受注側の手間はかえって増えるためです。
その場合も、受注側ではFAXの注文を、他の入口と同じ項目の入力画面へ打ち込む形に整えておきます。
そうすれば、入口が違っても基幹システム側の扱いはそろいます。

価格改定や掛率の変更は、入口ごとにどう反映すればよいですか。

基幹システムの単価マスタを起点にし、改定日に合わせて各入口へ同じ日に反映する段取りを決めておくのが基本です。
BtoB ECの注文画面に価格を持っているなら、その画面も同じ日に切り替えます。
発注データに単価が入って届くEDIの取引では、取引先側の単価が改定後のものに更新されているかを、改定の案内の時点で確かめておきます。
改定日の前後に届いた注文は、単価を照らし合わせます。

電話・FAXの注文を残したまま段階導入するとき、基幹システムへの入力はどう整理すればよいですか。

入口が違っても、取引先コード、自社品番、数量、単価、納品日、入口の区別といった同じ項目で基幹システムへ入れるように整理します。
電話・FAXの注文は、その項目の入力画面へ打ち込みます。
新しい入口に切り替えた取引先については、電話・FAXも受け付ける二重運用の期間を決め、同じ注文の二重登録を見つける方法を用意しておきます。

1. 1　出典：日経BP（日経クロステック）「ISDN移行のハードルは業界によって様々、EDIなどは早期対応が必要」（2016年）
2. 2　出典：GS1 Japan（一般財団法人流通システム開発センター）流通BMS協議会「流通BMS」（2018年 Ver.2.0公開時点の掲載）
3. 3　出典：GS1 Japan 流通BMS協議会「流通BMS標準仕様」（掲載時点）