(57)【特許請求の範囲】
【請求項１】
通信回線を介して情報処理装置から受信される、少なくとも商品の発注数量、発注時間および納期を示す情報を含む受注情報を受信する受信手段と、
前記受注情報、並びに、商品の在庫情報および出荷情報を管理するデータベースを参照して商品の在庫引当を制御する制御手段とを有し、
前記制御手段は、第一の受注情報に対して最寄の第一のブランチ倉庫について、発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第一のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第二の受注情報に対して引当が可能な在庫がマスタ倉庫にあるか否かの第一の判定を行い、
前記第一の判定によって、前記第一のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていないと判定し、かつ、前記引当の変更が不可能と判定した場合、または、前記第二の受注情報に対して引当が可能な在庫が前記マスタ倉庫にないと判定した場合は、前記第一の受注情報に対して次に近い第二のブランチ倉庫について、前記発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第二のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあるか否かを判定する第二の判定を行い、
前記第一または第二の判定によって、前記第一または第二のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていると判定した場合、または、前記引当の変更が可能と判定され、かつ、前記第二または第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあると判定した場合は、前記第一または第二のブランチ倉庫の在庫を前記第一の受注情報に引当てることを特徴とするサーバ装置。
【請求項２】
前記制御手段は、前記納期が当日の受注情報について前記第一および第二の判定を行って前記引当を行い、前記納期が当日ではない受注情報については、前記受注情報に対して最寄のブランチ倉庫に発注数量分の商品が引当可能に在庫されているか否かを判定し、前記ブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていると判定した場合は当該在庫を前記受注情報に引当て、前記ブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていないと判定した場合は販売者または製造者の在庫を確認し、前記販売者または製造者の在庫がなければバックオーダとすることを特徴とする請求項1に記載されたサーバ装置。
【請求項３】
サーバの制御方法であって、
通信回線を介して情報処理装置から受信される、少なくとも商品の発注数量、発注時間および納期を示す情報を含む受注情報を受信する受信ステップと、
前記受注情報、並びに、商品の在庫情報および出荷情報を管理するデータベースを参照して商品の在庫引当を制御する制御ステップを有し、
前記制御ステップは、第一の受注情報に対して最寄の第一のブランチ倉庫について、発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第一のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第二の受注情報に対して引当が可能な在庫がマスタ倉庫にあるか否かの第一の判定を行い、
前記第一の判定によって、前記第一のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていないと判定し、かつ、前記引当の変更が不可能と判定した場合、または、前記第二の受注情報に対して引当が可能な在庫が前記マスタ倉庫にないと判定した場合は、前記第一の受注情報に対して次に近い第二のブランチ倉庫について、前記発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第二のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあるか否かを判定する第二の判定を行い、
前記第一または第二の判定によって、前記第一または第二のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていると判定した場合、または、前記引当の変更が可能と判定され、かつ、前記第二または第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあると判定した場合は、前記第一または第二のブランチ倉庫の在庫を前記第一の受注情報に引当てることを特徴とする制御方法。
【請求項４】
前記制御ステップ手段は、前記納期が当日の受注情報について前記第一および第二の判定を行って前記引当を行い、前記納期が当日ではない受注情報については、前記受注情報に対して最寄のブランチ倉庫に発注数量分の商品が引当可能に在庫されているか否かを判定し、前記ブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていると判定した場合は当該在庫を前記受注情報に引当て、前記ブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていないと判定した場合は販売者または製造者の在庫を確認し、前記販売者または製造者の在庫がなければバックオーダとすることを特徴とする請求項3に記載された制御方法。
【請求項５】
情報処理装置を制御して、請求項3または請求項4に記載された制御を実行することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば、トナーカートリッジなどの商品の効率的かつ効果的な在庫、出荷および納期管理を行うサーバ装置およびその制御方法に関する。
【０００２】
【従来の技術】
電子写真方式を利用したプリンタ、複写機およびファクシミリ装置は、ビジネスを遂行する上で必須の機器である。これら電子写真方式を利用する機器は、トナーなどの消耗品を必要とする。もし、それらの消耗品が切れ、直ちに消耗品の補充ができなければ、それらの機器は利用不能になる。このような状況を防ぐために、各オフィスでは、消耗品の適正在庫を維持管理している。最近では、事業所全体で消耗品の適正在庫を維持管理するIMS(Information Manager of System)などと呼ばれる部署が存在する場合もある。
【０００３】
電子写真方式を利用する機器には、トナーカートリッジと呼ばれるカートリッジによってトナーが供給されるものがある。各機器には、その機種に応じたトナーカートリッジを装着する必要があり、同じプリンタでも機種が異なれば、大概は、異なるトナーカートリッジが必要になる。従って、多種類の機器を利用するオフィスや事業所では、多種類のトナーカートリッジを在庫し維持管理する必要がある。なお、トナーカートリッジに限らず、オフィスや事業所で消費されるすべてのビジネス用品は適正在庫の維持管理が要求される。以下では、トナーカートリッジのような物品を「ビジネス消耗品」と呼ぶ場合がある。「ビジネス消耗品」には、トナーカートリッジのほか、複写機用のトナー、感光ドラム、インクジェットプリンタ用のインク、その他サービスパーツ、紙やOHPシートなどを挙げることができる。
【０００４】
このような特性をもつビジネス消耗品の販売形態、在庫管理に関して、次に示すような要望がある。
【０００５】
［販売形態］
インターネットの普及に伴い、ビジネス消耗品の販売、注文にもインターネットの利用が望まれている。インターネットを利用して商品を販売するシステムは既に存在するが、即時に納期を回答しない場合があったり、納期までの長さが充分に顧客に応えるものではない場合がある。
【０００６】
［在庫管理］
従来から知られている在庫管理は、インターネット、電子メール、電話などを介して顧客から注文を受けると、注文ごとに在庫を引き当て、その引当情報を、顧客のプロフィール、注文数量、商品種別、納期などの情報と関連付けて在庫データベースで管理するものである。在庫データベースは、新たな受注がある都度、在庫数のチェックなどのために情報処理装置によって参照される。
【０００７】
上記の受注ごとに在庫を引き当て、かつ、在庫データベースによって在庫数を管理する在庫管理は、在庫データベースで管理された未引き当て在庫数を超える受注があった場合、在庫を引き当てることがきない。しかし、既に引き当て済みの在庫にも納品に緊急を要するもの、要しないものがあり、納品の緊急度を加味した在庫の引き当てを含む在庫管理が望まれる。
【０００８】
一方、代表的なビジネス消耗品である、複写機やプリンタなどに利用される記録剤を収納したトナーカートリッジは、トナー切れになれば複写機やプリンタが利用できないため、納品に緊急を要する注文が頻繁にあると想定される。納品に緊急を要する注文に対して、在庫不足のために商品を提供することができなければ、複写機やプリンタの不稼働時間を長くしてしまい、その結果、顧客の業務効率を低下させる問題がある。
【０００９】
【発明が解決しようとする課題】
本発明は、商品の効率的かつ効果的な在庫、出荷および納期管理を行うことを目的とする。
【００１１】
【課題を解決するための手段】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００１２】
本発明にかかる制御方法は、サーバの制御方法であって、通信回線を介して情報処理装置から受信される、少なくとも商品の発注数量、発注時間および納期を示す情報を含む受注情報を受信する受信ステップと、前記受注情報、並びに、商品の在庫情報および出荷情報を管理するデータベースを参照して商品の在庫引当を制御する制御ステップを有し、前記制御ステップは、第一の受注情報に対して最寄の第一のブランチ倉庫について、発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第一のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第二の受注情報に対して引当が可能な在庫がマスタ倉庫にあるか否かの第一の判定を行い、前記第一の判定によって、前記第一のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていないと判定し、かつ、前記引当の変更が不可能と判定した場合、または、前記第二の受注情報に対して引当が可能な在庫が前記マスタ倉庫にないと判定した場合は、前記第一の受注情報に対して次に近い第二のブランチ倉庫について、前記発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第二のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあるか否かを判定する第二の判定を行い、前記第一または第二の判定によって、前記第一または第二のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていると判定した場合、または、前記引当の変更が可能と判定され、かつ、前記第二または第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあると判定した場合は、前記第一または第二のブランチ倉庫の在庫を前記第一の受注情報に引当てることを特徴とする。
【００１４】
本発明にかかるサーバ装置は、通信回線を介して情報処理装置から受信される、少なくとも商品の発注数量、発注時間および納期を示す情報を含む受注情報を受信する受信手段と、前記受注情報、並びに、商品の在庫情報および出荷情報を管理するデータベースを参照して商品の在庫引当を制御する制御手段とを有し、前記制御手段は、第一の受注情報に対して最寄の第一のブランチ倉庫について、発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第一のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第二の受注情報に対して引当が可能な在庫がマスタ倉庫にあるか否かの第一の判定を行い、前記第一の判定によって、前記第一のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていないと判定し、かつ、前記引当の変更が不可能と判定した場合、または、前記第二の受注情報に対して引当が可能な在庫が前記マスタ倉庫にないと判定した場合は、前記第一の受注情報に対して次に近い第二のブランチ倉庫について、前記発注数量分の商品が引当可能に在庫されているか否かを判定し、前記発注数量分の商品が引当可能に在庫されていないと判定した場合は、前記第二のブランチ倉庫に在庫された引当済みの商品の引当の変更が可能か否かを判定し、前記引当の変更が可能と判定した場合は、前記引当の変更が可能と判定した第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあるか否かを判定する第二の判定を行い、前記第一または第二の判定によって、前記第一または第二のブランチ倉庫に前記発注数量分の商品が引当可能に在庫されていると判定した場合、または、前記引当の変更が可能と判定され、かつ、前記第二または第三の受注情報に対して引当が可能な在庫が前記マスタ倉庫にあると判定した場合は、前記第一または第二のブランチ倉庫の在庫を前記第一の受注情報に引当てることを特徴とする。
【００１８】
【発明の実施の形態】
以下、本発明にかかる商品の販売システムを図面を参照して詳細に説明する。なお、実施形態では電子写真方式のプリンタ、複写機、ファクシミリ装置などの機器に使用されるトナーカートリッジなどのビジネス消耗品を商品の一例として説明するが、他の商品にも本発明を適用することができる。例えば、複写機用のトナー、感光ドラム、その他サービスパーツ、紙やOHPシート、インクジェットプリンタ用のインクなどを挙げることができる。
【００１９】
【第１実施形態】
［トナーカートリッジの流れ］
図1は現状のトナーカートリッジの流れを説明する図である。
【００２０】
図1において、製造者1の工場11で生産計画に合わせて製造されたトナーカートリッジは、随時、製造者の倉庫12へ送られる。そして、注文が販売者3から製造者1へ入ると、販売者3（またはその倉庫）へ納入するのにかなり日数がかかる場合がある。販売者3からユーザ4へは、在庫があれば、遅くとも一日（注文の翌日）で納入可能である。
【００２１】
図2は本実施形態におけるトナーカートリッジの流れを示す図である。
【００２２】
図2において、製造者1の工場11で生産計画に合わせて製造されたトナーカートリッジは、随時、マスタ倉庫5へ送られる。マスタ倉庫5に一旦入荷したトナーカートリッジは、後述する出荷スケジュールに合わせて各地に分散配置された複数のブランチ倉庫6のB(x): x=1〜n（nはブランチ倉庫の数）へ配送される。詳細は後述するが、ユーザ4から注文が入ると、指定された出荷先に一番近いブランチ倉庫6のB(1)からユーザ4へトナーカートリッジが納入される。ただし、ブランチ倉庫6のB(1)に在庫がない場合は他のブランチ倉庫6のB(2)などから出荷されることがある。
【００２３】
図2に示すマスタ倉庫5は、トナーカートリッジの流れの中心になる主管的な倉庫であり、製造者1、販売者3あるいは物流業者などによって営まれる。ユーザ4との接点になるブランチ倉庫6は物流業者によって営まれるのが好ましい。
【００２４】
また、共有データベース  DB8は、工場11の生産、マスタ倉庫5およびブランチ倉庫6の在庫、ユーザ4の注文、さらに、工場11、マスタ倉庫5、ブランチ倉庫6、ユーザ4の物流を一元管理するものである。共有DB8による一元管理を行う目標としては、適切な生産、在庫および物流を実現し、ユーザ4から注文を受けたトナーカートリッジの例えば一日以内の納入を可能にする。
【００２５】
さて、図2に示すような、トナーカートリッジの流れを構築しシステム化することによって、ユーザは短期間に確実にトナーカートリッジを入手することができるとともに、希望した納期に対する納入可否の回答をすぐに得ることができる。従って、多種類のプリンタ、複写機、ファクシミリ装置を利用するオフィスや事業所における、多種類のトナーカートリッジの在庫の維持管理を容易にすることができる。さらに、小規模なオフィスや事業所であれば、例えば、トナーの残量がある閾値を割り、プリンタなどからトナーカートリッジの交換予告が通知された後にトナーカートリッジを発注すれば、在庫管理自体を不要にすることも可能になる。
【００２６】
言い換えれば、共有DB8により多種多様なトナーカートリッジの生産、物流、在庫、受注および配送を一元管理することにより、例えば、生産および受注に応じてマスタ倉庫5および複数のブランチ倉庫6の間でトナーカートリッジの在庫を調整することができる。従って、販売者3などの倉庫にビジネス消耗品を在庫しなくても、ユーザ4へトナーカートリッジを短期間に供給することができ、販売者3の在庫ぎれや過剰在庫に起因する問題、過剰在庫による金利負担増などを解消することができる。
【００２７】
以下では、図2に示すトナーカートリッジの流れを実現する販売システムを詳細に説明する。
【００２８】
メインサーバ81は、共有DB8を提供するサーバ装置である。なお、共有DB8は、一台のサーバ装置によって提供されるとは限らず、複数台のサーバ装置に分割されて、あるいは、並列に提供されることもある。つまり、共有DB8は、論理的に一つのデータベースとして提供されればよい。
【００２９】
メインサーバ81には、インターネットなどのワイドエリアネットワーク(WAN)100を介して、共有DB8を利用する複数の端末装置が接続される。端末装置13、31、41、51、61および71はそれぞれ製造者1、販売者3、ユーザ4、マスタ倉庫5、ブランチ倉庫6の端末である。また、端末装置32は販売者3のセールスマンやサービスマンが使用するモバイル端末、端末装置62は物流業者の配送係が使用するモバイル端末である。
【００３０】
図2に示されるメインサーバ81の内部構造について、図19を参照して説明する。
【００３１】
図19に示されるように、メインサーバ81は、CPU(Central Processing Unit)2501、入力装置2502、主記憶装置2503、出力装置2504、補助記憶装置2505および通信装置2506などから構成される。
【００３２】
処理装置であるCPU2501は、システム内の各装置に命令を送り、その動作を制御する制御機能、並びに、サーバの中心的な部分でディジタルデータの演算処理を行う機能を有する。
【００３３】
入力装置は2502は、各種データを入力するための装置で、例えばキーボード、マウスなどのポインティングデバイス、タッチパネル、感圧パッド、CCDカメラ、カード読取機、紙テープ読取機、磁気テープ装置などが考えられる。例えば、図6のインタフェイス画面を介して、マウスなどの入力装置2502から指示データが入力される。CPU2501は、入力された情報を認識し、次の処理に移行する。
【００３４】
主記憶装置2503とは、各処理装置および内部記憶装置において、命令を実行するために使われるアドレス可能なメモリ空間全体を指す。主記憶装置2503は、主として半導体素子により構成され、入力したプログラムやデータを格納、保持する、CPU2501は、メモリに保持されているデータを例えばレジスタに読み出す。主記憶装置2503を構成する半導体素子としては、RAM(Random Access Memory)やROM(Read Only Memory)などである。図5のユーザインタフェイスを介して入力されたID、パスワード情報は主記憶装置2503に一時記憶され、一時記憶された情報はCPU2501により通信装置2506を介して送信される（図4のステップS1に対応）。また、図5のユーザインタフェイスを表示するための表示用メモリとしての機能も有する。
【００３５】
出力装置2504は、CPU2501による演算結果を出力するための装置で、例えばCRT、プラズマディスプレイ、液晶ディスプレイ、その他の表示装置、プリンタなどの印刷装置、音声出力装置などが該当する。本実施形態では、例えば、図3に示される各端末装置の表示装置が出力装置2504に該当する。
【００３６】
補助記憶装置2505は、主記憶装置2503の記憶容量を補うため、不揮発にデータを保持するための装置で、例えば磁気ディスク装置、光ディスク装置、半導体ディスク装置、並びに、フロッピーディスク、CD-ROM、CD-R、CD-R/W、MO、DVDなどのメディアおよびドライブが該当する。補助記憶装置2505は、データベースの機能を実現するための装置で、本実施形態においては、例えば共有DB8が補助記憶装置2505に該当する。また、主記憶装置と同様にプログラムを格納する機能も有している。
【００３７】
通信装置2506は、外部のネットワークと通信を行うための装置で、接続されるネットワークに応じて適宜データの送受信やデジタル/アナログ変換などを行う。本実施形態においては、例えば図4の各ステップにおいて送信されるデータは、CPU2501の制御下で、通信装置2506を介して送信される。
【００３８】
上述した各装置は、アドレスバスまたはデータバスにより相互に接続されており、双方向の各種データの通信に利用される。
【００３９】
［共有データベース］
共有DB8には、下に一例を示すようなデータベースおよびそのフィールド情報が格納されている。これらの情報は、図3に示す各端末装置へ提供されるとともに、それら端末装置により更新される。なお、下に示すデータベースおよびそのフィールドは、販売回収システムの対象とするユーザやビジネス消耗品の特性などに応じて、追加または削除される場合がある。
【００４０】
●販売者情報データベース
販売者IDおよびパスワード
名称、住所、電話番号およびファクシミリ番号
電子メールアドレス
顧客担当者情報
販売実績情報
在庫情報
●倉庫情報データベース
マスタ倉庫情報
ブランチ倉庫情報
マスタ-ブランチ間連結情報
倉庫別在庫情報
倉庫出荷可能在庫情報
倉庫別出荷指示在庫情報
倉庫別出荷指示待ち在庫情報
推定納品時間
なお、在庫ステータスおよび、倉庫について今後以下の用語を用いる。
未引当在庫(出荷可能在庫）：どの注文からも引当をされていない在庫。
出荷指示待ち在庫：仮の引当がされているが、出荷までに時間的な余裕がある在庫。納期のより早い注文がはいった場合、引当が変更になる場合がある（顧客に対しては納期回答を行っている）
出荷指示在庫：注文に対して引当が行われている在庫（顧客に対しては納期回答を行っている）
M倉庫（マスタ倉庫）：全国に一箇所（または数箇所）を想定し、商品は工場などから一度この倉庫に入庫する。
B(x)倉庫（x=1〜n、ブランチ倉庫）：顧客に出荷する場合は原則これらの倉庫から出荷される。B1はある注文の出庫先から一番近い倉庫。B2、B3になるほど遠くなる（nはブランチ倉庫の数）
【００４１】
マスタ倉庫情報やブランチ倉庫情報には、それら倉庫の所在地などが含まれる。また、マスタ-ブランチ間連結情報には、マスタ倉庫5からブランチ倉庫6へ物品を配送するのに必要な時間、および、ブランチ倉庫6相互間で物品を配送するのに必要な時間を示す情報などが含まれる。さらに、倉庫別在庫情報には、上記の他、各倉庫の適正在庫量を示す情報などが含まれる。
【００４２】
メインサーバ81は、これらの情報に基づき、マスタ倉庫5からブランチ倉庫6への在庫移動、および、複数のブランチ倉庫6に対する配送の振り分けを制御することができる。また、ユーザ4から受注したトナーカートリッジが最寄りのブランチ倉庫6のB(1)にない場合、ユーザ4の希望納期で、または、次善の納期で納品できるように出荷先の地理情報に対して次に優先順位の高いブランチ倉庫6のB(2)の在庫を引き当てるなどを制御することができる。
【００４３】
●製品情報データベース
製品名および型番
関連消耗品
製品別在庫情報
価格情報
●顧客情報データベース
ユーザIDおよびパスワード
名称、住所、電話番号およびファクシミリ番号
電子メールアドレス
担当販売者、セールスマンおよびサービスマン
最寄りのブランチ倉庫#1および  出荷先までの推定納品時間
最寄りのブランチ倉庫#2および  出荷先までの推定納品時間
：
：
：
最寄りのブランチ倉庫#nおよび  出荷先までの推定納品時間
購入製品名（型番）および数
発注履歴
支払履歴
価格情報
●出荷情報データベース
出荷先顧客情報
ステータス
注文番号
注文日時
注文アイテム
納期
価格
支払方法
出荷日時
着荷日時
検収日時
●製造者、販売者情報、物流業者情報
製造者IDおよびパスワード
販売者IDおよびパスワード
セールスマンIDおよびパスワード
サービスマンIDおよびパスワード
倉庫IDおよびパスワード
配送係IDおよびパスワード
【００４４】
［発注シーケンスおよび画面］
図4はトナーカートリッジの発注シーケンスの一例を示す図、図5から図12はトナーカートリッジの発注時にユーザ4の端末装置41に表示される画面の一例を示す図である。
【００４５】
まず、ユーザ4は、端末装置41を介してメインサーバ81にアクセスする。つまり、ユーザ4は、端末装置41で稼動するWebブラウザなどのソフトウェアによりメインサーバ81のURL(Uniform Resource Locator)を指定する。これに応じてメインサーバ81から、ログイン画面に対応するHTML(Hyper Text Markup Language)で記述されたデータ（以下「HTMLデータ」と呼ぶ）が端末装置41に供給され、端末装置41のモニタに図5に示すログイン画面が表示される。なお、HTMLデータはXML(eXtensible Markup Language)で記述することもできる。
【００４６】
ユーザ4は、図4に示すステップS1で、お客様番号に対応するユーザIDを入力し、パスワードを入力した後、[OK]ボタンを押して、ユーザIDおよびパスワードをメインサーバ81に通知する。なお、ユーザIDおよびパスワードは、プリンタなどのユーザ（オフィスや事業所）単位に、予め販売者3によって通知されているものとする。
【００４７】
ユーザIDおよびパスワードを通知されたメインサーバ81は、ステップS2で、顧客情報データベースを参照して、通知されたユーザIDおよびパスワードに対応するユーザが存在するか否かを判定する。そして、対応するユーザが存在すればユーザ承認を経て、注文画面に対応するHTMLデータを生成し端末装置41に供給する。これにより、端末装置41のモニタには図6に示す注文画面が表示される。
【００４８】
図6に示す注文画面は、主に、ユーザが利用している機器に対応するトナーカートリッジのリスト101、決済方法の選択部102、納期の指定部103および使用済みトナーカートリッジの回収への参加申し込み部104から構成される。なお、納期の指定部103は、下記の[]で括った部分がブルダウンし、休日や祭日を除く営業日が指定できるプルダウンメニュー形式が望ましい。その場合、対応メッセージは「ご希望の納期をプルダウンメニューによって指定し、午前/午後の配達時間帯を指定してください」のようになる。
(例)  納期[今日]（6月30日）  ○午前  ●午後
【００４９】
リスト101には、トナーカートリッジの型番および対応する機器の型番、並びに、価格が表示され、トナーカートリッジの型番ごとに注文数を入力するための入力枠が備わっている。なお、図6には、二種類のトナーカートリッジしか示さないが、実際には、ユーザが利用しているプリンタ、複写機、ファクシミリ装置などの機種すべてに対応するトナーカートリッジの型番がリストされる。
【００５０】
ユーザが利用している機器の情報は、顧客情報データベースの購入製品名フィールドから得られる。この情報に対応する製品名または型番を有するレコードを製品情報データベースから検索し、そのレコードの関連消耗品フィールドからトナーカートリッジの型番を導き出すことができる。
【００５１】
発注画面の所定項目が入力された後、[送信する]ボタンが押されるとステップS3で、リスと101に対応する注文アイテムおよび注文数のデータ、選択部102に対応する決済方法のデータ、指定部103に対応する希望納期のデータがメインサーバ81へ送られる。
【００５２】
次に、メインサーバ81は、受信したデータおよびフラグに従い、ステップS4で注文確認画面に対応するHTMLデータを生成し端末装置41に供給する。これにより、端末装置41のモニタには図7に示す注文確認画面が表示される。
【００５３】
ユーザ4は、ステップS5で、注文確認画面を参照して、注文内容が正しければ[OK]ボタンを押す。また、誤りや訂正したい内容があれば[Cancel]ボタンを押す。[Cancel]ボタンが押された場合は、端末装置41のモニタに、再び注文画面が表示される。
【００５４】
メインサーバ81は、注文確認を受信すると、新規受注を示す情報を生成する。この情報には、注文番号、ユーザID、発注履歴、担当の販売者ID、注文日時、注文アイテム、注文数、希望納期、価格および支払方法などのデータが含まれる。
【００５５】
メインサーバ81は、ステップS6で顧客の希望納期に対して顧客情報データベースおよび倉庫情報データベースを用いて納期を判定する。顧客の注文希望納期が緊急であるか通常であるかによって分類する。ブランチ倉庫毎の在庫情報、他の注文情報、各倉庫と出荷先の地理情報などから最も適正な倉庫から出庫引当を行う。顧客の注文希望納期が緊急である場合、既に仮の引当が済んでいる他の注文希望納期が緊急でない注文に対して優先的に引当を行うことができる。
【００５６】
次に、メインサーバ81は、ステップS7で上記の受注情報に価格確認要求を含めて、ユーザ4を担当する販売者3へ送る。これは、ユーザへの納入価格は販売者3によって設定され、ユーザとの取引状況によって納入価格が変動するので、それを確認する必要があるからである。この価格確認要求は、販売者3の端末装置31上で稼働するソフトウェアによりただ直ちに処理され、ステップS8で価格確認または発注取消などの情報がメインサーバ81に返される。または、この価格確認要求は、ユーザの担当セールスマンの携帯端末32に送信され、ステップS8で、価格確認または発注取消などの情報がセールスマンによって携帯端末32を通してメインサーバ81に送信される。
【００５７】
メインサーバ81は、価格確認を受信した場合は直ちに、ステップS9で受注情報に発注承認要求を含めて製造者1へ送る。この発注承認要求は、製造者1の端末装置13上で稼働するソフトウェアにより直ちに承認処理されるか、または、端末装置13を管理するオペレータにより直ちに承認処理され、ステップS10では通常は発注承認が、メインサーバ81に返される。また、価格に誤りがあり、発注取消を示す情報を受信した場合は、対応する受注情報に対して、ステータスを例えば「取消」という形式に変更する。
【００５８】
次に、ステップS11で納期情報をユーザ送信する。ユーザ希望納期どおりであればこのステップで納期が確定するが、納期どおり出荷できない場合、ユーザは、図11に示すような所定の画面において、納期変更承認、または注文キャンセルの選択を行う。このユーザ情報はステップS12でメインサーバ81に送信される。
【００５９】
メインサーバ81は、納期どおり出荷できる場合、または、ステップS12で納期変更が承認された場合は、図10に示すようなユーザのログイン画面をHTMLデータで表示するとともに、発注確認を示す電子メールを生成し、その電子メールをユーザ4および販売者3に送信する。この電子メールには、注文番号、ユーザ名称、注文日時、注文アイテム、納入数、納期、価格および販売者3の情報（名称、住所、電話番号およびファクシミリ番号）などの情報が含まれる。
【００６０】
また、受注情報におけるステータスが発注取消を示すステータスである場合は、図12に示すようなユーザのログイン画面にHTMLデータで表示するとともに、発注取消確認を示す電子メールを生成し、その電子メールをユーザ4および販売者3に送信する。この電子メールには、発注取消理由、注文番号、ユーザ名称、注文日時、注文アイテム、納入数、納期、価格および販売者3の情報（名称、住所、電話番号およびファクシミリ番号）などの情報が含まれる。
【００６１】
以上でトナーカートリッジの発注シーケンスは終了する。ただし、図4には示さないが、ステップS5でユーザ4が注文確認を送った後、ユーザ4の端末装置41のモニタには図8に示すような注文の継続、注文内容の再確認あるいは注文の終了（ログアウト）を選択するための画面が表示される。ユーザ4が[logout]ボタンを押せば、メインサーバ81と端末装置41との接続が解除される。
【００６２】
［メインサーバの処理］
次に、メインサーバ81が実行する代表的な処理を説明する。
【００６３】
●受注処理
図13は受注処理の一例を示すフローチャートで、図4に示す発注シーケンスに対応するものである。
【００６４】
ユーザ4からユーザIDおよびパスワードが送られてくると、顧客情報データベースに基づき、ステップS21で登録ユーザか否かの判定が、ステップS22でパスワードの認証が行われる。登録ユーザであり、パスワードの認証にも成功した場合は、顧客情報データベースに基づき、ステップS23でユーザ4に関する不正情報があるか否かが判定され、なければステップS24で注文画面のHTMLデータを生成する。具体的には、ユーザIDに応じて図6および図9に示すリスト101および選択部102が生成され、さらに、図6に示す参加申し込み部104を表示させるか、図9に示す表示部105を表示するかが決定される。このようにして生成された注文画面のHTMLデータは、ステップS25でユーザ4へ送信される。
【００６５】
なお、登録ユーザではない、パスワードの認証に失敗した、並びに、ユーザ4に関する不正情報がある場合、処理は終了される。
【００６６】
続いて、ステップS26で注文データが受信されると、ステップS27で注文データに異常なデータが含まれるか否かが判定され、異常なデータが含まれれば処理はステップS25へ戻される。また、異常なデータが含まれなければステップS28で、注文データに基づき図7に示す注文確認画面のHTMLデータが生成され、ステップS29でユーザ4へ送信される。
【００６７】
ステップS30で注文確認を示すデータが受信されたか否かを判定し、もし、キャンセルを示すデータが受信された場合、処理はステップS25へ戻される。また、注文確認を示すデータが受信された場合は、ステップS31で納期回答情報を作成し、ステップS32で納期どおり出荷できるか否かが判定される。そして、納期どおり出荷できるか否かで、図10に示す確認画面106を表示するか、図11で示す注文確認部107、108を表示するかが決定される。なお、ステップS31の納期回答情報の作成に関する詳細な処理は後述する。
【００６８】
納期どおり出荷できない場合は、ステップS33でユーザよる注文をキャンセルを示すか否かのデータが生成され、キャンセルを示すデータが受信された場合は、処理を終了する。ステップS32で納期どおり出荷できると判定された場合、または、ステップS33でOKを示すデータが受信された場合は、ステップS34で顧客データベース（具体的には発注履歴など）が更新され、ステップS35で受注情報が生成される。
【００６９】
●納期確認および出荷処理
図14から図16は受注情報に基づく在庫確認、納期回答および出荷処理の一例を示す図で、上述した納期回答情報の作成の基本になる処理である。なお、以下で説明するマスタ倉庫に対応する処理、および、各ブランチ倉庫に対応する処理は、実際には、ひとまとめの処理としてメインサーバ81で実行されるが、ネットワーク化されたマスタ倉庫5および各ブランチ倉庫6で行われる、独立した処理として構成することもできる。
【００７０】
ステップS41で一つの受注情報が読み込まれる。そして、受注情報に記録されたユーザID、注文アイテムおよび注文数に基づき、納期確認および出荷処理が開始される。
【００７１】
ステップS42で、ユーザIDに対応する最寄りブランチ倉庫#1フィールドを参照して最寄りのブランチ倉庫6のB(1)を調べ、顧客の希望納期に対して顧客情報データベースおよび倉庫情報データベースを用いて納期を判定する。ステップS43で、最寄りブランチ倉庫#1フィールドによって示されるブランチ倉庫6のB(1)へ注文データを送る。
【００７２】
注文データを受けたブランチ倉庫6のB(1)は、ステップS51で顧客の注文希望納期が緊急（例えば当日納期）であるか、通常であるかを判定する。注文希望納期が緊急である場合、ステップS52で倉庫別在庫情報フィールドを参照して、ブランチ倉庫6のB(1)に注文数分の注文アイテムが引当可能ステータスで在庫されているか否かを判定する。引当可能な在庫があればステップS55で、その在庫を注文に引き当てる。
【００７３】
また、引当可能な在庫がない場合はステップS53で、引当済み在庫の引当を変更できるか否かを調べる。例えば、納期が緊急ではない他の注文（以下「被引当変更注文」と呼ぶ）に引き当てられている在庫であれば引当の変更が可能である。引当の変更が可能な場合、ステップS54で、被引当変更注文に対して引当可能な在庫がマスタ倉庫5にあるか否かを調べ、引当可能な在庫がマスタ倉庫5にあればステップS55で、その在庫を注文に引き当て、ステップS56で、被引当変更注文の出荷指示待ちステータスを緊急納期の出荷指示ステータスに変更する。
【００７４】
通常、最寄りブランチ倉庫#1フィールドに登録されたブランチ倉庫6のB(1)に在庫があれば短時間で納入可能である。
【００７５】
もし、上述のステップを経てもブランチ倉庫6のB(1)に引当可能な在庫が見付からない場合はステップS57で、倉庫情報データベースを利用してユーザIDに対応するブランチ倉庫#2フィールドを参照して、次にユーザの所在地に近いブランチ倉庫6のB(2)を調べる。そして、ステップS58で、ブランチ倉庫#2フィールドによって示されるブランチ倉庫6のB(2)へ注文データを送る。
【００７６】
注文データを受けたブランチ倉庫6のB(2)は、ステップS61で配送先は当日納期を満たせる場所か否かを判定する。
【００７７】
図17は、ステップS61で行われる当日納期を満たせるか否かの判定を説明するフローチャートである。
【００７８】
ステップS81で倉庫コードを取得し、ステップS82で配送先の住所を得て、これらの情報を基に、ステップS83で、図18に一例を示す倉庫データベースの推定納品時間テーブルから倉庫から出荷先までの納品に要する時間の推定値である推定納品時間を取得する。続いて、ステップS84で、推定納品時間に基づき、何時までに注文された商品を出庫すればよいかを示す出庫時間を計算し、ステップS85で、出庫時間および現在の時間から当日納期を満たせるか否かを判定する。そして、当日納期を満たせればステップS86で処理をステップS62へ進め、当日納期を満たせなければステップS87で処理をステップS63へ進める。
【００７９】
配送先の住所は例えば七桁の郵便番号などで代用することができる。また、推定納品時間は、商品を配送する曜日や時間帯ごとに実測値やVICS（高度道路情報システム）などのデータを蓄積することで、より詳細な推定値を蓄積することができる。なお、出庫時間の計算に関しては、その商品を配送する便が他の倉庫や他の配送先を経由することを考慮する必要がある。
【００８０】
当日納期を満たせる場合はステップS62で、ブランチ倉庫6のB(1)と同様の在庫確認および引当処理を行う。もし、当日納期を満たせない場合はステップS63で注文データをマスタ倉庫5（マスタ倉庫フィールド）へ戻し、引当可能な在庫が見付からない場合はステップS64で次にユーザの所在地に近いブランチ倉庫6のB(3)へ注文データを送る。
【００８１】
ブランチ倉庫#x (x=1〜n)フィールドから、当日納期を満たせるブランチ倉庫が見付からない場合はマスタ倉庫5（マスタ倉庫フィールド）に注文データが戻される。
【００８２】
注文データが戻されたマスタ倉庫5はステップS44で、在庫情報フィールドから引当可能な在庫があるか否かを判定する。引当可能な在庫があればステップS45で、その在庫を注文に引き当てる。
【００８３】
ブランチ倉庫6またはマスタ倉庫5で引当可能な在庫が見付かった場合は、ステップS55またはS45で在庫ステータスが出荷指示になった後、ステップS46で注文ステータスを「受注」に変更し、顧客の納期確認画面（図12）および図13の納期回答情報を更新して、納期を回答する。この納期回答を判定して(S47)、顧客が承認した場合はステップS48で納品手続（出庫指示、受注情報の更新（納品済フラグをオンにするなど）および在庫移動処理など）を行う。また、この納期回答に対して、顧客が注文を取り消せばステップS49で、変更した引当やステータスを復帰し、処理を終了する。
【００８４】
もし、ステップS44で引当可能な在庫が見付からない場合はステップS50で、販売者3や製造者1に引当可能な在庫がないか探す処理が行われる。販売者3に引当可能な在庫がある場合は納品を販売者3に依頼する。この依頼に応じて販売者3は、例えばサービスマンに納品させる。この場合、サービスマンのモバイル端末32から入力される情報に基づき、受注情報に対応する納品が行われたか否かが判定される。もし、製造者1にも在庫がない場合はバックオーダ手続および受注情報の更新が行われる(S51)。
【００８５】
次に、顧客の注文希望納期が緊急（当日）ではない場合はステップS44で、倉庫別在庫情報フィールドからブランチ倉庫6のB(1)に引当可能な在庫があるか否かを判定する。ブランチ倉庫6のB(1)に引当可能な在庫がなければ、マスタ倉庫フィールドに注文データを送り、在庫情報フィールドから引当可能な在庫があるか否かを判定する。引当可能な在庫があればステップS45で、その在庫ステータスを出荷指示待ちに変更する。
【００８６】
ブランチ倉庫6またはマスタ倉庫5で引当可能な在庫が見付かった場合は、ステップS45で在庫ステータスが出荷指示待ちになった後、ステップS46で注文ステータスを「受注」に変更し、顧客の納期確認画面（図12）および図13の納期回答情報を更新して、納期を回答する。この納期回答を判定して(S47)、顧客が承認した場合はステップS48で納品手続（出庫指示、受注情報の更新（納品済フラグをオンにするなど）および在庫移動処理など）を行う。また、この納期回答に対して、顧客が注文を取り消せばステップS49で、変更した引当やステータスを復帰し、処理を終了する。
【００８７】
もし、ステップS44で引当可能な在庫が見付からない場合はステップS50で、販売者3や製造者1に引当可能な在庫がないか探す処理が行われる。販売者3に引当可能な在庫がある場合は納品を販売者3に依頼する。この依頼に応じて販売者3は、例えばサービスマンに納品させる。この場合、サービスマンのモバイル端末32から入力される情報に基づき、受注情報に対応する納品が行われたか否かが判定される。もし、製造者1にも在庫がない場合はバックオーダ手続および受注情報の更新が行われる(S51)。
【００８８】
上述したように、緊急の注文により、注文ステータスが変更になる場合がある。この場合、ステップS71で注文ステータスを変更する指示が入ると、ステップS72で被引当変更注文に対応する在庫ステータス（出荷指示待ち）を未引当に変更し、ステップS73で緊急の注文に対応する在庫ステータス（未引当）を出荷指示に変更する処理が行われる。そして、被引当変更注文については、ステップS74でマスタ倉庫フィールドに注文データを送る。なお、ステップS71で注文ステータスの変更指示がない場合は、設定された時間に、在庫ステータスが「出荷指示待ち」から「出荷指示」に変更される。
【００８９】
【第２実施形態】
以下、本発明にかかる第2実施形態の消耗品の販売システムを説明する。なお、本実施形態において、第1実施形態と略同様の構成については、同一符号を付して、その詳細説明を省略する。
【００９０】
また、以下では説明を簡単にするために、ブランチ倉庫を一つとし、消耗品をプリンタLBP A用のトナーカートリッジA CRGに限定して説明するが、ブランチ倉庫ごとに、消耗品の品名や型番を含めて下記の処理を行えば、複数のブランチ倉庫において多種多様な消耗品の取り扱いが可能なことは、当業者であれば容易に理解される。
【００９１】
図20は第2実施形態における注文画面の一例を示す図で、図6に示した注文画面に、ユーザが当日納期を設定するための構成111を含めたものである。なお、当日納期の設定は、必要な消耗品および数を指定した後に可能になるが、図20ではA CRG、1000個が既に指定されている例を示している。
【００９２】
ここで、緊急の納品を望むユーザが当日ボタン112を押すと、納期入力欄に納期として当日が自動的に入力される。なお、当日ボタン112の日付情報は、メインサーバ81からユーザ端末41に発注画面が供給される度に随時更新されが、その更新の仕組みは、メインサーバ81またはユーザ端末41の時計機能を利用する形態でもよい。
【００９３】
図21Aから図21Cは受注情報に基づく在庫確認、納期回答および出荷処理の一例を示すフローチャートで、図3に示すメインサーバ81によって実行される処理である。
【００９４】
公衆回線などの通信回線を介して、遠隔に位置するユーザ端末41から新規に受注情報を受信すると(S101)、図22に一例を示す受注情報から注文数NQ、納期DDおよび時間情報（注文日PDおよび注文時間PTを含む）、商品種別（不図示）を取得し(S102)、システムに予め設定された、当日出荷の限界を示す当日出荷注文締め時間DTなども取得する(S103)。
【００９５】
次に、図22に示す受注情報から取得される商品種別情報を基に、図23Aに一例を示す、データベースのA CRGの受注状況テーブルを参照して、その出荷指示フィールドの倉庫フラグが「BW」、かつ、出荷フラグが「出荷指示待ち」の受注レコードの件数mを取得する(S104)。なお、倉庫フラグ「BW」はブランチ倉庫の在庫を、「MW」はマスタ倉庫の在庫であることを示す。また、この時点で、受信した受注情報は受注状況テーブルに未登録である。
【００９６】
続いて、倉庫フラグが「BW」、かつ、出荷フラグが「出荷指示待ち」の受注レコードの注文数NQの合計ΣNQm（以下「出荷指示待ち在庫数」と呼ぶ）を得る(S105)。図23Aの例ではΣNQmは1700である。
【００９７】
次に、図24Aに一例を示す、データベースのA CRGの在庫テーブルを参照して、ブランチ倉庫にあるA CRGの未引当在庫数BSを取得し(S106)、マスタ倉庫にあるA CRGの未引当在庫数MSを取得する(S107)。図24Aの例ではBSは零、MSは10000である。
【００９８】
以上の処理によってA CRGの在庫数を把握すると、マスタ倉庫およびブランチ倉庫の未引当在庫数の和MS + BSに、出荷指示待ち在庫数ΣNQmを加えた数（以下「出荷可能数NE」と呼ぶ）と、新規の受注情報の注文数NQとを比較する(S108)。
【００９９】
もし、NE < NQの場合は、通常の処理は不可能であり、例外処理を実行し(S109)、処理をステップS101へ戻す。なお、通常、マスタ倉庫は充分な在庫を抱えているので例外処理が発生する確率は極めて小さい。例外処理には、バックオーダ処理、納期調整や生産調整などが含まれる。
【０１００】
他方、NE≧NQの場合は、当日出荷注文締め時間DTと注文時間PTとの比較(S110)、並びに、納期DDおよび注文日PDとの比較(S111)の結果によって処理を分岐する。つまり、当日出荷注文締め時間DT前の注文か否か、当日納期(DD = PD)か否かをチェックし、当日納期であれば図21Bに示す処理へ、当日納期でなければ図21Cに示す処理へ分岐する。
【０１０１】
［当日納期の場合］
当日納期の場合は図21Bに示す処理へ分岐して、ブランチ倉庫にあるA CRGの未引当在庫数BSと新規の受注情報の注文数NQとの比較(S121)、並びに、未引当在庫数BSに出荷指示待ち在庫数ΣNQmを加えた数と新規の受注情報の注文数NQとの比較(S122)の結果によって処理を分岐する。
【０１０２】
つまり、BS≧NQであればブランチ倉庫の未引当在庫のA CRGの一部または全部を新規の受注に引き当てればよく、この場合は処理をステップS127へ進める。また、BS < NQで、かつ、BS +ΣNQm≧NQであれば在庫フラグが「出荷指示待ち」の受注レコードに引き当てられたA CRGを新規の受注に引き当て直すために処理をステップS123へ進める。上記の何れでもなければ（BS +ΣNQm < NQ）、ブランチ倉庫に存在する、新規の注文に引き当て（または引き当て直し）可能なA CRGの数では、新規の受注情報の注文数NQを満たすことはできす、少なくとも不足分のA CRGをマスタ倉庫から取り寄せる必要があるので、この場合は処理をステップS130へ進める。
【０１０３】
BS < NQかつBS +ΣNQm≧NQの場合は、「出荷指示待ち」の受注レコードに引き当てられたA CRGを新規の受注に引き当て直すために、図23Bに示すように、出荷フラグが「出荷指示待ち」の受注レコードの納期を遅い順に示す注文情報番号P(m)を設定する(S123)。そして、注文情報番号の順、つまり納期が遅い順に受注レコードの注文数NQを変数Qに加算し(S124)、加算結果のQ（ΣNQ）と未引当在庫数BSの和が新規の受注の注文数NQ以上（Q + BS≧NQ）になるまで(S125)、ステップS124の加算を繰り返す。なお、図24Bに示すP(2)およびP(3)は同日納期であり、図示はしないが、P(3)がP(2)に比べてより早い納期である。
【０１０４】
そして、Q + BS≧NQが満たされると、変数Qに加算された受注レコードの倉庫フラグを「MW」に、出荷フラグを「出荷指示」に変更する(S126)。新規の受注の注文数NQが1000だとすると、図25に示すP(1)およびP(2)の受注レコードの注文数NQを加算した時点でΣNQ=1100であるから、図23Cに示すように、注文番号123-3および123-4の受注レコードの出荷指示フラグが変更されて、その受注レコードに対応する数のA CRGがマスタ倉庫からブランチ倉庫へ発送されるように処理される。なお、ステップS123からS126の処理を「緊急処理」と呼ぶ。
【０１０５】
なお、上記では、注文情報番号P(m)を、納期をパラメータとしてソートするような処理を説明したが、効率のよいソーティング方法であればどのような方法を適用してもよい。例えば、予め各注文情報に優先度の属性情報を付属させることにより、ステップS123の処理を優先度の属性情報に基づき行うことも可能である。この方法によれば、例えば、同じ納期の受注情報が複数存在するとしても、優先度の属性情報により、どの受注情報からステップS125の処理対象にするかを容易に決定することができる。
【０１０６】
緊急処理が終わると、または、BS≧NQの場合は、新規の受注情報に基づく受注レコードを受注状況テーブルに追加する(S127)。図23Dに示すように、追加される受注レコードの出荷指示フラグは「BW」および「出荷指示」に設定される。
【０１０７】
続いて、図25に一例を示す当日納期可能を示す画面情報をユーザの端末装置41へ送り(S128)、出荷指示フラグの変更および/または受注レコードの追加に伴い、図24Bに示すように在庫テーブルを更新する(S135)。
【０１０８】
他方、BS +ΣNQm < NQの場合は、新規の受注情報に基づく受注レコードを受注状況テーブルに追加し(S130)、図26に一例を示す当日納期不可を示す画面情報をユーザの端末装置41へ送り(S131)、ユーザの応答を判定する(S132)。ユーザの応答が「キャンセル」であれば該当する受注レコードを受注状況テーブルから削除し(S133)、「注文」であれば、図23Eに示すように、該当する受注レコードの出荷指示フラグを「MW」および「出荷指示」に設定し(S134)、在庫テーブルを更新し(S135)、その後、処理をステップS101へ戻す。
【０１０９】
ステップS125の処理により、既に在庫が引き当てられた受注情報に付された緊急度を加味した在庫データベースの管理が実現される。また、ステップS128およびS131の処理により、ステップS108、S121、S122およびS125における、様々な在庫チェック処理が施された適切な結果を、ユーザ端末41に即座に通知することが可能になる。
【０１１０】
［翌日以降の納期の場合］
翌日以降の納期の場合は図21Cに示す処理へ分岐して、ブランチ倉庫にあるA CRGの未引当在庫数BSと新規の受注情報の注文数NQとの比較(S141)、当日出荷注文締め時間DT後の注文か否かの判定(S142)、および、翌日納期か否かの判定(S143)に応じて処理を分岐する。
【０１１１】
BS < NQの場合は、新規の受注情報に基づく受注レコードを受注状況テーブルに追加し、出荷指示フラグを「MW」および「出荷指示」に設定して(S144)、受注レコードに対応する数のA CRGがマスタ倉庫からブランチ倉庫へ発送されるように設定する。
【０１１２】
また、BS≧NQ、当日出荷注文締め時間DT以降の注文、かつ、翌日納期の場合は、新規の受注情報に基づく受注レコードを受注状況テーブルに追加し、出荷指示フラグを「BW」および「出荷指示」に設定する(S145)。これは、当日出荷注文締め時間DTを過ぎているので、この受注レコードに引き当てた在庫が、緊急処理によって後続の受注に引き当て直されることはないからである。
【０１１３】
上記の何れにも該当しない場合は、新規の受注情報に基づく受注レコードを受注状況テーブルに追加し、出荷指示フラグを「BW」および「出荷指示待ち」に設定する(S146)。
【０１１４】
続いて、図27に一例を示す納期回答を示す画面情報をユーザの端末装置41へ送り(S147)、出荷指示フラグの変更および/または受注レコードの追加に伴い、在庫テーブルを更新し(S148)、その後、処理をステップS101へ戻す。
【０１１５】
なお、上記の説明では、ブランチ倉庫の未引当の在庫が注文数を満たさない場合などは、必要数の消耗品がマスタ倉庫からブランチ倉庫へ移動されると説明した。配送効率を考慮すれば、消耗品をマスタ倉庫からブランチ倉庫へ移動した後、ブランチ倉庫からユーザ（顧客）が指定する納品場所へ発送するのが望ましい。しかし、注文数やマスタ倉庫と納品場所との関係を考慮して、マスタ倉庫から納品場所へ直接納品することも可能である。
【０１１６】
このように、図21Aおよび図21Bに示す処理が実現されることによって、図22に示されるような受注情報が、ユーザ端末41から通信回線を介して、本実施形態のシステムに入力された場合、新たな受注情報の緊急度の判定、および、新たな受注情報が示す注文数量と未引当の在庫数量との比較に基づく在庫引当の制御が実現される。
【０１１７】
その際、新たな受注情報の緊急度を判定し、緊急度が高いと判定した受注情報について、その発注数量を未引当の在庫数量が満たすか否かを判定し、未引当の在庫数量が不足すると判定した場合は、在庫データベースから緊急度の低い出荷情報を抽出し、抽出した出荷情報に引き当てられた在庫数量および未引当の在庫数量の和が、緊急度が高いと判定した受注情報の発注数量を満たすか否かを判定する。
【０１１８】
そして、出荷タイミングの遅い順に、出荷情報に引き当てられた在庫を、緊急度が高いと判定した受注情報に引き当て直し、発注数量が満たされるまで、出荷情報に引き当てられた在庫を、緊急度が高いと判定した受注情報に引き当て直すことを繰り返す。
【０１１９】
【他の実施形態】
本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることはいうまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（OS）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【０１２０】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【０１２１】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明した図4に示すシーケンス、および/または、図13から図16ないし図21Aから図21Cに示すフローチャートに対応するプログラムコード、並びに/あるいは、図5から図12、図20ないし図25から図27に示す画面のデータを作成するプログラムコードが格納されることになる。
【０１２２】
【発明の効果】
以上説明したように、本発明によれば、商品の効率的かつ効果的な在庫、出荷および納期管理を行うことができる。
【図面の簡単な説明】
【図１】現状のトナーカートリッジの流れを説明する図、
【図２】本実施形態におけるトナーカートリッジの流れを示す図、
【図３】トナーカートリッジの販売回収システムの構成例を示す図、
【図４】トナーカートリッジの発注シーケンスの一例を示す図、
【図５】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図６】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図７】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図８】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図９】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図１０】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図１１】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図１２】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図、
【図１３】受注処理の一例を示すフローチャート、
【図１４】受注情報に基づく在庫確認、納期回答および出荷処理の一例を示す図、
【図１５】受注情報に基づく在庫確認、納期回答および出荷処理の一例を示す図、
【図１６】受注情報に基づく在庫確認、納期回答および出荷処理の一例を示す図、
【図１７】当日納期を満たせるか否かの判定を説明するフローチャート、
【図１８】倉庫データベースの推定納品時間テーブルの一例を示す図、
【図１９】コンピュータの代表的な構成例を示すブロック図、
【図２０】第2実施形態における注文画面の一例を示す図、
【図２１Ａ】受注情報に基づく在庫確認、納期回答および出荷処理の一例を示すフローチャート、
【図２１Ｂ】受注情報に基づく在庫確認、納期回答および出荷処理の一例を示すフローチャート、
【図２１Ｃ】受注情報に基づく在庫確認、納期回答および出荷処理の一例を示すフローチャート、
【図２２】受注情報を説明する図、
【図２３Ａ】受注状況テーブルを説明する図、
【図２３Ｂ】受注状況テーブルを説明する図、
【図２３Ｃ】受注状況テーブルを説明する図、
【図２３Ｄ】受注状況テーブルを説明する図、
【図２３Ｅ】受注状況テーブルを説明する図、
【図２４Ａ】在庫テーブルを説明する図、
【図２４Ｂ】在庫テーブルを説明する図、
【図２５】当日納期可能を示す画面情報の一例を示す図、
【図２６】当日納期不可を示す画面情報の一例を示す図、
【図２７】納期回答を示す画面情報の一例を示す図である。
【図１】
0004115143.tif 000002
【図２】
0004115143.tif 000003
【図３】
0004115143.tif 000004
【図４】
0004115143.tif 000005
【図５】
0004115143.tif 000006
【図６】
0004115143.tif 000007
【図７】
0004115143.tif 000008
【図８】
0004115143.tif 000009
【図９】
0004115143.tif 000010
【図１０】
0004115143.tif 000011
【図１１】
0004115143.tif 000012
【図１２】
0004115143.tif 000013
【図１３】
0004115143.tif 000014
【図１４】
0004115143.tif 000015
【図１５】
0004115143.tif 000016
【図１６】
0004115143.tif 000017
【図１７】
0004115143.tif 000018
【図１８】
0004115143.tif 000019
【図１９】
0004115143.tif 000020
【図２０】
0004115143.tif 000021
【図２１Ａ】
0004115143.tif 000022
【図２１Ｂ】
0004115143.tif 000023
【図２１Ｃ】
0004115143.tif 000024
【図２２】
0004115143.tif 000025
【図２３Ａ】
0004115143.tif 000026
【図２３Ｂ】
0004115143.tif 000027
【図２３Ｃ】
0004115143.tif 000028
【図２３Ｄ】
0004115143.tif 000029
【図２３Ｅ】
0004115143.tif 000030
【図２４Ａ】
0004115143.tif 000031
【図２４Ｂ】
0004115143.tif 000032
【図２５】
0004115143.tif 000033
【図２６】
0004115143.tif 000034
【図２７】
0004115143.tif 000035