(57)【要約】【課題】  産地側と卸側の双方にとって便利な、例えば青果物の契約取引のための商談支援の仕組みを提供する。【解決手段】  商談支援システム１は、産地側担当者が操作する産地端末２から入力された商談の条件データを含む商談データを、提案したい卸側担当者の数だけ生成する。そして、この商談データを卸端末３のブラウザに個別に表示させる。商談データを閲覧した卸端末３から商談の辞退、了承又は回答のいずれかを表す返答データを受領したときは、それを提案元の産地端末２のブラウザに一覧表示させる。返答データを閲覧した提案元の産地側担当者から回答又は了承に対する合意又は中止を表す決定データが入力されたときは、それを回答又は了承を入力した卸端末３のブラウザに個別に表示させる。【選択図】  図１
2005332230.tif 000002
【特許請求の範囲】
【請求項１】
農水産物商品の生産又は出荷に関わる第１種ユーザ、および、第１種ユーザとの間で行われる農水産物商品の注文又は入荷の交渉に関わる第２種ユーザにより操作される通信端末が接続可能な広域ネットワークに接続される、前記農水産物商品の契約取引における商談支援を行うシステムであって、
前記第１種ユーザ又は前記第２種ユーザの一方である提案元ユーザが前記第１種ユーザ又は前記第２種ユーザの他方となる１又は複数の提案先ユーザに提案する商談の条件データを当該提案元ユーザの通信端末より受領し、受領した前記条件データを含む商談データを前記提案先ユーザの数だけ生成するとともに、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第１処理手段と、
前記商談データを閲覧した前記１又は複数の提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを受領し、受領した返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第２処理手段と、
前記返答データを閲覧した提案元ユーザの通信端末から前記回答又は了承に対する合意又は中止を表す決定データを受領し、受領した決定データを前記回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第３処理手段と、を具えたことを特徴とする、
農水産物商品に関する商談支援システム。
【請求項２】
前記第１種ユーザ又は前記第２種ユーザのユーザＩＤおよび利用権限情報を含むユーザ属性情報が格納されているユーザマスタを具えており、いずれかのユーザの通信端末からユーザＩＤを伴うアクセスがあったときに前記ユーザマスタに格納されている利用権限情報により、当該通信端末が閲覧可能な商談データ記録領域を特定することを特徴とする、
請求項１記載の商談支援システム。
【請求項３】
それぞれ第１種ユーザ又は第２種ユーザが取り扱い可能な農水産物商品の品名又は品種に関する情報が格納されている複数の商品マスタと、それぞれ前記複数の商品マスタの各々とリンク可能な当該農水産物商品について設定されるべき商談の条件が格納されている複数の条件マスタとをさらに具えており、
前記第１処理手段は、
提案元ユーザの通信端末に、前記複数の商品マスタから提案対象となる商品についての商品マスタを選択させ、選択された商品マスタにリンクする条件マスタを提示して前記条件を入力させるとともに、前記ユーザマスタから前記提案先ユーザを選択させることにより、前記商談データを生成することを特徴とする、
請求項２記載の商談支援システム。
【請求項４】
前記第１処理手段は、前記条件を含む商談データ毎に固有の取引名称を付与し、その取引名称をシステムで一意となる提案ＩＤで識別可能にすることを特徴とする、
請求項３記載の商談支援システム。
【請求項５】
前記第１種ユーザと前記第２種ユーザの少なくとも一方のユーザのユーザマスタには、前記利用権限情報が、上部組織、下部組織、組織内、部署内、担当者のように階層的に複数のレベルで設定されており、システムログイン時に、設定された利用権限情報に応じた範囲の情報のみの閲覧を可能にすることを特徴とする、
請求項２記載の商談支援システム。
【請求項６】
前記商談データ、前記返答データ又は決定データをいずれかの前記商談データ記録領域に登録する際に当該データに未閲覧状態を表す未開封フラグを付与し、この未開封フラグを当該データを発出したユーザの通信端末が閲覧可能な商談データ記録領域に登録するとともに、当該データが相手先のユーザに閲覧されたときは前記未開封フラグを開封フラグに変更する閲覧状態管理手段をさらに具えたことを特徴とする、
請求項１記載の商談支援システム。
【請求項７】
前記第１処理手段、前記第２処理手段又は前記第３処理手段は、未開封フラグが付与されているデータの取り戻しを許容するように構成されていることを特徴とする、
請求項６記載の商談支援システム。
【請求項８】
合意された商談に関する農水産物商品毎の出荷スケジュールを定めた出荷カレンダを生成し、生成した出荷カレンダを前記提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域および前記提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域の双方に登録する出荷スケジュール管理手段をさらに具えたことを特徴とする、
請求項１記載の商談支援システム。
【請求項９】
農水産物商品の生産又は出荷に関わる第１種ユーザ、および、第１種ユーザとの間で行われる農水産物商品の注文又は入荷の交渉に関わる第２種ユーザにより操作される通信端末が接続可能な広域ネットワークに接続される、前記農水産物商品の契約取引における商談支援を行う情報通信システムが実行する方法であって、
前記第１種ユーザ又は前記第２種ユーザの一方である提案元ユーザが前記第１種ユーザ又は前記第２種ユーザの他方となる１又は複数の提案先ユーザに提案する商談の条件データを当該提案元ユーザの通信端末より受領し、受領した前記条件データを含む商談データを前記提案先ユーザの数だけ生成するとともに、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する段階と、
前記商談データを閲覧した前記１又は複数の提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを受領し、受領した返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する段階と、
前記返答データを閲覧した提案元ユーザの通信端末から前記回答又は了承に対する合意又は中止を表す決定データを受領し、受領した決定データを前記回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する段階とを有する、
農水産物商品に関する商談支援のための方法。
【請求項１０】
農水産物商品の生産又は出荷に関わる第１種ユーザ、および、第１種ユーザとの間で行われる農水産物商品の注文又は入荷の交渉に関わる第２種ユーザにより操作される通信端末が接続可能な広域ネットワークに接続されるコンピュータシステムを、前記農水産物商品の契約取引における商談支援を行うシステムとして動作させるためのコンピュータプログラムであって、
前記コンピュータを、
前記第１種ユーザ又は前記第２種ユーザの一方である提案元ユーザが前記第１種ユーザ又は前記第２種ユーザの他方となる１又は複数の提案先ユーザに提案する商談の条件データを当該提案元ユーザの通信端末より受領し、受領した前記条件データを含む商談データを前記提案先ユーザの数だけ生成するとともに、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第１処理手段、
前記商談データを閲覧した前記１又は複数の提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを受領し、受領した返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第２処理手段、
前記返答データを閲覧した提案元ユーザの通信端末から前記回答又は了承に対する合意又は中止を表す決定データを受領し、受領した決定データを前記回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第３処理手段、として機能させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば青果物、水産物のように、天候その他の自然的要因に大きく左右され、それ故に出荷量および出荷時期が不安定で、且つ、工業製品のように品質を保証できない農水産物商品の契約取引、すなわち現物を伴わない取引についての商談支援を行う情報処理を行う商談支援システムに関する。
【背景技術】
【０００２】
日本国内の青果物取引は、昭和４０年代まで、競りおよび入札が原則とされていた。昭和５０年代より、量販店の台頭や輸入青果物の解禁等により、安定取引のニーズが増え、卸売市場においても、予約相対取引が認められるようになってきた。現在は、競り、入札と相対取引とが併存している。相対取引は、例えば、産地−卸間において、安定取引の実現並びに需要側の多様な取引ニーズに応える意味から、増加の方向にある。
【０００３】
ところで、青果物は、天候等に左右されるため、出荷量および出荷時期が不安定となる。そのため、事前に約束した青果物を契約通りに出荷保証するには、産地にとって大きなリスクがある。現行取引においても、正式な契約書を産地−卸間で取り交わす事例は少なく、出荷−販売を実行する前に、その約束を記載した書面をラフに作成し、それに基づき、取引を実行するが、キャンセルや出荷減に対しては、ペナルティはかけられていない。また、現物の出荷−販売の直前に、価格や数量を産地−卸の担当者間で電話やＦＡＸを用いて調整しながら取引を行っている。最近では、ジャガイモや玉葱、ハウス施設での工業製品的な青果物において、契約的取引が実行され、安定出荷の難しい、果菜類（例えばキュウリ、イチゴ）においても、過去の取引経験の蓄積により出荷量の３０％程度であれば、出荷減や品質劣化リスクを回避できるようになっている。需要側、例えば量販店外食等）の安定数量確保の要請も増え、青果物全般において、契約取引のニーズは高まっている。
【０００４】
しかし、産地−卸間の契約取引を単純にコンピュータシステム化しようとすると、契約取引の業務形態のパターンや、１対１の相対取引に登場する担当者や産地の出荷組織の形態を定型化する必要がある。しかし、産地の出荷組織である全農および県連・農協組織は、国内出荷量の５５％以上を占め、契約取引の大枠を卸担当者と決める担当者、出荷段階直前に数量、価格を調整する担当者、出荷現場（農協・選果場）にて集荷、出荷、配送をコントロールする担当者などがおり、また、県連全体の取引をチェックする担当者などがいて、その役割、機能は、多種多様である。系統県連以外にも、出荷団体組織、任意組合、一般企業、個人出荷者があり、出荷組織形態も多種多様であり、契約取引に係る登場人物は、非常に多い。出荷前に数量価格を卸と調整する担当者は、数件から数十件となる出荷先の卸と同時並行的に調整する必要がある。
【０００５】
また、日々の集荷量の予測や契約取引量の確保や契約取引以外の現物取引量の管理、各卸向けのトラック単位での配送量把握など、非常に煩雑な作業となっている。契約取引分の数量、価格を把握するためには、卸との調整する期限を決め、ルール化しているのが現状であるが、出荷直前まで交渉している場合もある。大型の産地においては、全国の卸に向け、出荷しているため、翌日、販売となる卸（近地）、翌々日、販売となる卸（遠地）など、出荷日調整が必要となっている。また、輸送コスト等の物流条件と価格の兼ね合いを考慮している。
【０００６】
産地側では、指定卸制度がとられており、系統出荷団体を中心に、産地−卸の紐付けは、強固であったが、最近では、生産量の減少などにより、指定卸制度を見直す動きがある。卸側組織を集約するとともに、産地にとって、有利に販売できる卸との取引を求めている。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
産地−卸間の取引は、現物取引では、ＥＤＩのような情報処理システムが存在する。しかし、現物を伴わない契約取引においては、産地−卸間の取引を効果的に支援するデファクトスタンダードな情報処理システムは存在しない。産地Ａと産地Ｂが個々に契約取引のための情報処理システムを構築する例も見られるが、卸側にとっては、それぞれの産地毎に対応しなければならないため、コストパフォーマンスが上がらないという問題がある。卸側で個々に情報処理システムを構築する場合も、その事情は同じである。
【０００８】
本発明は、例えば上述した産地側と卸側の双方にとって便利な、契約取引のための商談支援の仕組みを提供することを主たる課題とするものである。
【課題を解決するための手段】
【０００９】
本発明は、上記課題を解決するために、農水産物商品に関する商談支援システム、方法およびコンピュータプログラムを提供する。
本発明の商談支援システムは、農水産物商品の生産又は出荷に関わる第１種ユーザ、および、第１種ユーザとの間で行われる農水産物商品の注文又は入荷の交渉に関わる第２種ユーザにより操作される通信端末が接続可能な広域ネットワークに接続される、前記農水産物商品の契約取引における商談支援システムである。
この商談支援システムは、前記第１種ユーザ又は前記第２種ユーザの一方である提案元ユーザが前記第１種ユーザ又は前記第２種ユーザの他方となる１又は複数の提案先ユーザに提案する商談の条件データを当該提案元ユーザの通信端末より受領し、受領した前記条件データを含む商談データを前記提案先ユーザの数だけ生成するとともに、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第１処理手段と、前記商談データを閲覧した前記１又は複数の提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを受領し、受領した返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第２処理手段と、前記返答データを閲覧した提案元ユーザの通信端末から前記回答又は了承に対する合意又は中止を表す決定データを受領し、受領した決定データを前記回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第３処理手段と、を具えたことを特徴とする。
第１種ユーザは、例えば上述した産地側の組織構成員（責任者、担当者等）であり、第２種ユーザは、例えば上述した卸側の組織構成員（責任者、担当者等）である。
【００１０】
このような商談システムでは、提案元ユーザから条件データを含む商談データを一つの提案先ユーザはもとより、複数の提案先ユーザに同時に投げかけることができる。つまり、１対１の相対取引のほか、１対Ｎ（Ｎは２以上の自然数）の擬似的な相対取引も可能になる。しかも提案先ユーザおよび提案元ユーザは、それぞれ個別に閲覧可能な商談データ記録領域に記録されたデータのみを閲覧するので、商談のセキュリティ性も確保することができる。
【００１１】
前記第１種ユーザ又は前記第２種ユーザのユーザＩＤおよび利用権限情報を含むユーザ属性情報が格納されているユーザマスタ、それぞれ第１種ユーザ又は第２種ユーザが取り扱い可能な農水産物商品の品名又は品種に関する情報が格納されている複数の商品マスタ、および、それぞれ前記複数の商品マスタの各々とリンク可能な当該農水産物商品について設定されるべき商談の条件が格納されている複数の条件マスタとを具えて商談支援システムを構成し、いずれかのユーザの通信端末からユーザＩＤを伴うアクセスがあったときに前記ユーザマスタに格納されている利用権限情報により、当該通信端末が閲覧可能な商談データ記録領域を特定するようにしてもよい。
【００１２】
ユーザによる条件データの入力の便宜を図る観点からは、前記第１処理手段を、提案元ユーザの通信端末に、前記複数の商品マスタから提案対象となる商品についての商品マスタを選択させ、選択された商品マスタにリンクする条件マスタを提示して前記条件を入力させるとともに、前記ユーザマスタから前記提案先ユーザを選択させることにより、前記商談データを生成するようにする。
この場合、前記第１処理手段は、提案条件を含む商談データ毎に固有の取引名称を付与し、その取引名称をシステムで一意となる提案ＩＤで識別可能にする。このようにすれば、一つの提案から派生して種々のユーザの通信端末から入力される情報は提案ＩＤをキーとして、一元的に管理することができるようになる。
【００１３】
第１種ユーザ又は第２種ユーザの実際の組織構造を考慮して、利用者権限情報を複数設定するようにしてもよい。例えば、リレーショナル・データベース（ＲＤＢ）の機能等を利用して、ツリー構造又は逆ツリー構造における組織間関連を利用権限情報で特定できるようにしてもよい。より具体的には、前記第１種ユーザと前記第２種ユーザの少なくとも一方のユーザのユーザマスタに、前記利用権限情報を、上部組織、下部組織、組織内、部署内、担当者のように階層的に複数のレベルで設定しておき、システムログイン時に、設定された利用権限情報に応じた範囲の情報のみの閲覧を可能にする。このようにすれば、決定権限のない者による閲覧およびデータの入力を未然に防止することができる。
【００１４】
商談データ記録領域に記録されたデータが実際に閲覧されたかどうかを確認する仕組みを導入してもよい。すなわち、商談データ、返答データ又は決定データをいずれかの商談データ記録領域に登録する際に当該データに未閲覧状態を表す未開封フラグを付与し、この未開封フラグを当該データを発出したユーザの通信端末が閲覧可能な商談データ記録領域に登録するとともに、当該データが相手先のユーザに閲覧されたときは前記未開封フラグを開封フラグに変更する閲覧状態管理手段をさらに具えて商談支援システムを構成する。また、前記第１処理手段、前記第２処理手段又は前記第３処理手段を、未開封フラグが付与されているデータの取り戻し（修正）を許容するようにしてもよい。
【００１５】
商談に合意した提案元ユーザおよび提案先ユーザの便宜を図る観点から、合意された商談に関する農水産物商品毎の出荷スケジュールを定めた出荷カレンダを生成し、生成した出荷カレンダを前記提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域および前記提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域の双方に登録する出荷スケジュール管理手段をさらに具えて商談支援システムを構成する。
商品の配送時間は出荷先毎に異なるため、出荷先の販売日に合わせた日々の出荷量把握が必要となったり、全国の出荷先での市場の休市日が異なるため、市場取引日のカレンダの把握を容易にすることで、各ユーザの便宜を図ろうとするものである。
【００１６】
上記課題を解決する本発明の方法は、農水産物商品の生産又は出荷に関わる第１種ユーザ、および、第１種ユーザとの間で行われる農水産物商品の注文又は入荷の交渉に関わる第２種ユーザにより操作される通信端末が接続可能な広域ネットワークに接続される、前記農水産物商品の契約取引における商談支援を行う情報通信システムが実行する方法であって、前記第１種ユーザ又は前記第２種ユーザの一方である提案元ユーザが前記第１種ユーザ又は前記第２種ユーザの他方となる１又は複数の提案先ユーザに提案する商談の条件データを当該提案元ユーザの通信端末より受領し、受領した前記条件データを含む商談データを前記提案先ユーザの数だけ生成するとともに、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する段階と、前記商談データを閲覧した前記１又は複数の提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを受領し、受領した返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する段階と、
前記返答データを閲覧した提案元ユーザの通信端末から前記回答又は了承に対する合意又は中止を表す決定データを受領し、受領した決定データを前記回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する段階とを有する、農水産物商品に関する商談支援のための方法である。
【００１７】
上記課題を解決する本発明のコンピュータプログラムは、農水産物商品の生産又は出荷に関わる第１種ユーザ、および、第１種ユーザとの間で行われる農水産物商品の注文又は入荷の交渉に関わる第２種ユーザにより操作される通信端末が接続可能な広域ネットワークに接続されるコンピュータシステムを、前記農水産物商品の契約取引における商談支援を行うシステムとして動作させるためのコンピュータプログラムである。
すなわち、前記コンピュータを、前記第１種ユーザ又は前記第２種ユーザの一方である提案元ユーザが前記第１種ユーザ又は前記第２種ユーザの他方となる１又は複数の提案先ユーザに提案する商談の条件データを当該提案元ユーザの通信端末より受領し、受領した前記条件データを含む商談データを前記提案先ユーザの数だけ生成するとともに、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第１処理手段、前記商談データを閲覧した前記１又は複数の提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを受領し、受領した返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第２処理手段、前記返答データを閲覧した提案元ユーザの通信端末から前記回答又は了承に対する合意又は中止を表す決定データを受領し、受領した決定データを前記回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録する第３処理手段、として機能させるためのコンピュータプログラムである。
【発明の効果】
【００１８】
本発明では、提案元ユーザが１又は複数の提案先ユーザに提案する商談の条件データを含む商談データを提案先ユーザの数だけ生成し、生成した各々の提案先ユーザ用の商談データを当該提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録しておく一方、提案先ユーザの通信端末から商談の辞退、了承又は回答のいずれかを表す返答データを提案元ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録し、さらに、返答データを閲覧した提案元ユーザの通信端末から回答又は了承に対する合意又は中止を表す決定データを回答又は了承を表す返答データを入力した提案先ユーザの通信端末が個別に閲覧可能な商談データ記録領域に登録するので、各ユーザは、商談内容のセキュリティ性を確保しつつ、自己が関わる商談の経緯を随時確認することができる。また、条件データの内容を適宜見直すことで、リスクの大きい農水産物商品の契約取引に柔軟に対応できるようになる。これにより第１種ユーザ、例えば産地ないし水揚地にとって、新しい卸との取引が可能となる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明を青果物の産地−卸間取引の支援を行う商談支援システムとして実施する場合の好ましい形態例を説明する。本例において、第１種ユーザは産地側組織の構成員（責任者、担当者等）、第２種ユーザは卸側組織の構成員（責任者、担当者等）である。必要に応じて産地側組織およびその構成員を「産地」又は「産地側」、卸側組織およびその構成員を「卸」又は「卸側」と略称する。
【００２０】
図１は、この実施形態による商談支援システムの全体構成図である。
この商談支援システム１は、広域ネットワークの一例となるインターネットＬを通じてアクセスされる複数の産地端末２、および、複数の卸端末３と双方向通信を行うことができるＷｅｂサーバである。
産地端末２と卸端末３は、例えば汎用のブラウザソフトがインストールされた通信機能付きのパーソナルコンピュータ、あるいは、社内ＬＡＮで構築された複数のコンピュータからなるシステムである。一つの産地に一つの産地端末２のみが設けられている場合のほか、一つの産地に複数の産地端末２が設けられている場合もある。後者の場合は、産地端末２を操作する者にそれぞれ商談決定権限に応じたレベルの利用権限情報を設定することになる。卸端末３についても同様である。利用権限情報については、後述する。
【００２１】
商談支援システム１は、図２に示されるように、ＣＰＵ、ＲＡＭ、ＲＯＭ等が搭載されたプロセッサボード１０と、インターネットＬを介して産地端末２、卸端末３との間で双方向通信を行うための通信インタフェース１１と、外部入出力装置ないしＬＡＮとの間で各種データの入出力を行うための入出力インタフェース１２と、ハードディスク、光磁気ディスク、半導体メモリ等から成る外部記憶装置１３と、を少なくとも具えている。
プロセッサボード１０は、外部記憶装置１３のプログラム領域に格納されている本発明の商談支援用プログラムを適宜ＲＡＭに展開してＣＰＵが実行することにより、Ｗｅｂサーバとしての機能と、商談支援に関する種々の機能とを実現する。
【００２２】
Ｗｅｂサーバの機能の一つは、アクセスしてきた産地端末２又は卸端末３に対して、それぞれのブラウザを通じて、個別に閲覧可能なデータ記録領域を提供する機能である。ここにいう「データ記録領域」とは必ずしも物理的な記録領域に限らず、論理アドレスによって特定される、表示用データが存在する領域であってもよい。この機能自体は、公知の手法を採用することができるが、本実施形態では、データ記録領域を、商談データを登録するための商談データ記録領域とし、どの産地端末２又は卸端末３にどの商談データ記録領域を提供するかは、ログインパスワードや利用権限情報に基づいて特定するようにしている。商談データ記録領域は、より具体的には、後述する各種ＤＢ１６〜１９の特定したフィールド領域に存する商談データを産地端末２又は卸端末３のブラウザに表示させるための表示領域である。商談データ記録領域にデータを登録するとは、各種ＤＢ１６〜１９のうち、上記の表示領域に関連付けられたフィールドにそのデータを登録するということと同義である。
【００２３】
商談支援に関する機能としては、大別して、ＤＢＭＳ（データベース管理システム）、システムログイン時の認証処理を行う認証処理部、商談の提案に関する情報処理を行う提案処理部、商談の交渉に関する情報処理を行う交渉処理部、商談後の販売実績に関する情報処理を行う販売実績処理部、および、出荷スケジュール管理部がある。提案処理部、交渉処理部、販売実績処理部では、それぞれ、データをデータ記録領域に登録する際に未開封フラグを付与し、この未開封フラグを当該データの発出元が閲覧可能な商談データ記録領域に登録するとともに、当該データが相手先のユーザに閲覧されたときは未開封フラグを開封フラグに変更する閲覧状態管理の機能をも有している。また、未開封フラグが付与されているデータの取り戻しを許容する機能も有している。
スケジュール管理部は、出荷スケジュールを定めた出荷カレンダを生成し、この出荷カレンダを、当該商談に関与する産地端末２又は卸端末３が個別に閲覧可能なデータ記録領域に登録し、各端末２、３のブラウザに表示させるようにする。出荷カレンダは、日々の出荷数量を産地端末２毎又は卸端末３毎の一取引単位の集計結果をカレンダ形式でレイアウトしたものである。出荷数量の部分は、商談対象となった青果物の等階級別の明細ファイルとリンクしており、ある出荷数量の部分をクリックすることにより、該当する等階級の明細が出荷カレンダの下位層の画面として表示されるようになっている。この出荷カレンダは、提案の合意画面、交渉の成立画面の双方から、画面上の「出荷カレンダ」のボタンをクリックすることにより表示される。
【００２４】
外部記憶装置１３のデータ領域には、商談データ、あるいはそれを管理するためのデータないしパラメータを蓄積するための複数のデータベース（ＤＢ）が形成される。図３は、これらのＤＢの構成を例示している。ここでは、青果物の、産地−卸間の契約取引に際して産地端末２および卸端末３より入力された提案情報、交渉情報の含むすべてのデータ（このようなデータを総称して商談データとする）を蓄積するための商談ＤＢ１６、このシステムで取り扱う青果物の品名、品種、銘柄等に関するデータである商品マスタを青果物の品目毎に格納するための商品マスタＤＢ１７、このシステムを利用するすべてのユーザのＩＤを含む属性情報を記述したユーザマスタを記録しておくためのユーザ情報ＤＢ１８、産地端末２又は卸端末３のブラウザに表示させるための各種データ入力（選択）用テンプレート（条件マスタ等）、一覧表表示用テンプレートのような予め登録された内容のものを表示させるための各種テンプレートを格納したテンプレートＤＢ１９などで構成する。これらのＤＢ１６〜１９は、上述したＤＢＭＳ１５により管理される。
【００２５】
商談ＤＢ１６には、商談データが、ＩＤ採番マスタにより他のものと重複することなく付与された各種ＩＤにより識別される複数のデータの集合として記録される。すなわち、商談ＤＢ１６は、商談データを直接又は間接につながる複数のテーブルの形態で管理して記録する。
図４は、商談データの構造を示した図である。商談データは、例えば、新規提案がある度に生成される提案商品ヘッド部Ｔ１２、提案ヘッド部Ｔ１３、提案明細Ｔ１４と、その提案に起因する交渉が始まる度に生成される交渉ヘッド部Ｔ１５、交渉明細Ｔ１６と、提案ないし交渉時に必要に応じて生成される付加条件Ｔ１７、提案および交渉の経過を記録するための提案・交渉ログＴ１８、および提案および交渉時に適宜参照される共通Ｔ１１により構成される。
【００２６】
共通Ｔ１１には、例えば、取引名称、青果物の品名・品種・銘柄、出荷団体、出荷者、生産者、販売期間、値決方法、交渉成立の有無、明細数、各種コメント等が記述される。提案商品ヘッド部Ｔ１２には、商品マスタＤＢ１７より読み出した商品マスタにより特定される提案商品ＩＤが記述される。提案ヘッド部１３には、提案がある度に付与される提案ＩＤ、提案先（交渉先）であるユーザ、例えば組織ＩＤ、担当者ＩＤ、閲覧済みかどうかを表す未開封／開封フラグ、合意された販売日、交渉引継の有無、各種期限、交渉開始等のデータが記述される。提案明細Ｔ１４には、明細番号のほかに、提案ＩＤ、組織ＩＤを含む提案内容の詳細な明細データが記述される。交渉ヘッド部Ｔ１５には、提案ＩＤ、組織ＩＤのほか、交渉に関して入力されたデータを識別するための交渉ＩＤ、取引先担当者ＩＤ、上記の開封／未開封フラグ、販売日、提案合意書、成立期限、開始日、実績入力／未入力フラグ、申込期限、合意期限等が記述される。交渉明細には、明細番号のほかに、提案ＩＤ、組織ＩＤを含む交渉内容の詳細な明細データが記述される。提案・交渉ログＴ１８には、提案ＩＤ、組織ＩＤ、交渉ＩＤ、データ発生の日時、データ入力に携わった担当者ＩＤ、修正前後データ等が記述される。なお、提案・交渉ログＴ１８は、提案ログ、交渉ログのように分離した存在であってもよい。
このように、各テーブルは、それぞれ共通の提案ＩＤ、組織ＩＤ、交渉ＩＤ等によってその一部又は全部がリンクするようになっている。
【００２７】
図５は、商談ＤＢ１６およびユーザ情報ＤＢ１８の構造を、複数種類の情報の相互関連性の視点で示したものである。図５右側に示されるように、ユーザ情報ＤＢ１８に格納される個々のユーザマスタにおいて記録されるユーザの属性情報は、産地又は卸の組織毎に、その組織を識別するための組織ＩＤ（例えば、産地は１０＊＊＊、卸は２０＊＊＊）、部署ＩＤ、担当者ＩＤと、各々のＩＤと１対１に対応付けられた利用権限情報が設定されている。利用権限情報は、システムログインのためのパスワードとして機能するとともに、そのＩＤによって閲覧可能な商談データの範囲を定めるものである。つまり、組織毎の商談の決定権限レベルに応じて決められたＩＤとなっている。
【００２８】
決定権限レベルに応じたＩＤの関係を、産地の組織構造を例に挙げて示すと、図６のようになる。すなわち、図６（ａ）の系統構造をもつ産地に関して、同（ｂ）のように利用権限情報の設定を行った場合、各系統の組織ないし担当者が閲覧可能となる商談データの範囲は、同（ｃ）のようになる。これらの図において、「個人」は担当者個人、「部署」は当該部署の責任者、「組織」はその組織の責任者を示す。「上部」は上位の組織があるかどうか、「下部」は下位の組織があるかどうかを示す。「参照可否」は、「○」であれば、参照可能なデータであることを示している。これらの図から明らかなように、より上位の組織は、その下位の組織の閲覧が可能になる。また、最上位の組織の一部の部署が下部組織となり得る場合にも「上部」としての組織権限を付与することにより、最上位組織と同等の商談データを閲覧できるようにすることもできる。
【００２９】
図５に戻り、その左側を参照すると、提案元ユーザから新規提案が発生したり、その提案に対する交渉が始まる度に、商談ＤＢ１６に設けられたＩＤ採番マスタ１６０で上述した各種ＩＤが採番されることが示されている。提案時には、提案基本条件情報１６１（提案ヘッド部Ｔ１３）、提案明細情報１６２（提案明細Ｔ１４）、提案履歴基本情報１６３ａ、提案履歴明細情報１６４ｂおよび提案ログ１６４（提案・交渉ログＴ１８）がそれぞれ該当テーブルの該当フィールドに記述される。交渉時には、交渉基本条件情報１６５（交渉ヘッド部Ｔ１５）、交渉明細情報１６６（交渉明細Ｔ１６）、交渉履歴基本情報１６７ａ，交渉履歴明細情報１６７ｂ，交渉ログ１６８（提案・交渉ログ１８）がそれぞれ該当テーブルの該当フィールドに記述される。付加条件情報１６９も付加条件Ｔ１７に記述される。
【００３０】
＜運用形態＞
次に、上記のように構成される商談支援システム１の運用形態を説明する。
[事前作業〜マスタ登録]
商談支援システム１を利用するすべてのユーザは、予め、自己の組織が産地側であるか卸側であるかを識別するための識別コード、組織毎、部署毎、担当者毎のＩＤおよびそのＩＤに対応付けられた利用権限情報、自己が扱う青果物の種類等を、ユーザ情報ＤＢ１８にユーザマスタとして登録する。予め商談を行いたい担当者を事前に登録しておくことも可能である。
【００３１】
商談支援システム１（認証処理部）は、ユーザマスタに登録されたユーザの利用権限情報毎にログイン時に使用するパスワード等を設定し、これを登録したユーザに付与する。
商品マスタＤＢ１７に格納される商品マスタ、テンプレートＤＢ１９に格納される条件マスタその他のテンプレートは、随時、本システムで補充・更新しておく。
【００３２】
［運用の概要]
商談支援システム１では、提案処理部により、担当者間で行われる契約取引の基本条件の提案、合意およびその確定を支援する「提案フェーズ」と、交渉処理部により、週単位での出荷物の数量と価格の調整を行うための「交渉フェーズ」とを有し、これらの２種類のフェーズを経て、契約取引の大まかな合意から確定までの流れに対応した情報処理を行う。提案フェーズでは、例えば出荷開始１年前〜出荷開始１ヶ月までに、提案条件を提案先ユーザである交渉相手に提示して契約取引の基本条件の合意をとり、必要に応じて、より詳細な付加条件も設定する。他方、交渉フェーズでは、例えば出荷前週までに提案フェーズで合意した内容をもとに、提案元ユーザと提案先ユーザとの間で週単位で数量と価格の調整を行い、契約の成立およびその確定のための処理を行う。以後の説明では、提案フェーズと交渉フェーズとの間の段階を「交渉前」と呼ぶ場合もある。
販売実績処理部は、卸側で販売を行ったときに卸端末３からの入力データについての情報処理を行う。以下、このような運用を実現するための詳細な手順を説明する。
【００３３】
［ログイン処理]
産地端末２又は卸端末３から最初のアクセスがあると、商談支援システム１は、図７に示した手順で、ログイン処理を行う。すなわち、産地端末２又は卸端末３に対してそれぞれログイン画面を表示する（ＬＳ０１，ＬＯ０１）。これらのログイン画面からユーザＩＤ（担当者のアクセスの場合はその担当者のＩＤ）およびパスワードが入力されると、商談支援システム１は、そのユーザについてのユーザマスタがユーザ情報ＤＢ１８に存在するかどうかをチェックする（ＬＣ０１）。存在する場合は、利用権限情報による機能選択を行う（ＬＣ０２）。すなわち、ユーザＩＤおよびパスワードから、アクセスしてきた担当者の組織が産地側か卸側か、また、どのような利用権限情報が設定されている担当者かを判別し、それぞれ実現すべき所要の機能の内容を選択する。
【００３４】
アクセスしてきた担当者が産地側の担当者であれば、その産地側担当者が関わる商談データを商談ＤＢ１６から検索し、提案・交渉中の最新情報一覧の画面をその担当者が操作する産地端末２のブラウザに表示させる（ＬＣ０３、ＬＳ０２）。図１７は、この最新情報一覧画面の内容を例示したものであり、画面４０の所定部位に、交渉内容の一覧を表示するための交渉一覧領域４０１、提案内容の一覧を表示するための提案一覧領域４０２、表示領域を切り替えるためのメニュー領域４０３等が形成されている。交渉一覧領域４０１および提案一覧領域４０２は、後述する提案合意後交渉が成立する前の内容が一覧形式で表示される。担当者が各一覧領域４０１，４０２に表示された情報の詳細を参照したり、商談に関するデータ入力を行うときは、メニュー領域４０３のリンク領域（アンダーラインにより明示されている領域）をクリックすることにより、それが可能になる。
【００３５】
アクセスしてきた担当者が卸側の担当者であれば、その卸側担当者が関わる商談データを商談ＤＢ１６から検索し、提案・交渉中の最新情報一覧を作成して、その画面をその卸側担当者が操作する卸端末３のブラウザに表示させる（ＬＣ０３、ＬＯ０２）。図１８は、この最新情報一覧画面の内容を例示したものであり、画面４０の所定部位に、上述したような交渉一覧領域４１１、提案一覧領域４１２、表示領域を切り替えるためのメニュー領域４１３が形成されている。担当者が、各一覧の詳細を参照したり、データ入力を行うときは、メニュー領域４１３のリンク領域をクリックすることにより、それが可能になる。
【００３６】
産地側の担当者がメニュー領域４０３から「産地提案一覧」を選択すると、商談支援システム１は、利用権限情報により閲覧可能とされる範囲の商談データを提案ＩＤで検索し（ＬＣ０４）、そのユーザ（担当者）毎の産地提案一覧の画面を作成し、この産地提案一覧の画面をその担当者が操作する産地端末２のブラウザに表示させる（ＬＣ０５、ＬＳ０３）。図１９は、この産地提案一覧画面の内容例を例示したものであり、産地提案一覧画面５０の所定部位に、その担当者が提案した提案情報の一覧の表示領域５０１が形成されている。この表示領域の各行方向のフィールドの先頭には「取引名称」の項目が挙げられているが、この取引名称は、上述したように、提案ＩＤと１対１に対応付けられており、商談ＤＢ１６では、提案ＩＤとして扱われている。
産地提案一覧画面５０には、また、新規に条件データ等を提案をするために「新規作成」のボタン画像５０２が形成されている。なお、産地提案一覧画面５０には、「新規作成」のほか、取引の担当者を変更するための「担当者変更」のボタン画像等も形成されている。
【００３７】
図１８に戻り、卸側の担当者がメニュー領域４１３から「提案一覧」を選択すると、商談支援システム１は、上記の場合と同様の手順で、そのユーザ（担当者）毎の卸提案一覧の画面を作成し、この卸提案一覧の画面をその担当者が操作する卸端末３のブラウザに表示させる（ＬＣ０４，ＬＣ０５、ＬＯ０３）。卸提案一覧の画面の内容は、産地側に関する事項が卸側に置き換わるだけで、ほぼ図１９に示したものと同様の内容となる。
【００３８】
［産地提案１：Ｎ］
次に、本発明の特徴の一つである、産地端末２からの提案に基づいて行われる１対Ｎスタイルの提案の手順について説明する。このスタイルによる提案では、商談支援システム１では、ある産地側担当者からＮの卸側担当者へ共通の提案情報を同時に投げかける。このような態様であっても、各卸側担当者からみれば、商談相手となる産地側担当者は１人であり、１対１の相対取引となる。卸側担当者から産地側担当者への返答および卸提案は、取引者名を指定して個別的に行う。つまり、この商談支援システム１では、基本的には、産地側担当者と卸側担当者が１対１で行う相対取引を支援するようになっている。
【００３９】
このスタイルの提案処理の手順を以下に説明する。
図１９に例示された産地提案一覧画面５０が産地端末２のブラウザに表示されている状態（ＴＳ０１）で、「新規作成」のボタン画像５０２がクリックされることによって提案の指示があると、商談支援システム１は、商品マスタＤＢ１７から提案商品マスタを検索し（ＴＣ０１）、その提案商品マスタに基づく提案商品選択の画面を、図１９の産地提案一覧画面５０の下位層の画面として産地端末２のブラウザに表示させる（ＴＣ０２、ＴＳ０２）。図２０は、このようにして表示が切り替わる提案商品選択画面５０の内容を例示した図である。この提案商品選択画面５０には、提案商品である青果物の品名並びにその商品名について定められている取引内容（取引名称、条件等）を選択するための品名選択領域５０３と、その商品名について品種毎に定められている取引内容が存在するときは、それらのいずれかを選択するための品種別取引内容選択領域５０４とが形成されている。
なお、図示を省略したが、品種毎にリンク領域が形成されており、このリンク領域をクリックするなどして選択することにより、その品種別の取引内容が選択できるようになっている。
【００４０】
いま、提案商品選択画面５０の品名選択領域５０３を通じて商品Ａ（および品種Ｂ：図示省略）が選択されたとすると、商談支援システム１は、その商品Ａ、品種Ｂに関する取引の設定条件をテンプレートＤＢ１９に格納されている条件マスタを検索することにより特定し、条件設定のための画面を、図２０に示した提案商品選択画面５０の下位層の画面として産地端末２のブラウザに表示させる（ＴＣ０３，ＴＳ０３）。図２１は、このようにして切り替わる条件設定画面の内容を例示した図である。この条件設定画面５０には、出荷団体名、出荷者、販売期間、販売曜日、値決方法（週間等）、申込期限、合意期限等の提案基本条件を設定するための基本条件設定領域５０５と、個印、荷姿、量目、等級、階級、入数、箱数、価格等の明細条件を設定するための明細設定領域５０６とが形成されている。担当者がこれらの領域５０５，５０６に所望の条件データを入力すると、商談支援システム１は、品種Ｂの商品Ａを扱うすべての卸側担当者をユーザ情報ＤＢ１８から検索するとともに、その卸側担当者を確認させるための取引者担当者確認のための画面を、図２１の条件設定画面５０の下位層の画面として産地端末２のブラウザに表示させる（ＴＣ０４，ＴＳ０４）。この取引者担当確認画面の内容例を図２０に示す。この取引者担当確認画面５０には、商品名、上述のようにして設定された条件等の確認用の領域５０７と、取引先担当者候補が表示された担当者選択領域５０８とが形成されている。担当者選択領域５０８に表示される取引先担当者名は、ユーザ属性の登録時にその青果物を取り扱う旨を併せて登録した担当者名である。画面表示上は、担当者名であるが、システム上は、担当者ＩＤおよび通信アドレス等により特定されるようになっている。
【００４１】
産地端末２を操作する担当者が担当者選択領域５０８の該当フィールドをクリックして有効化するなどして、複数の卸側担当者を確認すると、商談支援システム１は、確認領域５０７に記録されている各種提案条件と、提案元ユーザである産地端末２を操作する担当者のＩＤと提案ＩＤ等を含む商談データを、卸側担当者の数だけ複写するなどして作成し、作成した各商談データを、さらに卸側担当者毎のＩＤを付与して個性化して、各卸側担当者が操作する卸端末３が閲覧可能な商談データ記録領域に登録する。他の産地側担当者も同様の手順で、同じ卸側担当者宛の商談データを作成している場合があるので、商談支援システム１は、担当者ＩＤにより特定される卸側担当者毎の提案一覧を作成して上記商談データ記録領域に登録し、これらを各卸側担当者が操作する卸端末３のブラウザに表示させる（ＴＣ０５、ＴＯ０１）。
【００４２】
提案一覧およびその詳細内容を閲覧した卸端末３を操作する卸側担当者からは、それぞれ、提案内容に対する辞退、回答、了承を表す返答データが、提案ＩＤにより特定される提案内容を含む商談データ毎に、個別的に商談支援システム１に入力される。「辞退」は産地側の提案内容を受けないことの意思表示である。「回答」は提案内容の修正を要請することの意思表示、「了承」は産地側の提案内容を修正することなく受け容れるという意思表示である。
【００４３】
商談支援システム１は、卸側担当者からの返答データを提案ＩＤにより特定される商談データの一部として商談ＤＢ１６の該当フィールドに追記するとともに、提案ＩＤ毎に集計する（ＴＣ０６）。そして、提案一覧を産地側担当者毎に作成し、これを当該産地側担当者が操作する産地端末２のブラウザに表示させる（ＴＣ０７）。産地端末２のブラウザには、その提案に関する交渉前の提案一覧の画面として表示される（ＴＳ０５）。
【００４４】
提案元ユーザである産地側担当者は、これらの返答データのうち、「辞退」に対しては返答データを閲覧した時点でその卸側担当者に対する提案フェーズは完結する。「回答」に対しては、提案内容を修正して再提案する「再要請」、卸側担当者からの回答内容で合意することを表す「合意」、その卸側担当者との取引を断念する「中止」のいずれかを表す決定データを選択する。商談支援システム１は、この決定データを返答データを入力した卸端末３のブラウザに表示させる。「合意」、「中止」のときはその提案内容について卸側担当者が閲覧した時点でその提案内容に対するその卸側担当者に対する提案フェーズは完結する。再要請に対して、卸側担当者により「辞退」あるいは「了承」が選択されたことを産地側担当者が確認した場合も提案フェーズが完結する。再び「回答」が選択された場合は、上記の処理を繰り返す。このようにして、１対Ｎスタイルの提案処理を行う。
【００４５】
［全体処理］
次に、図９〜図１６を参照して、提案フェーズおよび交渉フェーズを含む全体処理における、商談支援システム１と、産地端末２のアクションおよび卸端末３のアクションとの関係を説明する。全体処理は、産地端末２あるいは卸端末３において、各担当者が関わる取引についての商談データがブラウザで閲覧されたことを当該商談データの入力元に提示する「開封」（未開封フラグから開封フラグに変更されたことを意味する）と未だ閲覧されていない状態を提示する「未開封」（未開封フラグのままであることを意味する）によって、アクション可能な範囲が異なる。以下、この点を中心に説明する。図９〜図１１および図１４〜図１６において、単一の楕円は、相手方に対する返事を要しないイベントに対するアクションのステータスを表しており、二重の楕円は、相手方に対する返事を必須とするイベントに対するアクションのステータスを表す。相手方に対する返事を必須とするので、通常は、期限付きのアクションとなる。例えば図９において、「（再）提案」は、提示側からみれば、期限付で「（再）提案中」というステータスとなり、受側では○○日までの「（再）提案有り」というステータスとなる。他のイベントについても同様の関係がある。
【００４６】
＜産地提案１：Ｎ＞
図９は、上述した産地１：Ｎ提案の手順を俯瞰的に記述している。図９において「提示側」は産地（産地側担当者が操作する産地端末２）、「受側」は卸売会社（卸側担当者が操作する卸端末３）である。「Ｓ」は新規提案開始、「Ｅ」は提案フェーズ終了を意味している。
【００４７】
図９において、「提案未選択」は、特定の卸売会社を提案先ユーザとして選択しなかった場合において、それらの選択しなかった卸売会社の担当者に、参照のみが可能な提案を「提案未選択」というステータスで作成することを意味する。この提案は、産地側担当者から入力され、選択した取引先だけに送付される（ＳＴ１０１）。情報不達の場合（ＳＴ１０２）、１：Ｎの提案に関する処理は終了する。
上記以外の「提案」が発生したときは（ＳＴ１０３）、受側がその内容を開封したかどうかで、手順が異なる（ＳＴ１０４）。未開封のうちは、提案を取り戻し、その内容を修正して「再提案」を発生させることができる。受側が未開封のうちに「中止」を選択した場合は（ＳＴ１０５）、その「提案」を受側が開封した時点で（ＳＴ１０６）処理は終了する。「中止」が選択されなかった提案内容を受側が開封した後は、以下のような手順で処理が進む。
受側が「辞退」したときは（ＳＴ１０７）、それを提示側が開封した時点（ＳＴ１０８）で処理は終了する。受側が「回答」を発生させたときは（ＳＴ１０９）、その回答内容を提示側が開封（ＳＴ１１０）するまで、取り戻し、すなわち回答内容を修正することができる。これは、青果物の性質上、約束した取引期間を守ることができなかったりする場合、あるいは、販売終了時期が早まったり、逆に遅れる場合があるためである。また、市況が低迷し、買い手側がキャンセルする場合もあるためである。提示側が開封した後は、提示側で「再提案」を発生するのであれば、ＳＴ１０３に戻る。提示側の「中止」（ＳＴ１１１）又は「合意」（ＳＴ１１２）を受側で開封した時点（ＳＴ１１３）で処理を終了する。
受側で「了承」したときは（ＳＴ１１４）、提示側でそれを開封し（ＳＴ１１５）、且つ、提示側で「合意」（ＳＴ１１６）あるいは「中止」（ＳＴ１１７）を選択したことを受側で開封した時点（ＳＴ１１８）で、処理は終了する。ＳＴ１１２およびＳＴ１１６における「合意」のとき（このようなイベントがシステムにおいて発生したとき）は、後述する「交渉前」の処理を行う。
【００４８】
＜卸提案１：１＞
図１０は、卸１：１提案の手順を俯瞰的に記述している。図１０において「提示側」は卸売会社（卸側担当者が操作する卸端末３）、「受側」は産地（産地側担当者が操作する産地端末２）である。「Ｓ」は新規提案開始、「Ｅ」は提案フェーズ終了を意味している。
この例の場合、卸端末３から「提案」があったときは（ＯＴ１０１）、受側がその内容を開封したかどうかで、手順が異なる（ＯＴ１０２）。受側が未開封のうちは、「提案」を取り戻し、提案内容を修正することができる。また、受側が未開封のうちに「中止」を選択した場合（ＯＴ１０３）、それを受側が開封した時点で（ＯＴ１０４）処理は終了する。
提案内容を受側が開封した後は、以下のような手順で処理が進む。
受側が「辞退」したときは（ＯＴ１０５）、提示側が開封した時点（ＯＴ１０６）で処理は終了する。受側が「回答」したときは（ＯＴ１０７）、その回答内容を提示側が開封（ＯＴ１０８）するまで、取り戻し、すなわち回答内容を修正することができる。提示側が開封した後は、「再提案」であれば、ＯＴ１０１に戻る。提示側の「中止」（ＯＴ１０９）又は「合意」（ＯＴ１１０）を受側で開封した時点（ＯＴ１１１）で処理を終了する。
受側で「了承」したときは（ＯＴ１１２）、提示側でそれを開封し（ＯＴ１１３）、且つ、提示側で「合意」（ＯＴ１１４）あるいは「中止」（ＯＴ１１５）を選択したことを受側で開封した時点（ＯＴ１１６）で、処理は終了する。図９の場合と同様、ＯＴ１１０およびＯＴ１１４における「合意」のときは、後述する「交渉前」の処理を行う。
【００４９】
＜代行提案１：１＞
商談支援システム１では、一定の条件下で、卸提案（１：１）を産地側担当者が代行入力することを許容している。図１１は、このときの代行提案の手順を俯瞰的に記述している。図１１において「提示側」は産地（産地側担当者が操作する産地端末２）、「受側」は卸売会社（卸側担当者が操作する卸端末３）である。「Ｓ」は新規提案開始、「Ｅ」は提案フェーズ終了を意味している。
この処理の場合は、「回答」（ＤＴ１０１）が起点となる。回答内容は、受側が未開封（ＤＴ１０２）のうちは、それを取り戻してその内容を修正することができる。また、受側が未開封のうちに受側が「辞退」を選択した場合（ＤＴ１０３）、それを提示側が開封した時点で（ＤＴ１０４）処理は終了する。
回答内容を提示側が開封した後は、以下のような手順で処理が進む。
提示側が「中止」（ＤＴ１０５）、あるいは「合意」（ＤＴ１０６）、受側が開封した時点（ＤＴ１０７）で処理は終了する。提示側が「再提案」したときは（ＤＴ１０８）、その再提案内容を受側が開封（ＤＴ１０９）するまで、取り戻し、すなわち再提案内容を修正することができる。受側が開封した後は、「再回答」するのであればＤＴ１０１に戻る。受側の「辞退」（ＤＴ１１０）を提示側で開封した時点（ＤＴ１１１）で処理を終了する。
受側で「了承」したときは（ＤＴ１１２）、提示側でそれを開封し（ＤＴ１１３）、且つ、提示側で「合意」（ＤＴ１１４）あるいは「中止」（ＤＴ１１５）を選択したことを受側で開封した時点（ＤＴ１１６）で、処理は終了する。なお、ＤＴ１０６およびＤＴ１１４における「合意」のときは、後述する「交渉前」の処理を行う。
以上のような手順で行われる提案の経過を表すデータは、適宜、担当者より入力され、ＤＢＭＳ１５を通じて商談ＤＢ１６に蓄積される。
【００５０】
＜交渉前処理＞
図９〜図１１の処理において提示側で「合意」したときは（ＳＴ１１２，ＳＴ１１６，ＯＴ１１０，０Ｔ１１４）、少なくとも当該時点において提案された内容が一時的に確定する。商談支援システム１では、このように一時的に確定した提案内容をもとに、支援フェーズに先だつ「交渉前」のイベントを発生させるための処理を行う。「交渉前」は、産地／卸のどちらの担当者が先に交渉を開始するか、販売期間をどうするか等を表す交渉データを生成し、この交渉前データを産地端末２および卸端末３の双方のブラウザに表示させて、所定周期例えば一方の担当者から他方の担当者宛の各データを入力させ、あるいは、入力された各データを修正させながら取引内容の大枠を決めていくイベントである。青果物の生産時期や生産量は、天候等に大きく左右されるため、データ入力ないし修正を所定の周期、例えば１週間毎に行う。ある週において、各担当者の少なくとも一方が当該週の交渉データを閲覧しなかった場合には、当該週の交渉データを翌週分に繰り上げて表示させる。
【００５１】
図１２は、この「交渉前」のイベントを発生させるための処理手順説明図である。商談支援システム１では、提示側で「合意」を選択すると（ＢＡ１０１：Ｙｅｓ）、取引期間等で合意された内容に基づいて販売期間１週目に交渉すべき情報が何かを判断し（ＢＡ１０２）さらに、どちらの担当者が先に交渉を始めるかという情報（担当者入力）に基づいて次の回答権を有する担当者がどちらの担当者かを判断する（ＢＡ１０３）。その後、これらの情報と合意内容を反映させた情報とを基に１週目の交渉データを生成し（ＢＡ１０４）、「交渉前」のイベントを産地端末２および卸端末３において発生させる。「合意」がなかった場合には、以上の処理は回避される。
【００５２】
このようにして、生成された交渉データは、例えば図１７および図１８の交渉一覧領域４０１，４１１のようなものであるが、より詳細に内容を確認することができる。すなわち、図２３は、合意が得られた提案内容を詳細に表示させた結果参照（提案）画面であり、産地端末２および卸端末３のブラウザから「結果参照（提案）」のリンクをクリックすることにより、商談ＤＢ１６の該当アドレスに記録されているデータの内容を適宜読み出して確認することができる。図２３の例では、結果参照画面６０の書誌事項領域６０１に、合意した担当者同士の名称、品名・品種、販売日（予定日）販売期限、申込期限等の書誌事項が提案ＩＤ毎に表示される。提案ＩＤの枝番として交渉ＩＤも表示されるようにしてもよい。合意内容の詳細は、数情報領域６０１、明細領域６０２および付加条件領域６０３より確認することができる。
【００５３】
２週目以降は、図１３に示される所定手順で「交渉前」のイベントが発生する。すなわち、例えば図１７および図１８の「交渉一覧」のリンクを通じて提案側の担当者から「次週作成」のボタン画像（図示していない）が押下されるなどにより（ＢＢ１０１：Ｙｅｓ）、前回交渉データを反映した交渉データを生成し（ＢＢ１０２）、新たに「交渉前」イベントを発生させる。「前回交渉データを反映した交渉データ」とは、例えば前週が閲覧されなかった交渉データをコピーして、それを翌週の交渉データにすることをいう。通常は、１つの合意された提案について、図１３の手順を複数ループ繰り返すことになる。
【００５４】
＜交渉＞
図１４は、交渉フェーズでの処理手順を俯瞰的に記述している。図１４において「提示側」は産地（産地側担当者が操作する産地端末２）又は卸売会社（卸側担当者が操作する卸端末３）の一方、「受側」はその他方である。「Ｓ」は新規交渉開始、「Ｅ」は交渉フェーズ終了を意味している。
上述した「交渉前」（Ｋ１０１）により、合意内容が反映された交渉データを回答権を有する担当者（提示側）が開封（Ｋ１０２）した場合は、以下のような手順で、処理が進む。提示側による「中止」（Ｋ１０３）又は「成立」（Ｋ１０４）を受側で開封した時点（Ｋ１０５）で処理は終了する。提示側が修正のための「要請」を発生させた場合（Ｋ１０６）、受側が未開封のうちは、「要請」を取り戻し、要請内容を修正することができる。この「要請」を受側で開封した後（Ｋ１０７）は、受側の「回答」（Ｋ１０８）を提示側が開封するまでは（Ｋ１０９）、受側で回答内容を修正することができる。提示側開封後、「再要請」（Ｋ１１０）があったときは、受側でそれを開封するまで修正することができる。「再要請」を受側が開封した後は、Ｋ１０８、Ｋ１１６、Ｋ１１７の処理に進む。Ｋ１０９において提示側が開封し、且つ、提示側が「成立」（Ｋ１１２）又は「中止」（Ｋ１１３）したことを受側が開封した時点（Ｋ１１４）で処理は終了する。提示側の「再要請」に対して受側の「辞退」（Ｋ１１５）を提示側が開封したときも（Ｋ１１６）処理は終了する。
また、受側の「了承」（Ｋ１１７）を提示側で開封し（Ｋ１１８）、且つ、提示側の「成立」（Ｋ１１９）又は「中止」（Ｋ１２０）を受側で開封した時点（Ｋ１２１）で処理は終了する。
【００５５】
値決め方式や交渉サイクルは多様であり、例えば、品目によっては前週の交渉成立日までに、翌週分のすべての曜日の数量と価格を調整するのが困難な場合があり、週の前半と後半に分けて交渉する必要がある。このように値決方法が週２回にわたる場合、交渉フェーズを週の前半についての交渉処理と週の後半についての交渉処理の２通りに分けることができる。週前半の交渉処理と週後半の交渉処理が一対となって、週間での数量と価格の調整が実現可能となる。
図１５は、このような週前半の交渉処理の手順を示している。
【００５６】
図１５において、「提示側」は産地（産地側担当者が操作する産地端末２）又は卸売会社（卸側担当者が操作する卸端末３）の一方、「受側」はその他方である。「Ｓ」は新規交渉開始、「★」は後半起点を意味している。
上述した「交渉前」（ＦＫ１０１）により、合意内容が反映された交渉データを回答権を有する担当者（提示側）が開封（ＦＫ１０２）した場合は、以下のような手順で、処理が進む。
提示側による「前半中止」（ＦＫ１０３）を受側で開封した時点（ＦＫ１０４）で前半処理は終了する。提示側を「前半要請」した場合（ＦＫ１０５）、受側未開封のうちは、「前半要請」を取り戻し、その内容を修正することができる。受側が開封した後（ＦＫ１０６）は、受側の「前半回答」（ＦＫ１０７）を提示側が開封するまでは（ＦＫ１０８）、受側で前半回答の内容を修正することができる。提示側開封後、「前半再要請」（ＦＫ１０９）があったときは、受側でそれを開封するまで修正することができる。「前半再要請」を受側が開封した後は、ＦＫ１０７、ＦＫ１１４、ＦＫ１１６の処理に進む。
ＦＫ１０８において提示側が開封し、且つ、提示側が「前半成立」（ＦＫ１１１）又は「前半中止」（ＦＫ１１２）したことを受側が開封した時点（ＦＫ１１３）で前半処理は終了する。提示側の「前半再要請」に対して受側の「前半辞退」（ＦＫ１１４）を提示側が開封したときも（ＦＫ１１５）前半処理は終了する。
また、受側の「前半了承」（ＦＫ１１６を提示側で開封し（ＦＫ１１７）、且つ、提示側の「前半成立」（ＦＫ１１８）又は「前半中止」（ＦＫ１１９）を受側で開封した時点（ＦＫ１２０）で前半処理は終了する。
【００５７】
後半処理は、図１６の手順で処理が進む。すなわち、提示側による後半ボタン押下（ＡＫ１０１）によって後半処理が再開する。
提示側が開封した場合において、提示側による「後半中止」（ＡＫ１０２）を受側で開封した時点（ＡＫ１０３）で後半処理は終了する。提示側を「後半要請」した場合（ＡＫ１０４）、受側未開封のうちは、「後半要請」を取り戻し、その内容を修正することができる。受側が開封した後（ＡＫ１０５）は、受側の「後半回答」（ＡＫ１０６）を提示側が開封するまでは（ＡＫ１０７）、受側で後半回答の内容を修正することができる。提示側開封後、「後半再要請」（ＡＫ１０８）があったときは、受側でそれを開封するまで修正することができる。「後半再要請」を受側が開封した後は、ＡＫ１０６、ＡＫ１１３、ＡＫ１１５の処理に進む。
ＡＫ１０７において提示側が開封し、且つ、提示側が「後半成立」（ＡＫ１１０）又は「後半中止」（ＡＫ１１１）したことを受側が開封した時点（ＡＫ１１２）で後半処理は終了する。提示側の「後半再要請」に対して受側の「後半辞退」（ＡＫ１１３）を提示側が開封したときも（ＡＫ１１４）後半処理は終了する。
また、受側の「後半了承」（ＡＫ１１５）を提示側で開封し（ＡＫ１１６）、且つ、提示側の「後半成立」（ＡＫ１１７）又は「後半中止」（ＡＫ１１８）を受側で開封した時点（ＡＫ１１９）で後半処理は終了する。
以上のような手順で行われる契約の経過を表すデータは、適宜、担当者より入力され、ＤＢＭＳ１５を通じて商談ＤＢ１６に蓄積される。
【００５８】
このようにして、行われた交渉の結果は、任意の時点で、商談ＤＢ１６の該当アドレスより読み出して、詳細に内容を確認することができる。すなわち、図２４は、成立した商談内容を詳細に表示させた結果参照（交渉）画面であり、産地端末２および卸端末３のブラウザから「結果参照（交渉）」のリンクをクリックすることにより、該当するアドレスに記録されているデータの内容を適宜読み出して確認することができる。図２４の例では、結果参照画面６０の書誌事項領域６０５に、成立した商談の経過およびその結果等の書誌事項が提案ＩＤ毎に表示される。ここでも、提案ＩＤの枝番として交渉ＩＤも表示されるようにしてもよい。成立した内容の詳細は、数および金額情報領域６０６、週単位の明細領域６０７により確認することができる。
【００５９】
このように、本実施形態の商談支援システム１では、産地側担当者が操作する産地端末２から青果物の出荷に対する条件データを受領し、受領した条件データを含む提案用の商談データを、提案したい卸側担当者が操作する卸端末３の数だけ生成し、各商談データを卸端末３のブラウザに個別に表示させるようにし、商談データを閲覧した卸端末３から商談の辞退、了承又は回答のいずれかを表す返答データを受領したときは、それを提案元の産地端末２のブラウザに一覧表示させ、返答データを閲覧した提案元の産地側担当者から回答又は了承に対する合意又は中止を表す決定データが入力されたときは、それを回答又は了承を入力した卸端末３のブラウザに個別に表示させるようにしたので、産地側担当者と卸側担当者の１対１の相対取引のほか、１対Ｎ（Ｎは２以上の自然数）の取引をも可能することができる。しかも産地側担当者および卸側担当者は、それぞれ商談データを、自己の産地端末２又は卸端末３のブラウザで個別に閲覧するので、商談のセキュリティ性も確保することができる。
【００６０】
なお、本実施形態では、農水産物商品の例として青果物を挙げたが、他の種類の農産物ないしその加工品、あるいは水産物についても同様に適用が可能なものである。本実施形態において説明した産地は、加工品の場合は「加工地」、水産物の場合は「水揚地」と適宜読み替えることで、これらの商品についての商談支援のための情報処理を行うことが可能になる。
【図面の簡単な説明】
【００６１】
【図１】本発明を適用した商談支援システムの接続状態を示した図。
【図２】商談支援システムの要部ハードウエア構成図。
【図３】外部記憶装置に構築されるＤＢ（データベース）システムの構成図。
【図４】本実施形態における商談データの構造説明図。
【図５】商談ＤＢおよびユーザ情報ＤＢにおける情報関連図。
【図６】（ａ）はユーザの組織構造の説明図、（ｂ）は利用権限情報の設定状態を示した図表、（ｃ）は（ｂ）の設定内容に基づく閲覧（参照）可能な範囲を示した図表。
【図７】商談支援システムにおけるログイン時の手順説明図。
【図８】商談支援システムにおける産地１対Ｎ提案時の手順説明図。
【図９】産地１対Ｎ提案時の産地端末のアクションと卸端末のアクションとの関係を示したシーケンス図。
【図１０】産地１対１提案時の産地端末のアクションと卸端末のアクションとの関係を示したシーケンス図。
【図１１】卸１対１提案時の産地端末のアクションと卸端末のアクションとの関係を示したシーケンス図。
【図１２】交渉前のイベントを発生させるための処理の手順説明図（第１週分）。
【図１３】交渉前のイベントを発生させるための処理の手順説明図（第２週以降）。
【図１４】交渉時の産地端末のアクションと卸端末のアクションとの関係を示したシーケンス図。
【図１５】値決方法が週２回の場合における前半交渉処理時の産地端末のアクションと卸端末のアクションとの関係を示したシーケンス図。
【図１６】値決方法が週２回の場合における後半交渉処理時の産地端末のアクションと卸端末のアクションとの関係を示したシーケンス図。
【図１７】産地端末のブラウザに表示される、その産地に関する提案・交渉中の最新情報一覧の画面例。
【図１８】卸端末のブラウザに表示される、その卸に関する提案・交渉中の最新情報一覧の画面例。
【図１９】産地端末のブラウザに表示される、産地提案一覧の画面例。
【図２０】産地端末のブラウザに表示される、提案商品選択の画面例。
【図２１】産地端末のブラウザに表示される、条件設定の画面例。
【図２２】産地端末のブラウザに表示される、取引者担当確認の画面例。
【図２３】産地端末のブラウザに表示される、結果参照（提案）画面例。
【図２４】産地端末のブラウザに表示される、結果参照（交渉）画面例。
【符号の説明】
【００６２】
１６  商談ＤＢ
１７  商品マスタＤＢ
１８  ユーザ情報ＤＢ
１９  テンプレートＤＢ
Ｌ      インターネット
１    商談支援システム
２    産地端末
３    卸端末
１０  プロセッサボード
１１  通信インタフェース
１２  入出力インタフェース
１３  外部記憶装置
４０、５０  ブラウザに表示される画面
【図１】
2005332230.tif 000003
【図２】
2005332230.tif 000004
【図３】
2005332230.tif 000005
【図４】
2005332230.tif 000006
【図５】
2005332230.tif 000007
【図６】
2005332230.tif 000008
【図７】
2005332230.tif 000009
【図８】
2005332230.tif 000010
【図９】
2005332230.tif 000011
【図１０】
2005332230.tif 000012
【図１１】
2005332230.tif 000013
【図１２】
2005332230.tif 000014
【図１３】
2005332230.tif 000015
【図１４】
2005332230.tif 000016
【図１５】
2005332230.tif 000017
【図１６】
2005332230.tif 000018
【図１７】
2005332230.tif 000019
【図１８】
2005332230.tif 000020
【図１９】
2005332230.tif 000021
【図２０】
2005332230.tif 000022
【図２１】
2005332230.tif 000023
【図２２】
2005332230.tif 000024
【図２３】
2005332230.tif 000025
【図２４】
2005332230.tif 000026