JP4055366B2 - 受注システム及び受注処理方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明は、受注システム及び受注処理方法に関するものである。
【０００２】
【発明の背景】
商品の受注形態の一つとして、インターネットを利用したものがある。これは、受発注サーバのウェブサイトに対し、顧客がインターネット経由でアクセスし、注文画面にて必要な商品を選択するとともに、個数を入力することにより、顧客が発注を行う。受発注サーバは、この顧客からの発注（システムにとっては受注）に伴い、メーカ等に対して自動発注を行う。
【０００３】
さらに、自動発注する際に、メーカ等の在庫管理システムに直接行うものがある。すると、在庫管理システムは、注文を受けた商品の在庫情報がわかっているので、何時納品できるかなどの納期情報を受発注サーバに対して自動的に行うことができる。従って、顧客からの注文を受けた受発注サーバは、在庫管理システムからの納期情報に基づき、顧客に納期回答をすることができる。そして、当然のことながら、上記した受発注サーバと在庫管理システムは、ともにコンピュータその他の装置で構成されているため、データの送受は自動的かつリアルタイムで行うことができる。
【０００４】
上記したシステム構成によれば、顧客は、インターネットを経由して受発注サーバにアクセスし、そこにおいて商品の注文（仮の問い合わせ）をすると、上記した情報の送受により、瞬時にその商品の納期を知ることができる。よって、その納期でよいか否かの判断をして、正式な発注をするような運営ができるので、顧客にとっては安心して商品の納品を待つことができ、商品の販売側では受発注処理から顧客への納期の回答も自動的に行えるという利点がある。
【０００５】
ところで、上記したシステムを稼働させるためには、受発注サーバと在庫管理システムがともに稼働し、通信可能な状態になっている必要がある。しかしながら、在庫管理システムは、セキュリティその他の要因から通常その会社の営業時間中は稼働しているものの、夜間などは停止している。
【０００６】
従って、仮に受発注サーバを２４時間稼働させたとしても、在庫管理システム側が停止している夜間などでは、上記したリアルタイムでの納期回答や自動発注処理ができない。すると、使用者側（この場合には特に顧客）の都合に併せて２４時間いつでも利用できるというインターネットのメリットが十分に生かすことができない。
【０００７】
さらに、上記した両システムを共に２４時間稼働させることにより、２４時間体制で休みなく受注や納期回答などを行うことができる。しかし、実際には、受発注サーバを運営する会社（商社等の顧客の注文を受ける会社）と、在庫管理システムを稼働させる会社（メーカ等の工場その他の商品を生産している会社等）とが別会社の場合には、一方の都合で他方にシステムを２４時間稼働させることを要求するのは困難である。
【０００８】
この発明は、在庫管理システムと連携して顧客からの受注処理並びに納期回答などを行うシステムにおいて、在庫管理システムが非稼働時であっても各種処理を行うことができ、究極には、２４時間体制でサービスの提供を行うことのできる受注システム及び受注処理方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
この発明は、ネットワークに接続可能でかつ制御部と標準納期データベースと注文データベースと滞留データ一時記憶手段とを持つサーバと、そのサーバと通信可能でかつ在庫データベースを持つ在庫管理システムとを備え、前記ネットワークを介して顧客端末から注文を受けるオンラインによる受信システムを前提としている。顧客は、顧客端末をネットワークに接続することにより、そのネットワークを介してサーバにアクセスし、商品の注文等をすることができる。
【００１０】
そして、この発明による受注処理方法は、上記の受注システムにおける受注処理方法であり、以下の処理を実行するようにしている。すなわち、前記サーバの標準納期データベースは商品についての標準納期情報を、前記注文データベースは受けた注文情報を、前記在庫管理システムの在庫データベースは商品とその商品の在庫数を関連付けた在庫情報を、それぞれ記憶するものであり、前記サーバの制御部は、前記顧客端末からのアクセスによって商品情報とその個数情報とを含む注文情報を受信する処理と、その顧客端末に対して納期情報（出荷予定日）を通知する処理とを行うものである。
前記在庫管理システムの稼動中は、前記サーバの制御部は、前記顧客端末から受信した注文情報の商品情報と個数情報とに基づいて、前記在庫管理システムに対してその注文商品の納期の問い合わせの対象となるその商品情報と個数情報とを送信する処理を実行し、前記在庫管理システムは、前記サーバからの納期の問い合わせにより送られてくる商品情報と個数情報とを受信する処理と、在庫データベースをアクセスし、受信した商品情報の商品についての在庫数を確認し、在庫数が足りる場合には具体的な納期を納期情報とし、在庫数が足りない場合には納期不明扱いであるという納期情報とする処理と、その納期情報を前記サーバに送信する処理と、を実行し、前記サーバの制御部は、前記在庫管理システムから納期情報を受信する処理と、前記顧客端末に対してその納期情報を通知する処理と、前記顧客端末から正式な発注を受け付けた場合にその注文情報についての商品情報と個数情報と発注相手先とを含む正式注文情報を注文データベースに記憶する処理と、を実行する。
いっぽう、前記在庫管理システムが非稼働時には、前記サーバの制御部は、前記顧客端末から受信した注文情報の商品情報に基づいて、前記標準納期データベースをアクセスして対応する商品の標準納期情報を取得し、その標準納期情報を前記顧客端末に対して通知する処理と、前記顧客端末から要求に応じて、受信した、商品情報と個数情報とを含む注文情報を滞留データとして前記滞留データ一時記憶手段に登録する処理とを実行する。その後、稼動中の在庫管理システムは、前記サーバの制御部から送られる滞留データに基づく注文情報の商品情報と個数情報を取得する処理と、在庫データベースをアクセスし、受信した商品情報の商品についての在庫数を確認し、在庫数が足りる場合には具体的な納期を納期情報とし、在庫数が足りない場合には納期不明扱いであるという納期情報とする処理と、その納期情報を前記サーバに送信する処理とを実行し、前記サーバの制御部は、稼動中の在庫管理システムからその納期情報を取得するとともに、前記注文情報と関連付けて記憶する処理と、前記顧客端末から前記注文の確認要求があった場合に前記注文情報に関連付けて記憶した納期情報を送信する処理を実行するようにした。
【００１２】
ネットワークは、実施の形態では、インターネットであるが、他のネットワークでももちろん良い。サーバは、実施の形態では「受発注サーバ１」に対応し、標準納期データベースは、実施の形態では商品データベース１１ａに対応する。このように、実施の形態では、通常の商品に関する情報を記憶するデータベースと一体にしているが、標準納期を別途管理するデータベースを構築しても良い。納期情報は、実施の形態では出荷予定日であったり、出荷予定日不明であったりする。
【００１３】
また、係る方法を実施するのに適した本発明の受注処理システムは、ネットワークに接続可能なサーバと、そのサーバと通信可能な在庫管理システムとを備え、前記ネットワークを介して顧客端末から注文を受けるオンラインによる受注システムである。そして、前記サーバは、商品についての標準納期情報を記憶する標準納期データベースと、前記顧客端末からのアクセスによって商品情報とその個数情報とを含む注文情報を受信する受信手段と、受信した注文情報を記憶する注文データベースと、前記顧客端末から受信した注文情報の商品情報と個数情報とに基づいて、前記在庫管理システムに対してその注文商品の納期の問い合わせをし、その在庫管理システムから送信されてくる納期情報を受信することで納期確認をする確認手段と、確認した納期情報をその顧客端末に対して通知する納期情報通知手段と、前記在庫管理システムの非稼働時に前記顧客端末から受信した注文情報の商品情報に基づいて前記標準納期データベースをアクセスして対応する商品の標準納期情報を取得する取得手段と、取得した標準納期情報を前記顧客端末に対して通知する標準納期情報通知手段と、標準納期情報通知手段にて標準納期情報を通知した対象の注文情報を顧客端末から要求に応じて滞留データとして滞留データ一時記憶手段に登録する登録手段と、を持つ。また、前記在庫管理システムは、商品とその商品の在庫数を関連付けた在庫情報を記憶する在庫データベースと、その在庫データベースをアクセスし前記サーバの確認手段による納期確認対象の注文情報に含まれる商品情報と個数情報、または前記滞留データに基づく注文情報に含まれる商品情報と個数情報に基づき、その商品情報の商品についての在庫数を確認し、在庫数が足りる場合には具体的な納期を納期情報とし、在庫数が足りない場合には納期不明扱いであるという納期情報とする確認手段と、確認した納期情報をサーバに送信する送信手段と、を持つ。さらに前記サーバは、前記確認手段によって確認した納期情報を、注文情報と関連づけて記憶し、前記顧客端末から前記注文の確認要求があった場合に、在庫管理システムから取得し前記注文情報に関連付けて記憶した納期情報を顧客端末に対して通知する納期情報通知手段を持つ、ようにした。
【００１６】
この発明によれば、在庫管理システムが稼働中は、在庫管理システムに問い合わせることにより、注文を受ける商品の正確な納期を知ることができ、顧客に通知することができる。また、在庫管理システムが非稼働中の場合には、標準納期データベースに格納した標準納期に基づいて顧客に対しての右記回答をすることができる。よって、顧客は、係る納期を見て、必要な商品が間に合うか否かを判断し、正式な注文をすることができる。
【００１７】
よって、サーバが稼働していれば、在庫管理システムが稼働しているか否かに関わらず納期を回答でき、それに伴う注文を受けることができる。つまり、本システムを利用する顧客は、標準納期がわからずに仮注文をし、翌日に納期を確認した場合に間に合わないことがわかり、あわてて注文のキャンセル並びに別の注文先を探すというような事態を招くということを可及的に抑制できる。販売店側も、係る事態に伴うキャンセルの発生率を抑制できる。
【００１８】
また、非稼働中であると判断する機能としては、実施の形態では「稼働フラグのＯＮ／ＯＦＦ」をチェックするようにしたが、これに限ることはなく、予め記憶保持した稼働時間（非稼働時間）の情報に基づいて判断したり、まず在庫管理システムに対して問い合わせを行い、一定時間以内に回答がない場合には、非稼働中と推定し標準納期を通知するようにすることもできる。
【００１９】
そして、在庫管理システムから、少なくとも稼働開始時と、終了時に前記サーバに通知し、前記サーバは前記通知に基づいて前記在庫管理システムが現在非稼働時か否かを判断し、その判断結果に基づいて納期の通知方法を決定するようにするとよい。ここで、通知方法の決定とは、在庫管理システムに対して納期の問い合わせをして得られた結果を通知する方法と、標準納期を通知する方法のいずれをとるかである。
【００２０】
この発明によれば、稼働中か否かが確実にわかるので好ましい。なお、稼働開始時とは、開始したその時点（直後）でもよいし、一定時間経過した後でも良い。同様に、終了時とは、その終了した時点（直前）でもよいし、終了時刻の一定時間前でもよい。つまり「時」としているが、その時点という意味ではなく、稼働開始／終了という条件を満たしたときという意味である。
【００２１】
また、終了時刻よりも少し前に終了通知を送ることにより、タイミングのずれでサーバから問い合わせが送られてきたりすることが抑制できる。また、後述するように、正式な発注が継続して送られてくるような場合に、納期問い合わせの時には在庫管理システムは稼働していたものの、最終的な正式な発注の時には在庫管理システムが停止する事態の発生も未然に防止できる。
【００２２】
なお、前記注文データベースへ登録する情報は、前記在庫管理システムに対して行った正式発注を受けて、前記在庫管理システムから返答されてきた発注結果を含むようにしてもよい。
【００２３】
さらに本発明の受注処理方法は、前記在庫システムの稼働時に前記サーバの制御部が前記顧客端末から正式な発注を受け付けた場合に、前記制御部はその注文情報を前記在庫管理システムに送信する処理を実行し、前記在庫管理システムはその注文情報に含まれた商品情報および個数情報に基づいて前記在庫データベースに対して在庫数から商品の注文個数を引当てる在庫引当処理を実行し、前記在庫システムが非稼働時においては、前記サーバの制御部は、前記顧客端末からの正式な注文を受けた際にその注文情報を滞留データ一時記憶手段に登録する処理を実行し、次いで、前記在庫管理システムは、稼働中に、前記一時記憶手段の滞留データの注文情報に含まれた商品情報および個数情報に基づいて前記在庫データベースに対して在庫数から商品の注文個数を引当てる在庫引当処理を実行するようにするとよい。
そして、係る方法を実施するために適した本発明の受注処理システムとしては、前記サーバは、前記在庫システムの稼働時においては、前記顧客端末から正式発注を受け付けた場合、その注文情報を前記在庫管理システムに送信する送信手段を持ち、前記在庫システムの非稼働時においては、前記顧客端末からの正式な注文を受けた際に前記登録手段がその注文情報を滞留データとして前記滞留データ一時記憶手段に登録するものであり、前記在庫管理システムは、２つの注文情報について前記在庫データベースに対して在庫数から商品の注文個数を引当てる在庫引当処理を実行する在庫引当処理手段を持つようにするとよい。
【００２４】
このようにすると、顧客からの商品の正式な注文に基づき、仕入れ先への自動的な発注処理ひいては仕入れ先側での在庫管理（引当）がオンラインで人手を介することなく行うことができる。
【００２８】
さらに、在庫管理システムは１つの場合もあるし、複数の場合もある。そして、複数存在する場合は、前記サーバは、注文を受けた商品に基づき、その商品に関連する在庫管理システムを決定し、その決定した在庫管理システムとの間でデータの送受を行うことにより対応できる。
【００２９】
なお、前記注文データベースへ登録する情報は、前記在庫管理システムに対して行った正式発注を受けて、前記在庫管理システムから返答されてきた発注結果を含むものである。
【００３０】
＊用語の定義
「納期」は、在庫管理システムにて在庫引き当てができ、確実に商品を届けることのできる時期をいう。システム上は、発送日，出荷日，顧客到着日，物流開始日などから選ぶことになる。つまり、必ずしも最終的に顧客に到着する時ではない。「標準納期」は、システム上の想定納期であり、予め予想している設定納期（仮の納期）である。在庫等があった場合など、通常であれば商品を届けることができる時期に基づいて設定される。
【００３１】
「注文（を受ける）」とは、「受注」としての意味である。システム上ではサーバが受信するもので、顧客端末の操作結果により行われる。「正式発注」は、納期（標準納期）を確認した顧客が、顧客端末からサーバに対して行われる正式な注文（商品購入の意思表示）の場合と、その顧客端末からの正式発注を受けたサーバが在庫管理システムに対して行う発注（在庫引き当て依頼等）がある。
【００３２】
「サーバ」は、Ｗｅｂサーバ機能を持つコンピュータ装置により実現される。また、「顧客端末」は、Ｗｅｂブラウザ機能を持つコンピュータ端末により実現される。
【００３３】
「在庫管理システムの非稼働」は、在庫管理システムが実際に動作しているか否かにかかわらず、サーバからアクセスができない状態を言う。つまり、定期的、非定期的を問わず、電源を落としている場合はもちろんのこと、メンテナンス中で外部と遮断されている場合も含む。在庫管理システム側で停電、故障等が発生している場合もある。さらには、システムが稼働中であっても、サーバ−在庫管理システム間のネットワーク異常などにより、通信ができない場合等も含む。もちろん、上記したものは、例示列挙であり、それ以外の場合も該当するものはある。
【００３４】
一方、運営上、上記した総ての場合に非稼働中の処理（標準納期回答等）をする必要はない。つまり、例えばネットワーク異常等の一部の状況においては、所定のエラー処理を実行することもできる。エラー処理としては、複数回通信を試みたり、最終的につながらない場合には、エラーメッセージを出力することもある。但し、その場合でも、標準納期を併せて出力するのが好ましい。
【００３５】
【発明の実施の形態】
図１は、本発明が適用されるシステムの一形態を示している。同図に示すよう、受発注サーバ１は、インターネット２に接続され、情報の送受ができるようになっているとともに、仕入れ先の在庫管理システム３と接続されている。そして、インターネットに接続された顧客端末４から受発注サーバ１にアクセスすることにより、受発注サーバ１は受注処理並びにそれに付随する各処理を実施するようになっている。よって、本システムは、一種のインターネットショッピングを実現するものとも言える。
【００３６】
そして、受発注サーバ１は、商品の販売店に設置されるものであり、その販売店は、顧客からの注文を受けて、仕入れ先から商品を入手し、顧客に販売するものである。在庫管理システム３は、仕入れ先に実装されるシステムであり、その仕入れ先が持つ在庫状況を管理するシステムである。つまり、各商品についての現在の在庫数はもちろんのこと、たとえ現在在庫数が０であっても、工場の生産予定などから何時出荷可能になるかなどが管理される。
【００３７】
次に、上記したシステムを用いて行われる顧客端末４からの発注から、最終的に顧客に対して商品を配送するまでの処理の流れに従って、各システムの機能の概略を説明する。まず、顧客端末４は、インターネット経由で販売店のウェブサイトにアクセスし、受発注サーバ１に接続する。受発注サーバ１の制御部１０は、会員データベース１１ｂを参照し、アクセスしてきた顧客が正規の会員か否かを判断（ＩＤ＋パスワード等）し、正規の会員でない場合には、まず会員登録を促す。そして、正規の会員であることが確認できると、実際のサービスの提供を開始する。
【００３８】
すなわち、まず、購入しようとする商品を選択させる。つまり、顧客端末４からの情報（検索条件，過去の購入履歴情報等）に基づき、商品データベース１１ａをサーチし、顧客が購入しようとする商品リストを作成し、出力表示する。そして、表示した商品リストの中から顧客が購入しようとする商品が選択されるのを待つ。もちろん、要求に応じて別の商品リストを提示することもある。
【００３９】
商品及び個数が選択されると、制御部１０は在庫管理システム３に対して納期の問い合わせを行う。この問い合わせを受けた在庫管理システム３の制御部２０は、在庫データベース２１ａをアクセスし、問い合わせのあった商品の有無及び在庫数を確認し、その商品について必要な個数を発送できる納期を回答する。なお、納期は出荷日を基準としている。
【００４０】
受発注サーバ１側の制御部１０は、在庫管理システム３からの納期回答を受けて、顧客端末４の表示画面中の各商品の欄に出荷予定日を出力表示することにより、顧客への納期回答をする。
【００４１】
顧客は、出荷予定日を確認し、問題がなければ正式な注文（発注）を行う。この発注もインターネット２を経由して受発注サーバ１の制御部１０に与えられるので、制御部１０は、在庫管理システム３に対して正式な発注を送る。さらに、受発注サーバ１並びに在庫管理システム３は、各発注を受けてそれぞれの注文データベース１１ｃ，２１ｂに注文を受けた商品，個数，相手先，出荷予定日などの情報を格納する。さらに、在庫管理システム３は、在庫データベース２１ａに対して引当処理を行う。つまり、注文を受けた商品の個数分だけ在庫数を減らす処理をする。
【００４２】
そして、本形態では、短期納入を行うため、仕入れ先から顧客に対して直送する方式をとっている。そこで、仕入れ先では、販売店からの発注を受ける（受注する）と、契約している宅配業者を使って商品の出荷を行う。この出荷処理に伴い、注文データベース２１ｂには、伝票番号などの出荷・搬送に関する情報を格納する。この情報は、発注結果として受発注サーバ１にも送られ、受発注サーバ１の注文データベース１１ｃに格納される。
【００４３】
顧客は、発注した後、受発注サーバ１にアクセスすることにより、注文した商品の現在の状況を確認することができる。つまり、係る状況問い合わせを受けた受発注サーバ１の制御部１０は、その会員の注文した商品リストを出力する。この商品リストには、現在の状況（出荷待ち（出荷予定日），出荷中など）とともに、出荷したものについては宅配便の伝票番号を表示する。さらに、画面上には、上記宅配便のホームページ（追跡調査）６にリンクが張られており、係るホームページに飛ぶことにより、顧客は、伝票番号に基づいて商品が現在どこにあるかを確認できるようになる。
【００４４】
上記した処理は、受発注サーバ１並びに在庫管理システム３がともに稼働している場合の通常の処理である。ここで本発明では、在庫管理システム３が非稼働中であっても受発注サーバ１が、商品の受注や、納期回答などができるようにしている。これにより、受発注サーバ１を２４時間稼働させることができ、顧客は、自分の都合に合わせていつでも商品の注文ができるとともに、納期の確認をすることができる。
【００４５】
具体的には、受発注サーバ１に滞留データベース１１ｄを設ける。この滞留データベース１１ｄは、在庫管理システム３が非稼働中の時に受注したデータを一時的に格納するものである。そして、在庫管理システム３が稼働した際に、この滞留データベース１１ｄに格納した仮受注データに基づいて、在庫管理システム３に対して正式な発注処理等を行う。
【００４６】
正式な発注処理を行うことにより、滞留データベース１１ｄに格納されたデータは、注文データベース１１ｃに移し替えられる。そして、在庫管理システム３からの発注結果があると、通常の処理と同様に注文データベース１１ｃに登録される。
【００４７】
在庫管理システム３が稼働中か否かの判断は、例えば予め受発注サーバ１側で稼働している時刻（例えば、ＡＭ９：００からＰＭ５：３０など）のタイムテーブルを持ち、それに基づいて受発注サーバ１の制御部１０が判断することもできるが、係るタイムテーブルの更新の煩雑さや、在庫管理システム３の臨時停止に対応することから、本形態では「稼働フラグ」を持ち、在庫管理システム３側から現在稼働中か否かの情報を受け取り、稼働フラグをＯＮ／ＯＦＦすることにより制御する。制御部１０は、この稼働フラグを確認することにより、在庫管理システム３が稼働中で通常の処理が可能か、非稼働中で滞留データベース１１ｄに格納しなければならないかなどの判断を行うようにしている。
【００４８】
更に納期については、各商品毎に標準納期を設定することにより対応している。標準納期は、通常の状態で受注した場合に、その商品を出荷するまでに要する日数である。基本的に、在庫が存在する場合には即日（翌日）出荷対応できるが、タイミングが悪く在庫切れなどを生じていることも想定し、若干余裕を持って設定している。もちろん、商品の中には受注生産のものもあり、係る場合には、受注してから生産し製造するまでに係る平均日数を求め、それらから一定のマージンをとって決めても良い。なお、受注生産品の場合には、標準納期なしとすることもできる。また、本例では、標準納期は、「Ｘ営業日後」というように表すようにしている。
【００４９】
この標準納期は、仕入れ先との取り決めにより予め各商品毎に決めておき、商品データベース１１ａに商品と関連づけて格納する。これにより、在庫管理システム３が非稼働中に顧客からの注文があった場合には、商品データベース１１ａをアクセスし、その商品の標準納期を抽出し、それを表示することにより納期回答するようにした。
【００５０】
これにより、顧客は、標準納期を見ることにより、正式に購入（発注）するか否かを判断することができる。なお、正式に発注された商品は、滞留データベース１１ｄに格納され、在庫管理システム３が稼働した際に発注するのは上記した通りであるが、この発注にともない、在庫管理システム３からその商品についての納期回答があるので、係る納期回答を受けたならば、標準納期を正式な納期（出荷予定日）に置き替える処理を行う。
【００５１】
次に、上記した処理を実行するための具体的な構成について説明する。受発注サーバ１は、図２に示すように、インターネット２に接続され、データの送受を行うための通信インタフェース１２を備えている。また、在庫管理システム３とデータの送受を行うためのインタフェース１３も備えている。受発注サーバ１と在庫管理システム３は、公衆回線，専用回線７はもちろんのこと、インターネットやＬＡＮ等の各種のネットワーク網を用いることができ、インタフェース１３は、係る使用する通信形態に応じて設定する。
【００５２】
なお、本形態の場合、受発注サーバ１は販売店のシステムで、在庫管理システム３は仕入れ先のシステムと説明したが、係る場合のＬＡＮの利用形態としては、受発注サーバ１と在庫管理システム３を同一の場所に設置することにより対応できる。つまり、別会社であっても場所を共有することによりＬＡＮ接続は可能となる。
【００５３】
制御部１０は、会員管理処理部１０ａと、受発注処理部１０ｂと、滞留データ処理部１０ｃを備えている。まず、会員管理処理部１０ａは、会員データベース１１ｂへのデータ登録，更新処理などを行うものである。つまり、会員データベース１１ｂは、会員番号（会員ＩＤ），名前，会社名，所属，住所，電子メールアドレス，パスワード，電話・ＦＡＸ番号などを関連づけて格納するようになっている。
【００５４】
そこで、会員管理処理部１０ａは、例えば図３に示すような新規会員登録画面を顧客端末４のモニタ上に出力表示させ（実際には、図示の下にも各種のデータを入力領域がある）、会員登録を促す。そして、入力されたデータを取得し、「必須項目が入力されているか」、「文字数，使用可能な文字種類は正しいか」などの判断を行い、問題がない場合には図４に示すような確認画面を出力し、内容に間違いがないか否かを確認させる。
【００５５】
そして、「送信」キーが選択されたならば、内容に間違いなしと判断し、会員番号（会員ＩＤ）を発行し、その会員ＩＤとともに入力された情報を会員データベース１１ｂに登録する。また、同時に、顧客端末４のモニタ画面に対しては、例えば図５に示すような登録完了通知とともに会員ＩＤを通知するメッセージを出力する。
【００５６】
上記した以外にも、既登録の会員情報の内容に変更があった場合には、更新処理を行う機能も持つ。要は、通常のオンラインでの会員登録処理と同様の処理を行うものである。
【００５７】
受発注処理部１０ｂは、図６，図７に示すフローチャートを実施する機能を持つ。同図に示すように、まず顧客端末４からのアクセスがあると、正規の会員か否かを判断する（ＳＴ１）。すなわち、最初に会員ＩＤとパスワードの入力を受けるようにしているため、入力された会員ＩＤとパスワードの組み合わせがあっているか否かを判断する。
【００５８】
そして、非会員の場合には、所定の処理を実行する（ＳＴ２）。この所定処理としては、エラーメッセージとともにパスワード，会員ＩＤの再入力を促したり、新規登録画面へ飛ぶようにすることなどがある。
【００５９】
一方、正規の会員と判断されると、商品選択処理を行う（ＳＴ３）。つまり、商品の検索画面（図示省略）を表示する。この検索画面は、商品を絞り込むための条件の入力画面であり、例えば、商品の種類，商品名，商品コードなどを入力する。この入力を受けて該当する商品リストを表示する。そして、その商品リストを見た顧客は、自己が必要とする（注文しようとした）ものであるか否かを判断し、必要な場合には選択するとともに数量を入力する。
【００６０】
この入力に基づき、図８に示すような買い物かご画面を表示する。つまり、選択した商品の数量に基づき総金額を算出し、コード，商品名，数量，単価，金額を関連づけて表示する。図から明らかなように、画面の下方領域には、商品の追加を行うための「買い物を続ける」キーと、注文を停止する「買い物をやめる」キーと、納期を確認するための「納期確認」キーが用意されている。
【００６１】
そして、「買い物を続ける」キーをクリックすると、商品の検索・選択画面に進み、「買い物をやめる」キーをクリックすると、今まで選択し、買い物かごに登録した商品をクリアし、今回の注文処理を終了する。従って、必要なものが集まるまで「買い物を続ける」キーを押して逐次商品とその数量を選択する。
【００６２】
必要な商品の選択が終了したならば、「納期確認」キーがクリックされる（ＳＴ４でＹｅｓ）ので、それを検知すると稼働フラグのチェックを行う（ＳＴ５）。
【００６３】
すでに説明したように、稼働フラグは、在庫管理システム３から送られてくる通知に従ってＯＮ／ＯＦＦを切り替えるもので、在庫管理システム３が稼働中は稼働フラグもＯＮになるように制御されている。具体的には、在庫管理システム３の制御部２０が、稼働開始直後に「開始通知」を送ってくるので、その開始通知を受けると、稼働フラグをＯＮにする。また、在庫管理システム３が停止する所定時間前（例えば５分前）に「終了通知」を送ってくるので、その終了通知を受けると稼働フラグをＯＦＦにする。
【００６４】
そこで、このステップ５の処理では、係る稼働フラグをサーチし、ＯＮか否かを判断する。そして、ＯＦＦの場合には、非稼働時処理を実施する。この非稼働時処理は、滞留データ処理部１０ｃが実施するもので、具体的な処理は後述する。
【００６５】
一方、稼働フラグがＯＮの時には、在庫管理システムに対してオンラインでの問い合わせや注文が行えるので、ステップ６に進み、在庫管理システムへ納期の問い合わせを行う。つまり、商品を特定するコードと数量とともに納期確認（仮発注）を行う。なお、販売店側と仕入れ先では、同一の商品について付している商品コードが異なる場合が多々ある。特に、後述するように仕入れ先が複数存在する場合にはなおさらである。そこで、商品データベース１１ａには、仕入れ先の商品コード情報も併せて格納しておき、この処理ステップを実行するに際し、商品コードの変換、つまり、仕入れ先（在庫管理システム３）で扱っている商品コードを抽出し、それを出力する。
【００６６】
後述するように、在庫管理システム３は、問い合わせを受けた商品についての出荷予定日を通知（納期回答）してくるので、係る納期回答を待つ（ＳＴ７）。そして、係る納期回答に従って、顧客端末４のモニタに対し、納期確認画面（図９参照）を表示する（ＳＴ８）。図から明らかなように、在庫管理システム３から通知された出荷予定日を表示する。なお、在庫切れなどにより出荷予定日が不明であることを通知された場合には、この納期確認画面における出荷予定日は「＊＊＊」としている。
【００６７】
さらに、画面の下方には、会員データベース１１ｂに登録された会員の住所を表示するとともに、更に送付先が異なる場合に臨時の送付先を入力する画面を用意している。
【００６８】
この画面の下端領域には、表示内容で注文する「注文確認」キーと、注文した商品が全てそろったときにまとめて出荷することを要求する「最終出荷日にあわせて注文する」キーと、表示内容では注文をしない「戻る」キーを用意する。
【００６９】
次に、正式な注文を受けたか否かを判断する（ＳＴ９）。すなわち、図９に示した納期確認画面において、「注文確認」キー或いは「最終出荷日にあわせて注文する」キーがクリックされた場合には、この分岐判断はＹｅｓとなり、「戻る」キーがクリックされたならばＮｏとなる。そして、Ｎｏの場合には、ステップ３に戻り買い物かご画面へ戻る。
【００７０】
正式発注があると、商品発注画面を表示する（ＳＴ１０）。つまり、図１０に示すように、注文した商品情報（商品名，個数，金額，出荷予定日等）とともに確定した商品の発送先住所や支払方法を表示する。更に、この表示画面の下端には、「送信」キーと「戻る」キーを用意している。「戻る」キーがクリックされると、ステップ８の納期確認画面表示に戻り、「送信」キーがクリックされる（ステップ１１でＹｅｓ）と、正式発注処理を行う（ＳＴ１２）。つまり、ステップ１０で表示した内容を在庫管理システム３へ送信し、正式発注を行う。
【００７１】
この後、在庫管理システム３からは、発注結果が送られてくるので、それを待つ（ＳＴ１３）。そして、発注結果が送られてくると、顧客端末４のモニタに注文完了画面（図１１参照）を表示する（ＳＴ１４）。
【００７２】
また、サーバ用の注文データが作成され、注文データベース１１ｃに格納する（ＳＴ１５）。注文データとしては、顧客の正式注文に関する情報で、通販コード，商品名，数量等の情報と顧客情報を含む。さらに、在庫管理システム側の注文データと関連付ける照会番号も含む。在庫管理システム３への発注データにもなる。顧客注文が確定された情報となる。
【００７３】
次に、滞留データ処理部１０ｃの機能を説明する。滞留データ処理部１０ｃは、在庫管理システム３が非稼働時のときに仮の受注処理をして貯留データベース１１ｄに登録する機能（図６中の非稼働時処理を実行する機能）と、滞留データベース１１ｄに格納されたデータに基づき、正式な発注処理を行う機能を有する。
【００７４】
まず、前者の機能は、図１２に示すフローチャートのようになる。稼働フラグがＯＦＦの時に、ステップ３の処理により確定された商品に対し、商品データベース１１ａをアクセスし、その商品の標準納期を取得する（ＳＴ２１）。そして、顧客端末４のモニタに対し、納期確認画面を表示する（ＳＴ２２）。納期確認画面は、図９に示すものと同様で、出荷予定日の欄が「Ｘ営業日後」（Ｘは標準納期）となる。出荷予定日の表示以外は通常のものと同様である。従って、顧客は稼働時／非稼働時のどちらでも違和感無く対処できる。この点は、以下の各処理でも同様である。
【００７５】
次に、正式な注文を受けたか否かを判断する（ＳＴ２３）。すなわち、図９に示した納期確認画面において、「注文確認」キー或いは「最終出荷日にあわせて注文する」キーがクリックされた場合には、この分岐判断はＹｅｓとなり、「戻る」キーがクリックされたならばＮｏとなる。そして、Ｎｏの場合には、ステップ３に戻り買い物かご画面へ戻る。
【００７６】
正式発注があると、商品発注画面を表示する（ＳＴ２４）。つまり、図１０に示すように、注文した商品情報（商品名，個数，金額，出荷予定日等）とともに確定した商品の発送先住所や支払方法を表示する。更に、この表示画面の下端には、「送信」キーと「戻る」キーを用意している。「戻る」キーがクリックされると、ステップ２２の納期確認画面表示に戻り、「送信」キーがクリックされる（ステップ２５でＹｅｓ）と、顧客端末４のモニタに注文完了画面を表示する（ＳＴ２６）。この注文完了画面も、基本的に図１１と同様であり、異なるのは出荷予定日の表示が「Ｘ営業日後」となっている点である。そして、注文を受けた内容（顧客情報，商品，個数、送付先等の情報）を滞留データベース１１ｄに格納し、処理を終了する（ＳＴ２７）。
【００７７】
一方、滞留データベース１１ｄに格納されたデータに基づき、正式な発注処理を行う機能は、図１３に示すフローチャートのようになる。すなわち、在庫管理システム３から開始通知を受けたり、或いは、稼働フラグがＯＮになったのを確認した（ＳＴ３１）ならば、滞留データベース１１ｄをサーチし、稼働フラグがＯＮになった在庫管理システム３に対する滞留データがあるか否かを判断する（ＳＴ３２）。そして、無い場合には処理を終了し、滞留データが存在したならば、滞留データ処理を開始する。
【００７８】
滞留データ処理は、基本的には、蓄積されている滞留データ、つまり、仮受注した商品を正式に発注するものである。このとき、滞留データベース１１ｄに大量にデータが蓄積されている場合に、そのデータを一度に在庫管理システム３側に送ると、在庫管理システム３側の付加が大きくなりすぎるので、所定時間当たりに処理する件数を定め、分散して行う。
【００７９】
つまり、予め定めた件数分の受注データを読み出し、在庫管理システムの商品コードを取得して置き替える（ＳＴ３３，ＳＴ３４）。そして、その置き替えた商品コードに基づく発注データを作成し、在庫管理システム３へ送信し、正式な発注処理を行う（ＳＴ３５）。
【００８０】
この発注処理を受けた在庫管理システム３からは、発注結果が送られてくるので、それを待つ（ＳＴ３６）。そして、発注結果が送られてくると、注文データベース１１ｃに格納する（ＳＴ３７）。これにより、正確な出荷予定日がわかる。
【００８１】
さらに本形態では、注文状況の確認を行うことができるようになっている。すなわち、顧客端末４から受発注サーバ１に対して注文状況の確認要求があると、注文データベース１１ｃをアクセスし、会員ＩＤをキーにしてその会員の注文データを抽出し、顧客端末４のモニタに注文状況結果を表示する機能を持つ。この注文状況結果の一例としては、図１４に示すようになる。図から明らかなように、未出荷のものに付いては出荷予定日が表示され、出荷済のものには、宅配便の伝票番号が表示される。これにより、顧客は伝票番号から現在商品がどこにあるかを知ることができる。また、夜間などに注文した場合には、翌日などにこの注文状況の確認を行うと、正確な納期がわかる。
【００８２】
一方、在庫管理システム３の制御部２０は、図１５に示すフローチャートのように機能する。すなわち、納期問い合わせを受信すると、依頼のあった商品コードと数量を認識し、在庫データベース２１ａをアクセスして在庫状況を確認する（ＳＴ４０〜ＳＴ４２）。そして、在庫がある場合には出荷予定日を把握し、その結果を送信する（ＳＴ４３，ＳＴ４４，ＳＴ４６）。また、在庫がない場合には、出荷予定日不明扱いとし「＊＊＊」を返す（ＳＴ４５，ＳＴ４６）。
【００８３】
また、正式の発注（商品コード＋数量）を受けると、在庫データベース２１ａに対して該当する数量分だけ在庫の引当処理を行う（ＳＴ４７，ＳＴ４８）。次いで、在庫管理システム用の注文データを作成し、注文データベース２１ｂに登録する（ＳＴ４９）。ここで作成される注文データは、結果として受注サーバ１で作成され注文データベース１１ｃに格納された注文データと同じような内容となる。在庫引き当て済みの注文受け付け情報となる（在庫引き当て分を含むこともある）。
さらに、この注文データは、発注結果（出荷予定日，伝票番号等も含む）として受発注サーバ１側に送信される（ＳＴ５０）。
【００８４】
上記した処理によれば、受発注処理部１０ｂ，貯留データ処理部１０ｃからの処理の何れにも対応できる。また、それぞれ個別に対応するシステムにする場合には、例えば、受発注処理部１０ｂに対しては、正式な注文の前に納期問い合わせがあるので、その後に行われる正式な注文があった場合には、数量など受けることなく（納期問い合わせの際に受け取った数量）在庫引当処理をすることができる。また、納期問い合わせに対する回答として予定出荷日を教えているので、正式な注文を受けた際の発注回答としては、予定出荷日の通知を省略するようにしても良い。
【００８５】
図１６は、本発明の第２の実施の形態を示している。上記した実施の形態では、在庫管理システム３は１つであったが、本実施の形態では複数存在する点で相違する。説明の便宜上、受発注サーバ１は、２つの在庫管理システム３′，３″と接続されるようにしたが、３つ以上でももちろん良い。また、各在庫管理システム３，３′との接続媒体であるが、一方を公衆回線とし、他方をインターネットとする等、異ならせてももちろん良い。
【００８６】
係る構成において、受発注サーバ１側では商品データベース１１ｂに登録する情報として、上記した第１の実施の形態のものに加え、さらに、発注する在庫管理システムを特定する情報を入れている。すなわち、ある商品についての仕入れ先を１つに割り付けるようにしている。
【００８７】
一方、各在庫管理システム３′，３″は、ともに第１の実施の形態における在庫管理システム３と同様の構成からなり、稼働フラグＯＮ／ＯＦＦを制御するための「開始通知」並びに「終了通知」を行う機能と、図１５に示すフローチャートを実施する機能などを備えている。つまり、受発注サーバ１から納期問い合わせがあると、該当する商品の納期を返答し、正式な注文を受けると、在庫データベース２１ａに対する引当処理並びに注文データベース２１ｂへの登録及び発注結果の送信などを行う。
【００８８】
これにより、受発注サーバ１は、顧客からの注文に伴い、商品データベース１１ａをアクセスし、その商品の仕入れ先（在庫管理システム）を認識する。そして、以後の処理は、認識した仕入れ先との間で第１の実施の形態で説明した各種処理を実行することにより動作する。
【００８９】
また、顧客から複数種の商品を指定された場合に、各商品が別々の仕入れの場合には、仕入れ先ごとに納期問い合わせや正式な発注処理を行うことになる。ところで、１回の注文で複数の仕入れ先の商品が選択され、しかも、その複数の仕入れ先が非稼働中のものと稼働中のものが混在する場合は、稼働中のものはオンラインで納期の問い合わせを行って納期回答をするとともに、非稼働中のものに対しては標準納期を回答するようにすると良い。また、正式な発注も、稼働中のものはそのまま正式な発注処理を行い、非稼働中のものに対しては稼働した際に改めて正式な発注を行うようにすることもできる。
【００９０】
また、一部でも非稼働中のものが存在した場合には、全て標準納期を答えるようにし、翌日一斉に正式な注文をするように運用することもできる。さらには、問い合わせだけは、稼働中のものに対してはリアルタイムに行い、正式な発注は翌日にするなど、各種の対応が採れる。
【００９１】
但し、対顧客で考えた場合には、１つの注文としてとらえられるので、非稼働中のものを含む場合には、一旦貯留データベース１１ｄに格納するのがよい。そして、稼働中のものに対しては先に正式な発注を行うようにした場合には、貯留データベース１１ｄに格納する際に、発注済であることを示すフラグなどを立てる。これにより、翌日の正式な発注処理をするに際し、上記フラグのたっていないものに対してのみ処理をすれば良くなる。なお、その他の構成並びに作用効果は、上記した第１の実施の形態と同様であるので、対応する部材に同一符号を付し、その詳細な説明を省略する。
【００９２】
さらにまた、仕入れ先が複数存在している場合において、そのうちの一部の仕入れ店がオンラインによる自動受発注に対応していないケースもある。係る場合には、オンライン対応していない仕入れ先は、在庫管理システムが常に非稼働中であるとし、係る仕入れ先の商品については、標準納期で回答することにより本システムで対処できる。
【００９３】
図１７は、本発明の第３の実施の形態を示している。本実施の形態では、販売店側の受発注サーバ１，１′が複数存在している場合に適用した例である。すなわち、顧客がインターネット経由で注文できない場合に、顧客に代わって販売店側でデータの入力を行うものである。つまり、インターネットショッピングと、従来の人を介して受発注サーバを混在したものに適したシステムである。
【００９４】
一方の受発注サーバ１は、上記した各実施の形態と同様である。そして、他方の受発注サーバ１′は、ＬＡＮなどで接続された入力装置３０からの入力に従い、受発注を行うもので、仕入れ先が自動的な受発注に対応しているものに対しては、入力装置３０を介して受発注サーバ１′に登録したデータを、受発注サーバ１に送り、そこにおいて所定の処理を実行する。そして、その処理の結果の回答は、受発注サーバ１′に送られてくるので、その結果を顧客に伝達し、正式に発注して良いか否かの判断を行う。
【００９５】
そして、両受発注サーバ１，１′は、内容の同一性が確保される必要がある。そこで、一定の時間間隔ごとに現在の状況を相手に渡し、受け取った側ではコピーすることにより、同一性を担保する。なお、その他の構成並びに作用効果は、上記した第１の実施の形態と同様であるので、対応する部材に同一符号を付し、その詳細な説明を省略する。
【００９６】
【発明の効果】
以上のように、この発明では、在庫管理システムと連携して顧客からの受注処理並びに納期回答などを行うシステムにおいて、在庫管理システムが非稼働時であっても各種処理を行うことができ、究極には、２４時間体制でサービスの提供を行うことのできる受注システム及び受注処理方法並びにサーバを提供することを目的とする。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態を示す図である。
【図２】本発明の第１の実施の形態を示す図である。
【図３】新規会員登録画面の一例を示す図である。
【図４】新規会員登録確認画面の一例を示す図である。
【図５】登録確認画面の一例を示す図である。
【図６】受発注処理部の機能を示すフローチャートの一部である。
【図７】受発注処理部の機能を示すフローチャートの一部である。
【図８】受発注処理部の機能を説明する図である。
【図９】受発注処理部の機能を説明する図である。
【図１０】受発注処理部の機能を説明する図である。
【図１１】受発注処理部の機能を説明する図である。
【図１２】貯留データ処理部の機能を示すフローチャートの一部である。
【図１３】貯留データ処理部の機能を示すフローチャートの一部である。
【図１４】状況確認画面の一例を示す図である。
【図１５】在庫管理システムにおける制御部の機能を示すフローチャートの一部である。
【図１６】本発明の第２の実施の形態を示す図である。
【図１７】本発明の第３の実施の形態を示す図である。
【符号の説明】
１，１′ 受発注サーバ
２ インターネット
３ 在庫管理システム
４ 顧客端末
６ ホームページ
７ 通信網
１０ 制御部
１０ａ 会員管理処理部
１０ｂ 受発注処理部
１０ｃ 貯留データ処理部
１１ａ 商品データベース
１１ｂ 会員データベース
１１ｃ 注文データベース
１１ｄ 滞留データベース
１２ 通信インタフェース
１３ インタフェース
２０ 制御部
２１ａ 在庫データベース
２１ｂ 注文データベース
３０ 入力装置

Claims (4)

1. ネットワークに接続可能でかつ制御部と標準納期データベースと注文データベースと滞留データ一時記憶手段とを持つサーバと、そのサーバと通信可能でかつ在庫データベースを持つ在庫管理システムとを備え、前記ネットワークを介して顧客端末から注文を受けるオンラインによる受注システムにおける受注処理方法であって、
   前記サーバの標準納期データベースは商品についての標準納期情報を、前記注文データベースは受けた注文情報を、前記在庫管理システムの在庫データベースは商品とその商品の在庫数を関連付けた在庫情報を、それぞれ記憶するものであり、
   前記サーバの制御部は、前記顧客端末からのアクセスによって商品情報とその個数情報とを含む注文情報を受信する処理と、その顧客端末に対して納期情報を通知する処理とを行うものであり、
   前記在庫管理システムの稼動中は、
   前記サーバの制御部は、前記顧客端末から受信した注文情報の商品情報と個数情報とに基づいて、前記在庫管理システムに対してその注文商品の納期の問い合わせの対象となるその商品情報と個数情報とを送信する処理を実行し、
   前記在庫管理システムは、前記サーバからの納期の問い合わせにより送られてくる商品情報と個数情報とを受信する処理と、在庫データベースをアクセスし、受信した商品情報の商品についての在庫数を確認し、在庫数が足りる場合には具体的な納期を納期情報とし、在庫数が足りない場合には納期不明扱いであるという納期情報とする処理と、その納期情報を前記サーバに送信する処理と、を実行し、
   前記サーバの制御部は、前記在庫管理システムから納期情報を受信する処理と、前記顧客端末に対してその納期情報を通知する処理と、前記顧客端末から正式な発注を受け付けた場合にその注文情報についての商品情報と個数情報と発注相手先とを含む正式注文情報を注文データベースに記憶する処理と、を実行し、
   いっぽう、前記在庫管理システムが非稼働時には、
   前記サーバの制御部は、前記顧客端末から受信した注文情報の商品情報に基づいて、前記標準納期データベースをアクセスして対応する商品の標準納期情報を取得し、その標準納期情報を前記顧客端末に対して通知する処理と、前記顧客端末から要求に応じて、受信した、商品情報と個数情報とを含む注文情報を滞留データとして前記滞留データ一時記憶手段に登録する処理とを実行し、
   その後、稼動中の在庫管理システムは、前記サーバの制御部から送られる滞留データに基づく注文情報の商品情報と個数情報を取得する処理と、在庫データベースをアクセスし、受信した商品情報の商品についての在庫数を確認し、在庫数が足りる場合には具体的な納期を納期情報とし、在庫数が足りない場合には納期不明扱いであるという納期情報とする処理と、その納期情報を前記サーバに送信する処理とを実行し、前記サーバの制御部は、稼動中の在庫管理システムからその納期情報を取得するとともに、その取得した納期情報を前記注文情報と関連付けて記憶する処理と、前記顧客端末から前記注文の確認要求があった場合に前記注文情報に関連付けて記憶した納期情報を送信する処理を実行する
   ことを特徴とする受注処理方法。
2. 前記在庫システムの稼働時に前記サーバの制御部が前記顧客端末から正式な発注を受け付けた場合に、前記制御部はその注文情報を前記在庫管理システムに送信する処理を実行し、前記在庫管理システムはその注文情報に含まれた商品情報および個数情報に基づいて前記在庫データベースに対して在庫数から商品の注文個数を引当てる在庫引当処理を実行し、
   前記在庫システムが非稼働時においては、前記サーバの制御部は、前記顧客端末からの正式な注文を受けた際にその注文情報を滞留データ一時記憶手段に登録する処理を実行し、次いで、前記在庫管理システムは、稼働中に、前記一時記憶手段の滞留データの注文情報に含まれた商品情報および個数情報に基づいて前記在庫データベースに対して在庫数か ら商品の注文個数を引当てる在庫引当処理を実行するものである
   ことを特徴とする請求項１に記載の受注処理方法。
3. ネットワークに接続可能なサーバと、そのサーバと通信可能な在庫管理システムとを備え、前記ネットワークを介して顧客端末から注文を受けるオンラインによる受注システムであって、
   前記サーバは、
   商品についての標準納期情報を記憶する標準納期データベースと、
   前記顧客端末からのアクセスによって商品情報とその個数情報とを含む注文情報を受信する受信手段と、
   受信した注文情報を記憶する注文データベースと、
   前記顧客端末から受信した注文情報の商品情報と個数情報とに基づいて、前記在庫管理システムに対してその注文商品の納期の問い合わせをし、その在庫管理システムから送信されてくる納期情報を受信することで納期確認をする確認手段と、
   確認した納期情報をその顧客端末に対して通知する納期情報通知手段と、
   前記在庫管理システムの非稼働時に前記顧客端末から受信した注文情報の商品情報に基づいて前記標準納期データベースをアクセスして対応する商品の標準納期情報を取得する取得手段と、
   取得した標準納期情報を前記顧客端末に対して通知する標準納期情報通知手段と、
   標準納期情報通知手段にて標準納期情報を通知した対象の注文情報を顧客端末から要求に応じて滞留データとして滞留データ一時記憶手段に登録する登録手段と、
   を持ち、
   前記在庫管理システムは、
   商品とその商品の在庫数を関連付けた在庫情報を記憶する在庫データベースと、
   その在庫データベースをアクセスし前記サーバの確認手段による納期確認対象の注文情報に含まれる商品情報と個数情報、または前記滞留データに基づく注文情報に含まれる商品情報と個数情報に基づき、その商品情報の商品についての在庫数を確認し、在庫数が足りる場合には具体的な納期を納期情報とし、在庫数が足りない場合には納期不明扱いであるという納期情報とする確認手段と、
   確認した納期情報をサーバに送信する送信手段と、を持ち、
   前記サーバは、前記確認手段によって確認した納期情報を、注文情報と関連づけて記憶し、前記顧客端末から前記注文の確認要求があった場合に、在庫管理システムから取得し前記注文情報に関連付けて記憶した納期情報を顧客端末に対して通知する納期情報通知手段を持つ、
   ことを特徴とする受注システム。
4. 前記サーバは、
   前記在庫システムの稼働時においては、前記顧客端末から正式な発注を受け付けた場合、その注文情報を前記在庫管理システムに送信する送信手段を持ち、
   前記在庫システムの非稼働時においては、前記顧客端末からの正式な注文を受けた際に前記登録手段がその注文情報を滞留データとして前記滞留データ一時記憶手段に登録するものであり、
   前記在庫管理システムは、２つの注文情報について前記在庫データベースに対して在庫数から商品の注文個数を引当てる在庫引当処理を実行する在庫引当処理手段を持つ
   ことを特徴とする請求項３に記載の受注システム。

Images