日本流とは違う、アマゾンのEDIとその対応策
日本のEC市場とアマゾンの成長
2019年6月20日、 Amazonは日本版「2019年中小企業インパクトレポート」で、「引き続きオンラインストアでの商品販売や物流事業などを通して、中小企業のビジネスの成長を支援していく」と発表しました。
このレポートでは、日本の中小企業の15万社以上がAmazon.co.jpに出品し、2018年は日本の中小企業の販売事業者様のAmazon.co.jpでの流通総額が、9,000億円超えたとのこと。グローバルでは、多くの中小企業を含む販売事業者様がAmazonで商品を販売された流通総額の割合が、過去20年間で3％から58％に増加しているようです。
今後、さらに販売事業者との受発注業務の効率化のため、オンラインによるデータ交換、EDI化も進められていくことでしょう。しかし、アマゾンのEDIは日本流とは異なるため、納入業者（ベンダー）がとまどう場面が多く見られます。アマゾンのEDIは日本のEDIと何が違うのか、どう対応すればよいのでしょうか。
ユーザックシステム主催のEDI最新動向セミナーにて、「アマゾンのEDIについて」の講演を行いましたのでレポートいたします。
日本のEDI
日本の流通業ではこれまで、日本チェーンストア協会（JCA）が中心となってオンラインによるデータ交換（EDI）を推進し、小売と卸、メーカーとの受発注業務が効率化されてきました。通信はJCA手順に、納品書はチェーンストア統一伝票に、標準化が進められましたが、やり取りするデータの内容、受注や請求といったメッセージは小売ごとにバラバラでした。電話回線を利用した通信に時間がかかり、モデムの調達も困難になることから、小売、卸、メーカーが議論を重ね、2007年に流通BMS（流通ビジネスメッセージ標準）が制定されました。
流通BMSは、インターネットによる通信手順が採用され、高速通信を実現しました。また、各小売のメッセージも統一され、一部の小売との間では伝票レスも実現し、業界全体の最適化が進められています。大手小売はほぼ流通BMSに移行しましたが、まだJCA手順や全銀手順によるレガシーEDIも残っています。しかし、これら流通BMSとレガシーEDIに対応できれば、どの小売とのオンラインにも対応できます。これが日本の流通業におけるEDIの概要です。
ところが、ここ数年急成長しているECサイトの最大手アマゾンがEDIを展開しだしました。アマゾンは楽天やヤフーと違い、ショッピングモールを運営するのではなく、自社で商品を仕入れて消費者に販売する、イオンやイトーヨーカ堂といった小売と同じ流通形態なのです。実店舗を持たない点だけが異なるわけです。
取引する量が少なければベンダーセントラルと呼ばれるWebEDIにより、ウェブ画面でデータのやり取りができますが、1日の取引量が100件にもなれば、やはりファイル交換型のEDIを選択せざるを得ません。ところが、アマゾンのEDIは日本流とは大きく異なります。流通BMSやレガシーEDIと何が違うのか、詳しく見ていきましょう。
アマゾンのEDIとその対応策
1．メッセージの種類日本の流通業で主流となる流通BMSの基本メッセージは、発注、出荷、出荷梱包、受領、返品、請求、支払です。このうち発注、出荷、受領、請求がよく使われ、オプションメッセージに、商品マスタや値札があります。アマゾンにも発注メッセージがありますが、New Release（新製品）、Standard（通常発注）、Back Order（入荷待ち）の3つに区分されるのが特徴です。さらにそれぞれ、納期回答、出荷、請求、3つのメッセージを返す必要があります（図1）。
図1 アマゾンのEDI概要図
New Releaseは書籍でよく見られる予約注文で、ベンダー側に在庫がない商品でも注文するメッセージです。Standardは流通BMSの発注に相当しますが、大きく違う点は欠品の扱いです。流通BMSやJCAは、欠品がある場合、在庫分だけが納品され、残りはキャンセルとなり、お互いのEDIデータには残りません。しかし、アマゾンのEDIは、欠品した分はキャンセルとはならず、注残として管理されます。そして、回答した納期や様々な条件にもとづきBack Order※として改めて発注があり、商品の入荷後に出荷するという流れとなります。
※Back Orderは2017年に廃止
どのメッセージをベンダーセントラル（WebEDI）にし、どのメッセージをEDI（ファイル転送）にするかはベンダーが選択できます。基幹システムとの連携がむつかしい納期回答だけをベンダーセントラルにする企業が多いと思われます。
流通BMSはインターネットによる通信手順、ebXML MS、EDIINT AS2、JX手順の３つが採用され、多くのベンダーは主にJX手順を利用していますが、アマゾンではSFTPという暗号化されたFTP通信で、メッセージのレイアウトはANSIが採用されています。XMLで定義される点においては流通BMSに似ていますが、受信後にデータを変換する場合、今使っているプログラムが対応しているかを事前に確認しておきましょう。ちなみに当社、ユーザックシステムのEOS名人はSFTP+ANSIのデータ変換が可能です。
3．物流ラベル流通BMSには出荷梱包メッセージがあります。出荷する梱包にどの商品が入っているかをベンダー側で検品し、梱包番号との紐づけを要求する場合があります。これを出荷梱包ヒモ付けありと呼びます。事前に出荷梱包データを小売に送信することで、小売は入荷時に物流ラベルのバーコード（梱包番号）をスキャンし、その梱包に入っている商品を一括して入荷計上します。小売側の検品作業が大幅に削減できる反面、ベンダー側の出荷検品体制の整備が求められます。
これと同じような仕組みがアマゾンでも必要となります。アマゾンの物流ラベルはSSCC（Serial Shipping Container Code）を採用しています。SSCCはGS1-128という規格のバーコードを利用した梱包を識別するコードです。梱包番号をバーコードにして物流ラベルに印字する点は流通BMSと同じですが、アマゾンの物流ラベルには、梱包されている商品の伝票番号も記載する必要があります（図2）。さらに事前に送信する出荷梱包データには運送会社の送り状番号も必要となります。
図2 アマゾンの物流ラベル
このようにアマゾンのEDIは、FTPによる通信と納期回答など新たなメッセージ種別の対応だけでなく、出荷時の検品体制と送り状発行システムとのデータ連携が求められます。アマゾンとの取引が始まり、売上が増えるにつれてEDI化の必要性が高まります。これまで、他の小売とのEDIの実績があるから大丈夫と構えていると、日本流のEDIとの違いにとまどうことになるでしょう。アマゾンとの取引を検討している企業、すでに取引がありベンダーセントラルで対応している企業は、ぜひこのレポートをご確認いただき、アマゾンEDI対応の事例（図3）も参考にしていただけたらと思います。
図3 アマゾンのEDIに対応したシステム構成事例
アマゾンEDI対応のポイント
・自社の出荷体制とアマゾンの要望とのすり合わせを入念におこなう。
・WebEDIとファイル交換（EDI）を組み合わせて、費用対効果の高いシステムを構築する。
■このコラム「AmazonEDI対応事例｜Amazon取引において、EDI手順と物流センターのレイアウト見直しで効率化を実現」も合わせてご覧ください。
※本ページの内容はユーザックシステムの「業務改善とIT活用のトビラ」の転載です。転載元はこちらです。