JP2017111593A - 電子データ交換システムおよび電子データ交換方法 - Google Patents

Abstract

【課題】マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ効率的な商取引データの処理を可能とする。【解決手段】電子データ交換システム１００において、商取引の当事者、当該当事者が送信する可能性のある電子データ種別、および当該当事者と電子データ種別に応じたデータ処理の優先度、を定めたテーブルを格納する記憶装置１０１と、電子データを含むファイルを所定端末より受信し、当該ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した優先度をテーブルに基づき判定し、当該判定した優先度に基づいて、当該ファイルに含まれうる電子データ間での処理順序を仮定し、当該処理順序に従って、当該ファイルに含まれる電子データの抽出および送信先への配信を実行する演算装置１０４を含む構成とする。【選択図】図２

Description

本発明は、電子データ交換システムおよび電子データ交換方法に関するものであり、具体的には、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ効率的な商取引データの処理を可能とする技術に関する。

企業間の商取引の効率化のために、注文、見積、請求などの商取引データを、通信回線を介して電子的に送受信する、電子データ交換（ＥＤＩ：Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）システムを利用する企業が増加している。

このＥＤＩシステムは、従来では、電話、ＦＡＸ、郵送などでやり取りされてきた商取引データを、インターネット回線などを通じて電子データの形でやり取りできる。これにより、企業にとっては、業務効率やセキュリティの向上という効果を得ることができる。また、商取引データを、各企業の既存システムに依存する独自形式から業界標準の形式に変換する機能も備えることが一般的になっており、更なる業務効率の向上が可能となっている。

こうしたＥＤＩシステムに関する技術としては、例えば、基幹システムで管理される形式のデータを受信する受信手段と、前記受信手段によって受信した順に、ＥＤＩ通信をおこなう際に用いる形式のデータとなるようにフォーマット変換する変換手段と、を有するＥＤＩシステムであって、前記受信手段で受信されたデータが緊急案件であるか判断する判断手段と、前記判断手段で受信されたデータが緊急案件であると判断された場合に、当該緊急案件のデータをフォーマット変換するためにかかる変換時間に応じて、前記変換手段によってフォーマット変換を行う順番を調整する調整手段と、を有するＥＤＩシステム（特許文献１参照）などが提案されている。

特開２０１５−１６２１５９号公報

企業によっては、商取引データのやり取りの速度が売上や業務効率に大きく影響する。そのためＥＤＩシステムに対して、データ送受信に要する時間に関して、性能保証を厳しく求める場合がある。

例えば、注文データを送信し、その回答を受信するまでを１５分以内に完了する、といったレスポンスに関する条件や、買掛データを、その日の１５時までに全て送信完了する、といった処理期限に関する条件等の遵守が、ＥＤＩシステムに求められることになる。具体的には、ＥＤＩシステムを利用する企業毎の契約事項の一部に、上述のような条件がサービスレベルアグリーメント（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）として盛り込まれる。そこで、ＥＤＩシステムの提供者は、上述のＳＬＡを保証するための追加費用をユーザに請求する一方で、ＳＬＡの遵守は必須となる。

ところが、ＥＤＩシステムはいわゆるマルチテナント方式で構築、運用されることが一般的で、複数ユーザのデータ処理を同一環境で行うため、データ処理速度の保証が難しい。例えば、あるユーザ企業から受信した商取引データの形式変換に想定以上の時間がかか
った場合、その次に受信した別のユーザ企業の商取引データの処理が想定より遅れてしまい、結局、ＳＬＡを満たすことが困難になるケースがある。

しかも、上述した従来のＥＤＩシステムにおける商取引データ（以降、集信ファイルとする）の処理は、集信ファイルが複数の商取引データ（以降、個別ファイルとする）の統合体であることを踏まえたものではない。なお、個別ファイルは、ユーザ企業の業務システムで取り扱う任意形式の商取引データである。そのため、１つの集信ファイルに、処理の優先度が異なる個別ファイルが混在する状況であっても、優先度と無関係に形式変換等の処理を行うことになる。

他方、ＳＬＡの条件が厳しいユーザ企業用に、個別のシステム環境を提供することで、上述したマルチテナント方式に由来した問題を解決することも考えられる。しかし、こうした運用を行う場合、システム導入および運用のためのコスト、手間が増大する事態が生じる。

そこで本発明の目的は、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ効率的な商取引データの処理を可能とする技術を提供することにある。

上記課題を解決する本発明の電子データ交換システムは、商取引の当事者、当該当事者が送信する可能性のある電子データ種別、および当該当事者と電子データ種別に応じたデータ処理の優先度、を定めたテーブルを格納する記憶装置と、前記電子データを含むファイルを所定端末より受信し、当該ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該ファイルに含まれうる電子データ間での処理順序を仮定し、当該処理順序に従って、当該ファイルに含まれる電子データの抽出および送信先への配信を実行する演算装置と、を備えることを特徴とする。

また、本発明の電子データ交換方法は、商取引の当事者、当該当事者が送信する可能性のある電子データ種別、および当該当事者と電子データ種別に応じたデータ処理の優先度、を定めたテーブルを格納する記憶装置を備えた情報処理システムが、前記電子データを含むファイルを所定端末より受信し、当該ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該ファイルに含まれうる電子データ間での処理順序を仮定し、当該処理順序に従って、当該ファイルに含まれる電子データの抽出および送信先への配信を実行する、ことを特徴とする。

本発明によれば、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ効率的な商取引データの処理が可能となる。

本実施形態の電子データ交換システムを含むネットワーク構成図である。 本実施形態における電子データ交換システムのハードウェア構成例を示す図である。 本実施形態における集信ファイルの具体例１を示す図である。 本実施形態における集信ファイルの具体例１を示す図である。 本実施形態における集信ファイルの具体例１を示す図である。 本実施形態における集信ファイルの具体例１を示す図である。 本実施形態における会員マスタのデータ構成例を示す図である。 本実施形態における優先度マスタのデータ構成例を示す図である。 本実施形態における情報区分マスタのデータ構成例を示す図である。 本実施形態における取引関係マスタのデータ構成例を示す図である。 本実施形態における電子データ交換方法のフロー例を示す図である。 本実施形態における処理順序テーブルの遷移例１を示す図である。 本実施形態における処理順序テーブルの遷移例２を示す図である。 他の実施形態における電子データ交換方法のフロー例を示す図である。 他の実施形態における処理順序テーブルの遷移例１を示す図である。 他の実施形態における処理順序テーブルの遷移例２を示す図である。

−−−ネットワーク構成−−−

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の電子データ交換システムたる電子データ交換サーバ１００（以下、電子データ交換サーバ）を含むネットワーク構成図である。図１に示す電子データ交換サーバ１００は、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ効率的な商取引データの処理を可能とするコンピュータシステムである。

なお、本実施形態では、企業間の商取引における注文や見積依頼と、それらに対する回答を電子データで送受信する状況を踏まえた説明を行う。しかしながら、それ以外の、企業間での各種電子データのやり取りに関しても本発明は同様に適用可能である。

図１に例示するネットワーク構成は、ＥＤＩサービスを提供する電子データ交換サーバ１００と、ＥＤＩサービスの会員たる各企業の業務システム１００１〜１００４とが、インターネットなど適宜な通信網１０を介して、通信可能に接続された構成となっている。なお、本実施形態の電子データ交換サーバ１００と、業務システム１００１〜１００４をあわせて電子データ交換システムを構成するとしてもよい。

ここでまず、電子データ交換サーバ１００が提供するＥＤＩサービスの会員企業間の関係性について説明する。企業の立場において、ＥＤＩサービスの導入は、商取引データの送受信を効率化することが目的となっている。しかしながら、ＥＤＩサービスの会員として、商取引データの送信者だけが存在しても、商取引は成り立しない。従って、送信者がＥＤＩサービスを介して送信した商取引データを受信し、応答する受信者も、同じＥＤＩサービスを利用する状況が必要である。

そこで通常は、ＥＤＩサービス導入を決定した企業（主に物品やサービスの発注者）がＥＤＩサービスにおける「幹事会員」（図１における“企業Ａ”、“企業Ｂ”）となると共に、自身の取引相手の企業（主に受注者）に対して、同じＥＤＩサービスの「参加会員」（図１における“企業Ｘ”、“企業Ｙ”）となるよう要請する。この取引相手の企業がＥＤＩサービスの「参加会員」となった場合、上述の「幹事会員」との取引関係をＥＤＩサービスにて設定し、実際の商取引を行うことになる。

こうした会員企業間の関係性において、ＥＤＩサービスにおける、商取引データの送受信に関する時間的制約（ＳＬＡに反映される）を規定するニーズがあるのは幹事会員である。従って、幹事会員が、ＥＤＩサービスの契約時にＳＬＡを締結することになる。

こうした本実施形態では、「幹事会員企業Ａ」、「幹事会員企業Ｂ」、「参加会員企業Ｘ」、「参加会員企業Ｙ」が同じＥＤＩサービス、すなわち電子データ交換サーバ１００を利用し、「幹事会員企業Ａ」と「幹事会員企業Ｂ」のそれぞれが、ＥＤＩサービスの運
営企業とＳＬＡを締結しているとする。

図１のネットワーク構成のうち、上述した幹事会員企業や参加会員企業が備えるのが、業務システム１００１〜１００４である。こうした業務システム１００１〜１００４は、例えば各企業が独自に採用している任意の受発注システム１００５と、その受発注システムが生成する商取引データや電子データ交換サーバ１００から受信する商取引データを蓄積する記憶装置１００６と、商取引データを電子データ交換サーバ１００と送受信する通信装置１００７を少なくとも備えている。但し、ＥＤＩサービスの利用を前提として従来から存在する一般的な業務システムの構成と同様であり、詳細な説明は省略する。

なお、業務システム１００１〜１００４らが、電子データ交換サーバ１００を介して送信する商取引データは、各企業の任意のフォーマットの電子ファイルである。その詳細については後述するが、各企業の業務システムにおけるバッチ処理で、任意の個数の電子ファイルすなわち個別ファイルが統合された集信ファイルである。こうした集信ファイルは、企業ごとの任意のタイミングで電子データ交換サーバ１００に送信されるものとする。−−−ハードウェア構成−−−

続いて、本実施形態の電子データ交換サーバ１００のハードウェア構成について説明する。図２は、本実施形態における電子データ交換サーバ１００のハードウェア構成例を示す図である。本実施形態における電子データ交換サーバ１００は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、通信網１０と接続し各企業の業務システム１００１〜１００４との通信処理を担う通信装置１０５、を少なくとも備える。

なお、記憶装置１０１内には、本実施形態の電子データ交換システムとして必要な機能部１０１０〜１０７０を実装する為のプログラム１０２に加えて、各種データ１０８１〜１０８６が格納されている。こうしたデータ１０８１〜１０８６の詳細については後述する。

また、記憶装置１０１はファイル蓄積部１０２０を保持している。このファイル蓄積部１０２０は、当該電子データ交換サーバ１００の通信部１０１０が幹事会員企業や参加会員企業の業務システム１００１〜１００４から受信した集信ファイル（複数の個別ファイルを統合した電子ファイル）や、フォーマット変換部１０５０やファイル分割部１０６０による所定処理を受けた集信ファイルや個別ファイルを蓄積している。勿論、ファイル蓄積部１０２０は、記憶装置１０１ではなくメモリ１０３に備わるとしてもよい。

次に、当該電子データ交換サーバ１００の備える各機能部について説明する。このうち通信部１０１０は、幹事会員企業や参加会員企業の業務システム１００１〜１００４から受信した集信ファイルに対して、当該集信ファイルを一意に表すファイルＩＤを所定規則で付与し、ファイル蓄積部１０２０に蓄積するプログラムによって構成されている。また更に、当該通信部１０１０は、フロー制御部１０３０から個別ファイルの配信命令を受けた場合に、ファイル蓄積部１０２０に蓄積されている配信対象の個別ファイルを指定の順序で、指定の宛先に送信するプログラムによって構成されている。

なお、当該通信部１０１０は、ネットワークインターフェイスなど適宜な通信装置１０５によって構成される。

また、フロー制御部１０３０は、ファイル蓄積部１０２０を監視し、一定の期間ごとに、ファイル蓄積部１０２０に蓄積された集信ファイル群に対して、後述する各処理部１０４０〜１０７０を呼び出し、当該集信ファイル群の優先制御、フォーマット変換、ファイル分割、振分を行い、配信対象の個別ファイルを生成するごとに、通信部１０１０に対して当該個別ファイルを、指定の順序で、指定の宛先に送信するように命令するプログラムとして構成されている。当該フロー制御部１０３０および各処理部１０４０〜１０７０の動作フローは後述する。

また、優先制御部１０４０は、上述のフロー制御部１０３０から、ファイル蓄積部１０２０に蓄積されている集信ファイル群に対する優先制御処理の命令を受けて、記憶装置１０１に格納されているマスタ群１０８１〜１０８４を参照して集信ファイル群の処理順序を指定する処理順序テーブル１０８５、１０８６を生成し、当該処理順序テーブルを記憶装置１０１に格納するプログラムとして構成されている。

また、フォーマット変換部１０５０は、上述のフロー制御部１０３０から、ファイル蓄積部１０２０に蓄積されている集信ファイル群に対するフォーマット変換処理の命令を受けて、記憶装置１０１に格納されている処理順序テーブル１０８５、１０８６を参照して、変換対象となっている集信ファイル群を判別してフォーマット変換を行い、その変換後の集信ファイルをファイル蓄積部１０２０に蓄積するプログラムとして構成されている。

ここで上述のフォーマット変換について説明する。ＥＤＩサービスを利用する各企業の業務システムは、業界標準や独自仕様など、任意のフォーマットの電子ファイル、すなわち集信ファイルを生成し、電子データ交換サーバ１００に送信してくる。それらの集信ファイルに対して、統一的な処理や配信を行うために、業界標準や当該ＥＤＩサービス指定仕様、そして受信者の業務システムに合わせた仕様などに、フォーマット変換を行う必要がある。

このフォーマット変換の仕様は、企業毎に定義することが通常であり、本実施形態では詳細には言及しないが、フォーマット変換部１０５０は、企業毎のフォーマット変換定義（記憶装置１０１に予め保持）に基づいてフォーマット変換処理を実行する。このフォーマット変換には、文字コード変換や辞書変換（ある単語を別の単語に置き換える、など）の処理も含まれている。こうした各種のフォーマット変換は、その処理時間が長くなるケースもある。

また、ファイル分割部１０６０は、上述のフロー制御部１０３０から、ファイル蓄積部１０２０に蓄積されている集信ファイル群に対するファイル分割処理の命令を受けて、記憶装置１０１に格納されている処理順序テーブル１０８５、１０８６を参照して、分割対象となっている集信ファイルを判別し、個別ファイルへのファイル分割を行い、その分割後の電子ファイル群、すなわち個別ファイル群をファイル蓄積部１０２０に蓄積するプログラムとして構成されている。

ここで、上述のファイル分割について説明する。ＥＤＩサービスを利用する各企業から送信されてくる集信ファイルは、複数個の個別ファイルを結合したり、圧縮したりして統合した形であることが通常である。そのため、集信ファイルの送信先に統合前の個別ファイル群を配信するためには、個別ファイルへのファイル分割を行う必要がある。

例えば、ＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）形式やＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のファイルは、カンマ区切りで各値が定義されたファイルであるなど、その形式の特性上、個別ファイルへの分割方法の定義が容易である。そのため、上述のフォーマット変換では、任意フォーマットから
ＣＳＶ形式やＸＭＬ形式に変換することが電子データ交換サーバ１００にとって好適である。本実施形態では、詳細には言及しないが、電子データ交換サーバ１００のファイル分割部１０６０は、企業毎のファイル分割定義（記憶装置１０１に予め保持）に基づいてファイル分割を行う。

また、振分部１０７０は、上述のフロー制御部１０３０から、ファイル蓄積部１０２０に蓄積されている個別ファイル群に対する振り分け処理の命令を受けて、記憶装置１０１に格納されている処理順序テーブル１０８５、１０８６を参照し、配信対象となっている個別ファイル群を判別し、その電子ファイル群、配信順序、そして宛先に関する情報をフロー制御部１０３０に通知するプログラムと、この通知後に、処理順序テーブル１０８５、１０８６の状態を更新し、未処理の個別ファイルがあれば優先制御処理の継続を、未処理の個別ファイルがなければ優先制御処理の終了を、フロー制御部１０３０に通知するプログラムとして構成されている。
−−−データ構造例−−−

続いて、本実施形態の電子データ交換サーバ１００が用いるデータ類について説明する。図３Ａ〜図３Ｄに、本実施形態における集信ファイル２０１０〜２０４０の具体例１〜４を示す。集信ファイルは、上述の通り、幹事会員企業や参加会員企業の業務システム１００１〜１００４から送信されてくる電子ファイルである。

この集信ファイル２０１０〜２０４０は、複数個の個別ファイル２０１１〜２０１４、２０２１〜２０２３、２０３１〜２０３３、２０４１〜２０４２が統合された形となっている。

例えば、集信ファイル２０１０は、「幹事会員企業Ａ」の業務システム１００１から受信した集信ファイルであり、「参加会員企業Ｘ」への注文情報である個別ファイル２０１１、「参加会員企業Ｘ」への見積情報である個別ファイル２０１２、「参加会員企業Ｘ」への環境情報である個別ファイル２０１３、そして「参加会員企業Ｙ」への注文情報である個別ファイル２０１４が統合されている。また、この集信ファイル２０１０には、通信部１０１０によって、ファイルＩＤ：Ｆ００１が付加されている。他の集信ファイル２０２０、２０３０、２０４０も同様の構造である。

ところで、任意の種類、宛先、個数の個別ファイル群が統合された集信ファイルは、フォーマット変換し、ファイル分割を行わないと、含まれる個別ファイルの正確な内訳はわからないことが一般的である。本実施形態の電子データ交換サーバ１００では、そのような集信ファイル群に対する優先制御（後述）について対応可能となっている。但し、集信ファイルのフォーマットが、電子データ交換サーバ１００の規定する構造たるＣＳＶ形式やＸＭＬ形式であれば、フォーマット変換前にファイル分割をすることで個別ファイルの内訳がわかることもあり、そのような集信ファイル群に対する優先制御については、他の実施形態で説明する。

続いて図４は、本実施形態における会員マスタ１０８１のデータ構成例を示す図である。本実施形態の会員マスタ１０８１は、ＥＤＩサービスを利用する会員企業の会員ＩＤをキーとして、それぞれの会員企業の会員種別（幹事会員か参加会員か）の値を対応付けたレコードの集合体となっている。こうした会員マスタ１０８１は、各会員企業のＥＤＩサービス利用登録時に、登録・更新される。

続いて図５は、本実施形態における優先度マスタ１０８２のデータ構成例を示す図である。本実施形態における優先度マスタ１０８２は、上述の幹事会員がＥＤＩサービスの契約時に締結する、商取引データ（この場合は個別ファイル）の送受信の時間的制限に対す
るＳＬＡに相当するマスタである。

当該優先度マスタ１０８２は、幹事会員ＩＤをキーとして、その会員が送受信する個別ファイルの情報区分（例：注文情報、見積情報、環境情報）と、それぞれの情報区分の個別ファイルに対する処理の優先度（所要時間の上限）の各値を対応付けたレコードの集合体となっている。

図５で例示する優先度マスタ１０８２では、「幹事会員企業Ａ」が送受信する注文情報、見積情報、環境情報、「幹事会員企業Ｂ」が送受信する注文情報、見積情報に対して、優先度が指定された構造を示している。

なお、「幹事会員企業から参加会員企業への商取引データの送信」だけでなく、「参加会員企業から幹事会員企業への商取引データの送信」に対しても、幹事会員企業の指定した優先度が適用される必要がある。ＥＤＩサービスを利用する幹事会員企業にとって、商取引データの送信だけでなく受信も含めた商取引が、迅速化したい業務内容となるためである。この優先度マスタ１０８２は、各幹事会員企業のＥＤＩサービス利用契約時に、登録、更新されるものである。

続いて図６は、本実施形態における情報区分マスタ１０８３のデータ構成例を示す図である。本実施形態における情報区分マスタ１０８３は、ＥＤＩサービスを利用する会員企業の会員ＩＤをキーとして、それぞれの会員企業が送信する集信ファイルに含まれうる個別ファイルの情報区分の値を対応付けたレコードの集合体となっている。

この情報区分マスタ１０８３によって、集信ファイルのフォーマット変換やファイル分割を行わなくても、集信ファイルの送信者に基づいて、優先度の高い個別ファイルを含む集信ファイルである可能性を判定できる。図６で例示する情報区分マスタ１０８３では、「会員企業Ａ」の集信ファイルには、注文情報、見積情報、環境情報が含まれる可能性があり、「会員企業Ｂ」の集信ファイルには注文情報、見積情報が含まれる可能性があることを示している。また、この情報区分マスタ１０８３は、各会員企業のＥＤＩサービスの利用登録時に、登録、更新されるものである。

図７は、本実施形態における取引関係マスタ１０８４のデータ構成例を示す図である。本実施形態における取引関係マスタ１０８４は、幹事企業会員と参加企業会員の間で送受信する集信ファイルが含みうる個別ファイル、すなわち情報区分のリストである。

この取引関係マスタ１０８４によって、特に、参加会員企業の集信ファイルのフォーマット変換やファイル分割を行わなくても、優先度の高い個別ファイルを含む集信ファイルである可能性を判定できる。図７で例示する取引関係マスタ１０８４では、「幹事会員企業Ａ」と「参加会員企業Ｘ」の間でやり取りする集信ファイルに、注文情報、見積情報、環境情報が含まれる可能性があることを示している。この取引関係マスタ１０８４は、各会員企業のＥＤＩサービスの利用登録時に、登録、更新されるものである。
−−−フロー例−−−

以下、本実施形態における電子データ交換方法の実際手順について図に基づき説明する。以下で説明する電子データ交換方法に対応する各種動作は、電子データ交換サーバ１００がメモリ等に読み出して実行するプログラム１０２によって実現される。そして、このプログラム１０２は、以下に説明される各種の動作を行うためのコードから構成されている。

図８は、本実施形態における電子データ交換方法のフロー例を示す図である。ここでは
、ファイル蓄積部１０２０に蓄積された複数の集信ファイル群に対し、フロー制御部１０３０が行う優先送信処理の手順について、図３の集信ファイル、図４〜７の各マスタを例として説明する。

この場合、電子データ交換サーバ１００のフロー制御部１０３０は、ファイル蓄積部１０２０を監視し、一定の期間ごとに、ファイル蓄積部１０２０に蓄積された集信ファイル群に対して、優先送信処理を行う（Ｓ７００１）。

以降の処理は、ケース１：「集信ファイル２０１０と集信ファイル２０２０が蓄積されている場合」、とケース２：「集信ファイル２０３０と集信ファイル２０４０が蓄積されている場合」、のそれぞれについて説明する。ケース１は、送信者が幹事会員企業のみである場合、ケース２は送信者が参加会員企業のみである場合である。なお、送信者が幹事会員企業、参加会員企業の混在の場合も、同様の処理を適用することが可能である。
［ケース１］

フロー制御部１０３０は、優先制御部１０４０を呼び出し、ファイル蓄積部１０２０に蓄積されている各集信ファイル２０１０、２０２０に対して優先度判定処理を実施させる。 この場合の優先制御部１０４０は、該当集信ファイル２０１０、２０２０の送信元企業の会員ＩＤ（図３Ａ、３Ｂにおける“Ｆｒｏｍ”以降の値）を、会員マスタ１０８１に照合して、該当各集信ファイル２０１０、２０２０の送信者の会員種別に関する判定を行う（Ｓ７００２）。

集信ファイル２０１０の送信者は「会員企業Ａ」、すなわち会員ＩＤ「Ａ」であるため、これを会員マスタ１０８１に照合すれば「幹事会員」と判定される。同様に、集信ファイル２０２０の送信者は「会員企業Ｂ」、すなわち会員ＩＤ「Ｂ」であるため、これを会員マスタ１０８１に照合すれば「幹事会員」であると判定される。

続いて優先制御部１０４０は、上述のステップＳ７００２で該当集信ファイルから読み取った会員企業の会員ＩＤの値を、情報区分マスタ１０８３に照合して、該当集信ファイルに含まれうる個別ファイルの情報区分を判定する（Ｓ７００３）。

集信ファイル２０１０の送信者は「会員企業Ａ」、すなわち会員ＩＤ「Ａ」であるため、これを情報区分マスタ１０８３に照合すれば、集信ファイル２０１０に含まれうる個別ファイルの情報区分は、注文情報、見積情報、環境情報であると判定される。同様に、集信ファイル２０２０に含まれうる個別ファイルの情報区分は、注文情報、見積情報であると判定される。

この判定の結果、送信者が幹事会員であると判定した場合（Ｓ７００３：幹事企業）、優先制御部１０４０は、該当集信ファイルについての処理としてＳ７００５へステップを遷移させる。上述の例では、各集信ファイル２０１０、２０２０のいずれも、その送信者が幹事会員であるため、ステップはＳ７００５に遷移することになる。

この場合、優先制御部１０４０は、上述の各ステップで得ている会員ＩＤをキーに、優先度マスタ１０８２で検索を実行し、該当会員が送信してきた各集信ファイルが含みうる個別ファイルに基づいて、当該集信ファイルに対する処理の優先度を特定する（Ｓ７００５）。例えば、会員ＩＤ「Ａ」の会員企業に由来する集信ファイル２０１０が含みうる個別ファイル（情報区分）に基づいた優先度は、注文情報が「１５分」、見積情報が「６０分」、環境情報が「無条件」、と判定できる。また、会員ＩＤ「Ｂ」の会員企業に由来する集信ファイル２０２０が含みうる個別ファイル（情報区分）に基づいた優先度は、注文情報が「３０分」、見積情報が「６０分」、と判定できる。

また、当該ステップにおける優先制御部１０４０は、上述のように判定した優先度の高い順に、集信ファイルと情報区分の組合せをリスト化した、処理順序テーブル１０８５を生成して記憶装置１０１に格納し、フロー制御部１０３０に通知する。

こうして優先制御部１０４０が生成した処理順序テーブル１０８５の一例を図９に示す。図９では、送信者が幹事企業のみである場合の処理順序テーブル１０８５の構造と、その遷移例を示している。この処理順序テーブル１０８５は、処理の優先度の高い順を示す「順序」、集信ファイルに対するフォーマット変換の処理状態を表す「状態」、集信ファイルを一意に示す「集信ファイルＩＤ」、集信ファイルに含まれうる個別ファイルの属性として送信元たる「幹事会員ＩＤ」と「情報区分」、各値を組み合わせた構成となっている。

図９における処理順序テーブル１０８５の例では、まず順序「１」番目に、上述で特定している個別ファイルのうち、最も優先度の高い、すなわち処理の所要時間が最も短い「１５分」が指定されている「幹事会員企業Ａの注文情報」を含みうる集信ファイル２０１０（集信ファイルＩＤ：Ｆ００１）が設定される。

また、順序「２」番目には、次に優先度の高い、すなわち処理の所要時間が二番目に短い「３０分」が指定されている「幹事会員企業Ｂの注文情報」を含みうる集信ファイル２０２０（集信ファイルＩＤ：Ｆ００２）が設定される。

また、順序「３」番目には、三番目に優先度の高い、すなわち処理の所要時間が三番目に短い「６０分」が指定されている「幹事会員企業Ａの見積情報」を含みうる集信ファイル２０１０（集信ファイルＩＤ：Ｆ００１）が設定される。なお、この「幹事会員企業Ａの見積情報」と同じ優先度たる「６０分」が指定されている「幹事会員企業Ｂの見積情報」を含みうる集信ファイル２０２０（集信ファイルＩＤ：Ｆ００２）については、順序「４」番目としているが、この順序は、例えばファイル蓄積部１０２０に蓄積された順序を用いて決定したものとする。

最後の順序「５」番目には、優先度の最も低い、すなわち処理の所要時間が最も長い、「無条件」が指定されている「幹事会員企業Ａの環境情報」を含みうる集信ファイル２０１０（集信ファイルＩＤ：Ｆ００１）が設定される。こうした処理順序テーブル生成時点では、各レコードにおける「状態」欄は全て「未」の値が設定される。

次に、フロー制御部１０３０は、上述の優先制御部１０４０から、処理順序テーブル１０８５の生成完了通知を受けて、フォーマット変換部１０５０を呼び出し、ファイル蓄積部１０２０に蓄積されている集信ファイル群に対してフォーマット変換処理を実施させる（Ｓ７００６）。

この場合のフォーマット変換部１０５０は、上述のステップＳ７００５で作成されている処理順序テーブル１０８５を参照し、優先的にフォーマット変換を行う集信ファイルを判定する。具体的には、処理順序テーブル１０８５の「状態」を参照し、「未」となっている集信ファイルのうち「順序」の値が最小のもの、すなわち最上位のものを、優先的にフォーマット変換を行う集信ファイルとして判定してフォーマット変換を行う。

フォーマット変換部１０５０は、こうしたフォーマット変換を施した後の集信ファイルをファイル蓄積部１０２０に蓄積する。そして、処理順序テーブル１０８５のレコードのうち、当該フォーマット変換対象となった集信ファイルに対応するレコードにおいて、「状態」欄の値を「変換済」に更新し、フロー制御部１０３０に通知する。ここでは、順序
「１」に対応する集信ファイル２０１０（集信ファイルＩＤ：Ｆ００１）がフォーマット変換の対象となり、処理順序テーブル１０８５の順序１番目、３番目、５番目に対応するレコードの「状態」欄の値が「変換済」に更新されることとなる。

続いてフロー制御部１０３０は、上述のフォーマット変換部１０５０から、処理順序テーブル１０８５の更新完了通知を受けて、ファイル分割部１０６０を呼び出し、ファイル蓄積部１０２０に蓄積されている集信ファイル群（フォーマット変換済）に対してファイル分割処理を実施させる（Ｓ７００７）。

この場合のファイル分割部１０６０は、処理順序テーブル１０８５を参照し、優先的にファイル分割を行う集信ファイルを判定する。具体的には、処理順序テーブル１０８５における各レコードの「状態」欄の値を参照し、その値が「変換済」となっている集信ファイルのうち、「順序」がより上位のものを優先的にファイル分割を行う集信ファイルとして判定してファイル分割を行う。またファイル分割部１０６０は、ファイル分割によって得た個別ファイル群をファイル蓄積部１０２０に蓄積する。

上述までの例であれば、ファイル分割部１０６０は、優先的にファイル分割を行う対象として集信ファイル２０１０（集信ファイルＩＤ：Ｆ００１）に対するファイル分割を実行し、「参加会員企業Ｘ」宛の注文情報２０１１、「参加会員企業Ｘ」宛の見積情報２０１２、「参加会員企業Ｘ」宛の環境情報２０１３、「参加会員企業Ｙ」宛の注文情報２０１４という、４個の個別ファイルを、集信ファイル２０１０から分割することになる。

このうち注文情報２０１１と注文情報２０１４は、処理順序テーブル１０８５における順序「１」番目に対応する個別ファイル、見積情報２０１２は、順序「３」番目に対応する個別ファイル、環境情報２０１４は、順序「５」番目に対応する個別ファイルである。
そこでファイル分割部１０６０は、ファイル分割処理後に、処理順序テーブル１０８５の各レコードのうち、実際に生成した個別ファイルに対応するレコード、すなわち順序１番目、３番目、５番目に対応するレコードの「状態」欄を「変換済」から「分割済」に更新し、フロー制御部１０３０に通知する。この時の処理順序テーブル１０８５の「状態」を図９の１０８５−１１に示す。なお、例えば、集信ファイル２０１０に「環境情報」が含まれていない場合には、５番目のレコードにおける「状態」欄の値を、「変換済」から「無」に更新する。

次にフロー制御部１０３０は、上述のファイル分割部１０６０から、処理順序テーブル１０８５の更新完了通知を受けて、振分部１０７０を呼び出し、ファイル蓄積部１０２０に蓄積されている個別ファイル群に対して配信、振分の処理を実施させる（Ｓ７００８）。

この場合の振分部１０７０は、処理順序テーブル１０８５を参照し、優先的に配信する個別ファイルを判定する。具体的には、処理順序テーブル１０８５の各レコードにおける「状態」欄の値を参照し、その値が「分割済」となっている集信ファイルのうち、「順序」がより上位の個別ファイルを、優先的に配信する個別ファイルとして判定し、当該個別ファイルを指定する情報と配信順序と宛先について、フロー制御部１０３０に通知する。

一方、フロー制御部１０３０は、その通知を受けて、通信部１０１０を呼び出し、配信対象となった個別ファイルを指定順序で指定宛先に送信するように命令する。ここでは、順序「１」に対応する個別ファイルが配信対象となり、この個別ファイルの属性「幹事会員企業Ａ」の「注文情報」を持つ、注文情報２０１１、および、属性「幹事会員企業Ａ」の「注文情報」を持つ、注文情報２０１４が優先的に配信されることになる。

次に、振分部１０７０は、処理順序テーブル１０８５の各レコードのうち、「状態」欄の値が「分割済」のレコードであって、上述の配信を行った個別ファイルに対応するレコードについて、その「状態」欄を「分割済」から「配信済」に更新する。また、振分部１０７０は、今回配信対象とならなかった個別ファイルの属性に対応するレコード、すなわち順序３番目、５番目に対応するレコードの「状態」欄の値を、「分割済」から「保留」に更新する。この時の処理順序テーブル１０８５の「状態」を図９の１０８５−１２に示す。

続いて振分部１０７０は、処理順序テーブル１０８５を更新した旨を、フロー制御部１０３０に通知する（Ｓ７００９）。この時、振分部１０７０は、処理順序テーブル１０８５の「状態」欄の値が「未」の集信ファイルが残っていれば、上述のステップＳ７００６の処理へ戻ることをフロー制御部１０３０に通知する。また、処理順序テーブル１０８５の「状態」欄の値が「未」の集信ファイルが残っていなければ、優先制御を終了することを、フロー制御部１０３０に通知する。

ここでは、処理順序テーブル１０８５における順序２番目、４番目に対応する集信ファイル２０２０（集信ファイルＩＤ：Ｆ００２）の「状態」は「未」として残っている。そのため、引き続きステップＳ７００６を実施する。この場合のステップＳ７００６では、フォーマット変換部１０５０が、集信ファイル２０２０（集信ファイルＩＤ：Ｆ００２）のフォーマット変換を実行し、続くステップＳ７００７にて、ファイル分割部１０６０がファイル分割を実行し、「参加会員企業Ｘ」宛の注文情報２０２１、「参加会員企業Ｘ」宛の見積情報２０２２、「参加会員企業Ｙ」宛の見積情報２０２３という、３個の個別ファイルを集信ファイル２０２０から分割することになる。

上述の注文情報２０２１は、処理順序テーブル１０８５の順序２番目に対応する個別ファイル、見積情報２０２２と見積情報２０２３は、順序４番目に対応する個別ファイルとなる。この時の処理順序テーブル１０８５を図９の１０８５−１３に示す。

また、続くステップＳ７００８では、残り全ての個別ファイルが配信対象として判定され、順序２〜５に従って配信されることになる。具体的には、注文情報２０２１、見積情報２０１２、見積情報２０２２、見積情報２０２３、環境情報２０１４の順で配信がなされる。以上で、全ての集信ファイルに含まれる個別ファイルの配信が完了する。

なお、処理順序テーブル１０８５の更新を、フォーマット変換部１０５０、ファイル分割部１０６０、振分部１０７０が行うように説明したが、更新に必要な情報を受けて、フロー制御部１０３０が全て更新するようにしてもよい。
［ケース２］

ここでは、上述のケース１と異なる部分について主に説明する。このケース２における、ステップＳ７００２で、優先制御部１０４０は、集信ファイル２０３０の送信者は「参加会員企業Ｘ」、集信ファイル２０４０の送信者は「参加会員企業Ｙ」、と判定することになる。

次に、ステップＳ７００３で、優先制御部１０４０は、集信ファイル２０３０に含まれうる個別ファイルの情報区分は、注文情報、見積情報、環境情報、集信ファイル２０４０に含まれうる個別ファイルの情報区分は、注文情報、見積情報、と判定する。ここで、送信者が「参加会員」である集信ファイルに対しては、ステップがＳ７００４に遷移する。
この場合、優先制御部１０４０は、取引関係マスタ１０８４を参照し、参加会員が送信する集信ファイルに含まれうる個別ファイルの情報区分ごとに、取引相手となる幹事会員を判定する（Ｓ７００４）。「参加会員企業Ｘ」が送信する集信ファイルに対しては、注
文情報と見積情報は「幹事会員企業Ａ」と「幹事会員企業Ｂ」が取引相手であり、環境情報は「幹事会員企業Ａ」が取引相手と判定される。「参加会員企業Ｙ」が送信する集信ファイルに対しては、注文情報と見積情報は「幹事企業会員Ａ」と「幹事会員企業Ｂ」が取引相手と判定される。以上より、送信者が参加会員である集信ファイルに対しても、取引相手の幹事会員企業のＳＬＡを紐付けることができるようになる。

続いてＳ７００５で、優先制御部１０４０は、処理順序テーブル１０８６を生成し、これを記憶装置１０１に格納する。図１０は、本実施形態における処理順序テーブルの遷移例２を示す図である。この処理順序テーブル１０８６は、送信者が参加企業のみである場合の処理順序テーブルとなる。

上述のステップＳ７００４において判定した取引相手と、含まれうる個別ファイルの情報区分より、集信ファイル２０３０（集信ファイルＩＤ：Ｆ１０１）には、「幹事会員企業Ａ」への注文情報（１５分）、見積情報（６０分）、環境情報（無条件）、「幹事会員企業Ｂ」への注文情報（３０分）、見積情報（６０分）が含まれる可能性がある。また、集信ファイル２０４０（集信ファイルＩＤ：Ｆ１０２）には、「幹事会員企業Ａ」への注文情報（１５分）、見積情報（６０分）、「幹事会員企業Ｂ」への注文情報（３０分）、見積情報（６０分）が含まれる可能性がある。そのため、合計９種類の個別ファイルの情報区分に対する順序付けがなされたリストとなる。

以降の処理は上述のケース１と同様であり、処理順序テーブル１０８６の「状態」は、Ｓ７００７完了時には図１０の１０８６−１１、Ｓ７００８完了時には図１０の１０８６−１２、２回目のＳ７００７完了時には図１０の１０８６−１３となる。
−−−他の実施形態−−−

次に、他の実施形態として、集信ファイルが、フォーマット変換前にファイル分割を行うことができる場合の優先制御について図に基づき説明する。図１１は、他の実施形態における電子データ交換方法のフロー例を示す図である。なお、当該他の実施形態における電子データ交換サーバ１００の構成は、上述の本実施形態と同様であり、優先制御の処理フローのみが異なる。よって、図１１〜１３を用いて、上述の本実施形態と異なる部分について説明する。なお、図１２は他の実施形態における、送信者が幹事企業のみである場合の処理順序テーブルの構造と更新フローを示す図である。また、図１３は他の実施形態における、送信者が参加企業のみである場合の処理順序テーブルの構造と更新フローを示す図である。

ここで、図１１のステップＳ７００１〜Ｓ７００５の各処理は、上述した本実施形態と同様であるため説明を省略する。ステップＳ７００５を完了すると、上述の本実施形態と同様の処理順序テーブル１０８５（１０８６）が生成されることになる。以降、処理順序テーブル１０８５に対応する処理について説明する。

この場合のフォーマット変換部１０５０は、既に述べたステップＳ７００６と同様に、集信ファイル群から優先的に処理を行う集信ファイルを判定する。上述の本実施形態のケース１と同様の集信ファイル群の場合、集信ファイル２０１０（集信ファイルＩＤ：Ｆ００１）が処理の対象となる。ここでフォーマット変換部１０５０は、この集信ファイル２０１０のフォーマットの判定を行う（Ｓ１０００１）。

図３での説明で既述のように、フォーマット変換前にファイル分割を行うことができる形式の集信ファイルである場合（Ｓ１０００１：分割可）、フォーマット変換部１０５０は、処理順序テーブル１０８５における対応レコードの「状態」を「未」から「分割可」に更新し、フロー制御部１０３０に通知する。

他方、フォーマット変換前にファイル分割を行えないと判定した場合（Ｓ１０００１：分割不可）、フォーマット変換部１０５０は、上述の本実施形態と同様に図８のＳ７００６以降を実施する。以降、説明を単純化するために、集信ファイルは全て、フォーマット変換前に分割可能とするが、分割不可能なファイルが混在している場合でも、上述の本実施形態のＳ７００９の後にＳ１０００１へ戻ることで優先制御を行うことが可能である。

続いてフロー制御部１０３０は、フォーマット変換部１０５０から、フォーマット変換前に分割可能であることの通知を受け、ファイル分割部１０６０を呼び出し、処理順序テーブル１０８５で「状態」欄の値が「分割可」となっている集信ファイルに対してファイル分割を実行する（Ｓ１０００２）。

この場合のファイル分割部１０６０は、ファイル分割の処理後に、処理順序テーブル１０８５における該当レコードの「状態」欄を「分割可」から「分割済・未変換」に更新し、フロー制御部１０３０に通知する。

続いてフロー制御部１０３０は、上述のファイル分割部１０６０から通知を受けて、フォーマット変換部１０５０を呼び出し、処理順序テーブル１０８５のレコードにおいて、「状態」欄の値が「分割済み・未変換」となっている集信ファイルのうち、「順序」が最上位のものの個別ファイル群（ステップＳ１０００２のファイル分割で得ているもの）を、フォーマット変換する（Ｓ１０００３）。

このフォーマット変換後、フロー制御部１０３０は、処理順序テーブル１０８５で、フォーマット変換の対象となった個別ファイルに対応するレコードの「状態」欄を「分割済・変換済」に更新し、フロー制御部１０３０に通知する。この時の処理順序テーブル１０８５の「状態」欄を図１２の１０８５−２１に示す。また、処理順序テーブル１０８６に対応する処理であれば、図１３の１０８６−２１が対応している。

次に、フロー制御部１０３０は、フォーマット変換部１０５０から通知を受けて、振分部１０７０を呼び出し、「分割済・変換済」となった個別ファイルを配信対象と判定し、配信方法をフロー制御部１０３０に通知する。

この場合のフロー制御部１０３０は、その通知を受けて、通信部１０１０を呼び出し、配信対象となった個別ファイルの配信を実行する。

次に、振分部１０７０は、処理順序テーブル１０８５のレコードのうち、配信済の個別ファイルに対応するレコードの「状態」欄を「分割済・変換済」から「配信済」に更新し、未配信のレコードの「状態」欄を「分割済・未変換」から「保留・未変換」に更新する。この時の処理順序テーブル１０８５の「状態」を図１２の１０８５−２２に示す。また、処理順序テーブル１０８６に対応する処理であれば、図１３の１０８６−２２が対応している。

続いて振分部１０７０は、上述の図８のフローにおけるステップＳ７００９と同様に、未処理の集信ファイルがあれば、Ｓ１０００１の処理へ戻り、未処理の集信ファイルがなければ、優先制御を終了することを、フロー制御部１０３０に通知する（Ｓ１０００４）。

以降、Ｓ１０００１〜Ｓ１０００３をもう１回行うことで、全ての集信ファイルに含まれる個別ファイルの配信が完了する。２回目のステップＳ１０００３における配信前の処理順序テーブル１０８５の「状態」を図１２の１０８５−２３に示す。また、処理順序テ
ーブル１０８６に対応する処理であれば、図１３の１０８６−２３が対応している。

以上の他の実施形態によれば、集信ファイルのフォーマットの自由度は減少するものの、優先度の低い個別ファイルのフォーマット変換を待たずに、優先度の高い個別ファイルをより迅速に配信できるようになる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、マルチテナント環境のＥＤＩシステムにおいて、集信ファイル間をまたがって、各集信ファイルに含まれる各個別ファイルの処理優先度を適宜に決定し、効率的に配信することが出来る。これにより、マルチテナント環境のＥＤＩシステムにおける処理効率が改善され、ＳＬＡの遵守、および運用コストやサービス価格の抑制が可能となる。また、ＳＬＡに応じて、ＥＤＩシステムにおけるリソースを過度に増強する事態も回避出来る。つまり、一般的なリソース構成のＥＤＩシステムにおいて、データ処理効率を高め、全体として商取引データの処理、配信の速度も改善されることになる。ひいては、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ効率的な商取引データの処理が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の電子データ交換システムにおいて、前記演算装置は、前記ファイルからの電子データ抽出に際し、当該ファイルの所定フォーマットへの変換、および、当該変換後のファイルからの各電子データの分割、を実行して電子データを抽出するものである、としてもよい。

これによれば、上述のファイル、すなわち集信ファイルの形式が、ユーザ企業の業務システム等での形式となっている状況に対応し、ＥＤＩシステムで規定する所定ファイル形式への変換処理と、その変換処理で得たファイルからの各電子データ、すなわち個別ファイルの分割処理についても、データ処理の優先度に応じた順序で実行することが出来る。従って、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ、更に効率的な商取引データの処理が可能となる。

また、本実施形態の電子データ交換システムにおいて、前記演算装置は、前記ファイルの形式が、前記所定フォーマットへの変換無しで前記分割を行えるものである場合、当該ファイルからの各電子データの分割を実行した後、前記処理順序に従って、前記分割で得た電子データの所定フォーマットへの変換を実行し、当該変換後の電子データを前記送信先に配信するものである、としてもよい。

これによれば、上述のフォーマット変換の実行順序に関しても、データ処理の優先度に応じた順序で実行することが出来る。従って、マルチテナント環境のＥＤＩシステムにおいて、ＳＬＡの遵守を図りつつ、より一層効率的な商取引データの処理が可能となる。

また、本実施形態の電子データ交換システムにおいて、前記演算装置は、前記処理順序を仮定するに際し、所定期間内に受信した複数のファイルについて、各ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した、各ファイルをまたがる前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該各ファイルに含まれうる電子データ間での処理順序を仮定するものである、としてもよい。

これによれば、複数の集信ファイルを跨がって、上述の優先度に基づいた、各個別ファイルに対するデータ処理の順番を決定し、実行することが出来る。ひいては、複数ユーザ
企業がリソースを共有するマルチテナント環境のＥＤＩシステムにおいて、複数の集信ファイルが同時期に集中した場合でも、ＳＬＡの遵守を図りつつ、より一層効率的な商取引データの処理が可能となる。

また、本実施形態の電子データ交換方法において、前記情報処理システムが、前記ファイルからの電子データ抽出に際し、当該ファイルの所定フォーマットへの変換、および、当該変換後のファイルからの各電子データの分割、を実行して電子データを抽出する、としてもよい。

また、本実施形態の電子データ交換方法において、前記情報処理システムが、前記ファイルの形式が、前記所定フォーマットへの変換無しで前記分割を行えるものである場合、当該ファイルからの各電子データの分割を実行した後、前記処理順序に従って、前記分割で得た電子データの所定フォーマットへの変換を実行し、当該変換後の電子データを前記送信先に配信する、としてもよい。

また、本実施形態の電子データ交換方法において、前記情報処理システムが、前記処理順序を仮定するに際し、所定期間内に受信した複数のファイルについて、各ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した、各ファイルをまたがる前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該各ファイルに含まれうる電子データ間での処理順序を仮定する、としてもよい。

１０ 通信網
１００ 電子データ交換サーバ（電子データ交換システム）
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ 演算装置
１０５ 通信装置
１００１〜１００４ 業務システム
１００５ 受発注システム
１００６ 記憶装置
１００７ 通信装置
１０１０ 通信部
１０２０ ファイル蓄積部
１０３０ フロー制御部
１０４０ 優先制御部
１０５０ フォーマット変換部
１０６０ ファイル分割部
１０７０ 振分部
１０８１ 会員マスタ
１０８２ 優先度マスタ
１０８３ 情報区分マスタ
１０８４ 取引関係マスタ
１０８５、１０８６ 処理順序テーブル
２０１０〜２０４０ 集信ファイル
２０１１〜２０１４ 個別ファイル
２０２１〜２０２３ 個別ファイル
２０３１〜２０３３ 個別ファイル
２０４１〜２０４２ 個別ファイル

Claims (8)

1. 商取引の当事者、当該当事者が送信する可能性のある電子データ種別、および当該当事者と電子データ種別に応じたデータ処理の優先度、を定めたテーブルを格納する記憶装置と、
   前記電子データを含むファイルを所定端末より受信し、当該ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該ファイルに含まれうる電子データ間での処理順序を仮定し、当該処理順序に従って、当該ファイルに含まれる電子データの抽出および送信先への配信を実行する演算装置と、
   を備えることを特徴とする電子データ交換システム。
2. 前記演算装置は、
   前記ファイルからの電子データ抽出に際し、当該ファイルの所定フォーマットへの変換、および、当該変換後のファイルからの各電子データの分割、を実行して電子データを抽出するものである、
   ことを特徴とする請求項１に記載の電子データ交換システム。
3. 前記演算装置は、
   前記ファイルの形式が、前記所定フォーマットへの変換無しで前記分割を行えるものである場合、当該ファイルからの各電子データの分割を実行した後、前記処理順序に従って、前記分割で得た電子データの所定フォーマットへの変換を実行し、当該変換後の電子データを前記送信先に配信するものである、
   ことを特徴とする請求項２に記載の電子データ交換システム。
4. 前記演算装置は、
   前記処理順序を仮定するに際し、
   所定期間内に受信した複数のファイルについて、各ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した、各ファイルをまたがる前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該各ファイルに含まれうる電子データ間での処理順序を仮定するものである、
   ことを特徴とする請求項１に記載の電子データ交換システム。
5. 商取引の当事者、当該当事者が送信する可能性のある電子データ種別、および当該当事者と電子データ種別に応じたデータ処理の優先度、を定めたテーブルを格納する記憶装置を備えた情報処理システムが、
   前記電子データを含むファイルを所定端末より受信し、当該ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該ファイルに含まれうる電子データ間での処理順序を仮定し、当該処理順序に従って、当該ファイルに含まれる電子データの抽出および送信先への配信を実行する、
   ことを特徴とする電子データ交換方法。
6. 前記情報処理システムが、
   前記ファイルからの電子データ抽出に際し、当該ファイルの所定フォーマットへの変換、および、当該変換後のファイルからの各電子データの分割、を実行して電子データを抽出する、
   ことを特徴とする請求項５に記載の電子データ交換方法。
7. 前記情報処理システムが、
   前記ファイルの形式が、前記所定フォーマットへの変換無しで前記分割を行えるものである場合、当該ファイルからの各電子データの分割を実行した後、前記処理順序に従って、前記分割で得た電子データの所定フォーマットへの変換を実行し、当該変換後の電子データを前記送信先に配信する、
   ことを特徴とする請求項６に記載の電子データ交換方法。
8. 前記情報処理システムが、
   前記処理順序を仮定するに際し、
   所定期間内に受信した複数のファイルについて、各ファイルの送信者たる当事者が送信する可能性のある電子データ種別と当該当事者に対応した、各ファイルをまたがる前記優先度を前記テーブルに基づき判定し、当該判定した優先度に基づいて、当該各ファイルに含まれうる電子データ間での処理順序を仮定する、
   ことを特徴とする請求項５に記載の電子データ交換方法。

Images