(57)【要約】【課題】  複数企業間でＥＤＩ取引を行う場合、業界が異なるとそれぞれ相手先のフォーマット、コード体系、プロトコルに合わせるための導入コストが取引量と見合っていないため、ＥＤＩ取引が進展しない原因となっている。また海外企業とのＥＤＩ取引では、マスタ項目の見直しやシステム変更が必要となる場合もあり、広範囲のサプライチェーンシステム実現への妨げとなっている。各企業での導入負荷を軽減し、短期間で複数の企業とのＥＤＩ取引を実現させる事を目的とする。【解決手段】  企業内のＥＤＩシステムでは無く、企業との間に共同で利用可能なＥＤＩシステムを構築する。複数企業、異なる業界でＥＤＩ取引が可能とするためにＥＤＩデータを柔軟に分解、コード変換、再編集を行う。またＥＤＩデータをシステム内に保存することで同一取引情報を共有化することもできる。重要な取引情報の漏洩防止として企業及びユーザのアクセス許可確認、相手先からの情報開示の許可及びデータを複数サーバーで分解して保存を行う事で容易に情報が流出できない仕組みが必要となる。システム構成としてアプリケーションを実行するサーバーとデータ管理するサーバーを分け、アクセス数の増加やデータ量の増加への対応が可能となる。【選択図】    図１
0003105359.tif 000002
【実用新案登録請求の範囲】
【請求項１】
ＥＤＩ取引を広く普及させるための複数の企業及び異なる業界で共同利用可能なＥＤＩシステムで、４種類のサーバーと１種類のユーザツールから構成される。
サーバーには企業との通信を受け持つアプリケーションサーバーと物理的にデータを格納するデータサーバー、システムで使用するアプリケーションを開発し配信するアプリケーション開発サーバー、データを分解再構築するためのデータモデルを開発提供するデータモデル開発サーバーがある。ユーザインタフェースは、共同ＥＤＩシステムへ直接接続可能で、ＥＤＩデータの登録や送受信、コード変換テーブルの設定などを行う。
企業からの送信データはまずアプリケーションサーバーを経由してデータサーバーへ格納される。次に送信データより送信元情報を抽出し、送信元のデータモデルをデータモデル開発サーバーより取得する。送信元のデータモデルに従って、受信データを項目ごと分解し、データサーバーへ格納する。次に、送信データより送信先を抽出し、データモデル開発サーバーより送信先のデータモデルを取得する。分解されたデータを取り込み、データモデルに従って再編集し、その際レイアウトの変更や、項目編集、デフォルト値の設定、コード変換を行う。
受信データについても同様に、送信元のデータモデルに従って項目ごとに分解される。その分解された項目を送信先のデータモデルに従って再編集を行う。通常ＥＤＩデータは複数のレイアウトから構成されているので、受信データの１レコードがデータモデルのどのレコードレイアウトで分解再編集を行うのかを判断して、各レコードごとに分解し格納し再編集を行う。
【請求項２】
ＥＤＩシステムを共同利用する上で重要な情報漏洩の防止策として、上記アプリケーションサーバーとデータサーバーの分離の他、ユーザからのアクセスごとに許可を確認する方法、データを細分化し複数のデータサーバーへ分散する方法で対応する。
企業からの依頼は送信データとして共同ＥＤＩシステムへ送られる。共同ＥＤＩシステムではその送信データを受信した際に、登録されている契約情報と突合せ、アクセスが許可されているかを確認する。アクセス許可は企業コードとユーザコードごとに設定される。また、送受信データはデータセンタ内では分解し保存される。同一タイプの項目は同一データベースに格納され、コードと名称、項目と項目タイプは別データサーバーに保管される。
【請求項３】
共同ＥＤＩシステムでは情報の共有ができる。情報開示はまず、情報を開示する企業が相手先の企業コード、ユーザコード、項目ごとに開示のレベル（照会、変更、複製）を登録する。情報開示を受ける企業は、相手企業の情報開示データに自社会社コード、自社ユーザコードと開示されている項目を検索し、照会することができる。また、変更が許可されている項目に関しては、他社データ変更依頼を発行して変更することができる。複製に関しては、情報開示を受ける企業が、その情報を他企業へ提供する際に使用できるが、提供先企業は情報を開示する企業に事前に情報開示の登録を行う。
【考案の詳細な説明】
【技術分野】
【０００１】本考察は、複数の企業が複数の取引先とのＥＤＩ取引を円滑に行えるように共同で利用可能なＥＤＩシステムを実現するための、柔軟なデータの処理方法、情報漏洩防止、データ量やアクセスポイントの増加への対応方法の技術に関する。また、データの送受信だけでなく、データを保持することで、必要な情報の開示共有化も可能とする技術にも関する。
【背景技術】
【０００２】現状のＥＤＩ取引は、主要な取引先で取引量の多い企業間だけで行われている。また、業界で標準フォーマットや標準プロトコルを規定している団体もあるが、設定する内容やコード類が企業により異なる場合があり、ＥＤＩ取引を行う際に新しいプログラムの開発や新たな通信ソフト、専用端末等の購入が必要となる場合もある。そのため取引量の少ない企業では導入費用に見合う効果が得られず、広範囲のサプライチェーンシステムの実現に限界を与えている。【０００３】業界が異なる企業とのＥＤＩ取引を行う場合、その業界標準のフォーマットやコード体系に対応するためにシステムの開発、新たなマスタ項目の追加などの作業を行う事になる。【０００４】従来型のＥＤＩシステムは、生産管理や購買管理システムから発注データを生成し送信している。その発注内容は社内の生産管理システムや購買管理システムで確認はできるが納期などの回答情報や代替品の納入など変更に関する情報は必ずしも生産管理システムや購買管理システムに反映されていない場合も多い。また、送信または受信の時点でコード変換等が行われるが、その変換が最新情報に基づいていない場合もある。そのため、ＥＤＩ取引でもお互いに電話連絡での確認が無くならず充分な導入効果が得られているとは言えない。【０００５】工事や大規模なプロジェクトでは発注先が多数になる場合が多く、末端企業ではシステムを持たない企業もある。工事の進捗状況や、発注状況を網羅して把握するためには、それぞれの担当者と電話連絡などで行われているだけで、工事の進行の妨げとなるボトルネックの把握がしずらい環境がある。
【考案の開示】
【考案が解決しようとする課題】
【０００６】本考察は、前述の問題を解決するために、各企業の負担を軽減するとともに取引内容を共有化することを可能とするための共同で利用可能なＥＤＩシステムの実現を目的とする。
【課題を解決するための手段】
【０００７】各企業でそれぞれを相手先としてＥＤＩ取引を行う場合、業界である程度標準化できていたとしても複数の変換テーブルが必要となる。しかし、共同で利用可能なＥＤＩシステムでかつ様々なインタフェースに対応したシステムを利用できれば任意のアプリケーションシステムに接続するだけで、ネットワークを介して他企業とのＥＤＩ連携が可能となる。【０００８】１つの製品を完成させるための部品、原材料を調達する場合、全て同じ業界標準のＥＤＩが使用できる訳ではない。異なる業界標準のため、一旦受注システムで取り込み、生産管理システムまたは購買システムより再度発注を行う。その際は別のＥＤＩインタフェースを使用する事になる。共同で利用可能はＥＤＩシステムを実現するためには各種のＥＤＩ取引に対応するため柔軟なデータ処理が必要となる。そのためには、データは最小単位に分解し再編集する方法で対応する。【０００９】ただ、データを最小単位に分解再編集する場合、各企業で取引先ごとにその手順を設定していたら精度も悪く、作業量も膨大となってしまう。そのため、標準的な雛型としてデータモデルを用意し、そのデータモデルを参照しながら自社用のデータモデルを生成し短期間にＥＤＩ取引を実現する。【００１０】共同でＥＤＩシステムを運用するには、他社への情報漏洩を防止する必要が有るが、契約した企業のみアクセス可能とすることで外部からの不正アクセスを防止する。またアクセスは登録され有効となっている場合に許可される。その単位は企業だけでなくユーザごとにも行われるので、未登録の企業やユーザからのアクセスは防止できる。【００１１】また、データも最小単位に分割されそれぞれ別のデータサーバーへ格納されている。しかも、コードと名称、データと従属項目を分けて保存しているため例えば数字データだけでは、それは金額なのか単価なのか数量なのかは判別できない。【００１２】共同で利用可能なＥＤＩシステムで情報を共有化することにより利用範囲が拡大する。受注データを参照し、発注データへ変換も可能で、開示範囲を拡大することで発注先のそのまた先の発注先まで仕様や制限事項、納期等を伝えることができる。開示の内容は相手企業、相手ユーザ、項目ごとに参照可能か変更を許可するが、複製を許可するかなどを開示する企業は設定できる。
また、有効期間などを制限することで特定期間での特製取引の特定項目のみの開示を設定することができる。
【考案の効果】
【００１３】既に、一部のＥＤＩを稼動させている企業では、そのＥＤＩシステムを使用しながら、新たな取引先とのＥＤＩ取引が可能となる。使用中のＥＤＩフォーマットを変更せず、共同ＥＤＩシステムへ接続することで、相手先のフォーマットへの変換や情報の共有化を行う事ができる。それにより、特定企業との情報だけでなく、現在取引している全てのＥＤＩ取引の情報を取得することが可能となる。また、より細かい情報の伝達も共同ＥＤＩシステムで行う事も可能となる。【００１４】ＥＤＩ取引を行っていない企業では、共同ＥＤＩシステムとのアクセスを行う事で、複数の企業とのＥＤＩ取引が可能となる。
また、発注情報を共有化していれば受注データへの変換も容易で、自社の生産販売システムとの連携が行える。現在進行中のＥＤＩ取引を一覧的に検索を行う事ができる。
【考案を実施するための最良の形態】
【００１６】以下、本考察の実施の形態を図に基づき説明する。
図１は共同ＥＤＩシステムを構成する各サーバーの関連を示す。
図２はＥＤＩデータの送信に関する各サーバーの関連を示す。
図３はデータの共有に関する各サーバーの関連を示す。
図４はＥＤＩデータの送信の詳細な手順を示す。
図５は保存されている自社情報、ＥＤＩ受信データの取込みに関する詳細な手順を示す。
図６は情報開示に関する詳細な手順を示す。
図７は送受信データと内部データの関連を示す。
図８はデータ項目の項目を示す。【００１６】図１に基づき共同ＥＤＩシステムを構成するサーバーについて説明する。
ｃ１からｃ５は企業のシステムまたは端末を示す。ａ１からａ４は、アプリケーションを実行するサーバーで、各ユーザからの依頼データを受け処理を行う。ａ０は共同ＥＤＩシステム全体で使用されるアプリケーションの開発と提供を行う。ｂ０は共同ＥＤＩシステム全体で使用されるデータモデルの開発と提供を行う。ｂ１からｂ６は、実際のデータを保持し、要求にしたがって検索、更新、登録を行う。各システム間はネットワークで接続される。
企業からの大量のアクセスによるシステムの負荷に対しては、アプリケーションサーバーを分散することで対応する。また、データ量の増加による負荷の増加にはデータサーバーを分割することで対応する。【００１７】図２に基づきユーザからのアクセスと各システムの関連を説明する。
企業からのアクセスはｃ１からａ１へ行われる。ａ１ではまず、このアクセスが許可されているかを確認するため、ｃ１の契約情報が格納されているｂ１契約情報の有無及び基本情報設定アドレスの取得依頼を行う。
依頼内容は企業コード、ユーザコード、契約番号、日付で、ｂ１はその条件に一致するデータを検索し、検索結果をａ１へ返す。
基本情報がｂ２に格納されている場合、ｂ２より基本情報を検索し、データモデルを取得する。
取得したデータモデルに従って受信データを分割し、ｂ１からｂ３に分けて保存する。
その後、送信先ｃｘのデータモデルを取得し、ｂ１からｂ３に分散しているデータを再編集し、ｃｘへ送信する。
受信データはａ１内には保存されず、常にｂ１からｂ３に分割して保存される。【００１８】図３に基づき企業ｃ１がｃ２へ情報開示を行っている場合の手順を説明する。
企業のデータはアプリケーションサーバーａ１を経由してデータサーバーｂ１からｂ３に分割して保存されている。ｃ１とｃ２の契約のより、ｃ１のデータをｃ２に開示するため、データモデル開発サーバーｂ０に申請を行い、ｂ０はｃ１とｃ２の依頼を受け、契約情報に開示相手先としてｃ２及びｃ１の設定依頼をａ１及びａ２に対して行う。
ａ１はｃ１の契約情報に開示先としてｃ２を設定し、ａ２はｃ２の契約情報に開示先としてｃ１を設定する。
その後、ｃ１では開示先企業ｃ２を検索し、情報を開示するデータモデル、項目群、項目、開示範囲などを設定する。
ｃ２は契約情報の開示先ｃ１にアクセスが許可されているのを確認後、ｃ１の基本情報を読み、許可されている範囲のデータを取得する。【００１９】図４に基づき企業ｃ１からＥＤＩデータを送信するまでの手順を説明する。
ただし、送受信に使用するプログラムは業界や企業で規定され、市販ソフトも多数流通しているので詳細な説明はここでは省略する。
企業ｃ１からの受信文はプログラムｐ１に渡され、依頼番号００１を判別し処理される。まず、受信文を企業ｃ１の契約情報格納先ｂ１に保存する。データサーバーｂ１では内部処理番号００により、受信文をデータサーバーｂ１の作業領域ｃ１−ｗ１に保存する。
アプリケーションサーバーａ１内には送受信データは保存しない。
次にプログラムｐ１はデータサーバーｂ１に対し、内部処理番号０１の契約情報の確認依頼０１を送信する。データサーバーｃ１では企業ｃ１の契約情報を検索し、結果を依頼元アプリケーションサーバーへ送信するこの契約情報の確認は企業からのアクセスごとに最初に実行される。
アクセス許可が確認されたら、次に基本情報の取得依頼０２を基本情報設定先ｂ２に対してして行い、取得結果がプログラムｐ３へ渡される。プログラムｐ３では処理の続行可否を判断し、続行する場合データサーバーｂ１に保存されている受信文ｃ１−ｗ１に対して処理中フラグの設定依頼０３を送信する。また、データモデル開発サーバーｂ０に対して、企業ｃ１のデータモデルの提供依頼０４を送信する。データモデル開発サーバーｂ０ではデータモデルを取得し送信する。プログラムｐ４はデータサーバーｂ２に対して作業領域の確保依頼０５を送信する。作業領域が確保できたら、結果を依頼元アプリケーションサーバーへ送信する。プログラムｐ５では最初に受信文の取得依頼０６をデータサーバーｂ１に送信する。受信文はプログラムｐ６が受信しデータモデルに従って受信文を分解後、データサーバーｂ２の作業領域ｃ１−ｗ２への保存依頼０７を送信する。プログラムｐ７では登録結果を受け作業領域ｃ１−ｗ２の全データの取得依頼０８を送信する。プログラムｐ８では取得したｃ１−ｗ２の各項目を分解し、データサーバーｂ１からｂ３に項目ごとに登録依頼０９を送信する。その後、連続して送信を行うため送信先データモデルの取得依頼１０をデータモデル開発サーバーｃ０へ送信する。プログラムｐ９では送信先のデータモデルを取得後データサーバーｂ２の作業領域ｃ１−ｗ２に保存されているデータの取得依頼１１を送信する。
連続して処理しない場合は、各データサーバーに保存されているｃ１−ｄ１からｃ１−ｄ３までのデータを収集し、作業領域ｃ１−ｗ２を作成するプログラムを起動することになる。プログラムｐ１０では送信先のデータモデルとデータサーバーｂ２の作業領域ｃ１−ｗ２のデータを元に送信文を編集しデータサーバーｂ２の作業領域ｃ１−ｗ３への登録依頼１２を送信する。プログラムｐ１１では送信文を受取り送信先へ送信後、各作業領域のデータに対し処理済フラグの設定依頼１３，１４，１６を送信する。【００２０】図５に基づき企業ｃ１の分解された自社情報を取得する手順を説明する。
プログラムｐ４までの手順については前述と同じなので省略し、プログラムｐ２０から説明を行う。
プログラムｐ２０では、企業ｃ１の基本情報も元に最初のデータが格納されているデータサーバーｂ１に対し、対象データの抽出依頼２０を送信する。次に取得結果を受信し、取得内容をデータサーバーｂ２の作業領域ｃ１−ｗ２へ登録依頼２１を送信し、継続項目が有れば引き続きデータサーバーｂ２に対し、対象データの抽出依頼２０を送信する。その取得結果を受信後、取得内容をデータサーバーｂ２の作業領域ｃ１−ｗ２へ登録依頼２１を送信し、継続項目を確認し引き続きデータサーバーｂ３に対し、対象データの抽出依頼２０を送信する。その取得結果をデータサーバーｂ２の作業領域ｃ１−ｗ２へ登録依頼２１を送信する。継続項目が無しとなるまで、各データサーバーへの取得依頼とデータサーバーｂ２の作業領域ｃ１−ｗ２への登録依頼２１を繰り返す。最後にデータサーバーｂ２の作業領域ｃ１−ｗ２に完了フラグの設定依頼２２を送信する。プログラムｐ２１では集められたデータを受信し、送信文を作成し企業ｃ１へ送信する。その後、処理済フラグの設定依頼２３を送信する。【００２１】図６に基づき企業ｃ２の依頼で共同ＥＤＩシステムに保存されている企業ｃ１の開示情報を取得する手順を説明する。
プログラムｐ２までの手順については前述と同じなので省略し、プログラムｐ３０から説明を行う。
プログラムｐ３０では、企業ｃ２の基本情報に企業ｃ１のデータへのアクセスが許可されている事を確認し、企業ｃ１の契約情報にも企業ｃ２へのアクセスが許可されているかの取得依頼３０を送信する。アクセスの許可が確認されたらプログラムｐ３０は企業ｃ１の基本情報の取得依頼３１を送信する。その取得依頼で取得できるのはあくまで企業ｃ１が企業ｃ２に情報開示を設定した内容だけである。プログラムｐ３０では次に企業ｃ１の基本情報に企業ｃ２への開示項目が登録されているかを確認し、企業ｃ１の使用しているデータモデルの取得依頼３２をデータモデル開発サーバーｂ０へ送信する。プログラムｐ３１では企業ｃ１のデータモデルと基本情報に登録されている開示項目を各データサーバーへ取得依頼３３を送信し、作業領域ｃ２−ｗ２への登録依頼３４をデータサーバーｂ３へ送信する。継続項目が無くなったらデータサーバーｂ３の作業領域ｃ２−ｗ２へ完了フラグの設定依頼３５を送信する。集められたデータはプログラムｐ３３で受信し、企業ｃ２へ送信する。また、作業領域の受信文ｃ２−ｗ１及び収集用作業領域ｃ２−ｗ２に処理済フラグの設定依頼３６を送信する。【００２２】図７及び図８に基づき共同ＥＤＩシステムで使用されているデータ構造について説明する。
各業界標準となっているＥＤＩデータは固定長のテキストデータである場合が多い。
そのレイアウトは様々だが、データモデルを使用して分解再編集を行う。
データモデルの先頭項目の条件とは、桁位置と桁数、識別文字が設定されている。全銀フォーマットでは１バイト目の文字でどのレコードかを識別している。受信したデータがどのレコードのそのレイアウトなのかをまず判断するために使用する。その下にデータ項目として１から順に受信データを分割するための条件が設定されているその内容がデータ項目内容である。データモデルは標準以外に企業ごと、ユーザごとに作成ができる。
また情報開示の設定を項目ごとに行うため、各項目に企業コードとユーザコードを設定されている。項目群と項目はデータ項目の内容を識別するために使用する。品目や価格といった項目を表示させる場合に使用し、国外の取引先でも利用可能とするため言語コードごとの設定もできる。この項目群と項目も企業ごとユーザごとに設定ができる。
データはデータモデル内には無く分解し保存する際に設定される。データタイプはその項目の編集内容などを設定するために使用する。通常、ＥＤＩデータは金額でもテキストデータとして取り扱うが、他業界や国外とのＥＤＩ取引では桁数の違いや単位の表記が異なったりしている。変換する際には相手先の条件に合わせ編集するため項目ごとにデータタイプとして設定をしておく。現在用意されているデータタイプを図８に示す。国内のＥＤＩデータでは企業名は通常カタカナ半角で設定されるが、国外の場合、英語表記となる。受信データのデータモデルでは言語コードは日本語で設定されているが、送信先のデータモデルが国外の場合、言語コードを英語とし保存されているデータから英語表記の会社名を取得する。その場合事前に変換テーブルを登録しデータタイプの変換有無を有りと設定しておく必要がある。
【図面の簡単な説明】
【図１】共同ＥＤＩシステムの各サーバー関連を示す図である。
【図２】ＥＤＩデータを送信する際の各サーバーの関連を示す図である。
【図３】情報開示元ｃ１と情報開示を受けるｃ２の関連を示す図である。
【図４】ＥＤＩデータを送信する際の手続きを示す図である。
【図５】格納されているＥＤＩデータを受取る際の手続きを示す図である。
【図６】情報を共通化し、相手へ開示する為の手続きを示す図である。
【図７】送受信データと分解されたデータの関連を示す図である
【図８】項目に従属する情報を示す図である。
【符号の説明】
ａ０  アプリケーション開発サーバー
ａ１からａ４  アプリケーションサーバー
ｂ０  データモデル開発サーバー
ｂ１からｂ６  データサーバー
ｃ１からｃ５  企業
ｃｘ  送信先企業
ａ１−ｒａ  アプリケーションサーバーａ１の企業からの受信プログラム
ａ１−ｒ  アプリケーションサーバーａ１の受信プログラム
ａ１−ｓａ  アプリケーションサーバーａ１の企業への送信プログラム
ａ１−ｓ  アプリケーションサーバーａ１の送信プログラム
ａ２−ｒａ  アプリケーションサーバーａ２の企業からの受信プログラム
ａ２−ｒ  アプリケーションサーバーａ２の受信プログラム
ａ２−ｓａ  アプリケーションサーバーａ２の企業への送信プログラム
ａ２−ｓ  アプリケーションサーバーａ２の送信プログラム
ｂ０−ｒ  データモデル開発サーバーｂ０の受信プログラム
ｂ０−ｓ  データモデル開発サーバーｂ０の送信プログラム
ｂ１−ｒ  データサーバーｂ１の受信プログラム
ｂ１−ｓ  データサーバーｂ１の送信プログラム
ｂ２−ｒ  データサーバーｂ２の受信プログラム
ｂ２−ｓ  データサーバーｂ２の送信プログラム
ｂ３−ｒ  データサーバーｂ３の受信プログラム
ｂ３−ｓ  データサーバーｂ３の送信プログラム
ｃ１−ｒ  企業ｃ１の受信プログラム
ｃ１−ｓ  企業ｃ１の送信プログラム
ｃ２−ｒ  企業ｃ２の受信プログラム
ｃ２−ｓ  企業ｃ２の送信プログラム
ｐ１からｐ３３  アプリケーションプログラム
ｃ１−ｋ１  企業ｃ１の契約情報
ｃ１−ｋ２  企業ｃ１の基本情報
ｃ１−ｄ１  企業ｃ１のデータ１
ｃ１−ｄ２  企業ｃ１のデータ２
ｃ１−ｄ３  企業ｃ１のデータ３
ｃ１−ｍ１  企業ｃ１のデータモデル１
ｃ１−ｍ２  企業ｃ１のデータモデル２（送信先ｃｘ用データモデル）
ｃ１−ｗ１  企業ｃ１からの受信データ
ｃ１−ｗ２  企業ｃ１の編集データ
ｃ１−ｗ３  企業ｃ１の編集データ
ｃ２−ｋ１  企業ｃ２の契約情報
ｃ２−ｋ２  企業ｃ２の基本情報
ｃ２−ｗ１  企業ｃ２からの受信データ
ｃ２−ｗ２  企業ｃ２の編集データ
００１から００３  企業からの依頼番号
０１から３６  内部処理番号
【図１】
0003105359.tif 000003
【図２】
0003105359.tif 000004
【図３】
0003105359.tif 000005
【図４】
0003105359.tif 000006
【図５】
0003105359.tif 000007
【図６】
0003105359.tif 000008
【図７】
0003105359.tif 000009
【図８】
0003105359.tif 000010
【手続補正書】
【提出日】平成16年6月25日(2004.6.25)
【手続補正１】
【補正対象書類名】実用新案登録請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【実用新案登録請求の範囲】
【請求項１】
複数企業との通信及び送受信データの分解再構築により複数フォーマットへの変換処理を受け持ちデータは保有しないアプリケーションサーバー、物理的にデータを分解格納しアプリケーションサーバーからの依頼によりデータを抽出し提供するデータサーバー、当システム内で使用する全てのアプリケーションプログラムを開発し配信するアプリケーション開発サーバー、データを分解再構築するためのデータモデルを開発提供するデータモデル開発サーバー、アプリケーションサーバーへ直接接続し社内システムで取り込む必要のないＥＤＩデータの送受信や社内システムが未整備でもＥＤＩ取引や品目情報の提供、コード変換情報の設定を行うことができるユーザツールにより構成される複数企業と異なる業界でも共同で利用可能なＥＤＩシステム。
【請求項２】
アプリケーションサーバーとデータサーバーの分離、ユーザからのアクセスごとの許可確認、データを細分化し複数のデータサーバーへ分散し、同一タイプの項目を同一データベースに格納し他データとの関連性を分からないように格納、またコードと名称、項目と項目タイプを別データサーバーに保管する事で情報漏洩防止及び漏洩した情報が意味をなさない仕組みを保有する請求項１に記載のＥＤＩシステム。
【請求項３】
情報を開示したい企業が相手先の企業コード、ユーザコード、項目ごとに開示のレベル（照会、変更、複製）を登録しておき、情報開示を受けたい企業は、相手企業の情報開示データに自社会社コード、自社ユーザコードと開示されている項目を設定することで開示された情報を検索し照会することができ、また変更が許可されている項目に関しては、その項目の変更依頼を発行して変更し返信データとして送信を行うことも可能であり、また複製が許可されている項目に関して、情報開示を受けた企業が、その項目を事前に許可された企業へ複製し提供可能とする請求項１に記載のＥＤＩシステム。