JP2002245309A - 受注システム及び受注処理方法並びにサーバ及びインターネットショッピングシステム - Google Patents

Abstract

(57)【要約】 【課題】 在庫管理システムと連携して顧客からの受注
処理，納期回答などを行う受注システムにおいて、在庫
管理システムが非稼働時でも処理を行えること 【解決手段】 ネットワーク２に接続可能なサーバ１
が、在庫管理システム３と接続している。サーバは、ネ
ットワークを介して顧客端末４からの注文を受け付けた
際に、在庫管理システムに対してその商品の納期の問い
合わせをするとともに、在庫管理システムからの納期の
回答に基づき顧客端末に向けて納期を通知する。顧客端
末からの正式な発注を受け付け、データベースに記憶す
ることを基本とする。さらに、商品についての標準納期
を記憶した商品データベース１１ａを持ち、在庫管理シ
ステムの非稼働時に受けた顧客端末からの納期問い合わ
せに対しては、商品データベースから対応する商品の標
準納期を取得し、その標準納期を顧客端末に対して回答
するようにした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、受注システム及
び受注処理方法並びにサーバ及びインターネットショッ
ピングシステムに関するものである。

【０００２】

【発明の背景】商品の受注形態の一つとして、インター
ネットを利用したものがある。これは、受発注サーバの
ウェブサイトに対し、顧客がインターネット経由でアク
セスし、注文画面にて必要な商品を選択するとともに、
個数を入力することにより、顧客が発注を行う。受発注
サーバは、この顧客からの発注（システムにとっては受
注）に伴い、メーカ等に対して自動発注を行う。

【０００３】さらに、自動発注する際に、メーカ等の在
庫管理システムに直接行うものがある。すると、在庫管
理システムは、注文を受けた商品の在庫情報がわかって
いるので、何時納品できるかなどの納期情報を受発注サ
ーバに対して自動的に行うことができる。従って、顧客
からの注文を受けた受発注サーバは、在庫管理システム
からの納期情報に基づき、顧客に納期回答をすることが
できる。そして、当然のことながら、上記した受発注サ
ーバと在庫管理システムは、ともにコンピュータその他
の装置で構成されているため、データの送受は自動的か
つリアルタイムで行うことができる。

【０００４】上記したシステム構成によれば、顧客は、
インターネットを経由して受発注サーバにアクセスし、
そこにおいて商品の注文（仮の問い合わせ）をすると、
上記した情報の送受により、瞬時にその商品の納期を知
ることができる。よって、その納期でよいか否かの判断
をして、正式な発注をするような運営ができるので、顧
客にとっては安心して商品の納品を待つことができ、商
品の販売側では受発注処理から顧客への納期の回答も自
動的に行えるという利点がある。

【０００５】ところで、上記したシステムを稼働させる
ためには、受発注サーバと在庫管理システムがともに稼
働し、通信可能な状態になっている必要がある。しかし
ながら、在庫管理システムは、セキュリティその他の要
因から通常その会社の営業時間中は稼働しているもの
の、夜間などは停止している。

【０００６】従って、仮に受発注サーバを２４時間稼働
させたとしても、在庫管理システム側が停止している夜
間などでは、上記したリアルタイムでの納期回答や自動
発注処理ができない。すると、使用者側（この場合には
特に顧客）の都合に併せて２４時間いつでも利用できる
というインターネットのメリットが十分に生かすことが
できない。

【０００７】さらに、上記した両システムを共に２４時
間稼働させることにより、２４時間体制で休みなく受注
や納期回答などを行うことができる。しかし、実際に
は、受発注サーバを運営する会社（商社等の顧客の注文
を受ける会社）と、在庫管理システムを稼働させる会社
（メーカ等の工場その他の商品を生産している会社等）
とが別会社の場合には、一方の都合で他方にシステムを
２４時間稼働させることを要求するのは困難である。

【０００８】この発明は、在庫管理システムと連携して
顧客からの受注処理並びに納期回答などを行うシステム
において、在庫管理システムが非稼働時であっても各種
処理を行うことができ、究極には、２４時間体制でサー
ビスの提供を行うことのできる受注システム及び受注処
理方法並びにサーバ及びインターネットショッピングシ
ステムを提供することを目的とする。

【０００９】

【課題を解決するための手段】この発明は、ネットワー
クに接続可能なサーバと、そのサーバと通信で接続可能
な在庫管理システムとを備え、前記ネットワークを介し
ての顧客端末から受注を受けるオンラインによる受注シ
ステム或いはさらに顧客端末まで組み込んだオンライン
による受信システムを前提としている。顧客は、顧客端
末をネットワークに接続することにより、そのネットワ
ークを介してサーバにアクセスし、商品の注文等をする
ことができる。

【００１０】そして、この発明による受注処理方法は、
上記の受注システムにおける受注処理方法であり、以下
の処理を実行するようにしている。すなわち、前記サー
バは、商品についての標準納期を記憶した標準納期デー
タベースを持つ。前記サーバは、前記ネットワークを介
して顧客端末からの注文を受け付けた際に、その注文を
受けた商品を管理する前記在庫管理システムに対してそ
の商品の納期の問い合わせを実行し、前記納期の問い合
わせを受けた前記在庫管理システムは、在庫データベー
スをアクセスして取得したその商品についての納期情報
（出荷予定日）を前記サーバに送る。前記サーバは受け
取った納期情報に基づいて、前記顧客端末に向けて納期
を通知する。一方、前記在庫管理システムの非稼働時に
受けた前記顧客端末からの納期問い合わせに対しては、
前記標準納期データベースから対応する商品の標準納期
を取得し、その標準納期を前記顧客端末に対して通知す
る。そして、前記サーバは前記顧客端末からの正式な発
注を受け付けた場合、所定の処理をするようにした。

【００１１】ここで、「所定の処理」とは、例えば、在
庫管理システムが非稼働時に行われる滞留時の処理があ
る。つまり、実施の形態でいうと、ステップ２４〜２７
の処理に対応する。また、在庫管理システムに対して正
式な発注処理を行うこともある。さらに、発注に伴う情
報を注文データベースに記憶する処理などの他、各種の
ものがある。

【００１２】ネットワークは、実施の形態では、インタ
ーネットであるが、他のネットワークでももちろん良
い。サーバは、実施の形態では「受発注サーバ１」に対
応し、標準納期データベースは、実施の形態では商品デ
ータベース１１ａに対応する。このように、実施の形態
では、通常の商品に関する情報を記憶するデータベース
と一体にしているが、標準納期を別途管理するデータベ
ースを構築しても良い。納期情報は、実施の形態では出
荷予定日であったり、出荷予定日不明であったりする。

【００１３】また、係る方法を実施するのに適した受注
システムとしては、ネットワークに接続可能なサーバ
と、そのサーバと通信で接続可能な在庫管理システムと
を備え、前記サーバは、前記ネットワークを介して顧客
端末からの注文を受け付けた際に、その注文を受けた商
品を管理する前記在庫管理システムに対してその商品の
納期の問い合わせをするとともに、前記在庫管理システ
ムからの納期の回答に基づき前記顧客端末に向けて納期
を通知する機能と、前記顧客端末からの正式な発注を受
け付け、データベースに記憶する機能を備える。さら
に、前記サーバは、商品についての標準納期を記憶した
商品データベースを持ち、前記在庫管理システムの非稼
働時に受けた前記顧客端末からの納期問い合わせに対し
ては、前記商品データベースから対応する商品の標準納
期を取得し、その標準納期を前記顧客端末に対して回答
する機能を備えるようにした。

【００１４】上記の「問い合わせを行う機能」，「通知
する機能」，「記憶する機能」は、実施の形態では、受
発注処理部１０ｂにより実現されている。また、「回答
する機能」は、実施の形態では、貯留データ処理部１０
ｃにより実現されている。

【００１５】さらに、上記システムを構築したり、受注
処理方法を実施するために適したサーバとしては、ネッ
トワークを介して顧客端末から商品の注文を受け付ける
ためのサーバであって、前記商品を管理する在庫管理シ
ステムと通信で接続可能となり、受け付けた正式な注文
に関する情報を記憶する注文データベースと、商品につ
いての標準納期を記憶した標準納期データベースと、前
記顧客端末からの注文に基づき、前記在庫管理システム
に対して、商品の納期の問い合わせを行う機能と、前記
在庫管理システムからの納期回答に基づき前記顧客端末
に向けて納期を通知する機能と、前記顧客端末からの正
式な注文を受け付けた場合に、その発注に伴う情報を前
記注文データベースに記憶する機能と、前記在庫管理シ
ステムが非稼働中であると判断する機能と、前記在庫管
理システムの非稼働時に受けた前記顧客端末からの納期
問い合わせに対し、前記商品データベースにアクセスし
て対応する商品の標準納期を取得し、その標準納期を前
記顧客端末に対して回答する機能を備えることである。

【００１６】この発明によれば、在庫管理システムが稼
働中は、在庫管理システムに問い合わせることにより、
注文を受ける商品の正確な納期を知ることができ、顧客
に通知することができる。また、在庫管理システムが非
稼働中の場合には、標準納期データベースに格納した標
準納期に基づいて顧客に対しての右記回答をすることが
できる。よって、顧客は、係る納期を見て、必要な商品
が間に合うか否かを判断し、正式な注文をすることがで
きる。

【００１７】よって、サーバが稼働していれば、在庫管
理システムが稼働しているか否かに関わらず納期を回答
でき、それに伴う注文を受けることができる。つまり、
本システムを利用する顧客は、標準納期がわからずに仮
注文をし、翌日に納期を確認した場合に間に合わないこ
とがわかり、あわてて注文のキャンセル並びに別の注文
先を探すというような事態を招くということを可及的に
抑制できる。販売店側も、係る事態に伴うキャンセルの
発生率を抑制できる。

【００１８】また、非稼働中であると判断する機能とし
ては、実施の形態では「稼働フラグのＯＮ／ＯＦＦ」を
チェックするようにしたが、これに限ることはなく、予
め記憶保持した稼働時間（非稼働時間）の情報に基づい
て判断したり、まず在庫管理システムに対して問い合わ
せを行い、一定時間以内に回答がない場合には、非稼働
中と推定し標準納期を通知するようにすることもでき
る。

【００１９】そして、在庫管理システムから、少なくと
も稼働開始時と、終了時に前記サーバに通知し、前記サ
ーバは前記通知に基づいて前記在庫管理システムが現在
非稼働時か否かを判断し、その判断結果に基づいて納期
の通知方法を決定するようにするとよい。ここで、通知
方法の決定とは、在庫管理システムに対して納期の問い
合わせをして得られた結果を通知する方法と、標準納期
を通知する方法のいずれをとるかである。

【００２０】この発明によれば、稼働中か否かが確実に
わかるので好ましい。なお、稼働開始時とは、開始した
その時点（直後）でもよいし、一定時間経過した後でも
良い。同様に、終了時とは、その終了した時点（直前）
でもよいし、終了時刻の一定時間前でもよい。つまり
「時」としているが、その時点という意味ではなく、稼
働開始／終了という条件を満たしたときという意味であ
る。

【００２１】また、終了時刻よりも少し前に終了通知を
送ることにより、タイミングのずれでサーバから問い合
わせが送られてきたりすることが抑制できる。また、後
述するように、正式な発注が継続して送られてくるよう
な場合に、納期問い合わせの時には在庫管理システムは
稼働していたものの、最終的な正式な発注の時には在庫
管理システムが停止する事態の発生も未然に防止でき
る。

【００２２】なお、前記注文データベースへ登録する情
報は、前記在庫管理システムに対して行った正式発注を
受けて、前記在庫管理システムから返答されてきた発注
結果を含むようにしてもよい。

【００２３】一方、前記サーバは、前記顧客端末からの
正式な注文を受けた際に、前記在庫管理システムに対し
て正式発注をし、前記在庫管理システムは、その正式発
注を受けたならば、前記在庫データベースにアクセスし
て正式発注を受けた商品についての在庫引当処理を行う
ようにすることができる。

【００２４】このようにすると、顧客からの商品の正式
な注文に基づき、仕入れ先への自動的な発注処理ひいて
は仕入れ先側での在庫管理（引当）がオンラインで人手
を介することなく行うことができる。

【００２５】さらに、前記サーバは、前記在庫管理シス
テムが非稼働時に前記顧客端末からの正式な注文を受け
た際にその受けた内容を一時記憶手段に格納し、次い
で、前記在庫管理システムが稼働した際に、前記一時記
憶手段に格納したデータに基づいて前記在庫管理システ
ムに対して正式発注をし、前記在庫管理システムは、そ
の正式発注を受けたならば、前記在庫データベースにア
クセスして正式発注を受けた商品についての在庫引当処
理を行うようにするとよい。

【００２６】係る処理を実施するのに適したサーバとし
ては、前記顧客端末が非稼働時に前記顧客端末からの正
式な注文を受けた際にその受けた内容を一時記憶手段に
格納するとともに、前記在庫管理システムが稼働した際
に、前記一時記憶手段に格納したデータに基づいて前記
在庫管理システムに対して正式発注をする処理手段を備
えることである。ここで、処理手段は、実施の形態では
貯留データ処理部１０ｃに対応する。また、一時記憶手
段は、実施の形態では「貯留データベース１１ｄ」に対
応する。

【００２７】これにより、在庫管理システムが非稼働中
にサーバが受け取った正式な注文を在庫管理システムに
対して正式発注することができ、遅滞なく顧客に対して
発送される。

【００２８】さらに、在庫管理システムは１つの場合も
あるし、複数の場合もある。そして、複数存在する場合
は、前記サーバは、注文を受けた商品に基づき、その商
品に関連する在庫管理システムを決定し、その決定した
在庫管理システムとの間でデータの送受を行うことによ
り対応できる。

【００２９】なお、前記注文データベースへ登録する情
報は、前記在庫管理システムに対して行った正式発注を
受けて、前記在庫管理システムから返答されてきた発注
結果を含むものである。

【００３０】本発明に係るインターネットショッピング
システムでは、顧客が入力した商品情報要求を送信し、
返信された商品情報を表示し、発注情報を送信する顧客
端末と、前記商品情報要求に基づいて、納期情報を含む
商品情報を前記顧客端末に返信し、前記発注に基づい
て、在庫引き当てのトリガを出すサーバシステムと、前
記サーバシステムと連動し、前記サーバシステムからの
納期問い合わせに応じてその都度納期を判断してその結
果を前記納期情報として前記サーバシステムに返信し、
前記トリガに応じて在庫引き当て処理をして注文データ
ベースに記録することを行う在庫管理システムとからな
り、前記サーバシステムは、前記在庫管理システムが非
稼働と判断した際に、予めデータベースに記憶した標準
納期情報を前記納期情報として前記顧客端末に返信する
とともに、前記在庫管理システムが稼働するまで前記在
庫引き当てトリガを滞留するようにした。＊用語の定義
「納期」は、在庫管理システムにて在庫引き当てがで
き、確実に商品を届けることのできる時期をいう。シス
テム上は、発送日，出荷日，顧客到着日，物流開始日な
どから選ぶことになる。つまり、必ずしも最終的に顧客
に到着する時ではない。「標準納期」は、システム上の
想定納期であり、予め予想している設定納期（仮の納
期）である。在庫等があった場合など、通常であれば商
品を届けることができる時期に基づいて設定される。

【００３１】「注文（を受ける）」とは、「受注」とし
ての意味である。システム上ではサーバが受信するもの
で、顧客端末の操作結果により行われる。「正式発注」
は、納期（標準納期）を確認した顧客が、顧客端末から
サーバに対して行われる正式な注文（商品購入の意思表
示）の場合と、その顧客端末からの正式発注を受けたサ
ーバが在庫管理システムに対して行う発注（在庫引き当
て依頼等）がある。

【００３２】「サーバ」は、Ｗｅｂサーバ機能を持つコ
ンピュータ装置により実現される。また、「顧客端末」
は、Ｗｅｂブラウザ機能を持つコンピュータ端末により
実現される。

【００３３】「在庫管理システムの非稼働」は、在庫管
理システムが実際に動作しているか否かにかかわらず、
サーバからアクセスができない状態を言う。つまり、定
期的、非定期的を問わず、電源を落としている場合はも
ちろんのこと、メンテナンス中で外部と遮断されている
場合も含む。在庫管理システム側で停電、故障等が発生
している場合もある。さらには、システムが稼働中であ
っても、サーバ−在庫管理システム間のネットワーク異
常などにより、通信ができない場合等も含む。もちろ
ん、上記したものは、例示列挙であり、それ以外の場合
も該当するものはある。

【００３４】一方、運営上、上記した総ての場合に非稼
働中の処理（標準納期回答等）をする必要はない。つま
り、例えばネットワーク異常等の一部の状況において
は、所定のエラー処理を実行することもできる。エラー
処理としては、複数回通信を試みたり、最終的につなが
らない場合には、エラーメッセージを出力することもあ
る。但し、その場合でも、標準納期を併せて出力するの
が好ましい。

【００３５】

【発明の実施の形態】図１は、本発明が適用されるシス
テムの一形態を示している。同図に示すよう、受発注サ
ーバ１は、インターネット２に接続され、情報の送受が
できるようになっているとともに、仕入れ先の在庫管理
システム３と接続されている。そして、インターネット
に接続された顧客端末４から受発注サーバ１にアクセス
することにより、受発注サーバ１は受注処理並びにそれ
に付随する各処理を実施するようになっている。よっ
て、本システムは、一種のインターネットショッピング
を実現するものとも言える。

【００３６】そして、受発注サーバ１は、商品の販売店
に設置されるものであり、その販売店は、顧客からの注
文を受けて、仕入れ先から商品を入手し、顧客に販売す
るものである。在庫管理システム３は、仕入れ先に実装
されるシステムであり、その仕入れ先が持つ在庫状況を
管理するシステムである。つまり、各商品についての現
在の在庫数はもちろんのこと、たとえ現在在庫数が０で
あっても、工場の生産予定などから何時出荷可能になる
かなどが管理される。

【００３７】次に、上記したシステムを用いて行われる
顧客端末４からの発注から、最終的に顧客に対して商品
を配送するまでの処理の流れに従って、各システムの機
能の概略を説明する。まず、顧客端末４は、インターネ
ット経由で販売店のウェブサイトにアクセスし、受発注
サーバ１に接続する。受発注サーバ１の制御部１０は、
会員データベース１１ｂを参照し、アクセスしてきた顧
客が正規の会員か否かを判断（ＩＤ＋パスワード等）
し、正規の会員でない場合には、まず会員登録を促す。
そして、正規の会員であることが確認できると、実際の
サービスの提供を開始する。

【００３８】すなわち、まず、購入しようとする商品を
選択させる。つまり、顧客端末４からの情報（検索条
件，過去の購入履歴情報等）に基づき、商品データベー
ス１１ａをサーチし、顧客が購入しようとする商品リス
トを作成し、出力表示する。そして、表示した商品リス
トの中から顧客が購入しようとする商品が選択されるの
を待つ。もちろん、要求に応じて別の商品リストを提示
することもある。

【００３９】商品及び個数が選択されると、制御部１０
は在庫管理システム３に対して納期の問い合わせを行
う。この問い合わせを受けた在庫管理システム３の制御
部２０は、在庫データベース２１ａをアクセスし、問い
合わせのあった商品の有無及び在庫数を確認し、その商
品について必要な個数を発送できる納期を回答する。な
お、納期は出荷日を基準としている。

【００４０】受発注サーバ１側の制御部１０は、在庫管
理システム３からの納期回答を受けて、顧客端末４の表
示画面中の各商品の欄に出荷予定日を出力表示すること
により、顧客への納期回答をする。

【００４１】顧客は、出荷予定日を確認し、問題がなけ
れば正式な注文（発注）を行う。この発注もインターネ
ット２を経由して受発注サーバ１の制御部１０に与えら
れるので、制御部１０は、在庫管理システム３に対して
正式な発注を送る。さらに、受発注サーバ１並びに在庫
管理システム３は、各発注を受けてそれぞれの注文デー
タベース１１ｃ，２１ｂに注文を受けた商品，個数，相
手先，出荷予定日などの情報を格納する。さらに、在庫
管理システム３は、在庫データベース２１ａに対して引
当処理を行う。つまり、注文を受けた商品の個数分だけ
在庫数を減らす処理をする。

【００４２】そして、本形態では、短期納入を行うた
め、仕入れ先から顧客に対して直送する方式をとってい
る。そこで、仕入れ先では、販売店からの発注を受ける
（受注する）と、契約している宅配業者を使って商品の
出荷を行う。この出荷処理に伴い、注文データベース２
１ｂには、伝票番号などの出荷・搬送に関する情報を格
納する。この情報は、発注結果として受発注サーバ１に
も送られ、受発注サーバ１の注文データベース１１ｃに
格納される。

【００４３】顧客は、発注した後、受発注サーバ１にア
クセスすることにより、注文した商品の現在の状況を確
認することができる。つまり、係る状況問い合わせを受
けた受発注サーバ１の制御部１０は、その会員の注文し
た商品リストを出力する。この商品リストには、現在の
状況（出荷待ち（出荷予定日），出荷中など）ととも
に、出荷したものについては宅配便の伝票番号を表示す
る。さらに、画面上には、上記宅配便のホームページ
（追跡調査）６にリンクが張られており、係るホームペ
ージに飛ぶことにより、顧客は、伝票番号に基づいて商
品が現在どこにあるかを確認できるようになる。

【００４４】上記した処理は、受発注サーバ１並びに在
庫管理システム３がともに稼働している場合の通常の処
理である。ここで本発明では、在庫管理システム３が非
稼働中であっても受発注サーバ１が、商品の受注や、納
期回答などができるようにしている。これにより、受発
注サーバ１を２４時間稼働させることができ、顧客は、
自分の都合に合わせていつでも商品の注文ができるとと
もに、納期の確認をすることができる。

【００４５】具体的には、受発注サーバ１に滞留データ
ベース１１ｄを設ける。この滞留データベース１１ｄ
は、在庫管理システム３が非稼働中の時に受注したデー
タを一時的に格納するものである。そして、在庫管理シ
ステム３が稼働した際に、この滞留データベース１１ｄ
に格納した仮受注データに基づいて、在庫管理システム
３に対して正式な発注処理等を行う。

【００４６】正式な発注処理を行うことにより、滞留デ
ータベース１１ｄに格納されたデータは、注文データベ
ース１１ｃに移し替えられる。そして、在庫管理システ
ム３からの発注結果があると、通常の処理と同様に注文
データベース１１ｃに登録される。

【００４７】在庫管理システム３が稼働中か否かの判断
は、例えば予め受発注サーバ１側で稼働している時刻
（例えば、ＡＭ９：００からＰＭ５：３０など）のタイ
ムテーブルを持ち、それに基づいて受発注サーバ１の制
御部１０が判断することもできるが、係るタイムテーブ
ルの更新の煩雑さや、在庫管理システム３の臨時停止に
対応することから、本形態では「稼働フラグ」を持ち、
在庫管理システム３側から現在稼働中か否かの情報を受
け取り、稼働フラグをＯＮ／ＯＦＦすることにより制御
する。制御部１０は、この稼働フラグを確認することに
より、在庫管理システム３が稼働中で通常の処理が可能
か、非稼働中で滞留データベース１１ｄに格納しなけれ
ばならないかなどの判断を行うようにしている。

【００４８】更に納期については、各商品毎に標準納期
を設定することにより対応している。標準納期は、通常
の状態で受注した場合に、その商品を出荷するまでに要
する日数である。基本的に、在庫が存在する場合には即
日（翌日）出荷対応できるが、タイミングが悪く在庫切
れなどを生じていることも想定し、若干余裕を持って設
定している。もちろん、商品の中には受注生産のものも
あり、係る場合には、受注してから生産し製造するまで
に係る平均日数を求め、それらから一定のマージンをと
って決めても良い。なお、受注生産品の場合には、標準
納期なしとすることもできる。また、本例では、標準納
期は、「Ｘ営業日後」というように表すようにしてい
る。

【００４９】この標準納期は、仕入れ先との取り決めに
より予め各商品毎に決めておき、商品データベース１１
ａに商品と関連づけて格納する。これにより、在庫管理
システム３が非稼働中に顧客からの注文があった場合に
は、商品データベース１１ａをアクセスし、その商品の
標準納期を抽出し、それを表示することにより納期回答
するようにした。

【００５０】これにより、顧客は、標準納期を見ること
により、正式に購入（発注）するか否かを判断すること
ができる。なお、正式に発注された商品は、滞留データ
ベース１１ｄに格納され、在庫管理システム３が稼働し
た際に発注するのは上記した通りであるが、この発注に
ともない、在庫管理システム３からその商品についての
納期回答があるので、係る納期回答を受けたならば、標
準納期を正式な納期（出荷予定日）に置き替える処理を
行う。

【００５１】次に、上記した処理を実行するための具体
的な構成について説明する。受発注サーバ１は、図２に
示すように、インターネット２に接続され、データの送
受を行うための通信インタフェース１２を備えている。
また、在庫管理システム３とデータの送受を行うための
インタフェース１３も備えている。受発注サーバ１と在
庫管理システム３は、公衆回線，専用回線７はもちろん
のこと、インターネットやＬＡＮ等の各種のネットワー
ク網を用いることができ、インタフェース１３は、係る
使用する通信形態に応じて設定する。

【００５２】なお、本形態の場合、受発注サーバ１は販
売店のシステムで、在庫管理システム３は仕入れ先のシ
ステムと説明したが、係る場合のＬＡＮの利用形態とし
ては、受発注サーバ１と在庫管理システム３を同一の場
所に設置することにより対応できる。つまり、別会社で
あっても場所を共有することによりＬＡＮ接続は可能と
なる。

【００５３】制御部１０は、会員管理処理部１０ａと、
受発注処理部１０ｂと、滞留データ処理部１０ｃを備え
ている。まず、会員管理処理部１０ａは、会員データベ
ース１１ｂへのデータ登録，更新処理などを行うもので
ある。つまり、会員データベース１１ｂは、会員番号
（会員ＩＤ），名前，会社名，所属，住所，電子メール
アドレス，パスワード，電話・ＦＡＸ番号などを関連づ
けて格納するようになっている。

【００５４】そこで、会員管理処理部１０ａは、例えば
図３に示すような新規会員登録画面を顧客端末４のモニ
タ上に出力表示させ（実際には、図示の下にも各種のデ
ータを入力領域がある）、会員登録を促す。そして、入
力されたデータを取得し、「必須項目が入力されている
か」、「文字数，使用可能な文字種類は正しいか」など
の判断を行い、問題がない場合には図４に示すような確
認画面を出力し、内容に間違いがないか否かを確認させ
る。

【００５５】そして、「送信」キーが選択されたなら
ば、内容に間違いなしと判断し、会員番号（会員ＩＤ）
を発行し、その会員ＩＤとともに入力された情報を会員
データベース１１ｂに登録する。また、同時に、顧客端
末４のモニタ画面に対しては、例えば図５に示すような
登録完了通知とともに会員ＩＤを通知するメッセージを
出力する。

【００５６】上記した以外にも、既登録の会員情報の内
容に変更があった場合には、更新処理を行う機能も持
つ。要は、通常のオンラインでの会員登録処理と同様の
処理を行うものである。

【００５７】受発注処理部１０ｂは、図６，図７に示す
フローチャートを実施する機能を持つ。同図に示すよう
に、まず顧客端末４からのアクセスがあると、正規の会
員か否かを判断する（ＳＴ１）。すなわち、最初に会員
ＩＤとパスワードの入力を受けるようにしているため、
入力された会員ＩＤとパスワードの組み合わせがあって
いるか否かを判断する。

【００５８】そして、非会員の場合には、所定の処理を
実行する（ＳＴ２）。この所定処理としては、エラーメ
ッセージとともにパスワード，会員ＩＤの再入力を促し
たり、新規登録画面へ飛ぶようにすることなどがある。

【００５９】一方、正規の会員と判断されると、商品選
択処理を行う（ＳＴ３）。つまり、商品の検索画面（図
示省略）を表示する。この検索画面は、商品を絞り込む
ための条件の入力画面であり、例えば、商品の種類，商
品名，商品コードなどを入力する。この入力を受けて該
当する商品リストを表示する。そして、その商品リスト
を見た顧客は、自己が必要とする（注文しようとした）
ものであるか否かを判断し、必要な場合には選択すると
ともに数量を入力する。

【００６０】この入力に基づき、図８に示すような買い
物かご画面を表示する。つまり、選択した商品の数量に
基づき総金額を算出し、コード，商品名，数量，単価，
金額を関連づけて表示する。図から明らかなように、画
面の下方領域には、商品の追加を行うための「買い物を
続ける」キーと、注文を停止する「買い物をやめる」キ
ーと、納期を確認するための「納期確認」キーが用意さ
れている。

【００６１】そして、「買い物を続ける」キーをクリッ
クすると、商品の検索・選択画面に進み、「買い物をや
める」キーをクリックすると、今まで選択し、買い物か
ごに登録した商品をクリアし、今回の注文処理を終了す
る。従って、必要なものが集まるまで「買い物を続け
る」キーを押して逐次商品とその数量を選択する。

【００６２】必要な商品の選択が終了したならば、「納
期確認」キーがクリックされる（ＳＴ４でＹｅｓ）の
で、それを検知すると稼働フラグのチェックを行う（Ｓ
Ｔ５）。

【００６３】すでに説明したように、稼働フラグは、在
庫管理システム３から送られてくる通知に従ってＯＮ／
ＯＦＦを切り替えるもので、在庫管理システム３が稼働
中は稼働フラグもＯＮになるように制御されている。具
体的には、在庫管理システム３の制御部２０が、稼働開
始直後に「開始通知」を送ってくるので、その開始通知
を受けると、稼働フラグをＯＮにする。また、在庫管理
システム３が停止する所定時間前（例えば５分前）に
「終了通知」を送ってくるので、その終了通知を受ける
と稼働フラグをＯＦＦにする。

【００６４】そこで、このステップ５の処理では、係る
稼働フラグをサーチし、ＯＮか否かを判断する。そし
て、ＯＦＦの場合には、非稼働時処理を実施する。この
非稼働時処理は、滞留データ処理部１０ｃが実施するも
ので、具体的な処理は後述する。

【００６５】一方、稼働フラグがＯＮの時には、在庫管
理システムに対してオンラインでの問い合わせや注文が
行えるので、ステップ６に進み、在庫管理システムへ納
期の問い合わせを行う。つまり、商品を特定するコード
と数量とともに納期確認（仮発注）を行う。なお、販売
店側と仕入れ先では、同一の商品について付している商
品コードが異なる場合が多々ある。特に、後述するよう
に仕入れ先が複数存在する場合にはなおさらである。そ
こで、商品データベース１１ａには、仕入れ先の商品コ
ード情報も併せて格納しておき、この処理ステップを実
行するに際し、商品コードの変換、つまり、仕入れ先
（在庫管理システム３）で扱っている商品コードを抽出
し、それを出力する。

【００６６】後述するように、在庫管理システム３は、
問い合わせを受けた商品についての出荷予定日を通知
（納期回答）してくるので、係る納期回答を待つ（ＳＴ
７）。そして、係る納期回答に従って、顧客端末４のモ
ニタに対し、納期確認画面（図９参照）を表示する（Ｓ
Ｔ８）。図から明らかなように、在庫管理システム３か
ら通知された出荷予定日を表示する。なお、在庫切れな
どにより出荷予定日が不明であることを通知された場合
には、この納期確認画面における出荷予定日は「＊＊
＊」としている。

【００６７】さらに、画面の下方には、会員データベー
ス１１ｂに登録された会員の住所を表示するとともに、
更に送付先が異なる場合に臨時の送付先を入力する画面
を用意している。

【００６８】この画面の下端領域には、表示内容で注文
する「注文確認」キーと、注文した商品が全てそろった
ときにまとめて出荷することを要求する「最終出荷日に
あわせて注文する」キーと、表示内容では注文をしない
「戻る」キーを用意する。

【００６９】次に、正式な注文を受けたか否かを判断す
る（ＳＴ９）。すなわち、図９に示した納期確認画面に
おいて、「注文確認」キー或いは「最終出荷日にあわせ
て注文する」キーがクリックされた場合には、この分岐
判断はＹｅｓとなり、「戻る」キーがクリックされたな
らばＮｏとなる。そして、Ｎｏの場合には、ステップ３
に戻り買い物かご画面へ戻る。

【００７０】正式発注があると、商品発注画面を表示す
る（ＳＴ１０）。つまり、図１０に示すように、注文し
た商品情報（商品名，個数，金額，出荷予定日等）とと
もに確定した商品の発送先住所や支払方法を表示する。
更に、この表示画面の下端には、「送信」キーと「戻
る」キーを用意している。「戻る」キーがクリックされ
ると、ステップ８の納期確認画面表示に戻り、「送信」
キーがクリックされる（ステップ１１でＹｅｓ）と、正
式発注処理を行う（ＳＴ１２）。つまり、ステップ１０
で表示した内容を在庫管理システム３へ送信し、正式発
注を行う。

【００７１】この後、在庫管理システム３からは、発注
結果が送られてくるので、それを待つ（ＳＴ１３）。そ
して、発注結果が送られてくると、顧客端末４のモニタ
に注文完了画面（図１１参照）を表示する（ＳＴ１
４）。

【００７２】また、サーバ用の注文データが作成され、
注文データベース１１ｃに格納する（ＳＴ１５）。注文
データとしては、顧客の正式注文に関する情報で、通販
コード，商品名，数量等の情報と顧客情報を含む。さら
に、在庫管理システム側の注文データと関連付ける照会
番号も含む。在庫管理システム３への発注データにもな
る。顧客注文が確定された情報となる。

【００７３】次に、滞留データ処理部１０ｃの機能を説
明する。滞留データ処理部１０ｃは、在庫管理システム
３が非稼働時のときに仮の受注処理をして貯留データベ
ース１１ｄに登録する機能（図６中の非稼働時処理を実
行する機能）と、滞留データベース１１ｄに格納された
データに基づき、正式な発注処理を行う機能を有する。

【００７４】まず、前者の機能は、図１２に示すフロー
チャートのようになる。稼働フラグがＯＦＦの時に、ス
テップ３の処理により確定された商品に対し、商品デー
タベース１１ａをアクセスし、その商品の標準納期を取
得する（ＳＴ２１）。そして、顧客端末４のモニタに対
し、納期確認画面を表示する（ＳＴ２２）。納期確認画
面は、図９に示すものと同様で、出荷予定日の欄が「Ｘ
営業日後」（Ｘは標準納期）となる。出荷予定日の表示
以外は通常のものと同様である。従って、顧客は稼働時
／非稼働時のどちらでも違和感無く対処できる。この点
は、以下の各処理でも同様である。

【００７５】次に、正式な注文を受けたか否かを判断す
る（ＳＴ２３）。すなわち、図９に示した納期確認画面
において、「注文確認」キー或いは「最終出荷日にあわ
せて注文する」キーがクリックされた場合には、この分
岐判断はＹｅｓとなり、「戻る」キーがクリックされた
ならばＮｏとなる。そして、Ｎｏの場合には、ステップ
３に戻り買い物かご画面へ戻る。

【００７６】正式発注があると、商品発注画面を表示す
る（ＳＴ２４）。つまり、図１０に示すように、注文し
た商品情報（商品名，個数，金額，出荷予定日等）とと
もに確定した商品の発送先住所や支払方法を表示する。
更に、この表示画面の下端には、「送信」キーと「戻
る」キーを用意している。「戻る」キーがクリックされ
ると、ステップ２２の納期確認画面表示に戻り、「送
信」キーがクリックされる（ステップ２５でＹｅｓ）
と、顧客端末４のモニタに注文完了画面を表示する（Ｓ
Ｔ２６）。この注文完了画面も、基本的に図１１と同様
であり、異なるのは出荷予定日の表示が「Ｘ営業日後」
となっている点である。そして、注文を受けた内容（顧
客情報，商品，個数、送付先等の情報）を滞留データベ
ース１１ｄに格納し、処理を終了する（ＳＴ２７）。

【００７７】一方、滞留データベース１１ｄに格納され
たデータに基づき、正式な発注処理を行う機能は、図１
３に示すフローチャートのようになる。すなわち、在庫
管理システム３から開始通知を受けたり、或いは、稼働
フラグがＯＮになったのを確認した（ＳＴ３１）なら
ば、滞留データベース１１ｄをサーチし、稼働フラグが
ＯＮになった在庫管理システム３に対する滞留データが
あるか否かを判断する（ＳＴ３２）。そして、無い場合
には処理を終了し、滞留データが存在したならば、滞留
データ処理を開始する。

【００７８】滞留データ処理は、基本的には、蓄積され
ている滞留データ、つまり、仮受注した商品を正式に発
注するものである。このとき、滞留データベース１１ｄ
に大量にデータが蓄積されている場合に、そのデータを
一度に在庫管理システム３側に送ると、在庫管理システ
ム３側の付加が大きくなりすぎるので、所定時間当たり
に処理する件数を定め、分散して行う。

【００７９】つまり、予め定めた件数分の受注データを
読み出し、在庫管理システムの商品コードを取得して置
き替える（ＳＴ３３，ＳＴ３４）。そして、その置き替
えた商品コードに基づく発注データを作成し、在庫管理
システム３へ送信し、正式な発注処理を行う（ＳＴ３
５）。

【００８０】この発注処理を受けた在庫管理システム３
からは、発注結果が送られてくるので、それを待つ（Ｓ
Ｔ３６）。そして、発注結果が送られてくると、注文デ
ータベース１１ｃに格納する（ＳＴ３７）。これによ
り、正確な出荷予定日がわかる。

【００８１】さらに本形態では、注文状況の確認を行う
ことができるようになっている。すなわち、顧客端末４
から受発注サーバ１に対して注文状況の確認要求がある
と、注文データベース１１ｃをアクセスし、会員ＩＤを
キーにしてその会員の注文データを抽出し、顧客端末４
のモニタに注文状況結果を表示する機能を持つ。この注
文状況結果の一例としては、図１４に示すようになる。
図から明らかなように、未出荷のものに付いては出荷予
定日が表示され、出荷済のものには、宅配便の伝票番号
が表示される。これにより、顧客は伝票番号から現在商
品がどこにあるかを知ることができる。また、夜間など
に注文した場合には、翌日などにこの注文状況の確認を
行うと、正確な納期がわかる。

【００８２】一方、在庫管理システム３の制御部２０
は、図１５に示すフローチャートのように機能する。す
なわち、納期問い合わせを受信すると、依頼のあった商
品コードと数量を認識し、在庫データベース２１ａをア
クセスして在庫状況を確認する（ＳＴ４０〜ＳＴ４
２）。そして、在庫がある場合には出荷予定日を把握
し、その結果を送信する（ＳＴ４３，ＳＴ４４，ＳＴ４
６）。また、在庫がない場合には、出荷予定日不明扱い
とし「＊＊＊」を返す（ＳＴ４５，ＳＴ４６）。

【００８３】また、正式の発注（商品コード＋数量）を
受けると、在庫データベース２１ａに対して該当する数
量分だけ在庫の引当処理を行う（ＳＴ４７，ＳＴ４
８）。次いで、在庫管理システム用の注文データを作成
し、注文データベース２１ｂに登録する（ＳＴ４９）。
ここで作成される注文データは、結果として受注サーバ
１で作成され注文データベース１１ｃに格納された注文
データと同じような内容となる。在庫引き当て済みの注
文受け付け情報となる（在庫引き当て分を含むこともあ
る）。さらに、この注文データは、発注結果（出荷予定
日，伝票番号等も含む）として受発注サーバ１側に送信
される（ＳＴ５０）。

【００８４】上記した処理によれば、受発注処理部１０
ｂ，貯留データ処理部１０ｃからの処理の何れにも対応
できる。また、それぞれ個別に対応するシステムにする
場合には、例えば、受発注処理部１０ｂに対しては、正
式な注文の前に納期問い合わせがあるので、その後に行
われる正式な注文があった場合には、数量など受けるこ
となく（納期問い合わせの際に受け取った数量）在庫引
当処理をすることができる。また、納期問い合わせに対
する回答として予定出荷日を教えているので、正式な注
文を受けた際の発注回答としては、予定出荷日の通知を
省略するようにしても良い。

【００８５】図１６は、本発明の第２の実施の形態を示
している。上記した実施の形態では、在庫管理システム
３は１つであったが、本実施の形態では複数存在する点
で相違する。説明の便宜上、受発注サーバ１は、２つの
在庫管理システム３′，３″と接続されるようにした
が、３つ以上でももちろん良い。また、各在庫管理シス
テム３，３′との接続媒体であるが、一方を公衆回線と
し、他方をインターネットとする等、異ならせてももち
ろん良い。

【００８６】係る構成において、受発注サーバ１側では
商品データベース１１ｂに登録する情報として、上記し
た第１の実施の形態のものに加え、さらに、発注する在
庫管理システムを特定する情報を入れている。すなわ
ち、ある商品についての仕入れ先を１つに割り付けるよ
うにしている。

【００８７】一方、各在庫管理システム３′，３″は、
ともに第１の実施の形態における在庫管理システム３と
同様の構成からなり、稼働フラグＯＮ／ＯＦＦを制御す
るための「開始通知」並びに「終了通知」を行う機能
と、図１５に示すフローチャートを実施する機能などを
備えている。つまり、受発注サーバ１から納期問い合わ
せがあると、該当する商品の納期を返答し、正式な注文
を受けると、在庫データベース２１ａに対する引当処理
並びに注文データベース２１ｂへの登録及び発注結果の
送信などを行う。

【００８８】これにより、受発注サーバ１は、顧客から
の注文に伴い、商品データベース１１ａをアクセスし、
その商品の仕入れ先（在庫管理システム）を認識する。
そして、以後の処理は、認識した仕入れ先との間で第１
の実施の形態で説明した各種処理を実行することにより
動作する。

【００８９】また、顧客から複数種の商品を指定された
場合に、各商品が別々の仕入れの場合には、仕入れ先ご
とに納期問い合わせや正式な発注処理を行うことにな
る。ところで、１回の注文で複数の仕入れ先の商品が選
択され、しかも、その複数の仕入れ先が非稼働中のもの
と稼働中のものが混在する場合は、稼働中のものはオン
ラインで納期の問い合わせを行って納期回答をするとと
もに、非稼働中のものに対しては標準納期を回答するよ
うにすると良い。また、正式な発注も、稼働中のものは
そのまま正式な発注処理を行い、非稼働中のものに対し
ては稼働した際に改めて正式な発注を行うようにするこ
ともできる。

【００９０】また、一部でも非稼働中のものが存在した
場合には、全て標準納期を答えるようにし、翌日一斉に
正式な注文をするように運用することもできる。さらに
は、問い合わせだけは、稼働中のものに対してはリアル
タイムに行い、正式な発注は翌日にするなど、各種の対
応が採れる。

【００９１】但し、対顧客で考えた場合には、１つの注
文としてとらえられるので、非稼働中のものを含む場合
には、一旦貯留データベース１１ｄに格納するのがよ
い。そして、稼働中のものに対しては先に正式な発注を
行うようにした場合には、貯留データベース１１ｄに格
納する際に、発注済であることを示すフラグなどを立て
る。これにより、翌日の正式な発注処理をするに際し、
上記フラグのたっていないものに対してのみ処理をすれ
ば良くなる。なお、その他の構成並びに作用効果は、上
記した第１の実施の形態と同様であるので、対応する部
材に同一符号を付し、その詳細な説明を省略する。

【００９２】さらにまた、仕入れ先が複数存在している
場合において、そのうちの一部の仕入れ店がオンライン
による自動受発注に対応していないケースもある。係る
場合には、オンライン対応していない仕入れ先は、在庫
管理システムが常に非稼働中であるとし、係る仕入れ先
の商品については、標準納期で回答することにより本シ
ステムで対処できる。

【００９３】図１７は、本発明の第３の実施の形態を示
している。本実施の形態では、販売店側の受発注サーバ
１，１′が複数存在している場合に適用した例である。
すなわち、顧客がインターネット経由で注文できない場
合に、顧客に代わって販売店側でデータの入力を行うも
のである。つまり、インターネットショッピングと、従
来の人を介して受発注サーバを混在したものに適したシ
ステムである。

【００９４】一方の受発注サーバ１は、上記した各実施
の形態と同様である。そして、他方の受発注サーバ１′
は、ＬＡＮなどで接続された入力装置３０からの入力に
従い、受発注を行うもので、仕入れ先が自動的な受発注
に対応しているものに対しては、入力装置３０を介して
受発注サーバ１′に登録したデータを、受発注サーバ１
に送り、そこにおいて所定の処理を実行する。そして、
その処理の結果の回答は、受発注サーバ１′に送られて
くるので、その結果を顧客に伝達し、正式に発注して良
いか否かの判断を行う。

【００９５】そして、両受発注サーバ１，１′は、内容
の同一性が確保される必要がある。そこで、一定の時間
間隔ごとに現在の状況を相手に渡し、受け取った側では
コピーすることにより、同一性を担保する。なお、その
他の構成並びに作用効果は、上記した第１の実施の形態
と同様であるので、対応する部材に同一符号を付し、そ
の詳細な説明を省略する。

【００９６】

【発明の効果】以上のように、この発明では、在庫管理
システムと連携して顧客からの受注処理並びに納期回答
などを行うシステムにおいて、在庫管理システムが非稼
働時であっても各種処理を行うことができ、究極には、
２４時間体制でサービスの提供を行うことのできる受注
システム及び受注処理方法並びにサーバを提供すること
を目的とする。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態を示す図である。

【図２】本発明の第１の実施の形態を示す図である。

【図３】新規会員登録画面の一例を示す図である。

【図４】新規会員登録確認画面の一例を示す図である。

【図５】登録確認画面の一例を示す図である。

【図６】受発注処理部の機能を示すフローチャートの一
部である。

【図７】受発注処理部の機能を示すフローチャートの一
部である。

【図８】受発注処理部の機能を説明する図である。

【図９】受発注処理部の機能を説明する図である。

【図１０】受発注処理部の機能を説明する図である。

【図１１】受発注処理部の機能を説明する図である。

【図１２】貯留データ処理部の機能を示すフローチャー
トの一部である。

【図１３】貯留データ処理部の機能を示すフローチャー
トの一部である。

【図１４】状況確認画面の一例を示す図である。

【図１５】在庫管理システムにおける制御部の機能を示
すフローチャートの一部である。

【図１６】本発明の第２の実施の形態を示す図である。

【図１７】本発明の第３の実施の形態を示す図である。

【符号の説明】

１，１′ 受発注サーバ ２ インターネット ３ 在庫管理システム ４ 顧客端末 ６ ホームページ ７ 通信網 １０ 制御部 １０ａ 会員管理処理部 １０ｂ 受発注処理部 １０ｃ 貯留データ処理部 １１ａ 商品データベース １１ｂ 会員データベース １１ｃ 注文データベース １１ｄ 滞留データベース １２ 通信インタフェース １３ インタフェース ２０ 制御部 ２１ａ 在庫データベース ２１ｂ 注文データベース ３０ 入力装置

───────────────────────────────────────────────────── フロントページの続き (72)発明者 渡邊 正 京都府京都市下京区塩小路通堀川東入南不 動堂町801番地 オムロンネットワークア プリケーションズ株式会社内 (72)発明者 福森 務 京都府京都市下京区塩小路通堀川東入南不 動堂町801番地 オムロンネットワークア プリケーションズ株式会社内

Claims (11)

【特許請求の範囲】
1. 【請求項１】 ネットワークに接続可能なサーバと、そ
   のサーバと通信で接続可能な在庫管理システムとを備
   え、前記ネットワークを介して顧客端末から注文を受け
   るオンラインによる受注システムにおける受注処理方法
   であって、 前記サーバは、商品についての標準納期を記憶した標準
   納期データベースを持ち、 前記サーバは、前記ネットワークを介して顧客端末から
   の注文を受け付けた際に、その注文を受けた商品を管理
   する前記在庫管理システムに対してその商品の納期の問
   い合わせを実行し、 前記納期の問い合わせを受けた前記在庫管理システム
   は、在庫データベースをアクセスして取得したその商品
   についての納期情報を前記サーバに送り、 前記サーバは受け取った納期情報に基づいて、前記顧客
   端末に向けて納期を通知し、 前記在庫管理システムの非稼働時に受けた前記顧客端末
   からの納期問い合わせに対しては、前記標準納期データ
   ベースから対応する商品の標準納期を取得し、その標準
   納期を前記顧客端末に対して通知し、 前記サーバは前記顧客端末からの正式な発注を受け付け
   た場合、所定の処理を実行するようにしたことを特徴と
   する受注処理方法。
2. 【請求項２】 ネットワークに接続可能なサーバと、そ
   のサーバと通信で接続可能な在庫管理システムと、前記
   ネットワークを介して前記サーバに接続可能な顧客端末
   を備え、前記顧客端末から注文を受けるオンラインによ
   る受注システムにおける受注処理方法であって、 前記サーバは、商品についての標準納期を記憶した標準
   納期データベースを持ち、 前記サーバは、前記顧客端末からの注文を受け付けた際
   に、その注文を受けた商品を管理する前記在庫管理シス
   テムに対してその商品の納期の問い合わせを実行し、 前記納期の問い合わせを受けた前記在庫管理システム
   は、在庫データベースをアクセスして取得したその商品
   についての納期情報を前記サーバに送り、 前記サーバは受け取った納期情報に基づいて、前記顧客
   端末に向けて納期を通知し、 前記在庫管理システムの非稼働時に受けた前記顧客端末
   からの納期問い合わせに対しては、前記標準納期データ
   ベースから対応する商品の標準納期を取得し、その標準
   納期を前記顧客端末に対して通知し、 前記サーバは前記顧客端末からの正式な発注を受け付け
   た場合、所定の処理を実行するようにしたことを特徴と
   する受注処理方法。
3. 【請求項３】 前記サーバは、前記在庫システムが非稼
   働時に前記顧客端末からの正式な注文を受けた際にその
   受けた内容を一時記憶手段に格納し、 次いで、前記在庫管理システムが稼働した際に、前記一
   時記憶手段に格納したデータに基づいて前記在庫管理シ
   ステムに対して正式発注をし、 前記在庫管理システムは、その正式発注を受けたなら
   ば、前記在庫データベースにアクセスして正式発注を受
   けた商品についての在庫引当処理を行うことを特徴とす
   る請求項１または２に記載の受注処理方法。
4. 【請求項４】 前記在庫管理システムが複数存在し、 前記サーバは、注文を受けた商品に基づき、その商品に
   関する在庫管理システムを決定し、その決定した在庫管
   理システムとの間でデータの送受を行うことを特徴とす
   る請求項１〜３のいずれか１項に記載の受注処理方法。
5. 【請求項５】 ネットワークを介して顧客端末から商品
   の注文を受け付けるためのサーバであって、 前記商品を管理する在庫管理システムと通信で接続可能
   となり、 受け付けた正式な注文に関する情報を記憶する注文デー
   タベースと、 商品についての標準納期を記憶した標準納期データベー
   スと、 前記顧客端末からの注文に基づき、前記在庫管理システ
   ムに対して、商品の納期の問い合わせを行う機能と、 前記在庫管理システムからの納期回答に基づき前記顧客
   端末に向けて納期を通知する機能と、 前記顧客端末からの正式な発注を受け付けた場合に、そ
   の発注に伴う情報を前記注文データベースに記憶する機
   能と、 前記在庫管理システムが非稼働中であると判断する機能
   と、 前記在庫管理システムの非稼働時に受けた前記顧客端末
   からの納期の問い合わせに対し、前記商品データベース
   にアクセスして対応する商品の標準納期を取得し、その
   標準納期を前記顧客端末に対して回答する機能を備えた
   ことを特徴とするサーバ。
6. 【請求項６】 前記非稼働時に前記顧客端末からの正式
   な注文を受けた際に、その受けた内容を前記注文データ
   ベースに記憶することなく、その注文データベースと別
   に形成された一時記憶手段に格納するとともに、前記在
   庫管理システムが稼働した際に、前記一時記憶手段に格
   納したデータに基づいて前記在庫管理システムに対して
   正式発注をし、その後、前記注文データベースに正式な
   注文に関する情報を前記注文データベースに記憶する処
   理手段を備えたことを特徴とする請求項５に記載のサー
   バ。
7. 【請求項７】 前記在庫管理システムが複数存在する場
   合において、注文を受けた商品に基づき、その商品に関
   連する在庫管理システムを決定し、その決定した在庫管
   理システムとの間でデータの送受を行うようにしたこと
   を特徴とする請求項５または６に記載のサーバ。
8. 【請求項８】 ネットワークに接続可能なサーバと、そ
   のサーバと通信で接続可能な在庫管理システムとを備
   え、 前記サーバは、前記ネットワークを介して顧客端末から
   の注文を受け付けた際に、その注文を受けた商品を管理
   する前記在庫管理システムに対してその商品の納期の問
   い合わせをするとともに、前記在庫管理システムからの
   納期の回答に基づき前記顧客端末に向けて納期を通知す
   る機能と、 前記顧客端末からの正式な発注を受け付け、データベー
   スに記憶する機能を備えたオンラインによる受注システ
   ムであって、 前記サーバは、商品についての標準納期を記憶した商品
   データベースを持ち、 前記在庫管理システムの非稼働時に受けた前記顧客端末
   からの納期の問い合わせに対しては、前記商品データベ
   ースから対応する商品の標準納期を取得し、その標準納
   期を前記顧客端末に対して回答する機能を備えたことを
   特徴とする受注システム。
9. 【請求項９】 ネットワークに接続可能なサーバと、そ
   のサーバと通信で接続可能な在庫管理システムと、前記
   ネットワークを介して前記サーバに接続可能な顧客端末
   を備え、 前記サーバは、前記顧客端末からの注文を受け付けた際
   に、その注文を受けた商品を管理する前記在庫管理シス
   テムに対してその商品の納期の問い合わせをするととも
   に、前記在庫管理システムからの納期の回答に基づき前
   記顧客端末に向けて納期を通知する機能と、 前記顧客端末からの正式な発注を受け付け、データベー
   スに記憶する機能を備えたオンラインによる受注システ
   ムであって、 前記サーバは、商品についての標準納期を記憶した商品
   データベースを持ち、 前記在庫管理システムの非稼働時に受けた前記顧客端末
   からの納期の問い合わせに対しては、前記商品データベ
   ースから対応する商品の標準納期を取得し、その標準納
   期を前記顧客端末に対して回答する機能を備えたことを
   特徴とする受注システム。
10. 【請求項１０】 前記サーバは、前記非稼働時に受け付
    けた前記顧客端末からの正式な注文を一時記憶手段に格
    納するとともに、前記在庫管理システムが稼働した際
    に、前記一時記憶手段に格納したデータに基づいて前記
    在庫管理システムに対して正式発注をし、 前記在庫管理システムは、その正式発注を受けて在庫引
    当処理を実行するように構成したことを特徴とする請求
    項８または９に記載の受注システム。
11. 【請求項１１】 顧客が入力した商品情報要求を送信
    し、返信された商品情報を表示し、発注情報を送信する
    顧客端末と、 前記商品情報要求に基づいて、納期情報を含む商品情報
    を前記顧客端末に返信し、前記発注に基づいて、在庫引
    き当てのトリガを出すサーバシステムと、 前記サーバシステムと連動し、前記サーバシステムから
    の納期問い合わせに応じてその都度納期を判断してその
    結果を前記納期情報として前記サーバシステムに返信
    し、前記トリガに応じて在庫引き当て処理をして注文デ
    ータベースに記録することを行う在庫管理システムとか
    らなり、 前記サーバシステムは、前記在庫管理システムが非稼働
    と判断した際に、予めデータベースに記憶した標準納期
    情報を前記納期情報として前記顧客端末に返信するとと
    もに、前記在庫管理システムが稼働するまで前記在庫引
    き当てトリガを滞留するようにしたインターネットショ
    ッピングシステム。