【手続補正書】
【提出日】平成15年7月16日(2003.7.16)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の名称】調達支援システム及び方法
【特許請求の範囲】
【請求項１】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスの自動見積りをする見積手段を有する調達支援システムにおいて、
複数の発注元商取引団体および複数の発注先商取引団体とネット網を介して通信を行い、発注元商取引団体からの商品・サービスに関する見積依頼情報を受信し、発注先商取引団体へ見積依頼情報を送信した後に該見積依頼情報に対応する見積情報を受信し、さらに該見積情報を該発注元商取引団体へ送信する通信手段と、
前記発注元商取引団体が所望する条件で所望する商品・サービスを提供するために、前記発注先商取引団体が提供できる前記商品・サービスに関する情報を商品情報として記憶する商品情報データベースと、
前記商品・サービスを提供できる前記発注先商取引団体に関する情報を複数記憶する発注先情報データベースと、
前記通信手段によって前記発注元商取引団体から前記見積依頼情報を受信すると、受信した前記見積依頼情報に基づいて前記商品情報データベースを検索し、該当する前記商品情報があった場合には、前記商品情報データベースから抽出した前記商品情報を前記発注元商取引団体に前記通信手段を用いて送信する商品情報検索手段と、
前記商品情報検索手段が前記商品情報を検索できなかった場合には、前記発注先情報データベースから前記見積依頼情報に示す商品・サービスを提供できる前記発注先商取引団体を１又は複数、選択する発注先選択手段と、
前記発注先選択手段が選択した前記発注先商取引団体に対して前記見積依頼情報を前記通信手段を用いて送信し、送信した前記見積依頼情報に対応する見積情報を前記発注先商取引団体から前記通信手段を用いて受信すると、受信した見積情報から、予め決められた発注先決定条件で特定の前記発注先商取引団体を決定し、決定した前記発注先商取引団体から受信した前記見積情報を前記発注元商取引団体にとって最適な見積情報に決定し、決定した見積情報を見積情報データベースに記憶すると共に前記見積依頼情報を送信した前記発注元商取引団体に前記通信手段を用いて送信する見積決定手段とから構成されたことを特徴とする調達支援システム。
【請求項２】前記見積決定手段は、前記予め決められた発注先決定条件として前記発注元商取引団体の過去の購入履歴を用いて最適な見積情報を決定し、条件に合致しなかった場合には、見積価格、納期、品質等に対して所定のウエイトを付けて生成された条件を用いることを特徴とする請求項１記載の調達支援システム。
【請求項３】あらかじめ前記発注元商取引団体に関する情報を顧客に関する情報として顧客識別コードともに記憶する顧客情報データベースと、
前記発注元商取引団体から発注情報を顧客識別コードとともに前記通信手段を用いて受信すると、受信した顧客識別コードに基づいて前記顧客情報データベースから顧客に関する情報を取得し、前記見積情報データベースに該当する前記見積情報があった場合には該見積情報と受信した発注情報に基づいて、或いは該当する前記見積情報がなかった場合には前記商品情報データベースに記憶される前記商品情報と受信した発注情報に基づいて受注情報を作成し、作成した該受注情報を受注情報データベースに記憶すると共に発注情報として前記発注先商取引団体に前記通信手段を用いて送信する発注処理手段をさらに備えることを特徴とする請求項１または２に記載の調達支援システム。
【請求項４】前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を仕入情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記仕入情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段をさらに備えることを特徴とする請求項３に記載の調達支援システム。
【請求項５】前記請求処理手段は、前記第１の突き合せ機能によって前記仕入情報と一致しなかった検収済みの受注情報について、検収済みの前記受注情報があって前記仕入情報がなかった場合には入力誤りを示す情報を、未検収の前記受注情報で前記仕入情報がある場合には前記発注元商取引団体に対して検収依頼の対象とする検収依頼対象を示す情報を、未検収の前記受注情報で前記仕入情報がない場合には調査対象を示す情報を、それぞれ出力することを特徴とする請求項４に記載の調達支援システム。
【請求項６】前記顧客情報データベースには、前記顧客識別コードに加えて、顧客の部門コードや発注商品・サービスに対応した勘定科目が記憶され、前記発注元商取引団体からの前記発注情報を受けると、前記発注処理手段は前記顧客情報データベースより発注情報に対応する発注商品・サービスの勘定科目を抽出して仕分け情報を作成し、該作成された仕分け情報を前記発注情報に付与して発注先商取引団体へ発注し、かつ前記請求処理手段が前記請求情報を前記発注元商取引団体へ送付する際に、該仕分け情報を前記請求情報に付して前記発注元商取引団体へ送付することを特徴とする請求項４または５に記載の調達支援システム。
【請求項７】受領した商品・サービスに関する受領情報を記憶した受領情報データベースが前記発注元商取引団体に設けられており、該受領情報データベースからの前記受領情報と前記請求処理手段からの請求情報とを突き合わせる第２の突き合せ機能をさらに有し、両者が一致する場合は前記発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする請求項４〜６のいずれかに記載の調達支援システム。
【請求項８】前記請求処理手段にさらに、前記発注先商取引団体から受取った請求情報である発注先請求情報と、前記発注元商取引団体へ送付した請求情報とを突き合わせる第３の突き合せ機能をさらに有し、両者が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする請求項４〜７のいずれかに記載の調達支援システム。
【請求項９】前記発注先商取引団体に対する経理処理における支払金額は、前記発注元商取引団体へ送信した請求情報の請求金額と同額、または前記支払金額より請求金額の方が小額であり、該調達支援システムの利用料として両者の差額データが前記請求処理手段に蓄積されることを特徴とする請求項８記載の調達支援システム。
【請求項１０】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を仕入情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記仕入情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信するように構成された請求処理手段とを備えたことを特徴とする調達支援システム。
【請求項１１】前記請求処理手段は、前記第１の突き合せ機能によって前記仕入情報と一致しなかった検収済みの受注情報について、検収済みの前記受注情報があって前記納品情報がなかった場合には入力誤りを示す情報を、未検収の前記受注情報で前記納品情報がある場合には前記発注元商取引団体に対して検収依頼の対象とする検収依頼対象を示す情報を、未検収の前記受注情報で前記納品情報がない場合には調査対象を示す情報を、それぞれ出力することを特徴とする請求項１０に記載の調達支援システム。
【請求項１２】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記仕入情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段と、
受領した商品・サービスに関する受領情報を記憶した受領情報データベースが前記発注元商取引団体に設けられており、該受領情報データベースからの前記受領情報と前記請求処理手段からの請求情報とを突き合わせる第２の突き合せ機能をさらに有し、両者が一致する場合は前記発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする調達支援システム。
【請求項１３】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記納品情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段とを備え、
前記請求処理手段は、前記発注先商取引団体から受取った請求情報である発注先請求情報と、前記発注元商取引団体へ送付した請求情報とを突き合わせる第３の突き合せ機能をさらに有し、両者が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成することを特徴とする調達支援システム。
【請求項１４】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記納品情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段と、
受領した商品・サービスに関する受領情報を記憶した受領情報データベースが前記発注元商取引団体に設けられており、該受領情報データベースからの前記受領情報と前記請求処理手段からの請求情報とを突き合わせる第２の突き合せ機能をさらに有し、両者が一致する場合は前記発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成し、前記請求処理手段にさらに、前記発注先商取引団体から受取った請求情報である発注先請求情報と、前記発注元商取引団体へ送付した請求情報とを突き合わせる第３の突き合せ機能をさらに有し、両者が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする調達支援システム。
【請求項１５】発注元商取引団体に設けられ、実際に受領した商品・サービスと受信した請求情報を突き合せるための突き合せシステムを含む調達支援システムであって、該調達支援システムは発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行い、前記発注元商取引団体の突き合せシステムが、
前記発注情報に基づく前記発注先商取引団体からの前記商品・サービスの納品を受け付けた前記発注元商取引団体における検収を受領情報として記憶した発注元商取引団体側の受領情報データベースと、
前記調達支援システムから、前記発注元商取引団体の前記受領情報に基づく請求情報を受信すると、前記受領情報データベースに記憶する受領情報を突き合わせ、該請求情報と前記受領情報が一致することを確認する第２の突き合せ機能を有し、
該第２の突き合せ機能によって該請求情報と前記受領情報が一致する場合は該発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする突き合せシステムを含む調達支援システム。
【請求項１６】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記請求情報を記憶した請求情報データベースと、
前記発注先商取引団体から、前記発注元商取引団体への前記商品・サービスの納入に応じた代金を請求する発注先請求情報を受信すると、前記請求情報データベースに記憶する前記請求情報と突き合せ、該請求情報と前記発注先請求情報が一致することを確認する第３の突き合せ機能を有し、
該第３の突き合せ機能によって該請求情報と前記受領情報が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする調達支援システム。
【請求項１７】発注元商取引団体と発注先商取引団体の間のネット網を介した通信手段を通して、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスの自動見積りをする見積手段を有する調達支援方法において、
前記発注元商取引団体が所望する条件で所望する商品・サービスを提供するために、前記発注先商取引団体が提供できる前記商品・サービスに関する情報を商品情報として商品情報データベースに予め記憶するステップと、
前記商品・サービスを提供できる前記発注先商取引団体に関する情報を複数発注先情報データベースに予め記憶するステップと、
前記通信手段によって前記発注元商取引団体から見積依頼情報を受信すると、受信した前記見積依頼情報に基づいて前記商品情報データベースを検索し、該当する前記商品情報があった場合には、前記商品情報データベースから抽出した前記商品情報を前記発注元商取引団体に前記通信手段を用いて送信するステップと、
前記商品情報を検索できなかった場合には、前記発注先情報データベースから前記見積依頼情報に示す商品・サービスを提供できる前記発注先商取引団体を１又は複数、選択するステップと、
前記選択した発注先商取引団体に対して前記見積依頼情報を前記ネット網を介して送信し、送信した前記見積依頼情報に対応する見積情報を前記発注先商取引団体から前記通信手段を用いて受信すると、受信した見積情報から、予め決められた発注先決定条件で特定の前記発注先商取引団体を決定し、決定した前記発注先商取引団体から受信した前記見積情報を前記発注元商取引団体にとって最適な見積情報に決定し、決定した見積情報を見積情報データベースに記憶すると共に前記見積依頼情報を送信した前記発注元商取引団体に前記通信手段を介して送信するステップとから構成されたことを特徴とする調達支援方法。
【請求項１８】前記発注元商取引団体に関する情報を顧客に関する情報として顧客識別コードともに顧客情報データベースに予め記憶するステップと、
前記見積情報を前記発注元商取引団体へ送信した後に、前記発注元商取引団体から発注情報を顧客識別コードとともに前記通信手段を用いて受信すると、受信した顧客識別コードに基づいて前記顧客情報データベースから顧客に関する情報を取得し、前記見積情報データベースに該当する前記見積情報があった場合には該見積情報と受信した発注情報に基づいて、或いは該当する前記見積情報がなかった場合には前記商品情報データベースに記憶される前記商品情報と受信した発注情報に基づいて受注情報を作成するステップと、
作成した該受注情報を受注情報データベースに記憶すると共に発注情報として前記発注先商取引団体に前記通信手段を用いて送信するするステップとから構成されたことを特徴とする請求項１７に記載の調達支援方法。
【請求項１９】前記受注情報を作成するステップには、前記発注元商取引団体からの前記発注情報を受けると、前記顧客情報データベースより発注情報に対応する発注商品・サービスの予め記憶された顧客の部門コードや発注商品・サービスに対応した勘定科目を抽出して仕分け情報を作成し、該作成された仕分け情報を前記発注情報に付与するステップを含み、さらに前記発注商品・サービスに関する請求情報を前記発注元商取引団体へ送付する際に、該仕分け情報を前記請求情報に付して前記発注元商取引団体へ送付するステップから構成されたことを特徴とする請求項１８に記載の調達支援方法。
【請求項２０】発注元商取引団体と発注先商取引団体の間のネット網を介した通信手段を通して、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援方法において、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行するステップと、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶するステップと、
前記納品情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せステップを有し、該第１の突き合せステップによって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信するステップから構成されたことを特徴とする調達支援方法。
【請求項２１】前記受注情報について請求情報を作成するステップには、前記第１の突き合せステップによって前記仕入情報と一致しなかった検収済みの受注情報について、検収済みの前記受注情報があって前記検収情報がなかった場合には入力誤りを示す情報を、未検収の前記受注情報で前記検収情報がある場合には前記発注元商取引団体に対して検収依頼の対象とする検収依頼対象を示す情報を、未検収の前記受注情報で前記検収情報がない場合には調査対象を示す情報を、それぞれ出力することを特徴とする請求項２０に記載の調達支援方法。
【請求項２２】発注元商取引団体と発注先商取引団体の間のネット網を介した通信手段を通して、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援方法において、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行するステップと、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶するステップと、
前記納品情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せステップを有し、該第１の突き合せステップによって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信するステップと、
受領した商品・サービスに関する受領情報を記憶した受領情報データベースが前記発注元商取引団体に設けられており、該受領情報データベースからの前記受領情報と前記請求情報とを突き合わせる第２の突き合せステップをさらに有し、両者が一致する場合は前記発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するステップと、
前記発注先商取引団体から受取った請求情報である発注先請求情報と、前記発注元商取引団体へ送付した請求情報とを突き合わせる第３の突き合せステップをさらに有し、両者が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成するステップから構成されたことを特徴とする調達支援方法。
【請求項２３】発注元商取引団体に設けられ、実際に受領した商品・サービスと受信した請求情報を突き合せる突き合せステップを含む調達支援方法であって、該調達支援方法は発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行い、前記発注元商取引団体の突き合せステップは、
前記発注情報に基づく前記発注先商取引団体からの前記商品・サービスの納品を受け付けた前記発注元商取引団体における検収を受領情報として発注元商取引団体側の受領情報データベースに記憶するステップと、
前記調達支援システムから、前記発注元商取引団体の前記受領情報に基づく請求情報を受信すると、前記受領情報データベースに記憶する受領情報を突き合わせ、該請求情報と前記受領情報が一致することを確認する第２の突き合せステップと、
該第２の突き合せステップによって該請求情報と前記受領情報が一致する場合は該発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するステップから構成されたことを特徴とする突き合せステップを含む調達支援方法。
【請求項２４】発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援方法において、
前記請求情報を請求情報データベースに記憶するステップと、
前記発注先商取引団体から、前記発注元商取引団体への前記商品・サービスの納入に応じた代金を請求する発注先請求情報を受信すると、前記請求情報データベースに記憶する前記請求情報と突き合せ、該請求情報と前記発注先請求情報が一致することを確認する第３の突き合せステップを有し、
該第３の突き合せステップによって該請求情報と前記受領情報が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成するステップから構成されたことを特徴とする調達支援方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、法人活動における備品や消耗品などの資源の調達支援システム及び方法に関するものである。更に詳細には、法人活動に必要な備品や消耗品の調達時における経理処理などのように、法人活動としての利益を全く生み出さず、無益で不要な付加価値を生み出す作業を極力減らし、法人活動の人件費を含む全体的な経費を削減できる資源の調達システム及び方法を提供するためになしたものである。
【０００２】
【従来の技術】
法人活動においては、備品や消耗品などの資源の調達が必要不可欠である。そのため従来では、一般的に図３に示したような段階、工程を経てこういった事業活動に必要な資源を調達することが行われている。すなわち、まずステップ２０で発注先を複数選定してステップ２１で発注元が複数の発注先に購入希望の商品・サービスの価格、納期の見積もりを要求し、その中から発注先を選定してそれがＯＫになるとステップ２２で発注がおこなわれる。そしてステップ２３で納品を受け、その結果発注した商品・サービスが希望したものであるとステップ２４で検収し、ステップ２５で対価の支払いをおこなう。
【０００３】
しかしながらこういった備品や消耗品の調達においては、商品・サービスを受け取るまでに見積依頼や発注書を起票し、そして納品後は検収書をおこして経理部門に商品・サービスの支払い依頼を行い、経理部門は経理部門で発注先から送られてくる請求書と検収書の突き合わせ、勘定科目の付与、経費の分類、支払いのための伝票起票や振り込みなどの作業が発生する。
【０００４】
そこでこういった資源調達を簡単に行うため、特開平１１−３１１８４号公報などに見られるように、インターネットを活用して物品調達できる仕組みを提供することで、事務作業の簡素化を意識したサービスが増えている。しかしながらそれらは、単に発注をインターネットで実現するシステムであったり、購入履歴が参照できるシステムであり、顧客側の経理システムや実務作業の削減にまで踏み込んだシステムではないため、納品書と請求書の突き合わせや、勘定科目の確認などの経理処理に多くの時間と手間がかかっていた。また、発注データと請求データに一貫性がないため、発注元も発注先も全く個別に管理データなどを作成するなどの手間が生じていた。
【０００５】
そのため以下図１から図９を用い、従来のこういった資源調達の段階、工程、及びその問題点を明らかにする。
図１は、商取引、及び商取引団体の定義を示したもので、図２は商取引団体の事業活動の定義を示したもの、図３は事業活動に必要な資源調達の流れを説明するための図、図４は図３における発注先選定２０、見積２１の詳細、図５は図３における発注２２の詳細、図６は図３における納品２３の詳細、図７は図３における検収２４の詳細、図８は図３における支払２５の詳細、図９は発注元で発生している潜在問題点を説明するための図である。なお、この図１から図９において、同一構成要素には同一番号を付して説明する。
【０００６】
まず図１は、商取引、及び商取引団体の定義を示したもので、図中１は発注元としての商取引団体、２は発注先（仕入先）としての商取引団体である。商取引とは、一方が仕入先選択３を行ってもう一方が商品・サービス４を提供し、それに対して対価５を支払う行為をいう。ここで言う商取引団体１、及び２とは商取引行為をする団体であり、例えば企業、業界団体、官公庁（自治体を含む）、学校などの各種法人、及び個人商店など、経理機能を有して税金の支払いをする団体のことをいう。そして発注元（商取引団体）１とは、商品・サービス４を受け取り、対価５を支払う商取引団体のことであり、一般に顧客と呼ばれている。一方発注先（仕入先）（商取引団体）２とは、商品・サービス４を提供し、対価５を受け取る商取引団体のことであり、一般に仕入先やベンダーと呼ばれている。
【０００７】
図２は商取引団体の事業活動の定義を示したもので、商取引団体の事業活動１０とは、そもそも資源１１に付加価値１２を付与して提供することであり、提供されるのは、図１で説明した商品・サービス４である。事業活動に必要な資源１１には、有形１３のものと無形１４のものがあり、有形１３の資源とは形のある資源のことで、例えば材料である。無形１４の資源とは形のない資源のことであり、例えば人材、インフラなどのことである。資源１１に付与される付加価値１２には、有益１５なものと無益１６なものがある。有益な付加価値１５とは、商取引団体の事業活動１０において提供する商品・サービス４の価値を高めるものである。無益１６な付加価値のうち、必要１７なものとは、具体的には缶コーヒーを例に説明すると、商品である缶コーヒーを温めたり冷やしたりすることをいう。なぜなら、一般に寒いときの缶コーヒーは温めた方が消費者によく売れる。つまり消費者は、（寒いときには）暖かい缶コーヒーに付加価値１２を感じるからである。ただし、温めなくても（冷やさなくても）売価に変わりはないため、直接的には利益に還元されない故に、無益１６なコストであるといえる。同様に商品提供上必要な物流や商品を保護するパッケージングなどのコストは無益１６であるが、必要な付加価値１７である。無益１６な付加価値のうち不要１８なものとは、これまで商品・サービス４を提供する上で必要なものと思われてきたもので、例えば伝票処理、見積書の作成、カタログ制作、宣伝、電話やＦＡＸでのやりとりなどのコストを指し、実はそれが無くても消費者にとって提供上問題無いもののことをいう。ここでは消費者という言い方をしたが、提供される側と考えればよく、図１でいう発注元商取引団体１と概念的には同一である。
【０００８】
図３は先に説明したように、事業活動に必要な資源調達の流れを説明するための図である。２０の発注先選定は、発注元１が発注先２を選別することであり、２１の見積とは、発注先２が発注元１より問い合わせを受けた購入希望の商品・サービス４の価格、納期を回答することである。２２の発注は、発注元１が発注先２に対して商品・サービス４の購入依頼をすることであり、２３の納品は、発注元１が発注した商品・サービス４を発注先２が発注元１へ納めることである。２４の検収とは、発注元１に発注先２より納品された商品・サービス４の受領を認めることであり、２５の支払いは、発注先１が発注先２に対して対価５を還元することである。
【０００９】
図４は図３における発注先選定２０の詳細である。通常発注先２の選定は、発注元１が電話帳、カタログ、インターネットで調べる、他人に聞くなどして安価で対応の良い取扱業者の調査と打診をし、見積行為をする対象を絞り込む１次選定と、絞り込んだ発注先２に問い合わせをして対応してくれる業者を更に複数選定し、見積依頼をして納期、納品方法、価格、仕様、見積有効期限、支払方法、担当者、連絡先などを記した見積書３０を提出してもらい、発注元の時々に重要視される条件・要件に基づいてこれらの中から選定する２次選定とがある。１次選定では、例えばタウンページ（電話帳）をみて抽出するが、発注品（消費対象）が何であるかによって１次選定にて選定される発注先（仕入先）２が変わる。図中３１は、発注元１が発注先２に商品やサービスを発注し、購入した商品やサービスを使い減らす消費機能、３２は発注元１内部の経営活動のため、消費機能３１を取り仕切る管理機能で、発注元１の各個人、あるいは各部門の要望を取りまとめ、一括して発注先２に商品・サービス４を発注する。３３は発注先２が外部からの求めに応じて商品・サービスを提供する営業機能で、具体的には、企業活動における販売活動や受注行為をさす。
【００１０】
図５は図３における発注２２の詳細である。図４における見積で発注先２が確定すると、発注元１から商品・サービス４の提供を要求する発注必要情報が記載されている発注伝票３５が発注先２に送られる。発注必要情報とは、例えば図示した商品名、型式、仕様、数量、支払方法、支払先部門、納品先部門などである。基本的には管理機能３２から発注が入るが、消費機能３１から直接発注される場合もある。この発注元１より出された発注伝票２２に対して、発注先２の営業機能３３から納品情報を回答するために発行されるのが回答書３６であり、これには受注連絡、納期回答、変更通知などが記されている。
【００１１】
図６は図３における納品２３の詳細である。図５において正式発注がなされると商品・サービス４が納品される。この納品は、発注先２の発送機能３７によってなされる。この発送機能３７は、発送先２が発注元１に対して商品・サービス４を送り出す機能であり、例えば物流センタなどをいう。納品伝票３８とは、発注先２が発注元１に対して発行する商品・サービス４を納めたことを確認する為、納入日、商品名、型式、仕様、数量、納品先部門などを記した伝票であり、受領書３９とは発注元１が発注先２に対して商品・サービス４を受け取ったことを確認する伝票である。なお、消費機能３１に商品が届くことを納品という場合もある。
【００１２】
図７は図３における検収２４の詳細である。発注元１が発注先２より納品された商品・サービス４の受領を認めたとき検収２４が行われ、検収印が押された受領書３９が発注元１から発注先２に送られる。検収印は、発注元１が納品された商品に対する支払いを認めたことを記す印で、商取引が成立したことを示す。発送機能３７が宅配業者に委託されている場合、宅配便の受領書が受領書３９を兼ねる場合もある。受領を発注元１が拒否する場合、発注先（仕入先）２は発注元１からの連絡を待たなければならない。拒否の連絡がない場合、受領したと判断する。
【００１３】
図８は図３における支払２５の詳細である。発注先２による納品２３と発注元１による検収２４が済むと、発注先２の営業機能３３から請求書４０が発行される。この請求書４０は、発注先２が発注元１に対して商品・サービス４の対価５を請求するための伝票をいい、商品４の納品日、商品名、型式、仕様、単価、数量、合計金額、消費税、納品先部門、支払部門、支払先口座、商取引口座名などが記されており、発注元１の経理機能４１に対して送られる場合（Ａ）と、消費機能３１に対して送られる場合（Ｂ）とがある。（Ａ）の経理機能４１に送られた場合、先ず納品書（納品伝票）３８を消費機能３１から集計して請求書４０と突き合わせて確認し、各部門への請求、及び請求データが入力される。そしてその結果に基づいて発注先（仕入先）２の口座への振り込みが行われる。（Ｂ）の消費機能３１に送られた場合は、消費機能３１で先ず納品書（納品伝票）２６と請求書４０とを突き合わせて確認し、請求書４０を集計して各部門への請求、及び請求データが入力される。そしてそれが経理機能４１に送られて最後に発注先（仕入先）２の口座への振り込みが行われる。納品書（納品伝票）３８と請求書４０の突き合わせは発注元１が行う行為で、納品書３８と請求書４０を見比べ、納品書記載事項と請求書記載事項が同じであるかの確認をすることである。一般的には支払先部門毎に請求書４０が発行される。
【００１４】
【発明が解決しようとする課題】
しかしながら、図３に示したような資源調達の流れの場合、それぞれの工程においては以下に記すような問題点がある。すなわち、まず図４に示した図３における２０の発注先選定工程においては、例えば発注先２をタウンページ（電話帳）、カタログ、インターネットで調べる、他人に聞く、などしても調べられなかった発注先３４が有る場合、たとえそれが１次選定、及び２次選定で選んだ発注先２より優れた発注先であったとしても、発注ができない、すなわち発注先がわからないという問題がある。またその他にも、発注先選定の基準が不明瞭、発注先の選定に時間がかかる、さらにこうして発注先を選定してもその都度価格交渉をせねばならない、多数の発注先に発注をせねばならず手間がかかる、大口で発注しないと価格が安くならないなどの問題がある。また、発注単位、取引単位での消費機能３１と管理機能３２の確認行為における連携がうまくいかず、本来必要のない再照合作業がロスとなる問題もある。
【００１５】
そして、図５に示した図３における２２の発注工程においては、発注元１で管理機能３２が発注元１の各部門からの注文をまとめて発注すると、部門単位に仕分けする手間がかかると共に他部門の分まで受け取りに行く手間がかかる。また、管理機能３２が実際に商品を利用する消費機能３１と発注先２との間に入ってのやりとりは手間であり、消費機能３１が勝手に商品を発注すると、管理機能３２としてどこに届けたらよいか、振り替えたらよいかわからないという問題が発生する。更にそれ以外にも、例えば材料費なのか消耗品なのかなどの支払い科目が発注時にわからない（意識していない）、発注金額の責任権限を遵守できていない、予算、実績金額が科目毎にできていない、発注時に支払い科目が不明確なので予算管理ができないなどの問題がある。特に、各フェーズ（工程）には時限的ギャップがあり、確認作業が必要なことと、確認作業を実行するための例えば伝票などの確認媒体が必要となる。また発注先２では、受注方法が複数あるため受注窓口も多くなってコスト増につながり、受注確認内容と統一フォーマットで確認できないため確認に手間がかかる、発注伝票３５に基づいて発注内容をデータ入力する手間がかかる、一件一件の商品の仕様確認を相互で行う煩雑さがある、発注先２の受注方法が複数あるなどの問題点がある。
【００１６】
そして図７に示した図３における２４の検収工程においては、受領と検収２４にタイムラグがあること、発注元１の担当者による検収が不明確な為、支払い義務を明示できないこと、検収部門と管理（支払）部門が異なる場合、支払い確認に手間がかかる、などの問題点がある。
【００１７】
そして図８に示した図３における２５の支払工程においては、納品書３８と請求書４０の突き合わせに時間がかかるが、伝票チェックする日が集中するため残業になることが多い、振込先銀行が多いと振込依頼書を書く手間がかかると共に振り込み手数料が振込先分取られる、などの問題がある。また、機能の権限が複数先に委譲、分散されていて、しかも商品、金額等により複雑になっているといった問題もある。
【００１８】
また、以上説明してきた事業活動に必要な資源調達の流れには、これ以外にも図９の４２に記したような隠れている問題点、課題認識されていない問題点がある。すなわち、一般的に会社として特に用度品等の購買業務の考え方、明確な方針、判断基準が無い、発注したいがどこの業者に頼んだら良いかがわからないことによる手間が発生する、商品知識や経験が必要なため、発注先（仕入先）の選定基準が難しい、消費部門より納期クレームを受ける、注文したものが違うことがある、誰の注文かわからないときがある、伝票チェックそのものが手間である、科目毎の予算管理ができていない、何の科目にしたら良いかが判らない、部門単位での支払（振替）処理をしなければならない、請求書に部門宛先が無く、たらい回しになることがある、毎回権限を有する者の認可をもらうのは面倒、などである。
【００１９】
すなわち、従来の図３に示したような工程による事業活動に必要な資源の調達方法は、商品・サービスを受け取るまでに見積依頼や発注書を起票し、そして納品後は検収書をおこして経理部門に商品・サービスの支払い依頼を行い、経理部門は経理部門で発注先から送られてくる請求書と検収書や納品書の突き合わせ、経費の分類、支払いなどの作業が発生し、納品書と請求書の突き合わせにおいては勘定科目の確認などの経理処理に多くの時間と手間がかかっていた。また、発注データと請求データの一貫性がないため、発注元１も発注先２も個別に管理データなどを作成するなどの手間が生じていた。
【００２０】
そのため本発明においては、図９の４３に改善策として示したように、購買業務の集中化、単純化、標準化を実現することが課題である。そしてそれによって、図２に無益で不要な付加価値１８として示した、これまで商品・サービス４を提供する上で必要なものと思われてきたもの、例えば伝票処理、見積書の作成、カタログ制作、宣伝、電話やＦＡＸでのやりとりなどのコストを削減し、法人活動の人件費を含む全体的な経費を削減するシステムを提供することが課題である。
【００２１】
図１０は、このような考え方に従った本発明のコンセプトを説明するための図である。以上説明してきたように、従来の図３に示したような工程による事業活動に必要な資源の調達方法には種々の問題点がある。それらをまとめたのがこの図１０で、出会い情報４５は、図４における無知における非見積対象となっている発注先（仕入先）３４がわからない、すなわち発注先に対する非連携４８のため、安価でサービスの良い発注先２を知ることができず、結果として高価でサービスの悪い発注先に発注し、無益かつ不要な付加価値４９を消費することになることを示している。しかし、出会い情報４５を持っていれば、こうした無益、かつ、不要な付加価値の消費を削減することができる。処理プロセス４６は、例えば、発注先２への発注方法や発注先２による請求処理、納品形態に統一性がなくて非連携４８なため、作業効率が悪化する場合である。この場合、発注元１と発注先２の処理プロセスを統一することができれば、作業効率の悪化を防止し、無益、かつ不要な付加価値４９の消費を削減することができる。消費機能と管理機能４７は、企業活動に必要な資源調達に関する情報を共有する必要があるのだが、非連携４８であるため、商取引処理を行う際に伝票内容などの確認をする手間がかかり、無益、かつ不要な付加価値４９を消費することとなることを示している。一方、消費機能と管理機能４７を連携させることができれば、当然前記のような無益、かつ不要な付加価値の消費を削減することができる。
【００２２】
そのため、これら出会い情報４５、処理プロセス４６、消費機能と管理機能４７が非連携４８の場合、４９のような無益、かつ不要な付加価値が発生する。これは一般に見えないコストと総称されている。このような点に鑑みて、本発明では、５０に示したように、発注における入力データの一連処理、顧客勘定科目の自動生成、消し込み（請求情報と納品情報の突き合わせ）時の前処理情報の自動生成などをコンセプトとし、それによって５１のように無益、かつ不要な付加価値の消滅を計るようにした。すなわち、見えないコストの中で有益なものと無益なものとを分離し、かつ、無益なものを必要、不要に分離した上で、本発明に対する削減対象を無益、かつ不要な付加価値と定義付けるのである。
【００２３】
【課題を解決するための手段】
上記課題を解決するため本発明においては、サーバーによる処理の一元化、共通フォーマットによる受発注処理の明瞭化（統一帳票の使用）、発注・納品・決済フローの標準化などを行うシステムを提供し、発注元１からの発注情報が発注先２の受注情報となり、その情報が一貫して商取引の業務伝票の中で生かされ、請求伝票となる仕組みを構築したものである。すなわち、顧客より取得した基本情報を予め保持し、顧客から発注依頼があった際にこの保持している基本情報から、経理処理に必要な情報を自動的に読み出し、発注伝票に相当する情報から請求伝票に相当する情報までを自動生成する。更に、本発明の調達支援システム内で別々に生成されたデータベースから、それぞれ個別に情報を読み出して突き合わせる本発明は、これまで人的判断により突き合わせていた照合作業をシステム化することにより、上記問題点を解決することを目的としている。
【００２４】
このように、発注情報が受注情報となってシステムに取り込みができ、かつ請求情報となるため、発注先において、受注とその後当然必要となる請求にかかる手間が省け、さらに発注元団体が制定した勘定科目が自動生成されることで、経理部門などが税制上の整理も含めて確認していた手間が省ける。また、経理部門などで生じていた、納品書と発注先からの請求書の突き合わせなどの作業手間が省ける。
【００２５】
そのため本発明においては、請求項１で記載したように、発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスの自動見積りをする見積手段を有する調達支援システムにおいて、
複数の発注元商取引団体および複数の発注先商取引団体とネット網を介して通信を行い、発注元商取引団体からの商品・サービスに関する見積依頼情報を受信し、発注先商取引団体へ見積依頼情報を送信した後に該見積依頼情報に対応する見積情報を受信し、さらに該見積情報を該発注元商取引団体へ送信する通信手段と、
前記発注元商取引団体が所望する条件で所望する商品・サービスを提供するために、前記発注先商取引団体が提供できる前記商品・サービスに関する情報を商品情報として記憶する商品情報データベースと、
前記商品・サービスを提供できる前記発注先商取引団体に関する情報を複数記憶する発注先情報データベースと、
前記通信手段によって前記発注元商取引団体から前記見積依頼情報を受信すると、受信した前記見積依頼情報に基づいて前記商品情報データベースを検索し、該当する前記商品情報があった場合には、前記商品情報データベースから抽出した前記商品情報を前記発注元商取引団体に前記通信手段を用いて送信する商品情報検索手段と、
前記商品情報検索手段が前記商品情報を検索できなかった場合には、前記発注先情報データベースから前記見積依頼情報に示す商品・サービスを提供できる前記発注先商取引団体を１又は複数、選択する発注先選択手段と、
前記発注先選択手段が選択した前記発注先商取引団体に対して前記見積依頼情報を前記通信手段を用いて送信し、送信した前記見積依頼情報に対応する見積情報を前記発注先商取引団体から前記通信手段を用いて受信すると、受信した見積情報から、予め決められた発注先決定条件で特定の前記発注先商取引団体を決定し、決定した前記発注先商取引団体から受信した前記見積情報を前記発注元商取引団体にとって最適な見積情報に決定し、決定した見積情報を見積情報データベースに記憶すると共に前記見積依頼情報を送信した前記発注元商取引団体に前記通信手段を用いて送信する見積決定手段とから構成されたことを特徴とする調達支援システムを開示し、またこのシステムに対応する調達支援方法を請求項１７で開示する。
【００２６】
すなわち本発明は、発注元商取引団体、調達支援システム、発注先商取引団体の３者のコンピューターが通信回線で結ばれた情報仲介システムであり、本発明による調達支援システムは、サーバ内におかれた商品取引に関する各種のデータベースから最適な情報を検索し、かつ適切な情報が無い場合には外部のデータベースから条件に合う情報を自動入手する情報仲介システムを構成している。具体的には、この調達支援システムでは発注元商取引団体から特定の商品に関する見積依頼があると、サーバ内の商品情報データベースを検索してその見積価格を発注元商取引団体へ送信する。もしその商品に関する情報が自己の商品情報データベースに無い場合には、発注先情報データベースに予め記憶された複数の発注先商取引団体に見積依頼を出してその見積価格やその他の条件の中から最適な見積情報を決定して、発注元商取引団体へその最適な見積情報を送信することができるように構成されている。
【００２７】
このように調達支援システムと調達方法を構成することにより、前記図１０に示した出会い情報がわからないという問題が解決され、安価でサービスの良い発注先を知ることができないために結果として高価でサービスの悪い発注先に発注し、無益かつ不要な付加価値を消費することが無くなる。そのため、発注先の選択に時間がかかったり、さらにこうして発注先を選定してもその都度価格交渉をせねばならない、多数の発注先に発注をせねばならず手間がかかる、大口で発注しないと価格が安くならない、また、発注単位、取引単位での消費機能と管理機能の確認行為における連携がうまくいかず、本来必要のない再照合作業がロスとなる問題などが解決される。また、発注情報を基に検収情報や請求情報を作成することでデータに一貫性が生じ、検収情報と請求情報の突き合わせなどが容易になる。
【００２８】
又本発明の請求項２では、前記見積決定手段は、前記予め決められた発注先決定条件として前記発注元商取引団体の過去の購入履歴を用いて最適な見積情報を決定し、条件に合致しなかった場合には、見積価格、納期、品質等に対して所定のウエイトを付けて生成された条件を用いて決定される調達支援システムを開示する。これらのウエイト付けにより、実際の商取引における発注先を決定するステップと同様な判断基準で発注先を決定することが可能となる。
【００２９】
また請求項３では、あらかじめ前記発注元商取引団体に関する情報を顧客に関する情報として顧客識別コードともに記憶する顧客情報データベースと、
前記発注元商取引団体から発注情報を顧客識別コードとともに前記通信手段を用いて受信すると、受信した顧客識別コードに基づいて前記顧客情報データベースから顧客に関する情報を取得し、前記見積情報データベースに該当する前記見積情報があった場合には該見積情報と受信した発注情報に基づいて、或いは該当する前記見積情報がなかった場合には前記商品情報データベースに記憶される前記商品情報と受信した発注情報に基づいて受注情報を作成し、作成した該受注情報を受注情報データベースに記憶すると共に発注情報として前記発注先商取引団体に前記通信手段を用いて送信する発注処理手段をさらに備えることを特徴とする前記調達支援システムを開示し、またこのシステムに対応する調達支援方法を請求項１８で開示する。
【００３０】
このように本発明の調達支援システムでは、顧客識別コードによりその顧客に関する情報を取得して受注情報が生成され、発注先商取引団体への発注情報として自動処理されるので、効率よく発注処理をすることが可能となる。
【００３１】
また請求項４では、前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を仕入情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記仕入情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段をさらに備えることを特徴とする調達支援システムを開示する。
【００３２】
さらにまた請求項１０に記載したように、発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を仕入情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記仕入情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信するように構成された請求処理手段とを備えたことを特徴とする調達支援システムを開示し、また上記システムに対応する調達支援方法を請求項２０に開示する。
【００３３】
このように納品情報データベースに記憶した仕入情報と受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せを行うことにより、仕入情報と一致した検収済みの受注情報についてだけ請求情報を作成するので、検収情報と請求情報は発注元商取引団体の発注情報を基に作られた一貫性のあるデータであるから突き合わせは全く自動的に行うことができ、従来のように納品書と請求書の突き合わせに時間がかって伝票チェックする日が残業になるといったことがなくなり、また振込先銀行への振込依頼書を書く手間や振り込み手数料の問題、機能の権限が複数先に委譲、分散されていて、しかも商品、金額等により複雑になっているといった問題なども解決される。
【００３４】
さらに請求項５、請求項１１に記載したように、前記請求処理手段は、前記第１の突き合せ機能によって前記仕入情報と一致しなかった検収済みの受注情報について、検収済みの前記受注情報があって前記仕入情報がなかった場合には入力誤りを示す情報を、未検収の前記受注情報で前記仕入情報がある場合には前記発注元商取引団体に対して検収依頼の対象とする検収依頼対象を示す情報を、未検収の前記受注情報で前記仕入情報がない場合には調査対象を示す情報を、それぞれ出力することを特徴とする調達支援システムを開示し、またこのシステムに対応する調達支援方法を請求項２１で開示する。すなわちこの第１の突き合せ機能により、検収済み受注情報、未検収受注情報、そして仕入情報がチェックされ、矛盾する場合にはそれぞれの対応処置を行うことが可能となる。
【００３５】
さらに請求項６では、前記顧客情報データベースには、前記顧客識別コードに加えて、顧客の部門コードや発注商品・サービスに対応した勘定科目が記憶され、前記発注元商取引団体からの前記発注情報を受けると、前記発注処理手段は前記顧客情報データベースより発注情報に対応する発注商品・サービスの勘定科目を抽出して仕分け情報を作成し、該作成された仕分け情報を前記発注情報に付与して発注先商取引団体へ発注し、かつ前記請求処理手段が前記請求情報を前記発注元商取引団体へ送付する際に、該仕分け情報を前記請求情報に付して前記発注元商取引団体へ送付することを特徴とする調達支援システムが開示され、また上記システムに対応する調達支援方法を請求項１９で開示する。
【００３６】
このようにすることで、発注情報に仕分け情報が自動的に付加され、材料費なのか消耗品なのかなどの支払い科目が発注時にわからない（意識していない）、発注金額の責任権限を遵守できていない、予算、実績金額が科目毎にできていない、発注時に支払い科目が不明確なので予算管理ができないなどの問題が解決できる。また、経理部門は請求書と検収書の突き合わせ、勘定科目の付与、経費の分類、支払いのための伝票起票や振り込みなどの作業が全くなくなる。
【００３７】
また請求項７に記載したように、受領した商品・サービスに関する受領情報を記憶した受領情報データベースが前記発注元商取引団体に設けられており、該受領情報データベースからの前記受領情報と前記請求処理手段からの請求情報とを突き合わせる第２の突き合せ機能をさらに有し、両者が一致する場合は前記発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成した調達支援システムを開示する。この第２の突き合せ機能により、発注元商取引団体では、実際に受領したものについてだけ支払処理を行うので適切な経理処理が可能となる。
【００３８】
また請求項８では、前記請求処理手段にさらに、前記発注先商取引団体から受取った請求情報である発注先請求情報と、前記発注元商取引団体へ送付した請求情報とを突き合わせる第３の突き合せ機能をさらに有し、両者が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする調達支援システムを開示する。こにより、情報仲介システムである本発明に係る調達支援システムの運用者では、仕入れた商品・サービスの支払と請求を確実に突き合わせることが出来るので、的確な経理処理を行うことが可能となる。
【００３９】
また請求項９で開示するように、前記発注先商取引団体に対する経理処理における支払金額は、前記発注元商取引団体へ送信した請求情報の請求金額と同額、または前記支払金額より請求金額の方が小額であり、該調達支援システムの利用料として両者の差額データが前記請求処理手段に蓄積されるように本発明の調達支援システムが構成されているので、情報仲介料として上記の差額が蓄積され、ビジネスとしての情報仲介が可能となる。
【００４０】
また請求項１２では、発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記仕入情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段と、
受領した商品・サービスに関する受領情報を記憶した受領情報データベースが前記発注元商取引団体に設けられており、該受領情報データベースからの前記受領情報と前記請求処理手段からの請求情報とを突き合わせる第２の突き合せ機能をさらに有し、両者が一致する場合は前記発注元商取引団体の経理処理を行い、両者が不一致の場合は不一致情報を生成するように構成したことを特徴とする調達支援システムを開示する。
【００４１】
また請求項１３では、発注元商取引団体と発注先商取引団体の間にネット網を介して介在し、発注元商取引団体から発注情報を受けて、発注先商取引団体に商品・サービスを発注し、前記発注元商取引団体へは請求情報を送信することで、商品・サービスなどの資源調達の支援を行う調達支援システムにおいて、
前記発注元商取引団体からの発注情報を受信すると、受信した発注情報を受注情報として受注情報データベースに記憶すると共に前記発注先商取引団体へ発注処理を実行する発注処理手段と、
前記発注先商取引団体から、前記受注情報に対応した前記発注元商取引団体への前記商品・サービスの納品を示す納品情報を受信すると、受信した納品情報を納品情報データベースに記憶し、前記発注元商取引団体から該納品に対する検収を示す検収情報を受信すると、受信した検収情報を検収済みの受注情報として受注情報データベースに記憶する受領処理手段と、
前記納品情報データベースに記憶した仕入情報と前記受注情報データベースの検収済みの受注情報が一致することを確認する第１の突き合せ機能を有し、該第１の突き合せ機能によって前記仕入情報と一致した検収済みの受注情報について請求情報を作成し、作成した請求情報を前記発注元商取引団体に送信する請求処理手段とを備え、
前記請求処理手段は、前記発注先商取引団体から受取った請求情報である発注先請求情報と、前記発注元商取引団体へ送付した請求情報とを突き合わせる第３の突き合せ機能をさらに有し、両者が一致する場合は前記発注先商取引団体に対する経理処理を行い、両者が不一致の場合は不一致情報を生成することを特徴とする調達支援システムを開示する。
【００４２】
すなわちこれらの情報仲介サーバ内の第１の突き合せ機能と発注元商取引団体のコンピューター内第２の突き合せ機能の組合せ、および情報仲介サーバ内の第１および第３の突き合せ機能の組み合せにより、夫々の経理処理を適切に行うことが可能となる。なお上述の第１、第２、および第３の突き合せ機能を全て組み込まれたシステムを請求項１４で開示し、またこのシステムに対応する調達支援方法を請求項２２で開示する。
【００４３】
さらに上述の第２の突き合せ機能を有したシステムを請求項１５で開示し、またそのシステムに対応する調達支援方法を請求項２３で開示する。同様に上述の第３の突き合せ機能を有したシステムを請求項１６で開示し、またそのシステムに対応する調達支援方法を請求項２４で開示する。
【００４４】
【発明の実施の形態】
以下、図面に基づいて本発明の実施の形態を例示的に詳しく説明する。但し、この実施の形態に記載されている構成部品の寸法、材質、形状、その相対配置などは、特に特定的な記載がない限りはこの発明の範囲をそれのみに限定する趣旨ではなく、単なる説明例に過ぎない。
【００４５】
図１１から図１６は、本発明の機能ブロック図であり、図１７から図２０、及び図２２から図２５はこの機能ブロック図のフロー図、図２１は受注情報データベース７３と仕入れ情報データベース７４の突き合わせを説明する図、図２６は本発明における発注元商取引団体１の端末、発注先商取引団体２の端末、調達支援システム６０の端末などのハードブロック図である。このうち図１１は本発明の全体の機能ブロック図、図１２は図１１における顧客登録機能部６４の詳細機能ブロック図、図１３は図１１における見積機能部６５の詳細機能ブロック図、図１４は図１１における発注機能部６６の詳細機能ブロック図、図１５は図１１における受領機能部６７の詳細機能ブロック図、図１６は図１１における請求機能部６８、突き合わせシステム６２の詳細機能ブロック図である。図中同一構成要素には同一番号を付し、また前記従来説明で用いたと同じ機能ブロックには同一番号を付した。
【００４６】
図１１における１は発注元商取引団体、２は発注先商取引団体、４は商品・サービス、３１は消費機能、３２は管理機能、３３は営業機能、３７は商品の発送機能、４１は経理機能、６０は本発明になる調達支援システムで、インターネット、公衆通信回線などのネット網で発注元商取引団体１、発注元商取引団体２とデータのやりとりをおこなう。６１は消費機能３１が発注して受領した商品・サービス４の受領情報を記憶している受領情報データベース、６２は受領情報データベース６１の内容と請求情報８６を突き合せる突き合せシステム、６３は突き合せシステム６２の確認した請求情報８６に基づいた金額の支払い情報、６４は調達支援システム６０の顧客登録機能部、６５は同じく見積機能部、６６は発注機能部、６７は受領機能部、６８は請求機能部、６９は顧客登録機能部６４の顧客管理機能、７０は顧客情報データベース、７１は調達支援システム６０の受注処理機能、７２は見積機能部６５の商品情報データベース、７３は発注機能部６６の受注情報データベース、７４は受領機能部６７の仕入情報データベース、７５は請求機能部６８の請求処理機能、７６は発注先２の営業機能３３からの発注情報、７７は商品の納品情報、７８は商品の対価の請求機能である。
【００４７】
８０は発注元１の管理機能３２からの顧客情報、８１は発注元１の消費機能３１からの見積依頼情報、８２は調達支援システム６０の受注処理機能７１の見積機能部６５からの見積情報、８３は発注元１の消費機能３１からの発注情報、８４は調達支援システム６０の受注処理機能７１の受領機能部６７からの納品情報、８５は発注元１の消費機能３１からの検収情報、８６は調達支援システム６０の請求処理機能７５からの請求情報、８７は発注元１の経理機能４１からの支払済み通知情報、８８は調達支援システム６０の顧客登録機能部６４の顧客情報データベース７０からの顧客情報、８９は同じく調達支援システム６０の受注処理機能７１の見積機能部６５からの見積依頼情報、９０は発注先２の営業機能３３からの見積情報、９１は調達支援システム６０の受注処理機能７１の発注機能部６６からの発注情報、９２は発注先２の発送機能３７からの納品情報、９３は発注先２の請求機能７８からの請求情報、９４は調達支援システム６０の請求処理機能７５からの支払済み通知情報である。
【００４８】
図１２は、図１１における調達支援システム６０の顧客登録機能部６４の詳細であり、１００は登録依頼のあった顧客情報８０に関する情報が顧客情報データベース７０にあるか否かを検索する顧客情報検索機能で、無ければフォーマットを発注元１に送信し、取得した情報を与信判定機能１０１に出力する。この与信判定機能１０１は、顧客情報検索機能１００より入力のあった顧客について、与信情報データベース１０２を検索し、商取引相手として適正か否かを判定する機能であり、その判定結果を顧客情報登録機能１０３に出力する。与信情報データベース１０２は、商取引団体に関する与信情報を保管するデータベースであって、外部のデータベースを活用しても良い。顧客情報登録機能１０３は、与信判定機能１０１より入力のあった与信判定結果を顧客情報データベース７０に登録すると共に、発注元１の管理機能３２に返信する機能である。登録完了報告情報１０４は、顧客識別手段である顧客識別コード、及び調達支援システム６０にアクセスする権利キーとなるパスワードが付与される。なお、顧客情報データベース７０に登録された顧客情報は、顧客登録機能部６４の通信機能１０６を介して発注先２の営業機能３３にも出力され、発注元１が調達支援システム６０を利用するにあたって顧客コードで識別できるようになっている。顧客コードには、発注元１の納品先住所、連絡先、発注責任者、販売価格等の条件、与信限度額、支払条件、勘定科目コード一覧、発注に際しての認可対象者の有無（有ればその責任者名とＥ−Ｍａｉｌアドレスなど）などがひも付きになっている。
【００４９】
図１３は、図１１における調達支援システム６０の見積機能部６５の詳細であり、１０７は見積依頼情報８１の商品に関する情報が商品情報データベース７２に有るか否かを検索する商品情報検索機能で、無ければ見積依頼をする発注先２を選定するための商品情報を発注先選択機能１０８に出力する。商品情報データベース７２は、発注元１が所望する条件で所望する商品を提供するための情報を保管するデータベースである。ここでいう商品には、無形のサービス（商品）が含まれる。なお、後述の商品も特に説明がなければ同様の解釈とする。発注先選択機能１０８は、見積依頼のあった商品について、適した発注先２を発注先情報データベース１０９より選択し、選択した発注先２に見積依頼情報８９を送信する機能である。ここでいう適した発注先２とは、発注元１の所望する条件で所望する商品を提供できる可能性のある発注先２のことであり、複数でも良く、複数の場合は相見積もりとなる。発注先情報データベース１０９は、商品情報に基づいて、その商品を提供できる発注先２に関する情報を保管するデータベースである。見積決定機能１１０は、発注先２より取得した見積情報９０の中から最適な発注先見積情報を選択し、発注元１に送信する見積情報８２を生成する機能である。ここでいう最適な発注先見積情報とは、発注元１の所望する条件に最も適合するものである。より具体的には、商品の選定にあたって、発注元１の購入履歴をベースに商品の優先順位を選定し、それに合致しない場合は、価格の安さ、納期の早さ、品質によって発注元１の所望する条件に照らし合わせる調達代理人の役割を果たすことで、発注先２に利便性を提供することもできる。なおこの図１３で、１１１は見積決定機能１１０からの情報を記憶している見積情報データベース、１１２は発注先２の営業機能３３からの商品情報、１１３は発注先２の営業機能３３からの発注先見積情報データベースである。
【００５０】
図１４は、図１１における調達支援システム６０の発注機能部６６の詳細であり、１１４は発注元１より取得した発注情報８３に基づいて、顧客情報データベース６９、商品情報データベース７２、見積情報データベース１１１から必要な情報を読み込み、受注情報を生成する受注確定機能、１１５は発注先２の営業機能３３からの受注情報を記憶する受注情報データベースである。
【００５１】
図１５は、図１１における調達支援システム６０の受領機能部６７の詳細であり、納品確認機能１１６は、発注先２より取得した納品情報９２を発注元１の消費機能３１に納品情報８４として送信し、納品確認を促す機能である。検収確認機能１１７は、送信した納品情報８４に基づく検収行為を発注元１の消費機能３１が実行した結果である検収情報８５を受注情報データベース７３に格納する機能、１１８は、発注先２が商品・サービス４の納品情報７７を記憶している売上情報データベースである。
【００５２】
図１６は、図１１における調達支援システム６０の請求機能部６８、及び発注元１の突き合わせシステム６２、経理機能４１の詳細であり、１２０は未検収情報、１２１は消費機能３１が発注して受領した商品・サービス４の受領情報、１２２は受領情報１２１と請求情報８６の突き合わせ機能、１２３は突き合わせた結果一致した場合に出される突き合わせ一致情報、１２４は同じく一致しなかった場合の突き合わせ不一致情報、１２５は経理処理機能、１２６は各部門への振替処理、１２７は商品・サービス４に対する対価の引き落とし情報の作成、１２８は金融機関での自動引き落とし（発注元商取引団体１による対価の支払い行為）、１２９は受注情報データベース７３からの受注情報、１３０は受領情報と仕入情報の突き合わせ機能、１３１は仕入情報、１３２は受領情報と仕入情報とを突き合わせた結果、不一致（すなわち未納）の場合の未納情報、１３３は支払情報（発注先請求情報１３７）と発注先２の請求情報８６の突き合わせ機能、１３４は金融機関での自動引き落とし１２８によって口座から引き落とされたときの消し込み、１３５は支払情報と発注先２の請求情報の突き合わせ機能１５３により支払情報と発注先請求情報１３７との一致が確認されたとき起こす引き落とし情報、１３６は金融機関での自動引き落とし（調達支援システム６０による対価の支払い行為）、１３７は発注先請求情報、１３８は金融機関での自動引き落とし１３６による口座の消し込みである。
【００５３】
なお、営業機能３３には、本発明のシステムを利用するにあたり、商取引の信用情報を調査し、取り引きしていく上で問題がなければ顧客コードを付与する顧客登録機能を含む。また、本発明のシステムでは、Ｗｅｂブラウザを利用することで顧客コードとパスワードで発注者の識別を行う。顧客コードには、支払方法（クレジットカード、集金代行等金融機関での自動引き落としなど）、支払先部門、発注担当者などの情報がひも付きになっており、これに発注元１が科目コードを選択、通知することで仕分け（経費伝票記載処理）の自動生成を実現する。
【００５４】
図２６は本発明の調達支援システム６０のハードブロック図であり、突き合わせシステム、発注元商取引団体１の端末、及び発注先商取引団体２の端末のハードブロック図も同様になる。３００は演算装置、３０１はプログラム実行部でＲＡＭにより構成されており、以下に述べるようなフローを実行する各プログラムを実装して演算装置３００で実行する、いわゆるプログラムの実行領域である。３０２はデータベースメモリで、各データベースに相当するメモリである。３０３は通信インターフェース部で、ネットワーク３１２との通信を行う。３０４は入力手段インターフェース部で、マンマシン入力手段３０９で入力された情報を各ブロックに伝える。３０５は出力手段インターフェース部、３０６は画像データメモリで、マンマシン出力手段３１０に出力される画面データを保管するメモリである。３０７は処理部プログラムメモリで、演算装置３００で構成される処理部で実行されるプログラムを保管するメモリである。この処理部プログラムメモリ３０７とデータベースメモリ３０２は、書き換え可能なように一般に不揮発性メモリであるハードディスクなどの記憶媒体が用いられ、１つの記憶媒体にまとめて内部を領域分割して使用しても良い。３０８は媒体出力手段、３０９はマンマシン入力手段、３１０はマンマシン出力手段、３１１は出力媒体で、これは各システム及び各端末から出力される媒体である。媒体には、一般に紙媒体と電子媒体があり、例えば紙媒体とは印刷物であり、電子媒体とは電子情報を記憶したＦＤ（フロッピー（登録商標）ディスク）、ＣＤ−Ｒ（コンパクトディスクレコーダー）、ＭＯ（マグネトオプティカルディスク）、ＤＶＤ（ディジタルヴァーサタイルディスク）などである。媒体出力手段３０８は、この出力媒体に会わせて選択（用意）されればよい。３１２はネットワークである。
【００５５】
以下、図１１から図１６の機能ブロック図のフロー図である図１７から図２０、及び図２２から図２５、及び図２１の受注情報データベース７３と仕入れ情報データベース７４の突き合わせを説明する図を用いて本発明の調達支援システムについて説明する。
【００５６】
本発明においては、前記したように顧客より取得した基本情報を予め保持し、顧客から発注依頼があった際に、この保持している基本情報から経理処理に必要な情報を自動的に読み出し、発注伝票に相当する情報から請求伝票に相当する情報までを自動生成する。更に、本発明の調達支援システム内で別々に生成されたデータベースから、それぞれ個別に情報を読み出して突き合わせることにより、これまで人的判断により突き合わせていた照合作業をシステム化している。そのため、まず最初に調達支援システム６０に発注元１のデータを登録する。
【００５７】
図１７は、この発注元１、即ち顧客の登録フロー図で、前記図１１における顧客登録機能部６４、その詳細である図１２に対応する。まず顧客である発注元１より調達支援システム６０の顧客登録機能部６４に対して顧客情報８０を送り、登録依頼をする。調達支援システム６０の顧客登録機能部６４においては、ステップ１５１で発注元１より顧客登録依頼があったかどうかが判定され、無い場合は他の処理１５２がなされ、有った場合はステップ１５３に行って、顧客情報データベース７０に登録依頼のあった顧客情報があるかどうかが検索される。そしてステップ１５４で検索した顧客情報の登録があるかどうかが確認され、有った場合はステップ１６３に行って登録結果として登録完了報告１０４を発注元１に送信し、無い場合はステップ１５５で顧客情報データベース７０より顧客情報フォーマットを読み込む。そしてステップ１５６で読み込んだ顧客情報フォーマットを発注先１に送信する。そしてステップ１５７で送信したフォーマットに基づく顧客情報８０が返信されたかどうかが確認され、無い場合はステップ１５８の他の処理がなされ、有った場合はステップ１５９で受信した顧客情報に基づいて与信情報データベース１０２より与信情報を取得する。そしてステップ１６０で取得した顧客の与信情報が商取引相手として適正か否かが判断され、適正と判断したときはステップ１６１に進んで顧客情報データベース７０に登録し、不適正な場合はステップ１６２で不適正な顧客として顧客情報データベース７０に登録する。そしてステップ１６３で登録結果である登録完了報告１０４を発注元１に送信する。
【００５８】
こうして顧客情報が調達支援システム６０に登録されると、発注元１は商品・サービス４の調達支援システム６０を介しての購入が可能となる。そのため最初に、発注元１が発注先２に前記図３における見積２１を依頼する場合について、図１８のフローに基づいて説明する。この図１８は、前記図１３に示した見積機能部６５の見積情報作成のフロー図である。
【００５９】
まず発注元１の消費機能３１が、調達支援システム６０の見積機能部６５の商品情報検索機能１０７に対して見積依頼情報８１を送る。なおここでいう見積依頼情報８１は、本発明においては発注元１が欲しい商品・サービスを示すことである。見積機能部６５の商品情報検索機能１０７は、ステップ１７１で発注元１より見積依頼があったかどうかをチェックしており、無い場合は他の処理１７２おこない、有った場合はステップ１７３に行って、商品情報データベース７２より見積依頼のあった商品情報を検索する。そしてステップ１７４で、検索した商品情報が登録されているかどうかが確認され、有った場合はステップ１８１で見積情報８２を発注元１に送信し、無い場合はステップ１７５で発注先選択機能１０８に発注先選択の依頼が送られる。そして発注先選択機能１０８が見積依頼のあった商品につき、適した発注先を発注先情報データベース１０９より選択する。そしてステップ１７６で選択した発注先２に見積依頼情報８９を通信機能１０６で送信する。そしてステップ１７７で、送信した見積依頼情報８９に基づく発注先２の見積情報９０の返信があったかどうかが確認され、無い場合はステップ１７８で他の処理がなされ、有った場合はステップ１７９で、見積決定機能１１０が受信した発注先２の見積情報９０の中から最適な発注先２の見積情報９０を選択する。そしてステップ１８０で選択した発注先２の見積情報９０に基づいて見積情報を決定する。そしてステップ１８１で決定した見積情報８２を発注元１に送信する。
【００６０】
こうして見積が得られると、発注元１は商品・サービス４の調達支援システム６０を介しての発注が可能となる。そのため発注元１は、前記図３における発注２２を行う。この場合のフローが図１９である。この図１９は、前記図１４に示した発注機能部６６の発注のフロー図である。
【００６１】
まず発注元１の消費機能３１が、調達支援システム６０における発注機能部６６の受注確定機能１１４に発注情報８３を送る。この発注情報８３は、発注元１からの商品・サービス４購入の依頼情報のことであり、具体的には例えば商品の型式、数量、価格などのことである。この受注確定機能１１４は、ステップ１９１で発注元１より顧客識別コードを含んだ発注情報８３があったかどうかチェックしており、無い場合は他の処理１９２を行い、有った場合はステップ１９３に行き、顧客情報データベース６９より発注元１の基本情報、具体的には例えば部門名、部門コード、部門予算などで構成された発注元１に関する情報を読み込む。そしてステップ１９４で、取得した顧客識別コードと発注情報８３に含まれる商品情報に基づいて、発注元１へ請求するときに請求伝票に記載されているべき項目、具体的には例えば部門コード、勘定科目などで構成される請求情報必須事項を顧客情報データベース６９より抽出する。なお、ここでいう勘定科目とは、税制上の経費などを管理するための識別コードである。そしてステップ１９５で、抽出した請求情報必須事項より受注情報を生成する。なお、この受注情報とは、調達支援システム６０、及び発注先２から見た発注元１からの発注情報８３のことであり、具体的には例えば商品の型式、数量、価格などのことである。そしてステップ１９６で、見積情報データベース１１１に対応する見積情報があるか否かが確認され、有る場合は見積情報データベース１１１より対応する見積情報を読み込む。この見積情報は、発注先２より回答のあった見積情報のことであり、対応する見積情報が存在する場合には、優先的に参照する。一方無い場合は、ステップ１９８で商品情報データベース７２より対応する商品情報を読み込む。一般的に、商品情報データベース７２に対応する商品情報が存在する場合は見積行為そのものが発生しないので、商品情報データベース７２より読み込む情報とは、見積情報が存在しない場合に参照するものである。そしてステップ１９９で、読み込んだ商品情報をステップ１９５で生成した受注情報に書き込み、受注情報データベース７３に記憶すると共に、ステップ２００で通信機能１０６を介して発注情報９１として発注先２の営業機能３３に送信する。そして営業機能３３は、この発注情報９１を受注情報データベース１１５に記憶する。
【００６２】
こうして発注が行われると発注先２は、図１５に示したように受注情報データベース１１５に記憶した発注情報９１に基づいて発送機能３７に発注情報７６を送り、発送機能３７は図１１に示したように納品物（商品・サービス）４を発注元１の消費機能３１に送付すると共に納品情報７７を請求機能７８に送る。そして同時に納品情報９２を調達支援システム６０の受領機能部６７に送る。図２０は、この図１５に示した受領機能部６７の納品と検収のフロー図である。まずステップ２１１で、調達支援システム６０の受領機能部６７に発注先２の発送機能３７より、納品情報９２が送られてきたかどうかがチェックされる。無いと他の処理２１２がなされ、有った場合はステップ２１３に行って通信機能１０６を介して取得した納品情報９２を仕入情報データベース５４に記憶する。そしてこの取得した納品情報を、納品確認機能１１６によって納品情報８４として発注元１の消費機能３１に送信する。そしてステップ２１５で、送信した納品情報８４に対応する検収情報８５の受信があるかどうかが確認され、無い場合はステップ２１６に移って他の処理がなされ、有る場合はステップ２１７に移って検収確認機能１１７で受信した検収情報８５を受注情報データベース７３に検収済みとして記憶する。
【００６３】
こうして納品と検収が行われるわけであるが、この納品、または検収に基づいて対価の請求を行う場合、それに先だって納品が確実に行われているか、そして検収がなされているかの確認（突き合わせ）が必要となる。また、発注元１が請求に対して対価を支払う場合も、受領情報１２１と請求情報８６が一致しているかどうかの確認（突き合わせ）が必要となる。図２１は、図１５で説明した納品情報９２を記憶している仕入情報データベース７４と検収情報８５を記憶している受注情報データベース７３との突き合わせを説明するための図である。受注情報データベース７３においては、検収情報８５の取得により、受注情報１２９に検収済み情報が付与される。図中、受注情報データベース５３のＡとＢが検収済みの受注情報に相当する。同様にＣとＤは未検収の受注情報である。仕入情報データベース７４のＡとＣは、仕入情報１３１の取得により、データベースに書き込まれた情報である（仕入済みという意味）。突き合わせは、受注情報データベース７３と仕入情報データベース７４内のそれぞれの情報を突き合わせる処理であり、図中の４通りの組み合わせが考えられる。すなわちＡは検収済みで仕入済みであり、これは請求対象となる。Ｂは検収済みだが仕入が行われておらず、これは誤りであるからその旨を仕入情報データベース７４に書き込む。Ｃは未検収だが仕入は行われており、発注元１に検収依頼を行う対象となる。Ｄは未検収で仕入も行われておらず、なぜ仕入が行われなかったかの調査対象とする。
【００６４】
図２２は、図１６における請求機能部６８の受領情報と仕入情報の突き合わせ機能１３０動作フロー図である。まずステップ２２１で受注情報データベース７３を検索する。そしてステップ２２２で受注情報データベース７３に検収データがあるかどうかをチェックし、有る場合はステップ２３６へ、無い場合はステップ２２３へ進む。そのため、検収情報８５がない場合を先に説明すると、まずステップ２２３で仕入情報データベース７４から仕入情報１３１を読み込む。そしてステップ２２４で未検収情報と仕入情報１３１を突き合わせ、ステップ２２５で突き合わせた情報が一致するかどうかを確認する。一致しない場合はステップ２２６に進んで、発注先２に仕入待ち情報（未納情報１３２）、すなわち図２１におけるＤに相当することを送信する。そしてステップ２２７で返信があったかどうか確認し、無い場合はステップ２２８で他の処理をし、有った場合はステップ２２９で仕入待ち情報の対象は発送するのかどうか判断し、発送しない場合はステップ２３４で返信が有るかどうかを判断し、無い場合はステップ２３５で受注情報データベース７３に保留であることを書き込む。そしてステップ２３４で返信があった場合はステップ２３３に進み、受注情報データベース７３に検収情報を書き込む。
【００６５】
一方ステップ２２５で突き合わせた情報が一致したときと、ステップ２２９で仕入待ち情報の対象を発送する場合は、ステップ２３０に進んで受注情報データベース７３の未確認情報（未検収情報）１２０、すなわち図２１におけるＣで有ることを発注元１に送信する。そしてステップ２３１で返信があったかどうかを確認し、無い場合はステップ２３２で他の処理を行い、有った場合は受注情報データベース７３に検収情報を書き込む。また、ステップ２２２で受注情報データベース５３に検収データがある場合、ステップ２３６に進んで仕入情報データベース７４から仕入情報１３１を読み込む。そしてステップ２３７で検収有り情報を仕入情報と突き合わせ、ステップ２３８で突き合わせた情報が一致するかどうかを確認する。一致した場合は図２１におけるＡであるから終了し、一致しない場合は図２１におけるＢであるからステップ２３９に進み、仕入情報データベース７４の仕入漏れ情報を発注先２へ送信する。そしてステップ２４０で返信が有るかどうかを確認し、無い場合はステップ２４１で他の処理がなされ、有った場合はステップ２４２で仕入情報データベース７４に書き込んで終わりとなる。なお、受注情報１２９と仕入情報１３１の突き合わせとは、調達支援システム６０内で保存されている受注情報データベース７３の情報と、仕入情報データベース７４の情報を照合することであり、コンピュータの中で２つの情報を読み取り、差異が発生していないかを検証する処理である。不一致情報の抽出とは、受注情報１４９と仕入情報１３１の突き合わせ処理により、差異が発生した情報のことである。
【００６６】
図２３は、図１６の請求機能部６８の支払情報と発注先の請求情報の突き合わせ機能１３３の動作フロー図である。まずステップ２５１で発注先請求情報１３７を読み込み、ステップ２５２で発注元１からの請求情報８６を読み込む。そしてステップ２５３で発注元１の請求情報８６と発注先２の請求情報１３７を突き合わせる。そしてステップ２５４で突き合わせた情報が一致するかどうか確認し、一致した場合は終了し、一致しなかった場合はステップ２５５に進んで不一致情報を抽出する。そしてステップ２５６で発注先１の請求機能７８に未検収情報、すなわち発注元１の請求情報８６と発注先２の請求情報１３７が不一致であることを送信する。そしてステップ２５７で返信があったかどうか確認し、無い場合はステップ２５８で他の処理をし、有った場合はステップ２５９で一致した分の支払通知の出力をして終了する。この一致した分の支払通知の出力が、金融機関に対する引き落とし情報１３５による金融機関での自動引き落とし（または口座振替）１３６の指示に相当する。
【００６７】
図２４は、図１６の発注元１の突き合わせシステム６２の受領情報１２１と未検収情報１２０を突き合わせる場合の動作フロー図である。まずステップ２７１で受領情報１２１と請求情報８６の突き合わせ機能１２２が受領情報データベース６１の受領情報１２１と調達支援システム６０よりの未検収情報１２０を読み込み、突き合わせする。そしてステップ２７２で未検収情報１２０があるかどうかを確認し、無い場合は終了して有る場合はステップ２７３で消費部門の対象部門３１へ未検収情報、すなわち突き合わせ不一致情報１２４を送信する。そしてステップ２７４で返信があったかどうかを確認し、無い場合はステップ２７５で他の処理をし、有った場合はそれをステップ２７６で受領情報データベース６１に書き込んで終了する。
【００６８】
図２５は、図１６の発注元１の突き合わせシステム６２の受領情報１２１と請求情報８６を突き合わせる場合の動作フロー図である。まずステップ２８１で受領情報データベース６１から受領情報１２１を読み込み、次のステップ２８２で調達支援システム６０より請求情報８６を読み込む。そしてステップ２８３でこの受領情報１２１と請求情報８６を突き合わせ、ステップ２８４で突き合わせた情報が一致するかどうか判断する。一致した場合はステップ２８９に進み、突き合わせ一致情報１２３として経理機能４１へ出力する。一致しなかった場合はステップ２８５に進み、調達支援システム６０の請求機能部６８に過剰請求情報を送信する。そしてステップ２８６で返信があったかどうかを判断し、無い場合はステップ２８７で他の処理をし、有った場合はステップ２８８で受領情報データベース６１に書き込み、ステップ２８９に進んで、突き合わせ一致情報として経理機能４１へ出力する。
【００６９】
図２７は本発明の第２実施形態を説明する概念図であり、以上説明してきた図１１の実施形態においては、突き合わせシステム６２が発注元の内部にあったが、この図２７の第２実施形態ではこの突き合わせシステムを外部に設置した場合のイメージ図である。図中６０は以上説明してきたような調達支援システム、３２０は第１の発注元、３２１は第２の発注元、３２２は第ｎの発注元、３２３は突き合わせシステムで、中の３２４は第１の発注元に対応する突き合わせエリア、３２５は第２の発注元に対応する突き合わせエリア、３２６は第ｎの発注元に対応する突き合わせエリアである。なお、突き合わせエリアとは、発注元単位のデータベース及び突き合わせ作業エリアのことであり、このように構成することで、各発注元１は突き合わせシステムを内部に持つ必要が無くなり、それだけ発注元１の設備が不要になる。
【００７０】
図２８は、このような図２７の概念に従った本発明の第２実施形態の機能ブロック全体図で、図２７の概念図で説明したように、図１１における発注元１に含まれていた受領情報データベース６１、突き合わせシステム６２が発注元１の外部に突き合わせシステム３２３として設けられている。なお、この図２８における構成要素と動作は、図１１乃至図１６の機能ブロック図、及び図１７から図２０、及び図２２から図２５のフロー図で説明してきたものと同一である。そのため、突き合わせシステム３２３の動作のみを図１６の機能ブロック図と図２４、図２５のフロー図に基づいて説明する。
【００７１】
まず図２４のステップ２７１で図１６の受領情報１２１と請求情報８６の突き合わせ機能１２２が受領情報データベース６１の受領情報１２１と調達支援システム６０よりの未検収情報１２０を読み込み、突き合わせする。そしてステップ２７２で未検収情報１２０があるかどうかを確認し、無い場合は終了して有る場合はステップ２７３で発注元１の消費部門の対象部門３１へ未検収情報、すなわち突き合わせ不一致情報１２４を送信する。そしてステップ２７４で返信があったかどうかを確認し、無い場合はステップ２７５で他の処理をし、有った場合はそれをステップ２７６で受領情報データベース６１に書き込んで終了する。
【００７２】
そしてその後、発注元１の突き合わせシステム６２の受領情報１２１と請求情報８６を突き合わせる。まず図２５のステップ２８１で受領情報データベース６１から受領情報１２１を読み込み、次のステップ２８２で調達支援システム６０より請求情報８６を読み込む。そしてステップ２８３でこの受領情報１２１と請求情報８６を突き合わせ、ステップ２８４で突き合わせた情報が一致するかどうか判断する。一致した場合はステップ２８９に進み、突き合わせ一致情報１２３として発注元１の経理機能４１へ出力する。一致しなかった場合はステップ２８５に進み、調達支援システム６０の請求機能部６８に過剰請求情報を送信する。そしてステップ２８６で返信があったかどうかを判断し、無い場合はステップ２８７で他の処理をし、有った場合はステップ２８８で受領情報データベース６１に書き込み、ステップ２８９に進んで、突き合わせ一致情報として発注元１の経理機能４１へ出力する。
【００７３】
図２９は本発明の第３実施形態を説明する概念図であり、図２７に示した第２の実施形態においては突き合わせシステム３２３が発注元１の外部に設けられていたが、この第２の実施形態では調達支援システム６０内に設けた場合のイメージ図である。図中３２０は第１の発注元、３２１は第２の発注元、３２２は第ｎの発注元、３３０は突き合わせ部で、中の３３１は第１の発注元に対応する突き合わせエリア、３３２は第２の発注元に対応する突き合わせエリア、３３３は第ｎの発注元に対応する突き合わせエリア、３３４は調達支援部である。なお、突き合わせエリアとは、発注元単位のデータベース及び突き合わせ作業エリアのことであることは第２の実施形態である図２７で説明したとおりである。
【００７４】
図３０は、このような図２７の概念に従った本発明の第３実施形態の機能ブロック全体図で、図２９の概念図で説明したように、図１１における発注元１に含まれていた受領情報データベース６１、突き合わせシステム６２が調達支援システム６０の内部に突き合わせ部３３０として設けられる。なお、この図３０における構成要素と動作は、図１１乃至図１６の機能ブロック図、及び図１７から図２０、及び図２２から図２５のフロー図で説明してきたものと同一である。そのため、突き合わせシステム３３０の動作のみを図１６の機能ブロック図と図２４、図２５のフロー図に基づいて説明する。
【００７５】
まず図２４のステップ２７１で図１６の受領情報１２１と請求情報８６の突き合わせ機能１２２が受領情報データベース６１の受領情報１２１と調達支援システム６０よりの未検収情報１２０を読み込み、突き合わせする。そしてステップ２７２で未検収情報１２０があるかどうかを確認し、無い場合は終了して有る場合はステップ２７３で発注元１の消費部門の対象部門３１へ未検収情報、すなわち突き合わせ不一致情報１２４を送信する。そしてステップ２７４で返信があったかどうかを確認し、無い場合はステップ２７５で他の処理をし、有った場合はそれをステップ２７６で受領情報データベース６１に書き込んで終了する。
【００７６】
そしてその後、発注元１の突き合わせシステム６２の受領情報１２１と請求情報８６を突き合わせる。まず図２５のステップ２８１で受領情報データベース６１から受領情報１２１を読み込み、次のステップ２８２で調達支援システム６０より請求情報８６を読み込む。そしてステップ２８３でこの受領情報１２１と請求情報８６を突き合わせ、ステップ２８４で突き合わせた情報が一致するかどうか判断する。一致した場合はステップ２８９に進み、突き合わせ一致情報１２３として発注元１の経理機能４１へ出力する。一致しなかった場合はステップ２８５に進み、調達支援システム６０の請求機能部６８に過剰請求情報を送信する。そしてステップ２８６で返信があったかどうかを判断し、無い場合はステップ２８７で他の処理をし、有った場合はステップ２８８で受領情報データベース６１に書き込み、ステップ２８９に進んで、突き合わせ一致情報として発注元１の経理機能４１へ出力する。
【００７７】
図３１から図４６までは、本発明の調達支援システムを実際のサービスとして実施した場合の形態の一例と、そこで使う画面例を示したものである。図３１は調達支援サービスの実施形態の一例、図３２は顧客から見た調達支援システムにおけるコンピュータ画面階層の具体的構成例、図３３から図４６はその画面の具体例である。
【００７８】
これらの図においては、以上説明してきた機能ブロックと同じものには同一番号を付した。図３１において１は発注元、２は発注先、３１は消費機能、３３は営業機能、３７は発送機能、４１は経理機能、６０は調達支援システム、６１は受領情報データベース、６２は突き合わせシステム、６３は支払確定情報、７０は顧客情報データベース、７１は受注処理機能、７２は商品情報データベース、７３は受注情報データベース、７５は請求処理機能、７６は発送情報、７７は納品情報、７８は請求機能、８１は見積依頼情報、８２は見積決定情報、８３は発註情報、８４は納品情報、８５は検収情報、８６は請求情報、８９は見積依頼情報、９０は見積情報、９１は発註情報、９３は請求情報、１２８は金融機関での自動引き落とし、１３４は口座消し込み、１３６は金融機関での自動引き落とし、１３８は口座消し込み、４００は発注元１の調達支援システム６０へのログイン、４０１は商品・サービスの見積依頼、４０２は商品・サービスの発注、４０３は発注元１の予算管理データ、４０４は商品・サービスの発送、４０５は仕入れ伝票（納品書）の送付、４０６は商品・サービスの納品、４０７は商品・サービスの納品受領、４０８は検収情報のデータベース、４０９は発注元１の商品・サービスの購入履歴のデータベース、４１０は商品・サービスの請求書の作成と送付、４１１は仕入れ情報データベース７４の納品情報９３と検収情報データベース４０９の検収情報８５の突き合わせ、４１２は支払確定情報である。
【００７９】
図３２は、本発明の調達支援システムにおけるコンピュータ画面の具体的構成例である。図中５００は図３３に示したようなメインメニューで、この中に利用説明５０１、アウトソーシングの説明５０２、各商品群の一覧５０３、図４１に示したような商品の検索５０４、図３４に示したような会員のログイン５０５、新規会員の登録５０６、お問い合わせ５０７などか設定されている。そしてそれぞれのメニューの下にはさらにメニューが用意されており、例えばアウトソーシングの説明５０２の下には、各コアの説明５０８があり、各商品群の一覧５０３の下には各商品一覧５０９、各商品詳細一覧及び発注画面５１０、オーダー確認及び会員Ｎｏ．入力５１１、発注お礼画面５１２がある。また図３４に示したような会員のログイン５０５の下には、図３５に示したような各社別のメインメニュー５１３があり、その下に図３６に示したような各商品群の一覧５１４、商品一覧５１５、図３７に示したような商品詳細及び発注５１６、図３８に示したようなオーダー確認５１７、発注お礼画面５１８がある。またこれ以外にも各社別のメインメニュー５１３の下には、図３９に示したような購入履歴５１９、図４２に示したような予算管理５２０、図４０に示したようなマイカタログ５２１、図４３に示したような顧客基本情報５２２があり、さらにこの顧客基本情報５２２の下には部門コード５２３、勘定科目５２４、個人情報５２５などを入力する画面が用意されている。
【００８０】
以下、図３１に示した本発明の調達支援システムを実際のサービスとして実施した場合の形態の一例を、本発明の調達支援システムにおけるコンピュータ画面の具体的構成例を示しながら説明する。発注元１が商品・サービスを発注する場合、まず図３１の４００のログインで図３３のメインメニュー画面５００における会員ログイン５０５をクリックし、図３４に示した会員ログイン画面５０５を読み出す。そしてユーザーＩＤ（顧客コード）とパスワードを入力し、ログインする。すると調達支援システム６０の受注処理機能７１は、顧客情報データベース７０からこの発注元１の顧客コードの情報を読み出し、顧客コード、パスワードがある場合はログインを許可して図３５に示した各社別メインメニュー画面５１３が表示される。この各社別メインメニュー画面５１３には、図３９に示したような購入履歴５１９、図４２に示したような予算管理５２０、図４０に示したようなマイカタログ５２１、図４３に示したような顧客基本情報５２２があり、さらにこの顧客基本情報５２２の下には部門コード５２３、勘定科目５２４、個人情報５２５などを入力する画面が用意されている。
【００８１】
そのため、例えば展示会の実施５２６をクリックすると、図３６のような各商品群一覧が表示され、健康診断５２７をクリックしてさらに健康測定器のような項目をクリックすると、図３７に示したような商品の詳細及び発注画面５１６が表示され、購入希望の商品があった場合は数量５２８、価格５２９を入力してカートに入れる５３０をクリックすると、図３８に示したようなオーダー確認の画面が現れ、確認ＯＫ５３１をクリックするとこのまま発注することが可能となる。また、以前発注したものと同じものを発注する場合は、図３９に示したような購入履歴画面５１９を読み出せば可能であり、頻繁に購入するものについては図４０に示したマイカタログ５２１を編集することも可能である。また希望する商品がどこにあるかわからない場合は、図４１に示した商品検索画面５０４で簡単に探すことができ、個人、または部門別に予算が組まれている場合は、図４２に示したような予算管理画面５２０で定められた予算を入力しておくことで、予算残高をいつでも確認することができ、また誤って予算以上の購入をした場合は警告がなされて購入できないようにされている。
【００８２】
こうしてログインした発注元１が、商品・サービスについての見積依頼４０１をする場合は、所定のフォーマットに従って見積依頼情報８１を送る。すると受注処理機能７１は、商品情報データベース７２を検索して見積依頼のあった商品の情報が有るか無いかをチェックし、有った場合はそれを見積決定情報８２として発注元１に送付し、無い場合は必要に応じて複数の発注先２の営業機能３３に見積依頼情報８９を送る。そしてこの営業機能３３から見積情報９０を取得すると、これを商品情報データベース７２に記憶すると同時に最適な商品・サービスを提供できる発注先２の見積を、見積決定情報８２として発注元１に送付する。
【００８３】
こうして商品・サービスに関する見積を入手し、それでＯＫの場合、発注元１は４０２で勘定科目のコードを付した発注情報８３を調達支援システム７１の受注処理機能７１に送って発注を行う。この勘定科目コードは、図４３に示した顧客基本情報画面５２２を読み出し、その中の科目情報入力・修正５２４をクリックして入力する。すると受注処理機能７１は、まず顧客情報データベース７０に記憶されている前記図４２で入力する発注元１の予算管理データ４０３をチェックし、今回の発注が予算内であることを確認するとこの発注情報８３を受注情報データベース７３に記憶すると共に、発注情報９１を発注先２の営業機能３３へ送る。発注情報９１を送られた発注先２の営業機能３３は、この発注情報９１に基づいて発送情報７６を作成し、それを発送機能３７に送る。そして発送機能３７は、発注元１に対して商品・サービスの発送４０４を行い、同時に納品情報７７を仕入れ伝票送付４０５として調達支援システム６０の受注処理機能７１と発注先２の請求機能７８に送る。調達支援システム６０の受注処理機能７１へ送られた納品情報７７は、仕入れ情報データベース７４に記憶された後納品情報８４として発注元１の消費機能３１に送られる。一方発注先１は、商品・サービスの納品４０６が行われるとそれを納品受領４０７し、その商品・サービスが希望通りのもので有れば納品情報８４によって検収を行い、検収情報８５を調達支援システム６０と突き合わせシステム６２に送る。検収情報８５を送られた調達支援システム６０は、これを検収情報データベース４０８に記憶すると共に購入履歴データベース４０９に記憶し、突き合わせシステム６２は受領情報データベース６１に記憶する。なお、検収情報８５を記憶する検収情報データベース４０８は、前記図１６で説明したように、受注情報データベース７３が兼ねても良い。
【００８４】
こうして商品・サービスの納品と検収が済み、発注元１と調達支援システム６０との間で事前に設定した代金決済や代金請求の締め切り日が来ると、発注先２の請求機能７８は納品情報７７に基づいて請求書作成４１０を行い、請求情報９３として調達支援システム６０の請求処理機能７５に送付する。すると請求処理機能７５は、まず仕入れ情報データベース７４に記憶された納品情報７７と検収情報データベース４０８、または受注情報データべース７３に記憶された検収情報８５を４１１で突き合わせ、発注先１の希望した商品・サービスが確実に納品されているか否かを確認し、納品されていることが確認されると今度は図４４に示したように、検収情報８５と請求情報９３との突き合わせ４１１を行う。そして請求情報９３が、検収情報８５の記載内容と相違ないことが確認されると、支払確定情報４１２として経理システムに入力取り込みして支払口座での自動引き落とし１３６を行い、一方請求情報８６として発注元１の突き合わせシステム６２に送付する。図４６のように一致しなかった場合は、図２１で説明したＢ、Ｃ、Ｄのような場合であるので、これらについては別途原因を調査する。
【００８５】
請求情報８６を送られた発注元１の突き合わせシステム６２は、図４４に示したように、まず受領情報データベース６１に記憶されている検収情報８５を読み出し、この内容と請求情報８６を自動突き合わせで照合する。そして両者が一致したら経理機能４１に支払確定情報６３として送付し、経理システムに入力取り込みして支払口座での自動引き落とし１２８を行う。なおこの支払確定情報６３は、前記したように発注情報８３に勘定科目のコードが付されているから、経理機能４１は仕分けなどの手を加えることなくそのまま使用することができる。
【００８６】
【発明の効果】
以上種々述べてきたように、本発明によれば、出会い情報がわからないという問題が解決され、安価でサービスの良い発注先を知ることができないために結果として高価でサービスの悪い発注先に発注し、無益かつ不要な付加価値を消費することが無くなる。そのため、発注先の選択に時間がかかったり、さらにこうして発注先を選定してもその都度価格交渉をせねばならない、多数の発注先に発注をせねばならず手間がかかる、大口で発注しないと価格が安くならない、また、発注単位、取引単位での消費機能と管理機能の確認行為における連携がうまくいかず、本来必要のない再照合作業がロスとなる問題などが解決される。また、発注情報を基に検収情報や請求情報が作成することでデータに一貫性が生じ、検収情報と請求情報の突き合わせなどが容易になる。
【００８７】
また、発注情報に仕分け情報が自動的に付加され、材料費なのか消耗品なのかなどの支払い科目が発注時にわからない（意識していない）、発注金額の責任権限を遵守できていない、予算、実績金額が科目毎にできていない、発注時に支払い科目が不明確なので予算管理ができないなどの問題が解決できる。また、経理部門は請求書と検収書の突き合わせ、勘定科目の付与、経費の分類、支払いのための伝票起票や振り込みなどの作業が全くなくなる。
【００８８】
さらに検収情報と請求情報は発注元商取引団体の発注情報を基に作られた一貫性のあるデータであるから突き合わせは全く自動的に行うことができ、従来のように納品書と請求書の突き合わせに時間がかって伝票チェックする日が残業になるといったことがなくなり、また、振込先銀行への振込依頼書を書く手間や振り込み手数料の問題、機能の権限が複数先に委譲、分散されていて、しかも商品、金額等により複雑になっているといった問題なども解決される。
【図面の簡単な説明】
【図１】商取引、及び商取引団体の定義を示した図である。
【図２】商取引団体の事業活動の定義を示した図である。
【図３】事業活動に必要な資源調達の流れを説明するための図である。
【図４】発注先選定と見積の流れを説明するための図である。
【図５】発注の詳細を説明するための図である。
【図６】納品の詳細を説明するための図である。
【図７】検収の詳細を説明するための図である。
【図８】支払の詳細を説明するための図である
【図９】一般的に用度品等の購買業務における潜在問題点を説明する図である。
【図１０】本発明のコンセプトを説明するための図である。
【図１１】本発明の第１実施例の機能ブロック図である。
【図１２】本発明おける調達支援システムの顧客登録機能部の詳細機能ブロック図である。
【図１３】本発明おける調達支援システムの見積機能部の詳細機能ブロック図である。
【図１４】本発明おける調達支援システムの発注機能部の詳細機能ブロック図である。
【図１５】本発明おける調達支援システムの受領機能部の詳細機能ブロック図である。
【図１６】本発明おける調達支援システムの請求機能部、突き合わせシステムの詳細機能ブロック図である。
【図１７】顧客登録機能部における顧客登録のフロー図である
【図１８】見積機能部の見積情報作成のフロー図である。
【図１９】発注機能部の発注のフロー図である。
【図２０】受領機能部の納品と検収のフロー図である。
【図２１】受注情報データベースと仕入情報データベースの突き合わせを説明するための図である。
【図２２】請求機能部の受領情報と仕入情報の突き合わせ機能の動作フロー図である。
【図２３】請求機能部の支払情報と発注先の請求情報の突き合わせ機能の動作フロー図である。
【図２４】発注元の突き合わせシステムの受領情報と未検収情報を突き合わせる場合の動作フロー図である。
【図２５】発注元の突き合わせシステムの受領情報と請求情報を突き合わせる場合の動作フロー図である。
【図２６】本発明のハードブロック図である
【図２７】本発明の第２実施形態を説明する概念図である
【図２８】本発明の第２実施形態の機能ブロック全体図である。
【図２９】本発明の第３実施形態を説明する概念図である。
【図３０】本発明の第３実施形態の機能ブロック全体図である。
【図３１】調達支援サービス事業の実施形態の一例である
【図３２】顧客から見た調達支援システムにおけるコンピュータ画面階層の具体的構成例である。
【図３３】調達支援システムのメインメニュー画面の例である。
【図３４】調達支援システムの会員ログイン画面の例である。
【図３５】調達支援システムにおける各社別のメインメニュー画面例である。
【図３６】調達支援システムの各商品群一覧画面の例である。
【図３７】調達支援システムの商品詳細及び発注画面の例である。
【図３８】調達支援システムのオーダー確認画面の例である。
【図３９】調達支援システムの購入履歴画面の例である。
【図４０】調達支援システムのマイカタログ画面の例である。
【図４１】調達支援システムの商品検索画面の例である。
【図４２】調達支援システムの予算管理画面の例である。
【図４３】調達支援システムの顧客基本情報画面の例である
【図４４】調達支援システムの突き合わせ処理画面の例である。
【図４５】調達支援システムの突き合わせ処理画面の例である。
【図４６】調達支援システムの突き合わせ処理画面の例である。
【符号の説明】
１      発注元商取引団体
２      発注先商取引団体
４      商品・サービス
３１    消費機能
３２    管理機能
３３    営業機能
３７    発送機能
４１    経理機能
６０    調達支援システム
６１    受領情報データベース
６２    突き合せシステム
６３    支払い情報
６４    顧客登録機能部
６５    見積機能部
６６    発注機能部
６７    受領機能部
６８    請求機能部
６９    顧客管理機能
７０    顧客情報データベース
７１    受注処理機能
７２    商品情報データベース
７３    受注情報データベース
７４    仕入情報データベース
７５    請求処理機能
７６    発注先２の営業機能３３からの発注情報
７７    発注先２の発送機能３７からの商品の納品情報
７８    対価の請求機能