目次はじめに Ⅰ. 流通 BMS の概要と導入のメリット Ⅱ. 導入までの流れ 1. 従来型 EDI の課題 2. 課題解決のための流通 BMS 3. 流通 BMS と通信プロトコル標準 4. セキュリティ 5. 従来型 EDI との違い 6. 流通 BMS に移行するメリット 1. 導入のモデル

(1)

流通ビジネスメッセージ標準

（流通

BMS

）

2009

年度版

解

説

_説

書

_書

~

流通

BMS

の導入に必要な知識と具体的導入作業の解説

~

営業本部営業本部 EDI/ EDI/SCMSCM企画推進企画推進

藤野

裕司

2009.06

Ver 3.01

(2)

Ⅰ．流通BMSの概要と

導入のメリット

１．従来型EDIの課題２．課題解決のための流通BMS ３．流通BMSと通信プロトコル標準４．セキュリティ５．従来型EDIとの違い６．流通BMSに移行するメリット

はじめに

１．流通ビジネスメッセージ標準２．通信プロトコル標準３．必要となる申請・手続と期間

Ⅲ．導入事前準備

１．導入のモデル２．導入にかかわる全体の流れ３．事前準備から本番移行まで

Ⅱ．導入までの流れ

１．環境の構築２．システム規模の選択３．目的に応じた具体的構成４．ACMSアップグレードパス

Ⅳ．流通BMSの導入

(3)

2

はじめに

本資料には、これから流通ビジネスメッセージ標準（流通BMS ）を導入する

ために、

必要となる事前準備

及び

導入に際しての検討ポイント

が記載されています。

また資料後半には、流通BMSの概要を整理した知識編を添付しているた

め、社内での勉強用資料として、また実際の導入時の手引き書として、

ご活用ください。

なお、本書は下記の「流通システム開発センターWebサイト」で公開されている

公式情報に基づいて記述しております。必要に応じてご参照ください。

• 財団法人流通システム開発センター［http://www.dsri.jp/］ »流通業界の標準化・システム化を推進している団体。 – 「経済産業省流通システム標準化事業」 »流通システム開発センターのサイトからこのタイトルをクリックする。 »このページには流通次世代関連の重要な情報が掲載されている。 »このページ内でも特に重要なのが、「流通BMS」のページであり、ここに流通ビジネスメッセージ標準の資料が掲載されているため必読である。

(4)

Ⅰ．流通BMSの概要と導入のメリット

１．従来型EDIの課題

２．課題解決のための流通BMS

３．流通BMSと通信プロトコル標準

４．セキュリティ

５．従来型EDIとの違い

６．流通BMSに移行するメリット

(5)

4 取引先取引先 AA Internet Internet Internet Internet WebEDI WebEDI AA WebEDI WebEDI BB WebEDI WebEDI CC WebEDI WebEDI DD 新多端末現象新多端末現象新多端末現象新多端末現象取引先取引先ＢＢ取引先取引先ＣＣ取引先取引先ＤＤ

１．従来型EDIの課題

従来型ＥＤＩには課題が山積し、このままでは運用に耐えられない状況となってきた。

全銀・JCA手順はもう限界！ • サポートする機器が販売停止、もしくは高コスト。 • 画像情報が送れない。JCA手順は、漢字も送れない。安価で高速のインターネットが使えない。国際標準ではないため、海外との取引に利用できない。ファイル転送のため、トランザクション単位の処理ができない。データが固定長のため仕様変更が困難。それらの解決策としてWebEDIが登場したが、 • 各社個別画面ができたことにより新多端末（多画面）現象が起こった。 • 手動操作によるファイル転送を求められるようになった。これにより、ＥＤＩ本来の自動処理ができなくなり、多大な人的負荷が発生するようになった。企業間･企業内を取引のデータが縦横無尽に行き来している。 EDIの適用領域が「電子商取引」の範囲外へ拡大している。従来型EDI、WebEDI、社内ファイル転送、データ変換（手組み）は、すべて別のシステムとして稼動しており、運用監視が複雑化している。

JCA

手順は

日本語日本語漢字不可漢字不可画像情報不可画像情報不可機器の販売停止機器の販売停止通信速度は通信速度は2400bps2400bps

(6)

★課題解決のため

インターネット環境での効率的・効果的なEDIを目指す。

可能な限り標準化を進め、全体最適を目指す。

共通基盤は、デファクトスタンダードから選べるようにする。

結論

インターネット経由の国際標準の通信手順を使用したXML-EDI！

コードは国際標準（GTIN、GLN）を採用。データ項目・メッセージは業

界標準を策定。

取引業務プロセス（メッセージ種）取引業務プロセス（メッセージ種）データ項目データ項目コード（コード（GTINGTIN、、GLNGLN））データ表現形式（データ表現形式（XM LXM L））通信手順（

通信手順（ebXM L M SebXM L M S、、AS2AS2、、JXJX手順）手順）通信基盤（インターネット通信基盤（インターネット TCP/ IPTCP/ IP））ＥＤＩメッセージＥＤＩメッセージ通信インフラ通信インフラ共通基盤共通基盤（デファクトスタンダードの（デファクトスタンダードの中から選択）中から選択）（図は流通システム開発センター資料より）（図は流通システム開発センター資料より）

２．課題解決のための流通BMS

（ebXM L M S、AS2、JX手順は、別途説明）

(7)

6

２．課題解決のための流通BMS

★流通BMS検討の基本方針

個別仕様の発生を抑える

• すべての企業間取引で共通のEDIメッセージを使えるように、「メッセージ種別」、

「メッセージ構造」、「データ項目」と「データ項目の意味」・「データの属性」を標準

化する

現行業務の担保を図る（現行システムの担保ではない）

• 各社の現行業務をできるだけ担保し、移行の負担を軽減する。

将来の技術・業務に対応できる準備を盛り込む

• 商品マスターの同期化（GDS） →

未対応

• 共通企業識別コード(GLN)

• 共通商品識別コード(GTIN)

インターネットを使用した通信を前提とする

• XML、セキュリティ

伝票レスを促進する

• 取引証憑の要件を満たすEDIメッセージとすることで、ペーパー仕入伝票を不要

とする。

(8)

次世代EDI標準検討の経緯

２．課題解決のための流通BMS

（流通システム開発センター資料より）（流通システム開発センター資料より）２００３年∼２００８年：経産省事業流通業界全体の情報共有・交換のインフラ基盤としての新たな流通システム標準業種・業態を超え、ユーザー自らが作り、ユーザー自らが使いユーザー自らが管理するユーザー主体の新標準を目指す２００９年∼ ：民間運営流通システム標準普及推進協議会ユーザー企業・団体が主体となった検討の場業種・業態や製配販の枠を超えた意見調整と啓発の場２００３年度２００３年度２００２００４４年度年度２００２００５５年度年度２００２００６６年度年度２００２００７７年度年度流通サプライチェーン全体最適化促進事業流通サプライチェーン全体最適化促進事業流通システム標準化事業流通システム標準化事業取引プロセスモデルの検討設計開発実証実験基本形の標準化検討物流系・情報系メッセージ検討（預かり在庫型センター、 POS/ 在庫データ等）共同実証共同実証（生鮮、ｱﾊﾟﾚﾙ）基礎調査・研究標準化検討と実証実用化と普及拡大へ共同実証（チェーンドラッグホームセンター百貨店）２００２００８８年度年度流通システム標準流通システム標準普及推進協議会普及推進協議会流通システム標準・開発維持管理・導入支援普及推進・外部からの要請に応じた標準化検討

経産省事業

［標準の策定］

民間運営

[ 標準の維持管理 ] 引き継ぎ

(9)

8

２．課題解決のための流通BMS

★業界動向

スーパー業界では既に実運用及び普及段階に入り、百貨店業界や

チェーンドラッグ、ホームセンター業界でも共同実証を実施した。

酒類・加工食品日用品・化粧品生鮮食品アパレル医薬品住関連製品ホビー関連製品家電製品卸・メーカー書籍等総合スーパー食品スーパー百貨店ドラッグストア CO-OP ホームセンター家電量販点小売各種専門店等 2006年度共同実証実施 2007年度共同実証実施 2008年度共同実証実施

流通

BMS

発注/生鮮発注出荷/生鮮出荷受領/生鮮受領返品/生鮮返品請求/支払値札集計表作成在庫・POS売上･･･通信インフラ（図は流通システム開発センター資料より）（図は流通システム開発センター資料より）

(10)

(1) 流通ビジネスメッセージ標準（流通BMS）メッセージ基本形 V1.2

３．流通BMSと通信プロトコル標準

卸・メーカー小売商品ﾏｽﾀ登録発注商品ﾏｽﾀ登録消込買掛請求返品受領受注出荷納品提案メッセージ返品メッセージ支払メッセージ請求メッセージ発注予定メッセージ商品マスタ（継続検討）出荷梱包メッセージ（紐付有･無）小売から卸･ﾒｰｶｰから卸･ﾒｰｶｰへ小売へ受領訂正メッセージ POS情報集計表作成ﾃﾞｰﾀ（出荷梱包紐付有）集計表作成ﾃﾞｰﾀ（出荷用）出荷メッセージ集計表作成ﾃﾞｰﾀ（発注用）集計表作成ﾃﾞｰﾀ（発注用）請求支払売掛返品値札作成依頼値札メッセージ値札作成集計表作成ﾃﾞｰﾀ（受領用）受領メッセージ販売情報共有販売情報共有検品発注メッセージ

(11)

10

(2) 通信プロトコル標準

a. 通信基盤：インターネット、TCP/IP。

b. 通信プロトコル：国際標準のebXML MS、AS2と日本独自標準のJX手順。

① ebXML MSとは？ – ebXML MSとは、CEFACTとOASISが共同で開発した次世代EDIの国際標準ebXMLの通信プロトコル部分ebXML/MSのこと。 – インターネット上で高速安全なEDI環境を構築できる。 – アジアを中心に実装が始まっている。 – リアルタイムのEDI（メッセージング）を実現。 – データ発生のつどプッシュ型で相手に送るサーバ方式。 – 通常のファイル転送（文字情報）のほか、ファイル添付（Word、Excel、PowerPoint、PDF、 CAD、画像、音声、動画、等）も可能。 ② EDIINT AS2とは？ – IETFが制定したインターネットEDIの国際標準。 – 米国を中心に実装が始まっている。 – ebXML MS同様、データ発生のつどプッシュ型で相手に送るサーバ方式。 – ウォルマートを中心に国際レベルでの流通調達で普及が始まっている。 – 日本でも日用品雑貨メーカを中心に検討の機運が高まっている ③ JX手順とは？ – 2007年4月正式に命名され、それ以前はSOAP-RPCと呼ばれていた。 – 中小企業では、データ発生のつどプッシュ型で相手に送るサーバ方式の常時運用は難しい。その点JX手順は、必要の都度センターにアクセスし、データを送受信するプル型。 – 任意のタイミングでクライアントから起動し、取引先やVANとデータの授受を行う。 – ebXML MSでは現行EOSからの移行が難しいため、実態に合わせて作られた日本独自標準。

３．流通BMSと通信プロトコル標準

(12)

３．流通BMSと通信プロトコル標準

(3) S-S型（サーバ常時稼働）とC-S（PC随時稼働）型

（量販（量販ＸＸ））ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションデータ変換データ変換データ変換ＥＤＩクライアントシステムＥＤＩＥＤＩクライアントシステムクライアントシステムビジネス文書ビジネスビジネス文書文書インターネットインターネットインターネット社内形式社内形式ファイアウォール相当機能ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステムデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションインターネットインターネットインターネット社内形式社内形式ファイアウォール _（量販_（量販_Ｘ_Ｘ_）_）

★S-S型EDIモデル

_{ebXML MS}_{ebXML MS}_、_、_AS2_AS2

(13)

12

３．流通BMSと通信プロトコル標準

(4) 利用形態（イメージ）

二次卸二次卸倉庫倉庫大メーカ大メーカ一次卸一次卸 VAN VAN事業者事業者二次卸二次卸小売小売 _{ebXML MS}_{ebXML MS} AS2 AS2 中小卸中小卸 ebXML MS ebXML MS JX JX手順手順 JX JX手順手順 JX JX手順手順 JX JX手順手順 JX JX手順手順 AS2 AS2 ebXML MS ebXML MS

(14)

４．セキュリティ

(1) セキュリティ対策が必要

インターネットが前提になるため、従来にはなかったセキュリティ対策が必要

となる。

サーバ側セキュリティには「システムに対するアクセスの管理」「ファイア

ウォールやサーバのセキュリティ、監査用ログの管理」「通信プロトコル上で

の暗号化や認証」「文書の改竄防止」などがある。

クライアント側セキュリティは、インターネット接続のＰＣと同等レベルのセキュ

リティ＋認証情報の設定が必要。

(2) 証明書・署名の扱い

サーバシステムには、証明書が必要。署名が必要な場合もある（AS2）。

クライアントシステムにも、証明書が必要な場合がある。

認証局より証明書を取得し、目的に応じて証明書・署名として使用する。

流通BMSの場合は業界認定の認証局から取得することが前提となっている。

自社用の証明書は認証局から取得し、取引先認証のための認証局証明書

は取引先から受領する。

取得したサーバ証明書は、システムにセットして取引先と接続する。

(15)

14

５．従来型ＥＤＩとの違い

(1) 従来のJCA手順・WebEDI方式との差異

インターネット（固定料金、数Mbps）、TCP/IP、SSL 電話網（回線毎に固定＋従量料金、9600bps等）インターネット（固定料金、数Mbps）、 TCP/IP、SSL 通信基盤画面からの伝票入力、もしくは、手操作によるHTTPファイル転送（標準仕様・JCA手順方式とは異なる） JCA通信手順国際標準 ebXML MS、EDIINT-AS2、 SOAPを使用通信手順サーバ側より仕様提示情報システム部同士で個別調整 ebXML、CPA等で通信合意事項を規定通信に関する当事者間合意形式規定は小売の仕様書 JCA形式（固定長）、形式規定は小売の仕様書国際標準 XML（可変長）、形式規定も XML データ表現形式個別項目個別項目業務項目、メッセージヘッダー項目を標準化データ項目商品：JAN、企業識別：小売コード商品：JAN、企業識別：小売コード商品：GTIN(JAN)、企業識別：GLN、小売コードコード（商品、企業識別）小売の運用統一フォーマットは受発注のみ、小売の運用標準メッセージの規定、運用ガイドライン取引業務プロセス個別交渉個別交渉プロセスやコード種、等の選定項目を提示業務に関する当事者間合意 WebEDI方式 JCA手順方式標準ＥＤＩ E D I _通信標準 E D I _標準メッセージ

標準

EDI

_EDI

では、業界の標準となる様々な指針を打ち出している。それにより、従来

相手先毎個別に取り決めが必要だった要件を、標準仕様をベースに共通認識のも

とに設定できるよう考慮されている。

(16)

６．流通BMSに移行するメリット

(1) 流通ビジネスメッセージ標準を採用することによるメリット

最初にシステムを標準対応することにより、以降取引先毎のシステム

開発は最小限に抑えられる。

• 最初の標準対応も、現行業務が前提となるため、過大な開発負担はな

いものと考える。

同じシステムで現行のバッチ型ファイル送受信を行うことも、標準通

信プロトコル本来の機能であるメッセージ単位のトランザクション処理

もできる。

• データ発生の都度送受信することにより、データ精度を高めリードタイム

を短縮することが可能。

社内でのデータ活用が柔軟になる。

• XMLデータを活用することにより、アプリケーションの多様化に容易に対

応できる。

国際標準（XML、GLN、GTIN）採用により、グローバル対応が容易。

(17)

16

６．流通BMSに移行するメリット

(2) 通信プロトコル標準を採用するメリット

物理的回線や専用ハードウェアの管理が不要になる。

対応可能なハードウェアが豊富。

• 同期モデム損傷による受発注業務停止のリスクがなくなる。

TCP/IP経由のオープン系システムであるため、社内システムとの親

和性が高い。

• ハードやソフトの共用・集約ができ、技術や資産の有効活用が可能。

• 回線の高速化、利用料低廉化により、リードタイム短縮・締め時間延長・

利用コスト削減が可能。

• 漢字や画像、EXCEL、PDFなど多様なデータを扱えるので、さまざまな

アプリケーションを通じ、データの有効活用が可能。

ファイル転送型WebEDIの手動操作がなくなる。

• 人件費や人的ミスを削減でき、業務の自動連携を促進できる。

国際標準（ebXML MS、AS2）採用により、グローバル対応が容易。

(18)

６．流通BMSに移行するメリット

(3) 通信インフラが個別回線からインターネットに

①JCA手順固有のリスクから解放される。

・複数回線の管理

・固有のハードウェア（同期モデム等）

②インターネット利用による処理の高速化、コストの低廉化が実現できる。

EDIサーバダイアルアップルータ INS６４全銀TCP/ IP 9600bps∼ 19.2kbps 公衆回線網全銀，JCA 2400bps UST

EDIデータ ACM S_{ACM S} E

E22_X_X

EDIサーバ

EDIデータ ACM SACM S E E22_X_X ルータ ACM SACM S E E22_X_X 通信サーバインターネット 50M bps∼ 100M bps （ベストエフォート） DMZ DMZ ・・・・・・・・・・・・・・・・従量課金従量課金定額料金定額料金ファイアウォール

(19)

18

６．流通BMSに移行するメリット

(4)相手先毎の個別対応がなくなり、取引先やデータ種別の

追加が容易に

XML XML ビジネスビジネス文書文書ＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステム社内形式データ変換プログラムA データ変換データ変換プログラムプログラムAA A社ﾌｫｰﾏｯﾄデータ変換プログラムB データ変換データ変換プログラムプログラムBB Ｂ社ﾌｫｰﾏｯﾄデータ変換プログラムC データ変換データ変換プログラムプログラムCC Ｃ社ﾌｫｰﾏｯﾄ・・・・・・・・・・・・・・・・アプリケーションアプリケーションアプリケーション社内形式アプリケーションアプリケーションアプリケーションＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステム中間形式項目・ｺｰﾄﾞ項目・ｺｰﾄﾞﾚｲｱｳﾄ変換ﾚｲｱｳﾄ変換 XML変換新たなアプリケーションでの利用可！！取引先ごとに、データを自社のフォーマットに変換するプログラムを作成する必要があった。 •標準フォーマットを、取引先ごとに区別することなく自社フォーマットに変換できる。一部固有の部分がある場合も、従来と違い限られた範囲での対応に抑えることができる。 •この変換は市販のツールを利用できる。ただし、ツールによっては、項目・コード・レイアウト変換などを別に行う必要があるものもある。 •XM Lビジネス文書は、このまま新たなアプリケーションでの利用が可能。 •UN/ EDIFACTやCII、X.12などは、標準フォーマットをそのまま利用することができなかった。 ACMS ANY変換手組み開発市販製品インターネットインターネットインターネット一般的には

(20)

６．流通BMSに移行するメリット

(5) 伝票レスでコスト削減

伝票レスとは、小売と卸・メーカの双方が「受領データ」を保存することにより、従来印刷していた複写式のTA（Turn Around）伝票の印刷が不要になること。これにより、伝票用紙代、プリント費用、伝票保管費用を削減できる。複写式伝票を印刷するインパクトプリンタも、機種が少なく印刷速度が遅い、メンテコストがかかるなど多くの問題を抱えていた。印刷後の伝票も、後日参照･検索する場合、膨大な紙の山から探し出すのは業務の効率を大幅に低下させていた。従来も実施例はあるものの、小売毎に仕様が異なり卸側は相手先毎に別システムを持つ必要があった。今回の流通BMSでは、その仕様が標準化され、システムの統一を図ることが可能となった。ただし、これを実現するには双方に高度な在庫精度と検品体制が必要となる。

(21)

20

６．流通BMSに移行するメリット

(6) 検品レスで業務の改革と効率化

検品レスとは、卸・メーカ側から納品伝票に代わる「出荷（梱包紐付けあり）

データ」（事前出荷明細）を事前に小売側に送っておき、出荷時に梱包に貼付

したSCMラベルのバーコードを受け入れ側（主に小売物流センター等）がス

キャンし、あらかじめ受信した事前出荷明細と照合することにより検品を行うこ

と。店舗での検品は省略できる。

この検品レスも、前記伝票レスと同様、小売毎に異なる仕様であったものが標

準化されたため、大きな省力効果が期待できる。

一方、卸・メーカ側は従来にも増して高度な物流体制が求められることとなる。

これを機会に業務改革を目指し更なる高効率化を進めたい。

卸･メーカ側

小売側

出荷明細出荷検品 _入荷検品事前出荷明細照合出荷（梱包紐付けあり）データ出荷（梱包紐付けあり）データ

(22)

Ⅱ．導入までの流れ

１．導入のモデル

(1) サーバタイプかクライアントタイプか

(2) サーバタイプの特徴

(3) クライアントタイプの特徴

(4) 自社構築かASP利用か

２．導入にかかわる全体の流れ

３．最初の取引先との本番移行まで

(1) 事前準備

(2) 環境構築

(3) アプリケーション開発とEDI関連情報設定

(4) テスト計画・移行方針の策定

(5) 取引先との接続テスト

(6) 本番移行

(23)

22

１．導入のモデル

(1)

(1) サーバタイプかクライアントタイプか

サーバタイプかクライアントタイプか

小売もしくは大手の卸・メーカは、基本的にサーバモデル

小規模の卸・メーカは、クライアントモデル

中間規模の企業は、データ量やプロトコルの特性に応じて判断

大メーカ大メーカ一次卸一次卸小売小売・・ASPASP事業者事業者二次卸二次卸 JX JX手順手順 JX JX手順手順 AS2 AS2 ebXML MS ebXML MS AS2 AS2 サーバサーバサーバサーバサーバサーバサーバサーバサーバクライアントクライアントクライアントクライアントクライアントクライアント小規模小規模卸卸 S S--SS型型EDIEDIモデルモデル C C--SS型型EDIEDIモデルモデル

(24)

（量販（量販ＸＸ））ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションデータ変換データ変換データ変換ＥＤＩクライアントシステムＥＤＩＥＤＩクライアントシステムクライアントシステムビジネス文書ビジネスビジネス文書文書インターネットインターネットインターネット社内形式社内形式ファイアウォール相当機能ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書 _ＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステムデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションインターネットインターネットインターネット社内形式社内形式ファイアウォール _（量販_（量販_Ｘ_Ｘ_）_）

★S-S型EDIモデル

★C-S型EDIモデル

J XJ X手順手順

１．導入のモデル

［注意］この図は、クライアント側での運用。

(25)

24

S-S型EDIモデル

取引先とサーバ同士で接続するモデル。

通信プロトコルはebXML MSもしくはAS2。どちらを選ぶかは取引先との調

整により決定する。

どちらのプロトコルも、データが発生したタイミングで相手に送りつけるPush

型通信。

C-S型EDIモデル

ハブとなる企業がサーバシステムを設置し、そこに向けて小規模の企業がク

ライアントシステムで接続するモデル。

通信プロトコルはJX手順。

送受信の要求はクライアント側から発し、サーバ側はその要求に応じて送受

信を行うPull型通信。

現行のEOSと同様の運用を実現。サーバ側は、企業が直接行う場合とVAN

やASPが行う場合がある。

１．導入のモデル

(26)

１．導入のモデル

システム規模決定の目安

共同実証の結果、JX手順による取引は、取引先との１取引データ量が10MBを超えないことが推奨されている。 XML化する場合のデータは、概ねキャラクタの１２倍となる。データ量が大きくなった場合は圧縮をする。 ebXML MSおよびJX手順では、zipを使う。この場合、圧縮後のファイルサイズは、XML で１／５０くらいになると言われている。 AS2では、プロトコルが持つ圧縮で行う。通信上で行うため、具体的な圧縮率は不明。その他、近い将来、接続する取引先が大きく増えたり、データ量の急激な増加が見込まれる場合も「サーバシステム＋サーバ通信プロトコル」の採用が推奨される。通信速度は、インターネットの１００Mbpsを利用した場合でも、実行速度は社内のLAN 環境に依存するため、現実には1∼3Mbps程度と考える。同時接続数は、ピーク時（決算時期等）の運用で最大のデータ量（支払・請求）による通信時間と、そのタイミングで送受信を必要とする相手先の数から計算する。

(27)

26

１．導入のモデル

◆ＪＣＡ注文データ１伝票をXM L化した場合の想定データ量 128byte × 4.2レコード × 12倍 ≒ 6.5kbyte ※XM L化した１伝票のデータサイズは約6.5kbyte ◆データ量が10M Bを超える場合の想定パターン支払メッセージのデータ量が最も多い。そのデータが10M Bに達するためのケースを想定すると、下記のように、１日平均220伝票分の注文データ発生すると考えられる。 10M B ÷ 128byte ÷ 12倍 ≒ ６５００伝票 ※1ヶ月の注文伝票が約6500∼7000伝票［参考］注文データが10M Bになるケースは、下記にように、１日1600伝票が発生する場合となる。 10M B ÷ 128byte ÷ 4.2レコード ÷ 12倍 ≒ 1600伝票

XML化した場合のデータ量の目安

【

前提

】

注文伝票１枚の平均明細数（業界平均）は注文伝票１枚の平均明細数（業界平均）は3.2_3.2行行 JCA

JCA注文データは、注文データは、11レコードレコード128byte128byte 1

1伝票は、ヘッダーレコード＋明細レコード伝票は、ヘッダーレコード＋明細レコード JCA

JCA支払データは、支払データは、11伝票伝票11レコード（レコード（128byte128byte）） XM L XM L変換により、キャラクタデータは１２倍のサイズになる変換により、キャラクタデータは１２倍のサイズになる・注文データ１レコード＝128byte ・注文データ１伝票＝4.2レコード (1ヘッダ + 3.2明細) ・テキスト→XM L変換指数＝１２倍・支払データ１レコード＝128byte ・支払データ１伝票＝1レコード

(28)

１取引データ量による選択

１．導入のモデル

１４１無制限１ 15MB以上 10~15MB １０MB未満

同

時

接

続

数

に

よ

る

選

択

③ ③ クライアントクライアント ② ② ミドルサーバミドルサーバ ① ① サーバサーバ高セキュリティ構成、負荷分散型構成高セキュリティ構成、負荷分散型構成 ※表の基準は目安。・採用する通信手順、想定されるデータの量、必要となるメッセージ等は、必ずお取引先にご相談してください。 ∼ ∼ ∼ ∼

システム規模とデータ量・同時接続数の相関図

(29)

28

１．導入のモデル

ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書インターネットインターネットインターネット社内形式社内形式ファイアウォールビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステムデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションインターネットインターネットインターネット社内形式社内形式ファイアウォール _取引先_取引先 ebXML MS

ebXML MS、、AS2AS2

J X J X手順手順サーバプロトコルサーバプロトコルＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステム取引先取引先［注意］後述の［注意］後述のJ X_{J X}手順クライアントプロトコルと矢印の向きが反対手順クライアントプロトコルと矢印の向きが反対

(2) サーバタイプの特徴

(30)

サーバタイプの特徴

インターネット上でサーバを常時稼働させる。通信プロトコルが、ebXML MS、AS2の場合、Push型通信を行う。つまり、アプリケーション側で送信データが生成されたら、その場で相手先に送る。受信は常に相手先からのデータを待ち、先方から送りつけられたら、その場で受ける JX手順サーバプロトコルの場合、常に相手からの要求を待ち、相手からの送りつけならそのまま受信に、相手への送信要求なら用意してあったデータを送る。 Push型通信プロトコルは、従来型通信方式と違い、通信と業務は分離独立している。そのため、送信側は相手の業務スケジュールと関係なしに、データ発生の都度送信する。受信側は、送られてきたデータを蓄え続け、自社の業務スケジュールで溜まったデータを取り出し、アプリケーションに渡す。これにより、通信も業務も相手のスケジュールに合わせることなく平準化を図ることができる。この方式を応用すると、要求を受けたらすぐに返答を返す準リアルタイムのトランザクション処理が可能となる。通信サーバはDMZ上に、データおよび管理サーバは社内に設置する。外部からの攻撃を受ける可能性があるため、データおよび管理サーバをDMZ上に設置してはならない。通信サーバと管理サーバを分離することができない場合、リバースプロキシを置き、外部からの攻撃を避ける工夫が必要。従来型通信プロトコルも並行運用する場合、新旧プロトコルは統合運用が望ましい。

１．導入のモデル

(31)

30

１．導入のモデル

（量販（量販ＸＸ））ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションデータ変換データ変換データ変換ＥＤＩクライアントシステムＥＤＩＥＤＩクライアントシステムクライアントシステムビジネス文書ビジネスビジネス文書文書インターネットインターネットインターネット社内形式社内形式ファイアウォール相当機能ビジネス文書ビジネスビジネス文書文書 J X J X手順手順クライアントプロトコルクライアントプロトコル［注意］前述の［注意］前述のJ X_{J X}手順サーバプロトコルと矢印の向きが反対手順サーバプロトコルと矢印の向きが反対

(3) クライアントタイプの特徴

(32)

１．導入のモデル

クライアントタイプの特徴

ＥＤＩ関連業務を行うときのみ、システムを運用する随時稼動型。通信プロトコルはJX手順。データの送受信が必要なときのみ起動し、送信もしくは受信を行う。業務アプリケーションとセットになったパッケージもある。運用形態は、JCA手順と同じであるため、通信システムを入れ替え、流通BMS関連の設定を行うだけで、既存の業務につなぐことができる場合もある。ただし、業務との連携部分を十分に確認する必要がある。 PCでの運用を想定したモデルであるが、サーバOSで利用することも可能。

(33)

32

１．導入のモデル

小売ですか？小売ですか？大規模システム大規模システムですか？ですか？１通信での１通信での大量データは大量データはありますか？ありますか？通信プロトコルに通信プロトコルに ebMS

ebMS、、AS2AS2、、 J X J X手順サーバプロトコルを手順サーバプロトコルを利用しますか？利用しますか？ YES YES YES YES YES YES YES YES NO NO NO NO サーバサーバサーバクライアントクライアントクライアント ASP ASPを利用を利用しますか？しますか？自社専用自社専用 ASP ASPにしますか？にしますか？ YES YES NO NO NO NO YES YES NO NO 自社専用 ASP 自社専用自社専用 ASP ASP 汎用ASP 汎用汎用ASPASP NO NO

自社構築

ASP

利用

(4) 自社構築かASP利用か

(34)

−２ヶ月 −１ヶ月当月＋１ヶ月 −３ヶ月 −４ヶ月 −５ヶ月機器・ソフトの調達システム開発内容の確認必要に応じてシステム開発接続テストフェーズ１フェーズ２フェーズ３旧システムとの並行運用平行運用の停止マッピング取引先との接続情報設定環境構築アプリケーション開発と EDI関連情報の設定本番移行凡例：

２．

導入にかかわる全体の流れ

プロジェクトの立ち上げ事前準備標準EDI仕様の理解取引先との接続テスト取引先との方針確認ネットワーク環境手配システム環境構築取り決め基本情報作成テスト計画・移行方針の策定テスト計画・移行方針の策定

(35)

34

(1) 事前準備

具体的作業を始める前に、正式なプロジェクトを立ち上げ、流通BMSにつ

いての十分な理解、取引先との調整を行います。

①プロジェクトの立ち上げ

• システム形態の選定

プロジェクトを立ち上げるにあたり、導入するシステム形態を選定します。「大手企業や大規模システムを持つ企業」と「中小企業や取引量の少ない企業」とは準備するEDIシステムの形態は異なります。企業の実態に応じたシステムを選定してください。 – S-S型EDIモデル » 取引先とサーバ同士で接続するモデル。 » 通信プロトコルはebXML MSもしくはAS2。どちらを選ぶかは取引先との調整により決定する。 » どちらのプロトコルも、データが発生したタイミングで相手に送りつけるPush型通信。 – C-S型EDIモデル » ハブとなる企業がサーバシステムを設置し、そこに向けて小規模の企業がクライアントシステムで接続するモデル。 » 通信プロトコルはJX手順。 » 送受信の要求はクライアント側から発し、サーバ側はその要求に応じて送受信を行うPull型通信。 » 現行のEOSと同様の運用を実現。サーバ側は、企業が直接行う場合とVANやASPが行う場合がある。

３．最初の取引先との本番移行まで

(36)

３．最初の取引先との本番移行まで

（量販（量販ＸＸ））ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションデータ変換データ変換データ変換ＥＤＩクライアントシステムＥＤＩＥＤＩクライアントシステムクライアントシステムビジネス文書ビジネスビジネス文書文書インターネットインターネットインターネット社内形式社内形式ファイアウォール相当機能ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書ＥＤＩサーバシステムＥＤＩＥＤＩサーバシステムサーバシステムデータ変換データ変換データ変換ビジネス文書ビジネスビジネス文書文書ビジネス文書ビジネスビジネス文書文書アプリケーションアプリケーションアプリケーションインターネットインターネットインターネット社内形式社内形式ファイアウォール _（量販_（量販_Ｘ_Ｘ_）_）

★S-S型EDIモデル

(37)

36

• 体制の立ち上げ

プロジェクトを立ち上げるため、流通BMS導入の目的を明確にし、必要な体制を決めます。 – 導入目的の明確化 » 自社の現状を整理し、なぜ今流通BMSの導入が必要なのかまとめます。 » ポイントは、取引先からの依頼、JCA手順の限界回避、コスト削減、事業の効率化、業務の拡大、等会社の置かれている環境を的確に理解することです。 – 体制の検討、組織化 » プロジェクト実施に必要な人材を選出します。 » 体制は、「取引先との接点となる人」「取引先との業務アプリケーションを開発する人」「EDIを運用する人」「システム・ネットワークインフラを管理する人」から構成されます。 » 経営に関わる方がメンバーに入ることも重要な要件です。 » 実際の構築段階では、ここにEDIパッケージベンダーやSIerは加わります。

３．最初の取引先との本番移行まで

(38)

• 計画の立案

プロジェクトが立ち上がると、具体的な計画の策定に入ります。ここで全体の作業負荷を見極め、予算を決定します。 – 全体計画の策定 » 導入期間の目安は、６ヶ月。 » システムの規模やアプリケーション改変の有無によりその期間は前後します。 » 「１．導入に関わる全体の流れ」を参考に大まかなスケジュールを組みます。 » 詳細なスケジュールは、標準EDIの仕様の理解や業務の見直しを進める中で確定してください。 – 稟議（予算、人、物の確保） » 大まかなスケジュールをもとに、概略予算を立てます。 » それをもとに、ハードウェア、ソフトウェア（EDIシステム、アプリケーション開発）、ネットワークベンダーに対してRFPを提示し、その費用を確定します。 » その他導入関連費用を洗い出し、ベンダー見積を合わせて最終稟議を作成します。 » ポイントは、自社システムと標準システムとのギャップに関わる開発費。

３．最初の取引先との本番移行まで

(39)

38

②標準EDI仕様の理解

• 従来方式との差異を理解

– 流通BMSとはどのようなものか、新しい通信プロトコルにはどのような特徴があるかをまず理解する。 – XMLベースのメッセージとはどのようなものかを理解する。 – 標準の業務フロー、メッセージ、項目の意味や扱いに現状との違いがないかを確認する。 – セキュリティーや証明書・署名は、従来なかった概念なので十分な理解が必要。 – 参考とする資料は、本冊子のほか、巻頭「はじめに」記載の「流通ビジネスメッセージ標準」ダウンロード資料をご参考にしていただきたい。

３．最初の取引先との本番移行まで

(40)

③取引先との方針確認

• 方針等を相互確認

– 最初に取り組む相手先は、経営レベルで相互に流通BMSの拡大を合意できるお取引先であること。

– 「共通確認シート」（*1）

をベースに、どの業務をどういう方式でいつごろまでに実現するかを確認する。 – お互い同じ言葉で確認しても、レベルの相違や理解の仕方にズレがあり、誤解を生むこともある。十分な話し合いが必要。 – 実現方法には、いくつものパターンがあるため、具体的な内容まで事前に確認し合うこと。

• スケジュール決定

– 双方の確認事項をもとに、環境構築、システム開発、テスト、本番移行等の順に具体的なスケジュールを決定する。 – 基本は６ヶ月で可能であるが、各社の事情も加味し無理な計画は立てない。 – 決算期や自社のイベント（サーバ入れ替え・・・）など繁忙期は避ける。 – ここでは大まかなスケジュールとし、詳細な検討を進める中でより綿密なスケジュールに落としていく。

３．最初の取引先との本番移行まで

（＊1）流通システム開発センターよりダウンロード：巻頭はじめに参照

(41)

40

(2) 環境構築

①ハード・ソフトの調達

• 全体構成の設計

– どのくらいの規模のシステムにするか。 – シングル構成かクラスター構成か。 – 通信サーバを分散型にするかリバースプロキシ経由単独型にするか。 – 既存EDIとの住み分けをどうするか。 – 既存のインターネット環境との住み分けをどうするか。 – 既存のLAN環境との住み分けをどうするか。 – 基幹システムとの連携をどうするか。ハード・ソフトとも。

• ハード･ソフト構成の検討

– ハードやネットワークはどのようになるか。 » サーバやインターネット対応機器など。 – どのようなソフトが必要となるか。 » セキュリティ関連ソフトやEDIシステムソフト、業務連携ソフトなど。 – 新規ハードを調達するか既存ハードを転用するか。 – システムの開発が必要かどうか。 – 既存のネットワークやシステムにどの程度の影響を及ぼすか。

３．最初の取引先との本番移行まで

(42)

• ハード・ソフトの選定・手配

– 候補製品を選び比較・評価・発注。 – 評価結果は報告書としてまとめておく。

• 工事

– 関連工事の手配・実施 – マシンルームレイアウト、電源、空調、LAN、屋内配線工事など

• ハードの搬入・設置

– ハードの搬入・設置 – 現調・動作確認

• ソフトのインストール

– ソフトのインストール – 基本設定

３．最初の取引先との本番移行まで

(43)

42

②ネットワーク環境手配

• 回線事業者（プロバイダ）・回線手配

– 回線事業者やインターネットプロバイダを選ぶ。 – 回線は障害に備えて２系統で確保。（NTTとパワードコム、等）

• グローバルIP・ドメイン名の登録申請

– 流通BMSでは、グローバルIPおよび企業ドメイン名が前提となる。 – 既に所有している場合は問題ないが、なければ新規に申請し取得する必要がある。

３．最初の取引先との本番移行まで

(44)

• 証明書・署名の取得申請（流通BMS専用の証明書）

– インターネット経由であるため、証明書・署名の使用が必須となっている。 – 使用するプロトコルやサーバかクライアントにより、必要な証明書・署名が異なる。 – 流通BMSでは、流通業界専用の証明書・署名が必要。パブリック証明書は使用できない。 – 業界指定の発行局に申請し取得する。2008年9月時点では、インテック並びにグローバルサインの２社。 – 証明書にはサーバ証明とクライアント証明がある。サーバ運用する場合にはサーバ証明が必須。 – サーバ証明書を申請すると、サーバ証明書と、クライアント証明書と、署名のフル機能取得できる。 – JX手順のPCでクライアント運用をする場合は、クライアント証明書のみを取得する。 – AS2を使用する場合には、署名が必要。この場合も流通BMS専用証明書をそのまま利用することが可能。 – 一般に有効期限は３年。期限切れになる前に再取得し、自社EDIシステムに登録する必要がある。

• 企業コード（GLN）取得申請

– 流通BMSでは、企業コードとしてGLNの使用が必須となっている。 – すでにJAN企業コードもしくはJANメーカコードを保有している場合は、それの利用が可。 – 未使用の場合は、新たに流通システム開発センターに申請し取得する必要がある。

３．最初の取引先との本番移行まで

(45)

44

③システム環境構築

インターネットを利用したセキュアな通信・アプリケーション稼働環境を構築する。

• 基本ソフトとミドルウェアの環境設定

– サーバOS、DBまわりの設定。 – ウイルス対策、DNS設定、FW設定、NAT設定。

• ネットワーク機器の環境設定

– ルータやネットワーク関連機器の設定。 – 社内LANやプロバイダーとのインターネット接続確認。

• サーバ通信環境の構築

– EDI関連サーバと業務サーバ間のシステム連携確認。

３．最初の取引先との本番移行まで

(46)

(3) アプリケーション開発とEDI関連情報設定

①システム開発内容の確認

• 既存業務との差異を確認

– 基本的には、既存の業務を大幅に変更することなく流通BMSに移行できるように考えられている。 – ただ、細かく見ると少しずつ異なるところもあるはず。それがどの程度影響があるかを調べる必要がある。 – 業務フロー、メッセージで使われている項目、項目名称の呼び方・自社での使われ方など。 – 業務の視点では、 » 伝票レスをするかしないか、納品のプロセスはどのようなパターンになるか、など。 – メッセージでは、 » 企業識別がGLNになり、登場人物も小売側では「支払い法人」「発注者」「直接納品先」「最終納品先」「計上部署」、卸／メーカー側では「最終送信先」」「請求取引先」「取引先」「出荷場所」等の細かい分類となる。 » 商品コードはGTINになり、発注用コードと集合包装用コードは、分けて考える。 » 日付の考え方も、発注日、納品日（直接納品先納品日・最終納品先納品日）、計上日と意味づけが明確になっている。 » その他、番号（取引番号・取引明細番号・取引付属番号等）、金額、数量、区分・コード値、梱包情報、等の扱いも細かく定められた。 – また、自社独自の方式の有無や標準と一致しない所がないかなどを調査。 – これらについては

「マッピングシート」(*2)

により、標準と対比しながら使用の有無や扱

３．最初の取引先との本番移行まで

(47)

46

②必要に応じてシステム開発

• システムの改修･追加開発箇所を特定

– 調査結果に基づき、既存システムに改修を加える必要があるところ、新たに開発しなければならないところ、がどこかを特定する。 – 伝票レスによる業務の追加・変更、項目追加やコード値（荷姿コード）標準化による処理の変更など。

• トランスレータを用いてフォーマット変換・データ加工・編集処理

– 流通BMSでは標準データフォーマットがXMLとなる。そのため「既存データ⇒XML」「XML⇒既存データ」の変換のステップが新たに発生する。この変換は、フォーマット変換ツール（トランスレータ）を用いて行う。 – XML標準側スキーマは、流通システム開発センターより配布される。これにより、メッセージの基本チェック（バリデーションチェック）を行うことができる。 – トランスレータには、フォーマット変換・項目変換・コード変換・計算・関数処理ができるものもある。どの程度までできるかは、製品のスペックによる。 – 単純な変換や編集・計算などは、極力その機能を使い、手作りのプログラム開発は最小限に抑える。

• 既存業務との連携を含めて必要となるシステムを開発

– 開発内容を明確にし、詳細のスケジュールを確定する。 – 個別開発は、通常の開発ルールに従って設計∼開発∼テストを行う。 – 新しいシステムによる業務の組み立て、既存業務との連携、運用管理も含め、全体の流れを作り上げる。 – テストは、流通BMS関連業務の通信を除いた部分での業務連携テストまで実施する。

３．最初の取引先との本番移行まで

(48)

③EDIサーバに取引先との接続情報設定

レガシーＥＤＩに比べ設定情報が格段に増えている。特に、異なる法人が相対で

サーバ相互認証を行うのは経験の少ない分野。接続相手と十分に調整し、不整

合のないように注意する。

• 通信パラメータ設定

– 「通信パラメータ協定シート」

(*3)

を、「小売側」「卸／メーカー側」双方で記入。 – 記入したものをもとに双方でCPAを作成し、ＥＤＩサーバに登録。ただ、現実には「小売側」がCPAを作成し、「卸／メーカー側」に配布するパターンが多く見受けられる。 – 「通信パラメータ協定シート」にそってＥＤＩサーバに以下の接続情報を設定する。 » ＥＤＩ基本情報協定 » ＥＤＩ通信パラメータ協定（ebXML MS、AS2、JX手順）

• 証明書関連設定

– 証明書発行局から取得した自社証明書をＥＤＩサーバへ登録。 – ACMSの場合、通信サーバを分散構成にした場合であっても、証明書は管理サーバへ登録。

• 運用情報・業務連携情報設定

– スケジュール情報、業務連携情報、運用情報等を、各々必要とされる所定のEDIサーバや関連機器に設定する。

３．最初の取引先との本番移行まで

(49)

48

(4) テスト計画・移行方針の策定

①テスト計画の策定

• 流通BMSに関わる業務一連の流れに対してテスト計画を立てる。

• 改修・追加・新規開発を含めた社内システムと、相手先まで含めた全体の流れ

を分けたテスト計画が必要。

• 特に障害系については、社内のみならず関連企業との連携もふまえた計画を作

成する。

３．最初の取引先との本番移行まで

(50)

②移行方針の策定

– 移行にあたっては、接続先と移行対象・移行順・時期・整合性の確認方法・旧シ

ステムとの並行稼働期間等について綿密な調整を行う。

– 本番開始判定基準、旧システムの停止基準を双方で確認する。

– 本番移行が不可能だと判断した場合、旧システムに戻すための段取り等も計

画、明文化する。

– 移行において個別対応が必要な場合を想定し、その対応マニュアルも作成す

る。

– 本番移行後、未整備のドキュメントはキッチリとまとめ、拡大時に混乱のないよ

うマニュアル化を進める。

– 拡大に向けた取引先への説明会、説明資料等の準備も行う。

３．最初の取引先との本番移行まで

(51)

50

(5) 取引先との接続テスト

①フェーズ１：疎通テスト

• EDI通信環境の相互接続

• ネットワークの確認、EDIシステム送受信確認

– 相互認証を含めたEDIシステム間でのメッセージ送受信を確認。

②フェーズ２：EDIシステム間の流通ビジネスメッセージ標準確認

• 送信メッセージの生成とEDI通信、受信メッセージの検定

• 標準メッセージ形式と送受信の相互接続

– 業務データをXMLの標準フォーマットに変換して送信、受信した側はそのXMLデータを業務データに逆変換し整合性の確認を行う。 – 整合性の確認は、XMLレベルでのスキーマを使ったバリデーションチェックと業務レベルの項目チェックの両方で確認する。

③フェーズ３：業務システム間の整合性確認

• 業務システムを含めた標準プロセスに従った送受信の確認

– 本番業務に準ずるデータを用意し、業務の最初から最後まで通した一連の結果が正当であることを双方で確認する。 – 実際に起こり得るあらゆるパターンの確認を行い、整合性が確認できた段階で本番移行可能とする。

３．最初の取引先との本番移行まで

(52)

(6) 本番移行

①旧システムとの並行運用による新システムの稼働開始

• 本番稼動状況ウォッチ

• 旧システムとの整合性チェック

– 新システムに本番データと同じデータを投入し並行稼働開始。 – 稼働結果を確認し整合性をチェック。

②旧システムから新システムへ本番業務を切替

• 本番開始判定

• 本番業務を旧システムから新システムへ切替

– 本番開始判定基準に基づき、取引先と双方合意が取れた段階で本番業務を新システムに切替。

③旧システムの並行運用停止

• 旧システム停止判定

• 旧システムを停止し新システムでの完全本番化

– 一定の並行稼働後、旧システムの停止基準に基づき旧システムを停止。移行は新システムだけで稼働。

③移行後のドキュメント整備

– 正常稼働を開始した段階で、継続運用が可能なように各種ドキュメント、マニュアル類を整備する。

３．最初の取引先との本番移行まで

(53)

52

Ⅲ．導入事前準備

１．流通ビジネスメッセージ標準

２．通信プロトコル標準

３．必要となる申請・手続と期間

３−１回線・プロバイダ・グローバルIP

３−２ドメイン名

３−３証明書

(54)

１．流通ビジネスメッセージ標準

(1) 業務プロセス

受発注業務モデル：

業務の流れを標準化

•小売企業と卸・メーカとの間で受発注･出荷･受領をやり取りするモデル。 •発注で付番される取引番号が、出荷、受領、請求、支払の各メッセージに引き継がれるため、取引番号をキーとして発注から支払までの取引を追うことができる。

業務とメッセージ種：

業務の種類とメッセージの内容を標準化

•発注［発注、生鮮発注、集計表作成］、出荷［出荷伝票、出荷梱包（紐付あり）、出荷梱包（紐付なし）、生鮮出荷］、受領［受領、生鮮受領、集計表作成］、返品［返品、生鮮返品］、請求、支払、値札、在庫［補充勧告、報告］、入庫［予定、確定］、等。 •メッセージ種はEDI通信手順に依存していない。

伝票レス：

紙の伝票を廃止

•「ＥＤＩメッセージ」を商品売買の証憑とみなすことにより、取引当事者間でやり取りされているペーパーの仕入伝票（統一伝票）をなくし、運用費用（伝票代、発行時間、保存コスト、パンチコスト等）を削減する。 •現在は流通ＢＭＳの使用に限り、請求伝票に関して保存しなくても良いと国税庁から確認が取れている（請求伝票以外は、企業個別に税務署の確認を受ける必要があるが、将来的には、帳票保存が不要になる予定）

(55)

54

１．流通ビジネスメッセージ標準

メッセージ一覧

（流通システム開発センター資料より）

(56)

１．流通ビジネスメッセージ標準

(2) メッセージ項目

企業識別：

登場人物とコード体系を標準化

•登場人物の体系を標準化

【課題】 − 従来は、項目として「店」、「センター」、「計上部署」があり、指定が必要な場合に当事者が任意にセットするルールとしていたため、卸・メーカー（受注者）にとって、物流上、商流上の決済ポイントがあいまいになる恐れがあった。【対策】 − 流通ビジネスメッセージ標準では、最終納品先、直接納品先、計上部署、発注者、支払法人の５つを設けて、「卸メーカー（受注者）は、どこに納品するのか」、「最終的にどこに納品されるのか」「所有権が移転するのはどこか」「発注者は誰か」「支払うのは誰か」を表現できるようにした。（次ページ参照） – 登場人物：小売 » 最終納品先、直接納品先、計上部署、発注者、支払法人 – 登場人物：卸・メーカー » 最終送信先、請求取引先、取引先、出荷場所

(57)

56 売場・フロア売場・フロア

１．流通ビジネスメッセージ標準

– 登場人物の関係店舗店舗最終納品先／計上部門陳列場所物流センター物流センター直接納品先／計上部門小売Ａ社小売Ａ社小売小売（Ａ社グループ企業）（Ａ社グループ企業）卸・メーカ卸・メーカ XX社社卸・メーカ卸・メーカ（（XX社グループ企業）社グループ企業）支払企業請求取引先発注者取引先倉庫倉庫事業部事業部枝番出荷先コード VAN VAN データ送信元直接送信先最終送信先 VAN事業者が介在する場合（流通システム開発センター資料より）（流通システム開発センター資料より）

(58)

１．流通ビジネスメッセージ標準

•GLN（Global Location Number） − コード体系を標準化

– 国際流通標準機関GS1が、企業や事務所を識別するために定めた、グローバルでユニークになる１３桁のコード

– JAN企業コード／GLN企業コードは、流通システム開発センターが付番貸与 GLNロケーションコードは、各企業が付番基準に沿って自らの責任で付番

商品識別：

コード体系を標準化

•GTIN（Global Trade Item Number） − コード体系を標準化

– 集合包装用商品コード（１４桁）とEANコード（JANコード：１３桁、８桁）とUPCコード（１２桁、８桁）を包括し、１４桁にそろえた国際標準の識別コード。 – 現在のJANバーコード・シンボル、およびその桁数（１３桁、８桁）を変更する必要はない。 – 上記３種類のコードは、いずれも「０」を前詰めし、１４桁にそろえてGTINとする。４４９９００１１００１１００ＬＬＬＬＬＬＬＬＬＬ CDCD （例）（例） GLN GLN企業コード（企業コード（JANJAN企業コード）企業コード）ロケーションコードロケーションコード各企業が付番各企業が付番

(59)

58

１．流通ビジネスメッセージ標準

メッセージ間の項目の引継ぎ

発注・出荷・受領メッセージ間における項目の引継ぎ例。

赤字

の部分は、前の

メッセージでセットされた値を後のメッセージに引き継ぐ。

＜支払い法人＞支払い法人コード＜発注者＞発注者コード＜取引＞取引番号： 1000001 請求取引先コード取引先コード＜取引内容＞発注日： 2007年1月18日計上日： 2007年1月２０日（予定日）＜取引合計＞原価金額合計： 5,000円数量合計： 5 ＜取引明細＞商品コード（発注用）原価金額： 1,000円発注数量（バラ）： 5 ＜取引明細＞・・・・・・発注発注 ■赤字は引継項目 ■青字は基本的には引継だが変更する場合もある項目（再計算等） ■灰色の字は引き継がない項目＜支払い法人＞支払い法人コード＜発注者＞発注者コード＜取引＞取引番号： 1000001 請求取引先コード取引先コード＜取引内容＞発注日： 2007年1月18日計上日： 2007年1月２０日（予定日）＜取引合計＞原価金額合計： 4,000円数量合計： 4 （再計算）＜取引明細＞商品コード（発注用）原価金額： 1,000円発注数量（バラ）： 5 出荷数量（バラ）： 4 欠品数量（バラ）： 1 ＜取引明細＞・・・・・・出荷出荷＜支払い法人＞支払い法人コード＜発注者＞発注者コード＜取引＞取引番号： 1000001 請求取引先コード取引先コード＜取引内容＞発注日： 2007年1月18日計上日： 2007年1月２3日（確定日）＜取引合計＞原価金額合計： 4,000円数量合計： 4 ＜取引明細＞商品コード（発注用）原価金額： 1,000円発注数量（バラ）： 5 出荷数量（バラ）： 4 欠品数量（バラ）： 1 受領数量（バラ）： 4 ＜取引明細＞・・・・・・受領受領（流通システム開発センター資料より）（流通システム開発センター資料より）

(60)

１．流通ビジネスメッセージ標準

(3) メッセージ構造

メッセージフォーマットにXMLを採用

•XMLの特徴

–各データ項目単位にデータの意味を表すタグを持ち、複数のデータ項目をグループ化（構造化）することができる。外部構造化も可能。 –データとレイアウト・デザインを分離可能。［XMLデータ例］ <lineID> <lineNumber>01</lineNumber> </lineID> <itemID> <gtin>04902106843603</gtin>

<orderItemCode codeType="005">4902106843603 </orderItemCode> <name>こだいらカップ本格的コーンクリーム１０Ｐ</name> <name_sbcs>ｺﾀﾞｲﾗｶｯﾌﾟﾎﾝｶｸﾃｷｺｰﾝｸﾘｰﾑ</name_sbcs> </itemID> ・・

•EDIを行う上でのメリット

–XMLは多くのプラットフォーム上で取扱可能なため、システム環境に依存することなくデータ転送・データ処理が可能。