営業日毎に銀行入金額を計算する銀行入金額計算部を有する端末を備えたPOSシステムであって、前記銀行入金額計算部は、釣銭ではない用途で使用された金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算することを特徴とするPOSシステム。請求項1に記載のPOSシステムにおいて、釣銭ではない用途で使用された金額は、釣銭ではない用途で使用された、釣銭準備金の一部の金額であり、その当日に得られた現金の合計額は、その当日の現金売上の合計額を含むことを特徴とするPOSシステム。請求項2に記載のPOSシステムにおいて、前記POSシステムは、店舗に設けられたPOS端末と、前記店舗に設けられ、前記銀行入金額計算部を有する前記端末として働くストアコントローラと、本部に設けられた本部サーバとを備え、前記ストアコントローラは、前記店舗において、前記POS端末のドロワの釣銭準備金の一部が釣銭ではない用途で使用された場合、釣銭ではない用途で使用された釣銭準備金の一部の補充申請をする補充申請データを、前記本部サーバに送信し、前記本部サーバは、前記補充申請データを受信すると、受信した補充申請データに基づいて、受信釣銭ではない用途で使用された、釣銭準備金の一部に関し、その使用の妥当性を判断し、妥当であった場合、補充承認したことを表す補充承認データを、前記ストアコントローラに送信し、前記ストアコントローラの前記銀行入金額計算部は、釣銭ではない用途で使用された金額を、前記ストアコントローラが前記補充承認データを受信した当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算するものであり、前記ストアコントローラが前記補充承認データを受信した当日を、前記使用の妥当性が判断されて承認された当日とすることを特徴とするPOSシステム。請求項3に記載のPOSシステムにおいて、前記POS端末及び前記ストアコントローラは、同一の店舗内に設けられ、前記本部サーバは、その店舗を経営する会社の本部に設けられていることを特徴とするPOSシステム。POSシステムに用いられ、営業日毎に銀行入金額を計算する銀行入金額計算部を有する端末であって、前記銀行入金額計算部は、釣銭ではない用途で使用された金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算することを特徴とする端末。請求項5に記載の端末において、釣銭ではない用途で使用された金額は、釣銭ではない用途で使用された、釣銭準備金の一部の金額であり、その当日に得られた現金の合計額は、その当日の現金売上の合計額を含むことを特徴とする端末。前記関連技術としてのPOSシステムでは、上述したように、使用した釣銭準備金の一部の補充を、前記本部に、書類によって申請している。この際の書類申請に関する手続きは、煩雑であり、また、書類申請を忘れることもあり、書類申請を忘れることが重なると釣銭準備金が不足するという事態も発生していた。このように、前記関連技術としてのPOSシステムでは、釣銭準備金等の現金の管理が明瞭ではない。本発明の目的は、上記の課題を解決し、POSシステムにおける釣銭準備金等の現金の管理を明瞭にしようとするものである。本発明の具体的な目的は、釣銭ではない用途で使用した釣銭準備金の一部の金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算するようにしたPOSシステムを提供することにある。本発明のもう一つの具体的な目的は、釣銭ではない用途で使用した釣銭準備金の一部の金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算するようにした、POSシステムに用いられる端末を提供することにある。本発明によれば、営業日毎に銀行入金額を計算する銀行入金額計算部を有する端末を備えたPOSシステムであって、前記銀行入金額計算部は、釣銭ではない用途で使用された金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算することを特徴とするPOSシステムが得られる。更に本発明によれば、POSシステムに用いられ、営業日毎に銀行入金額を計算する銀行入金額計算部を有する端末であって、前記銀行入金額計算部は、釣銭ではない用途で使用された金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算することを特徴とする端末が得られる。本発明によれば、POSシステムにおいて、釣銭ではない用途で使用した釣銭準備金の一部の金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算する。従って、釣銭ではない用途で使用した釣銭準備金の一部を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金から補充することができ、翌日の釣銭準備金が不足するという事態の発生を防止することができる。また、本発明により、POSシステムにおける現金管理が明瞭なものとなる。次に本発明の実施形態について詳細に説明する。図1を参照すると、本発明の第1の実施形態によるPOSシステムが示されている。この第1の実施形態によるPOSシステムは、チェーン店の飲食店の店舗10に設けられるPOS端末11及びストアコントローラ12と、その飲食店の店舗を経営する会社の本部20に設けられる本部サーバ21とを有する。図1に図示の構成は、最小の構成であって、本部サーバ21には、複数の店舗の複数のPOS端末及び複数のストアコントローラが接続されていてもよい。POS端末11は、ディスプレイ111、キーボード図示せず、レシート発行用プリンタ図示せず等の入出力手段を備え、飲食代の精算、即ち、売上処理等を行うコンピュータ端末である。ストアコントローラ12は、ディスプレイ121やキーボード図示せず等の入出力手段を備え、釣銭準備金の一部の補充の申請や店舗10内の現金管理等を行うコントロール端末である。POS端末11及びストアコントローラ12は、通信線で接続され、店舗10内に設置されている。なお、POS端末11及びストアコントローラ12は、無線で接続されても良い。本部サーバ21は、ディスプレイ211やキーボード図示せず等の入出力手段を備え、釣銭準備金の一部の補充の申請を受けて、補充の申請を処理するコンピュータ端末である。本部サーバ21は、ストアコントローラ12と通信線で接続され、本部20内に設置されている。以下、上述のチェーン店の飲食店において、POS端末11のドロワのその時点の釣銭準備金の一部を使って、不足した食材や店舗10の消耗品を購入した場合の図1のPOSシステムの動作を説明する。まず、不足した食材や店舗10の消耗品を購入するために使用した釣銭準備金の一部の補充の申請以下、これを補充申請或いは買物金申請と称するについて、記述する。図1において、従業員は、補充申請買物金申請する際には、まず、POS端末11によって、ディスプレイ111に処理メニュー選択画面図2Aを表示させ、その処理メニュー選択画面において、支払を選択し、仮払いを選択し図2B、金額を入力する図2C。POS端末11は、このデータ仮払い金額をストアコントローラ12に送信する。ストアコントローラ12は、仮払い金額を受信して支払として記憶する。図1において、続いて、従業員は、ストアコントローラ12によって、補充申請入力買物金申請入力を行う。即ち、従業員は、ストアコントローラ12によって、ディスプレイ121に買物金精算入力画面図3を表示させ、その買物金精算入力画面において、氏名を入力IDカードを読ませる等して氏名を入力してもよいし、新規入力を選択し、新規入力の選択により、図4に示す買物金精算入力画面が表示される。従業員は、ストアコントローラ12によって、図4に示すように、買物金精算入力画面に、領収証日付、支払先、摘要明細、金額、分類を入力し、入力が終わると確定を選択する。なお、分類は、入力不要としてもよい。ストアコントローラ12は、確定の選択により、前記入力されたデータのうちの合計金額領収証金額を、POS端末11から受信した仮払い金額に比較し、両者が一致する場合は、図5に示す買物金精算入力画面を表示する。従業員は、ストアコントローラ12によって、その表示された買物金精算入力画面において、図5に示すように、送付にレ点入力して送付を指示すると、前記入力されたデータ及び該入力されたデータに付与された申請書番号は、買物金申請データ補充申請データとして、本部サーバ21に送信される。なお、ストアコントローラ12は、図4に示す買物金精算入力画面において、前述の確定が選択された時、前記入力されたデータのうちの合計金額領収証金額を、POS端末11から受信した仮払い金額に比較し、両者が一致しない場合は、図5に示す買物金精算入力画面は表示せずに、前記領収証金額と前記仮払い金額とが一致しない旨を表示し、従業員に訂正を促す。従業員は、ストアコントローラ12によって、図4に示す買物金精算入力画面において前記入力されたデータを訂正し、訂正が終わると確定を選択する。確定の選択によりストアコントローラ12は上記と同様の動作を行う。図5は、送信直前のものであり、送信後は、ステータスが、未申請送付予定から、送信済みに変わる。図1において、ストアコントローラ12から本部サーバ21へ上記補充申請買物金申請を行う際には、ストアコントローラ12によって本部サーバ21へ上述のように前記買物金申請データ補充申請データを送信すると共に、補充申請買物金申請の元となったレシート領収証を、郵送、FAX等で本部20に送付する。なお、ストアコントローラにレシート領収証を画像として取り込む手段を設け、補充申請買物金申請時、レシート領収証を画像として取り込み、この電子データを前記買物金申請データ補充申請データとともに送信するようにしてもよい。釣銭準備金の一部を従業員の臨時の交通費として使用した場合は、図4に示す買物金精算入力画面の右欄に、交通費内訳を入力して、上記と同様に補充申請買物金申請を行う。次に、本部サーバ21での買物金承認補充承認について記述する。図1において、決裁者は、本部サーバ21によって、決裁者としての氏名を入力IDカードを読ませる等して氏名を入力してもよいし、送付された買物金申請データ補充申請データと、別途送付されたレシート領収証とに基づいて、釣銭準備金の一部の使用が妥当であるかを判断し、妥当であった場合、買物金承認補充承認する。決裁者は、承認確定後、本部サーバ21によって、ストアコントローラ12に、補充承認したことを表す補充承認データを承認済みデータとして送信する。図6は、本部サーバ21によって、ストアコントローラ12に送信された承認済みデータ補充承認データを示すものである。なお、当然ながら、店舗10からは、釣銭準備金の一部の使用が妥当であるもののみを補充申請買物金申請する。次に、ストアコントローラ12での買物金承認補充承認の確認について記述する。図1において、ストアコントローラ12は、本部サーバ21からの承認済みデータ補充承認データ図6を受信すると、受信した承認済みデータ補充承認データを、ディスプレイ121に表示させる。店舗10の従業員は、ストアコントローラ12のディスプレイ121に表示された承認済みデータ補充承認データを確認し、図6に示すように、確定をレ点入力によりチェックし登録することによって、ストアコントローラ12において釣銭準備金に補充する金額が確定する。なお、従業員は、ストアコントローラ12によって、ディスプレイ121に表示された承認済みデータ補充承認データ図6における送付番号をクリックすることによって、詳細を確認することができる。次に、買物金として使用された釣銭ではない用途で使用された釣銭準備金の一部の補充について記述する。買物金として使用された釣銭ではない用途で使用された釣銭準備金の一部の補充は、1買物金として使用された釣銭ではない用途で使用された釣銭準備金の一部の金額を、その使用の妥当性が判断されて承認された当日に、現金売上等のその当日に得られた現金の合計額から差し引いて得られた金額を、前記当日の銀行入金額とする計算をストアコントローラ12の銀行入金額計算部122において行うこと、及び2前記銀行入金額に相当するお金をPOS端末11のドロワより取り出して、銀行に入金して、POS端末11のドロワに残ったお金を、次の営業日の釣銭準備金とすることにより行われる。以下、ストアコントローラ12の銀行入金額計算部122の動作特に前記銀行入金額の計算について説明する。図1において、ストアコントローラ12の銀行入金額計算部122は、営業日ごとの閉店後、その日の売上高などをPOS端末11から受信し、その日の売上高などに基づいて、後述の式1にて示される銀行入金額を計算して、計算した銀行入金額をディスプレイ121に表示する。従業員は、ディスプレイ121に表示された金額をPOS端末11のドロワより取り出して、銀行に入金する。POS端末11のドロワに残ったお金は、次の営業日の釣銭準備金となる。基本的には、釣銭準備金としてA円が登録され、POS端末11のドロワに収納されているとし、その日の売上高をB円とすると、B円が銀行入金額となり、B円が銀行に入金される。釣銭準備金の一部が買物金として使用されていなければ、釣銭準備金として、POS端末11のドロワにA円が残る。ここで、釣銭準備金の一部X円が、買物金として使用されると、次の営業日の釣銭準備金は、A-X円となる。具体例を図7を参照して説明する。図7は、ある営業日の閉店後、銀行入金額をストアコントローラ12の銀行入金額計算部122において計算した後のストアコントローラ12のディスプレイ121に表示された画面である。図7において、POS精算キャッシュカウントの欄は、当日の釣銭準備金の金額、当日の現金売上の金額等を示している。釣銭登録は、当日、POS端末11で一切の処理を行う前のドロワ中の金額当日の釣銭準備金を示す。営業の最初の日には、釣銭準備金としてドロワに収納する金額を登録する。従って、この時は、釣銭準備金としてドロワに収納された金額が釣銭登録の金額である。現金売上は、当日の現金による売上の総額を示す。クレジットカード等による精算もあるが、本発明には直接関係しないため、現金による売上に限定する例としている。この現金売上のデータは、POS端末11から営業日ごとの閉店時に送信されてくる。入金は、当日、POS端末11の近傍に設置された寄付のための募金箱に、顧客によって募金された金額を示す。図1において、従業員は、POS端末11によって、ディスプレイ111に処理メニュー選択画面図2Aを表示させ、その処理メニュー選択画面において、入金を選択して、銀行入金額を計算する前に前記募金された金額を入力する。本例では、0円である。支払は、当日、買物金等として使用された金額を示す。現金在高は、以下の計算により求めた金額閉店時のPOS端末11のドロワに収納されている金額である。現金在高=釣銭登録現金売上入金-支払銀行入金額の欄は、銀行に入金すべき金額等を示している。手元現金有高は、釣銭登録と同一である。現金入金は、現金売上入金の金額である。買物申請は、当日、買物金申請を行って未承認の金額である。買物未申請は、当日、買物金申請を行って未申請の金額である。本例では、0円である。買物承認は、前日までに買物金として承認され、当日、確認処理した金額である。買物金申請を申請した当日に承認することも可能である。銀行入金額は、銀行に入金すべき金額を示すもので、以下の計算により求める。銀行入金額=現金入金-買物承認1手元有高あるべきは、銀行に入金する金額をドロワより取り出した後にドロワに残る金額次の営業日の釣銭準備金となるで、以下の計算により求める。手元有高あるべき=手元現金有高現金入金-買物申請-買物未申請-銀行入金額以上に説明したように本発明の第1の実施形態によるPOSシステムでは、ストアコントローラ12の銀行入金額計算部122は、釣銭ではない用途で使用した釣銭準備金の一部の金額を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金の合計額から差し引いて、前記当日の銀行入金額を計算する。従って、釣銭ではない用途で使用した釣銭準備金の一部を、その使用の妥当性が判断されて承認された当日に、その当日に得られた現金から補充することができ、翌日の釣銭準備金が不足するという事態の発生を防止することができる。また、この第1の実施形態により、POSシステムにおける現金管理が明瞭なものとなる。以上、実施形態を参照して本願発明を詳細に説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解できる様々な変更をすることができる。