在庫管理システム
【課題】本発明は在庫管理システムに関し、購入希望者側の事情と販売側の事情に合わせた在庫管理を行なうことができる在庫管理システムを提供することを目的としている。
【解決手段】商品の予約依頼を行なう顧客端末１と、該顧客端末１とネットワーク２を介して接続され商品の在庫管理を行なう管理サーバ３と、該管理サーバ３に接続された商品の管理情報を記憶するデータベース４と、前記ネットワーク２に接続された店舗端末６と、同じく前記ネットワークに接続された店員端末５とを具備し、商品の在庫を管理するように構成される。
【解決手段】商品の予約依頼を行なう顧客端末１と、該顧客端末１とネットワーク２を介して接続され商品の在庫管理を行なう管理サーバ３と、該管理サーバ３に接続された商品の管理情報を記憶するデータベース４と、前記ネットワーク２に接続された店舗端末６と、同じく前記ネットワークに接続された店員端末５とを具備し、商品の在庫を管理するように構成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は在庫管理システムに関し、更に詳しくは商品の在庫をなるべく少なくなるようにした在庫管理システムに関する。また、商品予約希望者の予約実行度及び年間購入金額とから顧客ランクを決定し、この顧客ランクと商品販売状況とから商品予約希望者が予約できる商品一覧を表示し、商品予約が行われるようにしたものである。特に、優良顧客からの販売状況の良い商品の予約依頼について取り置きされるようにしたものである。
【背景技術】
【０００２】
今日、インターネット通販などで、全国チェーンの店舗の場合、全国の在庫のある店舗の検索を行なって表示部に一覧表示し、在庫のある店舗からインターネットショッピングで商品を購入したり、来店し購入する場合の利便性を考慮して、来店予約者の通常の移動ルートを登録した時には、そのルートの近傍に店舗群を紹介するシステムや、来店時に在庫があるように入荷予定を調整するシステムがある（例えば特許文献１，２参照）。
【特許文献１】特開２００２−１１７２２１号公報（段落００１３〜００１９、図１）
【特許文献２】特開２００２−１６９９４８号公報（段落００１１〜００２０、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のシステムでは、来店予約者が商品を確認してから購入したいという要望に応えるため、在庫調整を行なって来店当日の在庫があるように調整するシステムはあるが、この場合、販売状況や入庫予定での調整であり、来店予約者が来店時に商品が確保されているわけではなく、偶発的に在庫が無くなる可能性があった。また、流通性のよくない商品や高額商品は来店予約による在庫確保は、来店予約者が商品を確認したとしても必ずしも購入するわけではなく、購入しなかった場合は不良在庫となる場合もありえた。本発明はこのような課題に鑑みてなされたものであって、商品の購入希望者側の事情と販売側の事情に合わせた在庫管理を行なうことができる在庫管理システムを提供することを目的としている。
【課題を解決するための手段】
【０００４】
（１）請求項１記載の発明は、商品の予約依頼を行なう顧客端末と、該顧客端末とネットワークを介して接続され商品の在庫管理を行なう管理サーバと、該管理サーバに接続された商品の管理情報を記憶するデータベースと、前記ネットワークに接続された店舗端末と、同じく前記ネットワークに接続された店員端末とで構成された在庫管理システムにおいて、商品予約希望者が前記顧客端末から商品の予約を行なうと、前記管理サーバは、前記データベースに記憶されている商品予約希望者の予約実行度及び年間購入金額とから顧客ランクを決定し、この顧客ランクと商品の販売状況とから前記商品予約希望者が予約できる商品一覧を前記顧客端末の表示部に表示させて商品予約が行なえるようにし、商品予約がなされると前記店員端末に商品取り置き依頼を送信するようにしたことを特徴とする在庫管理システム。
【０００５】
（２）請求項２記載の発明は、前記商品予約希望者が商品を確認してから購入を決めたいという要望に対し、前記管理サーバは、前記データベースを参照して当該商品の最終販売可能日及び販売状況を参酌して当該商品の在庫を制限することを特徴とする。
【０００６】
（３）請求項３記載の発明は、販売状況の良い商品については、前記管理サーバは会員顧客からの商品予約依頼に対して商品取り置きを行なうことを特徴とする。
（４）請求項４記載の発明は、販売状況の悪い商品については、前記顧客サーバは会員顧客からの予約依頼を拒否することを特徴とする。
【０００７】
（５）請求項５記載の発明は、来店予約者が来店予約した店舗を含む会社又はその会社の指定する会の会員である場合、前記管理サーバは、その会員の購入実績又は過去の来店予約時の購入実績から当該商品の在庫を制限することを特徴とする。
【発明の効果】
【０００８】
（１）顧客ランクと商品の販売情報とから商品予約希望者が予約できる商品を決定すると、その商品の取り置きを店員端末に送信することで、商品購入可能性のある顧客の希望する商品を取り置きしておくことができる。
【０００９】
（２）請求項２記載の発明によれば、該当商品の最終販売可能日及び販売状況とから該当商品の在庫を制限することで、不良在庫の発生を抑制することができる。
（３）請求項３記載の発明によれば、販売状況の良い商品については、商品取り置きをしても不良在庫とならないので、会員顧客の要望どおり商品取り置きをすることができる。
【００１０】
（４）請求項４記載の発明によれば、販売状況の悪い商品については、会員顧客からの予約依頼を拒否することで不良在庫の発生を防止することができる。
（５）請求項５記載の発明によれば、来店予約者が会員顧客である場合に、その会員の購入実績又は過去の来店予約時の購入実績から当該商品を取り置きするか否かを決定するので、不良在庫の発生を抑えることができる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明の実施の形態を詳細に説明する。図１は本発明システムの一実施の形態を示す構成図である。図において、１は商品の予約依頼等を行なう顧客端末、２は該顧客端末１が接続されるインターネット等のネットワークである。３は該ネットワーク２と接続され、商品の在庫管理を行なう管理サーバである。
【００１２】
該管理サーバ２は、会員を登録する会員登録手段と、予約受付の判断を行なう予約受付判断手段と、予約可能商品を表示する予約可能商品表示手段と、購入実績を更新する購入実績更新手段と、販売状況を更新する販売状況更新手段と、予約実行率を更新する予約実行率更新手段と、顧客ランクを更新する顧客ランク更新手段と、取り置き商品の処理を行なう取り置き商品処理手段とから構成されている。これら構成手段は、ハードウェアでもソフトウェアでも実現することができる。
【００１３】
ここで、顧客ランクとは、その顧客が商品販売側にとってどれくらい商品を購入してくれるかを判断するランクであり、普通のランクをＢ、商品をよく購入してくれる顧客のランクをＡ、ほとんど購入してくれない顧客のランクをＣという具合に設定するものである（詳細後述）。
【００１４】
４は管理サーバ３と接続され、商品の管理情報を記憶するデータベース（ＤＢ）である。該データベースとしては、例えばハードディスク装置が用いられる。該データベース４には、商品の販売状況を記憶する商品販売情報管理テーブルと、商品の在庫情報を記憶する商品在庫テーブルと、予約可能在庫条件を記憶する予約可能在庫条件テーブルと、商品の販売状況を記憶する販売状況条件テーブルと、商品の取り置き可能日数を記憶する取り置き可能日数テーブルと、会員情報を記憶する会員情報テーブルを含んでいる。
【００１５】
また、会員の商品購入実績を記憶する会員購入実績テーブルと、商品の予約管理状況を記憶する予約管理テーブルと、顧客ランクを記憶する顧客ランクテーブルと、予約実行の判断条件を記憶する予約実行判断テーブルと、予約可能顧客の条件を記憶する予約可能顧客条件テーブルと、商品の売り上げ実績を記憶する商品売上実績テーブルと、店舗の管理状況を記憶する店舗管理テーブルと、メールの雛形を記憶するメール雛形テーブルを含んでいる。
【００１６】
以下に各テーブルの構成を示す。図２は商品販売状況管理テーブルの構成例を示す図である。図に示すように、商品の種類毎に販売状況が記憶されている。例えば、商品Ａについては、平均して月に１２品売上があることを示している。図３は商品在庫テーブルの構成例を示す図である。この商品在庫テーブルは、商品毎に販売価格と在庫数と商品ＩＤが記憶されている。例えば、商品Ａの価格は９８００円であり、在庫数は２、商品ＩＤはＡ１１１とＡ１１２であることを示している。
【００１７】
図４は予約可能在庫条件テーブルの構成例を示す図である。図に示すように、商品毎に在庫数と予約可能顧客ランクが記憶されている。例えば、商品Ａの在庫数１のものは顧客ランクＡのものであり、在庫数２のものは、顧客ランクＢである。図５は販売状況条件テーブルの構成例を示す図である。商品毎に販売状況条件と予約可能顧客ランクが記憶されている。例えば、商品Ａの販売状況条件が「月間売上数３品以上」である場合の予約可能顧客ランクはＡである。図６は取り置き可能日数テーブルの構成例を示す図である。商品毎に、取り置き可能日数と、予約可能顧客ランクが記憶されている。例えば商品Ａについて取り置き可能日数が３日のものは、予約可能顧客ランクＡが記憶されている。取り置き可能日数が１日のものは、予約可能顧客ランクがＢとなる。顧客ランクＢの商品は、不良在庫になる可能性が高いので取り置き可能日数を１日と短くしている。顧客ランクＡの商品は取り置き可能日数が３日と長い。
【００１８】
図７は会員情報テーブルの構成例を示す図である。図に示すように、会員ＩＤと、会員名と、住所と、会員登録日と、会員連絡先Ｅメールアドレスと、顧客購入ランクと、年間購入額と、予約品購入実績総回数と、予約実行率と、予約実行率ランクとが記憶されている。ここで、予約品購入実績総回数とは、予約した商品を実際に購入した回数のことであり、予約実行率は予約した総数に対する実際に購入した回数の割合を示すものである。予約実行率ランクは、予約した総回数に対する実際に購入した回数の割合を示す。
【００１９】
図８は会員購入実績テーブルの構成例を示す図である。会員ＩＤ毎に、購入日と、商品ＩＤと、購入額が記憶されている。図９は予約管理テーブルの構成例を示す図である。図に示すように予約番号と、予約した会員の会員ＩＤと、予約した商品の予約商品ＩＤと、取り置き締切日と、キャンセル日とが記憶されている。
【００２０】
図１０は顧客ランクテーブルの構成例を示す図である。年間購入額に応じてランクが記憶されている。例えば年間購入額が１０万円以上の場合にはランクは１になり、年間購入額が１万円〜１０万円の場合にはランクは２になる。図１１は予約実行判断テーブルの構成例を示す図である。図に示すように、予約実行率毎にランクが記憶されている。例えば予約実行率８０％以上の場合はクラスは１となる。図１２は予約可能顧客条件テーブルの構成例を示す図である。図に示すように条件毎に予約可能顧客ランクが記憶されている。例えば、予約実行判断テーブル又は顧客ランクテーブルのランクが１の場合は、予約可能顧客ランクはＡとし、予約実行判断テーブルと顧客ランクテーブルのランクが２の場合、予約可能顧客ランクはＢとなる。
【００２１】
図１３は商品売上実績テーブルの構成例を示す図である。図に示すように、日付と商品ＩＤと売上金額が記憶されている。図１４は店舗管理テーブルの構成例を示す図である。図に示すように、店舗名と店舗連絡先Ｅメールアドレスが記憶されている。
【００２２】
再び図１の説明に戻る。５は店員毎に持っている店員端末、６は店舗毎に設けられた店舗端末である。このように構成されたシステムの動作を説明すれば、以下の通りである。
顧客端末１から会員登録依頼があると、管理サーバ３は会員登録画面を顧客端末１に表示させる。図１５は会員登録画面を示す図である。表示部に「予約受付サービスをご利用頂くために会員登録をお願いします。」というメッセージと共に、氏名と住所と連絡先アドレスの入力領域が表示されるので、顧客は顧客端末１を操作して氏名と住所と連絡先アドレスを入力すると、送信ボタン１１を押す。この結果、氏名と住所と連絡先アドレスはネットワーク２を介して管理サーバ３に送信される。
【００２３】
この氏名と住所と連絡先アドレスは、会員登録手段によりデータベース４内の会員情報テーブル（図７参照）に記憶され登録される。この時、当該会員のＩＤが付加されるが、この会員ＩＤは顧客端末１に送信され、顧客にその番号が通知される。この時、会員情報テーブルの顧客購入ランクには、デフォルト値として「Ｂ」が設定される。ランクＢは普通のランクであることを示す。
【００２４】
次に、顧客端末１から商品予約依頼があると、管理サーバ３内の予約受付判断手段は、在庫数と顧客ランクとから、図３に示す商品在庫テーブルと図４に示す予約可能在庫条件テーブルを参照して、予約可能な商品があるか否かを判断する。上記条件に加えて、図５に示す販売状況条件テーブルを参照して販売状況と顧客ランクにより予約可能条件を満たす商品があるか否かを判断する。
【００２５】
上記条件により予約可能な商品がある場合には、これらの商品について管理サーバ３はデータベース４の取り置き可能日数テーブルを参照して、顧客ランクと商品名とから取り置き可能日数を抽出し、予約可能商品表示手段は予約可能商品一覧と共に顧客端末１に表示させる。
【００２６】
図１６は商品予約画面を示す図である。画面には「会員ＩＤ５５５様 お客様が予約可能な商品の一覧です。」という表示と共に、予約可能な商品の一覧が表示される。図１６の場合、商品Ａについては、ＩＤＡ１１１については、在庫数が２、最終販売可能日が３月２７日、取り置き可能日数１日が表示され、ＩＤＡ１１２については、在庫数が３、最終販売可能日が４月２７日、取り置き可能日数１日が表示される。
【００２７】
この場合に、顧客は商品の横に付された□の枠１２，１３の中に購入する商品のチェックを入れ、商品予約依頼ボタン１４を押して依頼予約を行なう。この依頼予約情報が管理サーバ３に入力されると、該管理サーバ３は図９に示す予約管理テーブルに予約番号と、会員ＩＤと、予約日と、予約商品ＩＤと、取り置き締切日を書き込む。なお、顧客に必要とする商品がない場合には、顧客はキャンセルボタン１５を押す。この結果、予約管理テーブルにキャンセル日が書き込まれる。
【００２８】
この依頼受付処理を行なうと、管理サーバ３は顧客端末１に商品予約受付完了メールを送信する。図１８は管理サーバ３から顧客端末１へのメールを示す図である。（ａ）は商品受付の完了メールであり、「下記商品の予約受付が完了しました。取り置き可能日数経過までにご来店下さい。」というメールと共に、商品名と取り置き可能日数が表示される。（ｂ）は取り置き解除のお知らせメールであり、「下記商品の取り置き期間が経過しました。取り置きの解除をしましたのでご了承下さい。」というメールと共に、取り置き解除された商品の内容が表示される。
【００２９】
また、管理サーバ３は、店員端末５に対して取り置き依頼情報メールを送信する。図１７は管理サーバ３から店員端末５へのメールを示す図である。（ａ）は取り置き依頼情報メールであり、「会員ＩＤ５５５様が予約されました。下記商品の取り置きをお願いします。」というメッセージと共に、取り置きすべき商品情報が表示される。（ｂ）は取り置き解除依頼メールである。店員端末５に対して「下記商品の取り置き期間が経過しました。取り置きの解除をお願いします。」というメッセージと共に取り置き解除する商品情報が表示される。なお、取り置きとは当該商品を別の専用の棚に並べ、一般の商品と同様に扱われないようにすることであり、取り置き解除は専用棚に並べられていた商品を一般の商品と同じ棚に並べ販売することである。
【００３０】
管理サーバ３は、取り置き可能日数が経過した商品があるか否か判断し、ある場合には取り置きしている店舗の店員端末５に取り置き依頼メールを送信するものであり、取り置きしている顧客の顧客端末１にも図１８の（ｂ）に示すように解除依頼メールを送信する。管理サーバ３は、取り置きしていた顧客について図１１に示す予約実行判断テーブルの年間予約実行率、顧客ランクを更新する。
【００３１】
管理サーバ３では、販売状況更新手段が店舗端末６から商品売上情報を受信すると、データベース４内の図１３に示す商品売上実績テーブルを更新する。また、購入実績更新手段が図５に示す商品販売状況管理テーブルにアクセスして、月末若しくは所定のタイミングで商品毎に平均月間売上数を更新する。
【００３２】
また、管理サーバ３の購入実績更新手段は、図８に示す会員購入実績テーブルにアクセスして、会員購入実績を更新する。また、管理サーバ３の予約実行率更新手段は、予約済み商品が含まれている場合には、図７に示す会員情報テーブルの年間予約実行率を更新する。また、顧客ランク更新手段は、図１１の予約実行判断テーブルにアクセスして、顧客ランクと予約実行率ランクを更新する。
【００３３】
図１９は管理サーバの動作の一例を示すフローチャートである。システムとしては、図１に示すシステムを用いるものとする。動作の主体は管理サーバである。先ず顧客端末１から会員登録依頼があったかどうかをチェックする（Ｓ１）。会員登録依頼があった場合には、データベース４の会員情報テーブルに会員情報を登録する（Ｓ２）。次に会員情報を登録したら、顧客のランクを「Ｂ」に初期設定する（Ｓ３）。ここで、顧客ランクＢは、普通のランクであることを示す。以降顧客が当該店舗の重要な顧客になったら、顧客ランクはＡに引き上げられる。当該店舗の商品をあまり購入しない顧客であることが分かったら、Ｂより下のランクＣに下げることになる。
【００３４】
会員登録依頼が終わり、顧客端末１から予約依頼があったかどうかチェックする（Ｓ４）。予約依頼がなかった場合、当該顧客の取り置き締切り日経過の商品があるかどうかチェックする（Ｓ５）。締切日経過の商品がなかった場合、予約商品のキャンセル依頼が店舗端末６又は顧客端末１からあったかどうかチェックする（Ｓ６）。キャンセル依頼があった場合には、キャンセル日を図９に示す予約管理テーブルに登録し（Ｓ７）、初めに戻る。ステップＳ６において、キャンセル依頼がなかった場合も、初めに戻る。
【００３５】
ステップＳ５において取り置き締切日の商品があった場合、取り置きしている店舗の店員端末５に取り置き解除依頼メールを送信し（Ｓ８）、取り置きしている顧客端末１にも取り置き解除報告メールを送信し（Ｓ９）、取り置き解除となった会員顧客の予約実行率と予約実行率ランク、顧客ランクを更新し（Ｓ１０）、初めに戻る。ここで、予約実行率ランクと顧客ランクの更新は、データベース４内の図１１に示す予約実行判断テーブルに対して行なわれる。
【００３６】
ステップＳ１において、会員登録依頼がなかった場合、店舗端末６からの商品売上情報を受信したかどうかチェックする（Ｓ１１）。商品売上情報を受信した場合には、図１３に示す商品売上実績テーブルの更新を行なう（Ｓ１２）。次に、商品売上情報が送信されたのが月末であったかどうかチェックする（Ｓ１３）。月末であった場合には、図２に示す商品販売状況管理テーブルにアクセスして平均月間売上数を更新する（Ｓ１４）。
【００３７】
次に、商品売上情報が登録された会員からのものであるかどうかチェックする（Ｓ１５）。会員からのものでない場合には、初めに戻る。会員からのものであった場合には、図８に示す会員購入実績テーブルにアクセスして会員の購入実績を更新する（Ｓ１６）。次に、受信情報の中に予約済み商品があるかどうかチェックする（Ｓ１７）。なかった場合には初めに戻り、有った場合には予約実行率を計算して、図１１に示す予約実行判断テーブルにアクセスして予約実行率の更新を行なう（Ｓ１８）。そして、図１２に示す予約可能顧客条件テーブルにアクセスして、顧客購入ランク、予約実行率ランクを更新して（Ｓ１９）、初めに戻る。
【００３８】
次に、ステップＳ４において、予約依頼があった場合、図４に示す予約可能在庫条件テーブル及び図１２に示す予約可能顧客条件テーブルの構成例を示す図を参照して、在庫数と顧客ランクから予約可能条件を満たす商品があるかどうかチェックする（Ｓ２０）。予約可能条件を満たす商品がある場合には、図１３に示す商品売上実績テーブルを参照して、ステップＳ２０に示す条件に加えて、販売状況と顧客ランクより予約可能条件を満たす商品があるかどうかチェックする（Ｓ２１）。
【００３９】
予約可能条件を満たす商品がある場合には、顧客ランクと商品名とから取り置き可能日数を抽出し、予約可能商品一覧と共に図１６に示すように表示する（Ｓ２３）。なお、ステップＳ２０において予約可能条件を満たす商品がない場合、またはステップＳ２１において予約可能条件を見たす商品がない場合には、顧客端末１に予約受付不可情報を表示し（Ｓ２２）、初めに戻る。
【００４０】
次に、ステップＳ２３で表示されている商品一覧の中に顧客希望商品の指定があったかどうかチェックする（Ｓ２４）。指定がなかった場合には、初めに戻る。指定があった場合には、予約受付番号を発行し、予約情報を図９に示す予約管理テーブルに登録する（Ｓ２５）。次に、顧客端末１に図１８の（ａ）に示すような商品予約受付完了メールを送信する（Ｓ２６）。また、図１７の（ａ）に示すように店員端末５に取り置き依頼情報メールを送信する（Ｓ２７）。この場合において、データベース４に記憶されているメール雛形テーブルを用いて簡単にメールを作成することができる。その後、最初に戻る。
【００４１】
このように、本発明によれば顧客ランクと商品の販売情報とから商品予約希望者が予約できる商品を決定すると、その商品の取り置きを店員端末に送信することで、商品購入可能性のある顧客の希望する商品を取り置きしておくことができる。
【００４２】
また、該当商品の最終販売可能日及び販売状況とから該当商品の在庫を制限することで、不良在庫の発生を抑制することができる。
また、販売状況の良い商品については、商品取り置きをしても不良在庫とならないので、会員顧客の要望どおり商品取り置きをすることができる。
【００４３】
また、販売状況の悪い商品については、会員顧客からの予約依頼を拒否することで不良在庫の発生を防止することができる。
更に、来店予約者が会員顧客である場合に、その会員の購入実績又は過去の来店予約時の購入実績から当該商品を取り置きするか否かを決定するので、不良在庫の発生を抑えることができる。
【図面の簡単な説明】
【００４４】
【図１】本発明システムの一実施の形態を示す構成図である。
【図２】商品販売状況管理テーブルの構成例を示す図である。
【図３】商品在庫テーブルの構成例を示す図である。
【図４】予約可能在庫条件テーブルの構成例を示す図である。
【図５】販売状況条件テーブルの構成例を示す図である。
【図６】取り置き可能日数テーブルの構成例を示す図である。
【図７】会員情報テーブルの構成例を示す図である。
【図８】会員購入実績テーブルの構成例を示す図である。
【図９】予約管理テーブルの構成例を示す図である。
【図１０】年間購入額に対するランク付けを示す図である。
【図１１】予約実行判断テーブルの構成例を示す図である。
【図１２】予約可能顧客条件テーブルの構成例を示す図である。
【図１３】商品売上実績テーブルの構成例を示す図である。
【図１４】店舗管理テーブルの構成例を示す図である。
【図１５】会員登録画面を示す図である。
【図１６】商品予約画面を示す図である。
【図１７】管理サーバから店員端末へのメールを示す図である。
【図１８】管理サーバから顧客端末へのメールを示す図である。
【図１９】管理サーバの動作の一例を示すフローチャートである。
【符号の説明】
【００４５】
１ 顧客端末
２ ネットワーク
３ 管理サーバ
４ データベース（ＤＢ）
５ 店員端末
６ 店舗端末
【技術分野】
【０００１】
本発明は在庫管理システムに関し、更に詳しくは商品の在庫をなるべく少なくなるようにした在庫管理システムに関する。また、商品予約希望者の予約実行度及び年間購入金額とから顧客ランクを決定し、この顧客ランクと商品販売状況とから商品予約希望者が予約できる商品一覧を表示し、商品予約が行われるようにしたものである。特に、優良顧客からの販売状況の良い商品の予約依頼について取り置きされるようにしたものである。
【背景技術】
【０００２】
今日、インターネット通販などで、全国チェーンの店舗の場合、全国の在庫のある店舗の検索を行なって表示部に一覧表示し、在庫のある店舗からインターネットショッピングで商品を購入したり、来店し購入する場合の利便性を考慮して、来店予約者の通常の移動ルートを登録した時には、そのルートの近傍に店舗群を紹介するシステムや、来店時に在庫があるように入荷予定を調整するシステムがある（例えば特許文献１，２参照）。
【特許文献１】特開２００２−１１７２２１号公報（段落００１３〜００１９、図１）
【特許文献２】特開２００２−１６９９４８号公報（段落００１１〜００２０、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のシステムでは、来店予約者が商品を確認してから購入したいという要望に応えるため、在庫調整を行なって来店当日の在庫があるように調整するシステムはあるが、この場合、販売状況や入庫予定での調整であり、来店予約者が来店時に商品が確保されているわけではなく、偶発的に在庫が無くなる可能性があった。また、流通性のよくない商品や高額商品は来店予約による在庫確保は、来店予約者が商品を確認したとしても必ずしも購入するわけではなく、購入しなかった場合は不良在庫となる場合もありえた。本発明はこのような課題に鑑みてなされたものであって、商品の購入希望者側の事情と販売側の事情に合わせた在庫管理を行なうことができる在庫管理システムを提供することを目的としている。
【課題を解決するための手段】
【０００４】
（１）請求項１記載の発明は、商品の予約依頼を行なう顧客端末と、該顧客端末とネットワークを介して接続され商品の在庫管理を行なう管理サーバと、該管理サーバに接続された商品の管理情報を記憶するデータベースと、前記ネットワークに接続された店舗端末と、同じく前記ネットワークに接続された店員端末とで構成された在庫管理システムにおいて、商品予約希望者が前記顧客端末から商品の予約を行なうと、前記管理サーバは、前記データベースに記憶されている商品予約希望者の予約実行度及び年間購入金額とから顧客ランクを決定し、この顧客ランクと商品の販売状況とから前記商品予約希望者が予約できる商品一覧を前記顧客端末の表示部に表示させて商品予約が行なえるようにし、商品予約がなされると前記店員端末に商品取り置き依頼を送信するようにしたことを特徴とする在庫管理システム。
【０００５】
（２）請求項２記載の発明は、前記商品予約希望者が商品を確認してから購入を決めたいという要望に対し、前記管理サーバは、前記データベースを参照して当該商品の最終販売可能日及び販売状況を参酌して当該商品の在庫を制限することを特徴とする。
【０００６】
（３）請求項３記載の発明は、販売状況の良い商品については、前記管理サーバは会員顧客からの商品予約依頼に対して商品取り置きを行なうことを特徴とする。
（４）請求項４記載の発明は、販売状況の悪い商品については、前記顧客サーバは会員顧客からの予約依頼を拒否することを特徴とする。
【０００７】
（５）請求項５記載の発明は、来店予約者が来店予約した店舗を含む会社又はその会社の指定する会の会員である場合、前記管理サーバは、その会員の購入実績又は過去の来店予約時の購入実績から当該商品の在庫を制限することを特徴とする。
【発明の効果】
【０００８】
（１）顧客ランクと商品の販売情報とから商品予約希望者が予約できる商品を決定すると、その商品の取り置きを店員端末に送信することで、商品購入可能性のある顧客の希望する商品を取り置きしておくことができる。
【０００９】
（２）請求項２記載の発明によれば、該当商品の最終販売可能日及び販売状況とから該当商品の在庫を制限することで、不良在庫の発生を抑制することができる。
（３）請求項３記載の発明によれば、販売状況の良い商品については、商品取り置きをしても不良在庫とならないので、会員顧客の要望どおり商品取り置きをすることができる。
【００１０】
（４）請求項４記載の発明によれば、販売状況の悪い商品については、会員顧客からの予約依頼を拒否することで不良在庫の発生を防止することができる。
（５）請求項５記載の発明によれば、来店予約者が会員顧客である場合に、その会員の購入実績又は過去の来店予約時の購入実績から当該商品を取り置きするか否かを決定するので、不良在庫の発生を抑えることができる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明の実施の形態を詳細に説明する。図１は本発明システムの一実施の形態を示す構成図である。図において、１は商品の予約依頼等を行なう顧客端末、２は該顧客端末１が接続されるインターネット等のネットワークである。３は該ネットワーク２と接続され、商品の在庫管理を行なう管理サーバである。
【００１２】
該管理サーバ２は、会員を登録する会員登録手段と、予約受付の判断を行なう予約受付判断手段と、予約可能商品を表示する予約可能商品表示手段と、購入実績を更新する購入実績更新手段と、販売状況を更新する販売状況更新手段と、予約実行率を更新する予約実行率更新手段と、顧客ランクを更新する顧客ランク更新手段と、取り置き商品の処理を行なう取り置き商品処理手段とから構成されている。これら構成手段は、ハードウェアでもソフトウェアでも実現することができる。
【００１３】
ここで、顧客ランクとは、その顧客が商品販売側にとってどれくらい商品を購入してくれるかを判断するランクであり、普通のランクをＢ、商品をよく購入してくれる顧客のランクをＡ、ほとんど購入してくれない顧客のランクをＣという具合に設定するものである（詳細後述）。
【００１４】
４は管理サーバ３と接続され、商品の管理情報を記憶するデータベース（ＤＢ）である。該データベースとしては、例えばハードディスク装置が用いられる。該データベース４には、商品の販売状況を記憶する商品販売情報管理テーブルと、商品の在庫情報を記憶する商品在庫テーブルと、予約可能在庫条件を記憶する予約可能在庫条件テーブルと、商品の販売状況を記憶する販売状況条件テーブルと、商品の取り置き可能日数を記憶する取り置き可能日数テーブルと、会員情報を記憶する会員情報テーブルを含んでいる。
【００１５】
また、会員の商品購入実績を記憶する会員購入実績テーブルと、商品の予約管理状況を記憶する予約管理テーブルと、顧客ランクを記憶する顧客ランクテーブルと、予約実行の判断条件を記憶する予約実行判断テーブルと、予約可能顧客の条件を記憶する予約可能顧客条件テーブルと、商品の売り上げ実績を記憶する商品売上実績テーブルと、店舗の管理状況を記憶する店舗管理テーブルと、メールの雛形を記憶するメール雛形テーブルを含んでいる。
【００１６】
以下に各テーブルの構成を示す。図２は商品販売状況管理テーブルの構成例を示す図である。図に示すように、商品の種類毎に販売状況が記憶されている。例えば、商品Ａについては、平均して月に１２品売上があることを示している。図３は商品在庫テーブルの構成例を示す図である。この商品在庫テーブルは、商品毎に販売価格と在庫数と商品ＩＤが記憶されている。例えば、商品Ａの価格は９８００円であり、在庫数は２、商品ＩＤはＡ１１１とＡ１１２であることを示している。
【００１７】
図４は予約可能在庫条件テーブルの構成例を示す図である。図に示すように、商品毎に在庫数と予約可能顧客ランクが記憶されている。例えば、商品Ａの在庫数１のものは顧客ランクＡのものであり、在庫数２のものは、顧客ランクＢである。図５は販売状況条件テーブルの構成例を示す図である。商品毎に販売状況条件と予約可能顧客ランクが記憶されている。例えば、商品Ａの販売状況条件が「月間売上数３品以上」である場合の予約可能顧客ランクはＡである。図６は取り置き可能日数テーブルの構成例を示す図である。商品毎に、取り置き可能日数と、予約可能顧客ランクが記憶されている。例えば商品Ａについて取り置き可能日数が３日のものは、予約可能顧客ランクＡが記憶されている。取り置き可能日数が１日のものは、予約可能顧客ランクがＢとなる。顧客ランクＢの商品は、不良在庫になる可能性が高いので取り置き可能日数を１日と短くしている。顧客ランクＡの商品は取り置き可能日数が３日と長い。
【００１８】
図７は会員情報テーブルの構成例を示す図である。図に示すように、会員ＩＤと、会員名と、住所と、会員登録日と、会員連絡先Ｅメールアドレスと、顧客購入ランクと、年間購入額と、予約品購入実績総回数と、予約実行率と、予約実行率ランクとが記憶されている。ここで、予約品購入実績総回数とは、予約した商品を実際に購入した回数のことであり、予約実行率は予約した総数に対する実際に購入した回数の割合を示すものである。予約実行率ランクは、予約した総回数に対する実際に購入した回数の割合を示す。
【００１９】
図８は会員購入実績テーブルの構成例を示す図である。会員ＩＤ毎に、購入日と、商品ＩＤと、購入額が記憶されている。図９は予約管理テーブルの構成例を示す図である。図に示すように予約番号と、予約した会員の会員ＩＤと、予約した商品の予約商品ＩＤと、取り置き締切日と、キャンセル日とが記憶されている。
【００２０】
図１０は顧客ランクテーブルの構成例を示す図である。年間購入額に応じてランクが記憶されている。例えば年間購入額が１０万円以上の場合にはランクは１になり、年間購入額が１万円〜１０万円の場合にはランクは２になる。図１１は予約実行判断テーブルの構成例を示す図である。図に示すように、予約実行率毎にランクが記憶されている。例えば予約実行率８０％以上の場合はクラスは１となる。図１２は予約可能顧客条件テーブルの構成例を示す図である。図に示すように条件毎に予約可能顧客ランクが記憶されている。例えば、予約実行判断テーブル又は顧客ランクテーブルのランクが１の場合は、予約可能顧客ランクはＡとし、予約実行判断テーブルと顧客ランクテーブルのランクが２の場合、予約可能顧客ランクはＢとなる。
【００２１】
図１３は商品売上実績テーブルの構成例を示す図である。図に示すように、日付と商品ＩＤと売上金額が記憶されている。図１４は店舗管理テーブルの構成例を示す図である。図に示すように、店舗名と店舗連絡先Ｅメールアドレスが記憶されている。
【００２２】
再び図１の説明に戻る。５は店員毎に持っている店員端末、６は店舗毎に設けられた店舗端末である。このように構成されたシステムの動作を説明すれば、以下の通りである。
顧客端末１から会員登録依頼があると、管理サーバ３は会員登録画面を顧客端末１に表示させる。図１５は会員登録画面を示す図である。表示部に「予約受付サービスをご利用頂くために会員登録をお願いします。」というメッセージと共に、氏名と住所と連絡先アドレスの入力領域が表示されるので、顧客は顧客端末１を操作して氏名と住所と連絡先アドレスを入力すると、送信ボタン１１を押す。この結果、氏名と住所と連絡先アドレスはネットワーク２を介して管理サーバ３に送信される。
【００２３】
この氏名と住所と連絡先アドレスは、会員登録手段によりデータベース４内の会員情報テーブル（図７参照）に記憶され登録される。この時、当該会員のＩＤが付加されるが、この会員ＩＤは顧客端末１に送信され、顧客にその番号が通知される。この時、会員情報テーブルの顧客購入ランクには、デフォルト値として「Ｂ」が設定される。ランクＢは普通のランクであることを示す。
【００２４】
次に、顧客端末１から商品予約依頼があると、管理サーバ３内の予約受付判断手段は、在庫数と顧客ランクとから、図３に示す商品在庫テーブルと図４に示す予約可能在庫条件テーブルを参照して、予約可能な商品があるか否かを判断する。上記条件に加えて、図５に示す販売状況条件テーブルを参照して販売状況と顧客ランクにより予約可能条件を満たす商品があるか否かを判断する。
【００２５】
上記条件により予約可能な商品がある場合には、これらの商品について管理サーバ３はデータベース４の取り置き可能日数テーブルを参照して、顧客ランクと商品名とから取り置き可能日数を抽出し、予約可能商品表示手段は予約可能商品一覧と共に顧客端末１に表示させる。
【００２６】
図１６は商品予約画面を示す図である。画面には「会員ＩＤ５５５様 お客様が予約可能な商品の一覧です。」という表示と共に、予約可能な商品の一覧が表示される。図１６の場合、商品Ａについては、ＩＤＡ１１１については、在庫数が２、最終販売可能日が３月２７日、取り置き可能日数１日が表示され、ＩＤＡ１１２については、在庫数が３、最終販売可能日が４月２７日、取り置き可能日数１日が表示される。
【００２７】
この場合に、顧客は商品の横に付された□の枠１２，１３の中に購入する商品のチェックを入れ、商品予約依頼ボタン１４を押して依頼予約を行なう。この依頼予約情報が管理サーバ３に入力されると、該管理サーバ３は図９に示す予約管理テーブルに予約番号と、会員ＩＤと、予約日と、予約商品ＩＤと、取り置き締切日を書き込む。なお、顧客に必要とする商品がない場合には、顧客はキャンセルボタン１５を押す。この結果、予約管理テーブルにキャンセル日が書き込まれる。
【００２８】
この依頼受付処理を行なうと、管理サーバ３は顧客端末１に商品予約受付完了メールを送信する。図１８は管理サーバ３から顧客端末１へのメールを示す図である。（ａ）は商品受付の完了メールであり、「下記商品の予約受付が完了しました。取り置き可能日数経過までにご来店下さい。」というメールと共に、商品名と取り置き可能日数が表示される。（ｂ）は取り置き解除のお知らせメールであり、「下記商品の取り置き期間が経過しました。取り置きの解除をしましたのでご了承下さい。」というメールと共に、取り置き解除された商品の内容が表示される。
【００２９】
また、管理サーバ３は、店員端末５に対して取り置き依頼情報メールを送信する。図１７は管理サーバ３から店員端末５へのメールを示す図である。（ａ）は取り置き依頼情報メールであり、「会員ＩＤ５５５様が予約されました。下記商品の取り置きをお願いします。」というメッセージと共に、取り置きすべき商品情報が表示される。（ｂ）は取り置き解除依頼メールである。店員端末５に対して「下記商品の取り置き期間が経過しました。取り置きの解除をお願いします。」というメッセージと共に取り置き解除する商品情報が表示される。なお、取り置きとは当該商品を別の専用の棚に並べ、一般の商品と同様に扱われないようにすることであり、取り置き解除は専用棚に並べられていた商品を一般の商品と同じ棚に並べ販売することである。
【００３０】
管理サーバ３は、取り置き可能日数が経過した商品があるか否か判断し、ある場合には取り置きしている店舗の店員端末５に取り置き依頼メールを送信するものであり、取り置きしている顧客の顧客端末１にも図１８の（ｂ）に示すように解除依頼メールを送信する。管理サーバ３は、取り置きしていた顧客について図１１に示す予約実行判断テーブルの年間予約実行率、顧客ランクを更新する。
【００３１】
管理サーバ３では、販売状況更新手段が店舗端末６から商品売上情報を受信すると、データベース４内の図１３に示す商品売上実績テーブルを更新する。また、購入実績更新手段が図５に示す商品販売状況管理テーブルにアクセスして、月末若しくは所定のタイミングで商品毎に平均月間売上数を更新する。
【００３２】
また、管理サーバ３の購入実績更新手段は、図８に示す会員購入実績テーブルにアクセスして、会員購入実績を更新する。また、管理サーバ３の予約実行率更新手段は、予約済み商品が含まれている場合には、図７に示す会員情報テーブルの年間予約実行率を更新する。また、顧客ランク更新手段は、図１１の予約実行判断テーブルにアクセスして、顧客ランクと予約実行率ランクを更新する。
【００３３】
図１９は管理サーバの動作の一例を示すフローチャートである。システムとしては、図１に示すシステムを用いるものとする。動作の主体は管理サーバである。先ず顧客端末１から会員登録依頼があったかどうかをチェックする（Ｓ１）。会員登録依頼があった場合には、データベース４の会員情報テーブルに会員情報を登録する（Ｓ２）。次に会員情報を登録したら、顧客のランクを「Ｂ」に初期設定する（Ｓ３）。ここで、顧客ランクＢは、普通のランクであることを示す。以降顧客が当該店舗の重要な顧客になったら、顧客ランクはＡに引き上げられる。当該店舗の商品をあまり購入しない顧客であることが分かったら、Ｂより下のランクＣに下げることになる。
【００３４】
会員登録依頼が終わり、顧客端末１から予約依頼があったかどうかチェックする（Ｓ４）。予約依頼がなかった場合、当該顧客の取り置き締切り日経過の商品があるかどうかチェックする（Ｓ５）。締切日経過の商品がなかった場合、予約商品のキャンセル依頼が店舗端末６又は顧客端末１からあったかどうかチェックする（Ｓ６）。キャンセル依頼があった場合には、キャンセル日を図９に示す予約管理テーブルに登録し（Ｓ７）、初めに戻る。ステップＳ６において、キャンセル依頼がなかった場合も、初めに戻る。
【００３５】
ステップＳ５において取り置き締切日の商品があった場合、取り置きしている店舗の店員端末５に取り置き解除依頼メールを送信し（Ｓ８）、取り置きしている顧客端末１にも取り置き解除報告メールを送信し（Ｓ９）、取り置き解除となった会員顧客の予約実行率と予約実行率ランク、顧客ランクを更新し（Ｓ１０）、初めに戻る。ここで、予約実行率ランクと顧客ランクの更新は、データベース４内の図１１に示す予約実行判断テーブルに対して行なわれる。
【００３６】
ステップＳ１において、会員登録依頼がなかった場合、店舗端末６からの商品売上情報を受信したかどうかチェックする（Ｓ１１）。商品売上情報を受信した場合には、図１３に示す商品売上実績テーブルの更新を行なう（Ｓ１２）。次に、商品売上情報が送信されたのが月末であったかどうかチェックする（Ｓ１３）。月末であった場合には、図２に示す商品販売状況管理テーブルにアクセスして平均月間売上数を更新する（Ｓ１４）。
【００３７】
次に、商品売上情報が登録された会員からのものであるかどうかチェックする（Ｓ１５）。会員からのものでない場合には、初めに戻る。会員からのものであった場合には、図８に示す会員購入実績テーブルにアクセスして会員の購入実績を更新する（Ｓ１６）。次に、受信情報の中に予約済み商品があるかどうかチェックする（Ｓ１７）。なかった場合には初めに戻り、有った場合には予約実行率を計算して、図１１に示す予約実行判断テーブルにアクセスして予約実行率の更新を行なう（Ｓ１８）。そして、図１２に示す予約可能顧客条件テーブルにアクセスして、顧客購入ランク、予約実行率ランクを更新して（Ｓ１９）、初めに戻る。
【００３８】
次に、ステップＳ４において、予約依頼があった場合、図４に示す予約可能在庫条件テーブル及び図１２に示す予約可能顧客条件テーブルの構成例を示す図を参照して、在庫数と顧客ランクから予約可能条件を満たす商品があるかどうかチェックする（Ｓ２０）。予約可能条件を満たす商品がある場合には、図１３に示す商品売上実績テーブルを参照して、ステップＳ２０に示す条件に加えて、販売状況と顧客ランクより予約可能条件を満たす商品があるかどうかチェックする（Ｓ２１）。
【００３９】
予約可能条件を満たす商品がある場合には、顧客ランクと商品名とから取り置き可能日数を抽出し、予約可能商品一覧と共に図１６に示すように表示する（Ｓ２３）。なお、ステップＳ２０において予約可能条件を満たす商品がない場合、またはステップＳ２１において予約可能条件を見たす商品がない場合には、顧客端末１に予約受付不可情報を表示し（Ｓ２２）、初めに戻る。
【００４０】
次に、ステップＳ２３で表示されている商品一覧の中に顧客希望商品の指定があったかどうかチェックする（Ｓ２４）。指定がなかった場合には、初めに戻る。指定があった場合には、予約受付番号を発行し、予約情報を図９に示す予約管理テーブルに登録する（Ｓ２５）。次に、顧客端末１に図１８の（ａ）に示すような商品予約受付完了メールを送信する（Ｓ２６）。また、図１７の（ａ）に示すように店員端末５に取り置き依頼情報メールを送信する（Ｓ２７）。この場合において、データベース４に記憶されているメール雛形テーブルを用いて簡単にメールを作成することができる。その後、最初に戻る。
【００４１】
このように、本発明によれば顧客ランクと商品の販売情報とから商品予約希望者が予約できる商品を決定すると、その商品の取り置きを店員端末に送信することで、商品購入可能性のある顧客の希望する商品を取り置きしておくことができる。
【００４２】
また、該当商品の最終販売可能日及び販売状況とから該当商品の在庫を制限することで、不良在庫の発生を抑制することができる。
また、販売状況の良い商品については、商品取り置きをしても不良在庫とならないので、会員顧客の要望どおり商品取り置きをすることができる。
【００４３】
また、販売状況の悪い商品については、会員顧客からの予約依頼を拒否することで不良在庫の発生を防止することができる。
更に、来店予約者が会員顧客である場合に、その会員の購入実績又は過去の来店予約時の購入実績から当該商品を取り置きするか否かを決定するので、不良在庫の発生を抑えることができる。
【図面の簡単な説明】
【００４４】
【図１】本発明システムの一実施の形態を示す構成図である。
【図２】商品販売状況管理テーブルの構成例を示す図である。
【図３】商品在庫テーブルの構成例を示す図である。
【図４】予約可能在庫条件テーブルの構成例を示す図である。
【図５】販売状況条件テーブルの構成例を示す図である。
【図６】取り置き可能日数テーブルの構成例を示す図である。
【図７】会員情報テーブルの構成例を示す図である。
【図８】会員購入実績テーブルの構成例を示す図である。
【図９】予約管理テーブルの構成例を示す図である。
【図１０】年間購入額に対するランク付けを示す図である。
【図１１】予約実行判断テーブルの構成例を示す図である。
【図１２】予約可能顧客条件テーブルの構成例を示す図である。
【図１３】商品売上実績テーブルの構成例を示す図である。
【図１４】店舗管理テーブルの構成例を示す図である。
【図１５】会員登録画面を示す図である。
【図１６】商品予約画面を示す図である。
【図１７】管理サーバから店員端末へのメールを示す図である。
【図１８】管理サーバから顧客端末へのメールを示す図である。
【図１９】管理サーバの動作の一例を示すフローチャートである。
【符号の説明】
【００４５】
１ 顧客端末
２ ネットワーク
３ 管理サーバ
４ データベース（ＤＢ）
５ 店員端末
６ 店舗端末
【特許請求の範囲】
【請求項１】
商品の予約依頼を行なう顧客端末と、該顧客端末とネットワークを介して接続され商品の在庫管理を行なう管理サーバと、該管理サーバに接続された商品の管理情報を記憶するデータベースと、前記ネットワークに接続された店舗端末と、同じく前記ネットワークに接続された店員端末とで構成された在庫管理システムにおいて、
商品予約希望者が前記顧客端末から商品の予約を行なうと、前記管理サーバは、前記データベースに記憶されている商品予約希望者の予約実行度及び年間購入金額とから顧客ランクを決定し、この顧客ランクと商品の販売状況とから前記商品予約希望者が予約できる商品一覧を前記顧客端末の表示部に表示させて商品予約が行なえるようにし、商品予約がなされると前記店員端末に商品取り置き依頼を送信するようにしたことを特徴とする在庫管理システム。
【請求項２】
前記商品予約希望者が商品を確認してから購入を決めたいという要望に対し、前記管理サーバは、前記データベースを参照して当該商品の最終販売可能日及び販売状況を参酌して当該商品の在庫を制限することを特徴とする請求項１記載の在庫管理システム。
【請求項３】
販売状況の良い商品については、前記管理サーバは会員顧客からの商品予約依頼に対して商品取り置きを行なうことを特徴とする請求項１記載の在庫管理システム。
【請求項４】
販売状況の悪い商品については、前記顧客サーバは会員顧客からの予約依頼を拒否することを特徴とする請求項１記載の在庫管理システム。
【請求項５】
来店予約者が来店予約した店舗を含む会社又はその会社の指定する会の会員である場合、前記管理サーバは、その会員の購入実績又は過去の来店予約時の購入実績から当該商品の在庫を制限することを特徴とする請求項１記載の在庫管理システム。
【請求項１】
商品の予約依頼を行なう顧客端末と、該顧客端末とネットワークを介して接続され商品の在庫管理を行なう管理サーバと、該管理サーバに接続された商品の管理情報を記憶するデータベースと、前記ネットワークに接続された店舗端末と、同じく前記ネットワークに接続された店員端末とで構成された在庫管理システムにおいて、
商品予約希望者が前記顧客端末から商品の予約を行なうと、前記管理サーバは、前記データベースに記憶されている商品予約希望者の予約実行度及び年間購入金額とから顧客ランクを決定し、この顧客ランクと商品の販売状況とから前記商品予約希望者が予約できる商品一覧を前記顧客端末の表示部に表示させて商品予約が行なえるようにし、商品予約がなされると前記店員端末に商品取り置き依頼を送信するようにしたことを特徴とする在庫管理システム。
【請求項２】
前記商品予約希望者が商品を確認してから購入を決めたいという要望に対し、前記管理サーバは、前記データベースを参照して当該商品の最終販売可能日及び販売状況を参酌して当該商品の在庫を制限することを特徴とする請求項１記載の在庫管理システム。
【請求項３】
販売状況の良い商品については、前記管理サーバは会員顧客からの商品予約依頼に対して商品取り置きを行なうことを特徴とする請求項１記載の在庫管理システム。
【請求項４】
販売状況の悪い商品については、前記顧客サーバは会員顧客からの予約依頼を拒否することを特徴とする請求項１記載の在庫管理システム。
【請求項５】
来店予約者が来店予約した店舗を含む会社又はその会社の指定する会の会員である場合、前記管理サーバは、その会員の購入実績又は過去の来店予約時の購入実績から当該商品の在庫を制限することを特徴とする請求項１記載の在庫管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１０−３１３９（Ｐ２０１０−３１３９Ａ）
【公開日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願番号】特願２００８−１６１８２８（Ｐ２００８−１６１８２８）
【出願日】平成２０年６月２０日（２００８．６．２０）
【出願人】（５９８０５７２９１）株式会社富士通エフサス (147)
【公開日】平成２２年１月７日（２０１０．１．７）
【国際特許分類】
【出願日】平成２０年６月２０日（２００８．６．２０）
【出願人】（５９８０５７２９１）株式会社富士通エフサス (147)
[ Back to top ]