まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

電子受発注の標準データ形式と変換:自社はどれに合わせ、何を手作業で残すか

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 電子受発注の標準データ形式は取引範囲ごとに分かれ、消費財流通なら流通BMS、業種を問わない中小企業向けには中小企業共通EDIがある。
  • 中小企業共通EDIはプロバイダによる変換を前提にした設計で、標準か変換かの二択ではなく、取引範囲ごとに標準で決まる部分と変換で埋める部分を切り分けて考えられる。
  • 変換で揃うのは主に項目の意味で、商品コード・取引先コード・入数などの値の対応は、自社のマスタや対応表に必要な情報があるかで決まる。
  • 相手ごとの項目対応表で空欄・不一致を洗い出し、マスタへの追加、相手との取り決め、人の確認に分けて手作業で残すものを決める。
  • 導入前は相手の形式の確認と対応表の作成を並行し、例外の扱いを決めてから過去の実際の注文で試験する。

40代後半の日本人女性が二人で画面を覗くをしている場面

取引先から電子受発注を求められたとき、形式の違いは業務のどこで問題になるのか

たとえば、ある取引先からは専用画面、別の取引先からは表計算ファイル、さらに別の取引先からは独自形式のデータで注文が届き、そのたびに品名や単位を自社の基幹システムの項目へ置き換えているとします。
この場合、電子受発注を求められて紙が電子データに変わっても、形式が違えば置き換えの作業は人の手に残ります。
電子受発注の標準データ形式は一つではありません。
消費財流通なら流通BMS、業種を問わない中小企業向けには中小企業共通EDIがあります。
中小企業共通EDIはプロバイダによる変換を前提にした設計なので、標準か変換かの二択でもありません。
まず自社の取引範囲に当たる標準を確かめ、次に相手ごとの項目対応表で、変換しても残る項目を洗い出すと、どこまで揃えて何を手作業で残すかを決められます。

注文を受けてから基幹システムに入るまで

受注側の業務で考えると、注文が届いてから基幹システムに登録されるまでには、次の作業が続きます。
受け取る、読み取る、自社の項目へ置き換える、入力する、内容を確かめる、の順です。
このうち、形式の違いがそのまま負担になるのは置き換えの部分です。
たとえば、ある取引先は「納期」、別の取引先は「納品希望日」という名前で同じ日付を送ってきます。
商品も、相手は相手側の商品コードで指定し、自社の基幹システムは自社品番で管理している、ということが起こります。
数量も、相手が「ケース」、自社が「個」で持っていれば、入数を掛けて直す必要があります。

紙やFAXの注文が電子データに変わると、文字を打ち込む手間は減ります。
しかし、届いたデータが相手の形式のままなら、項目名・コード・単位を自社の形式へ読み替える作業は残ります。
読み替えをプログラムや変換の仕組みが担うか、人が担うかが違うだけで、作業そのものは消えません。
取引先ごとに形式が違えば、読み替えのルールも取引先の数だけ必要になります。
担当者は、どの相手の注文かを見分けながら作業することになります。

電子受発注を求められたときに考えるべきなのは、データが電子になるかどうかよりも、この読み替えを誰が、どこで、どのルールで行うかです。
相手の形式と自社の形式の差が小さければ、読み替えは少なく済みます。
差が大きければ、電子化しても再入力や目視の照合が続きます。

発注側と受注側で再入力が起きる場所の違い

読み替えが起きる場所は、自社が発注する側か、注文を受ける側かで逆になります。
受注側では、相手から届いた注文を自社の基幹システムに取り込む入口で読み替えが発生します。
発注側では、自社のシステムで作った発注データを、相手ごとの形式に合わせて送り出す出口で発生します。
さらに発注側は、相手から返ってくる出荷の知らせや請求のデータを自社の発注と突き合わせる場面でも、同じ問題を抱えます。

もう一つの違いは、どちらの形式に合わせるかを誰が決めるかです。
取引先から特定の形式での送受信を求められた場合、受け取る側は相手の形式を前提に準備を始めることになります。
反対に、自社が取引先へ電子化を呼びかける立場なら、相手に求める形式を自社が選ぶことになり、その選択が相手の負担を左右します。
どちらの立場でも、形式は自社だけで決められるものではなく、相手との関係の中で決まる部分があります。
そのため、自社の都合だけで形式を選ぶ前に、相手がすでに何に対応しているかを知ることが出発点になります。

注文を受けてから基幹システムに入るまでの作業順(模式図)
受け取る、読み取る、自社の項目へ置き換える、入力する、確かめるの順に並び、置き換えの段階で項目名・コード・単位の違いが負担になることを示す図

電子受発注の標準データ形式にはどんなものがあり、自社の取引ではどれが関係するのか

流通BMS:消費財流通向けの標準

EDI(企業間で注文や請求などの取引データを電子的にやり取りする仕組み)の標準のうち、消費財の流通で使われているのが流通BMSです。
流通BMSは、消費財流通業界で唯一の標準を目標とするEDIの標準仕様です。
やり取りするメッセージの形式に加えて、通信の手順やセキュリティまで定めています3。
当初の対象は、スーパーやグロサリーの業界のうち、発注を起点に同じ取引のデータが行き来するターンアラウンド型と呼ばれる取引でした。
その後、アパレル、生鮮、チェーンドラッグストア、ホームセンター、百貨店へと対象が広がっています2。

受発注の標準といっても、扱うのは注文だけではありません。
初期版の時点で、発注、出荷、受領、返品、請求、支払の6つの業務について、8種類の標準メッセージが用意されていました2。
現在の版ではメッセージの種類が異なる可能性があるため、取引先と接続するときは、相手がどの版を使っているかを確かめる必要があります。
この広がりは、自社がどこまで電子化するかの判断に関わります。
注文だけを電子データで受け、出荷の知らせや請求を従来どおり紙で返していると、後工程で再び読み替えと転記が生じます。
流通BMSに合わせるなら、注文の後に続く書類までを一連の範囲として見ておくほうが、手作業がどこに残るかを見通しやすくなります。

項目の対応づけに使える公式の資料もあります。
基本形Ver2.2.2については、メッセージ項目一覧とマッピングシートが提供されています3。
マッピングシートは、自社のデータのどの項目が標準のどの項目に当たるかを対応づけるための資料で、後で触れる項目対応表を作る際の土台になります。
一方で、流通BMSは消費財流通のための仕様です。
製造業の部材調達のように対象業界の外にある取引には、そのまま当てはまりません。

中小企業共通EDI:業種を問わない中小企業向けの仕様

業界を限らず中小企業どうしの受発注をつなぐ考え方で作られたのが、中小企業共通EDIです。
中小企業庁が紹介している平成28年度の実証事業では、12のプロジェクトを選んでEDI導入の効果を測るとともに、国連CEFACTの共通辞書に準拠したEDI仕様の策定を目指しました1。
国連CEFACTは貿易や電子取引の手続きの標準化を進める国連の組織で、共通辞書は、取引データの項目が何を意味し、どう表すかを定めたものです。
業界ごとに異なる呼び方をしていた項目を、共通の意味の上で対応づけられるようにする、という発想です。

この仕様のもう一つの特徴は、変換を前提にしていることです。
プロバイダ(企業の間に入ってデータの受け渡しを担う事業者)が必要な情報を変換することで、各企業は統一されたデータを使えるとされています1。
取引先が全員同じ形式に揃えるのを待つのではなく、それぞれが使っている形式とのあいだを変換でつなぐ設計です。
流通BMSが業界で一つの形式に揃えることを目標にしているのに対し、こちらは意味を揃え、形式の差は変換で吸収するところに重心があります。

同じ実証では、効果の数字も示されています。
受発注データ連携の実証プロジェクト12件では、中小企業の業務時間が平均で51.4%削減されたと報告されています1。
これは平成28年度補正の実証事業という限られた条件での平均値で、受発注のデータ連携を導入したことによる効果です。
形式の変換だけで得られた数字ではなく、自社で同じ割合の削減が見込めることを示すものでもありません。
読み取れるのは、受発注の手作業がデータ連携によって大きく変わった実証例がある、というところまでです。

自社の取引相手の業界に標準があるかの確かめ方

どの標準が関係するかは、自社の業種よりも、主な取引相手がどの業界にいるかで決まります。
たとえば食品メーカーでも、スーパーや百貨店へ納める取引では流通BMSが関係し、原材料を仕入れる取引では別の形式が使われている、ということがあり得ます。
同じ会社の中でも、取引の範囲ごとに関係する標準が変わるわけです。

確かめる方法として最も確実なのは、取引先にどの形式でやり取りしているかを尋ねることです。
相手が流通BMSや中小企業共通EDIに対応していれば、その名前と版が分かります。
消費財流通以外の業界にも、業界ごとに独自のEDI標準が定められている場合があります。
相手が業界標準の名前を挙げたときは、その業界団体の公開資料で対象と仕様を確かめます。
相手が「特に標準はなく自社の形式で送っている」と答えた場合は、標準に合わせる話ではなく、相手の形式との差をどう埋めるかの話になります。

取引先が業種も規模もさまざまな中小企業で、共通の業界標準が見当たらない場合は、中小企業共通EDIのように業種を問わず意味を揃える仕様が候補になります。
二つの標準の違いを整理すると、次のようになります。

観点 流通BMS 中小企業共通EDI
対象 消費財流通(スーパー・グロサリー・アパレル・生鮮・チェーンドラッグストア・ホームセンター・百貨店) 業種を問わない中小企業の受発注
扱う業務 初期版で発注・出荷・受領・返品・請求・支払の6業務 受発注のデータ連携(実証の対象)
形式の揃え方 業界で唯一の標準を目標にする 国連CEFACTの共通辞書に準拠しプロバイダの変換を前提にする
項目の対応づけに使える資料 基本形Ver2.2.2のメッセージ項目一覧とマッピングシート 共通辞書に基づく仕様
取引相手の業界で関係する標準の分け方(模式図)
流通BMS、中小企業共通EDI、業界独自のEDI標準の三つについて、対象と形式の揃え方を分けて示した図

標準形式に揃える場合と、変換で受け渡す場合の負担はどう違うのか

比較表:自社が変える範囲・相手に求める範囲・継続して残る作業

標準に揃えるか、変換で受け渡すかを比べるとき、導入時の手間だけを見ると判断を誤りやすくなります。
自社のデータをどこまで変えるか、相手に何を求めるか、接続した後も何が作業として残り続けるか、の3つを並べると違いが見えてきます。
ここでは、流通BMSに合わせる方法、中小企業共通EDIとプロバイダの変換を使う方法、相手の形式に個別に対応する方法を比べます。

表の中で判断が分かれるのは、主に「相手に求める範囲」と「継続して残る作業」の関係です。
相手の形式に個別に対応する方法は、相手に何も求めないため、取引先との調整が少なく始めやすい方法です。
その代わり、自社が引き受ける読み替えのルールは相手の数だけ増えます。
相手がシステムを入れ替えれば、そのたびに自社側を直すことになります。
取引先が一社や二社のうちは目立たない負担でも、相手が増えるにつれて保守の対象が積み重なっていきます。

標準に合わせる方法は逆の性格を持ちます。
最初に自社データを標準の項目へ対応づける手間はかかりますが、同じ標準を使う相手とは、その対応づけを使い回せます。
ただし、相手も同じ標準に対応していることが前提で、対応していない相手の分は別の方法が要ります。
また、標準は版が改められることがあるため、追従する作業は継続して残ります。

どちらの負担が軽いかを数値で比べられる資料はなく、取引先の数、相手の対応状況、自社の基幹システムの改修のしやすさによって答えが変わります。
判断の手掛かりとして大きく効くのは、相手の数が増える見込みがあるか、主な相手が同じ標準を使っているか、の2点です。

標準と変換を併用する設計

比較表の2行目が示すように、標準と変換は対立するものではありません。
中小企業共通EDIでは、プロバイダが必要な情報を変換することで、仕様の異なる企業どうしでも統一されたデータを使えるとされています1。
標準を各社の形式のあいだに置く共通の中間形式として使い、その前後を変換でつなぐ、という考え方です。

この設計の利点は、自社が用意する対応づけが、相手ごとではなく共通の形式に対して一つで済むところにあります。
自社は自社の形式と共通の形式の対応だけを決め、相手は相手の形式と共通の形式の対応を決めます。
相手が増えても、自社側の対応づけを相手ごとに作り直す必要がなくなります。
なお、プロバイダがどの形式に対応し、どこまで変換を引き受けるかは提供元ごとに異なります。
料金や性能も含め、選ぶ際には自社の取引先が使っている形式に対応しているかを個別に見ていくことになります。

流通BMSを使う場合も、変換と組み合わせる余地があります。
自社の基幹システムをそのまま流通BMSの形式に作り替えるのではなく、マッピングシートを使って自社データと流通BMSの項目の対応を決め、その間を変換する方法です。
消費財流通の取引先とは流通BMSで、それ以外の中小企業の取引先とはプロバイダ経由で、というように、取引の範囲ごとに方法を分けることも考えられます。
こう整理すると、「標準か変換か」は一つを選ぶ問いではなく、取引範囲ごとに標準で決まる部分と、変換で埋める部分を切り分ける作業になります。

方法 自社が変える範囲 相手に求める範囲 継続して残る作業
流通BMSに合わせる 自社データを流通BMSのメッセージ項目へ対応づける 相手も流通BMSに対応していること 版の更新への追従と標準にない自社固有の情報の扱い
中小企業共通EDI+プロバイダの変換 自社データと共通の項目の対応づけをプロバイダとの間で設定する 相手も何らかの形式でプロバイダにつながること コード対応表の維持と変換で埋まらない項目の確認
相手の形式に個別対応 相手ごとに取り込みや出力の仕組みを用意する 特になし(相手の形式をそのまま受ける) 相手が増えるたび・相手の形式が変わるたびの改修
標準を中間形式にして前後を変換でつなぐ設計(模式図)
自社のデータが共通の形式に変換され、さらに相手の形式に変換されて相手のシステムへ渡る流れを示す図

形式を変換するとき、項目とコードの違いはどう扱われ、何が手作業で残るのか

品目・取引先・単位の対応づけ

変換を使えば形式の差がすべて埋まるわけではありません。
変換が扱うものには、性質の違う二つの層があります。
一つは項目の意味の対応で、相手の「納品希望日」が自社の「納期」に当たる、というような対応です。
共通辞書や流通BMSのマッピングシートは、主にこの層を揃えるための道具です。
もう一つは値の対応で、相手が送ってくる商品コード「A-1001」が自社の品番のどれに当たるか、という対応です。

値の対応は、標準や辞書だけでは決まりません。
自社が品目をどんなコードで管理し、取引先や届け先をどう区別しているかという、基幹システムのマスタ(品目や取引先の基本情報の一覧)の持ち方に左右されるからです。
たとえば相手が自社の商品を相手側のコードで指定してくる場合、そのコードと自社品番の対応表がどこかになければ、変換の仕組みは商品を特定できません。
取引先コードも同じです。
相手が自社をどのコードで識別し、届け先ごとにどの番号を振っているかを、自社の配送先と結び付けておく必要があります。

単位はさらに注意が要ります。
相手が「3ケース」と送り、自社が個数で在庫を管理しているなら、1ケースあたりの入数が分からなければ換算できません。
入数が品目のマスタに登録されていれば変換で直せますが、登録されていなければ、人がその都度確かめることになります。
同じ商品でも取引先によって入数の違う荷姿で納める場合は、品目と取引先の組合せごとに入数を持つ必要が出てきます。
このように、変換で自動化できるかどうかは、変換の仕組みそのものよりも、変換が参照する対応表やマスタに必要な情報があるかで決まる部分があります。

変換で埋まらない項目の洗い出し方

変換しても手作業が残る項目は、取引先と自社のデータによって変わるため、一般論では特定できません。
そこでおすすめしたいのが、相手ごとに項目対応表を作り、相手の項目と自社の項目を一行ずつ突き合わせる方法です。
相手の注文データの項目を左に並べ、それぞれに対応する自社の項目と、値をどう直すかを書き込んでいくと、空欄や不一致の行が浮かび上がります。

対応表で空欄や不一致になった行は、扱い方を三つに分けて決めます。
一つ目は、マスタや対応表に情報を加えて変換できるようにするものです。
商品コードの対応や入数のように、一度登録すれば繰り返し使える情報はここに入ります。
二つ目は、相手と取り決めて項目の使い方を変えるものです。
たとえば備考欄に毎回書かれている納品時間の指定を、相手に定型の項目で送ってもらえれば、人が読む必要がなくなります。
三つ目は、人の判断として残すものです。

手作業で残すと決めた項目は、残すこと自体よりも、誰がどの時点で確認するかを決めておくことが大切です。
自由記述の特記事項、マスタに未登録の新商品、相手からの訂正や取消のように例外として届くものは、変換の仕組みが判断できずに止まるか、空欄のまま通してしまうかのどちらかになります。
止まった注文を誰が見るのか、空欄のまま通さない設定にできるのかを決めておけば、手作業は全件を見直す作業から、引っかかったものだけを確かめる作業へ絞られます。
何を手作業で残すかを決めるとは、この例外の受け皿をどこに置くかを決めることでもあります。

相手の項目(例) 自社の項目 値の直し方 状態
発注番号 受注の参照番号 そのまま転記 一致
商品コード 自社品番 相手コードと自社品番の対応表で変換 対応表が必要
数量(ケース) 数量(個) 品目ごとの入数を掛ける マスタに入数が必要
届け先コード 配送先 相手の届け先コードと自社の配送先を結び付ける 対応表が必要
備考(自由記述) 対応する項目なし 人が読んで判断する 手作業で残る
変換で埋まらない項目の三つの扱い(模式図)
マスタや対応表に加える、相手と取り決める、人の判断として残すの三つに、項目の例を分けて示した図

自社の状況別に、どの方法を選べばよいのか

発注側の場合

自社が発注する側で、複数の仕入先へ電子受発注を呼びかける立場にあるなら、どの形式を求めるかがそのまま仕入先の負担になります。
自社が消費財流通の小売業や卸売業で、主な取引先が流通BMSに対応しているなら、流通BMSの適用を先に検討するのが自然です。
同じ標準を使う相手とは、対応づけを使い回せるからです。

一方で、仕入先に中小企業が多く、業界標準への対応がまちまちな場合は事情が変わります。
一つの形式を一律に求めると、対応できない仕入先がFAXやメールのまま残ることがあります。
その場合は、標準を軸にしつつ、プロバイダの変換を介して相手の形式でも受け付けられる経路を用意することが考えられます。
発注側にとっては、相手から返ってくる出荷や請求のデータを同じ形式で受け取れるかどうかも、突き合わせの手作業に直結します。
注文を送る形式だけでなく、返ってくるデータの形式も含めて相手の対応状況を見ておくと、判断がぶれにくくなります。

受注側の場合

注文を受ける側が取引先から電子受発注を求められた場合、形式は相手が指定してくることがあります。
取引先から流通BMSでの接続を求められたなら、その取引については流通BMSに合わせることが前提になり、自社が考えるのは基幹システムとのつなぎ方です。
マッピングシートで項目を対応づけて取り込み時の変換を用意するのか、基幹システムの側を改修するのかを、改修のしやすさから選ぶことになります。

複数の取引先がそれぞれ別の形式を指定してくる場合は、相手ごとの個別対応が積み重なりやすい状況です。
基幹システムに取り込む直前の形式を社内で一つに決め、各取引先の形式からその社内形式へ変換する構えにしておくと、取引先が増えたときに直す場所が変換の部分に限られます。
取引先の中に中小企業共通EDIやプロバイダ経由の接続を受け入れる相手がいれば、その相手とはプロバイダに変換を任せる方法も選べます。
ただし、取引先が多い受注側は必ずプロバイダを使うべき、とまでは言えません。
相手が指定する形式と、プロバイダがそれに対応しているかによって答えが変わります。

取引先が一社の場合と多数の場合

電子化する相手が一社だけなら、その相手の形式に個別に対応する方法も十分に候補になります。
個別対応の負担は相手の数とともに増えるものなので、相手が一社のうちは、標準のために自社のデータを大きく作り替えるよりも早く、確実に始められる場合があります。
相手自身が流通BMSなどの標準を使っているなら、相手に合わせることと標準に合わせることは同じ意味になります。

注意したいのは、一社のつもりで始めた個別対応が、二社目、三社目と増えていく場合です。
最初の接続で相手の形式に合わせて基幹システムを直接改修してしまうと、次の相手の形式が違ったときに、同じ改修をもう一度することになります。
一社目の段階でも、相手の形式と基幹システムのあいだに社内で決めた中間の形式と項目対応表を置いておけば、二社目以降は変換の部分を足すだけで済みます。

取引先が多く、業界も分かれている場合は、取引の範囲ごとに分けて考えます。
消費財流通の相手は流通BMS、業種がさまざまな中小企業の相手は中小企業共通EDIとプロバイダの変換、どちらにも当たらない少数の相手は個別対応、という組み合わせ方です。
一つの方法で全取引先を覆おうとしないほうが、現実的な場合があります。
どの組合せが合うかは相手の対応状況次第で変わるため、取引先ごとの形式を一覧にしてから決めるのが近道です。

自社の状況別に検討する方法(模式図)
発注側、受注側、取引先が一社、取引先が多数の四つの状況ごとに、検討する方法を分けて示した図

導入前に何を確認し、どの順で進めるのか

確認の順序と並行できる作業

ここまでの判断を実際の接続につなげるには、次の順で確認を進めると、後からの手戻りを減らせます。
(1)相手が対応している形式と版を確かめる、(2)相手ごとの項目とコードの対応表を作る、(3)変換できない項目の扱いを決める、(4)試験データで確かめる、の4段階です。

このうち(1)と(2)は並行して進められます。
相手の形式の名前や版が正式に決まる前でも、過去に届いた注文書や注文データがあれば、そこに並ぶ項目をもとに対応表の下書きを作れるからです。
形式が確定した段階で、流通BMSならメッセージ項目一覧やマッピングシートと照らして対応表を仕上げます。

(3)は(1)と(2)の結果を受けて決めます。
対応表の空欄や不一致が出そろわないうちに扱いを決めると、マスタに入数を足せば済む項目を手作業に回したり、逆に人の判断が必要な項目を自動で通したりすることになりかねません。
(3)では、注文の後に続く出荷や請求などのデータをどこまで電子化の範囲に含めるかも合わせて決めておくと、後工程に読み替えが残る場所を把握できます。
(4)は、それまでに決めたことが実際のデータで成り立つかを確かめる段階です。

試験データでの確かめ方

試験には、架空の整ったデータではなく、実際に過去に届いた注文を使うほうが、手作業が残る箇所を見つけやすくなります。
整ったデータだけで試すと、対応表の想定どおりに変換されたことしか確かめられないからです。
過去の注文の中から、明細が多い注文、単位がケースと個で混在する注文、マスタに未登録の新商品を含む注文、訂正や取消の注文、備考に指示が書かれた注文を選んでおくと、例外の扱いまで確かめられます。

確かめる観点は大きく二つです。
一つは、変換された結果が、これまで担当者が手で入力していた内容と一致するかです。
過去の注文なら正しい入力結果が基幹システムに残っているので、変換後のデータと並べて差を見られます。
もう一つは、変換できなかったときに何が起きるかです。
対応表にない商品コードが届いたとき、その注文が止まって担当者に知らされるのか、空欄のまま基幹システムへ入ってしまうのかは、運用の安全性を大きく左右します。
(3)で決めた例外の受け皿が実際にその通りに働くかを、ここで確かめます。

受注側であれば、注文を取り込んだ後に返す出荷の知らせなどのデータが相手の側で正しく読めるかも、相手と一緒に確かめておきたいところです。
自社の中で変換がうまくいっていても、往復のどこかで相手の形式とずれていれば、相手の担当者が読み替えを担うことになります。
試験で見つかった差は対応表やマスタに戻して直し、同じ注文でもう一度試す、という繰り返しを差がなくなるまで続けます。
こうして残った手作業は、偶然残ったものではなく、自社が残すと決めた確認作業になります。

導入前の確認の進め方(模式図)
相手の形式と版の確認、項目とコードの対応表の作成、変換できない項目の扱いの決定、試験データでの確認の順に並ぶ図。最初の二段階は並行できる

どの標準が関係し、どこを変換で埋めるかは、取引先ごとの形式と自社の基幹システムの項目を並べてみないと見通しにくく、社内だけで整理すると読み替えの漏れに気づきにくいためです。

取引先から届いている注文データと自社の項目を突き合わせ、標準に合わせられる部分、変換で埋められる部分、手作業として残る部分の見通しを確かめられます。無料相談で要件を整理する

要点の整理

軸 基準
関係する標準 自社の業種ではなく、主な取引相手の業界で決まる
流通BMS 消費財流通の取引が中心なら先に適用を検討し、相手の版を確かめる
中小企業共通EDI 業種がさまざまな中小企業の相手と、プロバイダの変換を介してつなぐ候補
個別対応 相手が一社なら候補。増える見込みがあれば社内の中間形式と対応表を挟む
手作業で残すもの 項目対応表の空欄・不一致を、マスタへの追加・相手との取り決め・人の確認に分けて決める
導入前の確認 形式の確認と対応表の作成を並行し、例外の扱いを決めてから過去の注文で試す

変換できない項目の扱いや試験に使う注文の選び方は、接続を始めてからでは手戻りが大きく、導入前に決めておくほど後の確認作業を絞り込めるためです。 相手ごとの項目対応表の空欄・不一致をもとに、マスタに加える情報、取引先と取り決める項目、人の確認として残す項目の切り分けと、試験で確かめる注文の候補を整理できます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

取引先が流通BMSでなく独自形式の場合、変換だけで受けられますか

相手の項目の意味を自社の項目へ対応づけられ、商品コードや入数などの値の対応表を用意できれば、変換で受けられる範囲は広がります。
ただし、自社の項目に当たるものがない情報や、自由記述の指示は変換では埋まりません。
相手が形式を変えたときには、自社側の変換も直す必要があります。
相手の項目を一行ずつ自社の項目と突き合わせて空欄や不一致の行を洗い出し、過去の注文で試験してから判断するのが確実です。

中小企業共通EDIと流通BMSは両方に対応する必要がありますか

両方への対応が一律に求められるわけではなく、取引先の範囲で決まります。
消費財流通の取引先が流通BMSを使い、ほかに業種のさまざまな中小企業の取引先がある場合は、両方が関係することがあります。
どちらか一方の取引先しかなければ、もう一方に備える必要は今のところありません。
両方が関係する場合も、基幹システムの前に社内の形式を一つ置き、それぞれの標準へ変換する形にすれば、基幹システムを二重に改修せずに済みます。
プロバイダを使う場合、どの形式に対応しているかは提供元ごとに異なります。

品目コードや取引先コードが相手と一致しないとき、どこで調整しますか

調整する場所は、自社のマスタに相手のコードを持たせる、変換の仕組みの側に対応表を持つ、相手に自社のコードで送ってもらう、の三つが考えられます。
どこで持つかより大事なのは、対応表を一か所にまとめ、誰が更新するかを決めておくことです。
マスタと変換の側の両方に似た対応表があると、新商品を登録したときに片方だけが更新され、変換が止まる原因になります。
新しい品目や届け先が増えたときに、どの手順で対応表へ反映するかも合わせて決めておくと安心です。

取引先が一社だけの場合も標準形式に揃えたほうがよいですか

必ずしも揃える必要はありません。
相手が一社なら、その相手の形式に個別に対応するほうが早く始められる場合があります。
相手自身が標準を使っているなら、相手に合わせることがそのまま標準に合わせることになります。
今後ほかの取引先とも電子化する見込みがあるなら、基幹システムを相手の形式に直接合わせず、社内の中間の形式と項目対応表を挟んでおくと、二社目以降の対応が変換の追加で済みます。

導入前の試験では何を確認すればよいですか

過去に実際に届いた注文を使い、変換結果がこれまでの手入力の内容と一致するかと、変換できないデータが届いたときに注文が止まるのか空欄のまま入るのかを確認します。
明細の多い注文、単位の混在、マスタ未登録の商品、訂正や取消、備考に指示がある注文を含めると、手作業が残る箇所を見つけやすくなります。
受注側なら、返送する出荷の知らせなどが相手の側で正しく読めるかも、相手と一緒に確かめておくと安心です。

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

> プロフィールの詳細を見る

  1. 1 出典:中小企業庁(ミラサポplus)「企業間のデータ連携で、受発注の業務コストを削減する!」(2020年)
  2. 2 出典:一般財団法人流通システム開発センター(GS1 Japan)「流通BMS」(掲載ページ)
  3. 3 出典:一般財団法人流通システム開発センター(GS1 Japan)「流通システム標準普及推進協議会(流通BMS)」(基本形Ver2.2.2時点の掲載ページ)

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top