基幹システム連携の項目の決め方：受注側が取込み・照合・返信で決める項目と合意手順

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

B2B EC-COLUMN

注文は届くのに基幹に載らない。止まらない最小項目は受注後の業務から逆算する

取引先から注文データは届いているのに、基幹システムに取り込むと品目が見つからない、納入先が特定できないといった理由で受注登録が止まる。
どこまで連携すれば止まらないのか、取引先の注文書を見比べても線が引けない。
そんなときは、基幹システム連携の項目を取引先の様式から決めず、自社の受注登録・在庫引当・出荷・請求が何を必要とするかから逆算します。
そこで残った最小の項目が必須です。
食い違いは変換・マスタ整備・取込時チェックのどれで吸収するかを取引先ごとに決めます。
返信と、変更・取消・重複の扱いまで一覧表にしてから、取引先と開発側の合意に進みます。

受注登録・在庫引当・出荷・請求が必要とする項目を書き出す

取引先の注文書やデータには、たくさんの項目が並んでいます。
全部を基幹システムへ取り込もうとすると、自社では使わない項目の定義や置き場所の議論にまで時間を取られます。
反対に、注文書で目立つ品名と数量だけを拾うと、出荷や請求の段階になってから「届け先が分からない」「取引先が支払照合に使う番号が無い」と気付くことになります。

どちらも、取引先の様式を出発点にしているところに原因があります。
そこで向きを逆にします。
受け取った注文が自社の中でどの工程を通るかを順に並べ、各工程の担当者がその注文を処理するときに何を見ているかを書き出します。

仮の例として、部材を卸している自社が、取引先から注文データを受け取る場面を考えます。
受注登録の担当者は、誰からの注文か、どの注文か（注文書番号と発行日）、何をいくつ、いくらで頼まれたかを見て登録します。
倉庫は、どの品目をいつまでに出すかを見て在庫を引き当てます。
出荷の担当者は、どこへ届けるか、納品書に取引先の注文書番号を載せるかを見ます。
経理は、請求先、確定した単価と数量、取引先が支払の照合に使う番号を見て請求書を作ります。

書き出してみると、同じ項目がいくつもの工程に出てくることが分かります。
注文書番号は受注登録で使うだけでなく、出荷の納品書や請求書でも取引先との照合に使われます。
こうした複数の工程にまたがる項目が欠けると、受注登録を通ったとしても後ろの工程で人が問い合わせることになり、結局どこかで処理が止まります。

標準が示す「最低限の項目」の考え方

全部を取り込まずに最小から決めるという考え方は、標準EDI（企業間で受発注データをやり取りするための共通の取り決め）の側にも表れています。
中小企業共通EDI標準は、プロバイダー（EDIのデータを中継・変換する事業者）に対応を求める注文メッセージの全項目と、業務アプリケーション（自社の販売管理などのシステム）に対応を求める最低限の項目とを分けて定めています¹。
その最低限の項目には、注文書番号や注文書発行日などが含まれます¹。

この分け方は、受け取ったデータを業務システムがすべて扱わなくても取引が成り立つように、標準自体が線を引いているということです。
ただし、標準の最低限の項目が、そのまま自社の必須項目になるわけではありません。
標準の最低限は、どの会社の業務アプリケーションにも求める共通の下限です。
自社の在庫引当や請求にとってそれで足りるかは、先ほど書き出した工程の一覧と突き合わせなければ分かりません。
最低限の項目の全名称や、品目・得意先・納入先のコードがそこに含まれるかどうかは、標準仕様書の本文で確かめてから当てにする必要があります。

中小企業共通EDI標準は、経済産業省と中小企業庁の支援のもと、ITコーディネータ協会が中心となって公開したもので、国際標準に沿ってデータ形式をそろえ、導入の手間とコストを抑えることをめざしています¹。
とはいえ、取引先がこの標準で発注しているとは限りません。
標準は自社の項目を考えるときの物差しとして使い、実際に何を受け取るかは、取引先ごとの方式で決まります。

必須と任意の線を引く基準

線を引くときの問いは一つです。
その項目が無い注文を受け取ったとき、どの工程で人が手を止めるか。
止まる工程があれば必須、後ろの工程で自社のマスタなどから補えるなら任意、どの工程も使わないなら取り込まずに保管だけにする、という順で分けていきます。

表のうち、単価と納入先を「取引先次第」にしたのには理由があります。
自社の価格マスタで単価が決まる取引なら、注文側の単価は照合のための情報で、無くても請求はできます。
一方、取引先が注文のたびに単価を指定してくる取引では、単価が無ければ請求額が確定しません。
納入先も同じで、得意先の所在地に届ける取引先なら補えますが、店舗や現場ごとに届け先が変わる取引先では、無いと出荷が止まります。

つまり必須の線は、自社の業務だけでなく、取引先との取引の形によっても動きます。
一つの基準で全取引先の必須項目を決め切ろうとせず、自社の最小セットを一つ持ったうえで、取引先ごとに追加で必須になる項目を足していくと、定義が取引先の数だけ増えることを避けられます。
そして、必須にした項目の多くは、自社のマスタと照らし合わせて初めて使える状態になります。
次に迷うのは、そこで取引先の値が自社のマスタと合わない場面です。

▼ 図の内容を文字で読む

• 必須
  • 無いと人が手を止める工程がある
• 任意
  • 後ろの工程で自社のマスタなどから補える
• 保管だけ
  • どの工程も使わないので取り込まない

取引先の項目・コードが自社マスタと合わないとき、変換・マスタ整備・取込時チェックをどう使い分けるか

品目・得意先・納入先コードの食い違い

前の節で必須にした品目・得意先・納入先は、取引先が自社のコードで書いてくるとは限りません。
取引先は自分の社内の品番で注文し、自分の会社を自社の得意先コードで名乗ることもなく、納入先には取引先側の店舗や事業所の番号を書いてきます。
データとしては項目がそろっているのに、自社のマスタに見つからないので受注登録が止まる、という状態です。

受注側が取引先ごとの違いに対応を迫られていることは、中小企業庁の記事にも書かれています。
発注元に近い階層の企業は、発注先ごとに異なるシステムへの対応が必要になり、画面がいくつも増える「多画面問題」を抱えています²。
さらに下の階層では複数システムへの対応が複雑なため、電話やFAXで受けた注文を手入力で転記する作業が多く、ミスや書類紛失のリスクがあるとされています²。

手入力で転記していたころは、担当者が取引先の品番を見て「これは自社のこの品目だ」と頭の中で読み替えていました。
連携にすると、この読み替えを人の記憶ではなく、どこかに置き場所を決めて持たせる必要があります。
コードの食い違いへの対応とは、その置き場所を選ぶことです。

単価・納期・数量単位の食い違い

単価・納期・数量単位の食い違いは、コードとは性質が違います。
コードは対応関係さえ分かれば機械的に読み替えられますが、こちらは値そのものが違っていて、どちらを正とするかの判断を伴います。

単価では、価格改定の時期が取引先と自社でずれていたり、特定の注文だけに特価が適用されていたりして、注文の単価と自社の価格マスタが合わないことがあります。
ここで自社の価格へ黙って置き換えると、受注登録は通りますが、請求の段階で取引先側の支払照合と金額が合わなくなります。
止めて確認するのか、取引先の単価を正として登録するのかを、取引先ごとに決めておく必要があります。

納期では、取引先は「納入日」で指定し、自社は「出荷日」で管理しているといったずれが起きます。
この場合は納入先までの日数を引いて出荷日に直す処理が必要で、その日数をどこで持つかを決めることになります。
数量単位では、取引先がケースで注文し、自社がバラで在庫を持っているといった違いがあります。
入数がマスタにあれば換算できますが、入数を変えた品目で古い値のまま換算すると、引き当てる量を誤ります。

変換テーブル・マスタ整備・取込時チェックの比較

食い違いを吸収する手段は、大きく次の三つに分けられます。

• 変換テーブル：取引先のコードや単位を自社のものへ読み替える対応表を、取込処理の手前に持つ
• マスタ整備：自社の品目や納入先のマスタに、取引先側のコードを持たせておく
• 取込時チェック：自社のマスタや価格と一致しない注文を取り込まずに止め、人が確認してから登録する

どれが良いかは一律には決まりません。
ここでは、誰が保守するか、取引先を追加するときの負担、誤って取り込むリスクという同じ軸で並べ、判断の材料にします。
表は編集上の整理で、特定の資料の比較結果ではありません。

表で判断が分かれるのは、保守する人の欄です。
変換テーブルは取込処理の一部なので、取引先が品番を変えたときに、その知らせが連携の担当者まで届かないと更新が漏れ、誤った品目へ読み替えたまま受注が登録されます。
マスタ整備は、取引先との窓口にいる業務部門が品目マスタを触れる体制なら、コードの変更を業務の流れの中で追えます。
取込時チェックは誤取込を防ぐ代わりに、確認する人の手が空かないと受注登録そのものが遅れます。

三つは排他ではありません。
仮の例なら、品目コードと納入先はマスタに取引先コードを持たせ、ケースとバラの換算は入数を使って取込時に計算し、単価の不一致だけは取込時チェックで止めて担当者が確認する、という組み合わせが考えられます。
コードのように対応関係で済むものは機械に任せ、値の判断が要るものだけを人に回すと、確認の手間を必要な注文に絞れます。

自社の外で吸収する選択肢もあります。
中小企業共通EDI標準では、発注側と受注側がそれぞれ対応するプロバイダーと契約すれば、データ変換はプロバイダーが担う設計になっています¹。
形式の違いを自社の取込処理の外に出せるのは、取引先が増えたときの負担を考えると大きな違いです。
ただしこれは同標準に沿って取引する場合の設計で、料金や、取引先の品番から自社の品目コードへの読み替えまで引き受けるかといった対応範囲は、個別の契約によります。

▼ 図の内容を文字で読む

• 変換テーブル
  • 連携を担う情シスや開発側が保守する
  • 対応表の更新漏れで別の品目に読み替える恐れがある
• マスタ整備
  • マスタを管理する業務部門が保守する
  • 登録漏れは不一致として表に出やすい
• 取込時チェック
  • 注文を処理する担当者が確認する
  • 確認待ちが溜まると受注登録が遅れる

EDI・API・CSV、連携方式で扱える項目と運用負担はどう変わるか

標準EDI（中小企業共通EDI・流通BMS）の項目定義

前の節の読み替えを、連携方式の違いに置き換えて見ると、方式による差がはっきりします。
方式の違いとは、項目の名前と意味を、誰がいつ決めておくかの違いです。

標準EDIでは、項目の定義が取引先と自社の外で先に決まっていて、双方が同じ定義を参照できます。
中小企業共通EDI標準は先に触れたとおり、注文メッセージの項目と、業務アプリケーションに求める最低限の項目を定めています¹。

流通BMSは、流通システム標準普及推進協議会が公開している標準で、スーパー業界とグロサリー業界の基本的な取引形態であるターンアラウンド型取引を対象に、発注・出荷・受領・返品・請求・支払の業務を標準メッセージにしています³。
対象がこの業界の取引形態なので、ほかの業種の受注側にそのまま当てはまるとは限りません。
また標準は改定されているため、取引先がどの版でやり取りしているかを合わせて確かめる必要があります。

CSV・Excel取込、個別API連携で自社が決めること

CSVやExcelのファイルで注文を受けて取り込む場合、項目の並び、文字コード、日付の書き方、数量の単位、空欄の扱いを、自社と取引先の間で一から決めることになります。
始めるまでの準備は少なく済みますが、取引先ごとに少しずつ違うファイルが届くようになると、取込の設定も取引先の数だけ増えていきます。

個別のAPI連携（システム同士がプログラムで直接データを受け渡す方法）も、項目の定義は相手との間で決まります。
取引先のシステムが仕様を出してくる場合、受注側は相手の仕様に合わせて接続を作ることになり、取引先が増えるたびに別の仕様に向き合います。
先ほどの「多画面問題」を、画面ではなく接続の数で抱える形です。

どちらの方式でも負担を抑える鍵は、第1節で作った自社側の項目一覧を「取込先の定義」として一つだけ持つことです。
取引先ごとの違いは、その定義へ写すための対応表として持ちます。
こうすると、取引先が増えても自社の基幹システム側の定義は変わらず、増えるのは対応表だけになります。

方式の比較表

判断が分かれるのは右端の列です。
標準EDIでは定義がすでに共有されているので、新しい取引先を迎えるときの作業は、自社の定義との対応を確かめることが中心になります。
CSVや個別APIでは、取引先ごとに定義を取り決めるところから始まります。
この差がどれだけの工数になるかは、取引先の数や形式のばらつきによって変わり、一律の目安は示せません。

もう一つ、受注側が方式を自由に選べるとは限らない点にも触れておきます。
取引先がすでに使っている方式に合わせることになる場面では、選ぶというより、その方式で項目定義をどこまで共有できるかを見極める作業になります。
標準EDIで受け取れる取引先が増えるほど、自社側の対応表は標準との対応一つにまとめやすくなります。

▼ 図の内容を文字で読む

• 標準EDI
  • 項目の定義が外で先に決まっている
  • 双方が同じ定義を参照できる
• CSV・Excel取込
  • 項目の並び・文字コード・日付・単位・空欄の扱いを決める
  • 取引先ごとに取込の設定が増える
• 個別API連携
  • 取引先の仕様に合わせて接続を作る
  • 取引先が増えるたびに別の仕様に向き合う

受注後に取引先へ返す情報はどこまで連携するか

受注確認・納期回答

受け取る項目が決まったら、次は返す項目です。
注文を出した取引先がまず知りたいのは、注文が届いたか、いつ届くかの二つです。

この二つは、返せるタイミングが違います。
受注確認は、取込が終わった時点で「受け付けた」「確認のため保留している」と返せます。
納期回答は、在庫引当の結果が出なければ返せません。
タイミングが違えば返す項目の出どころも違い、受注確認は取込の結果から、納期回答は引当の結果から作ることになります。

どちらにも欠かせないのが、取引先側の注文書番号です。
取引先は自分の番号で注文を管理しているので、自社の受注番号だけを返しても、どの注文への回答なのか取引先側で照合できません。
第1節で注文書番号を必須にしたのは、受け取る側の都合だけでなく、返す側の都合でもあります。
分納になる場合は、明細ごとの回答数量と回答納期も必要になります。

出荷・請求情報

標準の側では、流通BMSが出荷・受領・請求などを業務ごとのメッセージとして分けています³。
同じ業界でなくても、返す情報の候補をこの業務の区切りで洗い出すと、漏れに気付きやすくなります。

出荷の情報では、出荷日、出荷数量、納入先、そして元の注文書番号との対応が中心になります。
請求の情報では、どの注文・どの出荷に対する請求か、単価と数量、合計の金額が求められます。

ここで、第2節の単価の判断が効いてきます。
取込時に取引先の単価を自社の価格へ置き換えて受注登録していた場合、その単価で請求データを返すと、取引先側では注文時の単価と照合が合いません。
受け取るときの食い違いの処理と、返すときの値は、同じ一覧表の上で一緒に決めておく必要があります。

返す範囲の決め方

標準にメッセージがあることは、それを全部返す義務を意味しません。
何を連携で返すかは、取引先との合意で決まります。

順序としては、取引先が受注処理の後に必要とする受注確認と納期回答を先に決め、出荷と請求の情報は自社の出荷・請求業務が持っている項目から逆算して足していく、という進め方を勧めます。
出荷や請求の情報は自社の業務の中ですでに作られているので、新しく作る項目は少なく、返す形をそろえることが中心になります。

いまメールや紙で取引先に返している情報を並べてみると、どれを連携に移すと取引先側の転記が減り、どれは書類のままで構わないかが見えてきます。
返信を連携しないと決めた情報は、取引先からの問い合わせという形で戻ってくることがあるので、その窓口も含めて決めておきます。

▼ 図の内容を文字で読む

1. 取込が終わる
2. 受注確認を返す
3. 在庫引当の結果が出る
4. 納期回答を返す

変更・キャンセル・エラー・重複注文は、状態と処理ルールを先に決める

識別項目で重複・変更・取消を見分ける

連携を始めると、同じ注文が二度届く、数量だけ変わった注文が届く、取り消しの連絡が届く、といった場面が出てきます。
標準EDIを使う場合も、変更や取消がどう表現されるかは採用する標準の仕様書と取引先との取り決めで確かめる必要があります。
そのうえで自社側では、届いた注文をどう判定するかのルールを先に持っておくことを提案します。

判定の手掛かりになるのは、注文書番号と注文書発行日です。
この二つは、中小企業共通EDI標準が業務アプリケーションに求める最低限の項目に含まれています¹。
提案する判定は次のとおりです。

• 注文書番号が未登録なら、新規の注文として取り込む
• 注文書番号が登録済みで内容が同じなら、再送による重複として取り込まない
• 注文書番号が登録済みで数量や納期が違うなら、変更として扱うか、確認待ちに回す
• 取消を示す指示が届いたら、取消として扱う（どう表すかは取引先との取り決めによる）

判定で迷いやすいのは、基幹側の受注がすでに進んでいる場合です。
引当済みや出荷済みの注文に変更が届いたとき、自動で上書きすると、倉庫ではすでに出した数量と受注データが食い違います。
受注の状態ごとに、自動で反映するか、止めて人が確認するかを分けておくと、変更が届いたときの迷いが減ります。

取込エラー時の戻し先と連絡

取込時チェックで止めた注文や、判定で確認待ちに回した注文は、止めただけでは片付きません。
誰がその注文を見るのか、取引先に何を問い合わせるのか、直した注文をどの経路で入れ直すのかを、取引先ごとに決めておく必要があります。

入れ直しの経路は、後の照合に影響します。
取引先に正しいデータを再送してもらう場合は、同じ注文書番号で届くので、先ほどの判定を通って変更として扱われます。
自社の担当者が受注データを直接直す場合は、取引先の手元のデータと自社のデータが食い違ったままになるので、受注確認や納期回答で直した内容を返して、取引先側にも知らせる必要があります。

取込テストで確かめる3パターン

判定ルールは、本番の注文で初めて試すと、問題が起きたときには既に引当や出荷が進んでいます。
本番の前に、次の三つのパターンを取込テストで流し、基幹システムの受注データがどうなるかを確かめます。

• 同じ注文書番号の注文を、内容を変えずにもう一度送る
• 同じ注文書番号で、数量だけを変えた注文を送る
• 同じ注文書番号の注文に、取消の指示を送る

見るところは、受注が二重に登録されていないか、変更が元の受注の上書きになるのか別の受注として増えるのか、取消で引当がきちんと戻り、請求の対象から外れるか、です。
同じ三つを、未引当の状態だけでなく、引当済みや出荷済みの状態でも流してみると、受注の状態ごとに決めたルールが実際の動きと合っているかが分かります。
結果が想定と違えば、判定ルールか取込の仕様のどちらを直すかを、この段階で開発側と決められます。

▼ 図の内容を文字で読む

1. 注文書番号と発行日で照合
2. 新規・重複・変更・取消に分ける
3. 受注の状態を確認
4. 反映するか確認待ちにする

連携項目を取引先・開発側と合意する順序と、整える一覧表

合意用の一覧表の列

ここまでの判断を、取引先とベンダーに「この項目で連携したい」と示せる一覧表にまとめます。
列は次のように置くことを提案します。

• 自社の項目名
• 取引先側の項目名
• 必須か任意か
• 自社マスタとの照合方法
• 食い違い時の処理
• 返信の要否

取引先側の項目名の列を置くのは、第3節で触れたとおり、自社の定義を一つに保ったまま取引先ごとの違いを対応として書き込むためです。
取引先が増えたら、この列を取引先ごとに増やしていきます。

仮の例で品目の行を埋めると、自社の項目名は品目コード、取引先側は取引先品番、区分は必須、照合方法は品目マスタに持たせた取引先品番で照合、食い違い時は取込時チェックで確認待ちにして取引先に問い合わせ、返信は納期回答と出荷で品目を返す、となります。
一行ずつ埋めていくと、第2節や第4節で決めきれていなかった項目が空欄として浮かび上がるので、合意の場に持ち込む前に詰めるべきところが分かります。

作成と合意の順序

一覧表は、第1節の自社の最小セットから始め、コードの照合方法、方式、返信、例外の順に埋めていきます。
取引先の方式がすでに決まっているなら、方式を前提として最初から置いておけば構いません。
並行できるところは並行して進めます。

順序で大事なのは、最小セットを社内で固めてから取引先に示すことです。
先に取引先に聞くと、取引先の様式が自社の必須項目の出発点になり、第1節で避けたかった状態に戻ってしまいます。
社内では、受注登録の担当者だけでなく、倉庫と経理にも各工程で見ている項目を挙げてもらいます。
開発側へは、食い違い時の処理と例外の判定ルールが決まった段階で渡すと、取込処理の仕様として組み込みやすくなります。

実証プロジェクトの削減効果の読み方

データ連携で受発注の業務がどれだけ軽くなるかについては、中小企業庁の記事に、複数の業界と地域で行われた実証プロジェクトで中小企業の業務時間の削減効果が得られたという報告があります²。
ただし、この実証はプロバイダーとなるITベンダーの協力で選定されたプロジェクトで、記事には測定方法や期間の詳しい説明がありません²。
連携の方向性を示す材料にはなりますが、自社でどれだけ減るかの見込みには使えません。

自社の見込みを立てるなら、いま注文一件ごとに、どの画面からどの画面へ何を書き写しているかを数えるほうが確かです。
連携で減るのは、品名や数量を基幹システムへ打ち直す転記と、打ち直した内容を注文書と見比べる確認です。
一方で、取込時チェックで止まった注文の確認、取引先のコード変更に合わせたマスタや対応表の保守、変更・取消の判定の見直しといった作業は残ります。
一覧表の「食い違い時の処理」の列は、そのまま連携後に残る仕事の一覧でもあります。

▼ 図の内容を文字で読む

1. 社内で最小セットを決める：受注・倉庫・経理が工程ごとの項目を挙げる
2. 食い違いの処理を決める：変換テーブル・マスタ整備・取込時チェックを選ぶ
3. 取引先と合意する：方式と取引先側の項目名、返信の範囲を合わせる
4. 開発側へ渡して確かめる：一覧表を取込仕様にして取込テストで流す

自社の最小セットは書き出せても、取引先ごとの食い違いを変換・マスタ・取込時チェックのどこで持つかは、基幹システムの取込仕様や社内の保守体制が絡み、担当者だけでは決めきれないことがあります。

いまの受注項目と、取引先ごとの様式の違いを持ち寄っていただければ、どの項目から照合方法を決めると合意が早いかを一緒に確かめられます。無料相談で要件を整理する

要点の整理

必須項目の決め方	取引先の様式ではなく、受注登録・在庫引当・出荷・請求の工程から逆算する
必須と任意の線	欠けたときに止まる工程があれば必須、補えるなら任意、使わなければ保管のみ
コードの食い違い	変換テーブル・マスタ整備・取込時チェックを、保守する人・追加時の負担・誤取込リスクで選ぶ
単価・納期・単位	どちらの値を正とするかを取引先ごとに決め、判断が要るものは止めて確認する
連携方式	標準EDIは定義を共有でき、CSV・個別APIは取引先ごとに定義を取り決める
返信	受注確認・納期回答を先に決め、出荷・請求は自社の業務の項目から足す
変更・取消・重複	注文書番号と発行日で判定し、受注の状態ごとに反映か確認待ちかを決める
合意の順序	社内で最小セットを固めてから取引先へ、判定ルールが決まってから開発側へ

一覧表を取引先と開発側に出す前に、返信の範囲や変更・取消の判定ルールに抜けがないかを、受注業務の流れに沿って見直しておくと、合意後の手戻りを減らせます。 作成中の一覧表をもとに、空欄になっている項目や、取込テストで流すべき状態の組み合わせを確かめられます。

よくある質問

商品コードや得意先コードは、受注連携の必須項目に含めるべきですか。

自社の受注登録や在庫引当、請求でそのコードを使って照合しているなら、必須に含めるのが自然です。
ただし、取引先が自社のコードで書いてくるとは限らないので、取引先側のコードを受け取り、変換テーブルやマスタに持たせた取引先コードで自社のコードへ読み替える形が現実的です。
標準EDIの最低限の項目にこれらのコードが含まれるかは、採用する標準の仕様書で確かめてください。

取引先ごとに注文書の様式が違うときは、項目の定義を取引先の数だけ作る必要がありますか。

自社の基幹システム側の定義は一つに保てます。
受注後の工程から逆算した自社の項目一覧を取込先の定義として持ち、取引先ごとの違いは、その定義へ写すための対応表として持ちます。
取引先が増えたときに増えるのは対応表だけです。
取引先が中小企業共通EDI標準に沿っていて、双方が対応するプロバイダーと契約すれば、形式の変換はプロバイダーが担う設計もあります。

中小企業共通EDIと流通BMSは、どちらに対応すればよいですか。業種で選び方は変わりますか。

受注側から見ると、取引先がどちらで発注しているかで決まる場面がほとんどで、自社だけで選ぶものではありません。
流通BMSはスーパー業界とグロサリー業界のターンアラウンド型取引を対象にした標準なので、その業界の取引先から受注するなら関係が深くなります。
どちらの場合も、取引先が使っている版と、自社の項目一覧との対応を確かめることが先です。

同じ注文が二重に届いたとき、重複と変更をどう見分ければよいですか。

注文書番号と注文書発行日を手掛かりにする方法を提案します。
番号が登録済みで内容が同じなら重複、数量や納期が違うなら変更として扱うか確認待ちにします。
取消をどう表すかは取引先との取り決めによります。
本番前に、同じ番号の再送・数量変更・取消を取込テストで流し、受注が二重にならないか、引当が正しく戻るかを確かめてください。

注文を受けた後、納期回答はどのタイミングで取引先へ返すのがよいですか。

納期回答は在庫引当の結果がなければ返せないので、引当が確定する時点を基準に取引先と合意するのが筋です。
取込直後に返せるのは受注確認で、納期回答とは返す時点も項目の出どころも違います。
取引先がどの時点で回答を必要としているかと、自社の引当がいつ確定するかを突き合わせて決めます。

CSV取込から標準EDIに移るとき、既存の項目定義はどこまで使えますか。

受注後の工程から逆算した自社側の項目一覧と、食い違い時の処理、変更・取消の判定ルールは、方式が変わってもそのまま使えます。
変わるのは取引先側の項目名の列で、取引先ごとに取り決めたCSVの列から、標準の項目定義との対応へ書き換えることになります。
標準の最低限の項目と自社の必須項目の差は、移行の際に改めて確かめてください。

1. 1　出典：中小企業庁（ミラサポplus）「中小企業共通EDI標準」（2018年）
2. 2　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（掲載年不詳）
3. 3　出典：流通システム標準普及推進協議会「流通BMS標準仕様」（2007年 基本形Ver.1.0公開）