JP2014174788A - 受発注システム、受発注サーバ、受発注方法およびプログラム - Google Patents

Abstract

【課題】 ＩＴ化が進んでいない企業および販売店のコンサルティングを必要とする企業の利用に適した電子的受発注手段の提供。
【解決手段】 サーバが、受信したユーザＩＤと関連付けられた見積依頼情報および注文情報を含むユーザデータを記憶装置に記憶する手段と、受信した販売者ＩＤと関連付けられた見積回答情報および注文回答情報を含む販売者データを記憶装置に記憶する手段と、ユーザＩＤと担当として関連付けられた販売者ＩＤの情報を含むクライアントデータを記憶装置に記憶する手段と、各ユーザＩＤおよび各販売者ＩＤに固有のページをインターネット配信する手段と、販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段と、を備えることを特徴とする受発注システム
【選択図】図１

Description

本発明は、インターネットを利用した受発注システム、受発注サーバ、受発注方法およびプログラムに関する。

昨今、インターネットによる電子商取引が盛んに行われている。電子商取引の実現形態としては、電子商取引サイトの集積地であるモール型、インターネット上で買手と売手の仲介を行うインフォミディアリ型、インターネット上のオンライン店舗と現実に存在する店舗・物流システムを組み合わせ、相乗効果を図るクリック・アンド・モルタル型などがある。

従来からインターネットを利用したシステムとして、ユーザ、販売店 、卸売会社および製造会社間にインターネットを介したシステムを構築することで、既存の商品流通経路を保持したまま、ユーザに対する正確な商品知識や技術情報の伝達を可能とし、且つ商品の販売コストを全体として下げることを目的とするシステムが提案されている（特許文献１）。

本発明者も、複数のクライアントに関する情報とホストクライアントに関する情報から構成されるユニット情報をユニットＩＤと紐付けてデータベーステーブルに格納する手段と、ホストクライアントからアライアンス締結要求がなされた際に、当該アライアンス締結先のユニットのホストクライアントにアライアンス締結要求情報を送信し、当該ホストクライアントが承諾情報をサーバに返信した際にはアライアンス締結元のユニットＩＤおよびアライアンス締結先のユニットＩＤが関連付けられてなるアライアンス情報をデータベーステーブルへ書き込む手段と、クライアントからサーバへシステム資源の利用要求がなされた際に、データベーステーブルから当該クライアントのユニットＩＤと当該システム資源のユニットＩＤを照会し、両ユニットＩＤが同一である場合又はアライアンス締結元とアライアンス締結先の関係にある場合には当該システム資源を当該クライアントに開放する手段とを有するサーバと、サーバに他のユニットとのアライアンス締結を要求する手段を有するホストクライアントとを備える電子商取引システムを提案した（特許文献２）。

特開２００２−２８８４８９号公報 特許第４５００６０８号公報

従来、機械工具商品の注文は、カタログの中から、所望の商品のメーカー名、コード名、品名、型式や数量を紙などに記入し、同商品を販売する販売店に電話、ファクシミリ、郵送等、さらには口頭において申し込むことにより行われている。機械工具商品のカタログは、形状、材質、大きさ、用途等別に細分化され、掲載商品は数十万点に及び、そのページ数も数百〜数千ページにも亘る。
カタログに掲載される機械工具メーカーは、中小企業が大多数を占める。また、専門性の高い商品が多く、商品単体の説明はもちろんのこと、複数のメーカーの商品と組み合わせての利用の場合の説明を要求されることが多い。そのため、説明および支払信用リスク等の問題から、ユーザとの直接取引は行われず、現在でも大部分は販売店を通して取引が行われている。

昨今のインターネットの普及により、インターネットを介してオンラインで注文を行うインフラは整備されたといえる。同様の商品を繰り返し購入する大口ユーザの場合は、購入先が提供するシステムを導入し、オンラインで繰り返しの注文処理を効率的に行うことが可能である。また、ユーザによっては、独自のシステムを自前で導入しオンラインで効率的な取引を行っているところもある。しかしながら、購入先が多岐にわたり、購入先１社あたりの購入量が少なく、自前のシステムを導入するまでの必要性を認めていないユーザあるいは、システムの利用に懐疑的なユーザも多い。そのようなユーザに、オンラインでの注文処理を求めることは困難な場合が多い。使用頻度が少ないシステムを利用するためのユーザ研修会への参加は、かえって業務の効率性を損なう結果となる。このような現場の実情から、発明者は、ＩＴ化が進んでいない企業の利用に適した受発注システムが必要であると考えた。

また、ユーザにおいては、数十万点もある専門性の高い商品の中から、自分のニーズにあった商品を見つけることが困難な場合もある。それがゆえに、現状でも販売店によるコンサルティングを伴ったフェイス・ツー・フェイスの営業が必要とされるという事情もある。発明者は、全ての受発注をオンラインで行うのではなく、オンライン（ネット販売）と訪問販売の併用に適した受発注システムが必要であると考えた。

以上の課題を鑑み、本発明は、ＩＴ化が進んでいない企業および販売店のコンサルティングを必要とする企業の利用に適した電子的受発注手段を提供することを目的とする。

第１の発明は、販売者およびユーザが利用するクライアント端末のそれぞれとサーバとがネットワークを介して通信可能であり、前記サーバが、クライアント端末から受信したユーザＩＤと関連付けられた見積依頼情報および注文情報を含むユーザデータを記憶装置に記憶する手段と、クライアント端末から受信した販売者ＩＤと関連付けられた見積回答情報および注文回答情報を含む販売者データを記憶装置に記憶する手段と、ユーザＩＤと担当として関連付けられた販売者ＩＤの情報を含むクライアントデータを記憶装置に記憶する手段と、各ユーザＩＤおよび各販売者ＩＤに固有のページをインターネット配信する手段と、クライアント端末から販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段と、を備えることを特徴とする受発注システムである。
第２の発明は、第１の発明において、販売者ＩＤを用いて担当するユーザＩＤでの代行処理を行ったとき、当該代行処理を行った販売者ＩＤを記憶装置に記憶し、当該代行処理を行った販売者ＩＤを当該代行処理の対象となったユーザＩＤで閲覧することを可能とする手段を備えることを特徴とする。
第３の発明は、第１または２の発明において、ユーザＩＤと担当として関連付けられた販売者ＩＤにおいて、当該担当するユーザＩＤの特定の機能のみを代行処理可能とする代行権限情報を含むクライアントデータを記憶装置に記憶する手段と、クライアント端末から販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であり、かつ、代行権限があると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段と、を備えることを特徴とする。
第４の発明は、第１、２または３の発明において、前記サーバが、商品名情報および単価情報を含む商品管理データベースを備え、販売者ＩＤおよびユーザＩＤを用いて商品名情報および単価情報を閲覧可能とする手段を備えることを特徴とする。

第５の発明は、クライアント端末から受信したユーザＩＤと関連付けられた見積依頼情報および注文情報を含むユーザデータを記憶装置に記憶する手段と、クライアント端末から受信した販売者ＩＤと関連付けられた見積回答情報および注文回答情報を含む販売者データを記憶装置に記憶する手段と、ユーザＩＤと担当として関連付けられた販売者ＩＤの情報を含むクライアントデータを記憶装置に記憶する手段と、各ユーザＩＤおよび各販売者ＩＤに固有のページをインターネット配信する手段と、を備え、クライアント端末から販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段を備えることを特徴とする受発注サーバである。

第６の発明は、販売者およびユーザが利用するクライアント端末のそれぞれとサーバとがネットワークを介して通信可能であり、クライアント端末間でサーバを介して商品の受発注処理を行う受発注方法であって、サーバが、一のユーザＩＤによる見積依頼情報または注文情報を受信したとき、当該見積依頼情報または当該注文情報を記憶装置に記憶すると共に当該ユーザＩＤの担当として関連付けられた販売者ＩＤにより当該ユーザＩＤに係る見積依頼情報または注文情報を閲覧可能とするステップと、サーバが、一の販売者ＩＤによる特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせるステップと、を備える受発注方法である。

第７の発明は、販売者およびユーザが利用するクライアント端末のそれぞれとサーバとがネットワークを介して通信可能であり、クライアント端末間でサーバを介して商品の受発注処理を行うためのステップをサーバに実行させるためのプログラムであって、一のユーザＩＤによる見積依頼情報または注文情報を受信したとき、当該見積依頼情報または当該注文情報を記憶装置に記憶すると共に当該ユーザＩＤの担当として関連付けられた販売者ＩＤにより当該ユーザＩＤに係る見積依頼情報または注文情報を閲覧可能とするステップと、一の販売者ＩＤによる特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせるステップとをサーバに実行させるプログラム。

本発明によれば、ＩＴ化が進んでいない企業および販売店のコンサルティングを必要とする企業の利用に適した電子的受発注手段を提供することが可能となる。

本発明の実施形態例に係る受発注システムの構成図である。 実施形態例に係る受発注システムにおける見積・受発注の流れの一例を示す図である。 実施形態例に係る見積依頼確認画面のユーザ用画面のイメージ図である。 実施形態例に係る見積入力画面の担当者用画面のイメージ図である。 実施形態例に係る見積から遷移してきた注文閲覧画面の担当者用画面のイメージ図である。 ユーザＡの担当者に営業担当ａを設定した状態を示す画面のイメージ図である。 担当者ａがユーザＡの表紙ページに移動することを確認する画面のイメージ図である。 担当者ａに表示されるユーザＡの表紙ページを示す画面のイメージ図である。 実施形態例に係る注文確認画面のユーザ用画面のイメージ図である。 実施形態例に係る直接注文による注文閲覧画面の担当者用画面のイメージ図である。

以下では、本発明を実施するための形態例を説明する。
図１は、本発明の実施形態例に係る受発注システム（以下、「本システム」という）の構成図である。
本システムは、インターネット２に接続されたサーバ１と、インターネット２に接続されたユーザ端末３ａ〜３ｎと、販売店端末４とを主要な構成要素とする。また、後述するように、本システムは業務系システムおよび商品管理システムと連携を図ることも可能である。なお、本明細書では、ユーザ端末３と販売店端末４と合わせてクライアント端末と呼ぶ場合がある。

サーバ装置１は、ＣＰＵと記憶装置とを備え、記憶装置には本システムの画面をＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible Hyper Text Markup Language）等のマークアップ言語で記述されたＷｅｂページを通して配信可能とするＨＴＴＰサーバと、受発注の処理を行うアプリケーションサーバと、受発注等の管理データを格納するデータベースとが記憶されている。サーバ装置１は１台で構成してもよいし、複数台で構成してもよい。本実施形態例ではサーバ装置１をデータセンターに配置しているが、販売店にサーバ装置１を配置してもよい。

ユーザ端末３ａ〜３ｎは、通常は業務用途で利用されるノートＰＣ、デスクトップＰＣを用いるが、タブレット、携帯電話、スマートフォン、携帯用パソコン（ウルトラモバイルＰＣ、ポケットＰＣ）、ＰＤＡ（Personal Data Assistance）等の携帯端末を用いてもよく、少なくともＣＰＵ、記憶装置およびＷｅｂブラウザを有していれば足りる。各ユーザは、ユーザ端末３から、Ｗｅｂブラウザによりサーバ装置１の提供するＷｅｂページにアクセスして本システムを利用する。本システムを利用するにあたり、ユーザ端末３に特別なソフトウェアをインストールする必要は無い。

情報系端末４ａ〜４ｎは、ノートＰＣ、デスクトップＰＣ、タブレット、携帯電話、スマートフォン、携帯用パソコン、ＰＤＡ等の端末であり、少なくともＣＰＵ、記憶装置およびＷｅｂブラウザを有している。但し、フェイス・ツー・フェイス営業を行うためには、情報系端末４ａ〜４ｎに、ノートＰＣ、タブレット、スマートフォン、携帯用パソコン等の画面が比較的大きい携帯端末が含まれることが好ましい。販売店の各担当者は、情報系端末４から、Ｗｅｂブラウザによりサーバ装置１の提供するＷｅｂページにアクセスして本システムを利用する。本システムを利用するにあたり、情報系端末４ａ〜４ｎに特別なソフトウェアをインストールする必要は無い。情報系端末４ａ〜４ｎは、サーバ装置１から受発注等の取引データ５１をｃｓｖ等のファイル形式でダウンロードし、業務系システムと連携することも可能である。このデータ連携は、ｃｓｖファイル等をネットワークまたは記憶媒体を介して業務系端末５に取り込むことにより行うが、予め定められたスケジュールで実行されるバッチプログラムにより自動連携を図ることがより好ましい。

また、好ましい形態の本実施形態例は、卸売会社、製造会社などが管理する商品管理システム６から商品データを取り込み、ユーザ端末３および情報系端末４に商品データリストを表示することが可能である。数十万点もある商品リストを統一した体系で取り込むための労力を要するが、商品管理システム６との連携が可能となれば、重く分厚いカタログを営業担当者が客先に持参することが不要となる。好ましくは予め定められたスケジュールで実行されるバッチプログラムにより、商品管理システム６との自動連携を図り、常に最新の商品リストが表示されるようにする。なお、商品管理システム６とのデータ連携はインターネット２経由で行う必要は無く、専用通信回線などのネットワーク手段により連携してもよい。
さらに、サーバ装置１に、販売店の手数料と商品リストとを関連付けた商品管理データベースを記憶装置に格納することにより、自動見積を可能とすることがより好ましい。

図２は、実施形態例に係る受発注システムにおける見積・受発注の流れの一例を示す図である。以下では、本システムを利用するユーザをユーザＡ、ユーザＡを担当する担当者を担当者ａと呼ぶ場合がある。

ＳＴＥＰ１：ユーザＡが、ユーザ端末３を用いてサーバ装置１の提供するＷｅｂページにアクセスしログインする。そして、表紙ページ（初期ページ）に表示された見積アイコンをクリックすることにより見積トップページに遷移する。見積トップページ内の新規作成ボタンをクリックすることにより、見積入力画面に遷移する。見積入力画面において、ユーザＡは見積対象商品情報（例えば、メーカー名、商品名、型式、数量）を入力する。見積対象商品情報の入力が完了すると、確認ボタンをクリックすることにより見積依頼確認画面（図３参照）に遷移する。見積依頼確認画面において、ユーザＡが表示された見積対象商品情報を確認した後、送信ボタンをクリックすることで見積依頼情報がサーバ装置１に送信される。なお、ユーザＡは、見積閲覧画面において、いつでも取引経過を確認することが可能である。見積閲覧画面は、処理が進むごとに最新の情報が表示される。

ＳＴＥＰ２：サーバ装置１がユーザ端末３から見積依頼情報を受信すると、記憶装置に格納されたデータベースを更新する。これにより、ユーザＡを担当する担当者ａの表紙ページに見積依頼があったことを知らせる表示がなされるようになり、見積依頼閲覧画面へのアクセスが可能となる。この際、サーバ装置１から担当者ａにメール配信を行う設定とすることも可能である。

ＳＴＥＰ３：情報系端末４を用いて担当者ａが表紙ページにアクセスすると、回答および確認の必要のある取引の一覧が表示される。この一覧から任意の見積依頼を選択しクリックすることにより当該選択した見積依頼閲覧画面に遷移する。さらに担当者ａが見積手続ボタンをクリックすることで、見積回答画面（図４参照）に遷移する。見積回答画面において、担当者ａは見積回答情報（例えば、単価、備考、送料、出精値引、消費税有無、更に回答者側の備忘としての仕入先、仕切り）を入力する。見積回答情報の入力が完了すると、確認ボタンをクリックすることにより見積回答確認画面に遷移する。見積回答確認画面において、担当者ａが表示された見積回答情報を確認した後、送信ボタンをクリックすることで見積回答情報がサーバ装置１に送信される。なお、担当者ａは、見積閲覧画面において、いつでも取引経過を確認し、必要に応じて見積を修正することが可能である。

ＳＴＥＰ４：サーバ装置１が情報系端末４から見積回答情報を受信すると、記憶装置に格納されたデータベースを更新する。これにより、ユーザＡの表紙ページに見積回答があったことを知らせる表示がなされるようになり、見積回答閲覧画面へのアクセスが可能となる。この際、サーバ装置１からユーザＡにメール配信を行う設定とすることも可能である。

ＳＴＥＰ５：ユーザ端末３を用いてユーザＡが表紙ページにアクセスすると、回答および確認の必要のある取引の一覧が表示される。この一覧から任意の見積回答を選択しクリックすることにより当該選択した見積回答閲覧画面に遷移する。ここでユーザＡが、注文手続ボタンをクリックすると、注文確認画面に遷移する。注文確認画面において、ユーザＡが表示された注文内容を確認した後、送信ボタンをクリックすることで注文情報がサーバ装置１に送信される。ここでユーザＡが、見積回答に納得いかない場合、担当者ａにその旨を伝えることにより、修正された見積が見積回答閲覧画面に表示される。ユーザがその内容に納得して注文手続きボタンをクリックすることにより注文情報がサーバ装置１に送信される。ユーザが納得できない場合は、担当者ａが設定した見積有効期限を持って、その見積回答は一覧から削除される。なお、修正は何度でも可能である。また、修正を行うごとに作業日と作業者は、見積閲覧画面に表示される。

ＳＴＥＰ６：サーバ装置１がユーザ端末３から注文情報を受信すると、記憶装置に格納されたデータベースを更新する。これにより、担当者ａの表紙ページに注文があったことを知らせる表示がなされるようになり、注文閲覧画面へのアクセスが可能となる。この際、サーバ装置１から担当者ａにメール配信を行う設定とすることも可能である。

ＳＴＥＰ７：情報系端末４を用いて担当者ａが表紙ページにアクセスすると、回答および確認の必要のある取引の一覧が表示される。この一覧から任意の注文を選択しクリックすることにより当該選択した注文閲覧画面（図５参照）に遷移する。注文閲覧画面において、担当者ａは、依頼先、納期、見積金額などの当該取引関連情報を確認することが可能である。また、下段の取引経過には、本取引における見積依頼、修正、見積回答、注文などの経過情報が表示される。さらに担当者ａが注文確認送信ボタンをクリックすることで注文確認情報がサーバ装置１に送信される。

ＳＴＥＰ８：サーバ装置１がユーザ端末３から注文確認情報を受信すると、記憶装置に格納されたデータベースを更新する。これにより、ユーザＡの表紙ページに注文回答があったことを知らせる表示がなされるようになり、注文回答確認画面へのアクセスが可能となる。この際、サーバ装置１からユーザＡにメール配信を行う設定とすることも可能である。

以上の手続を経ることにより、見積から注文に至る手続が完了する。また、ユーザは、見積を経由せず直接注文する場合がある。

ＳＴＥＰ５−１：ユーザＡは表紙ページに表示された注文アイコンをクリックすることにより注文トップページに遷移する。注文トップページ内の新規作成ボタンをクリックすることにより、注文入力画面に遷移する。注文入力画面において、ユーザＡは注文対象商品情報（例えば、メーカー名、商品名、型式、数量）を入力する。注文対象商品情報の入力が完了すると、確認ボタンをクリックすることにより注文依頼確認画面（図９参照）に遷移する。注文依頼確認画面において、ユーザＡが表示された注文対象商品情報を確認した後、送信ボタンをクリックすることで注文依頼情報がサーバ装置１に送信される。なお、ユーザＡは、注文閲覧画面において、いつでも取引経過を確認することが可能である。

ＳＴＥＰ６−１：サーバ装置１がユーザ端末３から注文情報を受信すると、記憶装置に格納されたデータベースを更新する。これにより、担当者ａの表紙ページに注文があったことを知らせる表示がなされるようになり、注文閲覧画面へのアクセスが可能となる。この際、サーバ装置１から担当者ａにメール配信を行う設定とすることも可能である。

ＳＴＥＰ７−１：情報系端末４を用いて担当者ａが表紙ページにアクセスすると、回答および確認の必要のある取引の一覧が表示される。この一覧から任意の注文を選択しクリックすることにより当該選択した注文閲覧画面（図１０参照）に遷移する。注文閲覧画面において、担当者ａは、依頼先、納期、注文対象商品情報などの当該取引関連情報を確認することが可能である。但し、この段階において、価格情報の表示はない。価格情報を入力する場合は、下段にある価格入力ボタンをクリックし、価格情報を入力する。価格情報の入力が完了すると、確認ボタンをクリックすることにより価格確認画面に遷移する。価格確認画面において、担当者ａが表示された価格情報を確認した後、送信ボタンをクリックすることで注文回答情報がサーバ装置１に送信される。なお、価格が別途契約により確定している場合または、取り急ぎ注文確認をする場合は、注文確認送信ボタンをクリックすることで、価格が入力されていない注文確認情報がサーバ装置１に送信される。
なお、担当者ａは、注文閲覧画面において、いつでも取引経過を確認し、必要に応じて価格を入力して再送信することが可能である。また、注文確認送信ボタンをクリックする代わりに価格入力ボタンをクリックして価格が入力された注文確認情報をサーバ装置１に送信することも可能である。
以下ＳＴＥＰ８の手順を経ることにより、見積を経由しない直接注文にいたる手続きが完了する。

なお、本システムの管理者（販売店管理者）は、すべてのユーザに対して担当者ａと同様の入力、閲覧および修正を行うことができる。更に一覧からの削除を行うことができる。

以上が通常の受発注手続の流れであるが、本システムでは、見積依頼（ＳＴＥＰ１）、注文（ＳＴＥＰ３）などの本来はユーザが行うべき作業を、担当者が行うことが可能であるという希有な特徴を有するので、この点について説明する。
まず本システムの管理者（販売店管理者）は、各ユーザに対応するＩＤ・パスワードと、販売店の各担当者に対応するＩＤ・パスワードとを発行する。続いて、各ユーザを担当する一人または複数人の担当者を設定する。ここで、担当者は、営業担当者に限定するものではなく内勤の業務担当者も設定できる。例えば、ユーザＡの担当として営業担当ａを設定し、ユーザＢの担当として営業担当ｂ、業務担当ｃを設定する。図６は、ユーザＡの担当者に営業担当ａを設定した状態を示す画面のイメージ図である。この設定作業により、担当者は自身が担当するユーザと同じ作業を行うことが可能となる。これにより、営業担当者が客先での打ち合わせ中に入力した見積内容を、業務担当者が回答することにより、その回答に基づき商談を進めることができる。また、その場で見積修正も可能なため、発注効率の向上が可能となる。また、ユーザからの電話注文を業務担当者が入力することにより、注文ミスの防止に繋がる。より詳細には、担当者は、担当する顧客名一覧から任意の顧客名を選択しクリックすることにより当該選択したユーザの表紙ページに画面遷移し、代行処理をすることが可能となる。

図７は、担当者ａがユーザＡの表紙ページに移動することを確認する画面のイメージ図である。この画面において、「移動する」ボタンをクリックすることにより、担当者ａは自身が利用する情報系端末４からユーザＡの表紙ページに移動することができる。図８は、担当者ａに表示されるユーザＡの表紙ページを示す画面のイメージ図である。二段目に「○○株式会社（販売店名） 担当者ａ（担当者名）」の表記がなされ、三段目に「ユーザＡ（ユーザ企業名）、○○（ユーザ窓口担当者名）」の表記がなされ、新規情報欄にはユーザＡが現在、回答並びに確認を必要としている見積と注文の一覧が表示されている。ここで、ユーザＡの表紙ページを、Ｗｅｂブラウザに分割表示されたフレーム内に表示させたり、別ウィンドウまたは別タブで表示させたりするようにしてもよい。なお、現在やり取りしている見積と注文すべての一覧は、それぞれのアイコンをクリックしたトップページに表示されている。

ユーザＡの表紙ページに移動した担当者ａは、ユーザＡに代行して見積依頼、注文などの機能を利用することができる。なお、取引経過の欄に見積依頼、見積回答等の処理を行った作業日および作業者名が表示されるため（図５参照）、担当者ａがユーザＡに代行して見積依頼、注文などの処理を行った場合、取引経過の作業者欄に「販売店名 担当者ａ」と表示される。
また、担当者が、担当ユーザの表紙ページに画面遷移できなくする設定、担当ユーザの特定の機能のみを代行可能とする設定（例えば見積機能のみ代行可能とする設定）、更に担当者からの注文に対しては、ユーザの承認を必要とする設定を行うことも可能である。

ここで、担当者がユーザに成り代わり、見積、注文等の作業を行うことは、セキュリティの観点から避けるべきであるとの批判が想定される。しかしながら、ＩＴスキルが低い、またはシステム利用に懐疑的なユーザに、受発注システムの操作を覚えてもらうことは困難であることが現場では多々ある。そのような場合、ユーザからＩＤ・パスワードを聞き、ユーザに代わってログインをして見積、注文等の作業を行うという運用がなされるのが実情である。また、このようなＩＴスキルの低いユーザにおいては、ＩＤ・パスワードが付せんで画面などの人目につく場所に貼られている場合もあり、セキュリティ確保の理念を追求することがかえってセキュリティを低下させることになりかねない。そこで、本システムでは、ユーザのＩＴスキルが低いなどの事情がある場合には、見積、注文等の作業のアウトソースを可能とすべく、担当のユーザの表紙ページに画面遷移することを可能とするいわば折衷案を採用した。

近年のタブレット端末の普及により、現場にタブレットを持参し、ユーザにタブレット画面を示しながら説明する場面が増えている。ユーザ立ち会いのもと、営業担当者がコンサルティングを行いながら、見積、注文等の作業を代行するのであれば実質的な問題は生じない。また、従来から電話で注文を受け、担当者が見積等の作業を行っている実情にも合致するものと考えられる。すなわち、本システムは、フェイス・ツー・フェイスの信頼関係を基底とした地域密着型の営業を実現するために最適なツールである。
そして、ＩＴスキルの高いユーザにおいては、担当者が担当ユーザの表紙ページに画面遷移できなくする設定、担当ユーザの特定の機能のみを代行可能とする設定、更に担当者からの注文に対しては、ユーザの承認を必要とする設定を行うことの対処もできるので、ユーザの成長にあわせてシステムのセキュリティを高めることも可能である。

以上、本開示にて幾つかの実施形態を単に例示として詳細に説明したが、本発明の新規な教示及び有利な効果から実質的に逸脱しない範囲の改変例も本発明には含まれる。

１ サーバ装置
２ インターネット
３ ユーザ端末
４ 情報系端末
５ 業務系端末
６ 商品管理システム
５１ 連携データ

Claims (7)

1. 販売者およびユーザが利用するクライアント端末のそれぞれとサーバとがネットワークを介して通信可能であり、
   前記サーバが、クライアント端末から受信したユーザＩＤと関連付けられた見積依頼情報および注文情報を含むユーザデータを記憶装置に記憶する手段と、
   クライアント端末から受信した販売者ＩＤと関連付けられた見積回答情報および注文回答情報を含む販売者データを記憶装置に記憶する手段と、
   ユーザＩＤと担当として関連付けられた販売者ＩＤの情報を含むクライアントデータを記憶装置に記憶する手段と、
   各ユーザＩＤおよび各販売者ＩＤに固有のページをインターネット配信する手段と、
   クライアント端末から販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段と、を備えることを特徴とする受発注システム。
2. 販売者ＩＤを用いて担当するユーザＩＤでの代行処理を行ったとき、当該代行処理を行った販売者ＩＤを記憶装置に記憶し、当該代行処理を行った販売者ＩＤを当該代行処理の対象となったユーザＩＤで閲覧することを可能とする手段を備えることを特徴とする請求項１の受発注システム。
3. ユーザＩＤと担当として関連付けられた販売者ＩＤにおいて、当該担当するユーザＩＤの特定の機能のみを代行処理可能とする代行権限情報を含むクライアントデータを記憶装置に記憶する手段と、
   クライアント端末から販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であり、かつ、代行権限があると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段と、を備えることを特徴とする請求項１または２の受発注システム。
4. 前記サーバが、商品名情報および単価情報を含む商品管理データベースを備え、販売者ＩＤおよびユーザＩＤを用いて商品名情報および単価情報を閲覧可能とする手段を備えることを特徴とする請求項１、２または３の受発注システム。
5. クライアント端末から受信したユーザＩＤと関連付けられた見積依頼情報および注文情報を含むユーザデータを記憶装置に記憶する手段と、
   クライアント端末から受信した販売者ＩＤと関連付けられた見積回答情報および注文回答情報を含む販売者データを記憶装置に記憶する手段と、
   ユーザＩＤと担当として関連付けられた販売者ＩＤの情報を含むクライアントデータを記憶装置に記憶する手段と、
   各ユーザＩＤおよび各販売者ＩＤに固有のページをインターネット配信する手段と、を備え、
   クライアント端末から販売者ＩＤを用いて特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせる手段を備えることを特徴とする受発注サーバ。
6. 販売者およびユーザが利用するクライアント端末のそれぞれとサーバとがネットワークを介して通信可能であり、クライアント端末間でサーバを介して商品の受発注処理を行う受発注方法であって、
   サーバが、一のユーザＩＤによる見積依頼情報または注文情報を受信したとき、当該見積依頼情報または当該注文情報を記憶装置に記憶すると共に当該ユーザＩＤの担当として関連付けられた販売者ＩＤにより当該ユーザＩＤに係る見積依頼情報または注文情報を閲覧可能とするステップと、
   サーバが、一の販売者ＩＤによる特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせるステップと、を備える受発注方法。
7. 販売者およびユーザが利用するクライアント端末のそれぞれとサーバとがネットワークを介して通信可能であり、クライアント端末間でサーバを介して商品の受発注処理を行うためのステップをサーバに実行させるためのプログラムであって、
   一のユーザＩＤによる見積依頼情報または注文情報を受信したとき、当該見積依頼情報または当該注文情報を記憶装置に記憶すると共に当該ユーザＩＤの担当として関連付けられた販売者ＩＤにより当該ユーザＩＤに係る見積依頼情報または注文情報を閲覧可能とするステップと、
   一の販売者ＩＤによる特定のユーザＩＤについての代行処理要求情報を受信したとき、当該販売者ＩＤが当該特定のユーザＩＤの担当であると判定した場合には当該特定のユーザＩＤでの代行処理を当該販売者ＩＤに可能とさせるステップとをサーバに実行させる、プログラム。