IV.固定長メッセージ編第1章　1.EDI標準フロー 3/3

IV. 固定長メッセージ編

第1章小売業・卸売業間のビジネスプロセス

1.EDI標準フロー

　受発注･返品・請求・支払の一連の業務の流れに沿ったフローを提示するにあたって、ここでは２種類のレベルを用意しました｡『Ａパターン』と『Ｂパターン』がそれで､それぞれの趣旨がありますので説明します｡

(1) (現在において)理想的なＥＤＩの流れを示す『Ａパターン』

　現在､ＥＤＩは我が国の消費財流通の分野においては､発展途上の段階にあるといえます。そのなかで今後の発展の姿をどう捉えるかを示す必要があるという考えに基づいて､定義されたフローがこの『Ａパターン』です｡
　その考え方について解説します｡

	①.	商品マスターデータ

		商品マスターデータは新規登録の場合はまずメーカーや卸売業から小売業に対して情報を渡すことになります｡基本的には登録の二重作業化を防ぐためですが、その他のやり取りには商品情報に関するサブシステムの構築が必要と考えここでは登録のみの表現とし、商品登録後のプロモーションなどに関しては基本的に別データ種にて小売業からまたは卸売業から情報発信されることになるので､ここでは純粋な商品マスターの情報提供ということで一方通行に設定されています｡

	②.	発注データ

		発注データは通常ＥＯＳ発注と呼ばれるデータのことですが、『Ａパターン』では基本的に小売業の発注と位置付けられる全ての内容が収められているという考え方をしています。つまり、直送指示や特売などの一般的には必ずしもＥＯＳ発注しないものについても入っているということです。また、追加発注時に電話などで連絡されるものについても『Ａパターン』では全てこの発注データにて連絡することになります。

	③.	納品データ

		納品データで重要な項目は､いうまでもなく商品コードと数量です｡商品コードはＪＡＮコードを基準に考えていますが､内部的にＩＴＦコードやＳＣＭラベル用のコードなども追加できるようにし、物流システムに対しても指示ができるように構成してあります｡固定長メッセージフォーマットでは､データ種を分けることで対応しています｡（固定長メッセージ編第２章２参照）可変長メッセージフォーマットでは、データ種を分けずに項目を充実させることで対応しています｡次に数量については従来からの発注単位数量などにも対応し､さらに可変長メッセージフォーマットでは数量単位をコードで表現しながら異なる商品分類ごとの数量表現にもおおむね対応できるように考慮されています｡　　　　　　　　　　　　　　　　　　　　　　　　　　　また、送信に関しては、「送信Ａ」と「送信Ｂ」の２種類の定義をしました｡これらのメッセージフォーマットは基本的に同一ですが､異なる点は「送信Ａ」はＡＳＮ（ＡｄｖａｎｃｅｄＳｈｉｐｐｉｎｇＮｏｔｉｃｅ：事前出荷案内）的な要素から発注に対する返信を早期に出さなければならない状況を想定し､出荷作業が終了する以前に在庫管理システムに基づいた内容で出荷案内を送るというものです。逆に「送信Ｂ」はＡＳＮとして使う場合でも充分時間がある場合に、出荷作業が終了した時点で送信するものです。いづれの送信タイプにも納品分と欠品分の区分けがつくように項目が設定されています｡

	④.	納品確定・返品及び訂正データ

		卸売業からの納品を検収し､小売業はその納品確定データを返信します。この内容は納品データと変わらないものなので伝票１枚ごとの合計情報として省略してしまいます。またその際に受領時点での訂正があった場合にはその訂正データについてもそれぞれの明細用のデータ種のメッセージフォーマットを用いて返信します。訂正データは内容が納品データとの違いが分らなければなりませんので明細情報として返信します。そしてさらに返品があればそのデータも合わせてこのタイミングで送信します。その意図は小売業と卸売業との債権債務情報をできる限りリアルタイムに合致させることにあります。しかしここではお互いに正しい返品処理が行われることが前提条件になります。ここでの更なる返品訂正が多く発生すると送受信処理が煩雑になり、かえって違算の原因を作りかねません。そうした理由からあえて返品訂正は省略しています。（必要な場合に付け加えて処理して下さい）

	⑤.	請求データ

		この時点では小売業・卸売業間のデータはお互い整合性を保っていると考えられますので、従来のような違算はきわめて少なくなっています。そこで請求データは鑑部分の項目だけで構成し、無駄な送信処理を行わないようにしています。また訂正の必要度によって明細データの送信も考えられますが、ここでは割り切った考え方をしたわけです。本来、請求・支払時点で多くの訂正が発生することは基本的なビジネスプロトコルにまだ問題が残っているということなので、請求以前に解決するための仕組を持たせる方が良いという考え方なのです。

	⑥.	支払データ

		基本的には決済の確認という程度で、銀行とのＥＤＩが本格的になった時点ではそれほど細かいチェックを必要とするものではなくなると考えています。ただし支払時点で訂正をしてしまうなどの処理レベルであれば、付加情報が必要になるかもしれませんが、請求データの趣旨と同様に支払データ送信以前に解決する仕組を用意されることをお勧めします。