JP2003178223A

JP2003178223A - 欠品対応機能を備えた受注管理システム

Info

Publication number: JP2003178223A
Application number: JP2001377995A
Authority: JP
Inventors: Kenji Kusune; 健次楠根
Original assignee: Japan Tobacco Inc
Current assignee: Japan Tobacco Inc
Priority date: 2001-12-12
Filing date: 2001-12-12
Publication date: 2003-06-27

Abstract

(57)【要約】【課題】受注データベースを修正する機会の増加を防
ぎつつ在庫の削減に貢献できる受注管理システムを提供
する。【解決手段】在庫引当不可能な受注明細を含んだ受注
データ４５を受けたとき、欠品登録処理と欠品削除処理
とのいずれを行うかを受注データ４５に含まれる特定の
情報と関連付けて予め指定する。受注データが在庫引当
不可能な受注明細を含んでいる場合、その受注データに
含まれている特定の情報に対応して欠品登録処理又は欠
品削除処理のいずれが指定されているかを判別し、前者
が指定されているときは在庫引当不可能な受注明細を含
んだ受注データを受注データベース６１に登録し、後者
が指定されているときは、在庫引当不可能な受注明細を
削除した受注データを受注データベース６１に登録す
る。在庫引当が不可能な受注明細に対応して欠品情報を
生成し、これをオペレータに通知する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、欠品対応機能を備
えた受注管理システムに関する。

【０００２】

【従来の技術】顧客からの受注内容を受注データベース
に登録し、商品の配送や代金の収受等に関わる事項をそ
の受注データベースに基づいて一元的に管理するシステ
ムは種々の分野で運用されている。こうした受注管理シ
ステムは在庫管理機能を備えていることもあり、こうし
た在庫管理機能を受注管理機能と統合することにより、
顧客から受けた受注データに含まれている商品毎の受注
明細（例えば注文数量、納期等が含まれる）を在庫デー
タと比較して商品毎の在庫引当の可否を判断することも
既に実現されている。

【０００３】

【発明が解決しようとする課題】在庫引当を行った場
合、当然ながら商品の在庫数量が受注数量よりも不足す
る欠品が生じることがある。従来、こうした欠品部分は
受注データから削除され、受注データベースには在庫引
当が可能と判断された受注データのみが登録されてい
た。しかしながら、在庫データ上では引当不可能と判断
された場合でも、何らかの理由により受注数量分の商品
が供給可能となることがある。例えば、在庫データに反
映されていない商品が現実に存在する場合がある。ある
いは、在庫管理が地域毎や倉庫毎等の限定された範囲を
単位として相互に独立して行われている場合、顧客の担
当地域外の近隣の地域や倉庫に在庫が存在し、そこから
商品を融通して顧客に供給できることがある。ところ
が、従来の受注管理システムにおいては、欠品と判断さ
れた受注明細が受注データベースに登録されていないの
で、在庫引当不可能と判断された後に供給が可能となっ
た受注明細に関しては、システムのオペレータがこれを
受注データベースに登録しなければならない。受注デー
タベースの修正機会が多いと、オペレータの負荷が嵩
み、システムの円滑な運用に支障を来すおそれがある。
その反面、受注データベースの修正を行わないものとす
れば、現実に供給可能な商品が存在するにも拘わらずそ
れが出荷されないこととなって流通在庫が増す。顧客に
対するサービスも低下する。

【０００４】そこで、本発明は、受注データベースを修
正する機会の増加を防ぎつつ在庫の削減に貢献できる受
注管理システムを提供することを目的とする。

【０００５】

【課題を解決するための手段】以下、本発明について説
明する。なお、本発明の理解を容易にするために添付図
面の参照符号を括弧書きにて付記するが、それにより本
発明が図示の形態に限定されるものではない。

【０００６】本発明の受注管理システムは、顧客からの
発注に基づいて作成された受注データ（４５）を受注デ
ータベース（６１）に登録し、その受注データベースに
基づいて商品の供給に必要な各種の処理を行うように構
成され、かつ前記受注データに含まれている商品及びそ
の数量に関する受注明細と各商品の在庫データとを比較
して商品毎の在庫引当の可否を判断する機能を備えた受
注管理システムにおいて、在庫引当不可能な受注明細を
含んだ受注データを受けたとき、欠品登録処理と欠品削
除処理とのいずれを行うかを、前記受注データに含まれ
る特定の情報と関連付けて指定した情報を記憶する指定
記憶手段（１２，８５）と、新規に入力された受注デー
タが在庫引当不可能な受注明細を含んでいる場合、その
受注データに含まれている前記特定の情報に対応して前
記欠品登録処理又は前記欠品削除処理のいずれが指定さ
れているかを判別し、欠品登録処理が指定されていると
きは前記在庫引当不可能な受注明細を含んだ受注データ
を前記受注データベースに登録し、欠品削除処理が指定
されているときは前記在庫引当不可能な受注明細を削除
した受注データを前記受注データベースに登録する登録
管理手段（１０，６０）と、前記在庫引当が不可能な受
注明細が生じた場合、その在庫引当不可能な受注明細に
対応した欠品情報を生成する欠品情報生成手段（１０，
６０）と、前記欠品情報に基づいて特定される受注明細
の内容を、オペレータが把握可能な態様で出力する欠品
情報出力手段（１２，２１，６７）と、前記受注データ
ベースに登録されている受注データを、オペレータの指
示に基づいて修正する受注データ修正手段（１０，６
６）と、を備えた受注管理システム（２，８，１８，２
０）により、上述した課題を解決する。

【０００７】この受注管理システムによれば、受注デー
タに含まれる特定の情報と関連付けて欠品登録処理又は
欠品削除処理を予め指定しておくことができる。在庫引
当不可能な受注明細を含む受注データが入力され、か
つ、その受注データに含まれている特定の情報に関連付
けて欠品登録処理が指定されている場合、その受注デー
タは在庫引当不可能な受注明細を含めて受注データベー
スに登録される。この場合、在庫引当不可能な受注明細
に対応した欠品情報が生成され、オペレータは欠品情報
出力手段を介して在庫引当不可能な受注明細を把握する
ことができる。これにより、オペレータ等は顧客の担当
地域外の配達拠点や倉庫等に対して商品の融通を交渉す
る等して在庫確保に努めることができる。そして、在庫
引当不可能と一旦判断された受注明細に対して後に在庫
引当が可能となった場合、その受注明細は既に受注デー
タベースに登録されているので、受注明細を修正する必
要はない。在庫引当が不可能な受注明細が残った場合に
は、その受注明細について受注データ修正手段を利用し
て受注データベースから削除することになる。このよう
な処理は、在庫引当が成功する可能性の高い受注データ
を処理する場合に適している。あるいは、在庫引当が不
可能と判断された場合でも、在庫を探して引き当てるこ
とに努めるべき事情があるときにもこうした欠品登録処
理を指定しておくことが好ましい。在庫引当ができなけ
れば受注データベースを修正する手間が発生するため、
これを避けるべく在庫の引当に努めざるを得ないことに
なり、結果として在庫の削減と顧客に対するサービスの
向上が図られるからである。

【０００８】一方、在庫引当不可能な受注明細を含む受
注データが入力され、かつ、その受注データに含まれて
いる特定の情報に関連付けて欠品削除処理が指定されて
いる場合、その受注データは在庫引当不可能な受注明細
を削除してから受注データベースに登録される。この場
合、その削除された受注明細に対して在庫引当ができな
かったときには受注データベースを修正する必要がな
い。在庫引当不可能と一旦判断された受注明細に対して
後に在庫引当が可能となった場合には、その受注明細に
ついて受注データ修正手段を利用して受注データベース
に追加することになる。このような処理は、在庫引当を
行う必要がないか、又は在庫引当が成功する可能性の低
い受注データを処理するのに適している。

【０００９】このように、本発明の受注管理システムで
は、在庫引当が不可能と判断された受注明細を含めたま
まで受注データを登録するか、受注明細を削除して受注
データを登録するかを、受注データに含まれる特定の情
報に関連付けて予め指定できるようにしたので、在庫不
可能と判断されても実際には在庫が引当できる見込みが
高い受注データに対しては欠品登録処理を指定し、在庫
が引当できる見込みが低い受注データに対しては欠品削
除処理を指定することで、全体として受注データベース
の修正機会を減らし、それにより、オペレータの手間を
省略してシステムの運用コストを低減することができ
る。また、特に欠品登録処理が指定された受注データに
対しては在庫引当が促されることとなり、在庫の削減と
顧客サービスの向上とを図ることができる。

【００１０】本発明の受注管理システムにおいて、欠品
登録処理又は欠品削除処理の指定と関連付けられるべき
受注データの特定の情報は、種々の情報を選択してもよ
い。例えば、特定の情報は受注データを発注した顧客を
特定する情報としてもよい。この場合、在庫引当が達成
される見込みの高い顧客に対して欠品登録処理を指定
し、在庫引当ができる見込みの低い顧客に対しては欠品
削除処理を指定する。顧客の都合により在庫引当を要求
する顧客に対しては欠品登録処理を指定し、在庫引当を
要求しない顧客に対しては欠品削除処理を指定するよう
にしてもよい。あるいは、受注データに含まれている商
品と関連付けて欠品登録処理又は欠品削除処理を指定し
てもよい。この場合には、在庫を引当てられる見込みの
高い商品に関する受注データについては欠品登録処理
を、在庫を引当てられる見込みの低い商品に関する受注
データについては欠品削除処理を指定することができ
る。その他にも、欠品登録又は削除の指定は受注データ
に含まれ得る種々の情報と関連付けてよい。

【００１１】本発明の受注管理システムは、前記商品の
供給に関する複数の拠点がシステムの管理下に含まれる
とともに、前記在庫データは前記複数の拠点のそれぞれ
で区別して管理され、前記在庫引当の可否は、前記複数
の拠点のうち前記受注データに応じて割り当てられる担
当拠点についての在庫データに基づいて判断されてもよ
い。

【００１２】この場合において、前記欠品登録処理が行
われた受注データに対応する欠品情報が生成された場
合、前記欠品情報出力手段は、前記在庫引当が不可能な
受注明細に対応する担当拠点、商品及びその商品の不足
数量を特定した供給可能量不足リスト（７８）を出力す
るようにしてもよい。このような供給可能量不足リスト
によれば、システムのオペレータはどの拠点でどの商品
がどれだけ不足しているかを把握し、そのリストの内容
に基づいて近隣の拠点等に商品の融通を依頼することが
できる。

【００１３】また、既に受けた受注データを対象とし
て、前記在庫引当が不可能な受注明細に関する複数の受
注明細を抽出する抽出手段（１２，６７）と、その抽出
された受注明細を特定した欠品対応リスト（７９）を出
力する欠品対応リスト出力手段（１２，２１，６７）と
を備えてもよい。このような欠品対応リストを利用すれ
ば、一部の受注明細について在庫引当が期限までに達成
できなかった場合、どの受注明細を在庫引当不可能（欠
品）として処理するかを特定することができる。この場
合、前記受注データ修正手段により、前記欠品対応リス
トにて特定された受注明細を修正可能とすることが望ま
しい。

【００１４】本発明の受注管理システムにおいて、顧客
としてのユーザー企業（７）がその管理下の複数の個店
（１００）のそれぞれで発生した注文を統合して作成し
た発注情報を取得し、その発注情報に基づいて個店毎の
受注データを特定する企業間受注処理手段（８）を具備
してもよい。さらに、前記商品の供給に関する複数の拠
点がシステムの管理下に含まれるとともに、前記在庫デ
ータは前記複数の拠点のそれぞれで区別して管理され、
前記在庫引当の可否は、前記複数の拠点のうち前記受注
データに応じて個店毎に割り当てられる担当拠点につい
ての在庫データと前記個店毎の受注データとを比較して
判断されてもよい。

【００１５】そして、このような企業間受注処理手段を
備え、かつ拠点毎の在庫引当を実現した受注管理システ
ムにおいては、前記欠品登録処理が行われた受注データ
に対応する欠品情報が生成された場合、前記欠品情報出
力手段は、前記在庫引当が不可能と判断された受注明細
に対応するユーザー企業、担当拠点、商品及びその商品
の不足数量を特定した供給可能量不足リスト（７８）を
出力することが望ましい。これにより、ユーザー企業か
らの受注の担当者又は担当部署に対して在庫引当不可能
な受注明細の発生を確実に知らしめ、当該担当者による
商品の融通を促すことができる。

【００１６】また、既に受けた受注データを対象とし
て、前記在庫引当が不可能な受注明細とユーザー企業、
担当拠点及び商品が一致する複数の受注明細を抽出する
抽出手段（１２，６７）と、その抽出された受注明細に
対応する個店、商品及びその商品に数量を特定した欠品
対応リスト（７９）を出力する欠品対応リスト出力手段
（１２，２１，６７）と、を備えてもよい。この場合に
は、特定のユーザー企業に関する特定の担当拠点で所定
の期限（例えば受注データを確定して以降の処理に進む
期限）までに一部の在庫引当が達成できなかったとき、
そのユーザー企業に属し、かつ担当拠点を同じくする複
数の個店からの受注明細をリストにて出力し、どの個店
の受注明細を欠品として処理するかを担当者が判断する
資料を提供することができる。

【００１７】さらに、この場合において、前記受注デー
タ修正手段は、前記欠品対応リストにて特定されたいず
れかの個店に関する受注明細を修正可能とすることが望
ましい。

【００１８】企業間受注処理手段を備えた本発明の受注
管理システムにおいても、前記特定の情報は種々に設定
してよいが、前記ユーザー企業を特定する情報とするこ
とが望ましい。この場合には、在庫引当が不可能な受注
明細が発生したときに、ユーザー企業毎に統一した処理
を行うことができる。

【００１９】さらに、本発明の受注管理システムにおい
ては、前記欠品登録処理又は前記欠品削除処理の指定を
オペレータからの指示に応じて設定する設定手段（１
２，６８）を備えることが望ましい。この場合には、オ
ペレータが適宜に欠品登録処理と欠品削除処理とを切り
換えることができる。

【００２０】

【発明の実施の形態】以下、本発明をたばこの受注管理
システムに適用した一実施形態を説明する。図１は、本
発明の受注管理システムを含んだ、たばこの販売物流シ
ステムのアプリケーションマップである。図示の販売物
流システム１は、たばこの製造及び販売を行う企業がた
ばこの受注を処理するために運用するものであり、ＥＲ
Ｐパッケージの代表例として知られているＳＡＰ社のＲ
／３システムのＳＤモジュール（販売管理モジュール：
Sales & Distributionの略）を使用したＳＤサブシステ
ム２を中核として構成されている。

【００２１】図１において、一般販売店３からのたばこ
に関する注文は、受注情報としてＳＤサブシステム２に
引き渡される。ＳＤサブシステム２は、与えられた受注
情報に対応する商品の配送や代金決済に必要な定型処理
を実行し、配送処理システム４や実績管理サブシステム
５に対して必要な情報を提供する。実績管理サブシステ
ム５は、ＳＤサブシステム２から与えられる販売実績を
管理し、たばこの販売による収入金、たばこの販売（消
費）に対して課せられる国税及び地方税を集計する。収
入金及び地方税の情報は会計情報システム６に渡され、
そのシステム６により収入金に基づく経理処理や地方税
の納付に関する処理が行われる。たばこの地方税は、た
ばこを販売した小売店が属している市町村が課税するも
のと決められており、たばこの製造・販売企業には地方
税相当額を代行して納付することが義務付けられてい
る。このため、たばこの受注処理においては市町村単位
の販売数量を把握する必要があり、そのためには個店毎
の注文数量を把握することが必要不可欠となる。

【００２２】本実施形態の販売物流システム１において
は、上記の事情から、個店単位で受注情報を処理するよ
うにＳＤサブシステム２を構築する。その一方、量販企
業（又はコンビニエンスフランチャイズ企業）７からの
注文は、ＳＤサブシステム２を補完するＥＯＳサブシス
テム８にて受注し、そのＥＯＳサブシステム８にて企業
７が管理する個店毎の受注情報を確定してからＳＤサブ
システム２に引き渡すこととした。なお、本実施形態に
おいては、販売物流システム１を使用して受注を処理す
る企業を受注企業と呼び、ＥＯＳサブシステム８を介し
た受注処理の対象となる発注元の企業をユーザー企業と
呼ぶことがある。

【００２３】図２は、販売物流システム１を運用するた
めのハードウエア構成の一例を示している。この例で
は、ＳＤサブシステム２を構成するＳＤサーバ１０…１
０及びＥＯＳサブシステム８を構成するＥＯＳサーバ１
２…１２がＬＡＮ１３を介して相互に接続されている。
また、ＬＡＮ１３上には、ユーザー企業７で発生した発
注情報をフォーマット変換してＥＯＳサブシステム８に
受注情報として引き渡すＥＤＩサブシステム１４のＥＤ
Ｉサーバ１５…１５が接続されている。ＥＤＩサーバ１
５は所定の通信機器１６及び通信網１７を介して発注元
の企業群７…７と接続される。通信機器１６としては例
えばモデム、ターミナルアダプタ、ダイヤルアップルー
タ等が利用される。通信網１７としては例えば公衆回線
網が利用される。

【００２４】さらに、ＬＡＮ１３にはＳＤサブシステム
２からの指示に従って各種の帳票類のデータを生成する
ための帳票サブシステム１８の帳票出力サーバ１９と、
帳票類のデータを蓄積し、各拠点２４の端末等からの求
めに応じてその帳票類のデータを印刷データとして配信
するリストサブシステム２０のリストサーバ２１が接続
されている。ＬＡＮ１３は、ルーター２２及び所定のネ
ットワーク網２３を介して受注企業の各地の拠点２４…
２４に設置された他のシステムのサーバや端末と接続さ
れる。

【００２５】図３は、ユーザー企業７のたばこに関する
発注を処理するために販売物流システム１が実行する処
理の概要を示した図である。ユーザー企業７はその配下
の多数の個店１００…１００からの注文を受け、それら
の注文を統合した発注情報をトランザクションファイル
として作成する。その発注情報は、ユーザー企業７にお
ける各種の処理、例えば個店１００に対する代金決済や
商品の配送等に使用される。

【００２６】ＥＤＩサーバ１５は予め定められている集
信スケジュールに従って各ユーザー企業７のシステムに
アクセスし、各ユーザー企業７にて作成されている発注
情報を集信する。この段階で集信するファイルは各企業
７がその企業７内における業務処理で使用するために作
成するファイルであり、個店１００毎の注文内容を区別
するための情報を含むものである。

【００２７】集信スケジュールは受注日を確認するため
に使用されるものである。一例として、受注企業はユー
ザー企業からの商品の発注量に応じて配達方面毎の配達
スケジュールを計画してユーザー企業に通知する。ユー
ザー企業は、その与えられた配達スケジュールを参照し
て、特定配達日に対応する商品の発注情報の作成時期を
適当な時間的余裕を加味して決定する。受注企業では、
ユーザー企業における発注情報の作成時期を考慮して、
その作成時期よりも所定時間だけ遅らせた時期を発注情
報の集信時期として設定し、集信スケジュールとしてユ
ーザー企業に通知する。例えば、１０月１日の配達日に
関する発注情報をユーザー企業が９月２７日の午前１０
時までに作成すると決めている場合、受注企業では作成
期限よりも２時間余裕をみて９月２７日の正午を１０月
１日配達分の発注情報の集信時期として設定する。

【００２８】ＥＤＩサーバ１５は、企業７毎の集信スケ
ジュールを特定したカレンダーを保有し、そのカレンダ
ーに従って企業７から特定配達日に関するたばこ商品の
発注情報を集信する。集信のタイミングは日中のオンラ
イン処理が可能な時間帯に設定してもよいし、夜間のオ
フライン時間帯に設定してもよい。後者の場合には、例
えばＥＤＩサーバ１５からの呼び掛けに応じて企業７の
特定のサーバを起動させ、そこに蓄積されている発注情
報をバッチ処理にてＥＤＩサーバ１５に取り込むように
してもよい。

【００２９】ＥＤＩサーバ１５が集信する発注情報は、
上記のようにユーザー企業７における業務処理のために
作成されるものであり、そのフォーマットは各企業７に
て使用されている業務処理システムに依存して各社各様
である。例えばＡ社の発注情報がＥＢＣＤＩＣコードに
て記述されているのに対して、Ｂ社の発注情報がＡＳＣ
ＩＩコードにて記述されている等の相違がある。こうし
たフォーマットが異なる発注情報を受注企業側で一元的
に処理するため、ＥＤＩサーバ１５は所定のフォーマッ
ト変換プログラム３０を実行して各企業７からの発注情
報を物理的にフォーマット変換する。フォーマット変換
後のデータは集信ファイル３１として保存される。

【００３０】集信ファイル３１はユーザー企業７毎に作
成される発注情報を特定のフォーマットへと物理的に変
換したものであり、物理的なフォーマットは統一されて
いるものの、論理的なフォーマット（例えば各レコード
に含まれるフィールドの種類やフィールドの並び順な
ど）はユーザー企業７毎に異なっている。そこで、ＥＤ
Ｉサーバ１５はさらなるフォーマット変換プログラム３
２を実行して集信ファイル３１を論理的に統一された共
通フォーマットの受注データ３３（以下、共通フォーマ
ット３３と表記することがある。）に変換する。

【００３１】集信ファイル３１に含まれる各フィールド
と共通フォーマット３３に含まれる各フィールドとの対
応関係は企業７毎に異なる。そこで、この対応関係を記
述したテーブルを企業７毎に予め作成し、それを参照し
て集信ファイル３１から共通フォーマット３３へのフォ
ーマット変換を行うことになる。

【００３２】作成された共通フォーマット３３は、ＥＯ
Ｓサブシステム８のＥＯＳサーバ１２に引き渡される。
ＥＯＳサーバ１２は、データ補完プログラム４０を実行
して、ＥＤＩサーバ１５にて作成された共通フォーマッ
ト３３に不足しているデータ（情報）を補完し、受注デ
ータ４１として蓄積する。この段階で補完されるデータ
は、受注企業における内部処理で必要となる情報に関す
るものであって、集信ファイル３１には存在しないもの
である。特に、ＥＯＳサブシステム８において、ユーザ
ー企業７からの発注情報をその企業７の配下の個店毎の
発注情報として確定するために必要とされる各種の情報
が共通フォーマット３３に付加される。これらの情報
は、集信ファイル３１に含まれ、共通フォーマット３３
へと変換された時点で存在している各種の情報に基づい
て特定される。

【００３３】集信ファイル３１及び共通フォーマット３
３は例えば図４に示したように構成される。なお、図４
は、一件のレコードに含まれる各種のフィールドをそれ
らの並び順に従って上から下に記載したものである。こ
の例において、集信ファイル３１には、発注を特定する
基礎となる伝票番号、発注元の企業を特定する社コー
ド、発注元の個店を特定する店コード、発注日、納品
日、発注された商品を特定する商品コード、発注数量を
特定する発注単位、数量等の情報が含まれている。但
し、店コード、商品コード等はユーザー企業７が独自に
定めていることがある。

【００３４】一方、図４の共通フォーマット３３では、
集信ファイル３１に対応するフィールドが存在する情報
（例えばＥＯＳ販売店コード、相手販売店名）の他に、
受注企業にて行われる処理の都合から必要となる情報、
例えば、エラー区分、重複チェック区分、配達デポコー
ド、配達方面コード、製品部門、僅少銘柄削除区分、銘
柄削除区分等のフィールドが付加されている。共通フォ
ーマット３３にて追加するフィールドは、ＥＯＳサブシ
ステム８にて行われる処理の内容に応じて適宜定めてよ
い。但し、本実施形態では、後述する欠品対応処理にお
いて、欠品明細の登録の可否を判別するための情報とし
て、共通フォーマット３３に「伝票タイプ」のフィール
ドが設けられている。

【００３５】ＥＤＩサーバ１５にて生成される共通フォ
ーマット３３では、こうした受注企業が付加する情報の
フィールドは空欄のままである。こうした受注企業の都
合で必要となる情報はＥＯＳサーバ１２にて補完され、
その情報が補完されたデータが受注データ４１としてＥ
ＯＳサブシステム８に蓄えられる。なお、配達デポと
は、確定された受注に対応する商品の配達を担当する部
署である。

【００３６】再び図３により受注処理の流れを説明す
る。受注データ４１が作成されると、ＥＯＳサーバ１２
は所定の変換・チェックプログラム４２に従って受注デ
ータ４１に対する各種の変換処理、及びデータ内容のチ
ェックを行う。この段階で変換エラーや内容のエラーが
発見されるとＥＯＳサーバ１２はエラー情報４３を生成
する。なお、変換・チェックプログラム４２の処理は、
各種の変換テーブルを収容した変換用データ４９を参照
して行われる。図５に示したように、変換用テーブル４
９には業務指示テーブル８５が含まれている。業務指示
テーブル８５には、ユーザー企業７毎の受注処理に関す
る各種の設定値が記録される。例えば、代金電送フォー
マットの通知の要否、配達先、専用伝票出力の要否等を
判別する情報が業務指示テーブル８５に記録されるが、
特に本実施形態では、図４の共通フォーマット３３に含
まれている伝票タイプのフィールドが、「欠品登録」又
は「欠品削除」のいずれに該当するかを指定する情報
が、企業コード（図４の共通フォーマットのＥＯＳ企業
コードに相当）と対応付けて業務指示テーブル８５に記
録されている。

【００３７】図３に示すように、変換・チェックプログ
ラム４２により、リストサーバ２１に対してＣＡＰ受注
リスト７０又は銘柄削除リスト７１の作成が指示される
ことがある。また、エラー情報４３が生成された場合、
これがリストサーバ２１に提供されてコード変換エラー
リスト７２が作成されることがある。

【００３８】企業７からの発注を処理すべき担当者は所
定の端末４４にてエラー情報の有無を確認することがで
きる。エラーが生じている場合、担当者は端末４４を操
作してエラーを解消するために必要なテーブルを修正
し、ＥＯＳサーバ１２に対してリラン処理を指示するこ
とができる。

【００３９】リラン処理が指示されると、ＥＯＳサーバ
１２はその修正された受注データ４１に対して変換・チ
ェックプログラム４２に基づく変換処理及びチェック処
理を行う。受注データ４１の変換及びチェックが正常に
終了することにより、受注データ４１に含まれる個店１
００毎の受注内容が確定し、特定配達日に関する正常な
受注データ（図３では正常データと表記）４５が作成さ
れる。受注データ４５は、企業７の発注情報に含まれる
個店１００毎の特定配達日に関する受注情報としてＳＤ
サーバ１０に引き渡される。また、さしずまでに要する
時間がない場合は、エラーを留めておいて処理を先に進
める場合もある。

【００４０】図４の右側に示すＲ３受注データは、ＥＯ
Ｓサーバ１２からＳＤサーバ１０に渡される受注データ
４５の一例である。受注データ４５は、受注情報のヘッ
ダとして機能するレコードと、受注明細として機能する
レコードとに区分される。これらの区分は、集信ファイ
ル及び共通フォーマットのそれぞれのレコード区分の内
容に基づいて行われる。ヘッド部と明細部とはクライア
ント、Ｒ３販売店コード、販売年月日、シーケンス番号
までが共通で、その後のフィールドの内容が異なる。明
細部は品目コード及び数量のフィールドを含んでおり、
これらのフィールドには、受注データ４１に基づいて特
定された商品の特定するコードと、その発注数量とが代
入される。従って、１件の受注データ４５は、図６に示
すように、特定の個店Ａに対応した伝票番号や配達デポ
等を指定するヘッダ部と、同一販売日に関するその個店
Ａについての商品毎の受注明細とから構成されることに
なる。つまり、１件の受注データ４５は、同一販売日に
関する同一個店１００の受注明細を集約した受注情報で
ある。

【００４１】ＳＤサーバ１０に渡される受注データ４５
の各フィールドは、共通フォーマット３３に含まれる情
報から特定される。但し、ＳＤサーバ１０が受注を処理
するために必要とする情報以外の情報は受注データ４５
において削除される。例えば相手販売店名、相手原価の
情報等が削除される。このように共通フォーマット３３
にて付加した情報をＳＤサブシステム２への入力段階で
削除する理由の一つは次の通りである。

【００４２】ＳＤサブシステム２は受注処理のための汎
用パッケージソフトを利用して構成されており、その汎
用性を優先すれば、一般販売店３からの注文もユーザー
企業７の配下の個店１００の注文も区別することなく受
注データベース６１に統合して一元的に管理することが
望ましい。従って、ＳＤサブシステム２に対する入力デ
ータのフォーマットも、取引相手の業態の相違に拘わり
なく統合されるべきである。その一方、ユーザー企業７
から一括して提供される発注情報から個店１００毎の注
文を確定する処理は、地方税の処理と関連したたばこの
販売における特殊な事情に基づいて要求されるものであ
り、一般小売店からの受注においてはそのような処理は
必要とされない。従って、ユーザー企業７からの発注情
報を個店１００毎の注文として確定するために必要とな
る固有の情報を、ＳＤサブシステム２における入力情報
のフォーマットに含めることはＳＤサブシステム２の汎
用性を損なうこととなり適当ではない。そこで、本実施
形態では、ＥＯＳサブシステム８にて使用する独自情報
を共通フォーマット３３に含めておき、その情報を活用
して個店１００毎の受注を確定し、その後にＥＯＳサブ
システム２にて使用する固有の情報を削除して汎用的な
フォーマットの受注データ４５を作成し、これをＳＤサ
ブシステム２に引き渡すこととした。

【００４３】図３に戻って説明を続ける。ＥＯＳサブシ
ステム８からＳＤサーバ１０に対して受注データ４５が
渡されると、ＳＤサーバ１０は、在庫引当プログラム６
０に従って、受注データ４５にて指定されている商品
を、その受注データ４５にて指定された数量だけ引当可
能か否かを在庫データベース６４を参照して判断する。
在庫データベース６４には各商品の在庫量が配達デポ毎
に記録されており、在庫引当の判断は配達デポを単位と
して行われる。すなわち、在庫引当プログラム６０によ
る処理では、受注データ４５のヘッダ部に含まれている
配達デポのコードが参照されて個店１００の担当となる
配達デポが特定され、その特定された配達デポに関する
在庫データと個店１００の受注明細とが比較されて、受
注明細毎に在庫が引当可能か否か判断される。そして、
一つの個店１００の受注データ４５に含まれている全て
の受注明細が、全て在庫引当可能と判断された場合に
は、その個店１００の受注データ４５が、特定配達日に
関する確定した受注データとして受注データベース６１
に登録される。受注データ４５に含まれている受注明細
のいずれかについて在庫引当不可能と判断された場合に
は、所定の欠品対応処理が行われる。これについては後
述する。なお、受注データ４５に含まれている在庫量
は、現実の在庫量に対して、所定期間に予定されている
入庫量及び出庫量を反映した値である。

【００４４】受注データベース６１に書込まれた受注デ
ータはさしずプログラム６２に基づくさしず処理の対象
となる。さしず処理とは、受注内容を確定する処理であ
る。さしずプログラム６２は、配達日と関連付けられた
定刻（例えば配達日の２４時間前）に自動的にさしず処
理が行われるようにＳＤサーバ１０を機能させる。但
し、在庫引当不可能と判断された受注に対する融通処理
等を可能とするため、Ｒ３サブシステム２の端末上から
ＳＤサーバ１０に対してさしず管理プログラム６５の実
行を指示することにより、自動さしずの起動を抑止する
ことが可能とされ、また、オペレータの手動操作による
さしずも可能とされる。自動さしずの抑止、及び手動さ
しずは、伝票単位、つまり同一販売日についての同一店
舗（個店であるか、一般店であるかを問わない。）に関
する全ての受注明細を一つの単位として実行可能であ
る。また、ＳＤサブシステム２においては、端末上から
オペレータが受注修正プログラム６６の実行を指示する
ことにより、受注データベース６１に登録された受注デ
ータを伝票単位で呼び出して修正する処理も可能とされ
ている。

【００４５】さしず処理において、ＳＤサーバ１０は、
さしず対象の受注データに従って配送システム４（図１
参照）に所定の配送指示を出力し、あるいは実績管理サ
ブシステム５に対して確定された受注データに基づく販
売実績を通知する等の処理を行う。このように、さしず
処理を受けることにより、受注データが最終的に確定
し、そのデータに基づく商品の配送の手配や代金決済の
処理が開始されることになる。

【００４６】なお、受注データベース６１には、ＥＯＳ
サブシステム８から引き渡される受注データだけでな
く、一般販売店３（図１）からの受注データも含まれて
いる。さしずを受けて確定された受注データは、ＳＤサ
ーバ１０から帳票サブシステム１８の帳票出力サーバ１
９（図２参照）にも送られる。帳票出力サーバ１９は所
定の販売票作成プログラム６３を実行し、さしずによっ
て確定された受注データに対応する個店毎の販売票７３
を作成する。この販売票７３が、同一販売日（配達部）
に関する同一店舗のすべての受注明細を含んだ伝票に相
当する。販売票７３はリストサブシステム２０のリスト
サーバ２１に蓄積される。

【００４７】ＥＯＳサブシステム８からＳＤサブシステ
ム２に引き渡され、さしず処理によって確定された受注
データはＥＯＳサブシステム８に渡され、その受注デー
タに対応する特定配達日についての代金情報４６がＥＯ
Ｓサーバ１２にて生成される。なお、上記のさしず管理
プログラム６５に従って自動さしずが抑止された受注デ
ータに関しては、手動さしずが行われるまで代金情報４
６の通知が保留される。

【００４８】代金情報４６を受け取ったＥＯＳサーバ１
２は、代金伝送・データ作成プログラム４７を実行して
代金情報４６に対応する代金電送フォーマット４８を作
成する。作成された代金電送フォーマット４８はＥＤＩ
サーバ１５を介して発注元のユーザー企業７に特定配達
日に関する代金情報として通知される。また、代金情報
４６はリストサーバ２１にも提供され、リストサーバ２
１ではその代金情報４６に基づいて代金通知伝票７４が
作表される。なお、ＥＯＳサーバ１２はＳＤサーバ１０
から渡されるデータに基づく代金通知の他に、正常デー
タ４５に基づく代金通知伝票７５の作成も可能である。
さらに、専用伝票作成プログラム５０に従って、受注デ
ータ４１に対応する専用伝票のデータ５１を作成するこ
ともできる。専用伝票のデータ５１はユーザー企業７に
て指定されたフォーマットで伝票を発行するためのデー
タである。リストサーバ２１にはそのデータ５１に基づ
く専用伝票７６が蓄積される。販売票７３等はユーザー
７企業７の相違に拘わりなく、受注企業が用意する一定
のフォーマットで発行されるのに対して、専用伝票７６
はユーザー企業７が指定するフォーマットで発行され
る。

【００４９】なお、専用伝票７６を、正常データ４５で
はなく受注データ４１に基づいて発行することとしたの
は、ユーザー企業７から集信した発注情報に対して、正
常データ４５が受注企業の自社処理の都合により修正さ
れていることがあり、ユーザー企業７の立場において
は、自社のトランザクションファイルから受注企業が集
信した発注情報に忠実な伝票をユーザー企業７のフォー
マットに従って必要とすることがあるからである。その
一方、集信ファイル３１から専用伝票７６を作成しない
のは、受注データ４１に付加された受注企業に特有の情
報を参照して専用伝票作表用のデータ５１の編集を可能
とするためである。但し、出力される専用伝票７６は、
あくまでユーザー企業７から指定された仕様に従うもの
となる。

【００５０】次に、受注データ４５を受け取ったＳＤサ
ーバ１０が在庫引当プログラム６０に従って在庫引当を
行った結果、在庫不可能な受注明細が生じた場合の処理
を説明する。

【００５１】在庫引当不可能な受注明細を含んだ受注デ
ータ４５を受け取った場合、ＳＤサーバ１０は図７に示
す受注登録処理を行う。この処理では、まず、受注デー
タ４５のヘッダ部に含まれている伝票タイプに従って欠
品登録が指示されているか否かが判断される（ステップ
Ｓ１１）。欠品登録が指定されていないときは、在庫引
当不可能と判断された受注明細（欠品明細）が受注デー
タ４５から削除された上でその受注出データ４５が受注
データベース６１に登録される（ステップＳ１２）。一
方、欠品登録が指定されているときは、欠品明細を含め
て受注データ４５が受注データベース６１に登録される
（ステップＳ１３）。その後、引当エラー情報５２の一
種である欠品情報が生成されてＥＯＳサーバ１２に通知
され（ステップＳ１４）、これにより受注登録処理が終
了する。

【００５２】図７の処理で生成される欠品情報は例えば
図８に示すように構成される。この例では、ＥＯＳサー
バ１２が欠品明細の内容を特定するために必要なフィー
ルドが欠品情報に含まれる。例えば、欠品が生じている
個店１００の所属するユーザー企業７を特定するための
ＥＯＳコード及びＲ３企業コード、個店１００を特定す
るための販売店コード、担当部署を特定するための営業
所コード、デポコード、販売伝票タイプ、販売伝票番
号、販売年月日、銘柄コード、数量等が欠品情報に含ま
れる。

【００５３】欠品情報を受け取ったＥＯＳサーバ１２
は、図３に示す引当エラー対応プログラム６７に従って
種々の処理を実行する。図９は、その処理の一つとし
て、欠品情報を受け取ったときにＥＯＳサーバ１２が実
行する欠品情報蓄積処理を示している。この処理では、
受け取った欠品情報に含まれている伝票タイプに基づい
て、欠品が登録されたか否かが判断される（ステップＳ
２１）。欠品が登録されていないときはその欠品情報
が、欠品リスト７７（図３参照）の出力用のデータとし
てリストサーバ２１に蓄積され（ステップＳ２２）、登
録されているときはその欠品情報が供給可能量不足リス
ト７８（図３参照）の出力用のデータとしてリストサー
バ２１に蓄積される（ステップＳ２３）。

【００５４】このようにして蓄積された欠品リスト７７
及び供給可能量不足リスト７８は、ＥＯＳサブシステム
８の端末からの操作に応じてその端末の画面に表示され
る。また、リストサーバ２１から印刷データを受け取っ
て印刷出力することもできる。ここで、欠品リスト７７
の一例を図１０に、供給可能量不足リスト７８の一例を
図１１にそれぞれ示す。図１０に示すように、欠品リス
ト７７は在庫引当が不可能であった受注明細の内容を特
定するリストであり、ユーザー企業７の名前、配達日、
担当の配達デポ、さしず日、販売店コード、販売店名等
の情報とともに、欠品となった銘柄のコード、名前及び
数量が一覧形式で出力される。この欠品リスト７７に含
まれている受注明細は、要するにＳＤサーバ１０が受注
データ４５から削除した受注明細に相当する。一方、図
１１に示すように、供給可能量不足リスト７８は、ユー
ザー企業７の名前、欠品が生じた担当デポ、配達日、さ
しず日等の情報とともに、欠品となった銘柄のコード、
名前及び数量が一覧形式で出力される。供給可能量不足
リスト７８に個店１００に関する情報が存在しないの
は、供給可能量不足リスト７８に含まれる欠品明細に対
応した受注明細はすべて受注データベース６１に登録さ
れており、いずれの個店１００において欠品が生じたか
を特定できないからである。

【００５５】なお、特定配達日に対応するさしず処理が
自動的に実行された後にその特定配達日に対する受注デ
ータがＥＯＳサブシステム８からＳＤサブシステム２に
引き渡される等のさしず後エラーが生じた場合にもＳＤ
サーバ１０はエラー情報をＥＯＳサーバ１２に通知す
る。この場合、ＥＯＳサーバ１２はさしず後エラーリス
ト（不図示）のデータを生成してリストサーバ２１に蓄
積する。

【００５６】本実施形態のシステムにおいて、ユーザー
企業７からの受注の処理を担当する部署では、所定の端
末５３を利用して、データ変換・チェック処理にて発生
したエラー情報４３、正常データ４５の蓄積状況、引当
エラー情報５２を確認することができる。また、必要に
応じて、リストサーバ２１に蓄積されている欠品リスト
７７や供給可能量不足リスト７８を取り出して欠品の状
況を把握することができる。オペレータはこうした情報
に基づいてユーザー企業７からの発注情報の集信状況を
確認することができる。また、引当エラーが生じている
場合には例えば配達担当のデポの近隣の他の配達デポに
在庫を照会し、在庫の融通が可能か否かを交渉すること
ができる。融通可能であれば受注データベース６１を修
正することもできる。但し、その修正方法は欠品リスト
７７又は供給可能量不足リスト７８のいずれが出力され
ているかによって異なる。

【００５７】欠品リスト７７に含まれている欠品銘柄を
他の配達デポから融通することができた場合、その欠品
リスト７７に含まれている明細は受注データベース６１
に含まれていない。従って、この場合、オペレータは受
注修正プログラム６６を実行させ、融通可能となった受
注明細を手動にて受注データベース６１に登録すること
になる。一方、欠品リスト７７に含まれている欠品をそ
のまま放置する場合、あるいは欠品が融通不可能であっ
た場合、オペレータは受注データベース６１を修正する
必要はない。つまり、業務指示テーブル８５に、伝票タ
イプとして欠品削除が指定されているユーザー企業７に
おいて欠品が生じた場合、オペレータはその欠品を解消
できない限り受注データベース６１を修正する必要がな
い。このような設定は、現実に欠品を融通できる可能性
が低い場合に受注データベース６１の修正頻度を減らす
上で効果的である。

【００５８】これに対して、供給可能量不足リスト７８
が出力された場合、そこに記載されている欠品明細は受
注データベース６１に既に登録されている。従って、供
給可能量不足リスト７８に含まれている銘柄をそのリス
ト７８に載っている配達デポに対して不足量だけ融通で
きたときは受注データベース６１を修正する必要がな
い。このような設定は、現実に欠品を融通できる可能性
が高い場合に受注データベース６１の修正頻度を減らす
上で効果的である。また、欠品明細に相当する受注明細
を受注データベース６１に先に登録したならば、受注デ
ータベース６１の修正という手間を省くために、ユーザ
ー企業７からの受注の担当部署に欠品の融通を促し、そ
れにより在庫量の削減と顧客サービスの向上とを図るこ
とができる。但し、欠品の一部でも融通が不可能であっ
た場合、担当者は受注データベース６１を修正しなけれ
ばならない。この欠品に基づく受注データベース６１の
修正を行う場合、どの個店１００の注文を欠品として処
理するかを特定する作業が必要となる。

【００５９】そこで、図３の引当エラー対応プログラム
６７には、オペレータの求めに応じて欠品対応リスト７
９を出力する機能（モジュール）が含まれている。図１
２はその欠品リスト７９を出力するためにＥＯＳサーバ
１２が実行する欠品対応リスト出力処理の手順を示す。
端末５３上でオペレータが欠品対応リストの作成を要求
すると図１２の処理が開始され、まず、欠品対応リスト
作成画面が端末５３のモニタ上に表示され（ステップＳ
３１）、その後、オペレータが必要な条件を入力したか
否かが判断される（ステップＳ３２）。欠品対応リスト
作成画面は例えば図１３の画面２００のように構成され
る。リスト作成画面２００には、企業コード、販売年月
日、デポコード、銘柄コード等の入力部２０１〜２０４
が設けられている。オペレータが、供給可能量不足リス
ト７８に記載された事項を入力部２０１〜２０４に入力
して実行ボタン２０５をクリックすると図１２のステッ
プＳ３２が肯定判断され、その入力された条件に一致す
る受注明細を含んだ受注データ４５が検索される（ステ
ップＳ３３）。そして、合致した受注データ４５に基づ
いて欠品対応リストのデータが生成され、そのリストが
端末５３のモニタに出力される（ステップＳ３４）。

【００６０】以上の処理によって出力された欠品対応リ
スト７９の一例を図１４に示す。この例のように、欠品
対応リスト７９には、欠品が生じた配達デポの担当範囲
に含まれている欠品銘柄と同一銘柄の同一販売日（配達
日）に関する全ての受注明細（販売店コード、販売店
名、伝票番号、銘柄コード、銘柄名、数量）が含まれ
る。オペレータ（又は受注担当者）は欠品対応リスト７
９を見ながら、どの個店１００の受注明細を欠品として
処理するかを決定することができる。そして、欠品を生
じさせる個店１００を決定した後は、ＳＤサブシステム
２の端末から図３の受注修正プログラム６６に従って受
注データベース６１を修正することになる。

【００６１】図１５はその受注データベース６１を修正
する際に端末上に表示される受注修正画面２１０の一例
を示している。画面２１０には、修正対象の受注データ
（伝票）を特定するために、販売店コード、販売年月
日、デポコード、伝票番号の入力部２１１〜２１４が設
けられている。修正対象の受注データ４５に対応した情
報をこれらの入力部２１１〜２１４に入力すると、その
受注データ４５に含まれている商品銘柄と個数とが受注
明細表示部２１５に表示される。オペレータは修正を希
望する商品銘柄の数量の欄をクリックし、そこに修正後
の数量を代入することにより受注データベース６１を修
正することができる。

【００６２】なお、上記の欠品対応リスト７９を利用し
た欠品処理対象の特定は、欠品リスト７７に基づく融通
時にも行うことができる。すなわち、欠品リスト７７に
て特定されている個店１００に代え、他の個店１００を
欠品対象として処理したい場合にも同様の欠品リスト７
９を出力し、そのリスト７９に基づいて特定した欠品対
象の個店１００の受注データ４５を受注データベース６
１から読み出して数量を変更し、かつ、欠品リスト７７
に載っている個店１００の受注明細を受注データベース
６１に新たに登録すればよい。

【００６３】また、上記のように欠品リスト７７又は供
給可能量不足リスト７８に基づく融通を行う場合におい
て、受注データベース６１を修正する前に自動さしずが
実行され、融通結果に基づくデータ修正が不可能となる
おそれがあるときは、さしず管理プログラム６５に従っ
て修正対象となり得る受注データ４５についての自動さ
しずを停止し、修正完了後に手動にてさしずを実行する
ことが望ましい。

【００６４】ＥＯＳサブシステム８には、変換用データ
４９に含まれている各種のデータの変更、追加、修正を
行うためのメンテナンスプログラム６８も用意されてい
る。オペレータはこのメンテナンスプログラム６８を利
用して、業務指示テーブル８５に記録されている伝票タ
イプを適宜に切り換えることができる。これにより、在
庫引当が不可能と判断された受注明細を受注データベー
ス６１に登録するか否かをユーザー企業７毎に個別に設
定することができる。このため、システム１の運用者
は、欠品の発生状況や融通の達成状況を考慮しつつ受注
データベース６１を修正する機会が最も少なくなるよう
に企業７毎に伝票タイプを設定することができる。

【００６５】本発明は上記の実施形態に限定されず、種
々の変更が可能である。例えば、欠品登録を行うか欠品
削除を行うかを、商品の銘柄と関連付けて設定してもよ
い。本発明はユーザー企業からの受注を個店単位の受注
データに区別するＥＯＳサブシステム８を備えたものに
限定されず、種々の形態の受注管理システムに適用され
る。商品はたばこに限らず、種々の商品を対象としてよ
い。一般には役務として認識されるものであっても、欠
品の概念が生じ得る限りは本発明の商品の概念に含まれ
る。在庫引当を複数の配達拠点で分散して行うシステム
に限らず、単一の拠点から商品を供給するシステムであ
っても、一旦在庫引当が不可能と判断された受注明細が
後発的な事情により在庫引当可能となり得る受注管理シ
ステムであれば本発明は適用可能である。

【００６６】

【発明の効果】以上に説明したように、本発明の受注管
理システムでは、在庫引当が不可能と判断された受注明
細を含めたままで受注データを登録するか、受注情報を
削除して受注データを登録するかを、受注データに含ま
れる特定の情報に関連付けて予め指定できるようにした
ので、在庫不可能と判断されても実際には在庫が引当で
きる見込みが高い受注データに対しては欠品登録処理を
指定し、在庫が引当できる見込みが低い受注データに対
しては欠品登録処理を指定することで、全体として受注
データベースの修正機会を減らし、それにより、オペレ
ータの手間を省略してシステムの運用コストを低減する
ことができる。また、特に欠品登録処理が指定された受
注データに対しては在庫引当が促されることとなり、在
庫の削減と顧客サービスの向上とを図ることができる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係る受注管理システムを
包含した販売物流システムにおけるアプリケーション相
互間の関係を示した図。

【図２】図１のシステムを実現するためのハードウエア
構成の要部を示す図。

【図３】図１のシステムにて行われる受注処理の流れを
示した図。

【図４】図３の処理において生成されるデータの論理構
造を示した図。

【図５】図３のデータ変換用データに含まれる業務指示
テーブルの一部を示す図。

【図６】図３のＥＯＳサブシステムによって作成される
個店毎の受注データの概略構成を示した図。

【図７】図３のＳＤサブシステムにて実行される受注登
録処理の手順を示したフローチャート。

【図８】図７の処理によって生成される欠品情報の構成
を示した図。

【図９】図３のＥＯＳサブシステムにて実行される欠品
情報蓄積処理の手順を示したフローチャート。

【図１０】図３のリストサーバから出力される欠品リス
トの一例を示した図。

【図１１】図３のリストサーバから出力される供給可能
量不足リストの一例を示した図。

【図１２】図３のＥＯＳサブシステムにて実行される欠
品対応リスト出力処理の手順を示したフローチャート。

【図１３】図１２の処理でモニタに表示される欠品対応
リスト作成用の入力画面を示す図。

【図１４】図１３の処理で出力される欠品対応リストの
一例を示した図。

【図１５】図３のＳＤサブシステムにて受注データベー
スを修正する際にモニタに表示される伝票修正画面を示
す図。

【符号の説明】

１販売物流システム２ＳＤサブシステム３一般販売店４配送処理システム５実績管理サブシステム６会計情報システム７ユーザー企業８ＥＯＳサブシステム１０ＳＤサーバ１２ＥＯＳサーバ１５ＥＤＩサーバ１９帳票出力サーバ２１リストサーバ３１集信ファイル３３共通フォーマットの受注データ４１受注データ４５受注データ６１受注データベース１００個店

Claims

【特許請求の範囲】

【請求項１】顧客からの発注に基づいて作成された受
注データを受注データベースに登録し、その受注データ
ベースに基づいて商品の供給に必要な各種の処理を行う
ように構成され、かつ前記受注データに含まれている商
品及びその数量に関する受注明細と各商品の在庫データ
とを比較して商品毎の在庫引当の可否を判断する機能を
備えた受注管理システムにおいて、在庫引当不可能な受注明細を含んだ受注データを受けた
とき、欠品登録処理と欠品削除処理とのいずれを行うか
を、前記受注データに含まれる特定の情報と関連付けて
指定した情報を記憶する指定記憶手段と、新規に入力された受注データが在庫引当不可能な受注明
細を含んでいる場合、その受注データに含まれている前
記特定の情報に対応して前記欠品登録処理又は前記欠品
削除処理のいずれが指定されているかを判別し、欠品登
録処理が指定されているときは前記在庫引当不可能な受
注明細を含んだ受注データを前記受注データベースに登
録し、欠品削除処理が指定されているときは前記在庫引
当不可能な受注明細を削除した受注データを前記受注デ
ータベースに登録する登録管理手段と、前記在庫引当が不可能な受注明細が生じた場合、その在
庫引当不可能な受注明細に対応した欠品情報を生成する
欠品情報生成手段と、前記欠品情報に基づいて特定される受注明細の内容を、
オペレータが把握可能な態様で出力する欠品情報出力手
段と、前記受注データベースに登録されている受注データを、
オペレータの指示に基づいて修正する受注データ修正手
段と、を備えたことを特徴とする受注管理システム。
【請求項２】前記商品の供給に関する複数の拠点がシ
ステムの管理下に含まれるとともに、前記在庫データは
前記複数の拠点のそれぞれで区別して管理され、前記在
庫引当の可否は、前記複数の拠点のうち前記受注データ
に応じて割り当てられる担当拠点についての在庫データ
に基づいて判断されることを特徴とする請求項１に記載
の受注管理システム。
【請求項３】前記欠品登録処理が行われた受注データ
に対応する欠品情報が生成された場合、前記欠品情報出
力手段は、前記在庫引当が不可能な受注明細に対応する
担当拠点、商品及びその商品の不足数量を特定した供給
可能量不足リストを出力することを特徴とする請求項２
に記載の受注管理システム。
【請求項４】既に受けた受注データを対象として、前
記在庫引当が不可能な受注明細に関する複数の受注明細
を抽出する抽出手段と、その抽出された受注明細を特定
した欠品対応リストを出力する欠品対応リスト出力手段
と、を備えたことを特徴とする請求項３に記載の受注管
理システム。
【請求項５】前記受注データ修正手段は、前記欠品対
応リストにて特定された受注明細を修正可能であること
を特徴とする請求項４に記載の受注管理システム。
【請求項６】前記特定の情報が、前記顧客、又は前記
受注データに含まれている商品の種類のいずれかである
ことを特徴とする請求項１〜５のいずれか１項に記載の
受注管理システム。
【請求項７】顧客としてのユーザー企業がその管理下
の複数の個店のそれぞれで発生した注文を統合して作成
した発注情報を取得し、その発注情報に基づいて個店毎
の受注データを特定する企業間受注処理手段を具備する
ことを特徴とする請求項１に記載の受注管理システム。
【請求項８】前記商品の供給に関する複数の拠点がシ
ステムの管理下に含まれるとともに、前記在庫データは
前記複数の拠点のそれぞれで区別して管理され、前記在
庫引当の可否は、前記複数の拠点のうち前記受注データ
に応じて個店毎に割り当てられる担当拠点についての在
庫データと前記個店毎の受注データとを比較して判断さ
れることを特徴とする請求項７に記載の受注管理システ
ム。
【請求項９】前記欠品登録処理が行われた受注データ
に対応する欠品情報が生成された場合、前記欠品情報出
力手段は、前記在庫引当が不可能と判断された受注明細
に対応するユーザー企業、担当拠点、商品及びその商品
の不足数量を特定した供給可能量不足リストを出力する
ことを特徴とする請求項８に記載の受注管理システム。
【請求項１０】既に受けた受注データを対象として、
前記在庫引当が不可能な受注明細とユーザー企業、担当
拠点及び商品が一致する複数の受注明細を抽出する抽出
手段と、その抽出された受注明細に対応する個店、商品
及びその商品に数量を特定した欠品対応リストを出力す
る欠品対応リスト出力手段と、を備えたことを特徴とす
る請求項９に記載の受注管理システム。
【請求項１１】前記受注データ修正手段は、前記欠品
対応リストにて特定されたいずれかの個店に関する受注
明細を修正可能であることを特徴とする請求項１０に記
載の受注管理システム。
【請求項１２】前記特定の情報が、前記ユーザー企業
を特定する情報であることを特徴とする請求項７〜１１
のいずれか１項に記載の受注管理システム。
【請求項１３】前記欠品登録処理又は前記欠品削除処
理の指定をオペレータからの指示に応じて設定する設定
手段を備えたことを特徴とする請求項１〜１２のいずれ
か１項に記載の受注管理システム。