商品販売データ処理装置
【課題】ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かをチェックしないと精算処理を行うことができようにする。
【解決手段】実際にドロワ内にある在高を現金，金券等の支払い種別に入力する在高入力手段と、この在高入力手段により入力された金額の総額を記憶する入力総額記憶手段とを設ける。入力総額記憶手段により記憶された入力金額総額と複数の支払い種別に対応した所定の締めキーに対応して設けられている取引別メモリに記憶された金額との差額を算出する。差額を在高入力手段により支払い種別に入力された金額とともに表示部に表示させる。在高入力手段により入力された金額の保存を指令する保存指令手段を設ける。保存指令手段により保存が指令されたことを条件に精算処理の実行を許可する。
【解決手段】実際にドロワ内にある在高を現金，金券等の支払い種別に入力する在高入力手段と、この在高入力手段により入力された金額の総額を記憶する入力総額記憶手段とを設ける。入力総額記憶手段により記憶された入力金額総額と複数の支払い種別に対応した所定の締めキーに対応して設けられている取引別メモリに記憶された金額との差額を算出する。差額を在高入力手段により支払い種別に入力された金額とともに表示部に表示させる。在高入力手段により入力された金額の保存を指令する保存指令手段を設ける。保存指令手段により保存が指令されたことを条件に精算処理の実行を許可する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、小売店の会計業務に使用される電子式キャッシュレジスタ，ＰＯＳ（Point Of Sales）端末等の商品販売データ処理装置に関する。
【背景技術】
【０００２】
一般に、この種の商品販売データ処理装置は、登録，精算等の動作モードを備えている。そして、登録モード選択時においては、１商取引として売り上げる商品の販売データに続いて締めキーが操作入力されて商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理している。また、精算モード選択時において、精算処理実行が指令されると、取引別メモリのデータを基に精算レポートを出力後、該取引別メモリをクリアしている。そこで各小売店では、毎閉店後に精算処理を実行し、精算レポートを得ることによって、この精算レポートの内容から日々の総売上，総税額，純売上，客数等を把握できるようになっている。
【０００３】
一方、複数の店舗がテナントとして入るショッピングセンターでは、センターを運営する本部いわゆるデベロッパーが各店舗のテナント料等を算出するために各店舗の経営状況を把握する必要がある。このため、多くのショッピングセンターにおいては、各店舗から毎日、総売上，総税額，純売上，客数等のデータを記入した日報レポートをデベロッパーに提出させて、各店舗の日々の売上げをデベロッパーで管理している。
【０００４】
そこで、各店舗においては、それぞれ予め定められた時刻もしくは一日の営業を終了した精算時になると、稼働していた商品販売登録データ処理装置で精算処理を実行し、この精算処理によって得た精算レポートを参考に日報レポートを作成していた。この日報レポートを作成する業務を日報業務と称している。
【０００５】
ところで、日報レポートの項目は、通常、デベロッパーによって決められる。このため、総売上の項目だけでなく、現金，クレジットカード，商品券，ギフト券等の支払い種別の売上を記述する項目が日報レポートにあった場合、店舗側は各商取引の売上を支払い種別に管理する必要がある。
【０００６】
このような支払い種別売上の管理は、支払い種別毎に締めキーを備えた商品販売データ処理装置を使用することによって容易となる。すなわち、この種の商品販売データ処理装置は、各締めキーにそれぞれ対応して取引別メモリを備えており、支払いの種類に該当した締めキーが操作入力されて商取引の登録締めが宣言されると、この商取引の決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理するものとなっている。また、精算処理の実行が指令されると、この取引別メモリの内容が精算レポートに記録されるようになっている。したがって、精算レポートの内容から総売上等とともに支払い種別の売上を把握することができる。
【０００７】
しかしながら、支払い種別毎に締めキーを備えた商品販売データ処理装置は高級機に限られ高価である。このため、デベロッパーが要求する支払い種別売上の種類数よりも締めキーが少ない低級機を使用したい店舗では容易には対応できない。因みに、支払い種別売上の種類数よりも締めキーが少ない低級機を使用する場合、通常は、商品券，ギフト券等の金券による支払いも一括して現金支払いとみなして処理している。したがって、精算レポートからは現金の売上や金券種毎の売上を把握できない。そこで、このような店では閉店後、ドロワ内に残っている現金と金券の金額をそれぞれ種別に合計することによって現金及び金券種毎の売上を把握し、日報レポートに記入することとなる。
【０００８】
ここで、問題となるのは現金や金券の紛失である。通常、キャッシャは、客から預かった現金や金券をドロワ内に直ぐに収容する。ところが、例えば釣銭額を間違えてしまったり、客から預かった現金や金券を収容せずに放置したために紛失してしまったりすることが多々ある。このような場合、ドロワ内に残っている現金や金券の在高は理論上の在高と一致しなくなり、日報レポートが不正確なものとなる。そこで、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを、日報レポートの作成前に把握したいという要望があった。
【０００９】
そこで従来、入力された入出金額情報に基づいてドロワ内の理論上の在高（理論在高）を算出する手段と、実際にドロワ内にある現金等の在高（実在高）を金種別に入力する手段と、金種別に入力された実在高の合計を算出する手段と、理論在高に対する実在高合計の過不足を算出する手段と、算出された過不足の額を表示する手段とを備えた商品販売データ処理装置があった。このような装置を用いることにより、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握することができる。（例えば、特許文献１参照）。
【特許文献１】特開平６−２１５２５８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来のこの種の商品販売データ処理装置において、理論在高は取引別メモリの内容から算出されるため、精算処理が実行されて取引別メモリがクリアされた後では、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる。これに対して、日報レポートの作成には精算レポートが必要なため、日報業務は精算処理が行われた後に行うのが一般的である。このため、精算処理を行ってしまったために、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる事態が生じることがあった。
【００１１】
本発明はこのような事情に基づいてなされたもので、その目的とするところは、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かをチェックしないと精算処理を行うことができず、精算処理を行ってしまったために、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる不都合を未然に防止できる商品販売データ処理装置を提供しようとするものである。
【課題を解決するための手段】
【００１２】
本発明は、登録，精算等の動作モードを備え、登録モード選択時において、商品販売データの入力に続いて締めキーの操作入力により商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理し、精算モード選択時において、精算処理実行が指令されると、取引別メモリのデータを基に精算レポートを出力後、該取引別メモリをクリアする商品販売データ処理装置において、実際にドロワ内にある在高を現金，金券等の支払い種別に入力する在高入力手段と、この在高入力手段により入力された金額の総額を記憶する入力総額記憶手段と、この入力総額記憶手段により記憶された入力金額総額と複数の支払い種別に対応した所定の締めキーに対応して設けられている取引別メモリに記憶された金額との差額を算出する差額算出手段と、この差額算出手段により算出される差額を在高入力手段により支払い種別に入力された金額とともに表示部に表示させる表示制御手段と、在高入力手段により入力された金額の保存を指令する保存指令手段と、この保存指令手段により保存が指令されたことを条件に精算処理の実行を許可する精算処理規制手段とを備えたものである。
【発明の効果】
【００１３】
かかる手段を講じた本発明によれば、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かをチェックしないと精算処理を行うことができず、精算処理を行ってしまったために、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる不都合を未然に防止できる商品販売データ処理装置を提供できる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明を実施するための最良の形態について、図面を用いて説明する。
なお、この実施の形態は、商品販売データ処理装置の一態様であるテナント向けＰＯＳ端末に本発明を適用した場合である。
【００１５】
図１は本実施の形態におけるＰＯＳ端末の要部構成を示すブロック図である。ＰＯＳ端末には、制御部本体としてＣＰＵ１が搭載されている。また、ＲＯＭ（Read Only Memory）２およびＲＡＭ（Random Access Memory）３の記憶部のほか、時計部４，通信インターフェイス５，スキャナインターフェイス６，カードリーダインターフェイス７，Ｉ／Ｏポート８，キーボードコントローラ９，第１の表示コントローラ１０，第２の表示コントローラ１１及びプリンタコントローラ１２等の各部が設けられている。ＣＰＵ１と各部２〜１２とは、アドレスバス，データバス等のバスライン１３で接続されている。
【００１６】
通信インターフェイス５には、公衆回線または専用回線を介して外部コンピュータが接続されている。外部コンピュータとしては、デベロッパーに設置されているコンピュータや、クレジット処理を行うコンピュータ等が含まれる。
【００１７】
スキャナインターフェイス６には、バーコード等のコードを光学的に読取ることが可能なスキャナが接続されている。カードリーダインターフェイス７には、クレジットカードのカードデータを読取ることが可能なカードリーダが接続されている。
【００１８】
Ｉ／Ｏポート８には、モードスイッチ１４からの信号が入力される。また、現金や商品券，ギフト券等の金券を収容するためのドロワ１５に対してＩ／Ｏポート８から開放指令信号が出力される。ドロワ１５は、開放指令信号の入力に応じて自動的に開放動作する。キーボードコントローラ９には、キーボード１６が接続されており、このキーボード１６から操作キーに対応したキー信号が入力される。第１の表示コントローラ１０には、オペレータ用表示器１７が接続されており、このオペレータ用表示器１７に対する表示データが出力される。第２の表示コントローラ１１には、客用表示器１８が接続されており、この客用表示器１８に対する表示データが出力される。プリンタコントローラ１２には、レシート印字等を行うためのプリンタ１９が接続されており、このプリンタ１９に対する印字制御データが出力される。
【００１９】
図２は前記モードスイッチ１４を示す模式図である。図示するようにモードスイッチ１４は、休止モードと、登録，点検，精算，設定等の各種動作モードとを択一的に選択するためのスイッチで、鍵にて切換操作される。因みに登録モードとは、１商取引として売り上げる商品の販売データに続いて締めキーが操作入力されて商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理するモードである。点検モードとは、登録モードの処理により各締めキーにそれぞれ対応して設けられた取引別メモリに記憶されたデータを基に点検レポートデータを編集し、このデータを印刷または表示出力するモードである。精算モードとは、点検モードと同様に取引別メモリに記憶されたデータ等を基に精算レポートデータを編集し、このデータを印刷出力した後、取引別メモリをクリアするモードである。設定モードとは、登録，点検，精算などの各種動作モードを実行する上で必要なデータを予め記憶部に設定するモードである。
【００２０】
図３は前記キーボード１６に配置される主要なキーレイアウトを示す模式図である。図示するようにキーボード１６には、数値データを置数するための置数キー２１や、数値データのクリアやエラー状態の解除を指令するクリアキー２２の他、小計出力を指示する小計キー２３、現計キー２４、信計キー２５、矢印キー２６等の各種キーが配設されている。ここで信計キー２５は、クレジットカードで決済される商取引の登録締めを宣言する締めキーとして機能する。また、現計キー２４は、クレジットカード以外の支払いメディア（手段）で決済される商取引の登録締めを宣言する締めキーとして機能する。
【００２１】
因みに、本実施の形態のＰＯＳ端末は、現計キー２４及び信計キー２５以外の締めキーを備えていない。このため、例えば商品券やギフト券等の現金以外の金券で代金が支払われた場合には、その運用として現計キー２４を操作して商取引の登録締めを宣言するものとする。すなわち、現計キー２４は、複数の支払い種別に対応した所定の締めキーとして機能する。
【００２２】
図４は前記ＲＡＭ３に形成される主要なメモリエリアを示す模式図である。図示するようにＲＡＭ３には、現計，信計，総売上，税額，純売上，値引等の各種取引項目別に客数と金額を累計可能な取引別メモリテーブル３１、現金，商品券，ギフト券，掛売上，他券類等のクレジットカード以外の支払い項目別に入力された金額を保存する日報入力メモリテーブル３２、上記日報入力メモリテーブル３２に保存された金額の合計を記憶する入力総額記憶手段としての日報入力金額メモリ３３、上記日報入力金額メモリ３３に記憶された金額と複数の支払い種別に対応した所定の締めキーである現計キー２４に対応して設けられている取引別メモリに記憶された金額との差額を記憶する差額メモリ３４及び日報処理実行済か否かを識別する日報フラグ（０：未実行、１：実行済）のフラグメモリ３５等が形成されている。
【００２３】
ここで、取引別メモリテーブル３１において、項目「現計」のメモリエリアは、現計キー２４に対応した取引別メモリとして機能する。同様に、項目「信計」のメモリエリアは、信計キー２５に対応した取引別メモリとして機能する。
【００２４】
かかる構成のＰＯＳ端末は、通常、ショッピングセンターのテナント店舗に設置されており、会計業務を行う店員いわゆるキャッシャによって操作される。すなわちキャッシャは、当該ＰＯＳ端末の動作モードとしてモードスイッチ１４により登録モードを選択する。この状態で、客から商品買上の申し出を受けると、キーボード１６またはスキャナを操作してその買上商品の販売データを入力する。そして、全ての買上商品の販売データを入力し終えると、小計キー２３を操作する。そうすると、その買上商品の小計金額が算出され、オペレータ用表示器１７及び客用表示器１８に表示されるので、キャッシャは客から小計金額に見合った代金の支払いを受ける。
【００２５】
ここで、客がクレジットカードにより代金を支払った場合、キャッシャは信計キー２５を操作して商取引の登録締めを宣言する。そうすると、ＰＯＳ端末では、小計金額が商取引の決済金額として確定される。そして、この決済金額をカードリーダに装着されたクレジットカードで支払うことに対する認証問合せが、クレジット処理を行うコンピュータに対して行われる。ここで、上記コンピュータからクレジット決済の承認応答があると、ＰＯＳ端末では、プリンタ１９が動作してクレジット伝票が印字発行される。そこでキャッシャは、クレジット伝票を客に渡して、当該客との商取引を終了する。このとき、客数「１」のデータと上記決済金額のデータが取引別メモリテーブル３１の項目「信計」のメモリエリアと項目「総売上」のメモリエリアとにそれぞれ加算処理される。また、決済金額に税額が含まれる場合は、その税額が取引別メモリテーブル３１の項目「税額」のメモリエリアに加算処理される。
【００２６】
一方、客がクレジットカード以外の支払い手段である現金，商品券，ギフト券等で代金を支払った場合には、キャッシャは預かり金額を置数後、現計キー２４を操作して商取引の登録締めを宣言する。そうすると、ＰＯＳ端末では、小計金額が商取引の決済金額として確定され、預かり金額から決済金額が減算されて釣銭額が算出される。そして、この釣銭額がオペレータ用表示器１７及び客用表示器１８に表示され、ドロワ１５が開放動作する。また、プリンタ１９が動作して買上レシートが印字発行される。そこでキャッシャは、釣銭があるときにはドロワ１５から釣銭を揃え、買上レシートとともに客に渡して、当該客との商取引を終了する。また、客から預かった現金あるいは商品券，ギフト券等の金券をドロワ１５内に収容し、ドロワ１５を閉じる。このとき、客数「１」のデータと上記決済金額のデータが取引別メモリテーブル３１の項目「現計」のメモリエリアと項目「総売上」のメモリエリアとにそれぞれ加算処理される。また、決済金額に税額が含まれる場合は、その税額が取引別メモリテーブル３１の項目「税額」のメモリエリアに加算処理される。
【００２７】
したがって、当該ＰＯＳ端末においては、取引別メモリテーブル３１の項目「現計」のメモリエリアにて、クレジットカード以外の支払い手段、例えば現金，商品券，ギフト券等で代金が支払われた商取引の決済金額が累計される。同様に、項目「信計」のメモリエリアにて、クレジットカードで代金が支払われた商取引の決済金額が累計される。また、項目「総売上」のメモリエリアでは、全ての商取引の決済金額が累計され、項目「税額」のメモリエリアでは、全ての商取引に含まれる税額が累計される。さらに、項目「純売上」のメモリエリアでは、全ての商取引の決済金額からその商取引に含まれる税額が除かれた純売上金額が累計される。
【００２８】
さて、当該店舗の１日の営業が終了すると、店長などの店舗責任者はモードスイッチ１４を切換操作して精算モードを選択する。そうすると、ＣＰＵ１が図６の流れ図に示す手順の精算業務プログラムを開始する。
【００２９】
先ず、ＣＰＵ１は、ＳＴ（ステップ）１としてオペレータ用表示器１７に精算メニュー画面４０を表示する。この精算メニュー画面４０の一例を図５に示す。図示するように、精算メニュー画面４０には、少なくとも日報処理の選択ボタン４１と、精算処理の選択ボタン４２とが表示されている。そこで、オペレータである店舗責任者は、はじめに矢印キー２６を操作して日報処理の選択ボタン４１を選択し、実行キー（本実施の形態では小計キー２３を代用する）を操作入力する。
【００３０】
この操作により、ＣＰＵ１は、ＳＴ２としてキーボード１６のキー操作入力により日報処理の選択ボタン４１が選択されたと判断する。そして、ＳＴ３としてフラグメモリ３５の日報フラグを調べる。当初、日報フラグは“０”にリセットされているので、ＣＰＵ１は、ＳＴ４として日報入力金額メモリ３３をクリアする。しかる後、ＳＴ５として図７に具体的に示す日報処理を開始する。
【００３１】
すなわちＣＰＵ１は、ＳＴ２１としてオペレータ用表示器１７に日報データ入力画面５０を表示する。この日報データ入力画面５０の一例を図８に示す。図示するように、日報データ入力画面５０には、番号エリア，名称エリア，日報入力エリア及び売上エリアに区分されたデータ領域５１と、編集，印字，保存，終了等のボタン領域５２とが形成されている。そして、番号エリアには、１行毎に一連の番号が表示されている。名称エリアには、日報入力メモリテーブル３２に記憶されている各支払い項目（現金，商品券，ギフト券，掛売上，他券類，その他）と、名称「クレジット」と、名称「差額」が各行にそれぞれ表示されている。日報入力欄には、名称「差額」に対応する欄を除いて初期値“０”が表示されている。売上エリアには、日報入力メモリテーブル３２の各支払い項目が名称エリアに表示されている各行に対して共通に、取引別メモリテーブル３１の現計キー２４に対応したメモリエリアである項目「現計」のエリアに記憶された客数と金額が表示されている。また、名称「クレジット」が表示されている行には、取引別メモリテーブル３１の信計キー２５に対応したメモリエリアである項目「信計」のエリアに記憶された客数と金額が表示されている。
【００３２】
次にＣＰＵ１は、ＳＴ２２として日報入力金額メモリ３３のデータである金額から取引別メモリテーブル３１の項目「現計」のメモリエリアに記憶されている金額を減算し、その値である差額を差額メモリ３４にセットする。また、ＳＴ２３としてこの差額メモリ３４にセットした金額を、日報データ入力画面５０におけるデータ領域５１の名称「差額」に対応した日報入力欄に表示する。
【００３３】
さて、日報処理の選択ボタン４１を選択操作したオペレータは、名称「差額」の日報入力欄が“０円”でないことを確認すると、ドロワ１５に収容されている現金の総額や、商品券，ギフト券等の額面金額の合計を券種別に算出する。そして、現金の総額を算出したならば、矢印キー２６を操作して日報データ入力画面５０におけるデータ領域５１の名称「差額」に対応した日報入力欄を選択し、実行キーを操作入力する。次いで、置数キー２１により現金の総額を置数した後、実行キーを操作入力する。また、商品券の額面金額合計を算出したならば、矢印キー２６を操作して日報データ入力画面５０におけるデータ領域５１の名称「商品券」に対応した日報入力欄を選択し、実行キーを操作入力する。次いで、置数キー２１により商品券の額面金額合計を置数した後、実行キーを操作入力する。この他、ギフト券，他券類等の額面金額合計を算出した場合も、商品券の場合と同様に操作する。
【００３４】
ＣＰＵ１は、ＳＴ２４としてキーボード１６のキー操作入力により日報データ入力画面５０におけるデータ領域５１の日報入力欄が選択され、さらに、ＳＴ２５として置数データが入力されたことを検知すると（在高入力手段）、ＳＴ２６として日報データ入力画面５０におけるデータ領域５１の選択された日報入力欄に、置数金額を表示させる。また、ＳＴ２７として選択された日報入力欄と同一行の名称欄に表示されている項目を認識し、日報入力メモリテーブル３２の同一項目に対応した金額エリアに上記置数金額をセットする。さらに、ＳＴ２８として日報入力メモリテーブル３２の各項目に対応した金額の総額を算出し、日報入力金額メモリ３３にセットする。その後、ＳＴ２２の処理に戻り、日報入力金額メモリ３３に記憶された金額から取引別メモリテーブル３１の項目「現計」のメモリエリアに記憶されている金額を減算し、その値である差額を差額メモリ３４にセットする（差額算出手段）。また、この差額メモリ３４にセットした金額を、日報データ入力画面５０におけるデータ領域５１の名称「差額」に対応した日報入力欄に表示する（表示制御手段）。
【００３５】
ＣＰＵ１は、日報データ入力画面５０におけるデータ領域５１の日報入力欄が選択され、さらに置数データが入力されたことを検知する毎に、上記ＳＴ２６，２７，２８，２２，２３の各処理を順次実行する。
【００３６】
今、図８に示すデータ内容の日報データ入力画面５０が表示された場合において、ドロワ１５内に現金が９８，３５６円、商品券が２０，０００円、ギフト券が５，０００円収容されていたとする。この場合、オペレータは、図９に示すように、名称「現金」に対応した日報入力欄に置数データ「９８３５６」を入力し、名称「商品券」に対応した日報入力欄に置数データ「２００００」を入力し、名称「ギフト券」に対応した日報入力欄に置数データ「５０００」を入力する。そうすると、取引別メモリテーブル３１の項目「現計」のメモリエリアには、日報データ入力画面５０の売上エリアに表示されている金額データ「１２３４５６」がセットされているのに対し、日報入力金額メモリ３３の金額データは、置数データ「９８３５６」と「２００００」と「５０００」の総和である「１２３３５６」となるので、差額メモリ３４にセットされる差額データは「−１００」となる。その結果、名称「差額」に対応した日報入力欄には差額「−１００円」が表示される。この差額「−１００円」は、ドロワ１５内に残っている実際の在高が理論上の在高に対して１００円不足していることを示している。なお、この際、差額「−１００円」は赤等の目立つ色で表示させるとよい。
【００３７】
ドロワ１５に収容されている現金の総額や、商品券，ギフト券等の額面金額の合計を券種別に入力し終えたオペレータは、次に、矢印キー２６を操作して日報データ入力画面５０におけるボタン領域５２の保存ボタンを選択し、実行キーを操作入力する。
【００３８】
ＣＰＵ１は、ＳＴ２９としてボタン領域５２のいずれかのボタンが操作入力されたことを検知し、ＳＴ３０としてそのボタンが保存ボタンであることを確認すると（保存指令手段）、在高入力手段により入力された金額の保存が指令されたので、ＳＴ３１として差額メモリ３４の差額データが“０”であるか否かを判断する。
【００３９】
ここで、差額メモリ３４の差額データが“０”である場合には、ＳＴ３４の処理に進む。これに対し、差額データが“０”でない場合には、ＳＴ３２としてオペレータ用表示器１７に保存確認画面６０を表示する（保存可否問合せ手段）。この保存確認画面６０の一例を図１０に示す。図示するように、保存確認画面６０には、日報データ入力画面５０から入力した実際の在高と理論上の在高とに差額があるがそのまま保存してよいか否かをオペレータに問合せるメッセージと、保存してよいことを指示する「はい」ボタン６１と、保存しないことを指示する「いいえ」ボタン６２とが表示されている。そこでオペレータは、メッセージを確認し、保存する場合には矢印キー２６で「はい」ボタン６１を選択し、保存しない場合には矢印キー２６で「いいえ」ボタン６２を選択して、実行キーを操作入力する。
【００４０】
ＣＰＵ１は、ＳＴ３３として「はい」ボタン６１が選択されたことを検知した場合には、ＳＴ３４の処理に進む。これに対し、「いいえ」ボタン６２が選択されたことを検知した場合には、ＳＴ３４の処理を行うことなく、この日報処理を終了する。
【００４１】
ＳＴ３４では、ＣＰＵ１は、フラグメモリ３５の日報フラグを“１”にセットする（精算処理規制手段）。その後、この日報処理を終了する。
【００４２】
上記日報処理を終了すると、ＣＰＵ１は、ＳＴ１に戻り、オペレータ用表示器１７の画面を精算メニュー画面４０に戻す。そこで、オペレータである店舗責任者は、次に矢印キー２６を操作して精算処理の選択ボタン４２を選択し、実行キーを操作入力する。
【００４３】
この操作により、ＣＰＵ１は、ＳＴ６としてキーボード１６のキー操作入力により精算処理の選択ボタン４２が選択されたと判断する。そして、ＳＴ７としてフラグメモリ３５の日報フラグを調べる。ここで、日報フラグが”０”にリセットされていた場合、すなわち前記日報処理のＳＴ３３にて支払い種別に入力された金額の保存が指令されなかった場合には、精算処理の実行を許可しないので、ＣＰＵ１は、ＳＴ８として操作エラーメッセージをオペレータ用表示器１７に表示させる。このエラーメッセージを確認したオペレータは、クリアキー２２を操作入力する。ＣＰＵ１は、ＳＴ９としてクリアキー２２が操作入力されたことを検知すると、オペレータ用表示器１７の画面を精算メニュー画面４０に戻す。この場合、オペレータは、日報処理をやり直すことになる。
【００４４】
一方、ＳＴ７にて日報フラグが“１”にセットされていた場合には、ＣＰＵ１は、ＳＴ１０として精算処理を実行する。すなわち、取引別メモリテーブル３１に記憶されているデータを基に精算レポートデータを編集する。そして、この精算レポートデータをプリンタ１９に出力し、レシート用紙に印刷させて、精算レポートとして発行する。しかる後、取引別メモリテーブル３１をクリアする。以上の精算処理を終了したならば、ＣＰＵ１は、ＳＴ１１として日報フラグを“０”にリセットして、この精算業務プログラムを終了する。
【００４５】
このように本実施の形態のＰＯＳ端末においては、１日の営業終了後に実行される精算業務において、ドロワ１５内に実際に収容されている現金や商品券，ギフト券等の在高を支払い種別に入力することで、ドロワ１５内に残っている実際の在高が、取引別メモリテーブル３１に記憶されている理論上の在高と一致しているか否かをチェックする日報処理を行うことができる。しかも、この日報処理を実行し、支払い種別に入力した金額の保存を指令しないと、精算処理を実行することはできない。
【００４６】
したがって、日報処理を実行する前に精算処理を実行してしまったために、ドロワ１５内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる不都合が生じることを未然に防止できる。
【００４７】
かくして、デベロッパーが要求する支払い種別売上の種類数よりも締めキーが少ない低級機を使用したい店舗においても、精算処理によって印刷発行された精算レポートの内容と、その前に実施された日報処理で算出されかつ理論在高とのチェックが済んだ支払い種別の実際の在高とから正確な日報レポートを作成し、デベロッパーに提出できるようになる。
【００４８】
なお、この発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
【００４９】
例えば前記実施の形態では、日報処理において実在高と理論在高との差額を支払い種別に入力された金額とともにオペレータ用表示器１７に表示させたが、この差額を支払い種別に入力された金額とともに、プリンタによりレシート用紙に印字出力して、オペレータに確認させてもよい。
【００５０】
また、前記実施の形態では、精算メニュー画面において当初から日報処理と精算処理を選択可能としたが、日報処理が実行され、支払い種別に入力された金額の保存が指令されるまでは精算処理を選択不可能として、精算処理の実行を規制するようにしてもよい。
【００５１】
この他、前記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を組合わせてもよい。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施の形態であるＰＯＳ端末の要部構成を示すブロック図。
【図２】同ＰＯＳ端末が有するモードスイッチを示す模式図。
【図３】同ＰＯＳ端末が有するキーボードの主要なキー配置を示す模式図。
【図４】同ＰＯＳ端末のＲＡＭに形成される主要なメモリエリアを示す模式図。
【図５】同ＰＯＳ端末の表示部に表示される精算メニュー画面の一例を示す模式図。
【図６】同ＰＯＳ端末のＣＰＵが実行する精算業務の要部処理手順を示す流れ図。
【図７】図６における日報処理を具体的に示す流れ図。
【図８】同ＰＯＳ端末の表示部に表示される日報データ入力画面の初期画面例を示す模式図。
【図９】同ＰＯＳ端末の表示部に表示される日報データ入力画面のデータ入力例を示す模式図。
【図１０】同ＰＯＳ端末の表示部に表示される保存確認画面の一例を示す模式図。
【符号の説明】
【００５３】
１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ，１４…モードスイッチ、１５…ドロワ、１６…キーボード、１７…オペレータ用表示器、１９…プリンタ、２４…現計キー、２５…信計キー、３１…取引別メモリテーブル、３２…日報入力メモリテーブル、３３…日報入力金額メモリ、３４…差額メモリ、３５…日報フラグメモリ。
【技術分野】
【０００１】
本発明は、小売店の会計業務に使用される電子式キャッシュレジスタ，ＰＯＳ（Point Of Sales）端末等の商品販売データ処理装置に関する。
【背景技術】
【０００２】
一般に、この種の商品販売データ処理装置は、登録，精算等の動作モードを備えている。そして、登録モード選択時においては、１商取引として売り上げる商品の販売データに続いて締めキーが操作入力されて商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理している。また、精算モード選択時において、精算処理実行が指令されると、取引別メモリのデータを基に精算レポートを出力後、該取引別メモリをクリアしている。そこで各小売店では、毎閉店後に精算処理を実行し、精算レポートを得ることによって、この精算レポートの内容から日々の総売上，総税額，純売上，客数等を把握できるようになっている。
【０００３】
一方、複数の店舗がテナントとして入るショッピングセンターでは、センターを運営する本部いわゆるデベロッパーが各店舗のテナント料等を算出するために各店舗の経営状況を把握する必要がある。このため、多くのショッピングセンターにおいては、各店舗から毎日、総売上，総税額，純売上，客数等のデータを記入した日報レポートをデベロッパーに提出させて、各店舗の日々の売上げをデベロッパーで管理している。
【０００４】
そこで、各店舗においては、それぞれ予め定められた時刻もしくは一日の営業を終了した精算時になると、稼働していた商品販売登録データ処理装置で精算処理を実行し、この精算処理によって得た精算レポートを参考に日報レポートを作成していた。この日報レポートを作成する業務を日報業務と称している。
【０００５】
ところで、日報レポートの項目は、通常、デベロッパーによって決められる。このため、総売上の項目だけでなく、現金，クレジットカード，商品券，ギフト券等の支払い種別の売上を記述する項目が日報レポートにあった場合、店舗側は各商取引の売上を支払い種別に管理する必要がある。
【０００６】
このような支払い種別売上の管理は、支払い種別毎に締めキーを備えた商品販売データ処理装置を使用することによって容易となる。すなわち、この種の商品販売データ処理装置は、各締めキーにそれぞれ対応して取引別メモリを備えており、支払いの種類に該当した締めキーが操作入力されて商取引の登録締めが宣言されると、この商取引の決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理するものとなっている。また、精算処理の実行が指令されると、この取引別メモリの内容が精算レポートに記録されるようになっている。したがって、精算レポートの内容から総売上等とともに支払い種別の売上を把握することができる。
【０００７】
しかしながら、支払い種別毎に締めキーを備えた商品販売データ処理装置は高級機に限られ高価である。このため、デベロッパーが要求する支払い種別売上の種類数よりも締めキーが少ない低級機を使用したい店舗では容易には対応できない。因みに、支払い種別売上の種類数よりも締めキーが少ない低級機を使用する場合、通常は、商品券，ギフト券等の金券による支払いも一括して現金支払いとみなして処理している。したがって、精算レポートからは現金の売上や金券種毎の売上を把握できない。そこで、このような店では閉店後、ドロワ内に残っている現金と金券の金額をそれぞれ種別に合計することによって現金及び金券種毎の売上を把握し、日報レポートに記入することとなる。
【０００８】
ここで、問題となるのは現金や金券の紛失である。通常、キャッシャは、客から預かった現金や金券をドロワ内に直ぐに収容する。ところが、例えば釣銭額を間違えてしまったり、客から預かった現金や金券を収容せずに放置したために紛失してしまったりすることが多々ある。このような場合、ドロワ内に残っている現金や金券の在高は理論上の在高と一致しなくなり、日報レポートが不正確なものとなる。そこで、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを、日報レポートの作成前に把握したいという要望があった。
【０００９】
そこで従来、入力された入出金額情報に基づいてドロワ内の理論上の在高（理論在高）を算出する手段と、実際にドロワ内にある現金等の在高（実在高）を金種別に入力する手段と、金種別に入力された実在高の合計を算出する手段と、理論在高に対する実在高合計の過不足を算出する手段と、算出された過不足の額を表示する手段とを備えた商品販売データ処理装置があった。このような装置を用いることにより、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握することができる。（例えば、特許文献１参照）。
【特許文献１】特開平６−２１５２５８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来のこの種の商品販売データ処理装置において、理論在高は取引別メモリの内容から算出されるため、精算処理が実行されて取引別メモリがクリアされた後では、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる。これに対して、日報レポートの作成には精算レポートが必要なため、日報業務は精算処理が行われた後に行うのが一般的である。このため、精算処理を行ってしまったために、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる事態が生じることがあった。
【００１１】
本発明はこのような事情に基づいてなされたもので、その目的とするところは、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かをチェックしないと精算処理を行うことができず、精算処理を行ってしまったために、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる不都合を未然に防止できる商品販売データ処理装置を提供しようとするものである。
【課題を解決するための手段】
【００１２】
本発明は、登録，精算等の動作モードを備え、登録モード選択時において、商品販売データの入力に続いて締めキーの操作入力により商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理し、精算モード選択時において、精算処理実行が指令されると、取引別メモリのデータを基に精算レポートを出力後、該取引別メモリをクリアする商品販売データ処理装置において、実際にドロワ内にある在高を現金，金券等の支払い種別に入力する在高入力手段と、この在高入力手段により入力された金額の総額を記憶する入力総額記憶手段と、この入力総額記憶手段により記憶された入力金額総額と複数の支払い種別に対応した所定の締めキーに対応して設けられている取引別メモリに記憶された金額との差額を算出する差額算出手段と、この差額算出手段により算出される差額を在高入力手段により支払い種別に入力された金額とともに表示部に表示させる表示制御手段と、在高入力手段により入力された金額の保存を指令する保存指令手段と、この保存指令手段により保存が指令されたことを条件に精算処理の実行を許可する精算処理規制手段とを備えたものである。
【発明の効果】
【００１３】
かかる手段を講じた本発明によれば、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かをチェックしないと精算処理を行うことができず、精算処理を行ってしまったために、ドロワ内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる不都合を未然に防止できる商品販売データ処理装置を提供できる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明を実施するための最良の形態について、図面を用いて説明する。
なお、この実施の形態は、商品販売データ処理装置の一態様であるテナント向けＰＯＳ端末に本発明を適用した場合である。
【００１５】
図１は本実施の形態におけるＰＯＳ端末の要部構成を示すブロック図である。ＰＯＳ端末には、制御部本体としてＣＰＵ１が搭載されている。また、ＲＯＭ（Read Only Memory）２およびＲＡＭ（Random Access Memory）３の記憶部のほか、時計部４，通信インターフェイス５，スキャナインターフェイス６，カードリーダインターフェイス７，Ｉ／Ｏポート８，キーボードコントローラ９，第１の表示コントローラ１０，第２の表示コントローラ１１及びプリンタコントローラ１２等の各部が設けられている。ＣＰＵ１と各部２〜１２とは、アドレスバス，データバス等のバスライン１３で接続されている。
【００１６】
通信インターフェイス５には、公衆回線または専用回線を介して外部コンピュータが接続されている。外部コンピュータとしては、デベロッパーに設置されているコンピュータや、クレジット処理を行うコンピュータ等が含まれる。
【００１７】
スキャナインターフェイス６には、バーコード等のコードを光学的に読取ることが可能なスキャナが接続されている。カードリーダインターフェイス７には、クレジットカードのカードデータを読取ることが可能なカードリーダが接続されている。
【００１８】
Ｉ／Ｏポート８には、モードスイッチ１４からの信号が入力される。また、現金や商品券，ギフト券等の金券を収容するためのドロワ１５に対してＩ／Ｏポート８から開放指令信号が出力される。ドロワ１５は、開放指令信号の入力に応じて自動的に開放動作する。キーボードコントローラ９には、キーボード１６が接続されており、このキーボード１６から操作キーに対応したキー信号が入力される。第１の表示コントローラ１０には、オペレータ用表示器１７が接続されており、このオペレータ用表示器１７に対する表示データが出力される。第２の表示コントローラ１１には、客用表示器１８が接続されており、この客用表示器１８に対する表示データが出力される。プリンタコントローラ１２には、レシート印字等を行うためのプリンタ１９が接続されており、このプリンタ１９に対する印字制御データが出力される。
【００１９】
図２は前記モードスイッチ１４を示す模式図である。図示するようにモードスイッチ１４は、休止モードと、登録，点検，精算，設定等の各種動作モードとを択一的に選択するためのスイッチで、鍵にて切換操作される。因みに登録モードとは、１商取引として売り上げる商品の販売データに続いて締めキーが操作入力されて商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理するモードである。点検モードとは、登録モードの処理により各締めキーにそれぞれ対応して設けられた取引別メモリに記憶されたデータを基に点検レポートデータを編集し、このデータを印刷または表示出力するモードである。精算モードとは、点検モードと同様に取引別メモリに記憶されたデータ等を基に精算レポートデータを編集し、このデータを印刷出力した後、取引別メモリをクリアするモードである。設定モードとは、登録，点検，精算などの各種動作モードを実行する上で必要なデータを予め記憶部に設定するモードである。
【００２０】
図３は前記キーボード１６に配置される主要なキーレイアウトを示す模式図である。図示するようにキーボード１６には、数値データを置数するための置数キー２１や、数値データのクリアやエラー状態の解除を指令するクリアキー２２の他、小計出力を指示する小計キー２３、現計キー２４、信計キー２５、矢印キー２６等の各種キーが配設されている。ここで信計キー２５は、クレジットカードで決済される商取引の登録締めを宣言する締めキーとして機能する。また、現計キー２４は、クレジットカード以外の支払いメディア（手段）で決済される商取引の登録締めを宣言する締めキーとして機能する。
【００２１】
因みに、本実施の形態のＰＯＳ端末は、現計キー２４及び信計キー２５以外の締めキーを備えていない。このため、例えば商品券やギフト券等の現金以外の金券で代金が支払われた場合には、その運用として現計キー２４を操作して商取引の登録締めを宣言するものとする。すなわち、現計キー２４は、複数の支払い種別に対応した所定の締めキーとして機能する。
【００２２】
図４は前記ＲＡＭ３に形成される主要なメモリエリアを示す模式図である。図示するようにＲＡＭ３には、現計，信計，総売上，税額，純売上，値引等の各種取引項目別に客数と金額を累計可能な取引別メモリテーブル３１、現金，商品券，ギフト券，掛売上，他券類等のクレジットカード以外の支払い項目別に入力された金額を保存する日報入力メモリテーブル３２、上記日報入力メモリテーブル３２に保存された金額の合計を記憶する入力総額記憶手段としての日報入力金額メモリ３３、上記日報入力金額メモリ３３に記憶された金額と複数の支払い種別に対応した所定の締めキーである現計キー２４に対応して設けられている取引別メモリに記憶された金額との差額を記憶する差額メモリ３４及び日報処理実行済か否かを識別する日報フラグ（０：未実行、１：実行済）のフラグメモリ３５等が形成されている。
【００２３】
ここで、取引別メモリテーブル３１において、項目「現計」のメモリエリアは、現計キー２４に対応した取引別メモリとして機能する。同様に、項目「信計」のメモリエリアは、信計キー２５に対応した取引別メモリとして機能する。
【００２４】
かかる構成のＰＯＳ端末は、通常、ショッピングセンターのテナント店舗に設置されており、会計業務を行う店員いわゆるキャッシャによって操作される。すなわちキャッシャは、当該ＰＯＳ端末の動作モードとしてモードスイッチ１４により登録モードを選択する。この状態で、客から商品買上の申し出を受けると、キーボード１６またはスキャナを操作してその買上商品の販売データを入力する。そして、全ての買上商品の販売データを入力し終えると、小計キー２３を操作する。そうすると、その買上商品の小計金額が算出され、オペレータ用表示器１７及び客用表示器１８に表示されるので、キャッシャは客から小計金額に見合った代金の支払いを受ける。
【００２５】
ここで、客がクレジットカードにより代金を支払った場合、キャッシャは信計キー２５を操作して商取引の登録締めを宣言する。そうすると、ＰＯＳ端末では、小計金額が商取引の決済金額として確定される。そして、この決済金額をカードリーダに装着されたクレジットカードで支払うことに対する認証問合せが、クレジット処理を行うコンピュータに対して行われる。ここで、上記コンピュータからクレジット決済の承認応答があると、ＰＯＳ端末では、プリンタ１９が動作してクレジット伝票が印字発行される。そこでキャッシャは、クレジット伝票を客に渡して、当該客との商取引を終了する。このとき、客数「１」のデータと上記決済金額のデータが取引別メモリテーブル３１の項目「信計」のメモリエリアと項目「総売上」のメモリエリアとにそれぞれ加算処理される。また、決済金額に税額が含まれる場合は、その税額が取引別メモリテーブル３１の項目「税額」のメモリエリアに加算処理される。
【００２６】
一方、客がクレジットカード以外の支払い手段である現金，商品券，ギフト券等で代金を支払った場合には、キャッシャは預かり金額を置数後、現計キー２４を操作して商取引の登録締めを宣言する。そうすると、ＰＯＳ端末では、小計金額が商取引の決済金額として確定され、預かり金額から決済金額が減算されて釣銭額が算出される。そして、この釣銭額がオペレータ用表示器１７及び客用表示器１８に表示され、ドロワ１５が開放動作する。また、プリンタ１９が動作して買上レシートが印字発行される。そこでキャッシャは、釣銭があるときにはドロワ１５から釣銭を揃え、買上レシートとともに客に渡して、当該客との商取引を終了する。また、客から預かった現金あるいは商品券，ギフト券等の金券をドロワ１５内に収容し、ドロワ１５を閉じる。このとき、客数「１」のデータと上記決済金額のデータが取引別メモリテーブル３１の項目「現計」のメモリエリアと項目「総売上」のメモリエリアとにそれぞれ加算処理される。また、決済金額に税額が含まれる場合は、その税額が取引別メモリテーブル３１の項目「税額」のメモリエリアに加算処理される。
【００２７】
したがって、当該ＰＯＳ端末においては、取引別メモリテーブル３１の項目「現計」のメモリエリアにて、クレジットカード以外の支払い手段、例えば現金，商品券，ギフト券等で代金が支払われた商取引の決済金額が累計される。同様に、項目「信計」のメモリエリアにて、クレジットカードで代金が支払われた商取引の決済金額が累計される。また、項目「総売上」のメモリエリアでは、全ての商取引の決済金額が累計され、項目「税額」のメモリエリアでは、全ての商取引に含まれる税額が累計される。さらに、項目「純売上」のメモリエリアでは、全ての商取引の決済金額からその商取引に含まれる税額が除かれた純売上金額が累計される。
【００２８】
さて、当該店舗の１日の営業が終了すると、店長などの店舗責任者はモードスイッチ１４を切換操作して精算モードを選択する。そうすると、ＣＰＵ１が図６の流れ図に示す手順の精算業務プログラムを開始する。
【００２９】
先ず、ＣＰＵ１は、ＳＴ（ステップ）１としてオペレータ用表示器１７に精算メニュー画面４０を表示する。この精算メニュー画面４０の一例を図５に示す。図示するように、精算メニュー画面４０には、少なくとも日報処理の選択ボタン４１と、精算処理の選択ボタン４２とが表示されている。そこで、オペレータである店舗責任者は、はじめに矢印キー２６を操作して日報処理の選択ボタン４１を選択し、実行キー（本実施の形態では小計キー２３を代用する）を操作入力する。
【００３０】
この操作により、ＣＰＵ１は、ＳＴ２としてキーボード１６のキー操作入力により日報処理の選択ボタン４１が選択されたと判断する。そして、ＳＴ３としてフラグメモリ３５の日報フラグを調べる。当初、日報フラグは“０”にリセットされているので、ＣＰＵ１は、ＳＴ４として日報入力金額メモリ３３をクリアする。しかる後、ＳＴ５として図７に具体的に示す日報処理を開始する。
【００３１】
すなわちＣＰＵ１は、ＳＴ２１としてオペレータ用表示器１７に日報データ入力画面５０を表示する。この日報データ入力画面５０の一例を図８に示す。図示するように、日報データ入力画面５０には、番号エリア，名称エリア，日報入力エリア及び売上エリアに区分されたデータ領域５１と、編集，印字，保存，終了等のボタン領域５２とが形成されている。そして、番号エリアには、１行毎に一連の番号が表示されている。名称エリアには、日報入力メモリテーブル３２に記憶されている各支払い項目（現金，商品券，ギフト券，掛売上，他券類，その他）と、名称「クレジット」と、名称「差額」が各行にそれぞれ表示されている。日報入力欄には、名称「差額」に対応する欄を除いて初期値“０”が表示されている。売上エリアには、日報入力メモリテーブル３２の各支払い項目が名称エリアに表示されている各行に対して共通に、取引別メモリテーブル３１の現計キー２４に対応したメモリエリアである項目「現計」のエリアに記憶された客数と金額が表示されている。また、名称「クレジット」が表示されている行には、取引別メモリテーブル３１の信計キー２５に対応したメモリエリアである項目「信計」のエリアに記憶された客数と金額が表示されている。
【００３２】
次にＣＰＵ１は、ＳＴ２２として日報入力金額メモリ３３のデータである金額から取引別メモリテーブル３１の項目「現計」のメモリエリアに記憶されている金額を減算し、その値である差額を差額メモリ３４にセットする。また、ＳＴ２３としてこの差額メモリ３４にセットした金額を、日報データ入力画面５０におけるデータ領域５１の名称「差額」に対応した日報入力欄に表示する。
【００３３】
さて、日報処理の選択ボタン４１を選択操作したオペレータは、名称「差額」の日報入力欄が“０円”でないことを確認すると、ドロワ１５に収容されている現金の総額や、商品券，ギフト券等の額面金額の合計を券種別に算出する。そして、現金の総額を算出したならば、矢印キー２６を操作して日報データ入力画面５０におけるデータ領域５１の名称「差額」に対応した日報入力欄を選択し、実行キーを操作入力する。次いで、置数キー２１により現金の総額を置数した後、実行キーを操作入力する。また、商品券の額面金額合計を算出したならば、矢印キー２６を操作して日報データ入力画面５０におけるデータ領域５１の名称「商品券」に対応した日報入力欄を選択し、実行キーを操作入力する。次いで、置数キー２１により商品券の額面金額合計を置数した後、実行キーを操作入力する。この他、ギフト券，他券類等の額面金額合計を算出した場合も、商品券の場合と同様に操作する。
【００３４】
ＣＰＵ１は、ＳＴ２４としてキーボード１６のキー操作入力により日報データ入力画面５０におけるデータ領域５１の日報入力欄が選択され、さらに、ＳＴ２５として置数データが入力されたことを検知すると（在高入力手段）、ＳＴ２６として日報データ入力画面５０におけるデータ領域５１の選択された日報入力欄に、置数金額を表示させる。また、ＳＴ２７として選択された日報入力欄と同一行の名称欄に表示されている項目を認識し、日報入力メモリテーブル３２の同一項目に対応した金額エリアに上記置数金額をセットする。さらに、ＳＴ２８として日報入力メモリテーブル３２の各項目に対応した金額の総額を算出し、日報入力金額メモリ３３にセットする。その後、ＳＴ２２の処理に戻り、日報入力金額メモリ３３に記憶された金額から取引別メモリテーブル３１の項目「現計」のメモリエリアに記憶されている金額を減算し、その値である差額を差額メモリ３４にセットする（差額算出手段）。また、この差額メモリ３４にセットした金額を、日報データ入力画面５０におけるデータ領域５１の名称「差額」に対応した日報入力欄に表示する（表示制御手段）。
【００３５】
ＣＰＵ１は、日報データ入力画面５０におけるデータ領域５１の日報入力欄が選択され、さらに置数データが入力されたことを検知する毎に、上記ＳＴ２６，２７，２８，２２，２３の各処理を順次実行する。
【００３６】
今、図８に示すデータ内容の日報データ入力画面５０が表示された場合において、ドロワ１５内に現金が９８，３５６円、商品券が２０，０００円、ギフト券が５，０００円収容されていたとする。この場合、オペレータは、図９に示すように、名称「現金」に対応した日報入力欄に置数データ「９８３５６」を入力し、名称「商品券」に対応した日報入力欄に置数データ「２００００」を入力し、名称「ギフト券」に対応した日報入力欄に置数データ「５０００」を入力する。そうすると、取引別メモリテーブル３１の項目「現計」のメモリエリアには、日報データ入力画面５０の売上エリアに表示されている金額データ「１２３４５６」がセットされているのに対し、日報入力金額メモリ３３の金額データは、置数データ「９８３５６」と「２００００」と「５０００」の総和である「１２３３５６」となるので、差額メモリ３４にセットされる差額データは「−１００」となる。その結果、名称「差額」に対応した日報入力欄には差額「−１００円」が表示される。この差額「−１００円」は、ドロワ１５内に残っている実際の在高が理論上の在高に対して１００円不足していることを示している。なお、この際、差額「−１００円」は赤等の目立つ色で表示させるとよい。
【００３７】
ドロワ１５に収容されている現金の総額や、商品券，ギフト券等の額面金額の合計を券種別に入力し終えたオペレータは、次に、矢印キー２６を操作して日報データ入力画面５０におけるボタン領域５２の保存ボタンを選択し、実行キーを操作入力する。
【００３８】
ＣＰＵ１は、ＳＴ２９としてボタン領域５２のいずれかのボタンが操作入力されたことを検知し、ＳＴ３０としてそのボタンが保存ボタンであることを確認すると（保存指令手段）、在高入力手段により入力された金額の保存が指令されたので、ＳＴ３１として差額メモリ３４の差額データが“０”であるか否かを判断する。
【００３９】
ここで、差額メモリ３４の差額データが“０”である場合には、ＳＴ３４の処理に進む。これに対し、差額データが“０”でない場合には、ＳＴ３２としてオペレータ用表示器１７に保存確認画面６０を表示する（保存可否問合せ手段）。この保存確認画面６０の一例を図１０に示す。図示するように、保存確認画面６０には、日報データ入力画面５０から入力した実際の在高と理論上の在高とに差額があるがそのまま保存してよいか否かをオペレータに問合せるメッセージと、保存してよいことを指示する「はい」ボタン６１と、保存しないことを指示する「いいえ」ボタン６２とが表示されている。そこでオペレータは、メッセージを確認し、保存する場合には矢印キー２６で「はい」ボタン６１を選択し、保存しない場合には矢印キー２６で「いいえ」ボタン６２を選択して、実行キーを操作入力する。
【００４０】
ＣＰＵ１は、ＳＴ３３として「はい」ボタン６１が選択されたことを検知した場合には、ＳＴ３４の処理に進む。これに対し、「いいえ」ボタン６２が選択されたことを検知した場合には、ＳＴ３４の処理を行うことなく、この日報処理を終了する。
【００４１】
ＳＴ３４では、ＣＰＵ１は、フラグメモリ３５の日報フラグを“１”にセットする（精算処理規制手段）。その後、この日報処理を終了する。
【００４２】
上記日報処理を終了すると、ＣＰＵ１は、ＳＴ１に戻り、オペレータ用表示器１７の画面を精算メニュー画面４０に戻す。そこで、オペレータである店舗責任者は、次に矢印キー２６を操作して精算処理の選択ボタン４２を選択し、実行キーを操作入力する。
【００４３】
この操作により、ＣＰＵ１は、ＳＴ６としてキーボード１６のキー操作入力により精算処理の選択ボタン４２が選択されたと判断する。そして、ＳＴ７としてフラグメモリ３５の日報フラグを調べる。ここで、日報フラグが”０”にリセットされていた場合、すなわち前記日報処理のＳＴ３３にて支払い種別に入力された金額の保存が指令されなかった場合には、精算処理の実行を許可しないので、ＣＰＵ１は、ＳＴ８として操作エラーメッセージをオペレータ用表示器１７に表示させる。このエラーメッセージを確認したオペレータは、クリアキー２２を操作入力する。ＣＰＵ１は、ＳＴ９としてクリアキー２２が操作入力されたことを検知すると、オペレータ用表示器１７の画面を精算メニュー画面４０に戻す。この場合、オペレータは、日報処理をやり直すことになる。
【００４４】
一方、ＳＴ７にて日報フラグが“１”にセットされていた場合には、ＣＰＵ１は、ＳＴ１０として精算処理を実行する。すなわち、取引別メモリテーブル３１に記憶されているデータを基に精算レポートデータを編集する。そして、この精算レポートデータをプリンタ１９に出力し、レシート用紙に印刷させて、精算レポートとして発行する。しかる後、取引別メモリテーブル３１をクリアする。以上の精算処理を終了したならば、ＣＰＵ１は、ＳＴ１１として日報フラグを“０”にリセットして、この精算業務プログラムを終了する。
【００４５】
このように本実施の形態のＰＯＳ端末においては、１日の営業終了後に実行される精算業務において、ドロワ１５内に実際に収容されている現金や商品券，ギフト券等の在高を支払い種別に入力することで、ドロワ１５内に残っている実際の在高が、取引別メモリテーブル３１に記憶されている理論上の在高と一致しているか否かをチェックする日報処理を行うことができる。しかも、この日報処理を実行し、支払い種別に入力した金額の保存を指令しないと、精算処理を実行することはできない。
【００４６】
したがって、日報処理を実行する前に精算処理を実行してしまったために、ドロワ１５内に残っている実際の在高が理論上の在高と一致しているか否かを把握できなくなる不都合が生じることを未然に防止できる。
【００４７】
かくして、デベロッパーが要求する支払い種別売上の種類数よりも締めキーが少ない低級機を使用したい店舗においても、精算処理によって印刷発行された精算レポートの内容と、その前に実施された日報処理で算出されかつ理論在高とのチェックが済んだ支払い種別の実際の在高とから正確な日報レポートを作成し、デベロッパーに提出できるようになる。
【００４８】
なお、この発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
【００４９】
例えば前記実施の形態では、日報処理において実在高と理論在高との差額を支払い種別に入力された金額とともにオペレータ用表示器１７に表示させたが、この差額を支払い種別に入力された金額とともに、プリンタによりレシート用紙に印字出力して、オペレータに確認させてもよい。
【００５０】
また、前記実施の形態では、精算メニュー画面において当初から日報処理と精算処理を選択可能としたが、日報処理が実行され、支払い種別に入力された金額の保存が指令されるまでは精算処理を選択不可能として、精算処理の実行を規制するようにしてもよい。
【００５１】
この他、前記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を組合わせてもよい。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施の形態であるＰＯＳ端末の要部構成を示すブロック図。
【図２】同ＰＯＳ端末が有するモードスイッチを示す模式図。
【図３】同ＰＯＳ端末が有するキーボードの主要なキー配置を示す模式図。
【図４】同ＰＯＳ端末のＲＡＭに形成される主要なメモリエリアを示す模式図。
【図５】同ＰＯＳ端末の表示部に表示される精算メニュー画面の一例を示す模式図。
【図６】同ＰＯＳ端末のＣＰＵが実行する精算業務の要部処理手順を示す流れ図。
【図７】図６における日報処理を具体的に示す流れ図。
【図８】同ＰＯＳ端末の表示部に表示される日報データ入力画面の初期画面例を示す模式図。
【図９】同ＰＯＳ端末の表示部に表示される日報データ入力画面のデータ入力例を示す模式図。
【図１０】同ＰＯＳ端末の表示部に表示される保存確認画面の一例を示す模式図。
【符号の説明】
【００５３】
１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ，１４…モードスイッチ、１５…ドロワ、１６…キーボード、１７…オペレータ用表示器、１９…プリンタ、２４…現計キー、２５…信計キー、３１…取引別メモリテーブル、３２…日報入力メモリテーブル、３３…日報入力金額メモリ、３４…差額メモリ、３５…日報フラグメモリ。
【特許請求の範囲】
【請求項１】
登録，精算等の動作モードを備え、登録モード選択時において、商品販売データの入力に続いて締めキーの操作入力により商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理し、精算モード選択時において、精算処理実行が指令されると、前記取引別メモリのデータを基に精算レポートを出力後、該取引別メモリをクリアする商品販売データ処理装置において、
実際にドロワ内にある在高を現金，金券等の支払い種別に入力する在高入力手段と、
この在高入力手段により入力された金額の総額を記憶する入力総額記憶手段と、
この入力総額記憶手段により記憶された入力金額総額と複数の支払い種別に対応した所定の締めキーに対応して設けられている取引別メモリに記憶された金額との差額を算出する差額算出手段と、
この差額算出手段により算出される差額を前記在高入力手段により支払い種別に入力された金額とともに表示部に表示させる表示制御手段と、
在高入力手段により入力された金額の保存を指令する保存指令手段と、
この保存指令手段により保存が指令されたことを条件に前記精算処理の実行を許可する精算処理規制手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項２】
前記差額算出手段により算出される差額が０より大きい状況で前記保存指令手段により保存が指令されると、保存をしてよいか否かをオペレータに問合せる保存可否問合せ手段をさらに具備し、
前記精算処理規制手段は、前記保存可否問合せ手段により保存をしてよいか否かの問合せが発生した場合、保存してよいとの入力があったことを条件に前記精算処理の実行を許可することを特徴とする請求項１記載の商品販売データ処理装置。
【請求項１】
登録，精算等の動作モードを備え、登録モード選択時において、商品販売データの入力に続いて締めキーの操作入力により商取引の登録締めが宣言されると、入力された商品販売データを基に決済金額を算出し、この決済金額を操作入力された締めキーに対応して設けられている取引別メモリに加算処理し、精算モード選択時において、精算処理実行が指令されると、前記取引別メモリのデータを基に精算レポートを出力後、該取引別メモリをクリアする商品販売データ処理装置において、
実際にドロワ内にある在高を現金，金券等の支払い種別に入力する在高入力手段と、
この在高入力手段により入力された金額の総額を記憶する入力総額記憶手段と、
この入力総額記憶手段により記憶された入力金額総額と複数の支払い種別に対応した所定の締めキーに対応して設けられている取引別メモリに記憶された金額との差額を算出する差額算出手段と、
この差額算出手段により算出される差額を前記在高入力手段により支払い種別に入力された金額とともに表示部に表示させる表示制御手段と、
在高入力手段により入力された金額の保存を指令する保存指令手段と、
この保存指令手段により保存が指令されたことを条件に前記精算処理の実行を許可する精算処理規制手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項２】
前記差額算出手段により算出される差額が０より大きい状況で前記保存指令手段により保存が指令されると、保存をしてよいか否かをオペレータに問合せる保存可否問合せ手段をさらに具備し、
前記精算処理規制手段は、前記保存可否問合せ手段により保存をしてよいか否かの問合せが発生した場合、保存してよいとの入力があったことを条件に前記精算処理の実行を許可することを特徴とする請求項１記載の商品販売データ処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００７−１６４７０３（Ｐ２００７−１６４７０３Ａ）
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願番号】特願２００５−３６３５８７（Ｐ２００５−３６３５８７）
【出願日】平成１７年１２月１６日（２００５．１２．１６）
【出願人】（０００００３５６２）東芝テック株式会社 (5,631)
【Ｆターム（参考）】
【公開日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願日】平成１７年１２月１６日（２００５．１２．１６）
【出願人】（０００００３５６２）東芝テック株式会社 (5,631)
【Ｆターム（参考）】
[ Back to top ]