JP2001283060A

JP2001283060A - 受注処理装置、受注処理システム及び記録媒体

Info

Publication number: JP2001283060A
Application number: JP2000096254A
Authority: JP
Inventors: Madoka Matsuda; まどか松田; Osamu Seyama; 修瀬山
Original assignee: FARUMA MINAMI OSAKA KK
Current assignee: FARUMA MINAMI OSAKA KK
Priority date: 2000-03-31
Filing date: 2000-03-31
Publication date: 2001-10-12

Abstract

(57)【要約】【課題】本発明は、受注処理装置に関し、商品の在庫が
ない状態であっても当該商品の発注の入力を許容するこ
とを目的とする。【解決手段】受注処理装置（受注サーバ）１はコンピ
ュータ（クライアント）４からの商品の発注を受注す
る。受注処理装置１は、商品の在庫がない状態でコンピ
ュータ４からの商品の発注の入力を許容し、その発注の
入力についての情報を品切れ情報として保持し、また、
当該発注の入力について商品が引き当てられない場合に
その発注を保持するか否かの問い合わせをコンピュータ
４に返信する。受注処理装置１は、コンピュータ４から
前記問い合わせに対してその発注を保持する指示入力が
あった場合に、その発注を発注残情報として保持する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、受注処理装置、受
注処理システム及び記録媒体に関し、特に、商品の在庫
がない状態であっても当該商品の発注を許容する受注処
理装置、受注処理システム及び記録媒体に関する。

【０００２】

【従来の技術】インターネットの発達により、これを利
用した商取引（電子商取引）が盛んに行われるようにな
っている。その一形態として、問屋等が設置したサーバ
（受注サーバ又は受注処理装置）と小売店が設置したク
ライアントとの間においてインターネットを介して受注
処理を行う受注処理システムがある。

【０００３】このようなシステムにおいては、例えば、
クライアントは、受注サーバに対して、所望の商品の在
庫の有無を照会する。これに応じて、受注サーバは当該
商品の在庫の有無についての情報（在庫情報）を、当該
クライアントに返信する。この在庫情報を見たクライア
ントは、受注サーバに対して、当該商品を発注する。受
注サーバはこのクライアントからの発注を受注する。即
ち、受注サーバは、発注された数量だけ当該商品の在庫
から差し引き（当該数量を当該受注に割り当て）、受注
データを作成する。これにより、発注され受注された当
該商品の当該数量が、実際の商品として確保され、当該
クライアントに対して送られる。

【０００４】

【発明が解決しようとする課題】前述の受注処理システ
ムにおいては、その信頼性を高めるために、クライアン
トの発注を一旦受注サーバが受注したら確実に当該商品
等が確保されるようにしている。換言すれば、商品の在
庫がある場合には当該在庫について二重に受注すること
を防止し、かつ、在庫がない場合には当該発注を受注し
ないようにしている。

【０００５】具体的には、図１４（Ａ）に示す受注処理
システムにおいて、図１４（Ｂ）に示すように、在庫照
会それ自体を制限している（排他制御している）。即
ち、受注サーバＳに対して、ネットワークＮＷを介し
て、複数のクライアントＣ１、Ｃ２、Ｃ３、・・・か
ら、同一の商品Ａについての在庫照会が、略同時に行わ
れる場合がある。この場合、受注サーバＳは、最先に在
庫照会したクライアントＣ１からの在庫照会（及びこれ
に続く発注）の処理のみを受け付けて、当該処理の終了
まで他のクライアントＣ２、Ｃ３、・・・からの在庫照
会を受け付けない（排他制御する）。即ち、クライアン
トＣ１には在庫情報を返信し、クライアントＣ１が当該
商品を発注するとこれを受注する。一方、他のクライア
ントＣ２、Ｃ３、・・・には在庫情報が返信されず、従
って、これらはクライアントＣ１からの要求についての
処理が終了するまで待ち状態とされる。

【０００６】従って、例えば、商品Ａについてｎ個の在
庫がある場合において、クライアントＣ１からのｎ個の
発注を受注すると、これにより在庫していた全ての商品
が当該受注に割り当てられる。この結果、クライアント
Ｃ１についての在庫照会及び発注の処理の終了後に、在
庫照会が可能となったクライアントＣ２が在庫照会する
と在庫「０」と言う在庫情報を受信し、受注サーバＳは
在庫「０」に基づいてその時点以後の当該商品について
の発注を許容しない（クライアントＣ３、・・・につい
ても同様である）。

【０００７】又は、図１４（Ｃ）に示すように、在庫照
会は制限しない（排他制御しない）が、商品の受注を制
限している（排他制御している）。即ち、前述の図１４
（Ａ）の受注処理システムにおいて、受注サーバＳは、
クライアントＣ１、Ｃ２、Ｃ３、・・・からの在庫照会
をその先後にかかわらず受け付けて在庫情報をこれらに
返す。しかし、例えば、これらのうちで最先にクライア
ントＣ１が当該商品を発注したとすると、これのみを受
注し、当該商品を割り当てる。即ち、クライアントＣ１
からの発注の処理のみを受け付けて、当該処理の終了ま
で他のクライアントＣ２、Ｃ３、・・・からの発注を受
け付けない（排他制御する）。具体的には、クライアン
トＣ１が当該商品を発注するとこれを受注し、当該商品
を割り当てる。一方、他のクライアントＣ２、Ｃ３、・
・・には、クライアントＣ１に当該商品を割り当てた時
点で、新たな在庫情報が送信される。

【０００８】従って、例えば、前述したように、商品Ａ
についてｎ個の在庫がある場合において、クライアント
Ｃ１からのｎ個の発注を受注すると、これにより在庫し
ていた全ての商品が当該受注に割り当てられる。この結
果、在庫照会中の他のクライアントＣ２には在庫「０」
と言う在庫情報が返信される。この後、クライアントＣ
１についての発注の処理の終了後に、発注が可能となっ
た他のクライアントＣ２が発注しようとするが、受注サ
ーバＳは在庫「０」に基づいてその時点以後の当該商品
についての発注を許容しない（クライアントＣ３、・・
・についても同様である）。

【０００９】このため、前述の受注処理システムにおい
ては、以下のような種々の問題が発生している。

【００１０】即ち、クライアントの側から見ると、自己
が在庫照会を入力しても在庫の有無が不明のまま強制的
に待ち状態とされてしまうか、又は、自己が在庫を確認
している最中に強制的に在庫が「０」となってしまう。
従って、その後は当該商品について発注ができなくなっ
てしまい、不便である。むしろ、クライアントにとって
は、取引の便宜の観点からは、この時点では商品を割り
当てられなくてもその後に確実に当該商品を確保できる
なら、この時点で受注してもらった方が便利である。即
ち、受注サーバにおいて二重割り当て（及び受注）が防
止されており、その時点で受注したと（入手までの時間
やサービスの内容において）同様に商品を入手できるな
らば、受注の時点で商品が割り当てられないことは、ク
ライアントにとって何ら問題ではない。そして、二重引
当の防止、入手までの時間、サービスの内容等は、受注
サーバの側で対処すべき問題である。

【００１１】また、クライアントの側から見ると、当該
商品の在庫がない場合、在庫照会又は発注処理の排他制
御により、自己の発注が受注サーバにより受け付けられ
ない。この状態はその後に当該商品が入荷するまで続
く。しかし、クライアントにとって当該商品が本当に発
注したいものであれば、再度、在庫照会及び発注を（そ
れらが受け付けられるまで）繰り返さなければならな
い。また、当該商品の入荷の時期を見計らって在庫照会
及び発注をしなければならず、煩わしい。この点から
も、クライアントにとっては、在庫の有無とは無関係
に、自己の入力の時点で受注してもらった方が便利であ
る。

【００１２】受注サーバの側から見ると、当該商品の在
庫がない場合には発注が入力されないので、マーケティ
ングの観点から最も重要な情報の１つである「どの商品
の在庫がどの程度足りない」と言う情報（品切れ情報）
が得られない。即ち、単に在庫が「０」になった場合
と、在庫「０」において更に発注がある場合との区別が
できない。品切れ情報は、在庫「０」の後における更な
る発注であるから、当該商品の潜在需要（いわゆる売れ
筋）を示す。品切れ情報がない状態では、売り上げ情報
（受注の実績）は、顧客のニーズを正確には反映してい
ない。即ち、（売り上げ情報）＋（品切れ情報）が当該
商品の売れ行きの実情を示す。従って、受注サーバにと
っては、品切れ情報を蓄積できることが望ましい。

【００１３】また、受注サーバの側から見ると、在庫照
会又は発注処理の排他制御のためには当該処理をクライ
アント毎に管理する必要があるため、その処理プログラ
ムが複雑になる。即ち、在庫照会及び発注の先後をクラ
イアント毎に判断しなければならず、また、待ち状態の
クライアントを管理して当該待ち状態の解除の際にその
時点における（他のクライアントからの要求の処理結果
に応じた）適切な応答をしなければならない。

【００１４】本発明は、商品の在庫がない状態であって
も当該商品の発注を許容する受注処理装置を提供するこ
とを目的とする。

【００１５】また、本発明は、商品の在庫がない状態で
あっても当該商品の発注を許容する受注処理システムを
提供することを目的とする。

【００１６】また、本発明は、上述のような受注処理装
置を実現するプログラムを記録する記録媒体を提供する
ことを目的とする。

【００１７】

【課題を解決するための手段】本発明による受注処理装
置は、商品を発注するコンピュータとネットワークを介
して接続され、コンピュータからの商品の発注を受注す
る。この受注処理装置は、商品の在庫がない状態でコン
ピュータからの当該受注処理装置に対する当該商品の発
注を許容する。

【００１８】本発明の受注処理装置によれば、商品の在
庫がない状態であっても当該商品の発注を許容する。従
って、あるクライアントがある商品の在庫を確認してい
る途中で他のクライアントの当該商品の発注により在庫
が「０」となっても、その後も続けて当該商品について
発注ができる。従って、クライアントにとっては、自己
が発注をした時点で受注してもらうことができ、在庫照
会及び発注を繰り返す必要がなく、便利である。また、
受注処理装置は、在庫照会又は発注処理の排他制御を不
要にできるので、当該処理をクライアント毎に管理する
必要をなくすことができる。即ち、在庫照会及び発注の
先後をクライアント毎に判断する必要はなく、また、待
ち状態のクライアントを管理して当該待ち状態の解除の
際にその時点において他のクライアントからの要求の処
理結果に応じた適切な応答をする必要もない。従って、
受注処理装置において、その処理プログラムを簡単なも
のとすることができる。

【００１９】本発明の一実施態様による受注処理装置
は、上記の構成に加えて、商品の在庫がない状態で前記
コンピュータから当該受注処理装置に対する当該商品の
発注が入力された場合に当該発注についての情報を品切
れ情報ファイルに保持する。

【００２０】本発明の他の実施態様による受注処理装置
によれば、商品の在庫がない状態であっても当該商品の
発注を許容する。従って、受注処理装置（受注サーバ）
は、在庫「０」の後の発注により、マーケティングの観
点から最も重要な情報の１つである「どの商品の在庫が
どの程度足りない」と言う品切れ情報を得ることができ
る。従って、受注処理装置は、売り上げ情報（受注の実
績）と合わせて、当該商品の売れ行きの実情を知ること
ができる。

【００２１】本発明の他の実施態様による受注処理装置
は、上記の構成に加えて、前記商品の発注について当該
商品が引き当てられない場合に当該発注を有効な情報と
して保持するか否かの問い合わせを前記コンピュータに
返信し、当該発注について当該商品が引き当てられてい
ない前記発注を保持する発注残ファイルを備え、当該コ
ンピュータから前記問い合わせに対して当該発注を有効
な発注として保持することを指示する入力があった場合
に、当該発注を発注残情報として前記発注残ファイルに
保持する。

【００２２】本発明の更に他の実施態様による受注処理
装置によれば、商品の在庫がない状態であっても当該商
品の発注を許容することに加えて、商品の在庫がないこ
とを発注者に知らせた上で、これを有効な発注として保
持することができる。従って、当該コンピュータである
クライアントにとっては、その希望に応じて、自己が発
注した時点でこれを受注してもらうことができ、在庫照
会及び発注を繰り返す必要がなく、便利である。

【００２３】

【発明の実施の形態】図１は受注処理システム構成図で
あり、本発明による受注処理装置（受注サーバ）を有す
る受注処理システムの構成を示す。

【００２４】受注処理システムは、複数のクライアント
４（４１、４２、４３、・・・）である複数のコンピュ
ータと、受注処理装置（受注サーバ）１であるコンピュ
ータと、管理サーバ２であるコンピュータとからなる。
クライアント４であるコンピュータ（単に、クライアン
ト４と言う）は、ネットワーク３を介して、受注処理装
置又は受注サーバ１（単に、受注サーバ１と言う）に接
続される。受注サーバ１は、ＬＡＮ（ローカルエリアネ
ットワーク）５を介して、管理サーバ２に接続される。
ネットワーク３はインターネットからなる。

【００２５】複数のクライアント４は、各々、受注サー
バ１に商品を発注する。具体的には、クライアント４
は、後述するように、受注サーバ１に対して発注したい
商品についての在庫照会の依頼をして、この依頼に対す
る受注サーバ１からの応答に基づいて当該商品の発注の
依頼をする。クライアント４の各々は、例えば、当該商
品の小売店に設けられる。

【００２６】受注サーバ１は、複数のクライアント４の
各々からの商品の発注を受注する（受注処理を行う）。
受注処理は、在庫情報照会処理と商品引き当て処理とか
らなる。具体的には、受注サーバ１は、後述するよう
に、クライアント４からの商品についての在庫照会の依
頼に応じて在庫情報を応答として返信し（在庫情報照会
処理）、クライアント４からの発注の依頼に応じて商品
の引き当て（商品引き当て処理）を行う。管理サーバ２
は、商品についての種々のデータを管理することによ
り、商品を管理する。具体的には、管理サーバ２は、後
述するように、商品コードを用いて商品コード毎に種々
のデータを商品マスタファイル２１に蓄積し、商品の入
荷に応じて（ＬＡＮ５を介して）在庫ファイル１１を更
新する。受注サーバ１及び管理サーバ２は、例えば、当
該商品の問屋に設けられる。

【００２７】受注サーバ１は、以上のような受注処理の
ために、在庫ファイル１１、品切れ情報ファイル１２、
発注残ファイル１３、発注履歴ファイル１４を備える。
在庫ファイル１１は、管理サーバ２により作成され管理
され、受注サーバ１により管理される。品切れ情報ファ
イル１２、発注残ファイル１３、発注履歴ファイル１４
は、受注サーバ１により作成され管理される。管理サー
バ２は、商品管理のために、商品マスタファイル２１を
作成し管理する。

【００２８】在庫ファイル１１は商品毎の在庫情報を格
納する。在庫ファイル１１は、図２（Ａ）に示すよう
に、商品のメーカー（ＡＡ社等）毎に管理され、更に、
その内部が商品コード（Ａ等）毎に管理される。在庫情
報は当該商品の商品コード毎にまとめられて、（１個
の）在庫ファイル１１とされる。（１個の）在庫情報
は、当該商品の属性情報、在庫の数量、（次回の）入荷
予定日からなる。商品の属性情報とは、商品の色、サイ
ズ等である。属性情報の各々は、相互に独立に定めるこ
とができる。図２（Ａ）に示すように、在庫の数量が商
品の属性情報に対応して格納されているので、在庫情報
は、同一の属性情報を有する商品毎に管理される。従っ
て、実際には、同一の商品コードであっても、色やサイ
ズ等の属性が異なれば、別の商品として管理される。こ
れは商品の売買には消費者の嗜好が反映されるためであ
る。従って、属性情報の内容は商品（即ち、商品コー
ド）毎に定まり、各々異なる。

【００２９】商品コードは、各々の商品毎にユニークな
ものとされる。商品の属性情報は、当該商品について、
ユニークなものとされる。在庫ファイル１１において、
ある商品コードについてのある属性情報に対応する在庫
の数量が「０」である場合が、当該属性情報を有する商
品の「在庫がない」状態である。入荷予定日は、通常は
格納されず、在庫の数量が少ない（０個又は１個等）場
合、又は、次回の入荷の予定が定まっている場合に、そ
の日付が例えば「３／１（３月１日、実際には後述と同
様に「０００３０１」）」のように格納される。

【００３０】具体的には、クライアント４に対して、図
９に示すように在庫情報が提示されるので、これに対応
した形式で在庫ファイル１１が作成される。例えば、商
品コード「ＢＯ３５」である商品の中の「色」が「ブル
ー」かつ「サイズ」が「Ｍ」である属性（を有する物）
について、在庫の数量「８／４０」及び次回入荷予定日
「０００３０６」が格納される。これらについては後述
する。なお、当該商品名や価格等は、当該在庫ファイル
１１のヘッダ（図示せず）に格納される。管理サーバ２
は、在庫ファイル１１の作成時に商品マスタファイル２
１を参照することにより、商品名、属性情報等を得る。
管理サーバ２は、例えば、商品コード毎に、メーカー
名、商品名、属性情報等を商品マスタファイル２１に格
納する。

【００３１】管理サーバ２は、商品の入荷があった場
合、これに基づいて、在庫ファイル１１を更新し、ＬＡ
Ｎ５を介して、当該更新を受注サーバ１に通知する。即
ち、在庫ファイル１１を当該商品コードを用いて検索
し、当該商品の（古い又は現在の）在庫の数量の値に、
当該入荷した数量を加え、これを在庫ファイル１１にお
ける（新たな）当該商品の在庫の数量とする。受注サー
バ１は、ＬＡＮ５を介して（又は直接に）管理サーバ２
に接続され、在庫ファイル１１が更新された場合にその
旨の通知（更新通知）を管理サーバ２から受ける。

【００３２】品切れ情報ファイル１２は、図２（Ｂ）に
示すように、クライアント４毎の品切れ情報を格納す
る。（１個の）品切れ情報は、当該クライアント名（又
は、ＩＰアドレス）、当該品切れ情報の入力の時刻、当
該商品の商品コード（又は、商品名）及び属性情報、発
注残（後述する）となった商品の数量からなる。

【００３３】発注残ファイル１３は、図２（Ｃ）に示す
ように、クライアント４毎の発注残情報を格納する。
（１個の）発注残情報は、当該クライアント名（又は、
ＩＰアドレス）、当該発注残情報の入力の時刻、当該商
品の商品コード（又は、商品名）及び属性情報、発注残
（後述する）となった商品の数量からなる。従って、品
切れ情報ファイル１２と発注残ファイル１３とは同一の
内容を格納するが、前者は消去されない（保存のため
に、フレキシブルディスク等に取り出す場合を除く）の
に対して、後者は当該商品の優先発注（後述する）に応
じてその都度当該発注残情報の部分が消去される。

【００３４】なお、図２（Ｂ）に点線で示すように、品
切れ情報ファイル１２にフラグ領域を設けて、発注残フ
ァイル１３を省略してもよい。即ち、品切れ情報ファイ
ル１２に品切れ情報が格納された時点でそのフラグを
「１」とし、フラグが「１」である品切れ情報について
当該商品を優先発注して、これに応じてフラグを「０」
とするようにしてもよい。この場合、フラグが「１」で
ある品切れ情報が発注残情報に相当する。

【００３５】発注履歴ファイル１４は、図２（Ｄ）に示
すように、クライアント４毎の発注履歴情報を、その発
生順に格納する。（１個の）発注履歴情報は、当該クラ
イアント名（又は、ＩＰアドレス）、当該発注履歴情報
の入力の時刻、当該商品の商品コード（又は、商品名）
及び属性情報、発注した商品の数量からなる。従って、
発注履歴ファイル１４は、品切れ情報ファイル１２（又
は発注残ファイル１３）に、実際に発注を受注した情報
を付加したものとなる。

【００３６】受注処理において、受注サーバ１は、商品
の在庫がない状態で、クライアント４からの当該受注サ
ーバ１に対する当該商品の発注を許容する。即ち、受注
サーバ１は、当該商品の在庫の数量にかかわりなく、受
注処理（及び在庫照会処理）を行う。従って、受注処理
において、受注サーバ１が、当該商品の在庫の数量に応
じて、当該商品の受注を制限することはない。受注サー
バ１は、当該発注についての情報を発注履歴ファイル１
４に格納する。なお、従来は、受注のために、その都度
その時点での商品の在庫の数量が参照され、これに基づ
いて、当該商品の受注が制限（在庫の数量以下で受注す
る）されていた。

【００３７】また、受注サーバ１は、商品の在庫がない
状態でクライアント４から当該受注サーバ１に対する当
該商品が発注された場合に、当該発注についての情報
（品切れ情報）を保持する。品切れ情報は、品切れ情報
ファイル１２に格納される。このために、受注サーバ１
は、当該発注についての情報を保持する品切れ情報ファ
イル１２を備える。

【００３８】更に、受注サーバ１は、商品の在庫がない
状態でクライアント４から当該商品の発注が入力された
場合に、当該発注について当該商品が引き当てられない
場合に当該発注を有効な情報として保持するか否かの問
い合わせを、当該コンピュータに返信する。受注サーバ
１は、当該発注について当該商品が引き当てられていな
い発注を保持する発注残ファイル１３を備える。受注サ
ーバ１は、当該コンピュータから、前記問い合わせに対
して、当該発注を有効な発注として保持することを指示
する入力があった場合に、当該発注を発注残情報として
発注残ファイル１３に保持する。この後、受注サーバ１
は、発注残ファイル１３に発注残情報が保持されている
状態で発注残情報に含まれる当該商品の在庫が生じた場
合に、当該発注残情報である当該発注について当該商品
を引き当て、発注残ファイル１３から当該発注残情報を
削除する。

【００３９】次に、図３を参照して、クライアント４の
動作を詳細に説明する。図３は、クライアント４が実行
する発注処理フローを示す。

【００４０】受注サーバ１に対して会社（クライアン
ト）コード及びパスワードを入力すると、図６（Ａ）に
示すメニュー画面が表示される。この状態で、在庫照会
をクリックして選択することにより、当該画面から在庫
照会（の開始の依頼）を受注サーバ１に入力する（ステ
ップＳ１）。

【００４１】受注サーバ１から所定の画面情報を受信
し、当該受信した画面情報に基づいて、図６（Ｂ）に示
す在庫照会画面を表示する（ステップＳ２）。なお、こ
の画面からは、その右上の在庫商品をクリックすると在
庫ファイル１１の内容を参照することができ、発注履歴
をクリックすると発注履歴ファイル１４における当該会
社の発注履歴の内容を参照することができる。

【００４２】図６（Ｂ）に示す照会画面に、図７に示す
ように、照会情報を入力し、続けて確定ボタンをクリッ
クすることにより、当該画面から照会情報（在庫照会の
依頼の確定）を受注サーバ１に入力する（ステップＳ
３）。照会情報としては、商品のメーカー名「ＡＡ社」
及び商品コード（品番）「ｂｏ（又はＢＯ）３５」を入
力する。なお、商品コードに代えて商品名を入力するよ
うにしてもよい。

【００４３】受注サーバ１から所定の画面情報を受信
し、当該受信した画面情報に基づいて、図９に示す発注
画面を表示する（ステップＳ４）。この発注画面におい
て、その最上部に、引当区分のプルダウンメニューが表
示される。また、その下部に、自己が入力した商品コー
ド「ｂｏ３５」、その商品名（種別）「アンダーシャツ
（ハンソデ）」、価格（上代）「２２００円」、受注ロ
ット「１」が表示される。また、当該商品の属性情報に
従って、在庫情報が表示される。即ち、属性情報「色」
及び属性情報「サイズ」に従って、各々の属性情報を持
つ商品の在庫情報が表示される。例えば、「ブルー」の
「Ｍ」なる属性情報を持つ商品の在庫情報は、「４／３
０」及び「０００３０６」のように表示される。ここ
で、「４」はインターネット３を介してのクライアント
４からの発注に対して引き当てされる（リアルタイムで
引き当てされる）在庫数、「３０」は従来からの商習慣
により電話等での発注に対して引き当てされる（バッジ
で引き当てされる）在庫数、「０００３０６」は入荷予
定日（２０００年３月６日）を示す。従って、在庫の総
計である。これにより、クライアント４（の使用者）
は、リアルタイムで引き当てされる在庫の数量（この場
合は４個、及びバッジで数量が３０個）等を確認するこ
とができる。なお、例えば「ブルー」なる属性情報には
ユニークなコード「２３００」が与えられる。

【００４４】図９に示す発注画面において、引当区分の
プルダウンメニューを開いて、図８に示すようにその内
容を表示させ、いずれかのメニューを選択することによ
り、引当区分を当該画面に入力する（ステップＳ５）。
プルダウンメニューは、例えば、在庫が「有る物」につ
いては「引き当て」し、「無い物」は「発注」「キャン
セル」「発注（揃出、即ち、揃い出し）」のいずれかを
選択するようにされる。即ち、在庫が「無い物」につい
て、「発注」とは発注残ファイル１３に当該発注情報を
保持する指示であり、「キャンセル」とは当該引き当て
られない部分についての発注をキャンセルする指示であ
り、「発注（揃い出し）」とは当該引き当てられない部
分についての商品が入荷し引き当てられた時点で当該引
き当てられた部分と共に出荷（揃ったら出荷）する指示
である。

【００４５】図９に示す発注画面に、図１０に示すよう
に、発注情報を入力する（ステップＳ６）。例えば、
「ブラック」の「Ｌ」なる属性情報を持つ商品につい
て、発注数「１」を入力する。なお、在庫情報が「６０
／２３」であるので、クライアント４（の使用者）は、
リアルタイムでの引き当て用に６０個の在庫数量がある
ことを知ることができる。

【００４６】図１０に示す発注画面において、引き当て
ボタンをクリックすることにより、この画面から引き当
て又は発注（の指示）を受注サーバ１に入力する（ステ
ップＳ７）。

【００４７】受注サーバ１から、発注結果（の画面情
報）を受信し、当該受信した画面情報に基づいて、当該
発注結果画面を表示する（ステップＳ８）。図１１
（Ａ）及び図１１（Ｂ）に発注結果画面の一例を示す。
図１１（Ａ）及び図１１（Ｂ）に示す発注結果画面にお
いて、その最上部に確認の入力のための「確認」ボタ
ン、受付（受注）番号「８４８９５」、受注のメッセー
ジ「毎度・・・」が表示される。また、その下部に、当
該クライアントの発注した商品コード及び商品名が、確
認のために表示される。更に、その下部に、当該商品の
属性情報である「色」及び「サイズ」の内容、発注数、
引当数、発注残数、（引き当てについての）返事が、確
認のために表示される。

【００４８】ここで、例えば、発注数の全てが引き当て
られた場合、図１１（Ａ）に示すように、発注数
「１」、引当数「１」、発注残数「０」とされ、返事が
「（全て）引き当てされた」とされる。また、発注数の
全てが引き当てされなかった場合、図１１（Ｂ）に示す
ように、発注数「１」、引当数「０」、発注残数「１」
とされ、返事が「引き当てされなかった」とされる。こ
れにより、クライアント４（の使用者）は、自己の発注
の数量がどのように受注されたかを確認することができ
る。なお、発注数の一部のみが引き当てられた場合、例
えば、発注数「２」、引当数「１」、発注残数「１」と
され、返事が「一部引き当てされた」とされる。以上
は、前述のプルダウンメニューにおいて「無い物」は
「発注」又は「発注（揃い出し）」と指定された場合で
ある。一方、「無い物」は「キャンセル」と指定された
場合には、前述の場合において引き当てられなくても発
注残数「０」とされる。

【００４９】図１１（Ａ）又は図１１（Ｂ）に示す発注
結果画面において、確認ボタンをクリックすることによ
り、当該画面から確認を受注サーバ１に入力して（ステ
ップＳ９）、処理を終了する。なお、この確認入力は、
当該クライアント４（の使用者）が自己の発注の内容及
び受付番号を確認したことを通知する入力である。

【００５０】次に、図４を参照して、受注サーバ１の動
作を詳細に説明する。図４は、受注サーバ１が実行する
受注処理フローを示す。

【００５１】いずれかのクライアント４からの在庫照会
の開始の依頼（確定入力）があるか否かを調べる（ステ
ップＳ１０）。当該開始依頼がない場合、ステップＳ１
０を繰り返す。また、予め定められた時間が経過した後
に当該開始依頼である確定入力があった場合、当該依頼
は廃棄される。これは、以下の確定の入力の処理（例え
ば、ステップＳ１２等）についても同様である。

【００５２】なお、これに先立って、接続してきたクラ
イアント４に会社（クライアント）コード及びパスワー
ド（及び／又はＩＤ、以下同じ）の入力を求め、これに
応じて正しい会社コード及びパスワード（又はＩＤ）の
入力があった場合、図６（Ａ）に示すメニュー画面（の
画面情報）が、受注サーバ１からクライアント４に送信
される。

【００５３】当該開始依頼がある場合、図６（Ｂ）に示
す照会画面（の画面情報）を送信する（ステップＳ１
１）。

【００５４】当該照会画面からの（在庫照会の依頼の）
確定入力があるか否かを調べる（ステップＳ１２）。当
該確定入力がない場合、ステップＳ１２を繰り返す。

【００５５】当該確定入力がある場合、確定入力された
照会情報に基づいて、図９に示す発注画面（の画面情
報）を作成して、送信する（ステップＳ１３）。即ち、
当該在庫照会に応じて商品の在庫情報を含む画面情報を
クライアント４に返信する。この画面情報は、商品の発
注について当該商品が引き当てられない場合に当該発注
を有効な発注として保持するか否かの問い合わせを含
む。

【００５６】当該発注画面からの引き当て入力があるか
否かを調べる（ステップＳ１４）。即ち、商品の発注
は、発注画面の画面情報に基づく発注画面への入力によ
り行われる。当該引き当て入力がない場合、ステップＳ
１４を繰り返す。

【００５７】当該引き当て入力がある場合、当該商品に
ついての引き当て処理を行う（ステップＳ１５）。この
処理の一部のみ（在庫数量の更新処理の部分）が、ある
クライアント４からの引き当て処理を行っている場合に
他のクライアント４に対して排他的（かつ不可分）に実
行される。この処理については、図５を参照して後述す
る。

【００５８】引き当て処理の結果に基づいて、図１１
（Ａ）又は図１１（Ｂ）に示す引き当て画面（の画面情
報）を作成して、送信する（ステップＳ１６）。

【００５９】当該引き当て画面からの確認入力があるか
否かを調べる（ステップＳ１７）。当該確認入力がない
場合、ステップＳ１７を繰り返す。当該確認入力がある
場合、処理を終了する。

【００６０】図５は、受注サーバ１が実行する引き当て
処理フローを示す。

【００６１】当該商品の商品コード「Ａ」及び属性情報
を用いて、在庫ファイル１１を参照する（ステップＳ２
０）。

【００６２】当該在庫の数量（リアルタイムで引き当て
される在庫の数量）ｎ２と発注の数量ｎ１とを比較する
（ステップＳ２１）。

【００６３】在庫の数量ｎ２が発注の数量ｎ１以上（ｎ
２≧ｎ１）であるか否かを調べる（ステップＳ２２）。

【００６４】在庫の数量ｎ２が発注の数量ｎ１以上（ｎ
２≧ｎ１）である場合、排他的（かつ不可分）に在庫の
数量を更新する（ステップＳ２３）。即ち、商品Ａの在
庫の数量を、（ｎ２−ｎ１）個とする。

【００６５】当該クライアント４に対して、当該商品Ａ
を発注の数量ｎ１個だけ割り当てる（ステップＳ２
４）。

【００６６】ステップＳ２４又はＳ２９における割り当
てに基づいて、実際の出荷のための発注データ（出荷伝
票）を作成して（ステップＳ２５）、処理を終了する。
なお、ステップＳ２５において、発注履歴データが作成
され、発注履歴ファイル１４に格納される。発注履歴デ
ータは、ステップＳ２４での割り当て処理の結果、又
は、ステップＳ２９での一部割り当て処理の結果及びス
テップＳ３０での発注残情報からなり、図２（Ｄ）に示
すように作成される。

【００６７】在庫の数量ｎ２が発注の数量ｎ１以上でな
い（ｎ２＜ｎ１である）場合、排他的（かつ不可分）に
在庫の数量を更新する（ステップＳ２６）。即ち、商品
Ａの在庫の数量を、「０」個とする。

【００６８】当該商品についての品切れ情報を作成する
（ステップＳ２７）。品切れ情報は、以下のようにして
作成する。例えば、図１０に示す画面情報に基づいて、
在庫の数量ｎ２と発注の数量ｎ１との差（ｎ１−ｎ２）
個を求める。これに、当該クライアント４の名前（クラ
イアント名）、当該発注の時刻、当該商品コード及び属
性情報を付加する。

【００６９】作成した品切れ情報を品切れ情報ファイル
１２（の最後尾）に格納する（ステップＳ２８）。

【００７０】当該クライアント４に対して、当該商品Ａ
を発注の数量ｎ１個の内の一部であるｎ２個（在庫の数
量）だけ割り当て（ステップＳ２９）、残りの（ｎ１−
ｎ２）個は商品Ａを割り当てない。

【００７１】商品の割り当て処理の結果に基づいて、発
注残情報を作成して、発注残ファイル１３（の最後尾）
に当該発注残情報を格納し（ステップＳ３０）、ステッ
プＳ２５へ進む。実際は、発注残情報は、前述したよう
に、品切れ情報と同一の内容であるから、ステップＳ２
７において作成された品切れ情報を保持しておき、これ
を流用すればよい。

【００７２】なお、ステップＳ３０において、図８のプ
ルダウンメニューの在庫が「無い物」について「キャン
セル」が指示されている場合には、当該引き当てられな
い部分についての発注をキャンセルし、発注残情報は作
成されない。また、「発注（揃出）」が指示されている
場合には、当該引き当てられない部分についての商品が
入荷し引き当てられた時点で当該引き当てられた部分と
共に出荷されるように、その旨を指示する情報が発注残
情報に付加される。

【００７３】また、ステップＳ２６乃至Ｓ２９のいずれ
かにおいて、又は、ステップＳ２９の実行後に、受注サ
ーバ１の管理者に対するアラームを出力するようにして
もよい。アラーム出力は、例えば、受注サーバ１のプリ
ンタからの印刷出力又は受注サーバ１の表示装置の表示
画面上への表示（例えば、ポップアップ表示）による。
これにより、当該管理者は在庫「０」を知ることができ
る。

【００７４】更に、ステップＳ２３及びＳ２６において
排他的（かつ不可分）に在庫の数量を更新しているが、
これを必ずしも排他的（かつ不可分）に実行する必要は
ない。即ち、例えば経験的に複数のクライアント４から
の発注に基づく引き当て処理が重なる（衝突する）こと
が少ない場合には、排他処理を行わなくてもよい。これ
により、一律に排他処理を行う場合よりプログラムが複
雑な構造になるが、受注サーバ１からより少ない待ち時
間で応答が得られる。また、この場合、前記発注が重な
る場合にのみ時間的に後の発注側（のクライアント４）
を待たせるようにすれば、在庫ファイル１１の内容（在
庫の数量）を正しい値に維持することができる。

【００７５】図１２は、受注サーバ１が実行する優先受
注処理フローを示す。

【００７６】管理サーバ２からの在庫更新の通知がある
か否かを調べる（ステップＳ４０）。当該通知がない場
合、ステップＳ４０を繰り返す。

【００７７】当該通知がある場合、発注残ファイル１３
を検索する（ステップＳ４１）。

【００７８】発注残ファイル１３に在庫が更新された商
品についての発注残情報があるか否かを調べる（ステッ
プＳ４２）。当該商品についての発注残情報がない場
合、ステップＳ４０以下を繰り返す。

【００７９】当該商品についての発注残情報がある場
合、発注残ファイル１３の当該発注残情報に対して、更
新された当該商品の在庫を、他のクライアント４からの
発注に対してよりも優先的に当該クライアント４（例え
ば、４２）に引き当てる（ステップＳ４３）。このため
に、更新通知があった場合、ステップＳ４１乃至Ｓ４３
までの（優先）発注処理は排他的（かつ不可分）に行わ
れ、この期間中の他のクライアント４からの発注は待ち
状態とされる。即ち、ステップＳ４３における更新ファ
イル１１の更新処理のみでなく、ステップＳ４１以降が
排他制御される。これにより、管理サーバ２からの在庫
更新の通知を契機として、優先発注を可能とする。

【００８０】発注残ファイル１３の当該発注残情報を消
去して、処理を終了する（ステップＳ４４）。

【００８１】なお、管理サーバ２からの在庫更新の通知
を契機とする優先発注とは別に、１日の業務（営業）の
終了後に、当該業務の終了を契機とする優先発注処理が
実行される。即ち、ステップＳ４０に代えて当該業務が
終了すると、発注残ファイル１３を検索し（ステップＳ
４１）、ステップＳ４２に代えて発注残ファイル１３に
おける当該発注残情報がバッジで引き当てされる在庫数
の残っている商品か否かを調べ、当該商品についての発
注残情報である場合には当該商品のバッジで引き当てさ
れる在庫を当該発注残情報を発注元であるクライアント
４に引き当て（ステップＳ４３）、この後、発注残ファ
イル１３の当該発注残情報を消去して、処理を終了する
（ステップＳ４４）。この場合の引き当て処理は、業務
が終了しているので、排他的である必要はない。

【００８２】次に、図１３を参照して、図１の受注処理
システムの動作を詳細に説明する。図１３は、図１の受
注処理システムの動作を時間を追って示す。

【００８３】図１３において、複数のクライアント４
（例えば、４１及び４２）の各々が、受注サーバ１に対
して、略同一のタイミングで、同一の商品Ａの在庫照会
を行なう（−１、−２）。

【００８４】この場合、受注サーバ１が、当該在庫照会
に応じて当該商品Ａの在庫情報を複数のクライアント４
の各々に返信する（−１、−２）。

【００８５】複数のクライアント４（４１及び４２）の
各々が、当該受注サーバ１に対して、商品の発注を行う
（−１、−２）。

【００８６】受注サーバ１は、商品の在庫がない状態で
（複数の）クライアント４からの当該受注サーバ１に対
する当該商品の発注を許容する。即ち、受注サーバ１
は、このような複数のクライアントから当該商品の発注
が行われた場合に、その発注の順に、当該商品の在庫が
ある状態では当該商品の引き当てを行う。

【００８７】具体的には、受注サーバ１は、当該商品の
在庫がある状態では、当該発注について当該商品を引き
当てる。一方、受注サーバ１は、先行する在庫情報の返
信（−１、−２）において、当該発注について当該
商品が引き当てられない場合に当該発注を有効な情報と
して保持するか否かの問い合わせを、予め（複数の）当
該クライアント４１、４２に返信する。なお、在庫の数
量が「０」ではないが、当該発注の数量が在庫の数量よ
り大きい場合には、受注サーバ１は、当該発注の一部に
ついて在庫の全ての商品を引き当て、残りについては当
該商品が引き当てられないこととする。

【００８８】例えば、図１３に示すように、クライアン
ト４１からの発注（−１）が、クライアント４２から
の発注（−２）より先であったとする。

【００８９】この場合、受注サーバ１は、クライアント
４１からの発注に応じて、当該発注の数量だけの当該商
品を在庫の数量から引き当てる処理（引き当て処理）を
行う。この処理結果は発注履歴ファイル１４に格納され
る。これにより、在庫ファイル１１の当該商品の在庫の
数量は更新される（減る）ことになる。なお、クライア
ント４１の発注を受注したことにより、この（引当の）
時点で、当該商品Ａの在庫の数量が「０」になったとす
る。

【００９０】前記問い合わせに対する指示を先行する発
注（−１）において得ているので、この引き当て処理
（のみ）が排他的（かつ不可分）に行われる。即ち、在
庫ファイル１１の更新処理を行う極めて短い時間のみが
排他的期間であるので、他のクライアント（の使用者）
は実質的に排他期間を意識する必要がない。

【００９１】受注サーバ１は、当該発注について当該商
品が引き当てられたことを、クライアント４１に返信す
る（−１）。

【００９２】クライアント４１は、当該返信に基づい
て、当該発注の受付番号を確認する入力を行う（−
１）。

【００９３】ここで、クライアント４１の発注を受注し
たことにより、その時点で、当該商品Ａの在庫の数量が
「０」になったが、受注サーバ１は、在庫の数量「０」
にかかわりなく、クライアント４２からの当該商品Ａに
ついての発注を許す。即ち、クライアント４２からの当
該発注（−２）は、受け付けられる。また、この期間
は、クライアント４１の発注処理のための排他期間でも
ないので、当該発注は受け付けられる。一方、このクラ
イアント４２についての引き当て処理は排他的（かつ不
可分）に行われる。

【００９４】具体的には、受注サーバ１は、商品の在庫
がない状態で（複数の）クライアント４２から当該受注
サーバ１に対する当該商品の発注が入力された場合に、
以下の処理を行う。即ち、前述と同様に前記問い合わせ
に対する指示を先行する発注（−２）において得てい
るので、当該発注についての情報を品切れ情報ファイル
１２に保持し、当該発注について当該商品が引き当てら
れていない発注を、発注残ファイル１３に発注残情報と
して保持する。この処理結果は発注履歴ファイル１４に
格納される。

【００９５】受注サーバ１は、当該発注について（全部
又は一部の）当該商品が引き当てられないことを、クラ
イアントに返信する（−２）。

【００９６】クライアント４２は、当該返信に基づい
て、当該発注の受付番号を確認する入力を行う（−
２）。

【００９７】この後、発注残ファイル１３に発注残情報
が存在する場合には、在庫情報の更新を契機として、図
１２に示す優先発注の処理が行われる。なお、前述した
ように、優先発注の期間中も発注処理は排他制御され
る。また、優先発注の実行結果を当該クライアント４に
通知するようにしてもよい。

【００９８】

【発明の効果】以上説明したように、本発明によれば、
受注処理装置において、商品の在庫がない状態で当該商
品の発注を許容することにより、ある商品の在庫が
「０」でも当該商品について発注ができるので、クライ
アントにおいては、発注をした時点で受注してもらうこ
とができ、在庫照会及び発注を繰り返す必要がなく、ま
た、受注処理装置においては、在庫照会又は発注処理の
排他制御を不要にでき、その処理プログラムを簡単なも
のとすることができる。更に、受注処理装置において
は、在庫「０」の後の発注により、マーケティングの観
点から最も重要な情報の１つである品切れ情報を得るこ
とができので、受注の実績と合わせて、当該商品の売れ
行きの実情を正確に知ることができる。

【図面の簡単な説明】

【図１】受注処理システム構成図である。

【図２】受注処理説明図である。

【図３】発注処理フローチャートである。

【図４】受注処理フローチャートである。

【図５】引き当て処理フローチャートである。

【図６】受注処理説明図である。

【図７】受注処理説明図である。

【図８】受注処理説明図である。

【図９】受注処理説明図である。

【図１０】受注処理説明図である。

【図１１】受注処理説明図である。

【図１２】優先受注処理フローチャートである。

【図１３】受注処理説明図である。

【図１４】従来技術説明図である。

【符号の説明】

１受注処理装置（受注サーバ）２管理サーバ３ネットワーク４クライアント１１在庫ファイル１２品切れ情報ファイル１３発注残ファイル

Claims

【特許請求の範囲】

【請求項１】商品を発注するコンピュータとネットワ
ークを介して接続され、前記コンピュータからの前記商
品の発注を受注する受注処理装置であって、前記商品の在庫がない状態で前記コンピュータからの当
該受注処理装置に対する当該商品の発注を許容すること
を特徴とする受注処理装置。
【請求項２】前記商品の在庫がない状態で前記コンピ
ュータから当該受注処理装置に対する当該商品が発注さ
れた場合に、当該発注についての情報を品切れ情報ファ
イルに保持することを特徴とする請求項１に記載の受注
処理装置。
【請求項３】前記商品の発注について当該商品が引き
当てられない場合に当該発注を有効な情報として保持す
るか否かの問い合わせを前記コンピュータに返信するこ
とを特徴とする請求項１に記載の受注処理装置。
【請求項４】前記コンピュータから前記商品について
の在庫照会が行われた場合に、当該在庫照会に応じて前
記商品の在庫情報と前記問い合わせとを前記コンピュー
タに返信することを特徴とする請求項３に記載の受注処
理装置。
【請求項５】当該受注処理装置が、当該発注について当該商品が引き当てられていない前記
発注を保持する発注残ファイルを備え、前記コンピュータから、前記問い合わせに対して当該発
注を有効な発注として保持することを指示する入力があ
り、かつ、前記商品の在庫がない状態で前記コンピュー
タから当該商品が発注された場合に、当該発注を発注残
情報として前記発注残ファイルに保持することを特徴と
する請求項３に記載の受注処理装置。
【請求項６】前記発注残ファイルに前記発注残情報が
保持されている状態で前記発注残情報に含まれる当該商
品の在庫が生じた場合に、当該発注残情報である当該発
注について当該商品を引き当て、前記発注残ファイルか
ら当該発注残情報を削除することを特徴とする請求項５
に記載の受注処理装置。
【請求項７】商品を発注するコンピュータとネットワ
ークを介して接続され、前記コンピュータからの前記商
品の発注を受注する受注処理装置であって、前記商品の在庫がない状態で前記コンピュータからの当
該受注処理装置に対する当該商品の発注を許容し、当該発注についての情報を保持すると共に、当該発注に
ついて当該商品が引き当てられない場合に当該発注を有
効な情報として保持するか否かの問い合わせを当該コン
ピュータに返信し、当該発注についての情報を保持する品切れ情報ファイル
と、当該コンピュータから、前記問い合わせに対して当該発
注を有効な発注として保持することを指示する入力があ
り、かつ、前記商品の在庫がない状態で前記コンピュー
タから当該商品が発注された場合に、当該発注について
当該商品が引き当てられていない前記発注を発注残情報
として保持する発注残ファイルとを備えることを特徴と
する受注処理装置。
【請求項８】商品を発注する複数のコンピュータとネ
ットワークを介して接続され、前記複数のコンピュータ
からの前記商品の発注を受注する受注処理装置であっ
て、前記複数のコンピュータから当該商品の在庫照会が行わ
れた場合に、当該在庫照会に応じて当該商品の在庫情報
を前記複数のコンピュータに返信し、前記商品の発注について当該商品が引き当てられない場
合に当該発注を有効な情報として保持するか否かの問い
合わせを前記複数のコンピュータに返信し、前記複数のコンピュータから当該商品の発注が行われた
場合に、その発注の順に、当該商品の在庫がある状態で
は当該商品の引き当てを行い、当該引き当ての結果、当該発注について当該商品が引き
当てられない場合において、前記問い合わせに対して当
該発注を有効な発注として保持することを指示する入力
があった場合、当該発注を発注残情報として保持するこ
とを特徴とする受注処理装置。
【請求項９】商品を発注する複数のコンピュータと、前記複数のコンピュータとネットワークを介して接続さ
れ、前記複数のコンピュータからの前記商品の発注を受
注する受注処理装置とからなる受注処理システムであっ
て、前記複数のコンピュータの各々が、当該受注処理装置に
対して、前記商品の在庫照会を行ない、前記受注処理装置が、当該在庫照会に応じて当該商品の
在庫情報を前記複数のコンピュータの各々に返信し、前記複数のコンピュータの各々が、当該受注処理装置に
対して、前記商品の発注を行い、前記受注処理装置が、前記商品の在庫がない状態で前記
複数のコンピュータからの当該受注処理装置に対する当
該商品の発注を許容し、前記商品の在庫がない状態で前
記複数のコンピュータから当該受注処理装置に対する当
該商品の発注が入力された場合に、当該発注についての
情報を保持することを特徴とする受注処理システム。
【請求項１０】前記受注処理装置が、当該発注につい
て当該商品が引き当てられない場合に当該発注を有効な
情報として保持するか否かの問い合わせを前記複数のコ
ンピュータに返信し、前記複数のコンピュータが、前記問い合わせに対して、
当該発注を有効な発注として保持することを指示する入
力を行い、前記受注処理装置が、当該指示入力があり、かつ、前記
商品の在庫がない状態で前記複数のコンピュータから当
該受注処理装置に対する当該商品の発注が入力された場
合に、当該発注について当該商品が引き当てられていな
い前記発注を発注残情報として保持することを特徴とす
る請求項９に記載の受注処理システム。
【請求項１１】商品を発注するコンピュータとネット
ワークを介して接続され、前記コンピュータからの前記
商品の発注を受注する受注処理装置を実現するプログラ
ムを格納したコンピュータ読取可能な記録媒体であっ
て、当該プログラムは、前記商品の在庫がない状態で前記コ
ンピュータからの当該受注処理装置に対する当該商品の
発注を許容する処理を行うプログラムコードを備えるこ
とを特徴とするコンピュータ読取可能な記録媒体。