(57)【要約】【課題】受発注者や取引案件の属性、法的要件等に応じて的確に取引ルールを生成可能とする。【解決手段】発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納するステップと、前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定するステップと、前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定するステップと、前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行するステップとを実行する。【選択図】      図４
2004310145.tif 000002
【特許請求の範囲】
【請求項１】
商品の発注者および受注者の間での受発注処理の手段を情報処理装置により管理する方法であって、
前記情報処理装置は、発注者毎にその属性データをとりまとめたプロファイルを格納した発注者プロファイルテーブルと、
受注者毎にその属性データをとりまとめたプロファイルを格納した受注者プロファイルテーブルと、
各受発注者間で予め取り決めた取引合意事項を記録した取引合意テーブルと、
発注者からの商品発注情報を格納する注文管理テーブルと、
受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めた取引ルールテーブルとにアクセス可能であり、
発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納するステップと、
前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定するステップと、
前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定するステップと、
前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行するステップと、
を含むことを特徴とする受発注処理手段の管理方法。
【請求項２】
前記受発注処理の手段は、通信経路、通信装置、および通信プロトコルの少なくともいずれかであることを特徴とする請求項１に記載の受発注処理手段の管理方法。
【請求項３】
前記受発注処理は、前記受発注処理の手段をもって、商品発注情報のデータが該当する受注者端末にダウンロードされるべく行う処理であることを特徴とする請求項１に記載の受発注処理手段の管理方法。
【請求項４】
前記注文管理テーブルにおいて、各商品発注情報について、受注者端末からの閲覧の済／未済、受注者端末へのダウンロードの済／未済のいずれかの状態を管理することを特徴とする請求項１に記載の受発注処理手段の管理方法。
【請求項５】
前記受発注処理は、前記注文管理テーブルを参照し、商品発注情報の閲覧状況が未済あるいはダウンロード状況が未済である場合に、該当受注者端末へ閲覧もしくはダウンロードを促す通知を実行するものであることを特徴とする請求項４に記載の受発注処理手段の管理方法。
【請求項６】
前記受発注処理は、前記注文管理テーブルを参照し、商品発注情報の閲覧状況が未済あるいはダウンロード状況が未済である場合に、該当受注者端末へ閲覧もしくはダウンロードを促す通知を送信すべき旨のメッセージを該当発注者端末に送信するものであることを特徴とする請求項４に記載の受発注処理手段の管理方法。
【請求項７】
前記受発注処理は、前記注文管理テーブルを参照し、ダウンロード状況が未済である場合に、商品発注情報の該当受注者端末へのダウンロードを実行するものであることを特徴とする請求項４に記載の受発注処理手段の管理方法。
【請求項８】
前記受発注処理は、前記注文管理テーブルを参照し、商品発注情報の閲覧状況が未済みあるいはダウンロード状況が未済である場合に、商品発注情報の該当受注者端末へのファックス送信を実行するものであることを特徴とする請求項４に記載の受発注処理手段の管理方法。
【請求項９】
前記発注者プロファイルテーブルおよび受注者プロファイルテーブルに基づく受発注者のプロファイルのうち資本金規模または取引履歴、前記取引合意テーブルに基づく注文取引合意事項のうち通信手段または納期回答もしくは納期確定の可否、前記注文管理テーブルに基づく商品発注情報のうち汎用品またはカスタム品もしくは発注数量もしくは発注金額を、受発注処理の手段を定める条件として前記取引ルールテーブルに照合することを特徴とする請求項１に記載の受発注処理手段の管理方法。
【請求項１０】
前記プロファイルのうち受発注者の資本金規模を認識し、発注者の資本金規模が受注者を所定規模上回っていると判定したならば、前記受注者を前記発注者の下請け業者であると認識し、前記商品発注情報が受注者端末へダウンロードされるべく前記受発注処理を実行することを特徴とする請求項９に記載の受発注処理手段の管理方法。
【請求項１１】
前記商品発注情報のうち発注商品が汎用品かカスタム品のどちらであるか認識し、当該発注商品がカスタム品であると判定したならば、前記受注者を前記発注者の下請け業者であると認識し、前記商品発注情報が受注者端末へダウンロードされるべく前記受発注処理を実行することを特徴とする請求項９に記載の受発注処理手段の管理方法。
【請求項１２】
商品の発注者および受注者の間での受発注処理の手段を管理する情報処置装置であって、
発注者毎にその属性データをとりまとめたプロファイルを格納した発注者プロファイルテーブルと、
受注者毎にその属性データをとりまとめたプロファイルを格納した受注者プロファイルテーブルと、
各受発注者間で予め取り決めた取引合意事項を記録した取引合意テーブルと、
発注者からの商品発注情報を格納する注文管理テーブルと、
受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めた取引ルールテーブルとにアクセス可能であって、
発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納する手段と、
前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定する手段と、
前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定する手段と、
前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行する手段と、
を含むことを特徴とする情報処理装置。
【請求項１３】
商品の発注者および受注者の間での受発注処理の手段を管理する方法を、
発注者毎にその属性データをとりまとめたプロファイルを格納した発注者プロファイルテーブルと、
受注者毎にその属性データをとりまとめたプロファイルを格納した受注者プロファイルテーブルと、
各受発注者間で予め取り決めた取引合意事項を記録した取引合意テーブルと、
発注者からの商品発注情報を格納する注文管理テーブルと、
受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めた取引ルールテーブルとにアクセス可能な情報処理装置に実行させるためのプログラムであって、
発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納するステップと、
前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定するステップと、
前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定するステップと、
前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行するステップと、
を含むことを特徴とする受発注処理手段の管理プログラム。
【請求項１４】
請求項１３に記載の受発注処理手段の管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、受発注処理手段の管理方法、情報処理装置、プログラム、および記録媒体に関する。
【０００２】
【従来の技術】
企業間の受発注や見積もりなど企業間の商取引をデジタル化し、ネットワークを通じてやりとりする仕組みとしてＥＤＩ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）があげられる。このＥＤＩは電子データ交換とも呼ばれる。一般にＥＤＩは専用線やＶＡＮ（付加価値通信網）などの専用ネットワークを利用し、業界ごとの専用プロトコルでやり取りする方式が多い。また一方で、今後はウェブＥＤＩ（Ｗｅｂ−ｅｌｅｃｔｒｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）へ移行することでＥＤＩのオープン化を進め、更にＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）などの導入で業界を超えた企業間取引が可能になるものとされる。
【０００３】
このようにネットワークを通じ受発注等のやりとりを企業間で行う状況で、例えば、提供する情報の属性、あるいは情報送受信者の指定にしたがってその提供方法を決定することにより、情報の提供方法を統一するという目的のもと、提供する情報の属性を表すキー情報および前記提供する情報の提供形態情報を蓄積した情報提供方法登録ファイルと、前記提供する情報の提供情報内容および属性を表すキー情報を蓄積した提供情報格納ファイルと、前記キー情報をもとに前記提供情報格納ファイルに格納した提供情報および情報提供方法登録ファイルに蓄積した提供方法を選択する情報提供方法選択装置からなり、前記情報提供方法選択装置は、前記情報提供方法登録ファイルに登録したキー情報と前記提供情報格納ファイルに格納したキー情報を参照してキー情報が一致する情報を抽出し抽出した情報をもとに情報提供方法を選択する提供方法選択部、および選択した提供方法に基づいて前記提供情報を利用者に送信する送信部を備えたことを特徴とする情報提供方法選択装置などが提案されている（特許文献１参照）。
【０００４】
また、受発注業務において、得意先からの発注に対して、顧客別重要度や顧客の発注パターン等を加味して在庫引当てを行い、リアルタイムに納期回答をできるようにする方法およびシステムを提供するといった目的のもと、顧客からの発注情報と、現在日時情報と、顧客重要度情報と、顧客別発注パターン情報と、受注予測情報と、予定在庫情報と、配送スケジュール情報とから在庫引当処理を実施する受発注業務支援方法であって、前記受発注業務支援方法は、入力装置から、発注情報を入力し、計時装置から、現在日時情報を取得し、記憶装置から、顧客重要度情報と、顧客別発注パターン情報と、受注予測情報と、予定在庫情報と、配送スケジュール情報を検索し、前記発注情報と、前記顧客重要度情報と、前記顧客別発注パターン情報と、前記受注予測情報と、前記予定在庫情報と、前記配送スケジュール情報とを用いて算定した、時間変化に伴って変化する発注確度に基づいて在庫引当処理を行い、出力装置から、前記引当処理結果を出力する、ことを特徴とする受発注業務支援方法などが提案されている（特許文献２参照）。
【０００５】
【特許文献１】
特開２００２−１２３４５７号公報
【０００６】
【特許文献２】
特開平１１−２１３０７７号公報
【０００７】
【発明が解決しようとする課題】
しかしながら従来手法には改善点が存在した。すなわち、受発注者間の取引ルールが固定的にしか定められておらず、受発注処理手段の管理が硬直的であった点である。したがって、受発注者の属性や個々の取引要件、或いは法的要件などに細かく応じて取引ルールを選定あるいは策定するなどといった処理は困難であった。勿論、受発注者間の取引形態について、契約の見直しや法改正、或いは企業規模の変化など様々な変化に基づいて柔軟に対応することも難しかったのである。
【０００８】
そこで本発明はこのような経緯に基づいてなされたもので、受発注者や取引案件の属性、法的要件等に応じて的確に取引ルールを生成可能とする受発注処理手段の管理方法、情報処理装置、プログラム、および記録媒体を提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成する本発明の受発注処理手段の管理方法は、商品の発注者および受注者の間での受発注処理の手段を情報処理装置により管理する方法であって、前記情報処理装置は、発注者毎にその属性データをとりまとめたプロファイルを格納した発注者プロファイルテーブルと、受注者毎にその属性データをとりまとめたプロファイルを格納した受注者プロファイルテーブルと、各受発注者間で予め取り決めた取引合意事項を記録した取引合意テーブルと、発注者からの商品発注情報を格納する注文管理テーブルと、受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めた取引ルールテーブルとにアクセス可能であり、発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納するステップと、前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定するステップと、前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定するステップと、前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行するステップと、を含むことを特徴とする。
【００１０】
また、商品の発注者および受注者の間での受発注処理の手段を管理する情報処置装置であって、前記情報処理装置は、発注者毎にその属性データをとりまとめたプロファイルを格納した発注者プロファイルテーブルと、受注者毎にその属性データをとりまとめたプロファイルを格納した受注者プロファイルテーブルと、各受発注者間で予め取り決めた取引合意事項を記録した取引合意テーブルと、発注者からの商品発注情報を格納する注文管理テーブルと、受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めた取引ルールテーブルとにアクセス可能であって、発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納する手段と、前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定する手段と、前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定する手段と、前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行する手段と、を含むことを特徴とする情報処理装置にかかる。
【００１１】
更に、商品の発注者および受注者の間での受発注処理の手段を管理する方法を、
発注者毎にその属性データをとりまとめたプロファイルを格納した発注者プロファイルテーブルと、受注者毎にその属性データをとりまとめたプロファイルを格納した受注者プロファイルテーブルと、各受発注者間で予め取り決めた取引合意事項を記録した取引合意テーブルと、発注者からの商品発注情報を格納する注文管理テーブルと、受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めた取引ルールテーブルとにアクセス可能な情報処理装置に実行させるためのプログラムであって、発注者端末より商品発注情報を受信して、これを注文管理テーブルに格納するステップと、前記商品発注情報に含まれる発注者および受注者の属性データに基づいて、前記発注者プロファイルテーブルおよび受注者プロファイルテーブルより、該当する受発注者を特定するステップと、前記特定した受発注者のプロファイルを、前記取引ルールテーブルに照合し、当該受発注者間に適用すべき受発注処理の手段を特定するステップと、前記特定した受発注処理の手段を採用して該当する受注者端末および発注者端末の間における受発注処理を実行するステップと、を含むことを特徴とする受発注処理手段の管理プログラムにかかる。このプログラムは、前記各ステップの動作を行うためのコードから構成されている。
【００１２】
また、前記受発注処理手段の管理プログラムを記録したコンピュータ読み取り可能な記録媒体にかかる。
その他、本願が開示する課題、及びその解決方法は、発明の実施の形態の欄及び図面により明らかにされる。
【００１３】
【発明の実施の形態】
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の取引管理システム１００（情報処理装置）を含むネットワーク構成を示す図である。本発明における取引管理システム１００（以下、システム）は、一例として例えばインターネット１２０を介して発注管理システム１３０（発注者端末）、および受注管理システム１５０（受注者端末）とデータ通信可能に結ばれたサーバを想定し、本発明の受発注処理手段の管理方法を実現するプログラムを例えばデータベース１０１に格納し、これを演算装置たるＣＰＵ１０２らがＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍｓ）に基づきメモリ１０３に適宜読み出すなどして受発注処理手段の管理方法を実行する。
【００１４】
例えば本実施形態において想定する環境としては、ウェブＥＤＩ（Ｗｅｂ−ｅｌｅｃｔｒｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ）が展開された企業間の受発注ネットワークとなる。このウェブＥＤＩは、ＷＷＷブラウザを使って受発注など企業間のやりとりを実現するシステムである。従来専用のネットワークと独自の通信プロトコル上で実現してきたＥＤＩ（電子データ交換）を、インターネットの標準プロトコルのＴＣＰ／ＩＰに乗せ換えて、オープンな環境からでも利用可能にしたものとも言える。
【００１５】
前記メモリ１０３には、受発注処理手段の管理方法を実現するための組み合わさって稼動する各アプリケーションプログラム用の領域が確保されている。そしてここのメモリ１０３における各領域に読み込まれたアプリケーションプログラムは、それぞれの役割を果たす機能ブロックと読み替えることもできる。ここでいう機能ブロックはアプリケーションプログラムを指す。そこで例えば、プロファイル検索部１０４、取引ルール決定部１０５、プロセス実行管理部１０６、送受信部１０７が含まれるものとできる（各機能ブロックの役割については後述する）。
【００１６】
他に、システム１００がネットワーク１２０を介して発注管理システム１３０（以下、発注システム）や受注管理システム１５０（以下、受注システム）と接続してデータ通信を実行するネットワークアダプタ１０８、各種データの出力を実行する出力インターフェイスとしてのディスプレイ１０９、操作者からの選択や指示を受け付ける入力インターフェイスとしてのマウス１１０およびキーボード１１１を備えている。
【００１７】
図２は本実施形態におけるテーブル群を示す図である。上記システム１００は、前記データベース１０１において、受発注処理手段の管理プログラムの他にも、テーブル群１１５を格納している。当該テーブル群１１５は、発注者プロファイルテーブル２００、受注者プロファイルテーブル２１０、取引合意テーブル２２０、取引ルールテーブル２３０、注文管理テーブル２４０、品目管理テーブル２５０および履歴テーブル２６０らから構成される。
【００１８】
発注者プロファイルテーブル２００は、発注者毎に、その資本金規模、売上高といった属性データをとりまとめたプロファイルを格納したものであり、一方、受注者プロファイルテーブル２１０は、受注者毎にその資本金規模、売上高といった属性データをとりまとめたプロファイルを格納したものである。
【００１９】
取引合意テーブル２２０は、各受発注者間で予め取り決めた取引合意事項を記録したものである。図の例で言えば、“発注者Ａ”と“受注者ａ”との間では、受発注処理手段たる通信手段を「Ｗｅｂ」とし、そこで処理する情報区分を、「確定注文」および「納期回答」としている。
【００２０】
取引ルールテーブル２３０は、受発注者のプロファイルと取引合意事項と商品発注情報とのうち、少なくとも受発注者のプロファイルに基づいて受発注処理の手段を定めたものである。図の例では、「発注者の資本金が３億円以上で受注者の資本金が３億円以下であり、かつ通信手段がＷｅｂである」か否かを判定する条件式をキーに、システム１００の受発注処理の動作を例えば、「ダウンロード機能」、「納期回答機能」、「Ｍａｉｌ通知機能」といった具合に関連づけしている。
【００２１】
注文管理テーブル２４０は、発注者からの商品発注情報を格納するものである。図の例では、“未処理”、“処理済み”、“警告”の注文状態に各注文を分類している。受注システム１５０からの閲覧が未済のものは“未処理”、受注システム１５０へのダウンロードが済みのものは“処理済”、閲覧はされたがダウンロードはなされていないものは“警告”、のいずれか注文状態となる。
【００２２】
また、前記注文状態毎に注文番号（図中では“注番”）を振り分けしている。この注文番号毎のレコードが商品発注情報と言える。そしてこの各注文毎の情報区分、注文内容（納期や数量など）の情報を関連づけている。また、前記取引ルールテーブル２３０に基づいてシステム１００が受発注者間の関係を判定し、受注者が発注者の下請けであると判定した場合に、当該下請けであるか否かのフラグを注文毎に紐付けている。
【００２３】
品目管理テーブル２５０は、例えば前記注文管理テーブル２４０に付帯するものであり、発注者毎の注文に含まれる商品について、その品目、汎用品かカスタム品か、発注金額、納期回答の可否、所要計画の可否、予約注文の可否、買掛金額などが格納される。
【００２４】
履歴テーブル２６０は、前記注文管理テーブル２４０における各商品発注情報について、受注システム１５０へのダウンロードの済んだものについてそのダウンロード履歴を管理するものである。図の例では、各注文の受発注者の組合せ毎に、情報区分とダウンロード日時を関連づけたデータ構造となっている。
【００２５】
上記のようなシステム１００に対し、インターネットなどのネットワーク１２０を通じて結ばれるのが前記発注システム１３０である。この発注システム１３０は、演算装置たるＣＰＵ１３１、当該ＣＰＵ１３１が演算時に使用するメモリ１３２、ネットワーク１２０らを介したシステム１００とのデータ通信を行うネットワークアダプタ１３５、発注者側で管理する注文情報などを格納するデータベース１３６を備える。勿論他に、ディスプレイ１３７、マウス１３８、およびキーボード１３９を備える。前記メモリ１３２は、機能ブロックとして電子データの送受信処理を担う送受信部１３３、商品の発注情報を生成する取引情報作成部１３４を含む。
【００２６】
また同様に、前記システム１００に対し、インターネットなどのネットワーク１２０を通じて結ばれるのが前記受注システム１５０である。この受注システム１５０は、演算装置たるＣＰＵ１５１、当該ＣＰＵ１５１が演算時に使用するメモリ１５２、ネットワーク１２０らを介したシステム１００とのデータ通信を行うネットワークアダプタ１５５、受注者側で管理する受注情報（注文情報）などを格納するデータベース１５６を備える。勿論他に、ディスプレイ１５７、マウス１５８、およびキーボード１５９を備える。前記メモリ１３２は、機能ブロックとして電子データの送受信処理を担う送受信部１５３、商品発注に対する回答を生成する取引情報回答部１５４を含む。
【００２７】
なお、前記システム１００は、ファイヤウォールサーバとして外部からの不正進入を抑止したり、ＷＷＷサーバとして機能可能なものでもあるし、データ通信相手とのコミュニケーションを図るメールサーバーとしても機能可能なものとできる。
【００２８】
また、前記テーブル群１１５を構成する、発注者プロファイルテーブル２００、受注者プロファイルテーブル２１０、取引合意テーブル２２０、取引ルールテーブル２３０、注文管理テーブル２４０、品目管理テーブル２５０および履歴テーブル２６０らは、システム１００に一体に備わっている例だけでなく、別の装置に付帯しながらもネットワークを介して一体に稼動するとしてもよい。
【００２９】
また、システム１００、発注システム１３０、受注システム１５０らをそれぞれつなぐネットワーク１２０に関しては、専用回線やインターネットの他に、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＬＡＮ、電灯線ネットワーク、無線ネットワーク、公衆回線網、携帯電話網、ＥＤＩ専用回線など様々なネットワークを採用することも出来る。また、ＶＰＮなど仮想専用ネットワーク技術を用いれば、インターネットを採用した際にセキュリティ性を高めた通信が確立され好適である。
【００３０】
図３は本実施形態における受発注処理手段の管理方法の概要を示す図であり、図４は受発注処理手段の管理方法におけるメインフロー図である。以下、本発明の受発注処理手段の管理方法の実際手順について説明を行う。なお、以下で説明する受発注処理手段の管理方法に対応する各種動作は、システム１００に関する動作についてはデータベース１０１が備えるプログラムによって実現される。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００３１】
例えばあるメーカーが自社製品を構成する部品について他社に発注を行うとする。発注者たるメーカーは、発注システム１３０よりネットワーク１２０を介して取引情報３００（商品発注情報）をシステム１００に送信する（ｓ１０００）。なお、以下システム１００はＷｅｂ上でサービスを提供するＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）をイメージするとし、サービスプロバイダ１００と称する。サービスプロバイダ１００は、前記送受信部１０７を介しこれを受信する（ｓ１００１）。そして受信した取引情報３００をデータベース１０１における注文管理テーブル２４０に格納する（ｓ１００２）。
【００３２】
続いてサービスプロバイダ１００は、前記取引情報３００に含まれるメーカー（発注者）および受注者の例えばＩＤ（属性データ）に基づいて、前記発注者プロファイルテーブル２００および受注者プロファイルテーブル２１０より、該当する受発注者を特定する（ｓ１００３）。これは前記プロファイル検索部１０４が担うものとできる。
【００３３】
前記特定した受発注者のプロファイルを、前記取引ルールテーブル２３０に照合し、当該受発注者間に適用すべき取引ルール（つまり受発注処理の手段）を特定する（ｓ１００４）。これは取引ルール決定部１０５が担うものとできる。例として、発注者の資本金が３億円以上で受注者の資本金が３億円以下であった場合、前記受注者は発注者の下請け関係にあると判断し、取引情報データの受注者システム１５０側でのダウンロードを義務づける下請法等に対応した処理を選択することとなる。また、両者の間で予め定められている取引合意を前記取引合意テーブル２２０より抽出し、両者間の取引手段、ここでいう通信手段を認識する。例えばそれがＷｅｂであるとなれば、ＷｅｂベースでのＨｔｔｐリクエスト／レスポンスの通信を採用する訳である。
【００３４】
受発注処理の手段を選択するということは、取引情報３００など受発注に関わるデータをどのようにやりとりするのかを選択することであり、本実施形態においては、受発注者のシステム１３０、１５０間における通信経路（ネットワークの種類）、通信装置（例：コンピュータ、電話、ファックス等）、および通信プロトコルの少なくともいずれかが選択肢となりうる。
【００３５】
また、前記通信プロトコルには、例えばＯＳＩ基本参照モデル（ＯＳＩ  Ｂａｓｉｃ  Ｒｅｆｅｒｅｎｃｅ  Ｍｏｄｅｌ）の各階層のプロトコルが想定できる。階層には、最下位の物理層、第２層のデータリンク層、第３層のネットワーク層、第４層のトランスポート層、第５層のセッション層、第６層のプレゼンテーション層、最上位たる第７層のアプリケーション層がある。例えばどの階層ではどのようなプロトコルに従うのかといったことを選択肢として設定しておくことも可能である。
【００３６】
他方、発注商品が汎用品かカスタム品のどちらであるか認識し、当該発注商品がカスタム品であると判定したならば、前記受注者を前記メーカーの下請け業者であると認識することも出来る。この場合、前記同様に前記取引情報が受注システム１５０へダウンロードされるべく受発注処理を実行することとなる。
【００３７】
つまり前記サービスプロバイダ１００は、受発注者のプロファイルテーブル２００、２１０に基づく受発注者のプロファイルのうち資本金規模または取引履歴、取引合意テーブル２２０に基づく通信手段または納期回答もしくは納期確定の可否、注文管理テーブル２４０に基づく取引情報（商品発注情報）のうち汎用品またはカスタム品もしくは発注数量もしくは発注金額、の各条件を前記取引ルールテーブル２３０において照合し、取引ルールを定めるのである。
【００３８】
取引ルールが上記の如く定められ、これを選択したならば（ｓ１００５）、発注者と受注者の組合せたる取引グループ毎にこれを適用していく（この適用の処理については後述する）。つまり、受発注処理の手段を採用して該当する受注システム１５０および発注システム１３０の間における受発注処理を実行するのである（ｓ１００６）。これは前記プロセス実行管理部１０６が担うものとできる。
【００３９】
例えば取引グループ１の受注システム１５０に対しては、所定の取引情報３００をダウンロードさせるべく通知または指令を行う、といった対応処理を行う。該当する受注システム１５０ではこれを受けて取引情報３００のダウンロード処理（図中、“受注者処理”）を実行する（ｓ１００７）。他方、発注システム１３０に対しては、ダウンロードを促す通知を受注システム１５０に発信するよう通知を行うといった対応処理を行う。発注システム１３０ではこれを受けて、受注システム１５０に対し取引情報３００のダウンロードを行うよう通知（図中、“発注者処理”）を行う（ｓ１００８）。なお、このような処理のバリエーションについては後述することとする。なお、図３においては、前記した対応処理を「プロセス」、そしてこれの管理を「プロセス実行管理」として示している。
【００４０】
以上、本実施形態における受発注処理手段の管理方法の主たる処理の流れを示した。受発注処理手段の管理方法を実行する情報処理装置としての前記サービスプロバイダ１００は、受発注者の間にあって公正な仲介者の役割を担うと言える。
【００４１】
図５は受発注処理手段の管理方法における下請法対応フロー図である。上記したメインフローの他に、受発注者間に下請けの関係がある場合には発注書などの前記取引情報３００は下請けたる受注者の受注システム１５０にダウンロードされなくてはならないなどの事柄を規定した下請法に対応することも出来る。この場合、発注システム１３０よりシステム１００に対しての注文データ（取引情報の一種）の送信（ｓ２０００）から、取引ルールの決定（ｓ２００４）までのステップは上記メインフローの場合と同様である。
【００４２】
取引ルールを決定した際に、当該ルールが下請法を対象としたものであった場合（ｓ２００５：ＹＥＳ）、例えばサービスプロバイダ１００から受注システム１５０に対して注文データをダウンロードさせるべく対応処理を実行する（ｓ２００７）。そして、これを受けた受注システム１５０は、例えばサービスプロバイダ１００からの注文データのダウンロードを受け入れるといった処理を実行する（ｓ２００８）。勿論、これに対応して発注システム１３０でも適宜な処理を実行することもできる（ｓ２００９）。
【００４３】
一方、取引ルールを決定した際に、当該ルールが下請法を対象としたものでなかった場合（ｓ２００５：ＮＯ）、例えば通常の取引形態に基づく対応処理を実行する（ｓ２００６）。そして、これを受けた受注システム１５０および発注システム１３０も、該当処理を実行する（ｓ２０１０。ｓ２０１１）。
【００４４】
以下、上記下請法対応のフローにて述べた各ステップについて詳細な手順を逐一説明することとする。図６は注文データ受信処理の処理流れを示すフロー図である。前記したように発注システム１３０から注文データ（取引情報）を受信したサービスプロバイダ１００は、受信した注文データをデータベース１０１における例えば前記注文管理テーブル２４０に格納する（ｓ６０００、ｓ６００１）。そして当該注文データに含まれる受発注者のＩＤなどから該当プロファイルを発注者プロファイルテーブル２００および受注者プロファイルテーブル２１０から取得し適宜メモリーする（ｓ６００２）。
【００４５】
そしてのこのプロファイルに基づいて、受発注者の資本金規模を判定する（ｓ６００３）。例えば発注者の資本金が３億円を上回り、かつ受注者の資本金が３億円を下回っている場合（ｓ６００３：ＹＥＳ）、注文管理テーブル２４０における前記注文データに関して下請Ｆｌａｇ（下請フラグ）を“ＯＮ”にし（ｓ６００４）、注文データ受信から登録に至る処理を完了する。他方、発注者の資本金が３億円を上回り、かつ受注者の資本金が３億円を下回っているとの判定が下されない場合（ｓ６００３：ＮＯ）、前記下請Ｆｌａｇを“ＯＮ”にする処理は実行せず、つまり同Ｆｌａｇを“ＯＦＦ”のままとし処理を完了する。
【００４６】
図７は受注者による注文データ参照を受けた処理流れを示すフロー図である。受注システム１５０から注文データ閲覧のリクエストを受信したサービスプロバイダ１００は、該当受注者に対して受け付けている発注者からの注文データを、例えば受注者ＩＤなどをキーに前記注文管理テーブル２４０において検索する（ｓ７０００）。この検索により抽出された注文データについて、既に上記したような下請法に対応した処理が必要なものか否か、下請Ｆｌａｇの“ＯＮ”、“ＯＦＦ”を認識する（ｓ７００１、ｓ７００２）。
【００４７】
前記注文データの下請Ｆｌａｇが“ＯＮ”、つまり下請法に対応した処理をすべきことを認識した場合（ｓ７００２：ＹＥＳ）、当該注文データのダウンロードを促すメッセージを受注システム１５０に送信する（ｓ７００３）。この時、このメッセージを受信した受注システム１５０のディスプレイ１５７にて表示されることになる画面データを図８に例示する。
【００４８】
画面データ８００に示すように、受注者が受けている注文データを、その処理状態にわけて列挙している。例示した処理状態は、受注システム１５０が注文データをダウンロード済みである“済み”、受注システム１５０から閲覧済だがダウンロードはしていない場合の“警告”、そして前記閲覧もダウンロードもなされていない“未処理”の状態となっている。各注文データは、注文番号をキーにして、品名、単価、数量、納期といった項目が関連づけされている。そして、前記したような下請法に対応した処理をなすべき注文データについては、“注文番号６７８９０は下請対象の注文です”、“注文を承諾する場合は注文データをダウンロードして下さい”といったメッセージが表示される。また、それにあわせてダウンロードボタン８０１も示される。
【００４９】
上記のようなダウンロードを促すメッセージに対して、受注システム側で該当注文データのダウンロード処理を実行したならば（ｓ７００４：ＹＥＳ）、履歴テーブル２６０において当該ステップｓ７００４での処理内容を追加する（ｓ７００７）。また前記注文管理テーブルにおける“注文状態”を“処理済み”と更新する（ｓ７００８）。この時、図１４に示すごとく、ダウンロード完了の画面１４００が受注システム１５０に送信される。なお、この画面１４００において“ＯＫ”ボタン１４０１が押下された事象をサービスプロバイダ１００が認識したことをもって、ダウンロードの完了を確定するものと出来る。この事象が契機となって前記の前記履歴テーブル２６０へのダウンロード事象の格納はなされることとなる。
【００５０】
他方、前記メッセージの通知にも関わらずダウンロードがなされなかった場合（ｓ７００４：ＮＯ）、当該メッセージ通知を所定回数リトライし（ｓ７００５）、それでもダウンロードされなかった場合、前記“注文状態”を“警告”とする（ｓ７００６）。以上のような処理を注文データ毎に実行し、該当受注者に関する全ての注文データについて完了したならば、当該フローを終了する。
【００５１】
一方、発注者の側でも自分が発した注文がどのような状態にあるのか確認する場合がある。図９は発注者による注文状態の確認処理を受けた処理流れを示すフロー図であり、図１０は注文状態の確認画面例（発注者側）を示す図である。発注者システム１３０から注文データの状態確認のリクエストを受け付けたサービスプロバイダ１００は、該当発注者のＩＤなどをキーにして前記注文管理テーブル２４０において注文データを検索し、取得する（ｓ９０００）。
【００５２】
そこで取得した注文データについて、前記注文状態のカラムをチェックし、“警告”状態の注文データがあるか判定する（ｓ９００１）。そこで該当注文データがある場合（ｓ９００１：ＹＥＳ）、受注システム１５０にダウンロードを促すべきであるとのメッセージを送信する（ｓ９００２）。他方、前記“警告”状態の注文データがなければ処理は終了する。前記ダウンロードを促すべきであるとのメッセージは、図１０の画面１０００に示す如き形態をとることが出来る。
【００５３】
この画面１０００では、発注者が発している注文データを、その処理状態にわけて列挙している。例示した処理状態は、受注システム１５０が注文データをダウンロード済みである“済み”、受注システム１５０から閲覧済だがダウンロードはしていない場合の“警告”、そして前記閲覧もダウンロードもなされていない“未処理”の状態となっている。各注文データは、注文番号をキーにして、品名、単価、数量、納期といった項目が関連づけされている。そして、前記したような下請法に対応した処理をなすべきであるが、未だにダウンロードがなされていない“警告”状態の注文データについては、“注文番号６７８９０は下請対象の注文ですが、取引先は注文データをダウンロードしていません。確認して下さい”、といったメッセージが表示される。
【００５４】
なお、上記では、“警告”状態の注文データに着目して、ダウンロード処理の促進をはかる処理をとる例を示したが、“未処理”状態の注文データについて、これの閲覧およびそれに続くダウンロードを促進すべく処理を行うとしてもよい。
【００５５】
受発注者側のリクエストに応えて注文データの状態を確認し、当該注文状態に応じた処理を上記の如くなすのではなく、例えばサービスプロバイダ１００が一定時間毎に前記注文管理テーブル２４０をチェックし、“警告”状態の注文データを検索することも可能である。
【００５６】
図１１は警告状態の注文データについて受発注者に通知する処理流れを示すフロー図である。サービスプロバイダ１００は、発注者毎あるいは受注者毎に、前記注文管理テーブル２４０での注文データの検索を例えば一日ごとに行う（ｓ１１００）。そして検索された注文データに、注文状態が“警告”であるものが含まれるか判定する（ｓ１１０１、ｓ１１０２）。この判定の結果、警告状態の注文データがなければ（ｓ１１０２：ＮＯ）、処理は終了する。一方、警告状態の注文データが含まれていた場合（ｓ１１０２：ＹＥＳ）、これを受発注者側に通知するリストに追加する（ｓ１１０３）。このような処理を該当受発注者に関する全ての注文データについて行ったならば（ｓ１１０１：ＹＥＳ）、前記リストを該当発注者の発注システム１３０或いは受注者の受注システム１５０に通知するとともに、履歴テーブル２６０に処理内容を反映させ（ｓ１１０４、ｓ１１０５）、処理を終了する。
【００５７】
上記とは別に、前記注文状態が“警告”、つまりダウンロードが未済である注文データを、受注システム１５０からのリクエストとは関わりなく、サービスプロバイダ１００から該当受注システム１５０へ送信処理することも可能である。図１２は受注者への注文データの送信処理の流れを示すフロー図である。
【００５８】
サービスプロバイダ１００は、所定の受注者宛の注文データを注文管理テーブル２４０において検索する（ｓ１２００）。そして、検索された注文データが下請法の対応対象となるものであるか否か判定する（ｓ１２０１、ｓ１２０２）。下請法の対応対象とならない注文データしかなかったならば（ｓ１２０２：ＮＯ）、処理は終了する。他方、下請法の対応対象となる注文データが存在した場合（ｓ１２０２：ＹＥＳ）、該当注文データをＥＤＩ等で送信する旨を受注システム１５０側に通知する（ｓ１２０３）。
【００５９】
そして受注システム１５０が受信可能であるならば、注文データを送信し（ｓ１２０４）、履歴テーブル２６０に処理内容を反映させるとともに、注文管理テーブル２４０における注文状態カラムを“処理済”へと更新する（ｓ１２０５、１２０６）。このような処理を前記受注者宛の全注文データについて実行したならば（ｓ１２０１：ＹＥＳ）、処理は終了する。なお、注文データの送信手段としては、前記ＥＤＩの他に、ファックス送信を採用するとしてもよい。
【００６０】
図１３は回答確認の送信を促す処理の流れを示すフロー図である。他に、発注に対する受注回答着目した処理を想定することもできる。この場合、サービスプロバイダ１００は、受注者宛の注文データを上記同様に検索し（ｓ１３００）、それが下請法の対応対象なのか判定する（ｓ１３０２）。下請法の対応対象でなければ（ｓ１３０２：ＮＯ）、例えば注文管理テーブル２４０に設けた回答状態カラム（図示しない）を“処理済”として（ｓ１３０６）処理を終了する。
【００６１】
一方、下請法の対応対象であった場合（ｓ１３０２：ＹＥＳ）、注文データに対する受注回答を促すメッセージを受注システム１５０に送信する（ｓ１３０３）。このメッセージに応じて受注システム１５０から発注システム１３０に対して回答がなされたならば（ｓ１３０４：ＹＥＳ）、履歴テーブル２６０において処理内容を反映させるとともに前記回答状態を“処理済”とし処理を終了する（ｓ１３０６、ｓ１３０７）。他方、回答がなされなかった場合、回答状態を“警告”とする（ｓ１３０５）。このような処理を受注者宛の全注文データについて行ったならば（ｓ１３０１：ＹＥＳ）、フローを終了する。
【００６２】
本発明の受発注処理手段の管理方法等によれば、受発注者の属性や個々の取引要件、或いは法的な要件などに細かく応じて取引ルールを選定あるいは策定することが可能となる。また、受発注者間の取引形態について、契約の見直しや法改正、或いは企業規模の変化など様々な変化に基づいて柔軟に対応するもできる。つまり、受発注者や取引案件の属性等に応じて的確に取引ルールを生成可能とする受発注処理手段の管理方法、情報処理装置、プログラム、および記録媒体を提供可能とするのである。
以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００６３】
【発明の効果】
本発明によれば、受発注者や取引案件の属性、法的要件等に応じて的確に取引ルールを生成可能とする。
【図面の簡単な説明】
【図１】本実施形態の取引管理システム（情報処理装置）を含むネットワーク構成を示す図である。
【図２】本実施形態におけるテーブル群を示す図である。
【図３】本実施形態における受発注処理手段の管理方法の概要を示す図である。
【図４】受発注処理手段の管理方法におけるメインフロー図である。
【図５】受発注処理手段の管理方法における下請法対応フロー図である。
【図６】注文データ受信処理の処理流れを示すフロー図である。
【図７】受注者による注文データ参照を受けた処理流れを示すフロー図である。
【図８】注文データの閲覧画面例（受注者側）を示す図である。
【図９】発注者による注文状態の確認処理を受けた処理流れを示すフロー図である。
【図１０】注文状態の確認画面例（発注者側）を示す図である。
【図１１】警告状態の注文データについて受発注者に通知する処理流れを示すフロー図である。
【図１２】受注者への注文データの送信処理の流れを示すフロー図である。
【図１３】回答確認の送信を促す処理の流れを示すフロー図である。
【図１４】ダウンロード完了画面例を示す図である。
【符号の説明】
１００  情報処理装置、取引管理システム、サービスプロバイダ
１０１  データベース
１０２  ＣＰＵ
１０３  メモリ
１０４  プロファイル検索部
１０５  取引ルール決定部
１０６  プロセス実行管理部
１０７  送受信部
１０８  ネットワークアダプタ
１０９  ディスプレイ
１１０  マウス
１１１  キーボード
１１５  テーブル群
１２０  ネットワーク、インターネット
１３０  受注管理システム、発注者端末
１５０  受注管理システム、受注者端末
２００  発注者プロファイルテーブル
２１０  受注者プロファイルテーブル
２２０  取引合意テーブル
２３０  取引ルールテーブル
２４０  注文管理テーブル
２５０  品目管理テーブル
２６０  履歴テーブル
【図１】
2004310145.tif 000003
【図２】
2004310145.tif 000004
【図３】
2004310145.tif 000005
【図４】
2004310145.tif 000006
【図５】
2004310145.tif 000007
【図６】
2004310145.tif 000008
【図７】
2004310145.tif 000009
【図８】
2004310145.tif 000010
【図９】
2004310145.tif 000011
【図１０】
2004310145.tif 000012
【図１１】
2004310145.tif 000013
【図１２】
2004310145.tif 000014
【図１３】
2004310145.tif 000015
【図１４】
2004310145.tif 000016