JP2009238100A - 販売支援装置、販売支援プログラム、および販売支援方法 - Google Patents

Abstract

【課題】信用情報と自社の顧客情報との内容を考慮した取引条件の判定を迅速に行うことができるようにする。
【解決手段】取引条件記憶手段１ｃは、顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶している。取引条件決定手段１ｅは、注文用端末２から取引相手顧客を指定した取引条件取得要求が入力されると、顧客情報記憶手段１ａから取引相手顧客の与信情報を取得すると共に、取引履歴記憶手段１ｂから取引相手顧客との取引履歴を取得する。そして、取引条件決定手段１ｅは、取引条件記憶手段１ｃを参照し、取引相手顧客の与信情報と取引履歴とに応じた取引条件を決定する。取引条件送信手段１ｆは、取引条件決定手段１ｅが決定した取引条件を注文用端末２に送信する。
【選択図】図１

Description

本発明は商品の販売を支援するための販売支援装置、販売支援プログラム、および販売支援方法に関し、特に顧客の信用情報を利用した販売支援を行う販売支援装置、販売支援プログラム、および販売支援方法に関する。

製品等の販売会社では、電話やインターネット経由による製品販売の購入相談窓口が設けられている。このような購入相談窓口には、信用度が不明な会社を含めて、様々な会社からの商品の購入希望の連絡が入る。購入希望の中には、法人の顧客が掛買いを要望する場合がある。掛買いの場合、商品が先に引き渡され、後に代金が支払われる。そのため、販売会社では、代金を受け取れない可能性が生じ、掛売りにはリスクが伴う。

そこで、販売会社は、信用できない相手からの掛買いの依頼は断る必要がある。すなわち、販売会社は、掛買いの場合、顧客の信用度を書類上で審査する。顧客の信用度は、例えば、信用調査会社から取得した該当顧客の信用情報に基づいて判断される（例えば、特許文献１参照）。そして、顧客が信用できる会社だと判断した場合においてのみ、掛売りを実施する。

ところで、顧客の信用の審査過程では、企業の「規模」「業績」「経過年数」など多岐にわたる項目を調べ、かつ経理部門への通知および許可が必要となることが多い。このような審査は、できるだけ迅速に行われるのが理想である。審査が長期間に及ぶと顧客が商品の購入を思い直す可能性が高くなり、販売機会の喪失に繋がるためである。そこで、経理部門での審査を迅速に行うために、審査に必要な情報を審査依頼に添付してデータベースに格納し、その審査依頼を営業所からの要求に応じて送信するシステムが考えられている（例えば、特許文献２参照）。
特開２００５−３３２０６６号公報 特開２００１−２２９２２７号公報

しかし、実際に売買契約を締結してよいかどうかは、信用調査会社による顧客の信用情報だけでなく、自社との取引実績や購入希望数量などの他の要素を勘案して判断される。信用調査会社以外から取得する情報としては、例えば、その企業が開設しているウェブサイト内の情報、自社でもっている顧客情報データベースなどのデータがある。これら情報は、販売会社の担当営業が自ら調べて、審査依頼の書類に添付することとなり、情報の収集や整理に時間を要する。その結果、依然として、顧客に対して実際に販売できるか否かの判定が下るのに時間を要していた。

本発明はこのような点に鑑みてなされたものであり、信用情報と自社の顧客情報との内容を考慮した取引条件の判定を迅速に行うことができる販売支援装置、販売支援プログラム、および販売支援方法を提供することを目的とする。

上記課題を解決するために、販売を支援する販売支援装置が提供される。販売支援装置は、顧客情報記憶手段、取引履歴記憶手段、取引条件記憶手段、取引条件決定手段、および取引条件送信手段を有する。顧客情報記憶手段は、顧客の与信情報を記憶する。取引履歴記憶手段は、顧客との過去の取引履歴を記憶する。取引条件記憶手段は、顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する。取引条件決定手段は、注文用端末から取引相手顧客を指定した取引条件取得要求が入力されると、顧客情報記憶手段から取引相手顧客の与信情報を取得し、取引履歴記憶手段から取引相手顧客との取引履歴を取得し、取引条件記憶手段を参照し、取引相手顧客の与信情報と取引履歴とに応じた取引条件を決定する。取引条件送信手段は、取引条件決定手段が決定した取引条件を注文用端末に送信する。

このような販売支援装置によれば、注文用端末から取引条件取得要求が入力されると、取引相手顧客の与信情報と取引履歴とに応じた取引条件が決定され、決定した取引条件が注文用端末に送信される。

また、上記課題を解決するために、上記販売支援装置の機能をコンピュータで実現するための販売支援プログラムが提供される。さらに、上記課題を解決するために、上記販売支援装置の処理をコンピュータが実行する販売支援方法が提供される。

上記販売支援装置、販売支援プログラム、および販売支援方法では、信用情報と自社の顧客情報との内容を考慮した取引条件の判定を迅速に行うことが可能となり、売買契約を素早く締結できる。

以下、本発明の実施の形態を図面を参照して説明する。
図１は、実施の形態の概要を示す図である。販売支援装置１は、顧客情報記憶手段１ａ、取引履歴記憶手段１ｂ、取引条件記憶手段１ｃ、進捗情報記憶手段１ｄ、取引条件決定手段１ｅ、取引条件送信手段１ｆ、および審査管理手段１ｇを有する。

顧客情報記憶手段１ａは、顧客の与信情報を記憶する。与信情報は、例えば、顧客の信用度を数値化した評点である。
取引履歴記憶手段１ｂは、顧客との過去の取引履歴を記憶する。取引履歴によって、例えば、顧客ごとの過去の取引回数を知ることができる。取引履歴記憶手段１ｂには、過去に行われた取引の内容を示す既取引案件情報に加えて、注文を受けて取引の承認を待つ段階にある審査過程案件情報が、取引履歴として格納される。

取引条件記憶手段１ｃは、顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する。取引条件記憶手段には、例えば、取引条件として、与信情報による信用度が高いほど高い値となると共に、過去の取引回数が多いほど高い値となる割引率が設定されている。

進捗情報記憶手段１ｄは、審査過程案件情報の確認の有無を示す確認状態を記憶する。確認状態は、前記審査過程案件情報が確認担当者によって内容確認を経た後に承認される場合に使用される。

取引条件決定手段１ｅは、注文用端末から取引相手顧客を指定した取引条件取得要求が入力されると、顧客情報記憶手段１ａから取引相手顧客の与信情報を取得する。また、取引条件決定手段１ｅは、取引履歴記憶手段１ｂから取引相手顧客との取引履歴を取得する。そして、取引条件決定手段１ｅは、取引条件記憶手段１ｃを参照し、取引相手顧客の与信情報と取引履歴とに応じた取引条件を決定する。

取引条件送信手段１ｆは、取引条件決定手段が決定した取引条件を注文用端末に送信する。
審査管理手段１ｇは、承認担当者の使用する承認用端末４に対して取引相手顧客の審査過程案件情報、取引相手顧客の与信情報、および取引相手顧客の既取引案件情報を送信する。そして、審査管理手段１ｇは、承認用端末４から取引を承認することを示す承認情報を受け取ると、注文用端末２に対して承認された審査過程案件情報を送信する。

また、審査過程案件情報が確認担当者によって内容確認を経た後に承認される場合、審査管理手段１ｇは、審査過程案件情報の内容確認をする確認担当者が使用する確認用端末３に対して取引相手顧客の審査過程案件情報、取引相手顧客の与信情報、および取引相手顧客の既取引案件情報を送信する。その後、審査管理手段１ｇは、確認用端末３から確認完了を示す確認情報を受け取ると、進捗情報記憶手段１ｄ内の審査過程案件情報の進捗情報に確認済と設定する。そして、審査管理手段１ｇは、確認状態が確認済となった審査過程案件情報を承認用端末に対して送信する。

このような販売支援装置によれば、注文用端末から取引条件取得要求が入力されると、取引相手顧客の与信情報と取引履歴とに応じた取引条件が決定され、決定した取引条件が注文用端末に送信される。また、取引内容が確定した案件に対して、内容の確認や承認を実行する場合、確認用端末３に対して審査過程案件情報が送信され、確認情報を受け取る審査過程案件情報を承認用端末４に対して送信される。そして、承認用端末４から承認情報を受け取ると、注文用端末２に対して承認された審査過程案件情報が送信される。

このようにして、調査及び審査に至るまでの必要な情報が電子化され、販売担当者の負担軽減を計ることができる。また、確認の進捗状況が進捗情報で管理されることで、各承認や各種部門での取引内容の確認を迅速に行えるようになる。その結果、顧客への回答のスピードアップを図ることができる。これにより、販売機会を逃すことを防止できる。

次に、本実施の形態の詳細を説明する。
図２は、本実施の形態のシステム構成例を示す図である。本実施の形態では、販売管理サーバ１００を用いて、商品の販売企業における受注管理が行われる。

販売管理サーバ１００は、ネットワーク２０を介して信用情報提供サーバ２１に接続されている。信用情報提供サーバ２１は、企業の信用情報を提供する信用調査会社内に設置されている。信用情報提供サーバ２１には、信用調査会社が調査した各企業の信用情報が蓄積されている。信用情報には、会社の規模、従業員数、資本、売上、利益、決算期が含まれる。

販売管理サーバ１００は、信用情報提供サーバ２１から定期的に企業の信用情報を取得する。取得した信用情報は、時系列に保存される。また、保存された信用情報は、検索可能である。なお、図２では、信用情報提供サーバ２１が１台のみ示されているが、異なる信用調査会社の複数の信用情報提供サーバそれぞれから信用情報を取得して、一元管理することもできる。また、販売管理サーバ１００は、信用情報提供サーバ２１で信用情報が更新される度に、更新後の信用情報を自動で取得する。

なお、販売管理サーバ１００が管理する信用情報は、利用者によりデータの書き込みを可能とする。つまり、実際に利用し会社を調べてみてその信用度を変更したり、検索回数などを記録したりすることができる。このように適宜最新情報に応じて更新することで、信頼性の高い信用情報が得られる。

また、販売管理サーバ１００には、ネットワーク１０を介して、複数のクライアント端末３１〜３５が接続されている。ネットワーク１０は、例えば、社内のイントラネットである。クライアント端末３１〜３５は、販売企業内の社員が販売管理サーバ１００にアクセスするための端末装置である。図２の例では、クライアント端末３１を販売担当者４１が使用し、クライアント端末３２を価格担当者４２が使用し、クライアント端末３３を経理担当者４３が使用し、クライアント端末３４を幹部社員４４が使用し、クライアント端末３５を物流担当者４５が使用するものとする。

ここで、販売担当者４１は、コールセンタにおいて顧客からの注文電話に対応することを業務とする。価格担当者４２は、商品の価格を決定し、販売管理サーバ１００に登録することを業務とする。経理担当者４３は、顧客の与信判断をすることを業務とする。ここで与信とは、企業の信用度合いを示す値である。幹部社員４４は、顧客への商品の販売に関する承認権限を有し、販売の許否の判断を行うことを業務とする。物流担当者４５は、商品の製造スケジュールや在庫状況を販売管理サーバ１００に登録することを業務とする。

販売管理サーバ１００は、これらのクライアント端末３１〜３５と通信を行うことで、案件の内容確認や承認を電子データ上で実行する。すなわち、各利用者が利用者の決裁者（例えば、幹部社員）に対して必要情報を簡単に転送できる。決裁者はその情報をデータベース上の画面を閲覧し確認できる。このやり取りを管理することで、通常行われているような髪のやり取りや、居場所の制限といったボトルネックを解消できる。なお、通信には、例えば、Ｗｅｂベースの技術を利用できる。

なお、会社によっては、決裁者と経理部門が別々の場合がある。その場合にも柔軟に対応できるように、販売管理サーバ１００では、各利用者に対して個別の決裁者やその他の経理部門の有無などを登録できる。

複数の部門で確認を取る必要がある場合、確認の進捗を管理する必要がある。そこで、販売管理サーバ１００は、ワークフロー管理機能を有している。すなわち、販売管理サーバ１００は、利用者と決裁者や経理部門とのやり取りの進捗情報をワークフローとして記録する。これにより、各案件の確認や承認の進捗状況が明確となり、確認や承認を迅速に進めることができる。なお、販売管理サーバ１００は、確認や承認に際し、取引相手企業の与信情報や、自社との取引回数などの情報を各担当者のクライアント端末に送信する。これにより、確認や承認の判断も容易となる。

また、販売管理サーバ１００には、過去の取引内容が履歴として記録されている。これにより、各案件のステータスや過去の履歴参照などが行えるようになり、無駄な会社情報の調査や申請が必要なくなる。また、会社によっては業績の変動もあるため、商談によっては過去の履歴から再度会社の審査を簡単に、かつ過去からの変動情報なども参照できるようになる。

次に、顧客から注文を受けたときの手続の流れについて説明する。
図３は、注文処理業務を示す図である。本システムでは、価格担当者４２がクライアント端末３２を使用し、販売管理サーバ１００に予め商品の価格データを登録しておく。また、経理担当者４３は、クライアント端末３３を使用し、販売管理サーバ１００に取引条件を予め登録しておく。

顧客企業の発注担当者４６が電話機３６を用いてコールセンタに発注の電話をかけると、コールセンタの販売担当者４１が電話機３７で電話を受け、電話での対応を行う。そして、販売担当者４１は、発注担当者４６から、顧客企業の名称および注文の内容を聞き取る。注文の内容としては、例えば、商品、数量などである。

注文の内容の聞き取りを行った販売担当者４１は、クライアント端末３１を使用して販売管理サーバ１００にアクセスし、注文された商品の価格や取引条件を確認する。取引条件は、顧客企業の与信情報、過去の取引回数、今回の取引額などに応じて、販売管理サーバ１００で決定される。販売担当者４１は発注担当者４６との間で、取引条件の範囲内で価格、数量などを交渉する。交渉がまとまったら、販売担当者４１は、クライアント端末３１を使用して、販売管理サーバ１００に対して確定した注文内容を入力する。

確定した注文内容はクライアント端末３２に表示され、価格担当者４２が価格チェックを行う。価格担当者４２が販売価格に問題がないと判断すると、クライアント端末３２を使用して、販売管理サーバ１００に対して価格確認完了を示す情報を入力する。

価格確認が完了すると、与信情報を含む注文内容がクライアント端末３３に表示され、経理担当者４３が与信チェックを行う。経理担当者４３が顧客企業の信用度と販売リスク（販売額や代金の受取時期など）とに基づいて、販売可能か否かを判断する。経理担当者４３が販売可能と判断した場合、クライアント端末３３を使用して、販売管理サーバ１００に対して与信確認完了を示す情報を入力する。

与信確認が完了すると、注文内容がクライアント端末３４に表示され、幹部社員４４が販売を承認するか否かを破断する。販売を承認する場合、幹部社員４４はクライアント端末３４を使用して、販売管理サーバ１００に対して販売承認を示す情報を入力する。

販売が承認されると、クライアント端末３１に承認結果が表示される。販売担当者４１は、顧客企業の発注担当者４６に電話連絡し、合意した注文に対する承認が下りた旨を伝える。販売担当者４１は、発注担当者４６に注文の取り下げの意思がないことを確認し、取引が成約する。

取引が成約すると、販売担当者４１は、クライアント端末３１を使用して販売管理サーバ１００にアクセスし、確定した注文を受注状態とする。物流担当者４５は、クライアント端末３５を用いて販売管理サーバ１００にアクセスし、発注状態の案件情報を取得する。物流担当者４５が、工場での商品の製造スケジュールの調整などを行い、工場から顧客企業へ商品を発送する。

このような手順で注文処理を行うために必要な情報は販売管理サーバ１００で集中管理される。
図４は、本実施の形態に用いる販売管理サーバのハードウェア構成例を示す図である。販売管理サーバ１００は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０８を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ:Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、および通信インタフェース１０６，１０７が接続されている。

ＲＡＭ１０２は、販売管理サーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３は、販売管理サーバ１００の二次記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、二次記憶装置としては、フラッシュメモリなどの半導体記憶装置を使用することもできる。

グラフィック処理装置１０４には、モニタ１１が接続されている。グラフィック処理装置１０４は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１の画面に表示させる。モニタ１１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置がある。

入力インタフェース１０５には、キーボード１２とマウス１３とが接続されている。入力インタフェース１０５は、キーボード１２やマウス１３から送られてくる信号を、バス１０８を介してＣＰＵ１０１に送信する。なお、マウス１３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

通信インタフェース１０６は、ネットワーク１０に接続されている。通信インタフェース１０６は、ネットワーク１０を介して、クライアント端末３１〜３５との間でデータの送受信を行う。

通信インタフェース１０７は、ネットワーク２０に接続されている。通信インタフェース１０７は、ネットワーク２０を介して、信用情報提供サーバ２１との間でデータの送受信を行う。

以上のようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、図４では、販売管理サーバ１００のハードウェア構成を示したが、信用情報提供サーバ２１、およびクライアント端末３１〜３５も同様のハードウェア構成で実現することができる。

次に、販売管理サーバ１００の機能について説明する。
図５は、販売管理サーバの機能を示すブロック図である。販売管理サーバ１００は、顧客情報データベース（ＤＢ）１１０、案件管理データベース（ＤＢ）１２０、商品データベース（ＤＢ）１３０、ワークフローデータベース（ＤＢ）１４０、取引条件記憶部１５０、信用情報取得部１６０、および案件管理部１７０を有している。

顧客情報ＤＢ１１０は、顧客の信用情報を記憶する記憶機能である。例えば、ＨＤＤ１０３の記憶領域の一部が顧客情報ＤＢ１１０として使用される。
案件管理ＤＢ１２０は、注文案件内容を記憶する記憶機能である。例えば、ＨＤＤ１０３の記憶領域の一部が、案件管理ＤＢ１２０として使用される。

商品ＤＢ１３０は、商品に関する情報を記憶する記憶機能である。例えば、ＨＤＤ１０３の記憶領域の一部が、商品ＤＢ１３０として使用される。
ワークフローＤＢ１４０は、注文の案件に対する処理の進捗状況を示す情報（ワークフロー）を記憶する記憶機能である。例えば、ＨＤＤ１０３の記憶領域の一部が、ワークフローＤＢ１４０として使用される。

取引条件記憶部１５０は、販売担当者４１が顧客企業の発注担当者４６と交渉する際の取引条件を記憶する記憶機能である。例えば、ＨＤＤ１０３の記憶領域の一部が、取引条件記憶部１５０として使用される。

信用情報取得部１６０は、信用情報提供サーバ２１から信用情報を定期的に取得する。信用情報取得部１６０は、取得した信用情報を顧客情報ＤＢ１１０に格納する。
案件管理部１７０は、注文案件を管理する。具体的には、案件管理部１７０は、クライアント端末３１〜３５からの入力に応答して、注文の受け付け、各種担当部署における担当者による内容確認、幹部社員による注文の承認などの処理を、各記憶機能を用いて管理する。その際、案件管理部１７０は、顧客の与信情報や過去の取引内容に基づいてすべての確認や承認が問題なく行われるための販売条件を予め販売担当者４１に提示することができる。これにより、販売担当者４１は、示された販売条件の範囲内で顧客と交渉し、迅速に注文内容を合意できる。

なお、図１に示した販売支援装置１の各機能と販売管理サーバ１００の機能との対応関係は以下の通りである。顧客情報記憶手段１ａの機能は、顧客情報ＤＢ１１０に含まれる。取引履歴記憶手段１ｂの機能は、案件管理ＤＢ１２０に含まれる。取引条件記憶手段１ｃの機能は、取引条件記憶部１５０に含まれる。進捗情報記憶手段１ｄの機能は、ワークフローＤＢ１４０に含まれる。取引条件決定手段１ｅ、取引条件送信手段１ｆ、および審査管理手段１ｇの機能は、案件管理部１７０に含まれる。

次に、販売管理サーバ１００が有する各記憶機能に格納されるデータについて具体的に説明する。
図６は、顧客情報ＤＢのデータ構造例を示す図である。顧客情報ＤＢ１１０には、顧客に対応する顧客情報群１１１，１１２，１１３，・・・が登録されている。各顧客情報群１１１，１１２，１１３，・・・は、１つ以上の顧客情報で構成されている。

図６の例では、顧客情報群１１１は、複数の顧客情報１１１ａ，１１１ｂ，・・・で構成されている。顧客情報１１１ａ，１１１ｂ，・・・は、信用情報提供サーバ２１からの取得順に沿って格納されている。最後に登録された顧客情報が最新である。顧客情報１１１ａ，１１１ｂ，・・・には、ポインタ、更新日付、会社名、会社識別コード、決済月、資本金、従業員数、取引銀行、および評点のフィールドが設けられている。

ポインタのフィールドには、次の顧客情報の格納場所を示す位置情報（ポインタ）が設定される。更新日付のフィールドには、顧客情報を最後に更新した年月日が設定される。会社名の欄には、顧客企業の名称が設定される。会社識別コードのフィールドには、販売管理サーバ１００内で顧客企業を一意に識別するための識別子（会社識別コード）が設定される。決済月のフィールドには、顧客企業の決済月が設定される。資本金のフィールドには、顧客企業の資本金が設定される。従業員数のフィールドには、顧客企業の従業員数が設定される。取引銀行のフィールドには、顧客企業が取引をしている銀行の名称が設定される。評点のフィールドには、顧客企業に対して信用調査会社が判断した信用度（評点）が設定される。

図７は、案件管理ＤＢのデータ構造例を示す図である。案件管理ＤＢ１２０には、注文案件ごとの案件情報群１２１，１２２，１２３，・・・が登録されている。各案件情報群１２１，１２２，１２３，・・・は、１つ以上の案件情報で構成されている。

図７の例ででは、案件情報群１２１は、複数の案件情報１２１ａ，１２１ｂ，・・・，１２１ｎで構成されている。案件情報１２１ａ，１２１ｂ，・・・，１２１ｎには、審査中の案件情報１２１ａ，１２１ｂ，・・・と、注文の内容が確定した確定注文の案件情報１２１ｎとがある。審査中の案件情報１２１ａ，１２１ｂ，・・・は、販売担当者４１が顧客企業の発注担当者４６に対応し、対応の内容を登録した順に沿って格納されている。最後に登録された案件情報が最新である。

審査中の案件情報１２１ａ，１２１ｂのうち先頭の案件情報１２１ａには、案件管理番号、ポインタ、対応日時、対応状況、対応者、相手担当者、会社識別コード、相手連絡先、商談確度、取引形態、競合他社、および取引規模のフィールドが設けられている。

案件管理番号のフィールドには、注文案件を一意に識別するための識別子（案件管理番号）が設定される。ポインタのフィールドには、次の案件情報の格納場所を示す位置情報（ポインタ）が設定される。対応日時のフィールドには、販売担当者４１が対応した日時が設定される。対応状況のフィールドには、対応の内容を示す文章が設定される。対応者のフィールドには、対応した販売担当者４１を一意に識別するための識別子（社員コードなど）が設定される。相手担当者のフィールドには、顧客企業の発注担当者４６を一意に識別するための情報（所属部署、氏名など）が設定される。会社識別コードのフィールドには、顧客企業を一意に識別するための識別子（会社識別コード）が設定される。相手連絡先のフィールドには、発注担当者４６の連絡先（電話番号など）が設定される。商談確度のフィールドには、販売担当者４１の判断による商談が成立する確か度が設定される。取引形態のフィールドには、取引が現金引き替えなのか、納品後代金納付なのかといった取引形態が設定される。競合他社のフィールドには、顧客企業が他社の商品と競合させている場合、競合する商品を販売している企業が設定される。取引規模のフィールドには、注文の取引規模（例えば、受注予定額の概算値）が設定される。

２つめ以降の案件情報１２１ｂ，・・・には、先頭の案件情報１２１ａから案件管理番号のフィールドを除いた各フィールドが設けられている。確定注文の案件情報１２１ｎには、案件管理番号、受注日、商品、数量、金額、値引き額、値引率、粗利、納入日、検収日、売上日、支払条件、および回収状況のフィールドが設けられている。

案件管理番号のフィールドには、注文案件の案件管理番号が設定される。受注日のフィールドには、注文内容を合意した日付が設定される。商品の欄には、受注した商品の商品名が設定される。数量のフィールドには、受注数量が設定される。値引き額のフィールドには、標準価格で全数を販売した場合の総額と、実際の販売価格との差額が設定される。値引率のフィールドには、標準価格で全数を販売した場合の総額に対する値引き額の割合が百分率で設定される。粗利のフィールドには、販売によって得られる粗利（正式には売上げ総利益であり、売上額から売上原価を減算した値）が設定される。納入日のフィールドには、商品が顧客企業に到着する予定の日付が設定される。検収日のフィールドには、顧客企業において商品の検収を行う日付が設定される。売上日のフィールドには、販売する商品を売上げに参入する日が設定される。支払条件のフィールドには、支払いサイトなどの代金の支払い条件が設定される。なお、支払いサイトは、取引代金の締め日から支払日までの猶予期間である。回収状況のフィールドには、代金を回収できたか否かの状況が設定される。

図８は、商品ＤＢのデータ構造例を示す図である。商品ＤＢ１３０には、商品ごとの商品情報１３１，１３２，１３３，・・・が登録されている。商品情報１３１，１３２，１３３，・・・には、商品名、在庫数、標準価格、および原価のフィールドが設けられている。

商品名のフィールドには、商品の名称（型番など）が設定される。在庫数のフィールドには、現在の商品の在庫数が設定される。標準価格のフィールドには、商品の標準価格（希望小売価格）が設定される。

図９は、ワークフローＤＢのデータ構造例を示す図である。ワークフローＤＢ１４０には、注文案件ごとの進捗情報１４１，１４２，１４３，・・・が登録されている。
進捗情報１４１，１４２，１４３，・・・には、案件管理番号、価格確認状況、与信確認状況、幹部承認状況、および受注状況のフィールドが設けられている。案件管理番号のフィールドには、進捗情報に対応する注文案件の案件管理番号が設定される。

価格確認状況のフィールドには、注文案件に対して価格担当者４２による確認が完了したか否かを示すフラグが設定される。価格の確認が未完了であれば価格確認状況のフィールドの値は「未確認」であり、価格の確認が完了していれば価格確認状況のフィールドの値が「確認済」となる。

与信確認状況のフィールドには、経理担当者４３による与信確認が完了したか否かを示すフラグが設定される。与信の確認が未完了であれば与信確認状況のフィールドの値は「未確認」であり、与信の確認が完了していれば与信確認状況のフィールドの値が「確認済」となる。

幹部承認状況のフィールドには、幹部社員４４による承認が完了したか否かを示すフラグが設定される。承認が未完了であれば幹部承認状況のフィールドの値は「未承認」であり、承認が完了していれば幹部承認状況のフィールドの値が「承認済」となる。

受注状況のフィールドには、注文が成約し物流部門への受注が行われたか否かを示すフラグが設定される。成約していなければ受注状況のフィールドの値は「未受注」であり、成約していれば受注状況のフィールドの値が「受注済」となる。

図１０は、取引条件記憶部のデータ構造例を示す図である。取引条件記憶部１５０には、取引条件テーブル１５１が格納されている。取引条件テーブル１５１は、取引条件を決定するための判断基準と、各判断基準によって判断された取引条件との対応関係が登録されたデータテーブルである。取引条件テーブル１５１には、与信評点、取引回数、販売規模上限値、販売規模、割引上限値、支払いサイト、および付加取引条件の欄が設けられている。

与信評点の欄には、与信情報に含まれる評点に応じて取引条件を決定する場合における各取引条件を適用する評点の範囲が設定される。図１０の例では、評点が６０点以上、４５点以上６０点未満、および４５点未満の３つの範囲が設定されている。

取引回数の欄には、自社との過去の取引回数に応じて取引条件を決定する場合における各取引条件を適用する取引回数の範囲が設定される。なお、過去の取引回数に応じた取引条件の決定を行わない場合、取引回数の範囲は設定されない。図１０の例では、与信情報の評点が４５点以上６０点未満の場合にのみ過去の取引回数に応じた取引条件が設定されている。この例では、評点が４５点以上６０点未満の場合に適用する取引条件の取引回数の範囲として、１０回以上と１０回未満との２つの範囲が設定されている。

販売規模上限値の欄には、与信情報の評点と取引回数とに応じた販売規模上限値が設定される。販売規模上限値が設定されていた場合、販売規模上限値以上の規模の注文は、販売担当者４１のみで受注できるかどうかの判断を行うことはできない。すなわち、販売規模上限値以下の販売規模の注文であれば、本システムを用いた迅速な受注許否判断が可能となる。図１０の例では、評点が４５点以上６０点未満であり、かつ過去の取引回数が１０回以上であれば販売規模上限値は１０００万円である。また、評点が４５点以上６０点未満であり、かつ過去の取引回数が１０回未満であれば販売規模上限値は５００万円である。

販売規模の欄には、注文の販売規模に応じて取引条件を決定する場合における各取引条件を適用する範囲が設定される。なお、販売規模に応じた取引条件の決定を行わない場合、販売規模の範囲は設定されない。図１０の例では、与信情報の評点が４５点以上６０点未満の場合にのみ販売規模に応じた取引条件が設定されている。この例では、評点が４５点以上６０点未満の場合に適用する取引条件の販売規模の範囲として、５００万円以上、５００万円未満、２５０万円以上、および２５０万円未満の４つの範囲が設定されている。

割引上限値の欄には、与信情報の評点に応じた割引上限値が設定される。割引上限値は、販売担当者４１の権限で割引可能な割引率の上限を示している。なお、評点の範囲指定に該当する注文を、取引回数や販売規模でさらに分類して、評点、取引回数、および販売規模の組合せに応じた割引上限値を設定することもできる。図１０の例では、評点が６０点以上であれば、割引上限値が３０％である。評点が４５点以上６０点未満であり、取引回数が１０回以上であり、かつ販売規模が５００万円以上であれば、割引上限値は２０％である。評点が４５点以上６０点未満であり、取引回数が１０回以上であり、かつ販売規模が５００万円未満であれば、割引上限値は１５％である。評点が４５点以上６０点未満であり、取引回数が１０回未満であり、かつ販売規模が２５０万円以上であれば、割引上限値は１０％である。評点が４５点以上６０点未満であり、取引回数が１０回未満であり、かつ販売規模が２５０万円未満であれば、割引上限値は５％である。評点が４５点未満であれば、割引上限値は２％である。

支払いサイトの欄には、与信情報の評点に応じた支払いサイトが設定される。なお、評点の範囲指定に該当する注文を、取引回数や販売規模でさらに分類して、評点、取引回数、および販売規模の組合せに応じた支払いサイトを設定することもできる。図１０の例では、評点が４５点以上６０点未満であり、取引回数が１０回以上であれば、支払いサイトは１６０日である。評点が４５点以上６０点未満であり、取引回数が１０回未満であれば、支払いサイトは６０日である。評点が４５点未満であれば、支払いサイトは３０日である。

付加取引条件の欄には、与信情報の評点に応じた付加的な取引条件が設定される。なお、評点の範囲指定に該当する注文を、取引回数や販売規模でさらに分類して、評点、取引回数、および販売規模の組合せに応じた取引条件を設定することもできる。図１０の例では、評点が４５点未満の場合に対して、「前回の取引の決済が完了していること」という付加的な取引条件が設定されている。

このような取引条件によって、与信及び販売規模、過去の取引状況から判断して適正価格の決定を迅速に行うことが可能となる。すなわち、販売担当者４１と発注担当者４６との間での交渉期間を短縮できる。

なお、取引条件記憶部１５０には、取引条件の決定方針を示す文字列を記憶しておくこともできる。取引条件テーブル１５１に示された取引条件の決定方針は以下の通りである。

与信情報の評点が６０点以上の場合、優良顧客であると判断する。優良顧客は、資金面で優良企業としての評価が高い企業である。優良顧客であれば、販売規模（台数）によらず、今後の円滑な関係を保持するために割引上限値を大きく設定する。また、優良企業は資金面に優れるため代金が不払いとなる危険性も低いと判断され、支払いサイトにも余裕を持たせられる。

与信情報の評点が４５点以上６０点未満の場合、普通の企業と評価される。普通の企業は、販売規模が大きい場合にのみ割引上限値を大きくする。普通の企業は評点がそんなに高くないため、販売規模が大きくなければ、粗利の面から値引き幅は中程度に設定される。また、調査会社による評点による評価が普通であっても自社との取引を所定回数以上行っている場合、回数とその状況によって値引き幅や一度に販売できる数量などの優遇を行う。

与信情報の評点が４５点未満の場合、信用度が低い企業であると評価される。信用が低い企業は、取引相手として非常に危ない場合が想定される。そのため、販売規模上限値が低く設定される。販売規模が低いため、粗利との関係で値引き幅も小さく設定される。さらに、信用度が低い企業には、以前は優良であったが最近は資金繰りが難しくなっているような企業もある。そのため、信用度が低い企業の場合、過去の取引回数に寄らず値引き幅は小さいままに据え置かれ、支払いサイトも短い期間となる。そして、未回収の代金の累積を防止するため、信用度が低い企業との取引においては、代金回収支払いが済むまでは新たな取引はできなくする。

次に、販売管理サーバ１００が実行する処理について詳細に説明する。
図１１は、注文の受付から注文が確定するまでの処理を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。

［ステップＳ１１］販売管理サーバ１００は、販売担当者４１が使用するクライアント端末３１と連携動作して注文受け付け処理を行う。この処理の詳細は後述する（図１２参照）。

［ステップＳ１２］販売管理サーバ１００は、価格担当者４２が使用するクライアント端末３２と連係動作して価格確認処理を行う。この処理の詳細は後述する（図１３参照）。

［ステップＳ１３］販売管理サーバ１００は、経理担当者４３が使用するクライアント端末３３と連係動作して与信確認処理を行う。この処理の詳細は後述する（図１４参照）。

［ステップＳ１４］販売管理サーバ１００は、幹部社員４４が使用するクライアント端末３４と連係動作して承認処理を行う。この処理の詳細は後述する（図１５参照）。
［ステップＳ１５］販売管理サーバ１００は、販売担当者４１が使用するクライアント端末３１と連係動作して受注処理を行う。この処理の詳細は後述する（図１６参照）。

次に、図１１に示した各処理の詳細について説明する。まず、注文受け付け処理について詳細に説明する。
図１２は、注文受け付け処理の手順を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。

［ステップＳ２１］販売管理サーバ１００の案件管理部１７０は、会社名を取得する。具体的には、販売担当者４１が、顧客企業の発注担当者４６からの電話を受け、会社名や注文の内容を聞く。そして、販売担当者４１は、クライアント端末３１を使用し、会社名や注文内容を含む取引条件取得要求を販売管理サーバ１００に送信する。販売管理サーバ１００では、案件管理部１７０が取引条件取得要求を受信する。

［ステップＳ２２］案件管理部１７０は、取引条件取得要求に含まれる会社名に対応する顧客情報を顧客情報ＤＢ１１０から抽出する。
［ステップＳ２３］案件管理部１７０は、会社名に対応する過去の案件情報を案件管理ＤＢ１２０から抽出する。具体的には、案件管理部１７０は、ステップＳ２２で抽出した顧客情報から会社識別コードを抽出する。そして、案件管理部１７０は、抽出した会社識別コードに対応する案件情報群を案件管理ＤＢ１２０から抽出する。このとき、過去に取引の交渉が行われた回数分の案件情報群が抽出される。なお、過去に取引の交渉が一度も行われていない顧客であれば、案件情報群は抽出されない。

［ステップＳ２４］案件管理部１７０は、販売担当者４１が使用するクライアント端末３１に対して、取引条件を送信する。具体的には、案件管理部１７０は、ステップＳ２２で抽出した顧客情報に基づいて、該当顧客企業の評点を取得する。

また、案件管理部１７０は、ステップＳ２３で取得した案件情報群に基づいて、過去に成約した取引の回数を判断する。なお、ステップＳ２３では、単に取引の交渉があった案件に対応する案件情報群が抽出されており、成約したかどうかは不明である。そこで、案件管理部１７０は、抽出した案件情報群それぞれの案件管理番号でワークフローＤＢ１４０を検索し、対応する進捗情報を取得する。案件管理部１７０は、取得した進捗情報において受注状況のフィールドに「受注済」が設定されていれば、該当する案件は成約したと判断する。そして、案件管理部１７０は、成約した取引の案件の数を、過去の取引回数とする。

さらに、案件管理部１７０は、過去に成約した取引の各案件情報群内の注文合意後の案件情報を参照し、代金の回収状況（決済に完了の有無）を確認する。すなわち、案件管理部１７０は、決済未完了の取引が存在するか否かを判断する。

そして、案件管理部１７０は、取引条件記憶部１５０内の取引条件テーブル１５１を参照し、顧客企業に関する情報（評点、取引回数、決済未完了の取引の有無）と、取引条件取得要求に含まれる注文内容とに基づいて、取引条件を判断する。具体的には、案件管理部１７０は、注文内容に含まれる商品名、数量に基づいて、販売規模を計算する。すなわち、案件管理部１７０は、商品ＤＢ１３０を参照し、商品名に対応する商品情報に設定されている標準価格を取得する。標準価格に数量を乗算することで、販売規模が計算できる。案件管理部１７０は、取引条件テーブル１５１を参照し、評点、取引回数、および販売規模に応じた販売規模上限値、割引上限値、支払いサイト、および付加取引条件を決定する。

案件管理部１７０は、決定した各条件を取引条件として、クライアント端末３１に送信する。なお、送信する取引条件には、企業名、評点、過去の取引案件数、対象商品の標準価格などの情報が含まれる。

クライアント端末３１は、取得した取引条件を含む案件管理画面を表示する。販売担当者４１は、表示された取引条件の範囲内で、顧客企業の発注担当者４６と受注内容の交渉を行う。そして、販売担当者４１は、交渉の結果を示す案件情報をクライアント端末３１を使用して販売管理サーバ１００に送信する。交渉により注文内容が確定したときは、注文確定を示す情報（例えば、受注日）が案件情報に含められる。

［ステップＳ２５］販売管理サーバ１００の案件管理部１７０は、クライアント端末３１から送信された案件情報を取得する。そして、案件管理部１７０は、取得した案件情報を、案件管理ＤＢ１２０に登録する。

［ステップＳ２６］案件管理部１７０は、注文が確定したか否かを判断する。具体的には、案件管理部１７０は、取得した案件情報に注文確定を示す情報が含まれていれば、注文が確定した（確定案件である）と判断する。注文が確定した場合、処理がステップＳ２８に進められる。取得した案件情報に注文確定を示す情報が含まれていなければ、注文が確定していない（継続案件である）と判断する。注文が確定していなけれ、処理がステップＳ２７に進められる。

［ステップＳ２７］案件管理部１７０は、継続案件の案件情報を案件管理ＤＢ１２０に登録する。具体的には、案件管理部１７０は、まず、取得した案件情報に対して案件管理番号が付与されているか否かにより、新規案件なのか否かを判断する。

案件管理番号が付与されていなければ新規案件であり、案件管理部１７０は新たな案件管理番号を生成し、生成した案件管理番号付きの案件情報を案件管理ＤＢ１２０に格納する。案件管理番号が付与されていれば以前から交渉している案件であり、案件管理部１７０は、取得した案件情報と同じ案件管理番号が付与されている案件情報群の最後に取得した案件情報と登録する。この際、直前に登録されている案件情報のポインタのフィールドに、今回登録した案件情報の格納場所を示す位置情報を設定する。その後、注文受け付け処理が終了する。

［ステップＳ２８］案件管理部１７０は、確定案件の案件情報を案件管理ＤＢ１２０に登録する。
［ステップＳ２９］案件管理部１７０は、進捗情報を生成し、ワークフローＤＢ１４０に新規登録する。具体的には、案件管理部１７０は、確定案件の案件情報に示される案件管理番号を付し、価格確認状況が「未確認」、与信確認状況が「未確認」、幹部承認状況が「未承認」、受注状況が「未受注」である進捗情報を生成する。そして、案件管理部１７０は、生成した進捗情報をワークフローＤＢ１４０に格納する。その後、受注受け付け処理が終了する。

次に、価格確認処理について詳細に説明する。
図１３は、価格確認処理の手順を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。

［ステップＳ３１］販売管理サーバ１００の案件管理部１７０は、価格確認が完了していない確定注文の注文内容を価格担当者４２のクライアント端末３２に送信する。具体的には、価格担当者４２がクライアント端末３２を用いて、価格未確認注文の案件情報取得要求を販売管理サーバ１００に送信する。すると、販売管理サーバ１００の案件管理部１７０が案件管理ＤＢ１２０から確定注文の案件情報を抽出する。さらに案件管理部１７０は、抽出した案件情報の案件管理番号に基づいて、ワークフローＤＢ１４０内の対応する進捗情報を参照する。そして、案件管理部１７０は、進捗情報において価格確認状況が「未確認」である案件情報を、価格未確認注文とする。

このとき案件管理部１７０は、価格未確認注文の最新の顧客情報を顧客情報ＤＢ１１０から取得すると共に、案件管理ＤＢ１２０を参照して価格未確認注文の案件情報群に基づいて、過去の取引案件数をカウントする。そして、案件管理部１７０は、価格未確認注文の案件情報、該当案件の顧客情報（例えば、企業名、評点）、および取引案件数をクライアント端末３２に送信する。クライアント端末３２では、販売管理サーバ１００から送信された案件情報などの内容が価格確認画面に表示される。

価格担当者４２は、クライアント端末３２に表示された価格確認画面に基づいて、販売価格が妥当か否かを判断する。販売価格が妥当であれば、価格担当者４２は、クライアント端末３２に対して価格確認の完了を示す操作入力を行う。クライアント端末３２は、価格担当者４２からの操作入力に応答して、価格確認完了を示す価格確認情報（案件管理番号が含まれる）を販売管理サーバ１００に送信する。

［ステップＳ３２］販売管理サーバ１００の案件管理部１７０は、クライアント端末３２から価格確認情報が入力されたか否かを判断する。価格確認情報の入力があれば、処理がステップＳ３３に進められる。価格確認情報の入力がなければ、価格確認処理が終了する。なお、価格確認情報の入力がない場合とは、例えば、価格確認の完了を示す操作入力無しに、価格確認画面が閉じられた場合である。

［ステップＳ３３］案件管理部１７０は、ワークフローＤＢ１４０内の進捗情報を更新する。具体的には、案件管理部１７０は、価格確認情報に含まれる案件管理番号に基づいて、ワークフローＤＢ１４０内の価格確認が完了した案件の進捗情報を検索する。そして、案件管理部１７０は、該当する進捗情報の価格確認状況を「確認済」に更新する。その後、価格確認処理が終了する。

次に、与信確認処理について詳細に説明する。
図１４は、与信確認処理の手順を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。

［ステップＳ４１］販売管理サーバ１００の案件管理部１７０は、与信確認が完了していない確定注文の注文内容を経理担当者４３のクライアント端末３３に送信する。具体的には、経理担当者４３がクライアント端末３３を用いて、与信未確認注文の案件情報取得要求を販売管理サーバ１００に送信する。すると、販売管理サーバ１００の案件管理部１７０が案件管理ＤＢ１２０から確定注文の案件情報を抽出する。さらに案件管理部１７０は、抽出した案件情報の案件管理番号に基づいて、ワークフローＤＢ１４０内の対応する進捗情報を参照する。そして、案件管理部１７０は、進捗情報において与信確認状況が「未確認」である案件情報を、与信未確認注文とする。

このとき案件管理部１７０は、与信未確認注文の最新の顧客情報を顧客情報ＤＢ１１０から取得すると共に、案件管理ＤＢ１２０を参照して与信未確認注文の案件情報群に基づいて、過去の取引案件数をカウントする。そして、案件管理部１７０は、与信未確認注文の案件情報、該当案件の顧客情報（例えば、企業名、評点）、および取引案件数をクライアント端末３３に送信する。クライアント端末３３では、販売管理サーバ１００から送信された案件情報などの内容が与信確認画面に表示される。

経理担当者４３は、クライアント端末３３に表示された与信確認画面に基づいて、注文内容に対する顧客企業の信用度が妥当か否かを判断する。信用度が妥当であれば、経理担当者４３は、クライアント端末３３に対して与信確認の完了を示す操作入力を行う。クライアント端末３３は、経理担当者４３からの操作入力に応答して、与信確認完了を示す与信確認情報（案件管理番号が含まれる）を販売管理サーバ１００に送信する。

［ステップＳ４２］販売管理サーバ１００の案件管理部１７０は、クライアント端末３３から与信確認情報が入力されたか否かを判断する。与信確認情報の入力があれば、処理がステップＳ４３に進められる。与信確認情報の入力がなければ、与信確認処理が終了する。なお、与信確認情報の入力がない場合とは、例えば、与信確認の完了を示す操作入力無しに、与信確認画面が閉じられた場合である。

［ステップＳ４３］案件管理部１７０は、ワークフローＤＢ１４０内の進捗情報を更新する。具体的には、案件管理部１７０は、与信確認情報に含まれる案件管理番号に基づいて、ワークフローＤＢ１４０内の与信確認が完了した案件の進捗情報を検索する。そして、案件管理部１７０は、該当する進捗情報の与信確認状況を「確認済」に更新する。その後、与信確認処理が終了する。

次に、承認処理について詳細に説明する。
図１５は、承認処理の手順を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。

［ステップＳ５１］販売管理サーバ１００の案件管理部１７０は、承認が完了していない確定注文の注文内容を幹部社員４４のクライアント端末３４に送信する。具体的には、幹部社員４４がクライアント端末３４を用いて、未承認注文の案件情報取得要求を販売管理サーバ１００に送信する。すると、販売管理サーバ１００の案件管理部１７０が案件管理ＤＢ１２０から確定注文の案件情報を抽出する。さらに案件管理部１７０は、抽出した案件情報の案件管理番号に基づいて、ワークフローＤＢ１４０内の対応する進捗情報を参照する。そして、案件管理部１７０は、進捗情報において幹部承認状況が「未承認」である案件情報を、未承認注文とする。

このとき案件管理部１７０は、未承認注文の最新の顧客情報を顧客情報ＤＢ１１０から取得すると共に、案件管理ＤＢ１２０を参照して未承認注文の案件情報群に基づいて、過去の取引案件数をカウントする。そして、案件管理部１７０は、未承認注文の案件情報、該当案件の顧客情報（例えば、企業名、評点）、および取引案件数をクライアント端末３４に送信する。クライアント端末３４では、販売管理サーバ１００から送信された案件情報などの内容が承認画面に表示される。

幹部社員４４は、クライアント端末３４に表示された承認画面に基づいて、注文内容に応じた販売の許否を判断する。販売を許可するのであれば、幹部社員４４は、クライアント端末３４に対して承認の完了を示す操作入力を行う。クライアント端末３４は、幹部社員４４からの操作入力に応答して、承認完了を示す承認情報（案件管理番号が含まれる）を販売管理サーバ１００に送信する。

［ステップＳ５２］販売管理サーバ１００の案件管理部１７０は、クライアント端末３４から承認情報が入力されたか否かを判断する。承認情報の入力があれば、処理がステップＳ５３に進められる。承認情報の入力がなければ、承認処理が終了する。なお、承認情報の入力がない場合とは、例えば、承認の完了を示す操作入力無しに、承認画面が閉じられた場合である。

［ステップＳ５３］案件管理部１７０は、ワークフローＤＢ１４０内の進捗情報を更新する。具体的には、案件管理部１７０は、承認情報に含まれる案件管理番号に基づいて、ワークフローＤＢ１４０内の承認が完了した案件の進捗情報を検索する。そして、案件管理部１７０は、該当する進捗情報の承認状況を「承認済」に更新する。その後、承認処理が終了する。

次に、受注処理について詳細に説明する。
図１６は、受注処理の手順を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。

［ステップＳ６１］販売管理サーバ１００の案件管理部１７０は、承認済案件を抽出する。具体的には、案件管理部１７０は、定期的にワークフローＤＢ１４０から、幹部承認状況が承認済となっている進捗情報を検索する。次に、案件管理部１７０は、案件管理ＤＢ１２０から、検索によって見つけ出された進捗情報の案件管理番号に対応する案件情報群を検索する。

［ステップＳ６２］案件管理部１７０は、承認済となった案件の内容を販売担当者４１が使用するクライアント端末３１に送信する。すると、承認済の案件の情報がクライアント端末３１に表示される。

販売担当者４１は、承認済となった案件の顧客側の発注担当者４６に連絡し、注文が確定したことを連絡する。また、販売担当者４１は発注担当者４６と相談し、商品の納入日などの納品に必要な情報を決定する。そして、販売担当者４１は、クライアント端末３１を使用して納品に必要な情報を入力する。入力された情報は、クライアント端末３１から販売管理サーバ１００に送信される。

［ステップＳ６３］販売管理サーバ１００の案件管理部１７０は、確定した案件情報を受注状態とする。具体的には、案件管理部１７０は、クライアント端末３１から送られてきた受注確定を示す情報（案件管理番号が含まれる）に基づいて、ワークフローＤＢ１４０内の対応する進捗情報の受注状況に、注文の成約を示す「受注済」を設定する。

［ステップＳ６４］案件管理部１７０は、受注状態の案件情報を、物流担当者４５へ通知する。具体的には、物流担当者４５は、クライアント端末３５を使用して受注確認要求を販売管理サーバ１００に送信する。すると、販売管理サーバ１００の案件管理部１７０は、受注確認要求に応答して、ワークフローＤＢ１４０から受注状態となっている進捗情報を取得する。次に、案件管理部１７０は、該当する進捗情報の案件管理番号に基づいて、対応する顧客情報群と案件情報群とを、それぞれ顧客情報ＤＢ１１０と案件管理ＤＢ１２０とから取得する。案件管理部１７０は、取得した情報から工場または倉庫から顧客企業への商品の発送に必要な情報（会社識別コード、相手連絡先、商品、数量、納入日など）を抽出する。そして、案件管理部１７０は、抽出した情報を物流担当者４５が使用するクライアント端末３５に送信する。

クライアント端末３５では、受信した情報が表示される。物流担当者４５は、クライアント端末３５に表示された情報に基づいて、工場での商品の製造指示や、倉庫からの商品の出荷の手配を行う。

以上のようにして、販売担当者４１が注文内容を確定した案件について、効率的に承認することができる。以下、注文内容の確定から承認に至までに各クライアント端末３１〜３４に表示される画面について説明する。

図１７は、案件管理画面の例を示す図である。案件管理画面５０は、販売担当者４１が顧客企業の発注担当者４６と交渉する際に、クライアント端末３１に表示される画面である。案件管理画面５０には、企業名表示部５１、評点表示部５２、取引案件数表示部５３、取引条件表示部５４、注文内容入力部５５、標準価格表示部５６、および価格確認依頼ボタン５７が設けられている。

企業名表示部５１には、商品の購入を希望している顧客企業の名称が表示される。評点表示部５２には、信用調査会社が判定した顧客企業の評点が表示される。取引案件数表示部５３には、該当顧客企業が自社と過去に取引した案件の数が表示される。取引条件表示部５４には、顧客企業の評点や過去の取引案件数などに応じて決定された取引条件が表示される。

注文内容入力部５５は、注文の内容を入力するためのテキスト入力領域である。例えば、顧客企業が購入を希望している商品の商品名、顧客の希望金額、顧客が希望する支払いサイトなどが入力される。なお、希望金額や希望支払いサイトは、単に顧客が希望した値が入力されるのではなく、販売担当者４１と顧客企業の発注担当者４６との交渉により妥結した値が入力される。また、注文内容入力部５５には、図１７に表示されている内容以外にも、注文の確定に必要な各種情報（例えば、図７に示した確定注文の案件情報，１２１ａ，１２１ｂ，・・・，１２１ｎに含まれる情報）が設定される。標準価格表示部５６には、販売対象商品の標準価格が表示される。

価格確認依頼ボタン５７は、注文内容が確定したときに、価格担当者４２に価格確認を依頼するためのボタンである。価格確認依頼ボタン５７が押下されると、注文内容を確定した案件情報がクライアント端末３１から販売管理サーバ１００に送信される。確定案件の案件情報は、価格担当者４２の使用するクライアント端末３２の価格確認画面に表示される。

なお、図１７の例では、取引条件表示部５４に、販売管理サーバ１００で決定された取引条件を表示しているが、取引条件の決定方針を合わせて表示することもできる。取引条件の決定方針を表示しておくことで、販売担当者４１は、顧客企業の発注担当者４６と交渉する際に、どのような条件を満たせば取引条件を変更できるのかを提示できる。例えば、販売担当者４１は、取引回数が足りないために割引率が低い場合、取引回数を重ねれば、以後は高い割引率で販売可能であることを説明できる。このような説明ができることで、現在の割引率でしか販売できないことを顧客企業の発注担当者４６に納得させることができる。

図１８は、価格確認画面の例を示す図である。価格確認画面６０は、価格担当者４２が価格確認を行う際に、クライアント端末３２に表示される画面である。価格確認画面６０には、企業名表示部６１、評点表示部６２、取引案件数表示部６３、注文内容表示部６４、価格判断指標表示部６５、および与信確認依頼ボタン６６が設けられている。

企業名表示部６１には、商品の購入を希望している顧客企業の名称が表示される。評点表示部６２には、信用調査会社が判定した顧客企業の評点が表示される。取引案件数表示部６３には、該当顧客企業が自社と過去に取引した案件の数が表示される。

注文内容表示部６４には、案件管理画面５０で入力された注文内容が表示される。価格判断指標表示部６５には、価格が適正かどうかを判断するための指標となる情報が表示される。指標となる情報は、例えば、商品の原価や、顧客の希望価格で販売したとき粗利である。なお、商品の原価は商品ＤＢ１３０から取得される。

与信確認依頼ボタン６６は、価格確認が完了したときに、経理担当者４３に与信確認を依頼するためのボタンである。与信確認依頼ボタン６６が押下されると、価格確認が完了した案件情報がクライアント端末３２から販売管理サーバ１００に送信される。価格確認が完了した案件の案件情報は、経理担当者４３の使用するクライアント端末３３の与信確認画面に表示される。

図１９は、与信確認画面の例を示す図である。与信確認画面７０は、経理担当者４３が与信確認を行う際に、クライアント端末３３に表示される画面である。与信確認画面７０には、企業名表示部７１、評点表示部７２、取引案件数表示部７３、希望支払いサイト表示部７４、過去取引内容表示部７５、与信判断指標表示部７６、および承認依頼ボタン７７が設けられている。

企業名表示部７１には、商品の購入を希望している顧客企業の名称が表示される。評点表示部７２には、信用調査会社が判定した顧客企業の評点が表示される。取引案件数表示部７３には、該当顧客企業が自社と過去に取引した案件の数が表示される。

希望支払いサイト表示部７４には、顧客の希望する支払いサイトが表示される。過去取引内容表示部７５には、過去の取引における取引内容（支払いサイト、台数、金額、回収状況など）が表示される。与信判断指標表示部７６には、取引が安全かどうかを判断するための指標となる情報が表示される。指標となる情報は、例えば、今回の取引における販売台数、金額、粗利である。

承認依頼ボタン７７は、与信確認が完了したときに、幹部社員４４に承認を依頼するためのボタンである。承認依頼ボタン７７が押下されると、与信確認が完了した案件情報がクライアント端末３３から販売管理サーバ１００に送信される。与信確認が完了した案件の案件情報は、幹部社員４４の使用するクライアント端末３４の承認画面に表示される。

図２０は、承認画面の例を示す図である。承認画面８０は、幹部社員４４が承認を行う際に、クライアント端末３４に表示される画面である。承認画面８０には、企業名表示部８１、評点表示部８２、取引案件数表示部８３、希望支払いサイト表示部８４、取引内容表示部８５、および承認ボタン８６が設けられている。

企業名表示部８１には、商品の購入を希望している顧客企業の名称が表示される。評点表示部８２には、信用調査会社が判定した顧客企業の評点が表示される。取引案件数表示部８３には、該当顧客企業が自社と過去に取引した案件の数が表示される。

希望支払いサイト表示部８４には、顧客の希望する支払いサイトが表示される。取引内容表示部８５には、取引内容（商品名、値引き額、台数、支払いサイトなど）が表示される。承認ボタン８６は、承認した場合に押下するボタンである。承認ボタン８６が押下されると、承認したことを示す承認情報がクライアント端末３４から販売管理サーバ１００に送信される。

以上のように、本実施の形態では、信用調査会社によって提供される与信情報と、自社内で有する過去の取引履歴に基づいた顧客ごとの取引条件を、顧客との交渉段階で販売担当者４１が確認することができる。これにより、販売担当者４１と顧客企業の発注担当者４６との交渉の迅速化、および交渉により確定した注文に対する承認の迅速化を図ることができる。その結果、迅速に成約することができ、販売機会の喪失が防止できると共に、販売担当者４１の事務処理の負荷を軽減することができる。

すなわち、従来であれば販売担当者が自ら行っている調査及び紙によるやり取りが無くなり、替わりに調査及び審査に至るまでの情報が電子化されている。これにより、販売担当者の負担軽減が図られる。加えて決裁を電子データ化し、各決裁権限のある人物や経理部門間のやり取りを迅速に行えるようにした。その結果、顧客への回答のスピードアップを図り販売の効率化につながる。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、販売管理サーバ１００が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disc）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

なお、本発明は、上述の実施の形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変更を加えることができる。
以上説明した実施の形態の主な技術的特徴は、以下の付記の通りである。

（付記１） 販売を支援する販売支援装置であって、
顧客の与信情報を記憶する顧客情報記憶手段と、
顧客との過去の取引履歴を記憶する取引履歴記憶手段と、
顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する取引条件記憶手段と、
注文用端末から取引相手顧客を指定した取引条件取得要求が入力されると、前記顧客情報記憶手段から前記取引相手顧客の前記与信情報を取得し、前記取引履歴記憶手段から前記取引相手顧客との前記取引履歴を取得し、前記取引条件記憶手段を参照し、前記取引相手顧客の前記与信情報と前記取引履歴とに応じた前記取引条件を決定する取引条件決定手段と、
前記取引条件決定手段が決定した前記取引条件を前記注文用端末に送信する取引条件送信手段と、
を有する販売支援装置。

（付記２） 前記取引履歴記憶手段には、過去に行われた取引の内容を示す既取引案件情報に加えて、注文を受けて取引の承認を待つ段階にある審査過程案件情報が格納されており、
さらに、
承認担当者の使用する承認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記承認用端末から取引を承認することを示す承認情報を受け取ると、前記注文用端末に対して承認された前記審査過程案件情報を送信する審査管理手段、
を有することを特徴とする付記１記載の販売支援装置。

（付記３） 前記審査過程案件情報が確認担当者によって内容確認を経た後に承認される場合に、さらに、
前記審査過程案件情報の確認の有無を示す確認状態を記憶する進捗情報記憶手段を有し、
前記審査管理手段は、前記審査過程案件情報の内容確認をする確認担当者が使用する確認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記確認用端末から確認完了を示す確認情報を受け取ると、前記進捗情報記憶手段内の前記審査過程案件情報の前記進捗情報に確認済と設定し、前記確認状態が確認済となった前記審査過程案件情報を前記承認用端末に対して送信する、
ことを特徴とする付記２記載の販売支援装置。

（付記４） 前記審査過程案件情報の内容の確認が複数の前記確認担当者により行われる場合、前記進捗情報記憶手段には、前記確認担当者ごとに前記確認状態が設けられており、
前記審査管理手段は、前記審査過程案件情報の内容確認をする複数の前記確認担当者それぞれが使用する複数の前記確認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記確認用端末から確認完了を示す前記確認情報を受け取ると、前記確認情報を送信した前記確認用端末を使用する前記確認担当者に対応する前記確認状態に確認済と設定し、すべての前記確認状態が確認済となった場合に、前記審査過程案件情報を前記承認用端末に対して送信する、
ことを特徴とする付記３記載の販売支援装置。

（付記５） 前記取引条件記憶手段には、前記取引条件として、商品の販売総額の上限額を示しており、与信情報による信用度が高いほど高い額となると共に、過去の取引回数が多いほど高い額となる販売規模上限値が設定されていることを特徴とする付記１記載の販売支援装置。

（付記６） 前記取引条件記憶手段には、前記取引条件として、与信情報による信用度が高いほど高い値となると共に、過去の取引回数が多いほど高い値となる割引率が設定されていることを特徴とする付記１記載の販売支援装置。

（付記７） 前記取引条件記憶手段には、前記取引条件として、与信情報による信用度が高いほど長い期間となると共に、過去の取引回数が多いほど長い期間となる支払いサイトが設定されていることを特徴とする付記１記載の販売支援装置。

（付記８） コンピュータで販売支援を行うための販売支援プログラムであって、
コンピュータを、
顧客の与信情報を記憶する顧客情報記憶手段、
顧客との過去の取引履歴を記憶する取引履歴記憶手段、
顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する取引条件記憶手段、
注文用端末から取引相手顧客を指定した取引条件取得要求が入力されると、前記顧客情報記憶手段から前記取引相手顧客の前記与信情報を取得し、前記取引履歴記憶手段から前記取引相手顧客との前記取引履歴を取得し、前記取引条件記憶手段を参照し、前記取引相手顧客の前記与信情報と前記取引履歴とに応じた前記取引条件を決定する取引条件決定手段、
前記取引条件決定手段が決定した前記取引条件を前記注文用端末に送信する取引条件送信手段、
として機能させる販売支援プログラム。

（付記９） 前記取引履歴記憶手段には、過去に行われた取引の内容を示す既取引案件情報に加えて、注文を受けて取引の承認を待つ段階にある審査過程案件情報が格納されており、
前記コンピュータを、さらに、
承認担当者の使用する承認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記承認用端末から取引を承認することを示す承認情報を受け取ると、前記注文用端末に対して承認された前記審査過程案件情報を送信する審査管理手段、
として機能させることを特徴とする付記８記載の販売支援プログラム。

（付記１０） コンピュータで販売支援を行うための販売支援方法であって、
前記コンピュータが、
注文用端末から、取引相手顧客を指定した取引条件取得要求が入力されると、顧客の与信情報を記憶する顧客情報記憶手段から前記取引相手顧客の前記与信情報を取得し、
顧客との過去の取引履歴を記憶する取引履歴記憶手段から前記取引相手顧客との前記取引履歴を取得し、
顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する取引条件記憶手段を参照し、前記取引相手顧客の前記与信情報と前記取引履歴とに応じた前記取引条件を決定し、
決定した前記取引条件を前記注文用端末に送信する、
ことを特徴とする販売支援方法。

（付記１１） 前記取引履歴記憶手段には、過去に行われた取引の内容を示す既取引案件情報に加えて、注文を受けて取引の承認を待つ段階にある審査過程案件情報が格納されており、
前記コンピュータが、さらに、
承認担当者の使用する承認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記承認用端末から取引を承認することを示す承認情報を受け取ると、前記注文用端末に対して承認された前記審査過程案件情報を送信することを特徴とする付記１０記載の販売支援方法。

実施の形態の概要を示す図である。 本実施の形態のシステム構成例を示す図である。 注文処理業務を示す図である。 本実施の形態に用いる販売管理サーバのハードウェア構成例を示す図である。 販売管理サーバの機能を示すブロック図である。 顧客情報ＤＢのデータ構造例を示す図である。 案件管理ＤＢのデータ構造例を示す図である。 商品ＤＢのデータ構造例を示す図である。 ワークフローＤＢのデータ構造例を示す図である。 取引条件記憶部のデータ構造例を示す図である。 注文の受付から注文が確定するまでの処理を示すフローチャートである。 注文受け付け処理の手順を示すフローチャートである。 価格確認処理の手順を示すフローチャートである。 与信確認処理の手順を示すフローチャートである。 承認処理の手順を示すフローチャートである。 受注処理の手順を示すフローチャートである。 案件管理画面の例を示す図である。 価格確認画面の例を示す図である。 与信確認画面の例を示す図である。 承認画面の例を示す図である。

符号の説明

１ 販売支援装置
１ａ 顧客情報記憶手段
１ｂ 取引履歴記憶手段
１ｃ 取引条件記憶手段
１ｄ 進捗情報記憶手段
１ｅ 取引条件決定手段
１ｆ 取引条件送信手段
１ｇ 審査管理手段
２ 注文用端末
３ 確認用端末
４ 承認用端末

Claims (10)

1. 販売を支援する販売支援装置であって、
   顧客の与信情報を記憶する顧客情報記憶手段と、
   顧客との過去の取引履歴を記憶する取引履歴記憶手段と、
   顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する取引条件記憶手段と、
   注文用端末から取引相手顧客を指定した取引条件取得要求が入力されると、前記顧客情報記憶手段から前記取引相手顧客の前記与信情報を取得し、前記取引履歴記憶手段から前記取引相手顧客との前記取引履歴を取得し、前記取引条件記憶手段を参照し、前記取引相手顧客の前記与信情報と前記取引履歴とに応じた前記取引条件を決定する取引条件決定手段と、
   前記取引条件決定手段が決定した前記取引条件を前記注文用端末に送信する取引条件送信手段と、
   を有する販売支援装置。
2. 前記取引履歴記憶手段には、過去に行われた取引の内容を示す既取引案件情報に加えて、注文を受けて取引の承認を待つ段階にある審査過程案件情報が格納されており、
   さらに、
   承認担当者の使用する承認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記承認用端末から取引を承認することを示す承認情報を受け取ると、前記注文用端末に対して承認された前記審査過程案件情報を送信する審査管理手段、
   を有することを特徴とする請求項１記載の販売支援装置。
3. 前記審査過程案件情報が確認担当者によって内容確認を経た後に承認される場合に、さらに、
   前記審査過程案件情報の確認の有無を示す確認状態を記憶する進捗情報記憶手段を有し、
   前記審査管理手段は、前記審査過程案件情報の内容確認をする確認担当者が使用する確認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記確認用端末から確認完了を示す確認情報を受け取ると、前記進捗情報記憶手段内の前記審査過程案件情報の前記進捗情報に確認済と設定し、前記確認状態が確認済となった前記審査過程案件情報を前記承認用端末に対して送信する、
   ことを特徴とする請求項２記載の販売支援装置。
4. 前記審査過程案件情報の内容の確認が複数の前記確認担当者により行われる場合、前記進捗情報記憶手段には、前記確認担当者ごとに前記確認状態が設けられており、
   前記審査管理手段は、前記審査過程案件情報の内容確認をする複数の前記確認担当者それぞれが使用する複数の前記確認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記確認用端末から確認完了を示す前記確認情報を受け取ると、前記確認情報を送信した前記確認用端末を使用する前記確認担当者に対応する前記確認状態に確認済と設定し、すべての前記確認状態が確認済となった場合に、前記審査過程案件情報を前記承認用端末に対して送信する、
   ことを特徴とする請求項３記載の販売支援装置。
5. 前記取引条件記憶手段には、前記取引条件として、商品の販売総額の上限額を示しており、与信情報による信用度が高いほど高い額となると共に、過去の取引回数が多いほど高い額となる販売規模上限値が設定されていることを特徴とする請求項１記載の販売支援装置。
6. 前記取引条件記憶手段には、前記取引条件として、与信情報による信用度が高いほど高い値となると共に、過去の取引回数が多いほど高い値となる割引率が設定されていることを特徴とする請求項１記載の販売支援装置。
7. 前記取引条件記憶手段には、前記取引条件として、与信情報による信用度が高いほど長い期間となると共に、過去の取引回数が多いほど長い期間となる支払いサイトが設定されていることを特徴とする請求項１記載の販売支援装置。
8. コンピュータで販売支援を行うための販売支援プログラムであって、
   コンピュータを、
   顧客の与信情報を記憶する顧客情報記憶手段、
   顧客との過去の取引履歴を記憶する取引履歴記憶手段、
   顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する取引条件記憶手段、
   注文用端末から取引相手顧客を指定した取引条件取得要求が入力されると、前記顧客情報記憶手段から前記取引相手顧客の前記与信情報を取得し、前記取引履歴記憶手段から前記取引相手顧客との前記取引履歴を取得し、前記取引条件記憶手段を参照し、前記取引相手顧客の前記与信情報と前記取引履歴とに応じた前記取引条件を決定する取引条件決定手段、
   前記取引条件決定手段が決定した前記取引条件を前記注文用端末に送信する取引条件送信手段、
   として機能させる販売支援プログラム。
9. 前記取引履歴記憶手段には、過去に行われた取引の内容を示す既取引案件情報に加えて、注文を受けて取引の承認を待つ段階にある審査過程案件情報が格納されており、
   前記コンピュータを、さらに、
   承認担当者の使用する承認用端末に対して前記取引相手顧客の前記審査過程案件情報、前記取引相手顧客の前記与信情報、および前記取引相手顧客の前記既取引案件情報を送信し、前記承認用端末から取引を承認することを示す承認情報を受け取ると、前記注文用端末に対して承認された前記審査過程案件情報を送信する審査管理手段、
   として機能させることを特徴とする請求項８記載の販売支援プログラム。
10. コンピュータで販売支援を行うための販売支援方法であって、
    前記コンピュータが、
    注文用端末から、取引相手顧客を指定した取引条件取得要求が入力されると、顧客の与信情報を記憶する顧客情報記憶手段から前記取引相手顧客の前記与信情報を取得し、
    顧客との過去の取引履歴を記憶する取引履歴記憶手段から前記取引相手顧客との前記取引履歴を取得し、
    顧客の与信情報と取引履歴との組合せに応じた取引条件を記憶する取引条件記憶手段を参照し、前記取引相手顧客の前記与信情報と前記取引履歴とに応じた前記取引条件を決定し、
    決定した前記取引条件を前記注文用端末に送信する、
    ことを特徴とする販売支援方法。

Images