釣銭準備金管理システムおよび方法
【課題】釣銭準備金発注に要する手間を軽減することを可能とした釣銭準備金管理システムを提供することである。
【解決手段】提案する釣銭準備金管理システムでは、各出金機および各ＰＯＳ端末は、管理サーバからの金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を管理サーバに送信し、管理サーバは、各出金機および各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出し、算出された合計値と準備金として準備すべき最低金額を示す閾値とを金種別に比較して、算出された合計値が閾値より小さい金種に対して発注依頼書データを作成し、発注先に送信する。
【解決手段】提案する釣銭準備金管理システムでは、各出金機および各ＰＯＳ端末は、管理サーバからの金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を管理サーバに送信し、管理サーバは、各出金機および各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出し、算出された合計値と準備金として準備すべき最低金額を示す閾値とを金種別に比較して、算出された合計値が閾値より小さい金種に対して発注依頼書データを作成し、発注先に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、店舗で客に釣銭、釣札として渡すために準備する釣銭準備金の管理システムに関する。
【背景技術】
【０００２】
百貨店、ショッピングセンター、量販店、等の店舗で商品を購入する際に、客はそこに設置されているＰＯＳ（Point of Sale）端末を通して、商品代金の精算（決済）を行なう。決済に際しては、商品の購入代金に一致する、あるいは、商品の購入代金を上回る金額の紙幣、硬貨が客により支払われる。
【０００３】
客が支払った金額のうち、商品代金に対する超過分については、釣銭、釣札として客にお釣をその場で返すが、この釣銭、釣札用に店舗毎に準備されているお金が釣銭準備金である。なお、慣習で、釣銭準備金というが、これは、釣銭（５００円玉、１００円玉、１０円玉、５円玉、１円玉）の他に、釣札（５０００円札、２０００円札、１０００円札）も含むものとする。
【０００４】
図１０は、従来の店舗における釣銭準備金の準備の流れを示す図である。
図１０において、（１）で、店舗稼動中に、店舗の担当者（マネージャー）が定期的に（釣銭釣札機に接続された）ＰＯＳ端末５１内の釣銭残量（釣銭準備金）を確認する。例えば、そのＰＯＳ端末の釣銭残量がマネージャーが経験として知る基準値より少ない場合には、（２）で、店舗のマネージャーは金庫５５から（基準値からの）不足分の釣銭準備金を取り出し、そのＰＯＳ端末にセットする。
【０００５】
金庫５５内の釣銭準備金が例えばマネージャーが経験として知る基準値より減った場合、（３）で、釣銭準備金の提供会社（主に、警備輸送会社）に（基準値からの）不足額を記載した依頼書（ここでは紙媒体）５６をＦＡＸし発注する。すなわち、ファクシミリ（ＦＡＸ）５７を通してその依頼書の記載内容を画像データ化して、釣銭準備金提供会社のファクシミリ５９に公衆回線５８を通して送信する。釣銭準備金提供会社では、（４）で、その受信側のファクシミリ５９で画像データを印字した依頼書６１を受け取ることで、発注を受け、その後、釣銭準備金をその店舗に配達する。
【０００６】
（５）で、釣銭準備金を受け取った店舗側では、マネージャーが、その釣銭準備金を金庫５５に保管し、ＰＯＳ端末の釣銭不足に備える。
ここで、ＰＯＳ端末（釣銭釣札機）内の釣銭準備金の基準値や、金庫内の釣銭準備金の基準値は例えばマネージャーの経験により決められている。また、以下の２つの問題点がある。
【０００７】
第１の問題点は、ＰＯＳ端末内の釣銭準備金が不足しているかどうかの確認（金種毎の残数確認）を、１台１台のＰＯＳ端末を回って人手で頻繁に確認しないと、店舗として釣銭準備金が不足する事態が生じ、店舗業務に支障が生じてしまう。この確認作業が手間である。
【０００８】
第２の問題点は、金庫内の釣銭準備金が不足した場合などに人が判断して、釣銭準備金の発注を行なっているので手間である。
なお、関連技術として、特許文献１には、百貨店、ショッピングセンターなどの大規模店舗群において、店舗毎の収納部を備えた釣銭ロッカーと、店舗毎のＰＯＳ端末とを有する釣銭準備管理システムが示されている。このシステムでは、店舗毎に、釣銭ロッカーの対応する収納部の釣銭残量を検出し、それが基準を下回っていた場合に、釣銭準備催促情報をＰＯＳ端末に配信して、店舗側担当者に釣銭準備金関連業務の一部を行なわせることで、経費増大を抑制し、釣銭準備金関連業務を円滑に行なわせている。
【０００９】
この特許文献１の技術の場合、釣銭ロッカーの収納部内の釣銭残量が必ずしもその店舗の釣銭準備金の多寡を反映しているとはいえず、判断の精度が十分に高いとはいえない。
また、特許文献２には、周辺技術として、店舗毎の現金有高、その回収タイミング等をネットワークで管理し、この管理情報を別のネットワークで使用して、金融機関からの資金調達を行なう技術が示されている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２０１０−２１８２９２号公報
【特許文献２】特開２００９−０５９２９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、上記問題を解決するためになされたものであり、釣銭準備金発注に要する手間を軽減することを可能とした釣銭準備金管理システムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
提案する釣銭準備金管理システムは、１台以上の出金機と、１台以上のＰＯＳ端末と、管理サーバとがネットワークを通して接続されたシステムである。
前記各出金機および前記各ＰＯＳ端末は、前記管理サーバから定期的に受信する金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を生成し、前記管理サーバに送信する金種別残数情報生成部、を有する。
【００１３】
前記管理サーバは、準備金として準備すべき最低金額を示す金種別の閾値を記憶する閾値情報記憶部と、前記各出金機および前記各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出する金種別残数合計値算出部と、算出された合計値と前記閾値情報記憶部の閾値とを金種別に比較し、算出された合計値が閾値より小さい金種に対して発注依頼書データに追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを発注先に送信する発注依頼書データ作成部と、を有する。
【００１４】
また、前記釣銭準備金管理システムにおいて、前記管理サーバは、準備金を発注したかどうかを示す発注済みフラグ情報を金種別に記憶する発注済みフラグ記憶部、をさらに有してもよい。この場合、前記発注依頼書データ作成部は、全ての金種について下記（１）、（２）の処理を行い、その処理結果として作成された発注依頼書データを前記発注先に送信する。
（１）算出された合計値が閾値より大きい金種に対しては、発注済みフラグをオフにする。
（２）算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、その金種に対し発注依頼書データを追加する。
【発明の効果】
【００１５】
提案する釣銭準備金管理システムでは、前記管理サーバから前記各出金機および前記各ＰＯＳ端末に定期的に金種別残数取得依頼が送信され、前記管理サーバの金種別残数合計値算出部により、前記各出金機および前記各ＰＯＳ端末からの前記金種別残数取得依頼に対する応答としての金種別残数情報が金種別に集計され、金種別に残数の合計値が算出される。また、前記管理サーバの発注依頼書データ作成部により、算出された合計値と前記閾値情報記憶部の閾値とが金種別に比較され、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データが発注先に送信される。これにより、各出金機内の釣銭準備金と各ＰＯＳ端末内の釣銭準備金とを定期的にシステム管理し、金種別に、システムが設置された店舗内の釣銭準備金（残数）が予め定められた額（閾値）以下になった時点で自動的に釣銭準備金提供会社等の発注先に必要額の釣銭準備金が通知され配達されるので、釣銭準備金発注に要する手間を軽減することができる。
【００１６】
また、提案する釣銭準備金管理システムでは、前記管理サーバが、金種別の発注済みフラグ情報を記憶する発注済みフラグ記憶部を有する場合には、前記発注依頼書データ作成部が、算出された合計値が閾値より大きい金種に対しては、発注済みフラグをオフにすることで、未発注時に合計値が閾値を上回っている金種に対しては未発注の状態が維持され、発注した釣銭準備金を補充後の初回残量チェック時に、発注済みの状態を未発注に戻すことができる。また、前記発注依頼書データ作成部が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、発注依頼書データにその金種の発注内容データを追加することで、前回未発注であって今回合計値が閾値を下回っている金種に対して発注を行うことができる。また、前記発注依頼書データ作成部が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオンであった場合に、その金種に対する処理をバイパスする（何も行なわない）ことで、発注済みで閾値を下回っている金種に対しては重複して発注することを避けることができる。これにより、発注済みかどうかの情報管理も自動で行なうことができ、釣銭準備金発注に要する手間をさらに軽減できる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係る釣銭準備金管理システムが設置された店舗における釣銭準備金の準備の流れを示す図である。
【図２】本実施形態の釣銭準備金管理システムのブロック図である。
【図３】釣銭釣札機に接続されたＰＯＳ端末、あるいは、自動出金機により生成された金種別残数情報のデータ構造を示す図である。
【図４】閾値テーブルおよび自動発注額テーブルのデータ構造を示す図である。
【図５】発注済みフラグテーブルのデータ構造を示す図である。
【図６Ａ】本実施形態の釣銭準備金発注処理のフローチャート（その１）である。
【図６Ｂ】本実施形態の釣銭準備金発注処理のフローチャート（その２）である。
【図７】システムへのパラメータの登録および運用開始時の処理を例示するシステムフローである。
【図８】システム運用時の、自動出金機からＰＯＳ端末への釣銭準備金補充処理を例示するシステムフローである。
【図９】システム運用時の、店舗内釣銭準備金残高が閾値を下回った場合の処理を例示するシステムフローである。
【図１０】従来の店舗における釣銭準備金の準備の流れを示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明に係る実施の形態について図面を参照して詳細に説明する。
提案する釣銭準備金管理システムは、店舗内に設置され、管理サーバと１台以上のＰＯＳ端末と、１台以上の自動出金機とを有し、それらが有線あるいは無線のネットワーク（ＬＡＮ（Local Area Network）等）で互いに接続されたシステムである。このシステムでは、運用開始に先立つ準備として、下記準備１〜準備３を行なう。
準備１：ＰＯＳ端末と釣銭釣札機を接続し、釣銭釣札機内の釣銭準備金の残額（"残量"ともいう、あるいは、単に"釣銭準備金額"ということもある）をリモート確認できるようにする。
準備２：自動出金機内の釣銭準備金の残額をリモート確認できるようにする。
準備３：１台以上のＰＯＳ端末（釣銭釣札機）と１台以上の自動出金機が設置された店舗内の釣銭準備金の（金種毎の）総計がいくら以下になったら自動発注を行なうかを示す（金種毎の）閾値と、その（金種毎の）閾値を下回ったときの（金種毎の）発注量をシステムへ登録する。
【００１９】
このような登録作業を経て、システム運用時には、各ＰＯＳ端末（釣銭釣札機）内と各自動出金機内との釣銭準備金の（金種毎の）残額を定期的にオンラインで確認し、その金種毎の合計値が店舗内の釣銭準備金の（金種毎の）閾値をそれぞれ下回っているかどうかを監視する。閾値を下回った金種については、予め発注量として登録しておいた金額相当の釣銭準備金を釣銭準備金提供会社へ自動発注する。
【００２０】
図１は、本発明の一実施形態に係る釣銭準備金管理システムが設置された店舗における釣銭準備金の準備の流れを示す図である。
図１において、（１）で、運用開始に先立つ準備として、自動発注を行なう釣銭準備金額の（金種毎の）閾値と、その閾値を下回ったときの（金種毎の）発注量を管理サーバ３へ登録する。
【００２１】
そして、システム運用時には、（２）で、各（釣銭釣札機に接続された）ＰＯＳ端末（ここではＰＯＳ端末１の１台のみ示されている）内と各自動出金機（ここでは自動出金機５のみ示されている）内との釣銭準備金の（金種毎の）残額（残量）を管理サーバ３は定期的にオンラインで取得し、（３）で、（２）で取得した各（釣銭釣札機に接続された）ＰＯＳ端末および各自動出金機の釣銭準備金残量を（金種毎に）合計して、店舗内の釣銭準備金の残量トータル値（合計値）を金種毎に算出する。
【００２２】
そして、（３）で管理サーバ３により算出された金種毎の合計値が店舗内の釣銭準備金の（金種毎の）閾値をそれぞれ下回っているかどうかが判定され、閾値を下回った金種については、（４）で、予め発注量として登録しておいた金額相当の釣銭準備金を釣銭準備金提供会社へ自動発注する。
【００２３】
すなわち、ＦＡＸモデム７を通して発注内容が画像データ化された依頼書データ６が、釣銭準備金提供会社のファクシミリ（ＦＡＸ）９あてに送信され、その受信側のファクシミリ９において、画像データを印字した依頼書（紙媒体）１１を受け取ることで、釣銭準備金提供会社において発注が受け付けられ、後に、釣銭準備金がその店舗に配達される。
【００２４】
図２は、本実施形態の釣銭準備金管理システムのブロック図である。
図２に示すように、本実施形態の釣銭準備金管理システムは、ｍ台の釣銭釣札機２−１、・・・、２−ｍにそれぞれ接続されたｍ台のＰＯＳ端末１−１、・・・１−ｍ、ｎ台の自動出金機５−１、・・・、５−ｎ、管理サーバ３、を有し、それらが互いにネットワーク（ここではＬＡＮ１２）で接続されている。
【００２５】
ｍ台のＰＯＳ端末１−１、・・・１−ｍは、図２に示すように、ｍ台の釣銭釣札機２−１、・・・、２−ｍにそれぞれ接続されている。ＰＯＳ端末１−１、・・・１−ｍのそれぞれ（図２ではｍ台を代表してＰＯＳ端末１−１についてブロック図が示されている）は、金種別残数情報作成部３１および金種別残数情報送信部３２を有する。
【００２６】
金種別残数情報作成部３１は、管理サーバ３から定期的に受信する金種別残数取得依頼に対応して、自端末の金種別残数を有する金種別残数情報を生成する。金種別残数情報送信部３２は、生成された金種別残数情報を管理サーバ３に送信する。
【００２７】
ｎ台の自動出金機５−１、・・・、５−ｎのそれぞれ（図２ではｎ台を代表して自動出金機５−１についてブロック図が示されている）は、金種別残数情報作成部３３および金種別残数情報送信部３４を有する。
【００２８】
金種別残数情報作成部３３は、管理サーバ３から定期的に受信する金種別残数取得依頼に対応して、自機の金種別残数を有する金種別残数情報を生成する。金種別残数情報送信部３４は、生成された金種別残数情報を管理サーバ３に送信する。
【００２９】
図３は、釣銭釣札機に接続されたＰＯＳ端末、あるいは、自動出金機により生成された金種別残数情報３５のデータ構造を示す図である。
図３に示すように、金種別残数情報３５は、ＰＯＳ端末、あるいは、自動出金機のＩＤ、５，０００円札の残枚数、２，０００円札の残枚数、１，０００円札の残枚数、５００円玉の残個数、１００円玉の残個数、５０円玉の残個数、１０円玉の残個数、５円玉の残個数、１円玉の残個数、の各項目を有する。
【００３０】
図２の説明に戻る。図２において、管理サーバ３は、金種別残数取得依頼送信部２１、金種別残数合計値算出部２２、発注依頼書データ作成部２３、発注依頼書データ送信部２４、閾値ＤＢ２５、自動発注額ＤＢ２６、発注済みフラグ記憶領域２７、を有する。
【００３１】
金種別残数取得依頼送信部２１は、金種別残数取得依頼を管理サーバ３に接続されている全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎに対して同報通信（ブロードキャスト）する。
【００３２】
金種別残数合計値算出部２２は、全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎからの金種別残数情報を金種別に集計して、金種別に残数の合計値を算出する。
【００３３】
発注依頼書データ作成部２３は、算出された合計値と閾値ＤＢ２５に記憶される閾値とを金種別に比較し、自動発注額ＤＢ２６および発注済みフラグ記憶領域２７を参照して、算出された合計値が閾値より小さい金種に対して、発注する該当金種の枚数（硬貨の場合は個数。なお、枚数や個数に注目する代わりに金額に注目すると、これは、「自動発注額」という表現になる）を含む発注内容データを発注依頼書データに追加する、ことを全ての金種について行う。
【００３４】
発注依頼書データ送信部２４は、発注依頼書データ作成部２３の処理結果として作成された発注依頼書データをＦＡＸモデム７、公衆回線８を通して発注先（釣銭準備金提供会社のファクシミリ（ＦＡＸ）９）に送信する。
【００３５】
閾値ＤＢ２５には、閾値テーブルが記憶される。 自動発注額ＤＢ２６には、自動発注額テーブルが記憶される。
図４は、閾値テーブル３６および自動発注額テーブル３７のデータ構造を示す図である。
【００３６】
図４に示すように、閾値テーブル３６は、金種（５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、５０円玉、１０円玉、５円玉、１円玉）別に、その金種の下限を示す閾値を定めたテーブルである。この閾値は、その金種の残枚数（紙幣の場合）、あるいは、残個数（硬貨の場合）が店舗内合計値で何枚（何個）以下になったとき、その金種の紙幣（硬貨）の釣銭準備金を発注するかを定めた値である。
【００３７】
また、図４に示すように、自動発注額テーブル３７は、 金種別に、その金種が閾値テーブル３６の閾値以下になったときの発注数（何枚または何個）を定めたテーブルである。なお、この自動発注額テーブル３７は一例であり、他の形態（閾値から減った分量に応じて発注数を決めるなど）も採用可能である。
【００３８】
図２の発注済みフラグ記憶領域２７には、発注済みフラグテーブルが記憶される。
図５は、発注済みフラグテーブル３８のデータ構造を示す図である。
図５に示すように、発注済みフラグテーブル３８は、金種別に、その金種の紙幣（硬貨）を発注済みであるかどうか（配達されたかどうかは不明）を示す発注済みフラグ、を有するテーブルである。この発注済みフラグは、オン（値"１"）のとき、発注済みであることを示し、オフ（値"０（ゼロ）"）のとき、未発注であることを示している。
【００３９】
なお、閾値テーブル３６、自動発注額テーブル３７、および、発注済みフラグテーブル３８を用いた発注依頼書データ作成部２３の処理内容については、図６Ａ、図６Ｂのフローチャートで後述する。
【００４０】
図６Ａおよび図６Ｂは、本実施形態の釣銭準備金発注処理のフローチャートである。このフローチャートの処理は、図２の管理サーバ３の各部により定期的に（一定時間が経過する度に）実行される。
【００４１】
前回起動時から一定時間が経過したことをトリガとして一連の処理が起動する。
図６ＡのステップＳ１で、金種別残数取得依頼送信部２１により、金種別残数取得依頼が管理サーバ３に接続されている全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎに対して同報通信（ブロードキャスト）される。
【００４２】
上述したように、この金種別残数取得依頼を受信したＰＯＳ端末あるいは自動出金機側では、自端末あるいは自機の金種別残数を有する金種別残数情報を生成し、その生成された金種別残数情報を管理サーバ３に送信する。
【００４３】
図６ＡのステップＳ２では、金種別残数合計値算出部２２により、金種別残数情報をＰＯＳ端末または自動出金機から受信したかどうかが判定される。
金種別残数情報を受信しない限り（ステップＳ２の判定結果がＮＯである間は）、ステップＳ２の判定処理が繰り返される。
【００４４】
ステップＳ２で金種別残数情報が受信されたと判定された場合（ステップＳ２の判定結果がＹＥＳである場合）、続くステップＳ３で、金種別残数合計値算出部２２により、全ての自動出金機およびＰＯＳ端末から金種別残数情報を受信済みかどうかが判定される。
【００４５】
ステップＳ３で全ての自動出金機およびＰＯＳ端末から受信済みでないと判定された場合（ステップＳ３の判定結果がＮＯの場合）、ステップＳ２の金種別残数情報受信待ち状態に戻る。
【００４６】
ステップＳ３で全ての自動出金機およびＰＯＳ端末から受信済みであると判定された場合（ステップＳ３の判定結果がＹＥＳの場合）、ステップＳ４で、金種別残数合計値算出部２２により、全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎからの金種別残数情報が金種別に集計されて、金種別に残数の合計値が算出される。そして、制御が、金種別残数合計値算出部２２から発注依頼書データ作成部２３に移り、この発注依頼書データ作成部２３により、後続のステップＳ５〜ステップＳ１１が実行される。
【００４７】
ステップＳ５〜ステップＳ１１のうちの、ステップＳ６〜ステップＳ９の処理は、所定の金種に対して行なわれるものである。このため、ステップＳ５で現在の金種を設定する。設定方法は全ての金種を１度ずつ実行する任意の方法でよいが、一例としては、５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、５０円玉、１０円玉、５円玉、１円玉、の順に実行すること（金種の金額の降順に実行すること）が考えられる。この場合、初回にステップＳ５が実行されるときは、現在の金種に"５，０００円札"が設定され、２回目にステップＳ５が実行されるときは、現在の金種に"１，０００円札"が設定される、等する。
【００４８】
図６ＡのステップＳ５に続く図６ＢのステップＳ６では、発注依頼書データ作成部２３により、現在の金種において、ステップＳ４で算出された合計値と閾値ＤＢ２５に記憶される閾値とが比較される。
【００４９】
ステップＳ６で現在の金種において合計値が閾値より大きいと判定された場合（ステップＳ６の判定結果がＹＥＳの場合）、ステップＳ７で、発注済みフラグテーブル３８上の現在の金種に対する発注済みフラグの値がオフに設定され、ステップＳ１０に進む。
【００５０】
ステップＳ６で現在の金種において合計値が閾値以下であると判定された場合（ステップＳ６の判定結果がＮＯの場合）、ステップＳ８で、現在の金種における発注済みフラグの値がオンであるかどうかが判定される。
【００５１】
ステップＳ８で現在の金種における発注済みフラグの値がオンであると判定された場合（ステップＳ８の判定結果がＹＥＳの場合）、ステップＳ１０に進む。
ステップＳ８で現在の金種における発注済みフラグの値がオフであると判定された場合（ステップＳ８の判定結果がＮＯの場合）、ステップＳ９で、現在の金種における発注済みフラグの値をオンにし、自動発注額テーブル３７上の現在の金種に対する発注数を発注依頼書データに追加（発注依頼書データがまだこの時点で存在しない場合は、発注依頼書データを生成後に追加）する。そして、ステップＳ１０に進む。
【００５２】
ステップＳ７、ステップＳ８（判定結果がＹＥＳの場合）、ステップＳ９から制御を渡されたステップＳ１０では、発注依頼書データ作成部２３により、全ての金種（５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、５０円玉、１０円玉、５円玉、１円玉）について処理済みかどうかが判定される。
【００５３】
ステップＳ１０で全ての金種について処理済みでないと判定された場合（ステップＳ１０の判定結果がＮＯの場合）、ステップＳ５に戻り、次の金種を現在の金種に設定し、ステップＳ６以降の処理を続行する。
【００５４】
ステップＳ１０で全ての金種について処理済みであると判定された場合（ステップＳ１０の判定結果がＹＥＳの場合）、ステップＳ１１で、発注依頼書データ作成部２３により、ステップＳ５〜ステップＳ１０の処理結果としての発注依頼書データが存在するかどうかが判定される。
【００５５】
ステップＳ１１で発注依頼書データが存在しないと判定された場合（ステップＳ１１の判定結果がＮＯの場合）、一連の処理を終了する。
ステップＳ１１で発注依頼書データが存在すると判定された場合（ステップＳ１１の判定結果がＹＥＳの場合）、制御が、発注依頼書データ作成部２３から発注依頼書データ送信部２４に移り、ステップＳ１２で、発注依頼書データ送信部２４により、処理結果としての発注依頼書データがＦＡＸモデム７、公衆回線８、を通して釣銭準備金提供会社のファクシミリ９あてに送信される。
【００５６】
以上説明したように、提案する釣銭準備金管理システムでは、管理サーバ３から各自動出金機および各ＰＯＳ端末に定期的に金種別残数取得依頼が送信され、管理サーバ３の金種別残数合計値算出部２２により、各自動出金機および各ＰＯＳ端末からの金種別残数取得依頼に対する応答としての金種別残数情報が金種別に集計され、金種別に残数の合計値が算出される。また、管理サーバ３の発注依頼書データ作成部２３により、算出された合計値と閾値ＤＢ２５内の閾値テーブル３６の閾値とが金種別に比較され、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、公衆回線８を介して、その処理結果として作成された発注依頼書データが釣銭準備金提供会社のファクシミリ９あてに送信される。これにより、各自動出金機内の釣銭準備金と各ＰＯＳ端末（に接続された釣銭釣札機）内の釣銭準備金とを定期的にシステム管理し、金種別に、システムが設置された店舗内の釣銭準備金（残数）が予め定められた額（閾値）以下になった時点で自動的に釣銭準備金提供会社等の発注先に必要額の釣銭準備金が通知され、釣銭準備金が配達されるので、釣銭準備金発注に要する手間を軽減することができる。
【００５７】
また、提案する釣銭準備金管理システムでは、管理サーバ３の発注依頼書データ作成部２３が、算出された合計値が閾値より大きい金種に対しては、発注済みフラグをオフにする（図６ＢのステップＳ７）ことで、未発注時に合計値が閾値を上回っている金種に対しては未発注の状態が維持され、発注した釣銭準備金を補充後の初回残量チェック時に、発注済みの状態を未発注に戻すことができる。
【００５８】
また、発注依頼書データ作成部２３が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、発注依頼書データにその金種の発注内容データを追加する（図６ＢのステップＳ８の判定結果がＮＯ、および、ステップＳ９）ことで、前回未発注であって今回合計値が閾値を下回っている金種に対して発注を行うことができる。
【００５９】
また、発注依頼書データ作成部２３が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオンであった場合に、その金種に対する処理をバイパスする（何も行なわない、図６ＢのステップＳ８の判定結果がＹＥＳの場合）ことで、発注済みで閾値を下回っている金種に対しては重複して発注することを避けることができる。これにより、発注済みかどうかの情報管理も自動で行なうことができ、釣銭準備金発注に要する手間をさらに軽減できる。なお、全金種に対して行われる残数チェックの周期は充分短く、配達後の次回チェック時に閾値以下と判定されることはないものとする。
【００６０】
続いて、図７〜図９を参照して、具体的なデータ例を示しつつ、本システムの動作例を説明する。実際のシステムでは、釣銭釣札機に接続されたＰＯＳ端末や自動出金機はともに１台以上の任意の台数店舗に設置されていてもよいが、この図７〜図９に示す例では、ＰＯＳ端末、自動出金機はともに１台ずつ（１号機のみ）存在する。また、金種も、５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、・・・と複数種類あるが、この図７〜図９に示す例では、主に１，０００円札を扱う。
【００６１】
図７は、システムへのパラメータの登録および運用開始時の処理を例示するシステムフローである。
図７のフェーズ１では、閾値設定が行なわれる。図７の（１）で、管理サーバに接続されたシステムパラメータ入力用端末（不図示）などから店舗の管理者等によって、閾値ＤＢ２５の閾値テーブル３６に対し、５，０００円札に対し、３００枚以下で発注となるように、３００（枚）が閾値として入力される。また、１，０００円札に対し、３００枚以下で発注となるように、３００（枚）が閾値として入力される。また、１００円玉に対し、３００個以下で発注となるように、３００（個）が閾値として入力される。
【００６２】
図７のフェーズ２では、自動発注額設定が行なわれる。図７の（２）で、管理サーバに接続されたシステムパラメータ入力用端末（不図示）などから店舗の管理者等によって、自動発注額ＤＢ２６の自動発注額テーブル３７に対し、５，０００円札に対し、店舗内合計残枚数が閾値以下の枚数となったときに５００枚発注するように、５００（枚）が自動発注額（枚数）として入力される。また、１，０００円札に対し、店舗内合計残枚数が閾値以下の枚数となったときに５００枚発注するように、５００（枚）が自動発注額（枚数）として入力される。また、１００円玉に対し、店舗内合計残個数が閾値以下の個数となったときに５００個発注するように、５００（個）が自動発注額（枚数）として入力される。
【００６３】
図７のフェーズ３では、管理サーバ３により、（３）で、運用開始時に各機器（釣銭釣札機に接続されたＰＯＳ端末および自動出金機）に対し、所定のタイミングで（一定時間が経過する度に）各金種につき残数を取得すべく金種別残数取得依頼が送信される。なお、ここでは、単純化して１，０００円札の残枚数のみ対象とする（実際はすべての金種が取得処理の対象である）。図７の（４）で、自動出金機１号機から１，０００円札４００枚、ＰＯＳ端末１号機から１，０００円札５０枚、を上記依頼に対する応答として取得し、店舗内１，０００円札合計を４５０枚として算出する。続く（５）で、この４５０枚が１，０００円札に対して自動発注を行なう場合の閾値３００枚と比較される。この場合、４５０枚＞３００枚であり、１，０００円札に対する自動発注はない。
【００６４】
図８は、システム運用時の、自動出金機からＰＯＳ端末への釣銭準備金補充処理を例示するシステムフローである。
図８のフェーズ４では、レジでのお客様への精算に対応して、ＰＯＳ端末１号機で１，０００円札５０枚を使用し、ＰＯＳ端末１号機で１，０００円札の残枚数が５０枚から０枚に減ってしまったとする。これに対応して、自動出金機１号機内の１，０００円札４００枚のうちの２００枚が自動出金機１号機からＰＯＳ端末１号機に人手により移される（ＰＯＳ端末１号機に対し１，０００円札２００枚を補充した）。その後、管理サーバ３により、図８の（１）で、各機器（釣銭釣札機に接続されたＰＯＳ端末および自動出金機）に対し、所定のタイミングで各金種につき残数を取得すべく金種別残数取得依頼が送信される。 なお、ここでは、単純化して１，０００円札の残枚数のみ対象とする。図８の（２）で、自動出金機１号機から１，０００円札２００枚、ＰＯＳ端末１号機から１，０００円札２００枚、を上記依頼に対する応答として取得し、店舗内１，０００円札合計を４００枚として算出する。続く（３）で、この４００枚が１，０００円札に対して自動発注を行なう場合の閾値３００枚と比較される。この場合、４００枚＞３００枚であり、１，０００円札に対する自動発注はない。
【００６５】
図９は、システム運用時の、店舗内釣銭準備金残高が閾値を下回った場合の処理を例示するシステムフローである。
図９のフェーズ５では、レジでのお客様への精算に対応して、ＰＯＳ端末１号機で１，０００円札１１０枚を使用し、ＰＯＳ端末１号機で１，０００円札の残枚数が２００枚から９０枚に減ってしまったとする。自動出金機１号機内の１，０００円札の残数は２００枚のままである。その後、管理サーバ３により、図９の（１）で、各機器（釣銭釣札機に接続されたＰＯＳ端末および自動出金機）に対し、所定のタイミングで各金種につき残数を取得すべく金種別残数取得依頼が送信される。 なお、ここでは、単純化して１，０００円札の残枚数のみ対象とする。図９の（２）で、自動出金機１号機から１，０００円札２００枚、ＰＯＳ端末１号機から１，０００円札９０枚、を上記依頼に対する応答として取得し、店舗内１，０００円札合計を２９０枚として算出する。続く（３）で、この２９０枚が１，０００円札に対して自動発注を行なう場合の閾値３００枚と比較される。この場合、２９０枚＜３００枚であり、（４）で、自動発注額ＤＢ２６により、１，０００円札に対し、５００枚発注することが確定し、（５）で、「１，０００円札５００枚を明日届けてください」と記載された発注依頼書データが作成され、（６）で、作成された発注依頼書データがＦＡＸモデムを通して釣銭準備金提供会社のファクシミリあてに送信される。
【符号の説明】
【００６６】
１、１−１、・・・、１−ｍ、５１ ＰＯＳ端末
２−１、・・・、１−ｍ 釣銭釣札機
３ 管理サーバ
５、５−１、・・・、５−ｎ 自動出金機
６ 依頼書データ
７ ＦＡＸモデム
８、５８ 公衆回線
９、５７、５９ ファクシミリ（ＦＡＸ）
１１、５６、６１ 依頼書（紙媒体）
２１ 金種別残数取得依頼送信部
２２ 金種別残数合計値算出部
２３ 発注依頼書データ作成部
２４ 発注依頼書データ送信部
２５ 閾値ＤＢ
２６ 自動発注額ＤＢ
２７ 発注済みフラグ記憶領域
３１、３３ 金種別残数情報作成部
３２、３４ 金種別残数情報送信部
３５ 金種別残数情報
３６ 閾値テーブル
３７ 自動発注額テーブル
３８ 発注済みフラグテーブル
５５ 金庫
【技術分野】
【０００１】
本発明は、店舗で客に釣銭、釣札として渡すために準備する釣銭準備金の管理システムに関する。
【背景技術】
【０００２】
百貨店、ショッピングセンター、量販店、等の店舗で商品を購入する際に、客はそこに設置されているＰＯＳ（Point of Sale）端末を通して、商品代金の精算（決済）を行なう。決済に際しては、商品の購入代金に一致する、あるいは、商品の購入代金を上回る金額の紙幣、硬貨が客により支払われる。
【０００３】
客が支払った金額のうち、商品代金に対する超過分については、釣銭、釣札として客にお釣をその場で返すが、この釣銭、釣札用に店舗毎に準備されているお金が釣銭準備金である。なお、慣習で、釣銭準備金というが、これは、釣銭（５００円玉、１００円玉、１０円玉、５円玉、１円玉）の他に、釣札（５０００円札、２０００円札、１０００円札）も含むものとする。
【０００４】
図１０は、従来の店舗における釣銭準備金の準備の流れを示す図である。
図１０において、（１）で、店舗稼動中に、店舗の担当者（マネージャー）が定期的に（釣銭釣札機に接続された）ＰＯＳ端末５１内の釣銭残量（釣銭準備金）を確認する。例えば、そのＰＯＳ端末の釣銭残量がマネージャーが経験として知る基準値より少ない場合には、（２）で、店舗のマネージャーは金庫５５から（基準値からの）不足分の釣銭準備金を取り出し、そのＰＯＳ端末にセットする。
【０００５】
金庫５５内の釣銭準備金が例えばマネージャーが経験として知る基準値より減った場合、（３）で、釣銭準備金の提供会社（主に、警備輸送会社）に（基準値からの）不足額を記載した依頼書（ここでは紙媒体）５６をＦＡＸし発注する。すなわち、ファクシミリ（ＦＡＸ）５７を通してその依頼書の記載内容を画像データ化して、釣銭準備金提供会社のファクシミリ５９に公衆回線５８を通して送信する。釣銭準備金提供会社では、（４）で、その受信側のファクシミリ５９で画像データを印字した依頼書６１を受け取ることで、発注を受け、その後、釣銭準備金をその店舗に配達する。
【０００６】
（５）で、釣銭準備金を受け取った店舗側では、マネージャーが、その釣銭準備金を金庫５５に保管し、ＰＯＳ端末の釣銭不足に備える。
ここで、ＰＯＳ端末（釣銭釣札機）内の釣銭準備金の基準値や、金庫内の釣銭準備金の基準値は例えばマネージャーの経験により決められている。また、以下の２つの問題点がある。
【０００７】
第１の問題点は、ＰＯＳ端末内の釣銭準備金が不足しているかどうかの確認（金種毎の残数確認）を、１台１台のＰＯＳ端末を回って人手で頻繁に確認しないと、店舗として釣銭準備金が不足する事態が生じ、店舗業務に支障が生じてしまう。この確認作業が手間である。
【０００８】
第２の問題点は、金庫内の釣銭準備金が不足した場合などに人が判断して、釣銭準備金の発注を行なっているので手間である。
なお、関連技術として、特許文献１には、百貨店、ショッピングセンターなどの大規模店舗群において、店舗毎の収納部を備えた釣銭ロッカーと、店舗毎のＰＯＳ端末とを有する釣銭準備管理システムが示されている。このシステムでは、店舗毎に、釣銭ロッカーの対応する収納部の釣銭残量を検出し、それが基準を下回っていた場合に、釣銭準備催促情報をＰＯＳ端末に配信して、店舗側担当者に釣銭準備金関連業務の一部を行なわせることで、経費増大を抑制し、釣銭準備金関連業務を円滑に行なわせている。
【０００９】
この特許文献１の技術の場合、釣銭ロッカーの収納部内の釣銭残量が必ずしもその店舗の釣銭準備金の多寡を反映しているとはいえず、判断の精度が十分に高いとはいえない。
また、特許文献２には、周辺技術として、店舗毎の現金有高、その回収タイミング等をネットワークで管理し、この管理情報を別のネットワークで使用して、金融機関からの資金調達を行なう技術が示されている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２０１０−２１８２９２号公報
【特許文献２】特開２００９−０５９２９４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、上記問題を解決するためになされたものであり、釣銭準備金発注に要する手間を軽減することを可能とした釣銭準備金管理システムおよび方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
提案する釣銭準備金管理システムは、１台以上の出金機と、１台以上のＰＯＳ端末と、管理サーバとがネットワークを通して接続されたシステムである。
前記各出金機および前記各ＰＯＳ端末は、前記管理サーバから定期的に受信する金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を生成し、前記管理サーバに送信する金種別残数情報生成部、を有する。
【００１３】
前記管理サーバは、準備金として準備すべき最低金額を示す金種別の閾値を記憶する閾値情報記憶部と、前記各出金機および前記各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出する金種別残数合計値算出部と、算出された合計値と前記閾値情報記憶部の閾値とを金種別に比較し、算出された合計値が閾値より小さい金種に対して発注依頼書データに追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを発注先に送信する発注依頼書データ作成部と、を有する。
【００１４】
また、前記釣銭準備金管理システムにおいて、前記管理サーバは、準備金を発注したかどうかを示す発注済みフラグ情報を金種別に記憶する発注済みフラグ記憶部、をさらに有してもよい。この場合、前記発注依頼書データ作成部は、全ての金種について下記（１）、（２）の処理を行い、その処理結果として作成された発注依頼書データを前記発注先に送信する。
（１）算出された合計値が閾値より大きい金種に対しては、発注済みフラグをオフにする。
（２）算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、その金種に対し発注依頼書データを追加する。
【発明の効果】
【００１５】
提案する釣銭準備金管理システムでは、前記管理サーバから前記各出金機および前記各ＰＯＳ端末に定期的に金種別残数取得依頼が送信され、前記管理サーバの金種別残数合計値算出部により、前記各出金機および前記各ＰＯＳ端末からの前記金種別残数取得依頼に対する応答としての金種別残数情報が金種別に集計され、金種別に残数の合計値が算出される。また、前記管理サーバの発注依頼書データ作成部により、算出された合計値と前記閾値情報記憶部の閾値とが金種別に比較され、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データが発注先に送信される。これにより、各出金機内の釣銭準備金と各ＰＯＳ端末内の釣銭準備金とを定期的にシステム管理し、金種別に、システムが設置された店舗内の釣銭準備金（残数）が予め定められた額（閾値）以下になった時点で自動的に釣銭準備金提供会社等の発注先に必要額の釣銭準備金が通知され配達されるので、釣銭準備金発注に要する手間を軽減することができる。
【００１６】
また、提案する釣銭準備金管理システムでは、前記管理サーバが、金種別の発注済みフラグ情報を記憶する発注済みフラグ記憶部を有する場合には、前記発注依頼書データ作成部が、算出された合計値が閾値より大きい金種に対しては、発注済みフラグをオフにすることで、未発注時に合計値が閾値を上回っている金種に対しては未発注の状態が維持され、発注した釣銭準備金を補充後の初回残量チェック時に、発注済みの状態を未発注に戻すことができる。また、前記発注依頼書データ作成部が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、発注依頼書データにその金種の発注内容データを追加することで、前回未発注であって今回合計値が閾値を下回っている金種に対して発注を行うことができる。また、前記発注依頼書データ作成部が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオンであった場合に、その金種に対する処理をバイパスする（何も行なわない）ことで、発注済みで閾値を下回っている金種に対しては重複して発注することを避けることができる。これにより、発注済みかどうかの情報管理も自動で行なうことができ、釣銭準備金発注に要する手間をさらに軽減できる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係る釣銭準備金管理システムが設置された店舗における釣銭準備金の準備の流れを示す図である。
【図２】本実施形態の釣銭準備金管理システムのブロック図である。
【図３】釣銭釣札機に接続されたＰＯＳ端末、あるいは、自動出金機により生成された金種別残数情報のデータ構造を示す図である。
【図４】閾値テーブルおよび自動発注額テーブルのデータ構造を示す図である。
【図５】発注済みフラグテーブルのデータ構造を示す図である。
【図６Ａ】本実施形態の釣銭準備金発注処理のフローチャート（その１）である。
【図６Ｂ】本実施形態の釣銭準備金発注処理のフローチャート（その２）である。
【図７】システムへのパラメータの登録および運用開始時の処理を例示するシステムフローである。
【図８】システム運用時の、自動出金機からＰＯＳ端末への釣銭準備金補充処理を例示するシステムフローである。
【図９】システム運用時の、店舗内釣銭準備金残高が閾値を下回った場合の処理を例示するシステムフローである。
【図１０】従来の店舗における釣銭準備金の準備の流れを示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明に係る実施の形態について図面を参照して詳細に説明する。
提案する釣銭準備金管理システムは、店舗内に設置され、管理サーバと１台以上のＰＯＳ端末と、１台以上の自動出金機とを有し、それらが有線あるいは無線のネットワーク（ＬＡＮ（Local Area Network）等）で互いに接続されたシステムである。このシステムでは、運用開始に先立つ準備として、下記準備１〜準備３を行なう。
準備１：ＰＯＳ端末と釣銭釣札機を接続し、釣銭釣札機内の釣銭準備金の残額（"残量"ともいう、あるいは、単に"釣銭準備金額"ということもある）をリモート確認できるようにする。
準備２：自動出金機内の釣銭準備金の残額をリモート確認できるようにする。
準備３：１台以上のＰＯＳ端末（釣銭釣札機）と１台以上の自動出金機が設置された店舗内の釣銭準備金の（金種毎の）総計がいくら以下になったら自動発注を行なうかを示す（金種毎の）閾値と、その（金種毎の）閾値を下回ったときの（金種毎の）発注量をシステムへ登録する。
【００１９】
このような登録作業を経て、システム運用時には、各ＰＯＳ端末（釣銭釣札機）内と各自動出金機内との釣銭準備金の（金種毎の）残額を定期的にオンラインで確認し、その金種毎の合計値が店舗内の釣銭準備金の（金種毎の）閾値をそれぞれ下回っているかどうかを監視する。閾値を下回った金種については、予め発注量として登録しておいた金額相当の釣銭準備金を釣銭準備金提供会社へ自動発注する。
【００２０】
図１は、本発明の一実施形態に係る釣銭準備金管理システムが設置された店舗における釣銭準備金の準備の流れを示す図である。
図１において、（１）で、運用開始に先立つ準備として、自動発注を行なう釣銭準備金額の（金種毎の）閾値と、その閾値を下回ったときの（金種毎の）発注量を管理サーバ３へ登録する。
【００２１】
そして、システム運用時には、（２）で、各（釣銭釣札機に接続された）ＰＯＳ端末（ここではＰＯＳ端末１の１台のみ示されている）内と各自動出金機（ここでは自動出金機５のみ示されている）内との釣銭準備金の（金種毎の）残額（残量）を管理サーバ３は定期的にオンラインで取得し、（３）で、（２）で取得した各（釣銭釣札機に接続された）ＰＯＳ端末および各自動出金機の釣銭準備金残量を（金種毎に）合計して、店舗内の釣銭準備金の残量トータル値（合計値）を金種毎に算出する。
【００２２】
そして、（３）で管理サーバ３により算出された金種毎の合計値が店舗内の釣銭準備金の（金種毎の）閾値をそれぞれ下回っているかどうかが判定され、閾値を下回った金種については、（４）で、予め発注量として登録しておいた金額相当の釣銭準備金を釣銭準備金提供会社へ自動発注する。
【００２３】
すなわち、ＦＡＸモデム７を通して発注内容が画像データ化された依頼書データ６が、釣銭準備金提供会社のファクシミリ（ＦＡＸ）９あてに送信され、その受信側のファクシミリ９において、画像データを印字した依頼書（紙媒体）１１を受け取ることで、釣銭準備金提供会社において発注が受け付けられ、後に、釣銭準備金がその店舗に配達される。
【００２４】
図２は、本実施形態の釣銭準備金管理システムのブロック図である。
図２に示すように、本実施形態の釣銭準備金管理システムは、ｍ台の釣銭釣札機２−１、・・・、２−ｍにそれぞれ接続されたｍ台のＰＯＳ端末１−１、・・・１−ｍ、ｎ台の自動出金機５−１、・・・、５−ｎ、管理サーバ３、を有し、それらが互いにネットワーク（ここではＬＡＮ１２）で接続されている。
【００２５】
ｍ台のＰＯＳ端末１−１、・・・１−ｍは、図２に示すように、ｍ台の釣銭釣札機２−１、・・・、２−ｍにそれぞれ接続されている。ＰＯＳ端末１−１、・・・１−ｍのそれぞれ（図２ではｍ台を代表してＰＯＳ端末１−１についてブロック図が示されている）は、金種別残数情報作成部３１および金種別残数情報送信部３２を有する。
【００２６】
金種別残数情報作成部３１は、管理サーバ３から定期的に受信する金種別残数取得依頼に対応して、自端末の金種別残数を有する金種別残数情報を生成する。金種別残数情報送信部３２は、生成された金種別残数情報を管理サーバ３に送信する。
【００２７】
ｎ台の自動出金機５−１、・・・、５−ｎのそれぞれ（図２ではｎ台を代表して自動出金機５−１についてブロック図が示されている）は、金種別残数情報作成部３３および金種別残数情報送信部３４を有する。
【００２８】
金種別残数情報作成部３３は、管理サーバ３から定期的に受信する金種別残数取得依頼に対応して、自機の金種別残数を有する金種別残数情報を生成する。金種別残数情報送信部３４は、生成された金種別残数情報を管理サーバ３に送信する。
【００２９】
図３は、釣銭釣札機に接続されたＰＯＳ端末、あるいは、自動出金機により生成された金種別残数情報３５のデータ構造を示す図である。
図３に示すように、金種別残数情報３５は、ＰＯＳ端末、あるいは、自動出金機のＩＤ、５，０００円札の残枚数、２，０００円札の残枚数、１，０００円札の残枚数、５００円玉の残個数、１００円玉の残個数、５０円玉の残個数、１０円玉の残個数、５円玉の残個数、１円玉の残個数、の各項目を有する。
【００３０】
図２の説明に戻る。図２において、管理サーバ３は、金種別残数取得依頼送信部２１、金種別残数合計値算出部２２、発注依頼書データ作成部２３、発注依頼書データ送信部２４、閾値ＤＢ２５、自動発注額ＤＢ２６、発注済みフラグ記憶領域２７、を有する。
【００３１】
金種別残数取得依頼送信部２１は、金種別残数取得依頼を管理サーバ３に接続されている全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎに対して同報通信（ブロードキャスト）する。
【００３２】
金種別残数合計値算出部２２は、全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎからの金種別残数情報を金種別に集計して、金種別に残数の合計値を算出する。
【００３３】
発注依頼書データ作成部２３は、算出された合計値と閾値ＤＢ２５に記憶される閾値とを金種別に比較し、自動発注額ＤＢ２６および発注済みフラグ記憶領域２７を参照して、算出された合計値が閾値より小さい金種に対して、発注する該当金種の枚数（硬貨の場合は個数。なお、枚数や個数に注目する代わりに金額に注目すると、これは、「自動発注額」という表現になる）を含む発注内容データを発注依頼書データに追加する、ことを全ての金種について行う。
【００３４】
発注依頼書データ送信部２４は、発注依頼書データ作成部２３の処理結果として作成された発注依頼書データをＦＡＸモデム７、公衆回線８を通して発注先（釣銭準備金提供会社のファクシミリ（ＦＡＸ）９）に送信する。
【００３５】
閾値ＤＢ２５には、閾値テーブルが記憶される。 自動発注額ＤＢ２６には、自動発注額テーブルが記憶される。
図４は、閾値テーブル３６および自動発注額テーブル３７のデータ構造を示す図である。
【００３６】
図４に示すように、閾値テーブル３６は、金種（５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、５０円玉、１０円玉、５円玉、１円玉）別に、その金種の下限を示す閾値を定めたテーブルである。この閾値は、その金種の残枚数（紙幣の場合）、あるいは、残個数（硬貨の場合）が店舗内合計値で何枚（何個）以下になったとき、その金種の紙幣（硬貨）の釣銭準備金を発注するかを定めた値である。
【００３７】
また、図４に示すように、自動発注額テーブル３７は、 金種別に、その金種が閾値テーブル３６の閾値以下になったときの発注数（何枚または何個）を定めたテーブルである。なお、この自動発注額テーブル３７は一例であり、他の形態（閾値から減った分量に応じて発注数を決めるなど）も採用可能である。
【００３８】
図２の発注済みフラグ記憶領域２７には、発注済みフラグテーブルが記憶される。
図５は、発注済みフラグテーブル３８のデータ構造を示す図である。
図５に示すように、発注済みフラグテーブル３８は、金種別に、その金種の紙幣（硬貨）を発注済みであるかどうか（配達されたかどうかは不明）を示す発注済みフラグ、を有するテーブルである。この発注済みフラグは、オン（値"１"）のとき、発注済みであることを示し、オフ（値"０（ゼロ）"）のとき、未発注であることを示している。
【００３９】
なお、閾値テーブル３６、自動発注額テーブル３７、および、発注済みフラグテーブル３８を用いた発注依頼書データ作成部２３の処理内容については、図６Ａ、図６Ｂのフローチャートで後述する。
【００４０】
図６Ａおよび図６Ｂは、本実施形態の釣銭準備金発注処理のフローチャートである。このフローチャートの処理は、図２の管理サーバ３の各部により定期的に（一定時間が経過する度に）実行される。
【００４１】
前回起動時から一定時間が経過したことをトリガとして一連の処理が起動する。
図６ＡのステップＳ１で、金種別残数取得依頼送信部２１により、金種別残数取得依頼が管理サーバ３に接続されている全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎに対して同報通信（ブロードキャスト）される。
【００４２】
上述したように、この金種別残数取得依頼を受信したＰＯＳ端末あるいは自動出金機側では、自端末あるいは自機の金種別残数を有する金種別残数情報を生成し、その生成された金種別残数情報を管理サーバ３に送信する。
【００４３】
図６ＡのステップＳ２では、金種別残数合計値算出部２２により、金種別残数情報をＰＯＳ端末または自動出金機から受信したかどうかが判定される。
金種別残数情報を受信しない限り（ステップＳ２の判定結果がＮＯである間は）、ステップＳ２の判定処理が繰り返される。
【００４４】
ステップＳ２で金種別残数情報が受信されたと判定された場合（ステップＳ２の判定結果がＹＥＳである場合）、続くステップＳ３で、金種別残数合計値算出部２２により、全ての自動出金機およびＰＯＳ端末から金種別残数情報を受信済みかどうかが判定される。
【００４５】
ステップＳ３で全ての自動出金機およびＰＯＳ端末から受信済みでないと判定された場合（ステップＳ３の判定結果がＮＯの場合）、ステップＳ２の金種別残数情報受信待ち状態に戻る。
【００４６】
ステップＳ３で全ての自動出金機およびＰＯＳ端末から受信済みであると判定された場合（ステップＳ３の判定結果がＹＥＳの場合）、ステップＳ４で、金種別残数合計値算出部２２により、全てのＰＯＳ端末１−１、・・・１−ｍおよび自動出金機５−１、・・・、５−ｎからの金種別残数情報が金種別に集計されて、金種別に残数の合計値が算出される。そして、制御が、金種別残数合計値算出部２２から発注依頼書データ作成部２３に移り、この発注依頼書データ作成部２３により、後続のステップＳ５〜ステップＳ１１が実行される。
【００４７】
ステップＳ５〜ステップＳ１１のうちの、ステップＳ６〜ステップＳ９の処理は、所定の金種に対して行なわれるものである。このため、ステップＳ５で現在の金種を設定する。設定方法は全ての金種を１度ずつ実行する任意の方法でよいが、一例としては、５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、５０円玉、１０円玉、５円玉、１円玉、の順に実行すること（金種の金額の降順に実行すること）が考えられる。この場合、初回にステップＳ５が実行されるときは、現在の金種に"５，０００円札"が設定され、２回目にステップＳ５が実行されるときは、現在の金種に"１，０００円札"が設定される、等する。
【００４８】
図６ＡのステップＳ５に続く図６ＢのステップＳ６では、発注依頼書データ作成部２３により、現在の金種において、ステップＳ４で算出された合計値と閾値ＤＢ２５に記憶される閾値とが比較される。
【００４９】
ステップＳ６で現在の金種において合計値が閾値より大きいと判定された場合（ステップＳ６の判定結果がＹＥＳの場合）、ステップＳ７で、発注済みフラグテーブル３８上の現在の金種に対する発注済みフラグの値がオフに設定され、ステップＳ１０に進む。
【００５０】
ステップＳ６で現在の金種において合計値が閾値以下であると判定された場合（ステップＳ６の判定結果がＮＯの場合）、ステップＳ８で、現在の金種における発注済みフラグの値がオンであるかどうかが判定される。
【００５１】
ステップＳ８で現在の金種における発注済みフラグの値がオンであると判定された場合（ステップＳ８の判定結果がＹＥＳの場合）、ステップＳ１０に進む。
ステップＳ８で現在の金種における発注済みフラグの値がオフであると判定された場合（ステップＳ８の判定結果がＮＯの場合）、ステップＳ９で、現在の金種における発注済みフラグの値をオンにし、自動発注額テーブル３７上の現在の金種に対する発注数を発注依頼書データに追加（発注依頼書データがまだこの時点で存在しない場合は、発注依頼書データを生成後に追加）する。そして、ステップＳ１０に進む。
【００５２】
ステップＳ７、ステップＳ８（判定結果がＹＥＳの場合）、ステップＳ９から制御を渡されたステップＳ１０では、発注依頼書データ作成部２３により、全ての金種（５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、５０円玉、１０円玉、５円玉、１円玉）について処理済みかどうかが判定される。
【００５３】
ステップＳ１０で全ての金種について処理済みでないと判定された場合（ステップＳ１０の判定結果がＮＯの場合）、ステップＳ５に戻り、次の金種を現在の金種に設定し、ステップＳ６以降の処理を続行する。
【００５４】
ステップＳ１０で全ての金種について処理済みであると判定された場合（ステップＳ１０の判定結果がＹＥＳの場合）、ステップＳ１１で、発注依頼書データ作成部２３により、ステップＳ５〜ステップＳ１０の処理結果としての発注依頼書データが存在するかどうかが判定される。
【００５５】
ステップＳ１１で発注依頼書データが存在しないと判定された場合（ステップＳ１１の判定結果がＮＯの場合）、一連の処理を終了する。
ステップＳ１１で発注依頼書データが存在すると判定された場合（ステップＳ１１の判定結果がＹＥＳの場合）、制御が、発注依頼書データ作成部２３から発注依頼書データ送信部２４に移り、ステップＳ１２で、発注依頼書データ送信部２４により、処理結果としての発注依頼書データがＦＡＸモデム７、公衆回線８、を通して釣銭準備金提供会社のファクシミリ９あてに送信される。
【００５６】
以上説明したように、提案する釣銭準備金管理システムでは、管理サーバ３から各自動出金機および各ＰＯＳ端末に定期的に金種別残数取得依頼が送信され、管理サーバ３の金種別残数合計値算出部２２により、各自動出金機および各ＰＯＳ端末からの金種別残数取得依頼に対する応答としての金種別残数情報が金種別に集計され、金種別に残数の合計値が算出される。また、管理サーバ３の発注依頼書データ作成部２３により、算出された合計値と閾値ＤＢ２５内の閾値テーブル３６の閾値とが金種別に比較され、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、公衆回線８を介して、その処理結果として作成された発注依頼書データが釣銭準備金提供会社のファクシミリ９あてに送信される。これにより、各自動出金機内の釣銭準備金と各ＰＯＳ端末（に接続された釣銭釣札機）内の釣銭準備金とを定期的にシステム管理し、金種別に、システムが設置された店舗内の釣銭準備金（残数）が予め定められた額（閾値）以下になった時点で自動的に釣銭準備金提供会社等の発注先に必要額の釣銭準備金が通知され、釣銭準備金が配達されるので、釣銭準備金発注に要する手間を軽減することができる。
【００５７】
また、提案する釣銭準備金管理システムでは、管理サーバ３の発注依頼書データ作成部２３が、算出された合計値が閾値より大きい金種に対しては、発注済みフラグをオフにする（図６ＢのステップＳ７）ことで、未発注時に合計値が閾値を上回っている金種に対しては未発注の状態が維持され、発注した釣銭準備金を補充後の初回残量チェック時に、発注済みの状態を未発注に戻すことができる。
【００５８】
また、発注依頼書データ作成部２３が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、発注依頼書データにその金種の発注内容データを追加する（図６ＢのステップＳ８の判定結果がＮＯ、および、ステップＳ９）ことで、前回未発注であって今回合計値が閾値を下回っている金種に対して発注を行うことができる。
【００５９】
また、発注依頼書データ作成部２３が、算出された合計値が閾値より小さい金種に対しては、発注済みフラグがオンであった場合に、その金種に対する処理をバイパスする（何も行なわない、図６ＢのステップＳ８の判定結果がＹＥＳの場合）ことで、発注済みで閾値を下回っている金種に対しては重複して発注することを避けることができる。これにより、発注済みかどうかの情報管理も自動で行なうことができ、釣銭準備金発注に要する手間をさらに軽減できる。なお、全金種に対して行われる残数チェックの周期は充分短く、配達後の次回チェック時に閾値以下と判定されることはないものとする。
【００６０】
続いて、図７〜図９を参照して、具体的なデータ例を示しつつ、本システムの動作例を説明する。実際のシステムでは、釣銭釣札機に接続されたＰＯＳ端末や自動出金機はともに１台以上の任意の台数店舗に設置されていてもよいが、この図７〜図９に示す例では、ＰＯＳ端末、自動出金機はともに１台ずつ（１号機のみ）存在する。また、金種も、５，０００円札、２，０００円札、１，０００円札、５００円玉、１００円玉、・・・と複数種類あるが、この図７〜図９に示す例では、主に１，０００円札を扱う。
【００６１】
図７は、システムへのパラメータの登録および運用開始時の処理を例示するシステムフローである。
図７のフェーズ１では、閾値設定が行なわれる。図７の（１）で、管理サーバに接続されたシステムパラメータ入力用端末（不図示）などから店舗の管理者等によって、閾値ＤＢ２５の閾値テーブル３６に対し、５，０００円札に対し、３００枚以下で発注となるように、３００（枚）が閾値として入力される。また、１，０００円札に対し、３００枚以下で発注となるように、３００（枚）が閾値として入力される。また、１００円玉に対し、３００個以下で発注となるように、３００（個）が閾値として入力される。
【００６２】
図７のフェーズ２では、自動発注額設定が行なわれる。図７の（２）で、管理サーバに接続されたシステムパラメータ入力用端末（不図示）などから店舗の管理者等によって、自動発注額ＤＢ２６の自動発注額テーブル３７に対し、５，０００円札に対し、店舗内合計残枚数が閾値以下の枚数となったときに５００枚発注するように、５００（枚）が自動発注額（枚数）として入力される。また、１，０００円札に対し、店舗内合計残枚数が閾値以下の枚数となったときに５００枚発注するように、５００（枚）が自動発注額（枚数）として入力される。また、１００円玉に対し、店舗内合計残個数が閾値以下の個数となったときに５００個発注するように、５００（個）が自動発注額（枚数）として入力される。
【００６３】
図７のフェーズ３では、管理サーバ３により、（３）で、運用開始時に各機器（釣銭釣札機に接続されたＰＯＳ端末および自動出金機）に対し、所定のタイミングで（一定時間が経過する度に）各金種につき残数を取得すべく金種別残数取得依頼が送信される。なお、ここでは、単純化して１，０００円札の残枚数のみ対象とする（実際はすべての金種が取得処理の対象である）。図７の（４）で、自動出金機１号機から１，０００円札４００枚、ＰＯＳ端末１号機から１，０００円札５０枚、を上記依頼に対する応答として取得し、店舗内１，０００円札合計を４５０枚として算出する。続く（５）で、この４５０枚が１，０００円札に対して自動発注を行なう場合の閾値３００枚と比較される。この場合、４５０枚＞３００枚であり、１，０００円札に対する自動発注はない。
【００６４】
図８は、システム運用時の、自動出金機からＰＯＳ端末への釣銭準備金補充処理を例示するシステムフローである。
図８のフェーズ４では、レジでのお客様への精算に対応して、ＰＯＳ端末１号機で１，０００円札５０枚を使用し、ＰＯＳ端末１号機で１，０００円札の残枚数が５０枚から０枚に減ってしまったとする。これに対応して、自動出金機１号機内の１，０００円札４００枚のうちの２００枚が自動出金機１号機からＰＯＳ端末１号機に人手により移される（ＰＯＳ端末１号機に対し１，０００円札２００枚を補充した）。その後、管理サーバ３により、図８の（１）で、各機器（釣銭釣札機に接続されたＰＯＳ端末および自動出金機）に対し、所定のタイミングで各金種につき残数を取得すべく金種別残数取得依頼が送信される。 なお、ここでは、単純化して１，０００円札の残枚数のみ対象とする。図８の（２）で、自動出金機１号機から１，０００円札２００枚、ＰＯＳ端末１号機から１，０００円札２００枚、を上記依頼に対する応答として取得し、店舗内１，０００円札合計を４００枚として算出する。続く（３）で、この４００枚が１，０００円札に対して自動発注を行なう場合の閾値３００枚と比較される。この場合、４００枚＞３００枚であり、１，０００円札に対する自動発注はない。
【００６５】
図９は、システム運用時の、店舗内釣銭準備金残高が閾値を下回った場合の処理を例示するシステムフローである。
図９のフェーズ５では、レジでのお客様への精算に対応して、ＰＯＳ端末１号機で１，０００円札１１０枚を使用し、ＰＯＳ端末１号機で１，０００円札の残枚数が２００枚から９０枚に減ってしまったとする。自動出金機１号機内の１，０００円札の残数は２００枚のままである。その後、管理サーバ３により、図９の（１）で、各機器（釣銭釣札機に接続されたＰＯＳ端末および自動出金機）に対し、所定のタイミングで各金種につき残数を取得すべく金種別残数取得依頼が送信される。 なお、ここでは、単純化して１，０００円札の残枚数のみ対象とする。図９の（２）で、自動出金機１号機から１，０００円札２００枚、ＰＯＳ端末１号機から１，０００円札９０枚、を上記依頼に対する応答として取得し、店舗内１，０００円札合計を２９０枚として算出する。続く（３）で、この２９０枚が１，０００円札に対して自動発注を行なう場合の閾値３００枚と比較される。この場合、２９０枚＜３００枚であり、（４）で、自動発注額ＤＢ２６により、１，０００円札に対し、５００枚発注することが確定し、（５）で、「１，０００円札５００枚を明日届けてください」と記載された発注依頼書データが作成され、（６）で、作成された発注依頼書データがＦＡＸモデムを通して釣銭準備金提供会社のファクシミリあてに送信される。
【符号の説明】
【００６６】
１、１−１、・・・、１−ｍ、５１ ＰＯＳ端末
２−１、・・・、１−ｍ 釣銭釣札機
３ 管理サーバ
５、５−１、・・・、５−ｎ 自動出金機
６ 依頼書データ
７ ＦＡＸモデム
８、５８ 公衆回線
９、５７、５９ ファクシミリ（ＦＡＸ）
１１、５６、６１ 依頼書（紙媒体）
２１ 金種別残数取得依頼送信部
２２ 金種別残数合計値算出部
２３ 発注依頼書データ作成部
２４ 発注依頼書データ送信部
２５ 閾値ＤＢ
２６ 自動発注額ＤＢ
２７ 発注済みフラグ記憶領域
３１、３３ 金種別残数情報作成部
３２、３４ 金種別残数情報送信部
３５ 金種別残数情報
３６ 閾値テーブル
３７ 自動発注額テーブル
３８ 発注済みフラグテーブル
５５ 金庫
【特許請求の範囲】
【請求項１】
１台以上の出金機と、１台以上のＰＯＳ端末と、管理サーバとがネットワークを通して接続された釣銭準備金自動発注システムにおいて、
前記各出金機および前記各ＰＯＳ端末は、前記管理サーバから定期的に受信する金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を生成し、前記管理サーバに送信する金種別残数情報生成部、を有し、
前記管理サーバは、準備金として準備すべき最低金額を示す金種別の閾値を記憶する閾値情報記憶部と、
前記各出金機および前記各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出する金種別残数合計値算出部と、
算出された合計値と前記閾値情報記憶部の閾値とを金種別に比較し、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを発注先に送信する発注依頼書データ作成部と、を有することを特徴とする釣銭準備金管理システム。
【請求項２】
前記管理サーバは、準備すべき最低金額を示す閾値を下回った場合の発注数を金種別に記憶する発注情報記憶部、をさらに有し、
前記発注依頼書データ作成部は、算出された合計値が閾値より小さい金種に対する発注数を、前記発注情報記憶部の記憶内容を基に決定し、発注依頼書データに、前記決定した発注数を含むその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを前記発注先に送信する、ことを特徴とする請求項１記載の釣銭準備金管理システム。
【請求項３】
前記管理サーバは、準備金を発注したかどうかを示す発注済みフラグ情報を金種別に記憶する発注済みフラグ記憶部、をさらに有し、
前記発注依頼書データ作成部は、算出された合計値が閾値より大きい金種に対して、発注済みフラグをオフにするとともに、
算出された合計値が閾値より小さい金種に対して、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを前記発注先に送信する、ことを特徴とする請求項１または２に記載の釣銭準備金管理システム。
【請求項４】
１台以上の出金機と、１台以上のＰＯＳ端末と、準備金として準備すべき最低金額を示す金種別の閾値を記憶する閾値情報記憶部を有する管理サーバとがネットワークを通して接続されたシステムが実行する釣銭準備金管理方法において、
前記各出金機および前記各ＰＯＳ端末が、前記管理サーバからの金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を生成し、前記管理サーバに送信するステップと、
前記管理サーバが、前記各出金機および前記各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出するステップと、
前記管理サーバが、算出された合計値と前記閾値情報記憶部の閾値とを金種別に比較し、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを発注先に送信するステップと、を有することを特徴とする釣銭準備金管理方法。
【請求項１】
１台以上の出金機と、１台以上のＰＯＳ端末と、管理サーバとがネットワークを通して接続された釣銭準備金自動発注システムにおいて、
前記各出金機および前記各ＰＯＳ端末は、前記管理サーバから定期的に受信する金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を生成し、前記管理サーバに送信する金種別残数情報生成部、を有し、
前記管理サーバは、準備金として準備すべき最低金額を示す金種別の閾値を記憶する閾値情報記憶部と、
前記各出金機および前記各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出する金種別残数合計値算出部と、
算出された合計値と前記閾値情報記憶部の閾値とを金種別に比較し、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを発注先に送信する発注依頼書データ作成部と、を有することを特徴とする釣銭準備金管理システム。
【請求項２】
前記管理サーバは、準備すべき最低金額を示す閾値を下回った場合の発注数を金種別に記憶する発注情報記憶部、をさらに有し、
前記発注依頼書データ作成部は、算出された合計値が閾値より小さい金種に対する発注数を、前記発注情報記憶部の記憶内容を基に決定し、発注依頼書データに、前記決定した発注数を含むその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを前記発注先に送信する、ことを特徴とする請求項１記載の釣銭準備金管理システム。
【請求項３】
前記管理サーバは、準備金を発注したかどうかを示す発注済みフラグ情報を金種別に記憶する発注済みフラグ記憶部、をさらに有し、
前記発注依頼書データ作成部は、算出された合計値が閾値より大きい金種に対して、発注済みフラグをオフにするとともに、
算出された合計値が閾値より小さい金種に対して、発注済みフラグがオフであった場合に、発注済みフラグをオンにして、発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを前記発注先に送信する、ことを特徴とする請求項１または２に記載の釣銭準備金管理システム。
【請求項４】
１台以上の出金機と、１台以上のＰＯＳ端末と、準備金として準備すべき最低金額を示す金種別の閾値を記憶する閾値情報記憶部を有する管理サーバとがネットワークを通して接続されたシステムが実行する釣銭準備金管理方法において、
前記各出金機および前記各ＰＯＳ端末が、前記管理サーバからの金種別残数取得依頼に対応して、自機、あるいは、自端末の金種別残数を有する金種別残数情報を生成し、前記管理サーバに送信するステップと、
前記管理サーバが、前記各出金機および前記各ＰＯＳ端末からの金種別残数情報を集計して、金種別に残数の合計値を算出するステップと、
前記管理サーバが、算出された合計値と前記閾値情報記憶部の閾値とを金種別に比較し、算出された合計値が閾値より小さい金種に対して発注依頼書データにその金種の発注内容データを追加することを全ての金種について行い、その処理結果として作成された発注依頼書データを発注先に送信するステップと、を有することを特徴とする釣銭準備金管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−２１２２６３（Ｐ２０１２−２１２２６３Ａ）
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願番号】特願２０１１−７６８６３（Ｐ２０１１−７６８６３）
【出願日】平成２３年３月３０日（２０１１．３．３０）
【出願人】（０００２３７６３９）富士通フロンテック株式会社 (667)
【Ｆターム（参考）】
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願日】平成２３年３月３０日（２０１１．３．３０）
【出願人】（０００２３７６３９）富士通フロンテック株式会社 (667)
【Ｆターム（参考）】
[ Back to top ]