(57)【要約】【課題】決済機関は企業単位で与信枠を設定して管理することが不可欠であるにもかかわらず、部署毎、支店毎といったように企業内で複数の与信枠が設定されてしまうことになるため、企業を対象として共同購入を実施するための電子商取引において信用販売による決済を導入し難いという課題が発生した。【解決手段】電子商取引システム１は、販売仲介サーバ２と、決済機関サーバ３と、購入企業端末５１Ａ〜５１Ｃと、販売企業端末６１Ａ〜６４Ａとがネットワーク４により接続されて構成されている。販売仲介サーバ２は、購入企業端末５１Ａ〜５１Ｃによって入力された発注担当者ＩＤがどのＩＤ群に属するかを判断し、企業ＩＤを導き出す。決済機関サーバ３は、販売仲介サーバ２によって導き出された企業ＩＤに基づいて与信枠の特定を行う。【選択図】図２
2007257135.tif 000002
【特許請求の範囲】
【請求項１】
複数の購入者がデータベースに登録された商品を共同で購入するための共同購入サービスを前記購入者に対して提供する機能と、前記共同購入サービスを利用して購入する商品を予め設定された与信枠に基づいて決済する機能とを備える、ネットワーク上での電子商取引システムであって、
前記複数の購入者に対してそれぞれ設定されたＩＤを入力するＩＤ入力手段と、
前記ＩＤ入力手段により入力されたＩＤに対応し、前記データベースに登録された商品の購入データを入力する購入データ入力手段と、
前記ＩＤ入力手段により入力されたＩＤがどのＩＤ群に属するかを判断するＩＤ群判断手段と、
該ＩＤ群判断手段により判断されたＩＤ群に基づいて与信枠を特定する与信枠特定手段と、
前記購入データ入力手段により入力された購入データと前記与信枠特定手段により特定された与信枠とに基づいて、購入する商品についての代金が与信枠内であるか否かを判断する与信枠判断手段と、
を有することを特徴とする電子商取引システム。
【請求項２】
前記ＩＤ群判断手段により判断されたＩＤ群に対応付けられている代表ＩＤを導き出すＩＤ導出手段を有することを特徴とする請求項１に記載の電子商取引システム。
【請求項３】
前記与信枠特定手段は、前記ＩＤ導出手段により導き出された代表ＩＤから与信枠を特定することを特徴とする請求項２に記載の電子商取引システム。
【請求項４】
前記与信枠判断手段により購入する商品についての代金が与信枠内でないと判断したとき、エラー情報を表示するエラー情報表示手段を有することを特徴とする請求項１乃至３の何れか１項に記載の電子商取引システム。
【請求項５】
前記ＩＤ入力手段により入力されたＩＤに基づいて前記共同購入サービスの利用を許可するか否かを判断する共同購入サービス許可手段を有することを特徴とする請求項１乃至４の何れか１項に記載の電子商取引システム。
【請求項６】
前記電子商取引システムは、複数の入力端末を備え、何れの入力端末からでも前記ＩＤ及び前記購入データを入力可能としたことを特徴とする請求項１乃至５の何れか１項に記載の電子商取引システム。
【請求項７】
前記ＩＤ群に属するＩＤを新規に登録するＩＤ登録手段を有することを特徴とする請求項１乃至６の何れか１項に記載の電子商取引システム。
【請求項８】
前記複数の入力端末はイントラネットで接続されていることを特徴とする請求項６に記載の電子商取引システム。
【請求項９】
複数の購入者がデータベースに登録された商品を共同で購入するための共同購入サービスを前記購入者に対して提供する機能と、前記共同購入サービスを利用して購入する商品を予め設定された与信枠に基づいて決済するにあたり、前記商品の代金が与信枠内であるか否かを決算機関システムに対して問い合わせる機能とを備える販売仲介システムであって、
前記購入者が操作する入力端末により入力されたＩＤを取得するＩＤ取得手段と、
前記ＩＤ取得手段により取得したＩＤに対応して入力された購入データを受け付ける購入データ受付手段と、
前記ＩＤ取得手段により取得したＩＤがどのＩＤ群に属するかを判断するＩＤ群判断手段と、
を有することを特徴とする販売仲介システム。
【請求項１０】
前記ＩＤ群判断手段により判断されたＩＤ群に対応付けられている代表ＩＤを導き出すＩＤ導出手段を有することを特徴とする請求項９に記載の販売仲介システム。
【請求項１１】
前記ＩＤ導出手段により導き出された代表ＩＤと、前記購入データ受付手段により受け付けた購入データとを前記決算機関システムに送信する送信手段を有することを特徴とする請求項１０に記載の販売仲介システム。
【請求項１２】
前期決算機関システムは、前記送信手段によって送信された代表ＩＤから与信枠を特定することを特徴とする請求項１１に記載の販売仲介システム。
【請求項１３】
前記ＩＤ取得手段により取得したＩＤに基づいて前記共同購入サービスの利用を許可するか否かを判断する共同購入サービス許可手段を有することを特徴とする請求項９乃至１２の何れか１項に記載の販売仲介システム。
【請求項１４】
前記共同購入サービス許可手段により共同購入サービスの利用が許可されないとき、前記入力端末に対してエラー情報を送信するエラー情報送信手段を有することを特徴とする請求項１３に記載の販売仲介システム。
【請求項１５】
複数の購入者がデータベースに登録された商品を共同で購入するための共同購入サービスを前記購入者に対して提供する機能と、前記共同購入サービスを利用して購入する商品を予め設定された与信枠に基づいて決済するにあたり、前記商品の代金が与信枠内であるか否かを決算機関システムに対して問い合わせる機能とを備える販売仲介システムに用いられるプログラムであって、
コンピュータを、
前記購入者が操作する入力端末により入力されたＩＤを取得するＩＤ取得工程と、
前記ＩＤ取得工程により取得したＩＤに対応して入力された購入データを取得する購入データ取得工程と、
前記ＩＤ取得工程により取得したＩＤがどのＩＤ群に属するかを判断するＩＤ群判断工程と、
前記ＩＤ群判断工程により判断されたＩＤ群に対応付けられている代表ＩＤを導き出すＩＤ導出工程と、
前記ＩＤ導出工程により導き出された代表ＩＤと前記購入データ取得工程により取得された購入データとを前記決算機関システムに送信する送信工程と、
を含んで実行させることを特徴とする販売仲介システムに用いられるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、企業を対象として共同購入を実施するための電子商取引システムに関する。
【背景技術】
【０００２】
近年では、インターネットなどのネットワークの発達に伴って、ネットワーク上での商取引を実施する、いわゆる電子商取引が広く利用されるようになってきている。この電子商取引は大きく３つの形態に分けられ、企業同士の取引を「ＢｔｏＢ」（Ｂｕｓｉｎｅｓｓ  ｔｏ  Ｂｕｓｉｎｅｓｓ）、企業・消費者間の取引を「ＢｔｏＣ」（Ｂｕｓｉｎｅｓｓ  ｔｏ  Ｃｏｎｓｕｍｅｒ）、消費者同士の取引を「ＣｔｏＣ」（Ｃｏｎｓｕｍｅｒ  ｔｏ  Ｃｏｎｓｕｍｅｒ）と呼ばれている。
【０００３】
ところで、電子商取引における決済方法としては、銀行振込や郵便振替など、購入者が金融機関に赴き、販売者が指定する口座へ直接現金を振り込むのが一般的である。しかし、この従来の決済方法では、購入者にとっては、わざわざ金融機関に足を運ぶための時間が必要であることと、支払い代金を現金ですぐに用意できなければ購入できないという問題がある。また、販売者にとっては自身の口座番号など、秘匿性の高い情報を購入者に告知しなければならないという問題がある。
【０００４】
そこで、このような問題を解決するため、購入者が事前に信販会社などの決済機関に登録して与信枠を設定しておき、この与信枠内において決済機関が購入者の代金を一時的に立て替える信用販売による決済が行われている。このような信用販売による決済ならば、購入者は、あわてて金融機関に赴いて煩雑な振込作業を行わなくてよいし、手元に現金がなくても所定の期日時点で引き落とし口座に所要の残高があれば購入することができる。また、販売者は口座番号などを知られずに代金を徴収できる。
【０００５】
このような信用販売による決済方法を用いた電子商取引システムとして、例えば、特許文献１には、各個人購入者に対してその購入申し込み時点での申込総数に応じた設定価格で商品を販売し、当該価格に基づく金額で商品の発注をして当該金額の支払い承諾の与信を決済機関に対して問い合わせ、与信枠（与信限度額）を確保する電子商取引システムが提供されている。
【０００６】
一方、電子商取引の形態のなかでもＢｔｏＢとして、販売企業から提供される商品や資材を複数の購入企業が一括して発注することにより、購入企業が単独で商品を購入するのに比べて商品単価を引き下げることを可能とする共同購入システムが開発されている（例えば、特許文献２参照）。
【特許文献１】特開２００２−３１８９２７号公報
【特許文献２】特開２００２−９２４０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記特許文献１に係る決済方法は、商品を購入した個人消費者毎に信用を供与して与信枠を設定するものであり、ＢｔｏＢの共同購入システムに適用することについては考慮されていなかった。すなわち、上記の決済方法を用いて企業が購入した商品に対して決済する場合、企業では部署毎あるいは支店毎に必要な分だけ商品を発注して購入するため、それぞれの発注部署毎あるいは発注支店毎に与信枠を設定しなければならなかった。したがって、決済機関は企業単位で与信枠を設定して管理することが不可欠であるにもかかわらず、部署毎、支店毎といったように企業内で複数の与信枠が設定されてしまうことになるため、信用販売による決済を導入し難いという課題が発生した。
【０００８】
本発明は、上記課題に鑑みてなされたものであって、企業を対象として共同購入を実施するための電子商取引システムにおいて、信用販売による決済を簡易に導入することができる電子商取引システム、販売仲介システム及び販売仲介システムに用いられるプログラムの提供を目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するため本発明の電子商取引システムは、複数の購入者がデータベースに登録された商品を共同で購入するための共同購入サービスを前記購入者に対して提供する機能と、前記共同購入サービスを利用して購入する商品を予め設定された与信枠に基づいて決済する機能とを備える、ネットワーク上での電子商取引システムであって、前記複数の購入者に対してそれぞれ設定されたＩＤを入力するＩＤ入力手段と、前記ＩＤ入力手段により入力されたＩＤに対応し、前記データベースに登録された商品の購入データを入力する購入データ入力手段と、前記ＩＤ入力手段により入力されたＩＤがどのＩＤ群に属するかを判断するＩＤ群判断手段と、該ＩＤ群判断手段により判断されたＩＤ群に基づいて与信枠を特定する与信枠特定手段と、前記購入データ入力手段により入力された購入データと前記与信枠特定手段により特定された与信枠とに基づいて、購入する商品についての代金が与信枠内であるか否かを判断する与信枠判断手段と、を有することを特徴とする。
【００１０】
また、上記課題を解決するため本発明の販売仲介システムは、複数の購入者がデータベースに登録された商品を共同で購入するための共同購入サービスを前記購入者に対して提供する機能と、前記共同購入サービスを利用して購入する商品を予め設定された与信枠に基づいて決済するにあたり、前記商品の代金が与信枠内であるか否かを決算機関システムに対して問い合わせる機能とを備える販売仲介システムであって、前記購入者が操作する入力端末により入力されたＩＤを取得するＩＤ取得手段と、前記ＩＤ取得手段により取得したＩＤに対応して入力された購入データを受け付ける購入データ受付手段と、前記ＩＤ取得手段により取得したＩＤがどのＩＤ群に属するかを判断するＩＤ群判断手段と、を有することを特徴とする。
【００１１】
また、上記課題を解決するため本発明の販売仲介システムに用いられるプログラムは、
複数の購入者がデータベースに登録された商品を共同で購入するための共同購入サービスを前記購入者に対して提供する機能と、前記共同購入サービスを利用して購入する商品を予め設定された与信枠に基づいて決済するにあたり、前記商品の代金が与信枠内であるか否かを決算機関システムに対して問い合わせる機能とを備える販売仲介システムに用いられるプログラムであって、コンピュータを、前記購入者が操作する入力端末により入力されたＩＤを取得するＩＤ取得工程と、前記ＩＤ取得工程により取得したＩＤに対応して入力された購入データを取得する購入データ取得工程と、前記ＩＤ取得工程により取得したＩＤがどのＩＤ群に属するかを判断するＩＤ群判断工程と、前記ＩＤ群判断工程により判断されたＩＤ群に対応付けられている代表ＩＤを導き出すＩＤ導出工程と、前記ＩＤ導出工程により導き出された代表ＩＤと前記購入データ取得工程により取得された購入データとを前記決算機関システムに送信する送信工程と、を含んで実行させることを特徴とする。
【発明の効果】
【００１２】
本発明においては、入力されたＩＤがどのＩＤ群に属するかを判断するので、複数のＩＤを１つのＩＤ群として扱うことができる。したがって、決算機関はこのＩＤ群に対応して購入企業の与信枠を設定しておけば、複数のＩＤを有する購入企業であっても１つの与信枠により与信管理が可能となるので、これにより信用販売による決済を簡易に導入することができる。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して本発明の実施の形態を説明する。なお、本実施の形態における記載により、本発明の技術的範囲が限定されることはない。
【００１４】
図１は、本実施の形態における電子商取引システム１の概略全体構成図である。図１に示すように、この電子商取引システム１は、販売仲介サーバ２と、決済機関サーバ３と、購入企業５１のＡ支店、Ｂ支店及びＣ支店にそれぞれ備えられた購入企業端末５１Ａ、５１Ｂ及び５１Ｃと、販売企業６１、６２、６３及び６４にそれぞれ備えられた販売企業端末６１Ａ、６２Ａ、６３Ａ及び６４Ａとがネットワーク４により接続されて構成されている。
【００１５】
販売仲介サーバ２は、インターネットなどから構成されるネットワーク４を利用し、購入企業５１に対して、消耗品・補修用品など企業内で日常的に使用されるサプライ用品（ＭＲＯ）のオンライン共同購入サービスを提供するためのサーバである。販売仲介サーバ２は、購入企業５１の各Ａ〜Ｃ支店と、各販売企業６１〜６４と、決済機関サーバ３との３者間での受発注及び支払請求にかかる業務を仲介するサービスを購入企業５１に対して提供する。この共同購入サービスにより、購入企業５１は販売企業６１〜６４により提供される商品を一括したシステムで購入することができるとともに、購入した商品の代金を信用販売による決済で支払うことが可能となる。
【００１６】
販売仲介サーバ２は、販売仲介会社に設置されている。この販売仲介サーバ２には、受発注や支払請求などのデータを記憶する受発注データベース２１、販売企業６１〜６４から提供される商品の名称、価格、説明などからなるテキストデータやその商品の画像データを記憶する商品データベース２２、及び、後述する購入企業５１の名称、住所及び販売仲介サーバ２にログインするためのＩＤ、パスワードからなるデータなどが登録された購入企業データベース２３などが存在し、販売仲介サーバ２はこれらデータベース２１〜２３を管理するように構成されている。
【００１７】
なお、本実施の形態においては、販売仲介サーバ２により共同購入サービスの機能が達成できるように構成しているが、例えば、複数のパーソナルコンピュータをＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などで接続してシステムを構成し、これにより共同購入サービスの機能を達成するようにしても良い。
【００１８】
決済機関サーバ３は、購入企業５１の代金を立て替えて販売仲介会社に支払うとともに、所定の期日に一括して購入企業５１から後払いを受ける信販会社などの決済機関に設置されている。すなわち、この決済機関サーバ３は、販売仲介サーバ２からの請求に応じて購入企業５１に代行してこれを販売仲介会社に支払い、かつ、所定期日に購入企業５１からその支払いを受けるための処理を行う。購入企業５１は予め決済機関に対して会員登録されており、購入企業５１の決済属性（売上高や信用情報など）に応じて購入企業５１に与信枠が設定されている。
【００１９】
決済機関サーバ３には、購入企業５１毎に設定された与信枠が登録される与信枠データベース３１、購入企業５１の支払いを立て替えた金額が登録される代金データベース３２が存在する。なお、この販売仲介サーバ２は、ＣＡＦＩＳ（Ｃｒｅｄｉｔ  Ａｎｄ  Ｆｉｎａｎｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｗｉｔｃｈｉｎｇ  ｓｙｓｔｅｍ）などのクレジット専用のサービスによりネットワーク４と接続しても良い。
【００２０】
購入企業５１には、管轄地に応じてＡ支店、Ｂ支店、Ｃ支店が設けられている。Ａ支店は購入企業端末５１Ａ、Ｂ支店は購入企業端末５１Ｂ、Ｃ支店は購入企業端末５１Ｃを備えており、これら購入企業端末５１Ａ〜５１Ｃ（本発明におけるＩＤ入力手段、購入データ入力手段及びＩＤ登録手段とを兼ねる）はイントラネットにより接続されている。各支店に配属された操作者（発注担当者、発注承認者など）が購入企業端末５１Ａ〜５１Ｃを操作することにより、各支店の在庫状況に合わせて商品の発注、支払請求をすることが可能となっている。なお、ここでいうイントラネットとは、物理的な企業内ネットワークだけではなく、インターネットを経由した企業内ネットワークも含むものである。
【００２１】
各販売企業６１〜６４は、それぞれ独自に販売企業端末６１Ａ、６２Ａ、６３Ａ、６４Ａを備えている。これら販売企業端末６１Ａ〜６４Ａは、各販売企業６１〜６４が販売する商品の名称、価格、説明などからなるテキストデータやその商品の画像データを商品データべース（図示せず）に登録している。販売企業端末６１Ａ〜６４Ａに登録された商品データベースの内容は、定期的に（例えば毎朝）販売仲介サーバ２に送信されるように構成されており、販売仲介サーバ２の商品データベース２２の内容は、常に最新の情報を維持している。
【００２２】
図２は、販売仲介サーバ２が行う処理１０１〜１１２を示すブロック図である。なお、購入企業５１に対して処理（図２で購入企業５１と矢印で結ばれている処理）を行う場合は、購入企業端末５１Ａ〜５１ＣのＷＷＷブラウザのｗｅｂページを用いて、各操作者と情報をやり取りするようになっている。
【００２３】
購入企業情報管理１０１は、購入企業５１の企業属性（名称、所在地など）や後述するＩＤ・パスワードを、購入企業５１の各購入企業端５１Ａ〜５１Ｃからの入力を受けて、購入企業データベース２３に登録したり更新したりする処理である。
【００２４】
ＩＤ・パスワード認証１０２（本発明における共同購入サービス許可手段）は、購入企業端末５１Ａ〜５１Ｃが販売仲介サーバ２にログインしたり、販売仲介サーバ２の特定の処理機能を利用しようとするときに、購入企業データベース２３に登録された各種ＩＤ・パスワードを用いて、その購入企業端末５１Ａ〜５１Ｃの操作者の認証を行う処理である。
【００２５】
商品情報管理１０３は、各販売企業端末６１Ａ〜６４Ａ内の商品データベースから更新データを定期的に取得し、販売仲介サーバ２内の商品データベース２２を更新して管理する処理である。
【００２６】
商品検索１０４は、購入企業５１からの商品検索要求に応じて、商品データベース２２に登録された商品のテキストデータ及び画像データを購入企業５１へ送信する処理である。
【００２７】
受注１０５（本発明における購入データ受付手段）は、購入企業５１から購入データを受ける処理である。この購入データは、販売仲介サーバ２の受発注データベース２１に登録される。
【００２８】
企業ＩＤ導出１０６（本発明におけるＩＤ導出手段）は、購入企業５１の各支店に勤務する発注担当者に対してそれぞれ設定されている発注担当者ＩＤから、購入企業毎に設定された企業ＩＤを導き出す処理を行う。企業ＩＤは、予め購入企業データベース２３に登録されている。この変換１０６の詳細については後述する。
【００２９】
与信枠の確認１０７は、決済機関サーバ３に対して、ＩＤ導出１０６において導出された企業ＩＤ及び購入企業５１の購入情報（購入データ）を送信し、与信枠データベース３１に登録されている与信枠内であるか否かを確認する処理である。
【００３０】
発注１０８は、受注１０５で取得した購入データを販売企業６１〜６４に振り分け、各販売企業６１〜６４に送信する（発注する）処理である。
【００３１】
請求受信１０９は、購入企業５１が購入した商品についての請求を各販売企業６１〜６４から受け取り、受発注データベース２１に登録されている購入データと照合してチェックし、保存する処理である。
【００３２】
請求明細確認１１０は、購入企業５１の購入商品についての代金に販売仲介会社の利益分の金額を加算して請求明細を作成し、この請求明細を購入企業５１に送信する処理である。
【００３３】
請求送信１１１は、請求明細確認１１０で作成した請求明細に基づき、決済機関サーバ３へ請求を送信する処理である。
【００３４】
支払通知受信１１２は、決済機関サーバ３から商品代金の支払いデータを受け、請求明細と照合して違算チェックを行う処理である。
【００３５】
図２の左側の部分に示すように、購入企業５１内では、操作者の職務権限に応じて、販売仲介サーバ２が提供する機能の中から利用可能なものを限定する必要がある。また、複数の支店を備える購入企業５１においては、支店毎に商品を発注したり予算管理をする必要がある。したがって、支店毎、操作者毎に対して販売仲介サーバ２にログインするためのＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｄａｔａ）を設定し、図３に示すように、支店、操作者、ＩＤ及びパスワードからなるＩＤテーブルを購入企業データベース２３に登録しておく。そして、販売仲介サーバ２はログイン時に入力されたＩＤに応じて利用できる業務範囲を制限する処理を行う。
【００３６】
なお、ここでいうＩＤとは各操作者を認識するための識別情報のことであり、数字、文字、記号などを単独で、あるいはこれらを組み合わせて構成することができる。また、パスワードについては、各操作者が適宜設定変更することが可能である。
【００３７】
図４は、各操作者に設定されたＩＤを入力して販売仲介サーバ２にログインしたときに、各操作者が利用できる機能を説明する図である。図に示すように、販売仲介サーバ２は、システム管理者ＩＤ「１００１」を入力してログインした操作者に対しては、図２に示した購入企業情報管理１０１を利用し、購入企業全体に関する購入企業情報の登録や更新を行うことを許可する。
【００３８】
発注担当者ＩＤ「１００２」、「１００４」、「１００６」を入力してログインした操作者に対しては、商品検索１０４や発注１０５の利用を許可する。発注承認者ＩＤ「１００３」、「１００５」、「１００７」を入力してログインした操作者に対しては、請求明細確認１１０を許可する。このように、販売仲介サーバ２は、操作者が販売仲介サーバ２へのログイン時に入力したＩＤにより操作者の職務権限を判断し、以降に行うことができる処理を決定する。
【００３９】
なお、図３に示すＩＤテーブルの登録方法は、まず、購入企業５１が共同購入サービスの利用登録をする際に、販売仲介会社に対して提出する利用登録申請書にシステム管理者ＩＤを記載しておく。ついで、販売仲介会社の操作者は、該利用登録申請書を受け取ると、購入企業５１の登録作業を行うとともに、利用登録申請書に記載されたシステム管理者ＩＤを購入企業データベース２３に登録する。システム管理者１２１は、購入企業端末５１Ａ〜５Ｃの何れかによりシステム管理者ＩＤを入力して共同購入サービスにログインし、購入企業情報１０１でその他の操作者（発注担当者、発注承認者など）のＩＤを登録する（本発明におけるＩＤ登録手段）。そして、この登録作業を繰り返し、全操作者に対してＩＤを登録することより、販売仲介サーバ２の購入企業データベース２３にＩＤテーブルが登録される。
【００４０】
以上のようなＩＤによる利用業務の制限は、図２に示したＩＤ・パスワード認証１０２の処理で行う。すなわち、販売仲介サーバ２は、ログイン時に操作者により入力されたＩＤと購入企業データベース２３に登録されているＩＤテーブルのＩＤとを比較する。そして、ＩＤ及びパスワードが正しいものであるか否かを判断するとともに、ＩＤ及びパスワードが正しければ、そのＩＤに付与されている権限に応じて、購入企業端末５１Ａ〜５１Ｃの表示部に表示するＷＷＷブラウザのｗｅｂページにおいて、選択可能な業務の種類を制限する。このように、操作者の業務権限に応じて操作できる処理を設定することで、購入企業５１の組織構造に適合した業務権限の管理を行うことができる。
【００４１】
また、上記したように、発注担当者毎にＩＤが設定されており、各発注担当者は、それぞれ別々に設定された発注担当者ＩＤを入力して販売仲介サーバ２へログインし、商品の発注を行う。一方、販売仲介サーバ２は、ログイン時に入力されたＩＤに基づいて操作者に対する処理を決定するため、ログイン以降の処理については操作者をＩＤにより管理している。すなわち、購入した商品の代金について決済機関に与信枠の確認をするときも、ログイン時に入力されたＩＤ（発注担当者ＩＤ）に基づいて行われることになる。
【００４２】
したがって、このような形態であると、Ａ支店〜Ｃ支店の各発注担当者がそれぞれの発注担当者ＩＤによりログインして商品を発注し、発注した商品の代金について信用販売による決済をする場合、それぞれの支店（あるいは発注担当者ＩＤ）に対して与信枠を設定しておく必要が生じてしまう。
【００４３】
そこで、本実施の形態では、図５に示すように、発注担当者ＩＤ「１００２」、「１００４」、「１００６」をＩＤ群として設定しておくとともに、該ＩＤ群に応付けて企業ＩＤ（代表ＩＤともいう）を設定しておく。そして、与信枠の確認１０７において与信枠を確認する際に、入力された発注担当者ＩＤがどのＩＤ群に属するかを判断（本発明におけるＩＤ群判断手段）し、ＩＤ導出１０６により発注担当者ＩＤ「１００２」、「１００４」、「１００６」から企業ＩＤを導き出す。そして、決済機関サーバ３では、この企業ＩＤに基づいて与信枠を特定し（本発明における与信枠特定手段）、与信枠の照合を行う（本発明における与信枠判断手段）。
【００４４】
このように、複数の発注担当者ＩＤが割り振られた購入企業５１においては、発注担当者ＩＤからＩＤ群を判断して企業ＩＤを導き出し、この企業ＩＤに基づいて与信枠を確認する。したがって、決済機関サーバ３は、購入企業毎に設定されている企業ＩＤに対応して与信枠を設定しておけば良いので、購入企業毎に与信枠を管理することができる。なお、図５に示す発注担当者ＩＤと企業ＩＤとからなる企業ＩＤテーブルは、予めシステム管理者１２１により購入企業データベース２３に登録されている。
【００４５】
以上のような構成の下で、本実施形態の動作を以下に詳細に説明する。
【００４６】
図６は、販売仲介サーバ２へのログインから決済までについての電子商取引システム１の全体の動作の流れを示す。なお、本実施の形態においては、予め、システム管理者１２１の入力操作により、購入企業５１の属性、図３に示すＩＤテーブル、図５に示す企業ＩＤテーブルが購入企業データベース２３に登録されているものとする。
【００４７】
また、以下に示す処理は、購入企業５１のＡ支店における操作者が発注、支払いなどの処理を行う例について説明するが、Ｂ支店及びＣ支店についても同一の処理を行うことにより発注、支払いをすることが可能である。すなわち、各支店の操作者は、購入企業端末５１Ａ〜５１Ｃの何れの端末からでも、各操作者に設定されているＩＤを入力してログインし、必要とする商品について発注、支払いなどの処理をすることができる。
【００４８】
まず、購入企業５１のＡ支店の発注担当者は、購入企業端末５１Ａを操作することにより、ＷＷＷブラウザを立ち上げる（ステップＳ１）。そして、所定のＵＲＬを入力し、共同購入サービスのＴＯＰ画面、すなわち共同購入サービスにログインするためのＩＤ・パスワード入力画面を表示させる（ステップＳ２）。
【００４９】
Ａ支店の発注担当者により、発注担当者ＩＤ「１００２」及び該ＩＤに対応するパスワード「○○○」が入力される（ステップＳ３）と、販売仲介サーバ２は購入企業データベース２３のＩＤテーブルを確認し、ＩＤ及びパスワードの認証を行う（ステップＳ４）。ＩＤあるいはパスワードが正しくない場合（ステップＳ５でＮＯ）は、購入企業端末５１Ａにエラー情報を送信し（エラー情報送信手段）、購入企業端末５１ＡにてＩＤあるいはパスワードの再入力を促す。
【００５０】
ＩＤ及びパスワードが正しい場合（ステップＳ５でＹＥＳ）は、ログイン完了の画面及び商品検索用の画面を購入企業端末５１Ａに送信する（ステップＳ６）。
【００５１】
発注担当者は表示された商品検索用画面から、販売仲介サーバ２に対して所望する商品について検索依頼をする（ステップＳ７）。販売仲介サーバ２は、要求された商品についてのテキストデータ及び画像データを商品データベース２２から検索し（ステップＳ８）、購入企業端末５１Ａにその商品のテキストデータと画像を送信する。
【００５２】
これらステップＳ７及びステップＳ８を繰り返して商品が決定すると、該商品を購入予定商品として登録する（ステップＳ９）。図７は、商品検索を行うときに購入企業端末５１Ａの表示部に表示されるｗｅｂページの例を示す。この例は、商品検索を行った結果（例えば、「消しゴム」を検索した結果）を示すもので、購入企業端末５１Ａの表示部には販売仲介サーバ２の商品データベース２２に登録されている消しゴムの価格や画像が一覧として表示されている。発注担当者は、この一覧の中から１つの商品を選択し、その商品に対応した「買い物かご」ボタンをクリックすることにより、選択した商品を購入予定商品として登録することができる。
【００５３】
購入する全ての商品が買い物かごに登録され、発注担当者により「発注ボタン」がクリックされると（ステップＳ１０）、販売仲介サーバ２は発注画面を購入企業端末５１Ａに送信する（ステップＳ１１）。
【００５４】
図８は、発注を行うときに購入企業端末５１Ａの表示部に表示されるｗｅｂページの例を示す。この例では、ステップＳ９で「買い物かご」に登録された商品の商品名や単価などが表示されている。購入企業端末５１Ａにより、発注画面内の所定の項目が入力され（本発明における購入データ入力手段）、「購入ボタン」がクリックされると（ステップＳ１２）、購入データが販売仲介サーバ２に送信される。
【００５５】
販売仲介サーバ２は、購入データを保存するとともに、購入企業データベース２３に登録されている企業ＩＤテーブルに基づいて、Ａ支店の発注担当者ＩＤからＩＤ群を判断して企業ＩＤを導き出す（ステップＳ１３）。すなわち、ここでは発注担当者ＩＤ「１００２」から企業ＩＤ「１０００」が導き出される。そして、企業ＩＤ「１０００」と購入データを決済機関サーバ２に送信し（本発明における送信手段）、今回の購入にかかる代金が購入企業５１に設定された与信枠内であるか否かを決済機関サーバ３に確認する（ステップＳ１４）。
【００５６】
決済機関サーバ３では、送信された企業ＩＤと、企業ＩＤに対応して設定されている与信枠とから、購入企業５１の与信枠を特定する（ステップＳ１５）。そして、送信された購入データと代金データベース３２の登録内容とを確認しながら、所定の期間内（例えば月毎）において過去に支払った代金と今回の購入にかかる代金とを合算する（ステップＳ１６）。そして、与信枠データベース３１の登録内容を確認し、合算された金額が与信枠を超えているかどうかを照合する（ステップＳ１７）。合算金額が与信枠を超えていれば（ステップＳ１８でＮＯ）、販売仲介サーバ２にエラー情報を通知し、また、購入企業５１に対してはエラー画面を表示する（本発明のエラー情報表示手段）。
【００５７】
合算された金額が与信枠内であれば（ステップＳ１８でＹＥＳ）、販売仲介サーバ２にその旨を通知し、購入データを本発注として受けつける。その後、販売仲介サーバ２は、正式な受注データを販売企業６１〜６４別に振り分け、その受注データを基に各販売企業６１〜６４に対し発注する（ステップＳ１９）。
【００５８】
各販売企業６１〜６４は、購入企業５１に販売した商品についての請求を、請求データとして販売仲介サーバ２に送る（ステップＳ２０）。販売仲介サーバ２は、各販売企業６１〜６４からの請求を受発注データベース２１の購入データの内容に照らして違算チェックを行い（ステップＳ２１）、そして、その請求データを保存する。
【００５９】
販売仲介サーバ２は、受発注データベース２の登録内容に基づいて今回の商品購入に係る請求明細データを作成し（ステップＳ２２）、購入企業５１に送信する。購入企業５１のＡ支店では、発注承認者が発注承認者ＩＤを入力してログインし、その請求明細データを確認する。また、販売仲介サーバ２は、請求明細データを決済機関サーバ３に送信する（ステップＳ２３）。
【００６０】
決済機関サーバ３は、販売仲介サーバ２から送られてきた請求明細を受け取り、各購入企業向けの請求明細データを月毎に一括して作成し（ステップＳ２４）、購入企業５１に送信する。
【００６１】
以上がオンラインで行われる。一方、通常はオフラインで、販売企業から購入企業へ商品が配達される。また、販売仲介会社から販売企業への支払い、決済機関から販売仲介会社への支払い、購入企業から決済機関への支払いが月毎に行われる。
【００６２】
以上の説明したような処理によって、企業内のプロセスに対応した受発注及び決済業務を行うことができる。
【００６３】
なお、本実施の形態では、説明を間便にするためにネットワーク４に接続された購入企業を１社としたが、通常は複数の購入企業が接続されており、販売仲介サーバはこれら複数の購入企業に対して同様のサービスを提供するものである。
【００６４】
また、販売仲介サーバ２に存在する商品データベース２２の内容は、販売企業端末６１Ａ〜６４Ａに登録された商品データをオンラインで取得して自動的に登録、更新するように構成したが、例えば、販売企業端末６１Ａ〜６４Ａが商品データベースを持たずに、販売企業６１〜６４から商品データをオフラインで受け取り、販売仲介会社の操作者が商品データを直接入力することにより商品データベース２２の内容を登録、更新するように構成しても良い。
【図面の簡単な説明】
【００６５】
【図１】本発明における電子商取引システム１の概略全体構成図である。
【図２】販売仲介サーバ２が行う処理を示すブロック図である。
【図３】購入企業データベース２３にあるＩＤテーブルを示す図である。
【図４】各操作者に設定されたＩＤを入力して販売仲介サーバ２にログインしたときに、各操作者が利用できる機能を説明する図である。
【図５】購入企業データベース２３にある企業ＩＤテーブルを示す図である。
【図６】販売仲介サーバ２へのログインから決済までについての電子商取引システム１の全体の動作の流れを示すフローチャートである。
【図７】商品検索を行うときに購入企業端末５１Ａの表示部に表示されるｗｅｂページの例を示す図である。
【図８】発注を行うときに購入企業端末５１Ａの表示部に表示されるｗｅｂページの例を示す図である。
【符号の説明】
【００６６】
１  電子商取引システム
２  販売仲介サーバ
３  決済機関サーバ
４  ネットワーク
５１  購入企業
５１Ａ、５１Ｂ、５１Ｃ  購入企業端末
６1、６２、６３、６４  販売企業
６１Ａ、６２Ａ、６３Ａ、６４Ａ  販売企業端末
【図１】
2007257135.tif 000003
【図２】
2007257135.tif 000004
【図３】
2007257135.tif 000005
【図４】
2007257135.tif 000006
【図５】
2007257135.tif 000007
【図６】
2007257135.tif 000008
【図７】
2007257135.tif 000009
【図８】
2007257135.tif 000010