(2)(現在において)現実的なEDIの流れを示す『Bパターン』

  実際にEDIを進めていく過程においてはさまざまな問題が発生します。そうしたことからすぐに『Aパターン』の実現ができないこともありますので、それまでの間に暫定的にフローをブレークしたものがこの『Bパターン』です。但し、『Bパターン』の一部が『Aパターン』の方向へ変化することについては、推奨できるものとして考えることができます。

  ではその考え方について解説します。


  ①. 商品マスターデータ
     
     商品マスターはお互いに設定する項目が多岐にわたり、そのタイミングもまちまちになってしまう場合もあり、それぞれ必要となる情報を確認しあうようにするという流れに設定されています。したがってプロモーションなどに関するデータやその他の単価情報などがデータ交換されることもありえると考えられます。そうした情報交換が定着してきた段階で、別のサブシステムを設定して整理していくとよいと考えます。


  ②. 発注データ
     
     発注データと一言でいっても、実際は直送指示データであったり、物流センターに対する指示情報が中心であったり、追加発注であったりといくつかの属性の違いが一つにまとめられてしまっているのが実状でしょう。そうしたものは本来の発注データ以外で処理すべきであったり、しっかりとした項目設定に基づいて処理されるべきものですから、相互に充分話し合って決めなければならないのです。そこでメッセージフォーマット以外に決めることの例として、このデータ中に直送分を含むかどうか、追加受注を別の形にするか含めてしまうか、返品データ(概要編での返品通知データ)があれば同時に送り込むか、企画・特売などの訂正データを入れるかといった項目を選択できるように考えています。これらに関しては、メッセージフォーマットとして規定していないものもあります。


  ③. 納品データ
     
      『Bパターン』の場合にも納品データに関しては、「送信A」と「送信B」の2種類の定義をしました。これらの考え方は『Aパターン』と基本的に同一です。ただし現実的な運用上の制限などにより次のようなことを考慮する必要があると考えます。まず発注データと同様に直送分も納品データとして送るべきかどうかがあります。メーカーからの出荷タイミングは卸売業と同期が取れないことがほとんどですから、別のデータとして送る方が良いかもしれません。次に発注データと変わらない明細まですべて送る必要があるかという問題があります。高速な通信方法をとっていればさほど大きな問題とはいえませんが、従来方式であった場合には深刻です。問題がある場合は訂正分のみ送信することになります。そして発注のオンライン率が100%未満である場合には、手入力のデータが追加されますが、小売業側で別管理になる場合もあり、選択できるように考えました。


  ④. 返品データ
     
     『Bパターン』の返品データとは概要編でいうところの返品承認データ,返品確定データのことです。小売業から返品を行う時にオンラインにてメッセージを交換する前に、商品を移動してしまうといった運用もあります。この場合、卸売業側で返品データを作成した方が訂正が少なくて済むことが多いと考えられます。そこで『Aパターン』とは逆に卸売業から小売業に対して返品データを送信しています。これとは別に発注時点で発注データの中に返品分を小売業が連絡できるルートも考えています。この場合、返品商品を受け取った卸売業が返品内容を確認する返品データを送り確定することになるわけです。


  ⑤. 納品確定・返品及び訂正データ
     
     返品データを受け取った小売業はその内容を確認し、正しければ伝票合計で返信し、訂正があれば明細タイプのそれぞれのデータ種のメッセージフォーマットを使って返信します。これらの返信により納品データと返品データの確認ができることになりますが、ここで納品データで手入力分が抜けていたり、直送分が確認できなかったりすることがありますので注意が必要でしょう。


  ⑥. 支払予定データ・請求データ
     
     この時点では小売業・卸売業間のデータはお互い整合性を保っているかどうかはやや不明な点(手入力分、直送分など)と考えられますので、場合により支払予定データを事前に小売業から卸売業に送り確認しておく必要があることもあるでしょう。確認が必要のない程度に正確なデータのやり取りが実現できれば、『Aパターン』のように支払予定データを省略できるのです。請求データに関してもあまり無駄な通信は行わないという観点から、全明細を送るものに加え、伝票合計のみ送るもの、さらに鑑部分のみ送るものといった種類を用意しています。


  ⑦. 支払データ
     
     さまざまな事情からこの時点でも若干のずれが生じることもありますので、支払がなされた情報について確認を行うことになります。運用次第では、この情報は銀行からあるいは入金伝票から確認し、実際の訂正などについては別途方法が必要な場合もあるでしょう。