(57)【要約】【課題】ＥＤＩ伝送における伝送データを効率的かつ低コストで受信側が処理可能なものとし、伝送データの訂正や再送による業務処理のタイムラグを低減可能とする。【解決手段】買い手側端末より商品の注文情報を受信し注文情報が含む情報に基づいて売り手側システムのアドレスを検索する手段と、注文情報を含むチェック用データを売り手側システムのアドレスに宛ててチェック依頼とともに送信し売り手側システムの保持するデータチェックプログラムによるチェック用データに関するデータチェック結果を売り手側システムから受信する手段と、データベースチェック結果が問題ないものであれば該当注文情報を含む注文伝送データを該当売り手側システムに送信する手段とからＥＤＩデータ管理システム１００を構成する。【選択図】図１
2011128891.tif 000002
【特許請求の範囲】
【請求項１】
商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムであって、
買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段と、
買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する手段と、
前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する手段と、
前記データベースチェック結果が問題ないものであれば該当注文情報を含む注文伝送データを該当売り手側システムに送信する手段と、
を備えることを特徴とするＥＤＩデータ管理システム。
【請求項２】
売り手側システムから受信したデータチェック結果が、注文情報が含む各項目値の桁数、文字種、項目間での必須の関係性有無などの入力内容に関するチェック結果を示す場合、該当データチェック結果を前記買い手側端末に送信する手段と、
売り手側システムから受信したデータチェック結果が、前記注文情報から生成する前記チェック用データのレイアウトに関するチェック結果を示す場合、該当データチェック結果を出力手段に出力する手段と、
を更に備えることを特徴とする請求項１に記載のＥＤＩデータ管理システム。
【請求項３】
売り手側システムからデータチェック結果を受信する毎に、該当買い手に関する該当売り手のデータチェックプログラムの利用回数としてカウントし、この利用回数の値を記憶手段に格納する手段と、
前記記憶手段における利用回数の値に所定値を演算してサービス利用料金を算定し、このサービス利用料金を所定フォーマットに適用して請求書を生成し買い手側端末に送信する手段と、
前記利用回数のカウントおよび格納の処理と、前記サービス利用料金の算定、請求書生成および送信の処理とを、記憶手段に予め格納しているスケジュールに基づいて所定期間毎に実行する手段と、
を更に備えることを特徴とする請求項１または２に記載のＥＤＩデータ管理システム。
【請求項４】
買い手側端末が当該ＥＤＩデータ管理システムへログインしていた時間と回数を、ログインおよびログオフの処理時にカウントして記憶手段に格納し、買い手別にシステムの利用時間、利用回数の集計を行う手段と、
買い手側端末から当該ＥＤＩデータ管理システムを介して売り手側システムに伝送された各種データの伝送サイズと伝送回数を記憶手段に格納し、該当買い手に関する該当売り手へのデータ伝送量と回数の集計を行う手段とを更に備え、
前記サービス利用料金の算定、請求書生成および送信を行う手段が、記憶手段における前記利用回数の値、前記買い手別のシステムの利用時間、利用回数の集計値、前記買い手に関する該当売り手へのデータ伝送量と回数の集計値、の少なくともいずれに所定値を演算してサービス利用料金を算定し、このサービス利用料金を所定フォーマットに適用して請求書を生成し買い手側端末に送信する、
ことを特徴とする請求項３に記載のＥＤＩデータ管理システム。
【請求項５】
買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段を備えて、商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムが、
買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する処理と、
前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する処理と、
前記データベースチェック結果が問題ないものであれば該当注文情報を含む注文伝送データを該当売り手側システムに送信する処理と
を実行することを特徴とするＥＤＩデータ管理方法。
【請求項６】
買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段を備えて、商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムに、
買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する処理と、
前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する処理と、
前記データベースチェック結果が問題ないものであれば該当注文情報を含む注文伝送データを該当売り手側システムに送信する処理と、
実行させることを特徴とするＥＤＩデータ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＥＤＩデータ管理システム、ＥＤＩデータ管理方法、およびＥＤＩデータ管理プログラムに関するものであり、具体的には、ＥＤＩ伝送における伝送データを効率的かつ低コストで受信側が処理可能なものとし、伝送データの訂正や再送による業務処理のタイムラグを低減可能とする技術に関する。
【背景技術】
【０００２】
企業間での商取引データを標準的書式に統一し、電子的に交換するＥＤＩ（Electronic Data Interchange）システムが広がりをみせている。このＥＤＩシステムでは、受発注や見積もり、決済、出入荷などに関わるデータを、あらかじめ定められた形式にしたがって電子化し、専用線やVANなどのネットワークを通じて端末間で送受信する。
【０００３】
こうした企業間ＥＤＩ取引の実施にあたっては、予めＥＤＩデータの伝送仕様(レイアウト及び、値)について取り決めを行い、受発注者双方に対応できるシステムを開発・構築してきた。また、ＥＤＩシステムの運用にあたっては、取引相手先に仕様外のデータが取り込まれないよう、データの送り手、受け手でそれぞれ伝送データの内容確認をすることが要求され、これらを実施するデータチェックプログラムは、双方のシステムで作成・メンテナンスされている。
【０００４】
ＥＤＩシステムやこれに関連する従来技術としては、例えば、電子鍵を用いて暗号化された情報を、通信ネットワークを介して接続された他の情報交換装置と交換する情報交換装置において、公開鍵及び秘密鍵を電子鍵として発行する認証装置を有する情報交換装置（特許文献１参照）などが提案されている。
【０００５】
また、データフォーマットやアクセス方法等が異なる複数のデバイスやパッケージソフト等を円滑に統合化する統合化システム（特許文献２参照）なども提案されている。
【０００６】
また、電子データ交換システムに於ける受信側システムに於いて、送信側システムから送信されたタグ付標準フォーマットデータを受信する標準フォーマットデータ受信手段と、該受信されたデータを解析し、タグ無し標準データ形式のデータ定義体を生成する標準フォーマットデータ解析手段と、前記標準フォーマットデータ解析手段で生成した標準データ形式のデータ定義体を編集・表示させ、受信側独自のローカルデータ形式のデータ定義体に修正する標準データ形式修正手段と、を備えた電子データ交換システム（特許文献３参照）なども提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−１２８８５６号公報
【特許文献２】特開２００４−０８６３５５号公報
【特許文献３】特開平１０−１０５６３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、ＥＤＩシステムにおける上記データチェックプログラムでは、例えば、データ値のチェック項目として、属性、桁数、少数点位置確認、文字バイトなどの項目に関してチェックを行っている。またこうした項目それぞれについてのチェック以外にも、複数項目間における値の関連性、整合性に関するチェック、業務データとの整合性に関するチェックなども必要とされている。
【０００９】
しかし、例えば製造業者（メーカ）においては、取り扱っている製品の詳細仕様を機密情報扱いとして買い手側に公開しないため、ＥＤＩ取引に際して買い手側が注文情報を作成するとしても、上記で述べた項目間の関連性チェックや業務データの整合性チェックにまで網羅的に配慮した注文情報生成を行うことはできない。従って、こうした注文情報を受信したメーカ側システムで各種チェックを行うと、仕様外などと判定される注文情報が次々と生じ、買い手側に注文情報の修正を度々強いることになりやすい。
【００１０】
また、企業間ＥＤＩ取引のためのデータ交換にあたっては、ＦＴＰや全銀ＴＣＰ／ＩＰを利用したファイル転送方式が古くから利用してされている。このようなデータ交換方法においては、買い手側からＥＤＩ伝送されたデータ＝注文情報は、メーカ側でバッチ処理対象としてシステム取り込まれる。例えば、メーカ側で受け取った注文情報が個別注文品であった場合は、メーカの製造拠点である工場に対して納期回答を求めることになり、注文請け情報を買い手側に回答するまでには、数時間から数日の時間を要することになる。
【００１１】
もしも、買い手側が送付した注文情報に不具合があると、買い手側は注文情報のデータ訂正と再送を実行しなければならず、注文から納品までのタイムラグの発生要因となってしまう。そのため、買い手側はデータ訂正や再送が極力発生しないよう、メーカ公開の仕様部分について、伝送前に注文情報のデータチェックができるプログラムの開発を実施する。また、メーカ未公開仕様の部分についても、問題発生の都度メーカ側にその対処方法を確認し、可能な限りデータ取込不正が極力発生しないように、独自のチェックプログラムを追加したり、人手による運用で回避措置をして対応する。しかしながら、複数メーカを相手にＥＤＩ取引を実施している買い手の場合、その取引先の数だけ、独自のデータチェックプログラムを作成しなければならなく、プログラム対応に関わる費用が大きな負担となる。
【００１２】
そこで本発明は上記事情に鑑みてなされたものであり、ＥＤＩ伝送における伝送データを効率的かつ低コストで受信側が処理可能なものとし、伝送データの訂正や再送による業務処理のタイムラグを低減可能とする技術の提供を主たる目的とする。
【課題を解決するための手段】
【００１３】
ＥＤＩ取引において、買い手側が過去の経験・伝送実績に基づいて実施していた独自データチェックを、ＥＤＩデータ管理システムが主導して売り手側の保持しているプログラムで実施させ、このチェック結果を買い手側にサービスとして提供する。これにより、買い手側、売り手側でそれぞれ開発やメンテナンスを行っていたデータチェックプログラムは、売り手側に集約されることとなり、プログラムの開発やメンテナンスに関わる費用を全体として低減できる。また、データチェック精度の向上と、データ不具合時のタイムラグ発生のリスク軽減を実現する。
【００１４】
なお、売り手側システムでのデータチェックにあたっては、買い手側端末から入力された値や、複数の値間の相互関連性のチェック（項目間であり得ない組み合わせとなる値などをチェック）を目的としたチェックと、注文情報を売り手側にデータとして伝送する際のレイアウトチェックを目的としたチェックの２段階で実施される。これにより、買い手側での注文入力時における入力ミスや各種不具合等の人的原因によるエラーは、リアルタイムに入力誤りとして買い手側端末に通知され、迅速な訂正対応が可能となる。一方、伝送データのレイアウトチェックについては、ＥＤＩデータ管理システムの出力手段等に表示させるなどしてシステム管理者に通知し、注文情報から伝送データを生成するプログラムの修正等を促すことができる。
【００１５】
具体的に、上記課題を解決する本発明のＥＤＩデータ管理方法は、商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムであって、買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段と、買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する手段と、前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する手段と、前記データベースチェック結果が問題ないものであれば該当注文情報を含む注文伝送データを該当売り手側システムに送信する手段と、を備えることを特徴とする。
【００１６】
また、前記ＥＤＩデータ管理システムにおいて、売り手側システムから受信したデータチェック結果が、注文情報が含む各項目値の桁数、文字種、項目間での必須の関係性有無などの入力内容に関するチェック結果を示す場合、該当データチェック結果を前記買い手側端末に送信する手段と、売り手側システムから受信したデータチェック結果が、前記注文情報から生成する前記チェック用データのレイアウトに関するチェック結果を示す場合、該当データチェック結果を出力手段に出力する手段と、を更に備えるとしてもよい。
【００１７】
また、前記ＥＤＩデータ管理システムにおいて、売り手側システムからデータチェック結果を受信する毎に、該当買い手に関する該当売り手のデータチェックプログラムの利用回数としてカウントし、この利用回数の値を記憶手段に格納する手段と、前記記憶手段における利用回数の値に所定値を演算してサービス利用料金を算定し、このサービス利用料金を所定フォーマットに適用して請求書を生成し買い手側端末に送信する手段と、前記利用回数のカウントおよび格納の処理と、前記サービス利用料金の算定、請求書生成および送信の処理とを、記憶手段に予め格納しているスケジュールに基づいて所定期間毎に実行する手段と、を更に備えるとしてもよい。
【００１８】
また、前記ＥＤＩデータ管理システムにおいて、買い手側端末が当該ＥＤＩデータ管理システムへログインしていた時間と回数を、ログインおよびログオフの処理時にカウントして記憶手段に格納し、買い手別にシステムの利用時間、利用回数の集計を行う手段と、買い手側端末から当該ＥＤＩデータ管理システムを介して売り手側システムに伝送された各種データの伝送サイズと伝送回数を記憶手段に格納し、該当買い手に関する該当売り手へのデータ伝送量と回数の集計を行う手段とを更に備え、前記サービス利用料金の算定、請求書生成および送信を行う手段が、記憶手段における前記利用回数の値、前記買い手別のシステムの利用時間、利用回数の集計値、前記買い手に関する該当売り手へのデータ伝送量と回数の集計値、の少なくともいずれに所定値を演算してサービス利用料金を算定し、このサービス利用料金を所定フォーマットに適用して請求書を生成し買い手側端末に送信する、としてもよい。
【００１９】
また、本発明のＥＤＩデータ管理方法は、買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段を備えて、商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムが、買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する処理と、前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する処理と、売り手側システムから受信したデータチェック結果が、注文情報が含む各項目値に関するチェック結果を示す場合、該当データチェック結果を前記買い手側端末に送信する処理と、売り手側システムから受信したデータチェック結果が、前記チェック用データのレイアウトに関するチェック結果を示す場合、該当データチェック結果を出力手段に出力する処理と、を実行することを特徴とする。
【００２０】
また、本発明のＥＤＩデータ管理プログラムは、買い手側端末が利用する売り手側システムのネットワーク上のアドレスを記憶した記憶手段を備えて、商品売買に関するＥＤＩシステムの伝送データを管理するコンピュータシステムに、買い手側端末より商品の注文情報をネットワークを介して受信し、注文情報が含む情報に基づいて前記記憶手段で売り手側システムのアドレスを検索する処理と、前記買い手側端末より受信している注文情報を含むチェック用データを、前記検索した売り手側システムのアドレスに宛ててチェック依頼とともに送信し、売り手側システムの保持するデータチェックプログラムによる前記チェック用データに関するデータチェック結果を、売り手側システムから受信する処理と、売り手側システムから受信したデータチェック結果が、注文情報が含む各項目値に関するチェック結果を示す場合、該当データチェック結果を前記買い手側端末に送信する処理と、売り手側システムから受信したデータチェック結果が、前記チェック用データのレイアウトに関するチェック結果を示す場合、該当データチェック結果を出力手段に出力する処理と、実行させることを特徴とする。
【００２１】
その他、本願が開示する課題、およびその解決方法は、発明を実施するための最良の形態の欄、および図面により明らかにされる。
【発明の効果】
【００２２】
本発明によれば、売り手側が作成・運用しているデータチェックプログラムを用いて、買い手側の注文情報とデータレイアウトをＥＤＩ伝送前に事前チェックすることで、データチェック精度の向上と、データ不具合時のタイムラグ発生のリスク軽減と、売り手側やシステムでのデータチェックプログラムの開発・メンテナンス費用の低減を実現できる。
【００２３】
また、システムは買い手に対してデータチェックサービスを提供するとともに、買い手がデータチェックプログラムを利用した回数を集計することで、買い手側にデータチェックプログラム等の利用課金を請求することも可能である。この請求で得られる収入の一部をデータチェックプログラム利用費として売り手側に還流させることで、売り手側におけるデータチェックプログラムの開発・運用メンテナンス費用を軽減させることにもつながる。
【００２４】
したがって、ＥＤＩ伝送における伝送データを効率的かつ低コストで受信側が処理可能なものとし、伝送データの訂正や再送による業務処理のタイムラグを低減できる。
【図面の簡単な説明】
【００２５】
【図１】本実施形態のＥＤＩデータ管理システムを含むネットワーク構成例を示す図である。
【図２】買い手側端末のハードウェア構成を示す図である。
【図３】共同センタ発注サーバのハードウェア構成を示す図である。
【図４】共同センタ伝送スケジュールサーバのハードウェア構成を示す図である。
【図５】共同センタ課金集計サーバのハードウェア構成を示す図である。
【図６】共同センタデータベースサーバのハードウェア構成を示す図である。
【図７】売り手受注サーバのハードウェア構成を示す図である。
【図８】売り手受注承認端末のハードウェア構成を示す図である。
【図９】注文情報テーブルの構成例を示す図である。
【図１０】注文請書情報テーブルの構成例を示す図である。
【図１１】注文進捗情報テーブルの構成例を示す図である。
【図１２】接続先管理テーブルの構成例を示す図である。
【図１３】発注サーバログイン履歴管理テーブルの構成例を示す図である。
【図１４】データチェック利用履歴管理テーブルの構成例を示す図である。
【図１５】注文伝送履歴管理テーブルの構成例を示す図である。
【図１６】注文件数集計テーブルの構成例を示す図である。
【図１７】発注サーバログイン集計テーブルの構成例を示す図である。
【図１８】データチェック利用集計テーブルの構成例を示す図である。
【図１９】注文伝送量集計テーブルの構成例を示す図である。
【図２０】課金請求テーブルの構成例を示す図である。
【図２１】注文項目マスタの構成例を示す図である。
【図２２】課金按分マスタの構成例を示す図である。
【図２３】ユーザマスタの構成例を示す図である。
【図２４】メーカマスタの構成例を示す図である。
【図２５】会社マスタの構成例を示す図である。
【図２６】受注管理データベースの構成例を示す図である。
【図２７】本実施形態におけるＥＤＩデータ管理方法の処理フロー例１を示す図である。
【図２８】本実施形態におけるＥＤＩデータ管理方法の処理フロー例２を示す図である。
【図２９】本実施形態におけるＥＤＩデータ管理方法の処理フロー例３を示す図である。
【図３０】本実施形態におけるＥＤＩデータ管理方法の処理フロー例４を示す図である。
【図３１】本実施形態のログイン画面の構成例を示す図である。
【図３２】本実施形態の注文入力画面の構成例を示す図である。
【図３３】本実施形態のデータチェック結果表示画面の構成例を示す図である。
【発明を実施するための形態】
【００２６】
−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のＥＤＩデータ管理システム１００を含むネットワーク構成例を示す図である。図１に示すＥＤＩデータ管理システム１００（以下、システム１００）は、ＥＤＩ伝送における伝送データを効率的かつ低コストで受信側が処理可能なものとし、伝送データの訂正や再送による業務処理のタイムラグを低減可能とするコンピュータシステムである。
【００２７】
図１に例示したネットワーク構成は、企業間ＥＤＩ伝送システム１の全体構成とも言えるものであり、この企業間ＥＤＩ伝送システム１は、複数の買い手側端末１０と、ＥＤＩデータ管理システム１００（を構成する共同センタ発注サーバ１１と、共同センタスケジュールサーバ１２と、共同センタ課金集計サーバ１３と、共同センタデータベースサーバ１４）と、売り手側システム２００（を構成する売り手受注サーバ１５と、売り手受注承認端末１６）とがネットワークを介して接続され、構成されている。
【００２８】
前記買い手側端末１０は、買い手である例えば企業の担当者などのユーザが、売り手である例えばメーカに対する注文情報を入力及び、閲覧をするための端末である。一方、共同センタ発注サーバ１１は、買い手側端末１０から入力された注文情報に関する内容チェックと売り手側システム２００への伝送を行うためのアプリケーションサーバである。また、共同センタスケジュールサーバ１２は、バッチ処理のためのスケジュール管理をするサーバであり、共同センタ発注サーバ１１から売り手受注サーバ１５へのデータ伝送や、データチェックサービス利用料金の集計処理等の指示を行うサーバである。また、共同センタ課金集計サーバ１３は、データチェックサービス利用料金の集計処理を行うためのプログラムを実装しているアプリケーションサーバである。また、共同センタデータベースサーバ１４は、注文情報や各種履歴データなどを格納する各種テーブルやデータベース類を記憶するデータベースサーバである。
【００２９】
一方、売り手受注サーバ１５は、買い手からの注文情報を受注処理するサーバであり、注文情報や注文請書の送受信と、受注情報の内容のデータチェックをするためのアプリケーションサーバである。また、売り手受注承認端末１６は、売り手側の担当者等が注文情報の閲覧や注文承認を実施するための端末である。なお、買い手側端末１０、売り手受注サーバ１５、売り手受注承認端末１６は、複数存在することを前提とする。
【００３０】
続いて、前記ネットワーク１４０に接続されている各装置の構成例について説明する。なお、特に説明しない場合でも、いずれの装置もネットワーク接続可能なコンピュータ装置として備える一般的な構成（ＣＰＵ、記憶装置、ＮＩＣなどの通信装置、入出力用の各種インターフェイス類）を備え、必要な機能部を例えばプログラムで実現しているものとする。
【００３１】
図２は買い手側端末１０のハードウェア構成を示す図である。買い手側端末１０は、ハードディスクドライブや各種メモリ等で構成される記憶部２０１、ディスプレイなどの表示部２０２、キーボードやマウスなどの入力部２０３、ＣＰＵ等の制御部２０４、通信手段たるネットワークインターフェース部２０５を具備し、各部はＢＵＳに接続されている。
【００３２】
前記記憶部２０１には、制御部２０４が実行するプログラムとして、画面表示機能２０６のプログラムが格納されている。制御部２０４により実行された画面表示プログラム２０６の結果は、表示部２０２に表示される。また、買い手側端末のユーザは、表示部２０２に表示された画面に対して、入力部２０３から情報入力・操作を実施し、その情報はネットワークインターフェース部２０５を介して共同センタ発注サーバ１１にデータ受け渡しする。
【００３３】
図３は、共同センタ発注サーバ１１のハードウェア構成を示す図である。共同センタ発注サーバ１１は、ハードディスクドライブや各種メモリ等で構成される記憶部３０１、ＣＰＵ等の制御部３０２、通信手段たるネットワークインターフェース部３０５を具備し、各部はＢＵＳに接続されている。
【００３４】
前記記憶部３０１には、制御部３０２が実行するプログラムとして、ユーザ認証機能３０４、ユーザ画面生成機能３０５、注文番号発番機能３０６、注文進捗更新機能３０７、注文情報登録機能３０８、接続先情報取得機能３０９、注文情報チェックデータ生成機能３１０、注文情報チェック呼出機能３１１、注文伝送レイアウトチェック呼出機能３１２、注文伝送データ生成機能３１３、伝送データ送受信機能３１４、注文請書登録機能３１５、チェック結果通知機能３１６、チェック履歴情報登録機能３１７、ログイン履歴情報登録機能３１８、伝送履歴情報登録機能３１９の各プログラムが格納されている。
【００３５】
前記ユーザ認証機能３０４は、買い手側端末１０が共同センタ発注サーバ１１へログインする際のユーザ認証を実行するプログラムである。また、前記ユーザ画面作成機能３０５は、買い手側端末１０に対して表示する画面を生成するプログラムである。また、前記注文番号発番機能３０６は、注文を作成する際の注文番号を発番するためのプログラムである。また、前記注文進捗更新機能３０７は、前記注文番号発番機能３０６によって発番された注文情報が、売り手受注サーバ１５に伝送されるまでの注文の進み具合に関する情報を共同センタデータベースサーバ１４の注文進捗管理テーブル６０６に格納するプログラムである。
【００３６】
また、前記注文情報登録機能３０８は、買い手側端末１０から入力された注文情報を共同センタデータベースサーバ１４の注文情報テーブル６０４に格納するためのプログラムである。また、前記接続先情報取得機能３０９は、注文情報チェック呼出機能３１１、注文伝送レイアウトチェック呼出機能３１２を利用する場合に、複数ある売り手受注サーバ１５のどれに接続すればよいかの情報を共同センタデータベースサーバ１４の接続先管理テーブル６０７から取得するためのプログラムである。
【００３７】
また、前記注文情報チェックデータ生成機能３１０は、注文情報の値チェック（例：桁数、文字種など）や、関連性チェック（例：項目間で必須の組み合わせとなる値、或いは項目間であり得ない組み合わせの値の有無など）を実施する場合に、売り手受注サーバ１５へ送付するチェック用データの生成を行うプログラムである。前記注文情報チェック呼出機能３１１は、前記注文情報の値チェックや関連性チェックを実施する場合に、売り手受注サーバ１５のデータチェック機能７０４を呼び出すためのプログラムである。
【００３８】
また、前記注文伝送レイアウトチェック呼出機能３１２は、注文伝送データ生成機能３１３によって作成された注文伝送データのレイアウトチェック（図２９等に基づき後述する）を実施する場合に、売り手受注サーバ１５のレイアウトチェック機能７０６を呼び出すためのプログラムである。また、前記注文伝送データ生成機能３１３は、共同センタデータベースサーバ１４に登録されている注文情報テーブル６０４をもとに、売り手受注サーバ１５に注文として実際に伝送するデータを生成するプログラムである。
【００３９】
また、前記伝送データ送受信機能３１４は、売り手受注サーバ１５とのデータ伝送を実施するためのプログラムである。また、前記注文請書登録機能３１５は、売り手受注サーバ１５より伝送された注文請書情報を共同センタデータベースサーバ１４の注文請書情報テーブル６０５にデータ格納するためのプログラムである。また、前記チェック結果通知機能３１６は、前記注文情報チェック呼出機能３１１、前記注文伝送レイアウトチェック呼出機能３１２によってチェックされた結果を、買い手側端末１０における表示部２０２の画面に通知するためのプログラムである。
【００４０】
また、前記チェック履歴情報登録機能３１７は、前記注文情報チェック呼出機能３１１、注文伝送レイアウトチェック呼出機能３１２が実行された際にその履歴を共同センタデータベースサーバ１４のデータチェック利用履歴管理テーブル６０９に格納するためのプログラムである。また、前記ログイン履歴情報登録機能３１８は、買い手側端末１０から共同センタ発注サーバ１１に対し前記ユーザ画面生成機能３０５を介してログインがなされた際の履歴情報を、共同センタデータベースサーバ１４の発注サーバログイン履歴管理テーブル６０８に格納するためのプログラムである。また、前記伝送履歴情報登録機能３１９は、売り手受注サーバ１５に対してデータ伝送を実施した場合に、その履歴情報を共同センタデータベースサーバ１４の注文伝送履歴管理テーブル６１０に格納するためのプログラムである。
【００４１】
図４は、共同センタ伝送スケジュールサーバ１２のハードウェア構成を示す図である。共同センタ伝送スケジュールサーバは、ハードディスクドライブや各種メモリ等で構成される記憶部４０１、ＣＰＵ等の制御部４０２、通信手段たるネットワークインターフェース部４０３を具備し、各部はＢＵＳに接続されている。前記記憶部４０１には、前記制御部４０２が実行するプログラムとして、注文伝送スケジュール機能４０４、集計スケジュール機能４０５の各プログラムが格納されている。
【００４２】
前記注文伝送スケジュール機能４０４は、共同センタ発注サーバ１１に対して、注文伝送データを、予め登録された伝送スケジュール（所定の日時、所定間隔等）にしたがって伝送指示するためのプログラムである。また、前記集計スケジュール機能４０５は、共同センタ課金集計サーバ１３に対して、予め登録された時間にしたがって、集計処理するように指示するためのプログラムである。
【００４３】
図５は、共同センタ課金集計サーバ１３のハードウェア構成を示す図である。共同センタ課金集計サーバは、ハードディスクドライブや各種メモリ等で構成される記憶部５０１、ＣＰＵ等の制御部５０２、通信手段たるネットワークインターフェース部５０３を具備し、各部はＢＵＳに接続されている。前記記憶部５０１には、制御部５０２が実行するプログラムとして、注文約定件数集計５０４、利用ユーザ数・利用時間集計５０５、データチェック利用回数集計５０６、注文伝送サイズ・回数集計５０７、注文データチェックサービス請求料金計算５０８、注文データチェックサービス請求書生成５０９の各プログラムが格納されている。
【００４４】
前記注文約定件数集計５０４は、共同センタデータベースサーバ１４の注文情報テーブル６０４をもとに注文件数の集計を行い、その結果を注文件数集計テーブル６１１に格納するプログラムである。また、前記利用ユーザ数・利用時間集計５０５は、共同センタデータベースサーバ１４の発注サーバログイン履歴管理テーブル６０８をもとに、各ユーザの当該システム１００の利用時間・回数の集計を行い、その結果を発注サーバログイン集計テーブル６１２に格納するプログラムである。
【００４５】
また、前記データチェック利用回数集計５０６は、共同センタデータベースサーバ１４のデータチェック利用履歴管理テーブル６０９をもとに、前記売り手側システム２００が提供するデータチェックプログラムの利用回数を集計し、その結果をデータチェック利用集計テーブル６１３に格納するプログラムである。また、前記注文伝送サイズ・回数集計５０７は、共同センタデータベースサーバ１４の注文伝送履歴管理テーブル６１０をもとに、例えば買い手毎の注文伝送データの伝送サイズ、伝送回数の集計を行い、その結果を注文伝送量集計テーブル６１４に格納するプログラムである。
【００４６】
また、前記注文データチェックサービス請求料金計算５０８は、共同センタデータベースサーバ１４の注文件数集計テーブル６１１、発注サーバログイン集計テーブル６１２、データチェック利用集計テーブル６１３、注文伝送量集計テーブル６１４、課金按分マスタ６１７をもとに、各集計データの料金計算における重み付けと、買い手側に対するデータチェックサービスの利用料金計算を行い、その結果を課金請求テーブル６１５に格納するプログラムである。また、前記注文データチェックサービス請求書生成５０９は、共同センタデータベースサーバ１４の課金請求テーブル６１５をもとに、買い手側に発行するデータチェックサービスの利用に関する請求書の生成を行うプログラムである。
【００４７】
図６は、共同センタデータベースサーバ１４のハードウェア構成を示す図である。共同センタデータベースサーバ１４は、ハードディスクドライブや各種メモリ等で構成される記憶部６０１、ＣＰＵ等の制御部６０２、通信手段たるネットワークインターフェース部６０３を具備し、各部はＢＵＳに接続されている。前記記憶部６０１には、注文情報テーブル６０４、注文請書情報テーブル６０５、注文進捗管理テーブル６０６、接続先管理テーブル６０７、発注サーバログイン履歴管理テーブル６０８、データチェック利用履歴管理テーブル６０９、注文伝送履歴管理テーブル６１０、注文件数集計テーブル６１１、発注サーバログイン集計テーブル６１２、データチェック利用集計テーブル６１３、注文伝送量集計テーブル６１４、課金請求テーブル６１５、注文項目マスタ６１６、課金按分マスタ６１７、ユーザマスタ６１８、メーカマスタ６１９、および会社マスタ６２０の各テーブル情報が格納されている。以下、各テーブル類の概略を説明する（詳細は後述する）。
【００４８】
前記注文情報テーブル６０４は、買い手が売り手(メーカ)に発注する注文情報を格納する。また、前記注文請書情報テーブル６０５は、売り手が発行した注文請情報を格納する。また、前記注文進捗管理テーブル６０６は、買い手が共同センタ発注サーバ１１を介して注文発注する際の、注文の処理状況を格納する。また、前記接続先管理テーブル６０７は、共同センタ発注サーバ１１が売り手受注サーバ１５へチェック用データに関するデータチェック（レイアウトチェック含む）を実施させる場合の接続先情報を格納する。
【００４９】
また、前記発注サーバログイン履歴管理テーブル６０８は、買い手側端末１０から共同センタ発注サーバ１１のシステムへのログインがなされた際の履歴情報(例：時間と回数)を格納する。また、前記データチェック利用履歴管理テーブル６０９は、共同センタ発注サーバ１１が売り手受注サーバ１５に注文情報データチェック及び、レイアウトチェックを実施させた回数を格納する。また、前記注文伝送履歴管理テーブル６１０は、共同センタ発注サーバ１１から売り手受注サーバ１５へ伝送した注文伝送データの履歴情報(時間、サイズ、回数)を格納する。
【００５０】
また、前記注文件数集計テーブル６１１は、前記注文情報テーブル６０４をもとに集計された、例えば月別の注文件数情報を格納する。また、前記発注サーバログイン集計テーブル６１２は、前記発注サーバログイン履歴管理テーブル６０８をもとに集計された、例えば月別のログイン時間・回数情報を格納する。また、前記データチェック利用集計テーブル６１３は、データチェック利用履歴管理テーブル６０９をもとに集計された月別のデータチェック回数情報を格納する。
【００５１】
また、前記注文伝送量集計テーブル６１４は、前記注文伝送履歴管理テーブル６１０をもとに集計された、例えば月別の注文伝送量(サイズ、回数)情報を格納する。また、前記注文項目マスタ６１６は、注文情報の項目定義を格納するマスタ情報である。また、前記課金按分マスタ６１７は、データチェックサービスの利用料金を計算する際に、料金計算の基礎となる注文件数集計テーブル６１１、発注サーバログイン集計テーブル６１２、データチェック利用集計テーブル６１３、注文伝送量集計テーブル６１４の重み付け情報を格納するマスタ情報である。また、前記ユーザマスタ６１８は、買い手側端末１０から共同センタ発注サーバ１１にログインがなされる際の認証基準となるユーザ情報と認証情報を格納するマスタ情報である。また、前記メーカマスタ６１９は、製品等の発注先となる売り手(メーカ)の情報を格納するマスタ情報である。また、前記会社マスタ６２０は、共同センタ（前記システム１００）を利用する買い手ユーザの会社・部門情報を格納するマスタ情報である。
【００５２】
図７は、売り手受注サーバ１５のハードウェア構成を示す図である。売り手受注サーバは、ハードディスクドライブやメモリ等で構成される記憶部７０１、ＣＰＵ等の制御部７０２、通信手段たるネットワークインターフェース部７０３を具備し、各部はＢＵＳに接続されている。前記記憶部７０１には、前記制御部７０２が実行するプログラムとして、データチェック機能７０４、データチェック結果生成機能７０５、レイアウトチェック機能７０６、レイアウトチェック結果作成機能７０７、伝送データ生成機能７０８、伝送データ送受信機能７０９、伝送データ取込機能７１０の各プログラムと、受注データ管理データベース７１１が格納されている。
【００５３】
前記データチェック機能７０４は、共同センタ発注サーバ１１から要求された、注文情報の項目値と、複数の項目値の間の関連性チェックを実行するプログラムである。また、前記データチェック結果生成機能７０５は、前記データチェック機能７０４によって実行されたチェックの結果を共同センタ発注サーバへ返送する際のメッセージを生成するプログラムである。また、前記レイアウトチェック機能７０６は、共同センタ発注サーバ１１から要求された注文伝送データのレイアウトチェックを実行するプログラムである。
【００５４】
また、前記レイアウトチェック結果作成機能７０７は、前記レイアウトチェック機能７０６によって実行されたレイアウトチェックの結果を共同センタ発注サーバへ返送する際のメッセージを生成するプログラムである。また、前記伝送データ生成機能７０８は、共同センタ発注サーバ１１に対する注文請書データを生成するプログラムである。また、前記伝送データ送受信機能７０９は、前記伝送データ生成機能７０８によって生成された注文請書データを共同センタ発注サーバ１１に送信したり、共同センタ発注サーバ１１から伝送された注文伝送データを受信したりする伝送機能を実装したプログラムである。また、前記伝送データ取込機能７１０は、共同センタ発注サーバ１１から伝送された注文伝送データが含む注文情報を、受注データ管理データベース７１１に格納するプログラムである。また、前記受注データ管理データベース７１１は、共同センタ発注サーバ１１から伝送された注文情報を受注データとして管理するデータベースである。
【００５５】
図８は、売り手受注承認端末１６のハードウェア構成を示す図である。売り手受注承認端末１６は、ハードディスクドライブやメモリ等で構成される記憶部８０１、ディスプレイなどの表示部８０２、キーボードやマウスなどの入力部８０３、ＣＰＵ等の制御部８０４、通信手段たるネットワークインターフェース部８０５を具備し、各部はＢＵＳに接続されている。前記記憶部８０１には、制御部８０４が実行するプログラムとして、画面表示機能８０６、受注承認機能８０７の各プログラムが格納されている。実行された前記画面表示プログラム８０６の結果は、表示部８０２に表示される。また、売り手受注承認端末１６のユーザは、前記表示部８０２に表示された受注情報画面に対して、入力部８０３から受注承認機能８０７を介して受注承認処理を行い、その情報はネットワークインターフェース部８０５を介して、売り手受注サーバ１５の受注データ管理データベース７１１に格納される。
【００５６】
これまで示した前記システム１００、売り手側システム２００、買い手側端末１０における各機能はハードウェアとして実現してもよいし、メモリやＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの適宜な記憶部に格納したプログラムとして実現するとしてもよい。この場合、ＣＰＵなど制御部がプログラム実行に合わせて記憶部より該当プログラムを読み出して、これを実行することとなる。
【００５７】
−−−テーブル等の構成例−−−
続いて、前記システム１００の共同センタデータベースサーバ１４や、前記売り手側システム２００の売り手受注サーバ１５が備えるテーブル類についてその構成例を説明する。図９は、注文情報テーブル６０４の構成例を示す図である。図９に示すように、注文情報テーブル６０４には、注文番号９０１と、メーカＩＤ９０２と、会社ＩＤ９０３と、需要家９０４と、数量９０５、製品情報９０６、仕様情報９０７、その他仕様情報９０８、および登録日時９０９を示す各情報がそれぞれ対応付けて格納される。ここで、前記注文番号９０１は、買い手が売り手に対して発注する注文情報を識別する情報である。また、メーカＩＤ９０２は、注文発注先である売り手側のメーカを識別する情報である。また、会社ＩＤ９０３は、発注元となる買い手＝注文者を識別する情報である。
【００５８】
また、需要家９０４は買い手が発注した注文品について、実際に利用する会社・組織情報を示す項目である。例えば、実際に製品を調達したいユーザが、買い手を介してメーカに製品を発注する場合は、需要家９０４にはその調達したいユーザ(会社・組織)の情報が格納される。もしも注文者が製品の利用者と同じであれば、需要家９０４には会社ＩＤ９０３と同じ情報が格納される。また、数量９０５は、買い手が発注する注文製品の注文量を示す情報である。また、製品情報９０６は、買い手が発注する品を識別する情報である。また、仕様情報９０７と、その他仕様情報９０８は、製品情報９０６が示す製品に関する詳細仕様情報が示される。また、登録日時９０９は、注文情報が注文情報テーブル６０４に格納された日時を示す情報である。
【００５９】
図１０は、注文請書情報テーブル６０５の構成例を示す図である。図１０に示すように、注文請書情報テーブルには、注文番号１００１と、メーカＩＤ１００２と、会社ＩＤ１００３と、需要家１００４と、数量１００５、製品情報１００６、仕様情報１００７、その他仕様情報１００８、および承認日時１００９を示す情報がそれぞれ対応付けて格納される。前記注文番号１００１、メーカＩＤ１００２、会社ＩＤ１００３、需要家１００４、数量１００５、製品情報１００６、仕様情報１００７、その他仕様情報１００８については、売り手(メーカ)から送付された注文請書情報の項目であり、各項目の情報は注文情報テーブル６０４と同等の情報が示される。また、承認日時１００９については、売り手受注承認端末１６で承認された日時を示す情報である。
【００６０】
図１１は、注文進捗管理テーブル６０６の構成例を示す図である。図１１に示すように、この注文進捗管理テーブル６０６には、注文番号１１０１と、作成日時１１０２と、更新日時１１０３と、注文ステータス１１０４を示す情報がそれぞれ対応付けて格納される。前記注文番号１１０１は、前記注文情報テーブル６０４の注文番号９０１と対応付けされた情報であり、注文を識別するための情報である。また、前記作成日時１１０２は、注文ステータス１１０４が初めて更新された日時を示す時刻情報である。また、前記更新日時１１０３は、注文ステータス１１０４が最後に更新された日時を示す時刻情報である。また、前記注文ステータス１１０４は、作成された注文情報に関して発番がなされてから、注文請書を受信するまでの進捗状況を示す情報である。本実施形態では、注文ステータス１１０４は、「注文編集中」、「データチェック中」、「注文伝送待ち」、「注文伝送中」、「注文伝送済」、「注文保留登録」、「注文取消し」、「注文請済」のいずれかでステータス管理をする。
【００６１】
図１２は、接続先管理テーブル６０７の構成例を示す図である。図１２に示すように、この接続先管理テーブル６０７は、ユーザＩＤ１２０１と、会社ＩＤ１２０２と、兼務ＩＤ１２０３と、メーカＩＤ１２０４と、接続アドレス１２０５と、利用期限１２０６、有効無効フラグ１２０７を示す情報がそれぞれ対応付けて格納される。前記ユーザＩＤ１２０１と、会社ＩＤ１２０２と、兼務ＩＤ１２０３は、ユーザマスタ６１８のユーザＩＤ２３０１、会社ＩＤ２３０２、兼務ＩＤ２３０３と対応付けられた共同センタ発注サーバ１５を利用する買い手ユーザを識別する情報である。また、前記メーカＩＤ１２０４は、メーカマスタ６１９のメーカＩＤ２４０１と対応付けられた売り手メーカの情報を識別する情報である。また、前記接続アドレス１２０５は、共同センタ発注サーバ１１から売り手受注サーバ１５のデータチェック機能７０４やレイアウトチェック機能７０６を呼出すにあたって、接続すべき売り手受注サーバ１５の接続先＝ネットワーク上のアドレスを示す情報である。また、前記利用期限１２０６は、本レコードの利用有効期間を示す情報であり、この期限を過ぎているレコードは、データチェック機能やレイアウトチェック機能が無効となる。また、前記有効無効フラグ１２０７は、データチェック機能、レイアウトチェック機能を有効にするか無効にするかを識別するための情報である。前記有効無効フラグ１２０７は、「有効」、「無効」のいずれかで管理する。
【００６２】
図１３は、発注サーバログイン履歴管理テーブル６０８の構成例を示す図である。この発注サーバログイン履歴管理テーブル６０８は、図１３に示すように、年月日１３０１と、ユーザＩＤ１３０２と、会社ＩＤ１３０３と、兼務ＩＤ１３０４と、ログイン通算時間１３０５と、最終ログイン日時１３０６と、認証回数１３０７を示す情報がそれぞれ対応付けて格納される。なお、前記年月日１３０１は、買い手側端末１０が共同センタ発注サーバ１１へログインした年月日を示す時刻情報である。また、前記ユーザＩＤ１３０２と、会社ＩＤ１３０３と、兼務ＩＤ１３０４は、ユーザマスタ６１８のユーザＩＤ２３０１、会社ＩＤ２３０２、兼務ＩＤ２３０３と対応付けられた共同センタ発注サーバ１５を利用する買い手ユーザを識別する情報である。また、前記ログイン通算時間１３０５は、買い手側端末１０が過去に共同センタ発注サーバ１１にアクセスした利用時間の総和を示す時間情報である。また、前記最終ログイン日時１３０６は、買い手側端末１０が共同センタ発注サーバ１１へ最後にログインしたときの時刻を示す情報である。また、前記認証回数１３０７は、買い手側端末１０を介して買い手ユーザが共同センタ発注サーバ１１へログイン認証した回数を示す情報である。
【００６３】
図１４は、データチェック利用履歴管理テーブル６０９の構成例を示す図である。このデータチェック利用履歴管理テーブル６０９は、図１４に示すように、年月日１４０１と、チェック区分１４０２と、ユーザＩＤ１４０３と、会社ＩＤ１４０４と、兼務ＩＤ１４０５と、メーカＩＤ１４０６と、チェック回数１４０７を示す情報がそれぞれ対応付けて格納される。なお、前記年月日１４０１は、共同センタ発注サーバ１１が売り手受注サーバ１５にデータチェックを実施させた年月日情報を示す情報である。また、前記チェック区分１４０２は、チェックの方式を識別するための区分情報であり、「データチェック」と「レイアウトチェック」のいずれかで示す。また、前記ユーザＩＤ１４０３と、会社ＩＤ１４０４と、兼務ＩＤ１４０５は、ユーザマスタ６１８のユーザＩＤ２３０１、会社ＩＤ２３０２、兼務ＩＤ２３０３と対応付けられた共同センタ発注サーバ１５を利用する買い手ユーザを識別する情報である。また、前記メーカＩＤ１４０６は、メーカマスタ６１９のメーカＩＤ２４０１と対応付けられた売り手メーカの情報を識別する情報である。また、前記チェック回数１４０７は、共同センタ発注サーバ１１が売り手受注サーバ１５にデータチェックやレイアウトを実施させた回数を示すものである。つまり、データチェック利用履歴管理テーブル６０９は、ユーザ別、メーカ別、日別に、共同センタ発注サーバ１１が売り手受注サーバ１５にデータチェックやレイアウトを実施させた履歴情報が格納される。
【００６４】
図１５は、注文伝送履歴管理テーブル６１０の構成例を示す図である。この注文伝送履歴管理テーブル６１０は、図１５に示すように、伝送日時１５０１、会社ＩＤ１５０２、メーカＩＤ１５０３、注文サイズ１５０４を示す情報がそれぞれ対応付けて格納される。なお、前記伝送日時１５０１は、共同センタ発注サーバ１１から売り手受注サーバ１５へ注文伝送データの伝送を実施した日時を示す時間情報である。また、前記会社ＩＤ１５０２は、どの買い手ユーザから共同センタ発注サーバ１１を経由した売り手受注サーバ１５への注文伝送データの伝送を実施したかを識別する情報である。また、前記メーカＩＤ１５０３は、メーカマスタ６１９のメーカＩＤ２４０１と対応付けられ、伝送先の売り手メーカの情報を識別する情報である。また、前記注文サイズ１５０４は、共同センタ発注サーバ１１から売り手受注サーバ１５へ伝送した注文伝送データのサイズを格納する情報である。この注文伝送履歴管理テーブル６１０は、注文伝送毎に発生する上記情報を管理する。
【００６５】
図１６は、注文件数集計テーブル６１１の構成例を示す図である。この注文件数集計テーブル６１１は、図１６に示すように年月１６０１、会社ＩＤ１６０２、メーカＩＤ１６０３、注文約定件数１６０４を示す情報がそれぞれ対応付けて格納される。なお、前記年月１６０１は、年月の時間を示す情報である。また、前記会社ＩＤ１６０２は、発注元となる買い手＝注文者を識別する情報である。また、メーカＩＤ１６０３は、メーカマスタ６１９のメーカＩＤ２４０１と対応付けられた売り手メーカの情報を識別する情報である。また、前記注文約定件数１６０４は、共同センタ発注サーバ１１で注文約定された件数を示す情報であり、前記注文情報テーブル６０４の登録日時９０９の年月情報と、会社ＩＤ９０３と、メーカＩＤ９０２でサマリされたレコード件数で求められる。
【００６６】
図１７は、発注サーバログイン集計テーブル６１２の構成例を示す図である。この発注サーバログイン集計テーブル６１２は、図１７に示すように、年月１７０１と、会社ＩＤ１７０２と、ログイン時間合計１７０３と、ログイン回数合計１７０４と、ユーザ数合計１７０５を示す情報がそれぞれ対応付けて格納される。なお、前記年月１７０１は、発注サーバログイン履歴管理テーブル６０８の年月日１３０１の年月情報と対応づけられた時間情報である。また、前記会社ＩＤ１７０２は、発注元となる買い手＝注文者を識別する情報である。また、前記ログイン時間合計１７０３は、発注サーバログイン履歴管理テーブル６０８の年月日１３０１の年月情報と、会社ＩＤ１３０３で、ログイン通算時間１３０５をサマリした結果で求められる時間情報である。また、前記ログイン回数合計１７０４は、発注サーバログイン履歴管理テーブル６０８の年月日１３０１の年月情報と、会社ＩＤ１３０３で、認証回数１３０７をサマリした結果で求められる数値情報である。また、前記ユーザ数合計１７０５は、発注サーバログイン履歴管理テーブル６０８の年月日１３０１の年月情報と、会社ＩＤ１３０３で、サマリされたレコード件数で求められる。
【００６７】
図１８は、データチェック利用集計テーブル６１３の構成例を示す図である。このデータチェック利用集計テーブル６１３は、図１８に示すように、年月１８０１と、会社ＩＤ１８０２と、メーカＩＤ１８０３と、チェック利用回数１８０４を示す情報がそれぞれ対応付けて格納される。なお、前記年月１８０１は、データチェック利用履歴管理テーブル６０９の年月日１４０１の年月情報と対応付けられた時間情報である。また、前記会社ＩＤ１８０２は、発注元となる買い手＝注文者を識別する情報である。また、前記メーカＩＤ１８０３は、データチェックプログラムを提供した売り手(メーカ)を識別するための情報である。また、前記チェック利用回数１８０４は、データチェック利用履歴管理テーブル６０９の年月日１４０１の年月情報と、会社ＩＤ１４０３で、チェック回数１４０７をサマリした結果で求められる数値情報である。
【００６８】
図１９は、注文伝送量集計テーブル６１４の構成例を示す図である。この注文伝送量集計テーブル６１４は、図１９に示すように、年月１９０１と、会社ＩＤ１９０２と、メーカＩＤ１９０３と、注文サイズ合計１９０４と、伝送回数合計１９０５を示す情報がそれぞれ対応付けて格納される。なお、前記年月１９０１は、注文伝送履歴管理テーブル６１０の伝送日時１５０１の年月情報と対応付けられた時間情報である。また、前記会社ＩＤ１９０２は、発注元となる買い手＝注文者を識別する情報である。また、前記メーカＩＤ１９０３は、メーカマスタ６１９のメーカＩＤ２４０１と対応付けられた売り手メーカの情報を識別する情報である。また、前記注文サイズ合計１９０４は、注文伝送履歴管理テーブル６１０の伝送日時１５０１の年月情報と、会社ＩＤ１５０２と、メーカＩＤ１５０３で注文サイズ１５０４をサマリした結果で求められる数値情報である。また、前記伝送回数合計１９０５は、注文伝送履歴管理テーブル６１０の伝送日時１５０１の年月情報と、会社ＩＤ１５０２と、メーカＩＤ１５０３で、サマリされたレコード件数で求められる。
【００６９】
図２０は、課金請求テーブル６１５の構成例を示す図である。この課金請求テーブル６１５は、図２０に示すように、年月２００１と、会社ＩＤ２００２と、請求料金２００３を示す情報がそれぞれ対応付けて格納される。なお、前記年月２００１は、料金請求月を示す時間情報である。また、前記会社ＩＤ２００２は、発注元となる買い手＝注文者を識別する情報で、料金請求先情報でもある。また、前記請求料金２００３は、料金請求先への請求料金を示す金額情報である。
【００７０】
図２１は、注文項目マスタ６１６の構成例を示す図である。この注文項目マスタ６１６は、図２１に示すように、項目ＩＤ２１０１と、項目名２１０２と、文字属性２１０３と、桁数２１０４を示す情報がそれぞれ対応付けて格納される。なお、前記項目ＩＤ２１０１は、注文情報を構成する各項目の識別情報であり、前記項目名２１０２は、前記項目ＩＤ２１０１の名称を示すものである。また、前記文字属性２１０３は、該当する項目がどのような文字属性になるかを示す情報であり、例えば、数値、文字列といった情報が格納される。また、前記桁数２１０４は、該当項目の数値の有効桁数、文字列のバイト数情報である。
【００７１】
図２２は、課金按分マスタ２２０１の構成例を示す図である。この課金按分マスタ２２０１は、図２２に示すように、按分ＩＤ２２０１、チェック回数按分２２０２と、ログイン按分２２０３と、伝送量按分２２０４と、伝送回数按分２２０５と、注文件数按分２２０６と、請求予定金額２２０７を示す情報がそれぞれ対応付けて格納される。なお、前記按分ＩＤ２２０１は、買い手ユーザ(会社)に、データチェックサービスの利用料金の按分方法を識別するための情報であり、このＩＤを利用することで例えば、年月毎に請求按分を変更したり、買い手ユーザの利用度合いや会社規模によって、サービス料金の計算方式を変更したりといったことも可能となる（ただし本実施形態において、このＩＤの利用の仕方はどのような方法でも構わない）。また、前記チェック回数按分２２０２と、伝送量按分２２０４と、伝送回数按分２２０５と、注文件数按分２２０６は、データチェックサービスの利用に対する負担重み付けを行う値であり、各値の総和は１００％となる。そのため、重み付けの値が高いものほど、サービス料金に対する影響も大きくなる。また、前記請求予定金額２２０７は、買い手ユーザに対するデータチェックサービスの利用料の請求予定金額の総和を示す情報である。この費用は共同センタ側＝システム側が、売り手のメーカに対して還流させることで、売り手側でのデータチェックプログラムの開発・メンテナンス費用の資金源にもなる。
【００７２】
図２３は、ユーザマスタ６１８の構成例を示す図である。このユーザマスタ６１８は、図２３に示すように、ユーザＩＤ２３０１と、会社ＩＤ２３０２と、業務ＩＤ２３０３と、権限２３０４と、パスワード２３０５と、有効期限２３０６と、有効フラグ２３０７を示す情報がそれぞれ対応付けて格納される。なお、前記ユーザＩＤ２３０１は、買い手側端末１０から共同センタ発注サーバ１１のシステムへログインする利用者の識別情報である。また、前記会社ＩＤ２３０２は、ユーザＩＤ２３０１が所属する会社を識別する情報であり、会社マスタ６２０の２５０１に対応付けられる。また、前記兼務ＩＤ２３０３は、ユーザＩＤ２３０１に対応するユーザが複数部門に兼務で所属している場合の識別情報である。また、前記権限２３０４は、ユーザＩＤ２３０１に対応するユーザが、共同センタ発注サーバ１１の利用可能範囲を示す識別情報である。また、前記パスワード２３０５は、買い手側端末１０から共同センタ発注サーバ１１へログインする際の認証情報である。また、前記有効期限２３０６は、該当ユーザが、共同センタ発注サーバ１１のシステムをいつまで利用可能かを示す年月日情報である。また、前記有効フラグ２３０７は、ユーザＩＤ２３０１の有効、無効の設定を示す識別情報である。この有効フラグ２３０７が無効である場合は、該当ユーザに関して、共同センタ発注サーバ１１への認証は全てなされない。
【００７３】
図２４は、メーカマスタ６１９の構成例を示す図である。このメーカマスタ６１９は、図に示すように、メーカＩＤ２４０１と、メーカ名２４０２と、メーカグループ２４０３を示す情報がそれぞれ対応付けて格納される。なお、前記メーカＩＤ２４０１は、売り手となるメーカを識別する情報であり、前記メーカ２４０２は、前記メーカＩＤ２４０１に対応付けられた名称情報である。また、前記メーカグループ２４０３は、複数の売り手が連結会社として同系列の会社としてまとめられる場合に、これを識別する情報である。
【００７４】
図２５は、会社マスタ６２０の構成例を示す図である。この会社マスタ６２０は、図に示すように、会社ＩＤ２５０１と、会社名２５０２と、住所２５０３を示す情報がそれぞれ対応付けて格納される。なお、前記会社ＩＤは、買い手や売り手など前記システム１００等を利用する組織や会社を識別するための情報である。また、会社名２５０２は、前記会社ＩＤ２５０１で識別される会社の名称を示す情報であり、前記住所２５０３は、前記会社ＩＤ２５０１で識別される会社の住所を示す情報である。
【００７５】
図２６は、受注データ管理データベース７１１の構成例を示す図である。この受注データ管理データベース７１１は、図２６に示すように、注文番号２６０１と、注文者２６０２と、需要家２６０３と、数量２６０４、製品情報２６０５、仕様情報２６０６、注文受付日時２６０７、承認日時２６０８、納期２６０９を示す情報がそれぞれ対応付けて格納される。なお、前記注文番号２６０１、注文者２６０２、需要家２６０３、数量２６０４、製品情報２６０５、仕様情報２６０６については、共同センタ発注サーバ１１から伝送された注文伝送データ（＝注文情報を含んでいる）と対応づけられた情報を格納する。また、前記注文受付日時２６０７は、共同センタ発注サーバ１１から注文伝送データが伝送された日時を示す時間情報であり、前記承認日時２６０８は、売り手受注承認端末１６から注文承認された日時を示す時間情報である。また、前記納期２６０９は、受注した製品の納期日時を示す時間情報である。
【００７６】
−−−処理手順例（値チェック）−−−
以下、本実施形態におけるＥＤＩデータ管理方法の実際手順について図を用いながら説明する。以下で説明するＥＤＩデータ管理方法に対応する主たる動作は、前記システム１００を構成する各サーバのＣＰＵなど制御部が記憶部より読み出して実行するプログラムによって実現される。また、その他の動作は、買い手側端末１０や売り手側システム２００を構成する装置で同様に実現される。そして、こうしたプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００７７】
図２７と図２８は、本実施形態におけるＥＤＩデータ管理方法の処理フロー例１、および処理フロー例２を示す図であり、企業間ＥＤＩ取引における注文情報の値チェック処理を示すフローチャートである。
【００７８】
ここではまず、買い手ユーザ＝企業の担当者等が買い手側端末１０において、共同センタ発注サーバ１１のログインＵＲＬを入力したとする。これを受けた共同センタ発注サーバ１１は、図３１のログイン画面に対応する画面データを返信し、買い手側端末１０の表示部２０２では画面表示機能２０６により前記ログイン画面が表示されることとなる(Ｓ２７０１、Ｓ２７０２)。
【００７９】
この時、前記買い手ユーザは、図３１のログイン画面においてユーザＩＤとパスワードを入力し、ログインボタンを押下する。これを受け付けた買い手側端末１０は、ユーザＩＤ、パスワードの各データを含む認証要求を、共同センタ発注サーバ１１に送る(Ｓ２７０３)。
【００８０】
一方、前記共同センタ発注サーバ１１は、前記買い手側端末１０から送信された認証要求が含むユーザＩＤとパスワードをもとに、前記ユーザ認証機能３０４によって、前記共同センタデータベースサーバ１４のユーザマスタ６１８を利用するなどして認証処理を実施する(Ｓ２７０４)。ここでのユーザ認証が成功した場合、共同センタ発注サーバ１０は、ログイン情報履歴登録機能３１８により、発注サーバログイン履歴管理テーブル６０８において、該当するユーザＩＤのレコードでログイン時間と回数の更新処理を行う(Ｓ２７０５)。
【００８１】
このログイン履歴更新終了後、前記共同センタ発注サーバ１１は、図３２の注文基本入力画面のデータ（例：記憶部にて予め保持）を買い手側端末１０に送信して表示させる(Ｓ２７０６)。買い手ユーザは、買い手側端末１０で表示された前記注文基本入力画面において、発注先となる売り手(メーカ)情報の入力をし、登録ボタンを押下することとなる。この入力と登録ボタン押下を受けた買い手側端末１０は、前記注文基本入力画面で得た情報を共同センタ発注サーバ１１に送る(Ｓ２７０７、Ｓ２７０８)。
【００８２】
共同センタ発注サーバ１１では、買い手側端末１０から送られた注文基本情報に対し、注文番号発番機能３０６によって注文番号の発番を行い、注文情報テーブル６０４において、前記発番した注文番号を対応付けて注文情報を格納する(Ｓ２７０９)。また、共同センタ発注サーバ１１は、注文進捗更新機能３０７により、注文ステータス「注文編集中」として、注文進捗管理テーブル６０６に情報を格納する(Ｓ２７１０)。さらに、共同センタ発注サーバ１１は、注文詳細画面データ（例：記憶部にて予め保持）を買い手側端末１０に送信し表示させる(Ｓ２７１１)。
【００８３】
買い手ユーザは、買い手側端末１０の表示部２０２に表示された注文詳細画面において、発注する注文製品の詳細情報を入力し、登録ボタンを押下する。これを受けた買い手側端末１０は、前記注文詳細情報を共同センタ発注サーバ１１に送信する(Ｓ２８０１、Ｓ２８０２)。一方、共同センタ発注サーバ１１は、買い手側端末１０より送付された注文詳細情報を受信し、注文情報テーブル６０４に格納する(Ｓ２８０３)。その後、共同センタ発注サーバ１１は、注文情報が含む値（例：注文の数量や製品の型番、年月日、など）や、複数項目間の値の関連性チェックのために、接続先情報取得機能３０９により、接続先管理テーブル６０７から該当売り手(メーカ)に関するネットワーク上のアドレス＝接続先情報の取得を試みる(Ｓ２８０４)。ここで接続先情報の取得が成功しなかった場合（Ｓ２８０５：Ｎ）は、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、注文進捗管理テーブル６０６での該当注文情報に関する注文ステータスを「注文編集中」から「注文伝送待ち」に更新する(Ｓ２８１４)。
【００８４】
他方、接続先情報の取得が成功した場合（Ｓ２８０５：Ｙ）、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、注文進捗管理テーブル６０６での該当注文情報に関する注文ステータスを「注文編集中」から「注文チェック中」に更新する(Ｓ２８０６)。その後、共同センタ発注サーバ１１は、注文情報チェックデータ生成機能３１０によって、注文情報テーブル６０４と注文項目マスタ６１６から、注文情報に関するチェックを実施するためのチェック用データの生成を行う(Ｓ２８０７)。この注文情報チェックデータ生成機能３１０によるチェック用データの生成処理は、売り手側システム２００で備えるチェックプログラムの要求仕様に合わせて事前に生成手順等が決められているものである（既存のものでもよい）。
【００８５】
ここで生成されたチェック用データは、前記共同センタ発注サーバ１１の注文情報チェック呼出機能３１１によって、共同センタ発注サーバ１１から売り手受注サーバ１５に渡される(Ｓ２８０８)。一方、売り手受注サーバ１５は、データチェック機能７０４によって、共同センタ発注サーバ１１から受け取ったチェック用データをもとに、桁数や文字種などといった注文情報の各項目値、および各項目値間の関連性（必須ないしあり得ない関連性。例えば、「項目Ａに値ａが設定されている時、項目Ｂに値ｂの設定が必須」、或いは、「項目Ａに値ａが設定されている時、項目Ｃに値ｄの設定はあり得ない」といった観点のチェック）に関するチェックを行う(Ｓ２８０９)。このとき、もしも注文者固有のチェックがある場合は、チェック用データとして送付された情報に格納されている会社ＩＤから注文者の特定を行い、注文者特有の個別の項目値チェックを実施する(Ｓ２８１０)。チェック結果は、データチェック結果生成機能７０５によって生成され、売り手受注サーバ１５から共同センタ発注サーバ１１へ返される(Ｓ２８１１)。
【００８６】
共同センタ発注サーバ１１は、売り手受注サーバ１５から返されたデータチェックの結果を、チェック履歴情報登録機能３１８により、チェック利用履歴としてデータチェック利用履歴管理テーブル６０９に格納する(Ｓ２８１２)。さらに、前記共同センタ発注サーバ１１は、ユーザ画面生成機能３０５によりデータチェック結果画面を生成して、チェック結果を買い手側端末１０に送信し、その表示部２０２に図３３のような画面で表示させる(Ｓ２８１３)。買い手ユーザは、図３３の画面を閲覧し、その内容にエラーがある場合は、注文情報の訂正を即時に実施可能となる。データチェック結果がエラーを示さないものか、あるいはユーザによる訂正等を経て所定の指示を受けた時、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、注文進捗管理テーブル６０６の該当レコードで注文ステータスを「注文チェック中」から「注文伝送待ち」に更新する(Ｓ２８１４)。
【００８７】
−−−処理手順例（レイアウトチェック）−−−
次に、レイアウトチェックについて説明する。図２９は、企業間ＥＤＩ取引における注文伝送データのレイアウトチェックの処理を示すフローチャートである。この場合まず、共同センタスケジュールサーバ１２は、注文伝送スケジュール機能４０４によって、予め定められたスケジュールで共同センタ発注サーバ１１へ伝送開始指示を行う(Ｓ２９０１)。一方、共同センタ発注サーバ１１は、共同センタスケジュールサーバ１２からの伝送開始指示を受け、注文伝送データ生成機能３１３によって、注文情報テーブル６０４の注文情報をもとに注文伝送データの生成を行う(Ｓ２９０２)。この注文伝送データはレイアウトチェックを受けるデータであるからチェック用データとも言えるが、買い手と売り手の間の正式な注文情報となるものであり、例えば、買い手から予め指定された仕様に基づいたデータで構成される。注文伝送データの生成は、例えば、注文伝送データ生成用のテンプレートを予めシステム１００のいずれかのサーバの記憶部に保持しておき、注文伝送データ生成機能３１３が、このテンプレートにおける各項目に、注文情報中の項目のうち対応項目の値を設定するなどして行う。或いは既存の技術を採用すればよい。
【００８８】
その後、共同センタ発注サーバ１１は、生成された注文伝送データのレイアウトチェックのために、接続先情報取得機能３０９により、取得接続先管理テーブル６０７から該当売り手(メーカ)のネットワーク上の接続情報の取得を試みる(Ｓ２９０４)。ここで接続先情報の取得が成功しなかった場合（Ｓ２９０４：取得失敗）、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、注文進捗管理テーブル６０６の該当レコードで注文ステータスを「伝送待ち」から「注文伝送中」に更新し、共同センタ発注サーバ１１から売り手受注サーバ１５へ注文データの伝送処理を実施する(Ｓ２９０４、Ｓ２９１２、Ｓ２９１３)。つまり、売り手側システム２００での事前チェックを経ずにとりあえず注文伝送データを売り手側システム２００に送信しておくことになる。
【００８９】
一方、接続先情報の取得に成功した場合（Ｓ２９０４：取得成功）、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、進捗管理テーブル６０６の該当レコードで注文ステータスを「伝送待ち」から「注文チェック中」に更新する(Ｓ２９０５)。共同センタ発注サーバ１１は、注文伝送レイアウトチェック呼出機能３１２を行い、注文伝送データ生成機能３１３によって作成された注文伝送データを、売り手受注サーバ１５へ渡し、レイアウトの事前チェックを要求する(Ｓ２９０６)。
【００９０】
他方、売り手受注サーバ１５は、共同センタ発注サーバ１１からのレイアウトチェック要求を受け、レイアウトチェック機能７０６によってレイアウトチェックを実施する(Ｓ２９０７)。このレイアウトチェックに関しては、売り手側の仕様により様々であり、既存技術により実行されることとしてよい。いずれにしても、共同センタ発注サーバ１１が発する注文伝送データが、売り手側の仕様に合致したものかをチェックする。
【００９１】
売り手側システム２００でのチェック結果は、レイアウトチェック結果作成機能７０７によって例えばエラーの有無を示す所定メッセージなどとして生成され、売り手受注サーバ１５から共同センタ発注サーバ１１へ返される(Ｓ２９０８)。共同センタ発注サーバ１１は、売り手受注サーバ１５から返されたレイアウトチェック結果を受信し、チェック履歴情報登録機能３１８により、前記レイアウトチェック結果をデータチェックサービスの利用履歴情報として、データチェック利用履歴管理テーブル６０９に格納する(Ｓ２９０８)。
【００９２】
続いて、共同センタ発注サーバ１１はチェック結果通知機能３１６により、前記レイアウトチェック結果がエラーを示すものか判定する（Ｓ２９１０）。この判定でエラーありと判定した場合（Ｓ２９１０：エラーあり）、前記チェック結果通知機能３１６は、例えば、エラー通知用の所定端末（例：共同センタ発注サーバ１１のシステム管理者が利用する端末等であり、予めそのネットワークアドレスをシステム１００で保持している）や所定の出力装置に、そのエラー内容を通知する(Ｓ２９１１)。この通知を閲覧したシステム管理者等は、エラー内容に従って、注文伝送データ生成プロセスの見直しなど必要な対処を行うこととなる。
【００９３】
他方、前記判定でエラーなしと判定した場合（Ｓ２９１０：エラーなし）、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、進捗管理テーブル６０６の該当レコードに関して注文ステータスを「伝送中」に更新し（Ｓ２９１２）、伝送データ送受信機能３１４により、売り手受注サーバ１５へ注文伝送データの送付を行う（Ｓ２９１３）。この時、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、進捗管理テーブル６０６の該当レコードで注文ステータスを「注文伝送中」から「注文伝送済」に更新し、伝送履歴情報登録機能３１９によって伝送履歴情報を共同センタデータベースサーバ１４の注文伝送履歴管理テーブル６１０に格納する(Ｓ２９１４、Ｓ２９１５)。
【００９４】
一方、売り手受注サーバ１５は、伝送データ送受信機能７０９により、共同センタ発注サーバ１１から伝送された注文伝送データを受取る(Ｓ２９１６)。さらに、伝送データ取込機能７１０により、受注データ管理データベース７１１に注文情報を格納する(Ｓ２９１７)。この伝送データ取込機能７１０による処理については、売り手受注サーバ１５によって実行タイミングが異なっても構わない。
【００９５】
売り手ユーザは、売り手受注承認端末１６の表示部８０２から、受注データ管理データベース７１１に格納された注文情報を確認することとなる。この時、売り手受注承認端末１６は、受注承認機能８０７により、前記売り手ユーザからの受注承認を受け付け、例えば、受注管理データベース７１１の該当レコードで承認日時に承認時点の日時情報を設定する(Ｓ２９１８)。また、売り手受注サーバ１５は、伝送データ生成機能７０８により、前記受注データ管理データベース７１１のうち前記売り手ユーザに受注承認されたデータを、例えば、承認日時欄に日時情報が設定されているレコードを選び出すことで抽出し、注文請書データ（既存形式のものでよい）の生成を行う(Ｓ２９２０)。また、売り手受注サーバ１５は、伝送データ送受信機能７０９により、前記注文請書データを共同センタ発注サーバ１１へ伝送する(Ｓ２９２１)。
【００９６】
一方、共同センタ発注サーバ１１は、伝送データ送受信機能３１４により、注文請書データを受取り(Ｓ２９２１)、注文請書登録機能３１５により、注文請書情報テーブル６０５に格納する(Ｓ２９２２)。さらに、共同センタ発注サーバ１１は、注文進捗更新機能３０７によって、進捗管理テーブル６０６の該当レコードで注文ステータスを「注文伝送済」から「注文請済」に更新を行う(Ｓ２９２３)。
【００９７】
−−−処理手順例（集計と課金）−−−
前記システム１００は、売り手側システム２００を利用しつつ、注文に関するデータチェック（値やレイアウト）のサービスを提供していると言える。このサービス提供に当たっては、買い手側に対してサービス利用料を徴収するビジネス形態を想定できる。そこで、以下にこうしたサービス利用料の算定等について説明する。
【００９８】
図３０は、データチェックサービスの利用料金計算処理を示すフローチャートである。この場合まず、共同センタスケジュールサーバ１２は、集計スケジュール機能４０５によって、予め定められたスケジュールで共同センタ課金集計サーバ１３へ集計開始指示を行う(Ｓ３００１)。
【００９９】
この時、共同センタ課金集計サーバ１３は、共同センタスケジュールサーバ１２からの集計開始指示に従い、例えば、四つの集計処理を実施する。ここでまず一つ目の集計処理として、共同センタ課金集計サーバ１３は、注文約定件数集計機能５０４により、注文情報テーブル６０４における会社別（会社ＩＤ９０３で検索）の注文情報の登録数の集計処理を行い、その集計結果を注文約定集計テーブル６１１に格納する(Ｓ３００２)。
【０１００】
次に二つ目の集計処理として、共同センタ課金集計サーバ１３は、利用ユーザ数・利用時間集計機能５０５により、発注サーバログイン履歴管理テーブル６０８から、会社別（会社ＩＤ１３０３で検索）の利用時間（ログイン通算時間１３０５）とログイン回数（認証回数１３０７）の集計処理を行い、その集計結果を発注サーバログイン集計テーブル６１２に格納する(Ｓ３００３)。
【０１０１】
三つ目の集計処理として、共同センタ課金集計サーバ１３は、データチェック利用回数集計機能５０６により、データチェック利用履歴管理テーブル６０９から会社別（会社ＩＤ１４０４で検索）のデータチェック回数（チェック回数１４０７）の集計を行い、その集計結果をデータチェック利用集計テーブル６１２に格納する(Ｓ３００４)。
【０１０２】
四つ目の集計処理として、共同センタ課金集計サーバ１３は、注文伝送サイズ・回数集計機能５０７により、注文伝送履歴管理テーブル６１０から、会社別（会社ＩＤ１５０２で検索）の伝送サイズ（注文サイズ１５０４）と回数（レコードの件数）の集計を行い、その結果を注文伝送量集計テーブル６１４に格納する(Ｓ３００５)。
【０１０３】
続いて、共同センタ課金集計サーバ１３は、注文データチェックサービス請求料金計算機能５０８によって、買い手ユーザ(会社)へ請求するサービス料金の計算を実施する(Ｓ３００６)。具体的には、上述のステップＳ３００２〜Ｓ３００５で集計された各種情報と、課金按分マスタ６１７をもとに料金の重み付けを加味した料金計算を実施する。例えば、按分内訳が、チェック回数按分「６０％」、ログイン按分「１０％」、伝送量按分「１０％」、伝送回数按分「１０％」、注文件数按分「１０％」である時、前記ステップＳ３００２〜Ｓ３００５による各集計結果に、例えば、所定単価と該当按分値（６０％や１０％）を乗算し、サービス料金の計算を実施する。こうして得られる料金計算結果は、前記共同センタ課金集計サーバ１３の注文データチェックサービス請求料金計算機能５０８によって課金請求テーブル６１５に格納される。
【０１０４】
また、共同センタ課金集計サーバ１３は、注文データチェックサービス請求書生成機能５０９により、買い手ユーザ(会社)へ請求するデータチェックサービスの利用請求書を作成する(Ｓ３００７)。この利用請求書の作成は、所定のフォーマット（予め記憶部に保持）に前記ステップＳ３００６で得られた金額値を設定するなどして行われる。なお、請求金額の合計を、チェックプログラムを提供する売り手側（メーカ）の数で按分し、利用費として該当売り手に対する支払いを行うとしてもよい。
【０１０５】
以上説明したように本実施形態によれば、ＥＤＩ伝送における伝送データを効率的かつ低コストで受信側が処理可能なものとし、伝送データの訂正や再送による業務処理のタイムラグを低減できる。
【０１０６】
以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【符号の説明】
【０１０７】
１  企業間ＥＤＩ伝送システム
１０  買い手側端末
１１  共同センタ発注サーバ
１２  共同センタスケジュールサーバ
１３  共同センタ課金集計サーバ
１４  共同センタデータベースサーバ
１５  売り手受注サーバ
１６  売り手受注承認端末
１４０  ネットワーク
１００  ＥＤＩデータ管理システム
２００  売り手側システム
【図１】
2011128891.tif 000003
【図２】
2011128891.tif 000004
【図３】
2011128891.tif 000005
【図４】
2011128891.tif 000006
【図５】
2011128891.tif 000007
【図６】
2011128891.tif 000008
【図７】
2011128891.tif 000009
【図８】
2011128891.tif 000010
【図９】
2011128891.tif 000011
【図１０】
2011128891.tif 000012
【図１１】
2011128891.tif 000013
【図１２】
2011128891.tif 000014
【図１３】
2011128891.tif 000015
【図１４】
2011128891.tif 000016
【図１５】
2011128891.tif 000017
【図１６】
2011128891.tif 000018
【図１７】
2011128891.tif 000019
【図１８】
2011128891.tif 000020
【図１９】
2011128891.tif 000021
【図２０】
2011128891.tif 000022
【図２１】
2011128891.tif 000023
【図２２】
2011128891.tif 000024
【図２３】
2011128891.tif 000025
【図２４】
2011128891.tif 000026
【図２５】
2011128891.tif 000027
【図２６】
2011128891.tif 000028
【図２７】
2011128891.tif 000029
【図２８】
2011128891.tif 000030
【図２９】
2011128891.tif 000031
【図３０】
2011128891.tif 000032
【図３１】
2011128891.tif 000033
【図３２】
2011128891.tif 000034
【図３３】
2011128891.tif 000035