JP7180860B2 - 登録装置、システムおよびプログラム - Google Patents

Description

本発明は、登録装置、システムおよびプログラムに関する。

所定の取引について権限者が内容を確認するＰＯＳ装置が知られている（例えば、特許文献１参照）。

特開平１０－３０２１６２号公報

しかしながら、取引の内容を確認する権限者の負担が大きいという問題がある。

本発明は、このような事情に鑑みてなされたもので、権限者の負担を軽減させる技術を提供することを目的とする。

上述した課題を解決する本発明の一態様である商品データ処理装置は、権限者による確認が必要な確認必要取引か否かを判別する判別手段と、前記確認必要取引について権限者による確認を要求する確認要求手段とを備え、前記確認要求手段は、前記判別手段によって判定された前記確認必要取引について、閉店処理において、権限者による確認を要求する。

上記によれば、閉店処理において権限者に確認を要求するため、権限者の負担が軽減する。

上述した課題を解決する本発明の他の態様である商品データ処理装置は、権限者による確認が必要な確認必要取引か否かを判別する判別手段と、前記確認必要取引について権限者による確認を要求する確認要求手段と、閉店処理の実行を制御する閉店処理制御手段とを備え、前記閉店処理制御手段は、前記確認要求手段が、前記判別手段によって判定された前記確認必要取引について権限者による確認を要求した後に、閉店処理の実行を制御する。

上記によれば、好適に（権限者による確認の要求後の取引を用いて）、閉店処理を実行することができる。

上記商品データ処理装置において、前記確認要求手段は、前記確認必要取引について権限者による確認を要求した後に、前記確認必要取引について確認した旨の応答を受付可能であり、前記閉店処理制御手段は、前記確認要求手段が、前記確認必要取引について確認した旨の応答を受け付けた後に、閉店処理の実行を制御するようにしてもよい。

上記によれば、より好適に（権限者による確認がなされた取引を用いて）、閉店処理を実行することができる。

上記商品データ処理装置において、前記閉店処理制御手段は、前記確認要求手段が、前記確認必要取引について確認した旨の応答を受け付けなかった場合であっても、所定の入力があった場合には、閉店処理の実行を制御するようにしてもよい。

上記によれば、必要に応じて迅速に（権限者による確認を待つことなく、柔軟に）、閉店処理を実行することができる。

上記商品データ処理装置において、権限者による確認が必要な取引は、置数入力による値引き操作、返品に係る操作、両替に係る操作のうちの少なくとも１つの操作がなされた取引であってもよい。

上記によれば、置数入力による値引き操作などについて、的確に、管理者の確認をとることができる。

上記商品データ処理装置において、前記確認要求手段は、他装置に確認用の画面を表示させるための情報を送信するようにしてもよい。

上記によれば、他装置において簡便に確認することができる。

上述した課題を解決する本発明の他の態様であるプログラムは、商品データ処理装置としてコンピュータを機能させるプログラムであって、前記コンピュータを、権限者による確認が必要な確認必要取引か否かを判別する判別手段、前記確認必要取引について権限者による確認を要求する確認要求手段として機能させ、前記確認要求手段は、前記判別手段によって判定された前記確認必要取引について、閉店処理において、権限者による確認を要求することを特徴とするプログラムである。

以上、本発明によれば、権限者の負担を軽減させることができる。

ＰＯＳシステムのネットワーク構成図である。 登録装置の構成を示すブロック図である。 精算装置の構成を示すブロック図である。 取引データの一例である。 取引データの一例である。 登録装置に表示される画面例である。 登録装置に表示される画面例である。 登録装置に表示される画面例である。 閉店処理に関わる動作の流れの一例を示すフローチャートである。 閉店処理に関わる動作の流れの他の一例を示すフローチャートである。 閉店処理に関わる動作の流れの他の一例を示すフローチャートである。 閉店処理に関わる動作の流れの他の一例を示すフローチャートである。 閉店処理に関わる動作の流れの他の一例を示すフローチャートである。 閉店処理に関わる動作の流れの他の一例を示すフローチャートである。 他の画面例である。

以下、本発明の実施形態について図面を参照して説明する。図１は、本実施形態におけるＰＯＳシステム１のネットワーク構成図を示している。図１に示すＰＯＳシステム１は、複数の登録装置１０ａ、１０ｂ等と、複数の精算装置２０ａ、２０ｂ等と、ストアコントローラ３０と、監視装置４０とを備え、各装置はＬＡＮ１１を介して通信可能に接続されている。以下、個々の登録装置１０ａ、１０ｂ等の夫々を特に区別しない場合には単に登録装置１０と称し、個々の精算装置２０ａ、２０ｂ等の夫々を特に区別しない場合には単に精算装置２０と称するものとする。

登録装置１０は、店員により操作され、買上商品の登録処理を行うための装置である。例えば、登録装置１０は、登録処理の実行し、登録処理の処理内容（当該客の買上商品に関する商品登録情報）を含む登録データ（登録情報）を生成し、生成した登録データを店員により指定された精算装置２０に送信する。

以下の記載において、登録装置１０から精算装置２０に登録データを送信するとは、別段の断りがない限り、登録装置１０から送信された登録データが最終的に精算装置２０において受信されるという意味であり、登録装置１０から他の装置（例えば、ストアコントローラ３０等）を介して精算装置２０に登録データが送信される場合の他、登録装置１０から他の装置を介さずに直接精算装置２０に登録データが送信される場合も含まれる。登録装置１０から精算装置２０への他のデータ（例えば、各種の問い合せ情報や制御情報等）の送信や、精算装置２０から登録装置１０へのデータ（例えば、各種の応答情報等）についても同様である。

精算装置２０は、主に客により操作され、買上商品の精算処理を行うための装置である。例えば、精算装置２０は、登録装置１０から送信された登録データを受信し、該登録データに基づいて精算処理を実行する。

また、精算装置２０は、閉店処理を実行する。閉店処理とは、閉店後や開店前などに、釣札機２１２（図３参照）内の金額を確認、調整する処理である。閉店処理の詳細は後述する。

ストアコントローラ３０は、少なくとも、制御部（ストアコントローラ制御部と称する。不図示）、記憶部（ストアコントローラ記憶部と称する。不図示）、通信部（ストアコントローラ通信部と称する。不図示）を備える。ストアコントローラ制御部は、ストアコントローラ３０全体を制御する。

ストアコントローラ記憶部は、種々の情報を記憶する。例えば、ストアコントローラ記憶部は、商品ファイルをマスタファイルとして記憶する。商品ファイルは、商品コード（例えば、ＪＡＮ）、商品名、単価等を含むマスタファイルである。また例えば、ストアコントローラ記憶部は、他の装置（登録装置１０、精算装置２０等）から送信された情報を記憶する。

ストアコントローラ通信部は、ストアコントローラ制御部の制御によって、種々の情報を送受信する。例えば、ストアコントローラ通信部は、外部（例えば、本部のサーバ）から商品ファイルを受信し、ストアコントローラ記憶部に記憶する。また、ストアコントローラ通信部は、ストアコントローラ記憶部に記憶している商品ファイルを登録装置１０や精算装置２０に送信（配信）する。また、ストアコントローラ通信部は、他の装置から情報を受信する。

監視装置４０は、少なくとも、制御部（監視装置制御部と称する。不図示）、記憶部（監視装置記憶部と称する。不図示）、表示部（監視装置表示部と称する。不図示）、通信部（監視装置通信部と称する。不図示）を備え、他の装置（登録装置１０、精算装置２０等）の状態を監視する。例えば、監視装置４０は、精算装置２０が備える印刷部２１１（図３参照）において使用するレシート用紙（ロール紙）の残量や、精算装置２０が備える釣銭機２１２（図３参照）内の貨幣の数量を監視する。

図２は、登録装置１０の構成を示すブロック図である。図２に示すように、登録装置１０は、ＣＰＵ１０１と、ＲＯＭ１０２と、ＲＡＭ１０３と、スキャナ部１０４と、店員用表示部１０５と、客用表示部１０６と、ハードディスク１０７と、キー操作部１０８と、通信部１０９と、ブザー１１０と、印刷部１１１と、バス１１５とを備える。これらは、バス１１５を介して互いに接続されている。

ＲＯＭ１０２は、登録処理をＣＰＵ１０１に実行させるための商品登録プログラムを記憶する。ＲＡＭ１０３には、ＲＯＭ１０２又はハードディスク１０７から読み出された商品登録プログラムが展開される。また、ＲＡＭ１０３は、商品登録プログラムが実行されることによって生成された各種変数及びデータを一時記憶する。

スキャナ部１０４は、バーコードを光学的に読み取るスキャナである。スキャナ部１０４は、店員による操作により、商品に付されたバーコードから商品コードを光学的に読み取って、読み取った商品コードをＲＡＭ１０３に記憶させる。

ＣＰＵ１０１は、ＲＯＭ１０２等に記憶された商品登録プログラムを読み出してＲＡＭ１０３に展開し、展開した商品登録プログラムのステップを実行することにより、登録装置１０全体を制御する。例えば、ＣＰＵ１０１は、スキャナ部１０４が読み取った商品コードと、ハードディスク１０７に記憶された商品ファイルとに基づいて、買上商品の商品名及び小計金額等を、店員用表示部１０５に表示させる。

また、ＣＰＵ１０１は、商品登録した全部の商品の商品コードを含む登録データを生成する。ＣＰＵ１０１は、生成した登録データを、通信部１０９を制御して、精算装置２０に送信させる。なお、ＣＰＵ１０１は、生成した登録データを精算装置２０に送信することに加えて、ＲＡＭ１０３又はハードディスク１０７に記憶してもよい。

店員用表示部１０５は、例えば、液晶タッチディスプレイ装置である。店員用表示部１０５は、店員に各種の情報（登録画面、両替用画面、各種の確認用画面等）を表示する。また、店員用表示部１０５は、店員が操作する各種ボタン（各種キー）を表示する。例えば、商品登録の終了を指示するための小計ボタン、登録データの送信先を指定（選択）するための精算装置指定ボタン、操作に基づく割引（値引）をするための割引ボタン（値引ボタン）、登録した商品の登録を取り消すための取消ボタン（訂正ボタン）、既に販売した商品の返品を受け付けるための返品ボタン、両替をするための両替ボタン等を表示してもよい。訂正ボタンと返品ボタンとは一のボタン（両用途を兼ねた兼用のボタン）であってもよい。

なお、操作に基づく割引（値引）とは、商品コードを読み取ることによって予め登録された割引（値引）情報に基づいて自動的に適用される割引（値引）ではなく、店員の操作（割引ボタン（値引ボタン）の操作）によって適用される割引（値引）である。以下の説明において、操作に基づく割引（値引）を、手入力による割引と称する場合がある。また、予め登録された割引（値引）情報に基づいて自動的に適用される割引（値引）を、事前登録による割引と称する場合がある。

客用表示部１０６は、例えば、液晶タッチディスプレイ装置である。客用表示部１０６は、客に各種の情報（単価等）を表示する。また、客用表示部１０６は、客が操作する各種ボタン（例えば年齢確認のＯＫボタン等）を表示する。

ハードディスク１０７は、例えば、磁気記録装置であり、外部から取得される情報（例えば、商品ファイル、商品登録プログラム等）や、自登録装置１０において生成される情報（例えば、登録データ等）を記憶する。

キー操作部１０８は、店員が操作する各種ボタン（金額等の数字を入力するための数字ボタン等）を配置する。なお、店員用表示部１０５に表示することに代えて又は加えて、店員用表示部１０５に表示するものであるとして説明した各種のボタン（例えば、上述した小計ボタン、返品ボタン等）を、キー操作部１０８に配置してもよい。換言すれば、あるボタンについて、店員用表示部１０５への表示か、キー操作部１０８への配置のうち、少なくとも一方がなされていればよい。

通信部１０９は、ＬＡＮ１１を介して外部の装置（他の登録装置１０、精算装置２０、ストアコントローラ３０、監視装置４０）と通信するための通信インタフェースである。ブザー１１０は、確認音及び警告音を発生させるための音発生部である。印刷部１１１は、各種媒体を印刷、発行する。

図３は、精算装置２０の構成を示すブロック図である。図３に示すように、精算装置２０は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、スキャナ部２０４と、表示部２０６と、ハードディスク２０７と、通信部２０９と、ブザー２１０と、印刷部２１１と、釣銭機（自動釣銭釣札機）２１２と、サインポール２１３と、バス２１５とを備える。これらは、バス２１５を介して互いに接続されている。

ＲＯＭ２０２は、精算処理をＣＰＵ２０１に実行させるための会計プログラムを記憶する。ＲＡＭ２０３は、ＲＯＭ２０２又はハードディスク２０７から読み出された商品登録プログラムが展開される。また、ＲＡＭ２０３は、会計プログラムが実行されることによって生成された各種変数及びデータを一時記憶する。スキャナ部２０４は、バーコードを光学的に読み取るスキャナである。

ＣＰＵ２０１は、ＲＯＭ２０２に記憶された会計プログラムを読み出してＲＡＭ２０３に展開し、展開した会計プログラムのステップを実行することにより、精算装置２０全体を制御する。例えば、ＣＰＵ２０１は、登録装置１０から送信された登録データに基づいて合計金額を表示部２０６に表示させる。また、ＣＰＵ２０１は、釣銭機２１２に投入された貨幣の金額に関する情報を釣銭機２１２から取得し、入金額として表示部２０６に表示させる。また、ＣＰＵ２０１は、合計金額と入金額とに基づいて釣銭額（釣り銭金額）を算出し、表示部２０６に表示させる。また、ＣＰＵ２０１は、精算処理が終了すると、レシートを印刷部２１１から発行させるとともに、釣銭額と等しい額の貨幣を釣銭機２１２から排出させる。また、ＣＰＵ２０１は、精算処理が終了すると、預り金額や釣銭額を含む精算データ（精算情報）を生成し、通信部２０９を制御して、外部の装置（例えば、ストアコントローラ３０）に送信させる。なお、ＣＰＵ２０１は、生成した精算データを、外部の装置に送信することに加えて、ＲＡＭ２０３又はハードディスク２０７に記憶してもよい。また、ＣＰＵ２０１は、他の装置（例えば、登録装置１０）から送信された制御情報（閉店処理開始制御情報）に基づいて閉店処理を実行する。閉店処理の詳細は後述する。

表示部２０６は、例えば、液晶タッチディスプレイ装置である。表示部２０６には、客が操作するためのガイダンス（メッセージ）表示や操作ボタンが表示される。操作ボタンとしては、例えば、精算装置２０に移動してきた客が精算装置２０における処理（精算）の開始を宣言（指示）するための開始ボタンや、貨幣の投入を終えた客が釣銭機２１２に釣銭処理（投入金額を確定させて必要な釣り銭を排出させる処理）を開始させるためのおわりボタン等である。

ハードディスク２０７は、例えば、磁気記録装置であり、外部から取得される情報（例えば、登録データ等）や、自精算装置２０において生成される情報（例えば、精算データ等）を記憶する。

通信部２０９は、ＬＡＮ１１を介して外部の装置（登録装置１０、他の精算装置２０、ストアコントローラ３０、監視装置４０）と通信するための通信インタフェースである。ブザー２１０は、確認音及び警告音を発生させるための音発生部である。印刷部２１１は、各種媒体を印刷、発行する。

釣銭機２１２は、貨幣（金銭）が収納される収納部（非図示）への入出金を制御する自動釣銭釣札機である。なお、図３に示す例では、釣銭機２１２は精算装置２０に内蔵されているが、釣銭機２１２は精算装置２０に接続されていてもよい。釣銭機２１２の詳細は後述する。

サインポール２１３は、複数色の表示灯を有し、夫々の表示態様（消灯、点灯、点滅等）により、店員や客に対し、自精算装置２０がどのような状態であるかや、自精算装置２０が特定の精算装置２０（例えば、店員によって指定された精算装置等）であるかなどを報知する。

続いて、釣銭機２１２について詳しく説明する。以下の説明において、精算装置２０と釣銭機２１２との関係について、精算装置２０に内蔵された釣銭機２１２と精算装置２０に接続されている釣銭機２１２とを特に区別しない場合には、ともに、精算装置２０の釣銭機２１２とも称する。また、精算装置２０と釣銭機２１２との関係について、釣銭機２１２を内蔵している精算装置２０と釣銭機２１２を接続している精算装置２０とを特に区別しない場合には、ともに、釣銭機２１２を内蔵等する精算装置２０とも称する。

釣銭機２１２は、精算装置２０において、登録された商品の代金を現金（貨幣）にて決済するときに使用される。釣銭機２１２は、紙幣を投入するための紙幣投入口（非図示）、硬貨を投入するための硬貨投入口（非図示）、紙幣を放出するための紙幣放出口（非図示）、硬貨を放出するための硬貨放出口、投入又は放出される貨幣を計数する計数部（非図示）、投入口又は放出口と収納部（非図示）の間の貨幣の搬送機構（非図示）などを有する。なお、紙幣投入口及び硬貨投入口は、預り金投入口とも称される。紙幣放出口及び硬貨放出口は、釣銭放出口とも称される。なお、紙幣投入口と紙幣放出口は共通であってもよく、また、硬貨投入口と硬貨放出口は共通であってもよい。

釣銭機２１２は、釣銭投入口された貨幣を計数し、収納部に収納する。また、釣銭機２１２は、放出する貨幣を計数し、釣銭放出口から放出する。例えば、釣銭機２１２は、精算時にお客から預かった貨幣を計数し、収納部に収納し、精算時にお客への釣り銭とする貨幣を計数し、釣銭放出口から放出する。

また、釣銭機２１２は、閉店処理時に補充された貨幣を計数し、収納部に収納する。また、釣銭機２１２は、閉店処理時に出金する貨幣を計数し、釣銭放出口から放出する。閉店処理とは、閉店後や開店前などに釣銭機２１２内に収納されている金額（現金有高／現金在高）を基準金額に調整する処理である。閉店処理は、釣銭機２１２に貨幣を補充する処理や釣銭機２１２から貨幣を回収する処理などを含む。

釣銭機２１２を内蔵等する精算装置２０は、登録装置１０からの閉店処理開始制御情報に応じて釣銭機２１２による閉店処理を実行する。

また、釣銭機２１２を内蔵等する精算装置２０は、閉店処理の開始時に、当該閉店処理の対象となる取引データ（取引情報）のなかに、特定の取引データ（手入力による割引を含む取引データ、返品に係る取引データ、両替に係る取引データ等）が含まれている場合には、当該閉店処理の開始に先立って、所定の管理者（店長等の所定の権限を有する者）に対し、当該閉店処理の開始について承認（確認）を求めるようにしている（具体的には、特定の取引データの承認を求める承認要求情報を送信する）。なお、釣銭機２１２を内蔵等する精算装置２０は、閉店処理の実行中に当該閉店処理を一時中断し、所定の管理者に対し、当該閉店処理の進行について承認（確認）を求めるようにしてもよい。

なお、取引データとは、取引に関する情報である。例えば、登録装置１０が生成する登録データも、精算装置２０が生成する精算データも取引データに該当するが、閉店処理の開始時（閉店処理の実行中）に、特定の取引データであるか否かを確認する取引データは、精算装置２０が生成した精算データである。

図４及び図５は、取引データの一例である。図４（Ａ）は、通常の取引データの一例である。図４（Ａ）の取引データにおいて、「入金貨幣枚数」は、預り金の貨幣毎の枚数の内訳を示し、「出金貨幣枚数」は、釣銭の貨幣毎の枚数の内訳を示している。例えば、当該取引における預り金額が５０３円、釣銭金額が１２０円であれば、入金貨幣枚数として、例えば、５百円１枚、１円３枚が記憶され、出金貨幣枚数として、例えば、百円１枚、十円２枚が記憶されていることになる。

図４（Ｂ）は、手入力による割引を含む取引データ（特定の取引データの一種）の一例である。図４（Ｂ）の取引データにおいて、「割引」は、当該商品（花火セット）の割引金額を示し、「割引区分」は、当該割引の割引態様（例えば、事前登録による割引か、手入力による割引か等）を示している。例えば、登録装置１０において、当該商品（花火セット）の読み取り後に、４８０を置数入力し、割引ボタンを押下した場合、図４（Ｂ）に示すように、割引として４８０（円）、割引区分として手入力を示す情報（「０２」）が記憶される。なお、例えば、当該取引における預り金額が１０００円、釣銭金額が２００円であれば、入金貨幣枚数として、例えば、千円１枚が記憶され、出金貨幣枚数として、例えば、百円２枚が記憶されていることになる。なお、図４（Ｂ）の取引データの「管理者承認状況」については後述する。

図４（Ｃ）及び図５（Ａ）は、返品を含む取引データ（特定の取引データの一種）の一例である。具体的には、図４（Ｃ）の取引データは、購入日とは異なる日に返品を受け付けた場合（より詳細には、購入日の閉店処理が既に完了しているときに返品がなされた場合）の取引データの一例である。また、図５（Ａ）の取引データは、購入日当日に返品を受け付けた場合（より詳細には、購入日の閉店処理が未だ完了していないときに返品がなされた場合）の取引データの一例である。

図４（Ｃ）において、「単価」は、当該商品（ヘッドセット）の返金金額を示し、「返品区分」は、当該割引の返品区分（例えば、返品の理由等）を示している。例えば、登録装置１０において、返品ボタンの押下し、返品理由を入力（例えば、返品ボタンの押下後に表示される返品理由画面から選択する等）した後に、当該商品（ヘッドセット）を読み取った場合、図４（Ｃ）に示すように、単価として－９８０（円）、返品区分として不良を示す情報（「０１」）が記憶される。図５（Ａ）における「単価」や「返品区分」も同様である。

なお、図４（Ｃ）の場合、返金金額が出金金額であるため、出金貨幣枚数として、例えば、５百円１枚、百円４枚、５十円１枚、十円３枚が記憶されていることになる。図５（Ａ）における「出金貨幣枚数２」も同様である。なお、図４（Ｃ）の取引データの「管理者承認状況」については後述する。

図５（Ａ）の取引データは、当該商品（ヘッドセット）の購入時の情報に、返品時の取情報を付加した構成となっている。従って、例えば、購入時における預り金額が１０００円、釣銭金額が２０円であれば、入金貨幣枚数として、例えば、千円１枚が記憶され、出金貨幣枚数１として、例えば、十円２枚が記憶されていることになる。また、出金貨幣枚数２として、例えば、５百円１枚、百円４枚、５十円１枚、十円３枚が記憶されていることになる。なお、図５（Ａ）の場合、購入時における出金貨幣枚数と、返品時における貨幣枚数とを区別するため、前者を出金貨幣枚数１、後者を出金貨幣枚数２としている。なお、図５（Ａ）の取引データの「管理者承認状況」については後述する。

図５（Ｂ）及び図５（Ｃ）は、両替を含む取引データ（特定の取引データの一種）の一例である。具体的には、図５（Ｂ）の取引データは、店員を介さずに客自身が一人で両替を行った場合（より詳細には、登録装置１０を介さずに、精算装置２０において両替の操作が行われた場合）の取引データの一例である。また、図５（Ｃ）の取引データは、店員を介して両替を行った場合（より詳細には、客の両替の申し出に従って登録装置１０において両替の登録を行った後、客が精算装置２０に移動し両替を行った場合）の取引データの一例である。

図５（Ｂ）に示す例において、「両替日時」は、客が両替を行った日時（例えば、客が両替操作を行った日時、両替客からの入金を受け付けた日時、両替客に出金した日時等）である。図５（Ｃ）における「両替日時」も同様である。また、両替の場合、両替客から受け取る金額が入金金額、両替客に差し出す金額が出金金額であるため、例えば、１万円を５千円１枚と千円５枚に両替した場合には、図５（Ｂ）に示すように、入金貨幣枚数として、例えば、１万円１枚が記憶され、出金貨幣枚数として、例えば、５千円５枚、千円５枚が記憶される。図５（Ｃ）における「入金貨幣枚数」や「出金貨幣枚数」も同様である。なお、図５（Ｂ）の取引データの「管理者承認状況」については後述する。

図５（Ｃ）に示す例において、「登録日時」は、登録装置１０において店員が両替の登録を行った日時である。なお、登録装置１０は、両替の登録後に、両替に係る登録データを生成し、該登録データを、例えば店員が指定した精算装置２０に送信する。なお、図５（Ｃ）の取引データの「管理者承認状況」については後述する。

なお、図５（Ｃ）に示した取引データは、登録装置１０側において両替客から現金を受け取らずに両替客から両替の宣言だけを受け付ける態様における取引データであるが、登録装置１０側において両替客から現金を受け取る態様における取引データは、登録装置１０側において両替客から現金を受け取らずに両替客から両替の宣言だけを受け付ける態様における取引データと異なる構成であってもよい。登録装置１０側において両替客から現金を受け取る態様では、両替客から受け取った現金を登録装置１０側に収容し、精算装置２０側における入金は行われないため、入金貨幣枚数は不要となる。従って、登録装置１０側において両替客から現金を受け取る態様における取引データには、「入金貨幣枚数」がなくてもよい。

なお、登録装置１０側において両替客から現金を受け取る態様の場合、精算装置２０における出金金額を特定させるために、精算装置２０に送信する登録データ（両替に係る登録データ）に、登録装置１０側において収容した金額（両替客から受け取った金額）に関する情報を含める。また、登録装置１０側において両替客から要望（どのように両替するかの情報）を登録し、登録データ（両替に係る登録データ）に含めることにより、精算装置２０側における出金（どの金種を何枚出金するか）を制御してもよい。

図５（Ｄ）は、特定の取引データ（例えば、図４（Ｂ）に示したような手入力による割引を含む取引データ、図４（Ｃ）及び図５（Ａ）に示したような返品を含む取引データ、図５（Ｂ）及び図５（Ｃ）に示したような両替を含む取引データ等）に含まれる「管理者承認状況」の構成例である。

精算装置２０は、上述したように、閉店処理の開始時等に、当該閉店処理の対象となる取引データのなかに特定の取引データが含まれている場合には、当該閉店処理の開始等に対し、当該閉店処理の開始等について承認を求めるようにしている。具体的には、精算装置２０は、特定の取引データ毎に承認を求めるようにしている。従って、例えば、当該閉店処理の対象となる取引データのなかに３件の特定の取引データが含まれている場合には、３件夫々の取引データについて承認を求めるようにしている。

図５（Ｄ）に示した管理者承認状況は、「承認状況区分」、「日時」、「店員コード」を含む。「承認状況区分」は、当該取引データにおける承認の状況を示している。例えば、承認状況区分「０」は、未承認（管理者から閉店処理の開始等を承認する旨の応答がない旨）を示している。承認状況区分「０」は初期値であって、閉店処理の開始前（即ち、当該取引データの生成時）には、承認状況区分は「０」である。承認状況区分「１」は、承認済（管理者から閉店処理の開始等を承認する旨の応答があった旨）を示している。承認状況区分「２」は、承認省略（管理者から閉店処理の開始等を承認する旨の応答はないが、管理者以外の店員から管理者による承認を省略し、閉店処理の開始等を強行する旨の応答があった旨）を示している。

なお、承認状況区分「１」であるときには、「日時」には管理者による「承認」の日時（管理者から閉店処理の開始等を承認する旨の応答があった日時等）が記憶され、「店員コード」には、当該管理者の店員コードが記憶される。また、承認状況区分「２」であるときには、「日時」には管理者以外の店員による「強行」の日時（管理者以外の店員から閉店処理の開始等を強行する旨の応答があった日時等）が記憶され、「店員コード」には、当該店員の店員コードが記憶される。なお、承認状況区分「０」であるときには、「日時」及び「店員コード」には値がなくてもよい（例えば、Null等であってもよい）。

また、承認状況区分は、上記「０」～「２」に限定されない。例えば、応答として不承認を設ける態様の場合には、承認状況区分「３」を、不承認（管理者から閉店処理の開始等を承認しない旨の応答があった旨）としてもよい。

図６は、登録装置１０に表示される画面例である。登録装置１０は、店員の操作（例えば、特定取引一覧画面を表示するための所定のボタンの押下等）に応じて、図６（Ａ）に示すような特定取引一覧画面を表示する。図６（Ａ）に示した特定取引一覧画面は、特定の取引データ（手入力による割引を含む取引データ、返品に係る取引データ、両替に係る取引データ等）を表示する画面である。なお、ある取引データが特定の取引データであるか否かは、当該取引データにおける管理者承認状況（図５（Ｄ）参照）の有無に基づいて判断してもよい。

図６（Ａ）に示した特定取引一覧画面では、ＬＡＮ１１に存在する全ての精算装置２０（精算機１（２０１レジ）、精算機２（２０２レジ）、精算機３（２０３レジ）、精算機４（２０４レジ）、精算機５（２０５レジ）の５台）に関連する特定の取引データ（つまり、ＰＯＳシステム１に存在する全ての特定の取引データ）を表示可能である。

図６（Ａ）に示すように、特定取引一覧画面の左側領域には、未承認の特定の取引データが一覧表示される。なお、番号「１」の取引データは、図４（Ｂ）に示した取引データである。番号「２」の取引データは、図４（Ｃ）に示した取引データである。番号「３」の取引データは、図５（Ｂ）（又はず５（Ｃ））に示した取引データである。

特定取引一覧画面の右側領域には、左側領域における一の取引データ（左側領域において店員が選択した取引データ、又は、未選択の場合には最上部の取引データ）に係る詳細情報が表示される。図６（Ｂ）に示した例では、右側領域には、番号「２」の取引データに係る詳細情報が表示されている。なお、番号「２」の斜線は、右側領域に詳細情報が表示されている取引データが、番号「２」の取引データである旨を示したものである。

特定取引一覧画面の「承認」ボタンは、選択等された取引データ（左側領域に表示された取引データ）を承認するためのボタンである。本実施形態では、特定の取引データの承認は、管理者に与えられた権限である。従って、管理者がログインしている場合には、「承認」ボタンの操作は有効となる（「承認」ボタンの操作によって、当該特定の取引データについて承認された旨の承認応答情報が送信され、当該特定の取引データを承認することが可能となる）。一方、管理者でない者がログインしている場合には、「承認」ボタンの操作は無効となる。例えば、操作後に権限がない旨のエラーメッセージを表示し、当該特定の取引データを承認できないようにしてもよい。あるいは、管理者でない者がログインしている場合には、特定取引一覧画面に「承認」ボタンを表示しないようにしてもよい。

特定取引一覧画面の「映像確認」ボタンは、選択等された取引データ（左側領域に表示された取引データ）の撮像データ（動画データ。静止画データであってもよい）を確認するためのボタンである。本実施形態では、各取引（登録時、精算時）の様子を撮像し、夫々の取引（取引番号等）に対応付けて撮像データを記憶（例えば、ストアコントローラ３０や監視装置４０に記憶）している。撮像装置（カメラ）は、夫々の登録装置１０（精算装置２０）に接続されるようにしてもよいし、夫々の登録装置１０（精算装置２０）が、撮像装置を備えるようにしてもよい。また、撮像装置や店内の柱や天井等に配置してもよい。なお、店内の柱や天井等に配置する態様では、夫々の取引に対応付けて撮像データが最終的にストアコントローラ３０等の記憶部に記憶できるようになっていればよい。

特定取引一覧画面の「映像確認」ボタンが操作された場合には、例えば、図６（Ｂ）に示すような映像確認画面を表示し、映像確認画面において、当該取引データの撮像データをストアコントローラ３等から読み出して（受信して）、再生（表示）する。登録時と精算時の２つの撮像データが存在する場合には、再生する撮像データを店員が選択できるようにしてもよい。また、一部の取引データ（店員を介さずに両替した場合の取引データ等）は、精算時の撮像画像を再生し、他の取引データ（手入力の割引の取引データ、返品の取引データ、店員を介して両替した場合の取引データ等）は、登録時の撮像データを再生するようにしてもよい。

なお、映像確認画面では、図６（Ｂ）に示すように、映像指定として、時間や取引番号から撮像データを指定し、再生することも可能である。

なお、本実施形態では、特定取引一覧画面の左側領域には特定の取引データのうち未承認のものを一覧表示しているが、未承認でないものも含め一覧表示してもよい。なお、左側領域に未承認でないものも含め一覧表示する場合には、夫々の取引データの管理者承認状況（図５（Ｄ）参照）に基づいて、夫々の承認の状況を表示してもよい。

また、応答として不承認を設ける態様の場合には、図６（Ａ）に示すように、「不承認」ボタンを設けるようにしてもよい。「不承認」ボタンは、選択等された取引データ（左側領域に表示された取引データ）を不承認とするためのボタンである。なお、不承認の詳細は後述する。

図７は、登録装置１０に表示される画面例である。登録装置１０は、店員の操作（例えば、精算機一覧画面を表示するための所定のボタンの押下等）に応じて、図７に示すような精算機一覧画面を表示する。図７に示した精算機一覧画面は、各精算装置について、種々の警告情報（例えば、釣銭ニアエンドである旨、釣銭ニアフル、領収証への捺印を要する旨、レシート残量が少ない旨、お会計に時間を要している旨）を表示する画面である。図７に示した精算機一覧画面では、ＬＡＮ１１に存在する全ての精算装置２０（精算機１（２０１レジ）～精算機５（２０５レジ）の５台）の夫々における種々の警告情報を表示している。

図８は、登録装置１０に表示される画面例である。登録装置１０は、店員の操作（例えば、閉店処理状況画面を表示するための所定のボタンの押下等）に応じて、図８に示すような各精算機（精算装置）における閉店処理状況画面を表示する。図８に示した閉店処理状況画面では、店員によって閉店処理の開始を指示された４台の精算装置（精算機２（２０２レジ）～精算機５（２０５レジ））の夫々における閉店処理の状況画面を表示している。

なお、店員は、登録装置１０において、閉店処理の開始を指示可能である。即ち、登録装置１０は、店員による所定の操作（閉店処理を実行させる精算装置２０を選択する操作、当該指定した精算装置２０に閉店処理を実行させる操作等）に基づいて、閉店処理を実行させる精算装置２０に閉店処理開始制御情報を送信する。

閉店処理は、複数の工程から構成されている。本実施形態において、閉店処理は、釣銭再精査、実在高確定、残置金確定、釣銭回収、レジ閉設処理から構成されている。「釣銭再精査」は、当該機器内の貨幣を再精査することである。「実在高確定」は、釣銭再精査の結果、当該機器の実在高が確定することである。「残置金確定」は、当該機器内の残置金額を調整し確定させることである。「釣銭回収」は、回収ボックス（カセット）を用いて、当該機器内の貨幣を回収することである。「レジ閉設処理」は、当該機器の売上情報を他の装置（例えば、ストアコントローラ３０）に送信することである。

登録装置１０は、図８に示すように、各精算装置２０について、閉店処理に含まれる各工程（釣銭再精査、実在高確定、残置金確定、釣銭回収、レジ閉設処理）に対応する工程領域の表示態様を変化（例えば、色を変化）させることによって、各精算装置２０の閉店処理の処理状況を表示する。

例えば、夫々の精算装置２０は、各工程の処理状況に応じて（例えば、各工程が終わったときに）、閉店処理状況画面を表示する装置（登録装置１０）に対し、各工程の処理状況に関する情報（処理状況通知）を送信する。処理状況通知は、複数の工程のうち何れの工程が始まったかや終わったかを閉店処理状況画面を表示する装置（登録装置１０）側で特定できるような情報を含むものであればよい。閉店処理状況画面を表示する装置（登録装置１０）は、各精算装置２０から受信した処理状況通知に基づいて、図８に示すような閉店処理状況画面を表示する。

なお、図８において、無地の工程領域は、当該工程が未だ行われていない旨を表している。濃い（密な）ドット表示の工程領域は、当該工程が現在行われている旨を表している。薄い（疎な）ドット表示の工程領域は、当該工程が既に終わった旨を表している。なお、本実施形態では、現在行われている工程と、既に終わった工程とを区別し、異なる表示態様で表示しているが、現在行われている工程と、既に終わった工程とを区別せずに、同一の表示態様で表示するようにしてもよい。

上述のように各工程の処理状況を表示することによって、店員は、閉店処理が「釣銭再精査」→「実在高確定」→「残置金確定」→「釣銭回収」→「レジ閉設処理」の順に行われ、最後の「レジ閉設処理」が終わると完了するということや、各機器において閉店処理がどの程度、進んでいるかということを、視覚的に認識することができる。例えば、図８の例によれば、店員は、例えば、精算機４について、「釣銭再精査」が終わって「実在高確定」が行われていることを認識することができる。

また、店員は、夫々の精算装置２０に対応する、メッセージ欄Ｍのメッセージ、背景の表示態様によっても、夫々の精算装置２０における、処理状況や必要な作業を認識することができる。例えば、精算機２のメッセージ欄のメッセージ「要承認取引有。管理者に確認しています…」により、店員は、当該精算装置２０が、現在、特定の取引データ（手入力による割引を含む取引データ、返品に係る取引データ、両替に係る取引データ等）が存在するため、管理者に承認を求めている状況（最初の工程である「釣銭再精査」の開始待ちの状況）にあると認識することができる。また例えば、精算機５のメッセージ欄のメッセージ「売上回収（ドロアー）してください」により、店員は、当該精算装置２０が、現在、店員の作業（売上回収）が必要な状況（当該精算装置２０は店員による作業待ちの状況）にあると認識することができる。なお、精算機５の背景の表示態様（斜線）は、当該精算装置２０が、店員による作業待ちとなっている旨を視覚的に強調したものである。

精算機２の「承認省略」ボタンは、管理者の承認を省略する（閉店処理の開始等を強行する）ためのボタンである。「承認省略」ボタンの操作によって、当該特定の取引データについて管理者の承認が省略された旨の承認省略情報が送信され、当該特定の取引データの承認を省略することが可能となる。

以下、他の構成例について説明する。

（特定の取引データの表示）
上記では、特定取引一覧画面（図６（Ａ）参照）において「特定の取引データ」の存在及び内容を確認する例を説明したが、他の画面において「特定の取引データ」の存在及び内容を確認できるようにしてもよい。例えば、特定取引一覧画面に代えて又は加えて、精算機一覧画面（図７参照）において、「特定の取引データ」の存在及び内容を確認できるようにしてもよい。なお、精算機一覧画面において、特定の取引データの内容（つまり、手入力による割引を含む取引データ、返品に係る取引データ、両替に係る取引データの別）については確認できないが、特定の取引データの存在のみを確認できるようにしてもよい。一例として、図７の精算機５に対する「ニアエンド」などと同様、特定の取引データが存在する精算装置２０に対して「特定の取引データ」などと表示するようにしてもよい。

上記では、登録装置１０において「特定の取引データ」の存在を確認する例を説明したが（具体的には、特定取引一覧画面（図６（Ａ）参照）にて「特定の取引データ」の存在及び内容を確認する例を説明したが）、他の装置において「特定の取引データ」の存在を確認できるようにしてもよい。具体的には、登録装置１０に代えて又は加えて、監視装置４０において、特定の取引データの存在を確認できるようにしてもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０が、特定取引一覧画面を表示してもよい。

また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０において、特定の取引データの存在を確認できるようにしてもよい。例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０が、特定取引一覧画面を表示してもよい。また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォンにおいて、特定の取引データの存在を確認できるようにしてもよい（例えば、特定取引一覧画面を表示してもよい）。

（映像確認）
上記では、特定取引一覧画面（図６（Ａ）参照）から映像確認画面（図６（Ｂ）参照）を呼び出す例を説明したが、他の画面から映像確認画面を呼び出すようにしてもよい。例えば、特定取引一覧画面に代えて又は加えて、精算機一覧画面（図７参照）から映像確認画面を呼び出すようにしてもよい。また、特定取引一覧画面や精算機一覧画面に代えて又は加えて、閉店処理状況画面（図８参照）から映像確認画面を呼び出すようにしてもよい。

上記では、登録装置１０において映像データを確認する例を説明したが（具体的には、映像確認画面（図６（Ｂ）参照）にて映像データを確認する例を説明したが）、他の装置において映像データを確認できるようにしてもよい。具体的には、登録装置１０に代えて又は加えて、監視装置４０において、映像データを確認できるようにしてもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０が、映像確認画面を表示してもよい。

また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０において、映像データを確認できるようにしてもよい。例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０が、映像確認画面を表示してもよい。また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォンにおいて、映像データを確認できるようにしてもよい
（例えば、映像確認画面を表示してもよい）。

（精算装置の一覧）
上記では、登録装置１０において精算機一覧画面（図７参照）を表示する例を説明したが、他の装置において精算機一覧画面を表示してもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０が、精算機一覧画面を表示してもよい。また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０が、精算機一覧画面を表示してもよい。また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォンが、精算機一覧画面を表示してもよい。

（閉店処理の開始）
上記では、登録装置１０において閉店処理を開始する操作が行われる例を説明したが（具体的には、登録装置１０における店員の操作に基づいて、当該登録装置１０から精算装置２０に閉店処理開始制御情報が送信される例を説明したが）、他の装置において閉店処理を開始する操作が行われるようにしてもよい。具体的には、登録装置１０に代えて又は加えて、監視装置４０において、閉店処理を開始する操作が行われるようにしてもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０における店員の操作に基づいて、当該監視装置４０から精算装置２０に閉店処理開始制御情報が送信されるようにしてもよい。

また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０において、閉店処理を開始する操作が行われるようにしてもよい。例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０における閉店処理が開始されるようにしてもよい（具体的には、精算装置２０において店員の操作があった場合には、他の装置から閉店処理開始制御情報を受信した場合と同様の制御がなされるようにしてもよい）。また例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０とは異なる他の精算装置２０における閉店処理が開始されるようにしてもよい（具体的には、精算装置２０において店員の操作があった場合には、当該精算装置２０から他の精算装置２０に閉店処理開始制御情報が送信されるようにしてもよい）。また例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０、及び、他の精算装置２０における閉店処理が開始されるようにしてもよい。

また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォンにおいて、閉店処理を開始する操作が行われるようにしてもよい（例えば、操作があった場合に閉店処理開始制御情報が送信されるようにしてもよい）。

（閉店処理の状況）
上記では、登録装置１０において閉店処理状況画面（図８参照）を表示する例を説明したが、他の装置において閉店処理状況画面を表示してもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０が、閉店処理状況画面を表示してもよい。また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０が、閉店処理状況画面を表示してもよい。また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォンが、閉店処理状況画面を表示してもよい。

（特定の取引データの承認の要求）
上記では、精算装置２０において「特定の取引データ」の承認を求める例を説明したが（具体的には、精算装置２０が、閉店処理の開始時（閉店処理の実行中）に、特定の取引データの承認を求める承認要求情報を送信する例を説明したが）、他の装置において「特定の取引データ」の承認を求めるようにしてもよい。具体的には、精算装置２０に代えて又は加えて、閉店処理開始制御情報を送信した装置（登録装置１０、監視装置４０、タブレット、ノートパソコン、スマートフォン等）が、「特定の取引データ」の承認を求めるようにしてもよい。

例えば、登録装置１０（監視装置４０、タブレット等も同様）は、閉店処理を実行させる精算装置２０に関係する「特定の取引データ」（該精算装置２０における閉店処理に利用される「特定の取引データ」）が存在するか否かを判断する。そして、登録装置１０は、「特定の取引データ」が存在すると判断した場合に、承認を求めるようにしてもよい（例えば、該登録装置１０を管理者が使用している場合には承認画面を表示し、該登録装置１０を管理者が使用していない場合には管理者が使用する装置に承認要求情報を送信してもよい）。なお、その後、管理者の承認があった場合に（又は、承認省略の操作があった場合に）、精算装置２０に閉店処理開始制御情報を送信する。

また例えば、登録装置１０（監視装置４０、タブレット等も同様）は、閉店処理を実行させる精算装置２０に閉店処理開始制御情報を送信し、閉店処理開始制御情報を受信した精算装置２０は、自装置に関係する「特定の取引データ」が存在するか否かを判断する。精算装置２０は、「特定の取引データ」が存在すると判断した場合に、「特定の取引データ」が存在する旨の情報を登録装置１０に送信する。そして、「特定の取引データ」が存在する旨の情報を受信した登録装置１０は、承認を求めるようにしてもよい（例えば、該登録装置１０を管理者が使用している場合には承認画面を表示し、該登録装置１０を管理者が使用していない場合には管理者が使用する装置に承認要求情報を送信してもよい）。

なお、上述したように、「特定の取引データ」を含む取引データ（精算データ）は、少なくともストアコントローラ３０に記憶されている。換言すれば、ストアコントローラ３０に代えて又は加えて、夫々の精算装置２０も、「特定の取引データ」を含む取引データ（精算データ）を記憶している。なお、閉店処理の開始時点では、ストアコントローラ３０には未だ記憶されておらず、夫々の精算装置２０にのみ記憶されていてもよい。いずれにしても、「特定の取引データ」は、アクセス可能な場所に記憶されていればよい。

（特定の取引データの存在の確認）
上記「特定の取引データの承認の要求」において説明したように、閉店処理の対象となる精算装置２０自身が、該精算装置２０に関係する「特定の取引データ」が存在するか否かを判断してもよいし、他の装置（例えば、該精算装置２０に閉店処理を実行させる装置）が、該精算装置２０に関係る「特定の取引データ」が存在するか否かを判断してもよい。

（特定の取引データの承認）
上記では、特定取引一覧画面（図６（Ａ）参照）において「特定の取引データ」を承認する操作が行われる例を説明したが（具体的には、特定取引一覧画面の「承認」ボタンの操作に基づいて、承認応答情報が送信される例を説明したが）、他の画面において「特定の取引データ」を承認する操作が行われるようにしてもよい。例えば、特定取引一覧画面に代えて又は加えて、閉店処理状況画面（図８参照）において、「特定の取引データ」を承認する操作が行われるようにしてもよい。一例として、図８に示した「承認省略」ボタンなどと同様、「承認」ボタンを配置してもよい。つまり、閉店処理状況画面に「承認」ボタンと「承認省略」ボタンとを配置するようにしてもよい。

なお、同一画面（例えば、閉店処理状況画面）に、「承認」ボタンと「承認省略」ボタンとを配置する構成においては、管理者でない者がログインしている場合には、「承認」ボタンの操作は無効とするか、「承認」ボタンを表示しないようにしてもよい。

上記では、登録装置１０において「特定の取引データ」を承認する操作が行われる例を説明したが（具体的には、特定取引一覧画面の「承認」ボタンの操作に基づいて、承認応答情報が送信される例を説明したが）、他の装置において「特定の取引データ」を承認する操作が行われるようにしてもよい。具体的には、登録装置１０に代えて又は加えて、監視装置４０において、「特定の取引データ」を承認する操作が行われるようにしてもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０における店員の操作に基づいて、当該監視装置４０から承認の要求元の装置に承認応答情報が送信されるようにしてもよい。

また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０において、「特定の取引データ」を承認する操作が行われるようにしてもよい。例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０における「特定の取引データ」の承認がなされるようにしてもよい（具体的には、精算装置２０において店員の操作があった場合には、他の装置から承認応答情報を受信した場合と同様の制御がなされるようにしてもよい）。また例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０とは異なる他の精算装置２０における「特定の取引データ」の承認がなされるようにしてもよい（具体的には、精算装置２０において店員の操作があった場合には、当該精算装置２０から他の精算装置２０に承認応答情報が送信されるようにしてもよい）。また例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０、及び、他の精算装置２０における「特定の取引データ」の承認がなされるようにしてもよい。

また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、管理者が使用するタブレットやノートパソコンやスマートフォンにおいて、「特定の取引データ」を承認する操作が行われるようにしてもよい（例えば、操作があった場合に承認応答情報が送信されるようにしてもよい）。

また、上記では、店員の操作に基づいて、「承認」の操作が可能な画面（例えば、「承認」を配置した特定取引一覧画面）が表示される例を説明したが、店員の操作がなくても「承認」の操作が可能な画面を表示してもよい。例えば、承認が必要な取引（特定の取引データ）が存在すると判断した場合や、他の装置２０が送信した承認要求情報を受信した場合に、「承認」の操作が可能な画面を自動的に表示してもよい。なお、承認が必要な取引（特定の取引データ）が存在すると判断した場合や、他の装置２０が送信した承認要求情報を受信した場合に、「承認」の操作が可能な画面を、直接、表示するのではなく、「承認」の操作が可能な画面に遷移するため操作を受け付ける画面やメッセージやボタンを自動的に表示してもよい。

（特定の取引データの承認の省略）
上記では、閉店処理状況画面（図８参照）において「特定の取引データ」の承認を省略する操作が行われる例を説明したが（具体的には、閉店処理状況画面の「承認省略」ボタンの操作に基づいて、承認省略情報が送信される例を説明したが）、他の画面において「特定の取引データ」の承認を省略する操作が行われるようにしてもよい。例えば、閉店処理状況画面に代えて又は加えて、特定取引一覧画面（図６（Ａ）参照）において、「特定の取引データ」の承認を省略する操作が行われるようにしてもよい。一例として、図６（Ａ）に示した「承認」ボタンなどと同様、「承認省略」ボタンを配置してもよい。つまり、特定取引一覧画面に「承認」ボタンと「承認省略」ボタンとを配置するようにしてもよい。

なお、上述したように、同一画面（例えば、特定取引一覧画面）に、「承認」ボタンと「承認省略」ボタンとを配置する構成においては、管理者でない者がログインしている場合には、「承認」ボタンの操作は無効とするか、「承認」ボタンを表示しないようにしてもよい。

上記では、登録装置１０において「特定の取引データ」の承認を省略する操作が行われる例を説明したが（具体的には、閉店処理状況画面の「承認省略」ボタンの操作に基づいて、承認省略情報が送信される例を説明したが）、他の装置において「特定の取引データ」の承認を省略する操作が行われるようにしてもよい。具体的には、登録装置１０に代えて又は加えて、監視装置４０において、「特定の取引データ」の承認を省略する操作が行われるようにしてもよい。例えば、登録装置１０に代えて又は加えて、監視装置４０における店員の操作に基づいて、当該監視装置４０から承認の要求元の装置に承認省略情報が送信されるようにしてもよい。

また、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０において、「特定の取引データ」の承認を省略する操作が行われるようにしてもよい。例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０における「特定の取引データ」の承認を省略できるようにしてもよい（具体的には、精算装置２０において店員の操作があった場合には、他の装置から承認省略情報を受信した場合と同様の制御がなされるようにしてもよい）。また例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０とは異なる他の精算装置２０における「特定の取引データ」の承認を省略できるようにしてもよい（具体的には、精算装置２０において店員の操作があった場合には、当該精算装置２０から他の精算装置２０に承認省略情報が送信されるようにしてもよい）。また例えば、登録装置１０や監視装置４０に代えて又は加えて、精算装置２０における店員の操作に基づいて、当該精算装置２０、及び、他の精算装置２０における「特定の取引データ」の承認を省略できるようにしてもよい。

また、登録装置１０や監視装置４０や精算装置２０に代えて又は加えて、管理者が使用するタブレットやノートパソコンやスマートフォンにおいて、「特定の取引データ」の承認を省略する操作が行われるようにしてもよい（例えば、操作があった場合に承認省略情報が送信されるようにしてもよい）。

また、上記では、店員の操作に基づいて、「承認」を省略する操作が可能な画面（例えば、「承認省略」を配置した閉店処理状況画面）が表示される例を説明したが、店員の操作がなくても「承認」を省略する操作が可能な画面を表示してもよい。例えば、承認が必要な取引（特定の取引データ）が存在する場合や、承認が必要な取引が存在しかつ所定時間経過しても承認がなされない場合や、承認省略要求情報（後述）を受信した場合に、「承認」を省略する操作が可能な画面を自動的に表示してもよい。なお、承認が必要な取引が存在する場合や、承認が必要な取引が存在しかつ所定時間経過しても承認がなされない場合や、承認省略要求情報を受信した場合に、「承認」を省略する操作が可能な画面を、直接、表示するのではなく、「承認」を省略する操作が可能な画面に遷移するため操作を受け付ける画面やメッセージやボタンを自動的に表示してもよい。

図９は、閉店処理に関わる動作の流れの一例を示すフローチャートである。具体的には、図９（Ａ）のフローチャートは、管理者である店員が、精算装置２０において当該精算装置２０の閉店処理の開始の操作を行った場合における、当該精算装置２０の動作の流れを示している。また、図９（Ｂ）のフローチャートは、図９（Ａ）のステップＳ１８０の処理に含まれる各処理の流れを示している。なお、図９のフローチャート（図１０～図１４のフローチャートも同様）において不承認については省略している。

ステップＳ１００：精算装置２０は、管理者から閉店処理を実行させる操作を受け付ける。
ステップＳ１１０：精算装置２０は、閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを判断する。つまり、精算装置２０は、閉店処理の対象となる取引データ（精算データ）のなかに、未承認（承認前）の「特定の取引データ」が存在するか否かを判断する。承認が必要な取引がある場合にはステップＳ１２０に進む。承認が必要な取引がない場合にはステップＳ１８０に進む。

ステップＳ１１０の処理では、精算装置２０は、「管理者承認状況」が存在する取引データ（つまり、「特定の取引データ」）であって、かつ、当該「管理者承認状況」の「承認状況区分」が「０（未承認）」である取引データについて、未承認の「特定の取引データ」であると判断してもよい。つまり、ステップＳ１１０の処理では、精算装置２０は、閉店処理の対象となる取引データのなかに、「管理者承認状況」が存在する取引データであって、かつ、当該「管理者承認状況」の「承認状況区分」が「０（未承認）」である取引データが存在するか否かを判断してもよい。

ステップＳ１２０：精算装置２０は、承認の操作を受付可能な承認用画面を表示する。なお、上述したように、精算装置２０は、承認が可能であればどのような画面やボタンを表示してもよいが、一例として、精算装置２０は、「承認」ボタンを配置した特定取引一覧画面（図６（Ａ）参照）を表示してもよい。そしてステップＳ１３０に進む。
ステップＳ１３０：精算装置２０は、承認用画面を介して、管理者から承認の操作があったか否かを判断する。承認の操作があった場合にはステップＳ１８０に進む。承認の操作がなかった場合にはステップＳ１３０に戻る。

ステップＳ１３０の処理では、精算装置２０は、承認が必要な取引データ（未承認の取引データ）が複数存在する場合には、承認が必要な取引データの全部について管理者から承認の操作があったか否かを判断する。そして、全部について承認の操作があった場合にはステップＳ１８０に進む。一方、少なくとも一部について承認の操作がなかった場合にはステップＳ１３０に戻る。つまり、ステップＳ１３０の処理では、未承認の取引データが最終的になくなった場合（全部について管理者による承認がなされた場合）に、ステップＳ１８０に進む。

また、精算装置２０は、ある取引データについて承認の操作があった場合には、当該取引データの管理者承認状況（図５（Ｄ）参照）を更新する。具体的には、精算装置２０は、「承認状況区分」を「０（未承認）」から「１（承認済）」に更新し、「確認日時」に承認した日時を入力し、「店員コード」に承認した管理者の店員コードを入力する。

ステップＳ１８０：精算装置２０は、閉店処理を実行する。具体的には、精算装置２０は、図９（Ｂ）に示したステップＳ１８１～Ｓ１８５の各処理（各工程）を実行する。

ステップＳ１８１：精算装置２０は、釣銭再精査を実行する。つまり、精算装置２０は、釣銭機２１２内の貨幣を再精査する。
ステップＳ１８２：精算装置２０は、実在高を確定させる。つまり、精算装置２０は、釣銭再精査の結果に基づいて、釣銭機２１２の実在高が確定させる。
ステップＳ１８３：精算装置２０は、残置金を確定させる。つまり、精算装置２０は、釣銭機２１２内の残置金額を調整し確定させる。
ステップＳ１８４：精算装置２０は、釣銭を回収させる。具体的には、精算装置２０は、例えば、店員（管理者含む）に対し、釣銭機２１２内の貨幣を回収すべき旨のメッセージを報知する。
ステップＳ１８５：精算装置２０は、レジ閉設処理を実行する。つまり、精算装置２０は、自装置の売上情報を例えばストアコントローラ３０に送信する。そして、図９（Ａ）及び図９（Ｂ）のフローチャートは終了する。

なお、ステップＳ１３０の処理の実行中（承認待ちの間）には、管理者による承認待ちの状況（状態）である旨を報知する。例えば、ステップＳ１３０の処理の実行中（承認待ちの間）に、当該精算装置２０、又は、他の装置（例えば、登録装置１０、監視装置４０、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォン等）において、閉店処理状況画面（図８参照）を表示している場合には、例えば、図８（精算機２欄参照）の「要承認取引有。管理者に確認しています…」などのように、管理者による承認待ちの状況である旨を報知する。

管理者による承認待ちの状況である旨を報知する方法（仕組み）としては、種々の方法が考えられるが、例えば、以下のようにしてもよい。精算装置２０は、処理の進行状況によって値を変化させる進行状況フラグ（例えば、０：閉店処理の開始指示無、１：閉店処理の開始指示有（取引データ確認中）、２：管理者承認待ち、３：釣銭再精査中、４：釣銭再精査済、５：実在高確定済、６：残置金確定済、７：釣銭回収待ち、８：釣銭回収済、９：レジ閉設処理済）を記憶（管理）する。例えば、精算装置２０は、ステップＳ１００の処理において進行状況フラグを「０：閉店処理の開始指示無」から「１：閉店処理の開始指示有（取引データ確認中）」に更新し、ステップＳ１３０の処理の実行中（承認待ちの間）には進行状況フラグを「１：閉店処理の開始指示有（取引データ確認中）」から「２：管理者承認待ち」に更新する。そして、当該精算装置２０、又は、他の装置は、進行状況フラグの値を参照し、値が「２：管理者承認待ち」であれば、管理者による承認待ちの状況である旨を報知してもよい。なお、当該精算装置２０に代えて又は加えてストアコントローラ３０や監視装置４０が進行状況フラグを記憶（管理）してもよい。また、進行状況フラグ等のフラグを用いるのではなく、進行状況が変化する都度、変化後の進行状況を通知することによって、管理者による承認待ちの状況である旨等を報知してもよい。

なお、閉店処理状況画面（図８参照）に代えて又は加えて、閉店処理状況画面とは異なる画面において、管理者による承認待ちの状況である旨を報知してもよい。また、現在表示中の画面にテロップ表示によって管理者による承認待ちの状況である旨を報知してもよい。また、現在表示中の画面に小画面（ポップアップ画面等）を重畳させて表示し、当該小画面にて管理者による承認待ちの状況である旨を報知してもよい。また、画面による報知に代えて又は加えて、音声（ブザー１１０、ブザー２１０）や発光（サインポール２１３）によって報知してもよい。

なお、ステップＳ１３０の処理の実行中（承認待ちの間）に管理者による承認待ちの状況である旨を報知するのと同様に、当該精算装置２０、又は、他の装置（例えば、登録装置１０、監視装置４０、店員（管理者含む）が使用するタブレットやノートパソコンやスマートフォン等）は、例えば閉店処理状況画面（図８参照）に例示したように、閉店処理の各処理（各工程）の進行状況を表示してもよい。

図１０は、閉店処理に関わる動作の流れの他の一例を示すフローチャートである。具体的には、左側のフローチャートは、非管理者である店員が、精算装置２０において当該精算装置２０の閉店処理の開始の操作を行った場合における、当該精算装置２０の動作の流れを示している。右側のフローチャートは、管理者が使用する他の装置（例えば、登録装置１０、監視装置４０、タブレット、ノートパソコン、スマートフォン等）における、動作の流れを示している。なお、便宜上、右側のフローチャートは、管理者が使用する登録装置１０の動作として説明する。

（左側のフローチャート）
ステップＳ２００：精算装置２０は、図９のステップＳ１００と同様、店員（非管理者）から閉店処理を実行させる操作を受け付ける。
ステップＳ２１０：精算装置２０は、図９のステップＳ１１０と同様、閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを判断する。承認が必要な取引がある場合にはステップＳ２１２に進む。承認が必要な取引がない場合にはステップＳ２８０に進む。

ステップＳ２１２：精算装置２０は、承認要求情報を送信する。具体的には、精算装置２０は、管理者が利用する装置として予め定めた装置や管理者がログインしている装置に、承認要求情報を送信する。なお、精算装置２０は、ＬＡＮ１１上の全部の装置に承認要求情報を送信してもよい（例えば、管理者が利用する装置は承認要求情報を受信し、他の装置は承認要求情報を無視するようにしてもよい）。また、精算装置２０は、直接、目的の装置（管理者が利用する装置）に承認要求情報を送信してもよいし、他の装置（例えば、ストアコントローラ３０等）を介して（経由して）、目的の装置に承認要求情報を送信してもよい。

（右側のフローチャート）
ステップＳ３２０：登録装置１０は、精算装置２０から送信された承認要求情報を受信した場合、承認の操作を受付可能な承認用画面を表示する。なお、登録装置１０は、承認が可能であればどのような画面やボタンを表示してもよいが、一例として、登録装置１０は、「承認」ボタンを配置した特定取引一覧画面（図６（Ａ）参照）を表示してもよい。そしてステップＳ１３０に進む。
ステップＳ３３０：登録装置１０は、承認用画面を介して、管理者から承認の操作があったか否かを判断する。承認の操作があった場合にはステップＳ３３２に進む。承認の操作がなかった場合にはステップＳ３３０に戻る。

なお、ステップＳ３３０の処理では、図９のステップＳ１３０と同様、登録装置１０は、承認が必要な取引データ（未承認の取引データ）が複数存在する場合には、承認が必要な取引データの全部について管理者から承認の操作があったか否かを判断してもよい。つまり、ステップＳ３３０の処理では、未承認の取引データがなくなった場合（全部について管理者による承認がなされた場合）にステップＳ３３２に進むようにしてもよい。

なお、上記とは異なるが、ステップＳ３３０の処理では、登録装置１０は、承認が必要な取引データ（未承認の取引データ）が複数存在する場合に、少なくとも一部について承認の操作があった場合にはステップＳ３３２に進むようにしてもよい。つまり、ステップＳ３３０の処理では、一部に未承認の取引データが残っている場合にもステップＳ３３２に進むようにしてもよい。

また、登録装置１０は、ある取引データについて承認の操作があった場合には、当該取引データの管理者承認状況を更新してもよい。具体的には、登録装置１０は、「承認状況区分」を「０（未承認）」から「１（承認済）」に更新し、「確認日時」に承認（又は更新）した日時を入力し、「店員コード」に承認した管理者の店員コードを入力してもよい。

ステップＳ３３２：登録装置１０は、承認応答情報を送信する。具体的には、登録装置１０は、承認要求情報の送信元の装置に、承認応答情報を送信する。なお、登録装置１０は、ＬＡＮ１１上の全部の装置に承認応答情報を送信してもよい（例えば、承認要求情報の送信元の装置は承認要求情報を受信し、他の装置は承認応答情報を無視するようにしてもよい）。また、登録装置１０は、直接、目的の装置（承認要求情報の送信元の装置）に承認応答情報を送信してもよいし、他の装置（例えば、ストアコントローラ３０等）を介して（経由して）、目的の装置に承認応答情報を送信してもよい。そして、図１０の右側のフローチャートは終了する。

なお、登録装置１０が送信する承認応答情報は、管理者が承認した特定の取引データを認識可能な情報（どの特定の取引データが管理者によって承認されたかを判断可能な情報）を含むものであってもよい。つまり、承認が必要な取引データが複数存在するような場合において、承認の要求側（精算装置２０）にて承認応答情報を参照すれば、管理者がどの特定の取引データを承認したか（あるいは、どの特定の取引データを承認していないか）を判断することができるようにしてもよい。なお、登録装置１０側において管理者承認状況（承認状況区分）を更新する態様では、承認の要求側（精算装置２０）にて承認応答情報を参照しなくても管理者承認状況（承認状況区分）を参照すれば、管理者がどの特定の取引データを承認したか（あるいは、どの特定の取引データを承認していないか）を判断することができる。

（左側のフローチャート）
ステップＳ２４０：精算装置２０は、承認の応答があったか否かを判断する。つまり、管理者が使用する登録装置１０から承認応答情報を受信したか否かを判断する。承認の応答があった場合にはステップＳ２８０に進む。承認の応答がなかった場合にはステップＳ２４２に進む。

なお、ステップＳ２４０の処理では、承認が必要な取引データが複数存在していた場合に、全部について管理者による承認がなされた旨の承認応答情報を受信した場合に、ステップＳ２８０に進む。すなわち、登録装置１０側（管理者側）が、全部ではなく一部について承認がなされた旨の承認応答情報を送信した場合（つまり、一部に未承認の取引データが残っている場合）には、ステップＳ２８０ではなくステップＳ２４２に進む。

また、精算装置２０は、いずれの特定の取引データが管理者によって承認されたかを識別可能な情報を含む承認応答情報を受信した場合には、承認応答情報によって示される取引データ（管理者によって承認された特定の取引データ）の管理者承認状況（承認状況区分）を更新してもよい。つまり、承認された特定の取引データの管理者承認状況（承認状況区分）については、登録装置１０が承認応答情報を送信したとき（ステップＳ３３０（ＹＥＳ）のとき）に更新するか、精算装置２０が承認応答情報を受信したとき（ステップＳ２４０（ＹＥＳ）のとき）に更新すればよい。

ステップＳ２４２：精算装置２０は、所定時間を経過したか否かを判断する。例えば、承認要求情報の送信（ステップＳ２１２）後の経過時間が、所定時間を経過したか否かを判断する。所定時間を経過した場合にはステップＳ２５０に進む。所定時間を経過していない場合にはステップＳ２４０に戻る。

ステップＳ２５０：精算装置２０は、承認を省略する操作を受付可能な承認省略用画面を表示する。なお、上述したように、精算装置２０は、承認を省略する操作が可能であればどのような画面やボタンを表示してもよいが、一例として、精算装置２０は、「承認省略」ボタンを配置した閉店処理状況画面（図８参照）を表示してもよい。そしてステップＳ２６０に進む。
ステップＳ２６０：精算装置２０は、承認省略用画面を介して、店員（非管理者）から承認を省略する操作があったか否かを判断する。承認を省略する操作があった場合にはステップＳ２８０に進む。承認を省略する操作がなかった場合にはステップＳ２４０に戻る。

なお、ステップＳ２６０の処理では、承認が必要な取引データ（未承認の取引データ）が複数存在する場合には、承認が必要な取引データが最終的になくなった場合（全部について、管理者による承認か、または、店員（非管理者）による承認省略がなされた場合）に、ステップＳ２８０に進む。

また、精算装置２０は、ある取引データについて承認を省略する操作があった場合には、当該取引データの管理者承認状況（図５（Ｄ）参照）を更新する。精算装置２０は、「承認状況区分」を「０（未承認）」から「２（承認省略）」に更新し、「確認日時」に承認を省略した日時を入力し、「店員コード」に承認を省略した店員（非管理者）の店員コードを入力する。

ステップＳ２８０：精算装置２０は、図９のステップＳ１８０と同様、閉店処理を実行する。そして、図１０のフローチャートは終了する。

図１１は、閉店処理に関わる動作の流れの他の一例を示すフローチャートである。具体的には、左側のフローチャートは、管理者である店員が、精算装置２０とは異なる他の装置（例えば、登録装置１０、監視装置４０、タブレット、ノートパソコン、スマートフォン等）において当該精算装置２０の閉店処理の開始の操作を行った場合における、当該他の装置の動作の流れを示している。右側のフローチャートは、上記他の装置からの指示による精算装置２０における、動作の流れを示している。なお、便宜上、左側のフローチャートは、管理者が使用する登録装置１０の動作として説明する。

（左側のフローチャート）
ステップＳ３００：登録装置１０は、管理者から閉店処理を実行させる操作を受け付ける。
ステップＳ３０２：登録装置１０は、閉店処理を実行させる精算装置２０に閉店処理開始制御情報を送信する。

（右側のフローチャート）
ステップＳ２１０：精算装置２０は、図９のステップＳ１１０と同様、閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを判断する。承認が必要な取引がある場合にはステップＳ２１２に進む。承認が必要な取引がない場合にはステップＳ２８０に進む。

ステップＳ２１２：精算装置２０は、承認要求情報を送信する。具体的には、精算装置２０は、閉店処理開始制御情報の送信元の装置（登録装置１０）に承認要求情報を送信する。なお、精算装置２０は、ＬＡＮ１１上の全部の装置に承認要求情報を送信してもよい（例えば、閉店処理開始制御情報の送信元の装置は承認要求情報を受信し、他の装置は承認要求情報を無視するようにしてもよい）。また、精算装置２０は、直接、目的の装置（閉店処理開始制御情報の送信元の装置）に承認要求情報を送信してもよいし、他の装置（例えば、ストアコントローラ３０等）を介して、目的の装置に承認要求情報を送信してもよい。

（左側のフローチャート）
ステップＳ３１４：登録装置１０は、承認要求情報を受信したか否かを判断する。換言すれば、管理者の承認が必要な取引があったか否かを判断する。承認要求情報を受信した場合にはステップＳ３２０に進む。承認要求情報を受信していない場合には、左側のフローチャートは終了する。

ステップＳ３２０：登録装置１０は、図９のステップＳ１２０と同様、承認用画面を表示する。そしてステップＳ３３０に進む。
ステップＳ３３０：登録装置１０は、図９のステップＳ１３０と同様、承認用画面を介して、管理者から承認の操作があったか否かを判断する。承認の操作があった場合にはステップＳ３３２に進む。承認の操作がなかった場合にはステップＳ３３０に戻る。

ステップＳ３３２：登録装置１０は、承認応答情報を送信する。そして、左側のフローチャートは終了する。

（右側のフローチャート）
ステップＳ２４０：精算装置２０は、図１０のステップＳ２４０と同様、承認の応答があったか否かを判断する。承認の応答があった場合にはステップＳ２８０に進む。承認の操作がなかった場合にはステップＳ２４２に進む。

ステップＳ２４２：精算装置２０は、図１０のステップＳ２４２と同様、所定時間を経過したか否かを判断する。所定時間を経過した場合にはステップＳ２５０に進む。所定時間を経過していない場合にはステップＳ２４０に戻る。

ステップＳ２５０：精算装置２０は、図１０のステップＳ２５０と同様、承認を省略する操作を受付可能な承認省略用画面を表示する。
ステップＳ２６０：精算装置２０は、図１０のステップＳ２６０と同様、承認省略用画面を介して、店員（非管理者）から承認を省略する操作があったか否かを判断する。承認を省略する操作があった場合にはステップＳ２８０に進む。承認を省略する操作がなかった場合にはステップＳ２４０に戻る。

ステップＳ２８０：精算装置２０は、図１０のステップＳ２８０と同様、閉店処理を実行する。そして、右側のフローチャートは終了する。

なお、図１１の処理では、精算装置２０において、店員（非管理者）から承認を省略する操作を受け付けているが（ステップＳ２５０、Ｓ２６０）、当該精算装置２０には店員（非管理者）がいない場合があるため、店員（非管理者）が使用する他の装置（例えば、登録装置１０、監視装置４０、タブレット、ノートパソコン、スマートフォン等）に、特定の取引データの承認の省略を求める承認省略要求情報（図１３のステップＳ２５１参照）を送信し、当該他の装置において、店員（非管理者）から承認を省略する操作を受け付ける（承認省略情報を受信する）ようにしてもよい。もっとも、管理者による承認の操作があれば（図１１のステップＳ２４０参照）、店員（非管理者）による承認を省略する旨の操作は不要である。

図１２は、図１１に示したフローチャートと同様の場面における変形例である。なお、便宜上、左側のフローチャートは、管理者が使用する登録装置１０の動作として説明する。

（左側のフローチャート）
ステップＳ３００：登録装置１０は、図１１のステップＳ３００と同様、管理者から閉店処理を実行させる操作を受け付ける。
ステップＳ３１０：登録装置１０は、閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを判断する。つまり、先の図１１に示した例では閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを精算装置２０側で判断しているが、図１２に示した例では精算装置２０に代えて登録装置１０側で判断している。承認が必要な取引がある場合にはステップＳ３２０に進む。承認が必要な取引がない場合にはステップＳ３７２に進む。

ステップＳ３２０：登録装置１０は、図１１のステップＳ３２０と同様、承認用画面を表示する。そしてステップＳ３３０に進む。
ステップＳ３３０：登録装置１０は、図１１のステップＳ３３０と同様、承認用画面を介して、管理者から承認の操作があったか否かを判断する。承認の操作があった場合にはステップＳ３７２に進む。承認の操作がなかった場合にはステップＳ３３０に戻る。

ステップＳ３７２：登録装置１０は、閉店処理開始制御情報を送信する。つまり、先の図１１に示した例では、管理者から閉店処理を実行させる操作を受け付けた後に（図１１のステップＳ３０２）、閉店処理開始制御情報を送信しているが、図１２に示した例では、閉店処理の対象となる取引のなかに承認が必要な取引が存在しないと判断した後か（図１２のステップＳ３１０（Ｎｏ）、閉店処理の対象となる取引のなかに承認が必要な取引が存在していたが全て承認された後に（ステップＳ３３０（Ｙｅｓ））、閉店処理開始制御情報を送信している。そして、左側のフローチャートは終了する。

（右側のフローチャート）
ステップＳ２８０：精算装置２０は、図１１のステップＳ２８０と同様、閉店処理を実行する。そして、右側のフローチャートは終了する。

図１３は、閉店処理に関わる動作の流れの他の一例を示すフローチャートである。具体的には、左側（上段、下段）のフローチャートは、非管理者である店員が、精算装置２０とは異なる他の装置（例えば、登録装置１０、監視装置４０、タブレット、ノートパソコン、スマートフォン等）において当該精算装置２０の閉店処理の開始の操作を行った場合における、当該他の装置の動作の流れを示している。左側（中段）のフローチャートは、管理者である店員が使用する他の装置（例えば、登録装置１０、監視装置４０、タブレット、ノートパソコン、スマートフォン等）における、動作の流れを示している。右側のフローチャートは、非管理者である店員が使用する上記他の装置からの指示による精算装置２０における、動作の流れを示している。なお、便宜上、左側(上段、中段、下段)のフローチャートは、登録装置１０の動作として説明する。

（左側（上段）のフローチャート）
ステップＳ４００：登録装置１０は、図１１のステップＳ３００と同様、店員（非管理者）から閉店処理を実行させる操作を受け付ける。
ステップＳ４０２：登録装置１０は、図１１のステップＳ３０２と同様、閉店処理を実行させる精算装置２０に閉店処理開始制御情報を送信する。そして、左側（上段）のフローチャートは終了する。

（右側のフローチャート）
ステップＳ２１０：精算装置２０は、図１１のステップＳ２１０と同様、閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを判断する。承認が必要な取引がある場合にはステップＳ２１２に進む。承認が必要な取引がない場合にはステップＳ２８０に進む。

ステップＳ２１２：精算装置２０は、図１１のステップＳ２１２と同様、承認要求情報を送信する。

（左側（中段）のフローチャート）
ステップＳ３２０：登録装置１０は、精算装置２０から送信された承認要求情報を受信した場合、図１１のステップＳ３２０と同様、承認用画面を表示する。そしてステップＳ３３０に進む。
ステップＳ３３０：登録装置１０は、図１１のステップＳ３３０と同様、承認用画面を介して、管理者から承認の操作があったか否かを判断する。承認の操作があった場合にはステップＳ３３２に進む。承認の操作がなかった場合にはステップＳ３３０に戻る。

ステップＳ３３２：登録装置１０は、図１１のステップＳ３３２と同様、承認応答情報を送信する。そして、左側（中段）のフローチャートは終了する。

（右側のフローチャート）
ステップＳ２４０：精算装置２０は、図１１のステップＳ２４０と同様、承認の応答があったか否かを判断する。承認の応答があった場合にはステップＳ２８０に進む。承認の操作がなかった場合にはステップＳ２４２に進む。

ステップＳ２４２：精算装置２０は、図１１のステップＳ２４０と同様、所定時間を経過したか否かを判断する。所定時間を経過した場合にはステップＳ２５１に進む。所定時間を経過していない場合にはステップＳ２４０に戻る。

ステップＳ２５１：精算装置２０は、特定の取引データの承認の省略を求める承認省略要求情報を送信する。なお、精算装置２０は、直接、目的の装置（非管理者が利用する装置）に承認省略要求情報を送信してもよいし、他の装置（例えば、ストアコントローラ３０等）を介して（経由して）、目的の装置に承認省略要求情報を送信してもよい。

（左側（下段）のフローチャート）
ステップＳ４５０：登録装置１０は、精算装置２０から送信された承認省略要求情報を受信した場合、特定の取引データの承認の省略を求める承認省略用画面を表示する。そしてステップＳ４６０に進む。
ステップＳ４６０：登録装置１０は、図１０のステップＳ２６０と同様、承認省略用画面を介して、店員（非管理者）から承認を省略する操作があったか否かを判断する。承認を省略する操作があった場合にはステップＳ４６２に進む。承認を省略する操作がなかった場合にはステップＳ４６０に戻る。

ステップＳ４６２：登録装置１０は、管理者の承認が省略された旨の承認省略情報を送信する。そして、左側（下段）のフローチャートは終了する。

（右側のフローチャート）
ステップＳ２６１：精算装置２０は、店員（非管理者）から承認を省略する応答があったか否かを判断する。つまり、承認省略情報を受信したか否かを判断する。承認を省略する応答があった場合にはステップＳ２８０に進む。承認を省略する応答がなかった場合にはステップＳ２４０に戻る。

ステップＳ２８０：精算装置２０は、図１１のステップＳ２８０と同様、閉店処理を実行する。そして、右側のフローチャートは終了する。

図１４は、図１３に示したフローチャートと同様の場面における変形例である。なお、便宜上、左側のフローチャートは、非管理者が使用する登録装置１０の動作として説明する。また、右側（上段）のフローチャートは、管理者が使用する登録装置１０の動作として説明する。

（左側のフローチャート）
ステップＳ４００：登録装置１０は、図１３のステップＳ４００と同様、店員（非管理者）から閉店処理を実行させる操作を受け付ける。
ステップＳ４１０：登録装置１０は、閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを判断する。つまり、先の図１３に示した例では閉店処理の対象となる取引のなかに承認が必要な取引があるか否かを精算装置２０側で判断しているが、図１４に示した例では精算装置２０に代えて登録装置１０側で判断している。承認が必要な取引がある場合にはステップＳ４１２に進む。承認が必要な取引がない場合にはステップＳ４７２に進む。
ステップＳ４１２：登録装置１０は、承認要求情報を送信する。

（右側（上段）のフローチャート）
ステップＳ３２０：登録装置１０（管理者が利用する登録装置１０）は、他の登録装置１０（非管理者が利用する登録装置１０）から送信された承認要求情報を受信した場合、図１３のステップＳ３２０と同様、承認用画面を表示する。そしてステップＳ３３０に進む。
ステップＳ３３０：登録装置１０は、図１３のステップＳ３３０と同様、承認用画面を介して、管理者から承認の操作があったか否かを判断する。承認の操作があった場合にはステップＳ３３２に進む。承認の操作がなかった場合にはステップＳ３３０に戻る。

ステップＳ３３２：登録装置１０は、図１３のステップＳ３３２と同様、承認応答情報を送信する。そして、右側（上段）のフローチャートは終了する。

（左側のフローチャート）
ステップＳ４４０：登録装置１０は、承認の応答があったか否かを判断する。承認の応答があった場合にはステップＳ４７２に進む。承認の操作がなかった場合にはステップＳ４４２に進む。

ステップＳ４４２：登録装置１０は、所定時間を経過したか否かを判断する。所定時間を経過した場合にはステップＳ４５０に進む。所定時間を経過していない場合にはステップＳ４４０に戻る。
ステップＳ４５０：登録装置１０は、承認省略用画面を表示する。そしてステップＳ４６０に進む。
ステップＳ４６０：登録装置１０は、承認省略用画面を介して、店員（非管理者）から承認を省略する操作があったか否かを判断する。承認を省略する操作があった場合にはステップＳ４７２に進む。承認を省略する操作がなかった場合にはステップＳ４４０に戻る。

ステップＳ４７２：登録装置１０は、閉店処理開始制御情報を送信する。そして、左側のフローチャートは終了する。

（右側（下段）のフローチャート）
ステップＳ２８０：精算装置２０は、閉店処理を実行する。そして、右側（下段）のフローチャートは終了する。

図１５は、他の画面例である。図１５（Ａ）は、閉店処理を実行する精算装置（精算機）２０を指定するための機器指定画面の一例である。機器指定画面は、所定の操作に基づいて、各種装置（登録装置１０、精算装置２０、監視装置４０、タブレット、スマートフォン、パーソナルコンピュータ等）において表示可能（なお、表示に際し、権限を設けるようにしてもよい）である。

図１５（Ａ）に示す例では、精算機２について、特定の取引データ（管理者の承認が必要な取引データ）が存在する旨のメッセージ「管理者承認取引有」が表示されている（符号Ａ）。これにより、閉店処理を開始する精算装置２０を指定する時点において、いずれの精算装置２０について、管理者の承認が必要であるか（管理者の承認が必要な取引データがあるか）を認識することができる。

図１５（Ａ）の表示（後述する図１５（Ｂ）の表示も同様）がなされる方法（仕組み）としては、種々の方法が考えられるが、例えば、以下のようにしてもよい。精算装置２０は、特定の取引データ（精算データ）の有無によって値を変化させる特定取引有無フラグ（例えば、０：無（初期値）、１：有）を記憶（管理）する。精算装置２０は、特定の取引データを生成したときに特定取引有無フラグを「０：無」から「１：有」に更新する（なお、既に「１：有」の場合には「１：有」を維持し、閉店処理の終了時に「０：無」に初期化する）。一方、機器指定画面を表示する各種装置は、機器指定画面を表示させる際に、特定取引有無フラグが「１：有」である精算装置２０について、特定の取引データ（承認が必要な取引データ）が存在する旨のメッセージを表示する。また、特定取引有無フラグを用いるのではなく、管理者承認状況（承認状況区分）を用いて、特定の取引データが存在する旨のメッセージを表示してもよい。

なお、特定の取引データが存在する旨のメッセージに代えて又は加えて特定の取引データが存在する旨の記号、図柄等を表示してもよいし、特定の取引データが存在する旨を色（例えば、レジ名称の色）にて表現してもよい。また、特定の取引データが存在する旨に代えて又は加えて、特定の取引データの数を表示してもよいし、特定の取引データの数に応じた数（例えば、実際の数に基づく概数、実際の数に応じた図柄等）を表示してもよい。図１５（Ｂ）における表示も同様である。

なお、特定の取引データが存在する旨の表示領域（符号Ａ）を操作（タッチ）可能とし、当該表示領域が操作された場合に、特定の取引データの詳細を表示（例えば、図６（Ａ）の特定取引一覧を表示）してもよい。

なお、図１５（Ａ）では、特定の取引データの有無等（有無、内容等）が、閉店処理を開始する精算装置２０を指定する時点に（閉店処理を開始する精算装置２０を指定する機器指定画面において）表示される旨を説明したが、指定された精算装置２０において閉店処理を開始させる時点において表示されるようにしてもよい。つまり、例えば、閉店処理を開始する精算装置２０を指定する画面（例えば、図１５（Ａ）の機器指定画面）において１以上の精算装置２０を指定して実行ボタンを操作した後に、当該指定した精算装置２０において閉店処理を実際に開始させる旨の最終的な確認画面（非図示）を表示するような場合に、精算装置２０を指定する画面（例えば、図１５（Ａ）の機器指定画面）において特定の取引データの有無等を表示することに代えて又は加えて、上述した最終的な確認画面（非図示）において特定の取引データの有無等を表示するようにしてもよい。すなわち、閉店処理を開始する精算装置２０の指定に際し、特定の取引データの有無等が表示されるようになっていればよい。

図１５（Ｂ）は、登録装置１０に表示される登録画面の一例である。なお、図１５（Ｂ）の登録画面は、登録装置１０ａにおいて表示されるものであり、当該登録装置１０ａの登録データの送信先（通常の送信先）は、精算装置２０ａ（２０１レジ）又は精算装置２０ｂ（２０２レジ）の何れかであるものとする。

図１５（Ｂ）において、画面右下の送信ボタンＢＴ１１は、精算装置２０ａに登録データを送信する際（精算処理を実行する精算装置２０として精算装置２０ａを指定する際）に操作（タッチ）するボタンである。送信ボタンＢＴ１２は、精算装置２０ｂに登録データを送信する際（精算処理を実行する精算装置２０として精算装置２０ｂを指定する際）に操作（タッチ）するボタンである。送信ボタンＢＴ１５は、お会計券を印字、発行する際に操作（タッチ）するボタンである。なお、お会計券とは、精算処理を開始する精算装置２０において読み取らせる紙媒体であって、読み取らせることによって精算処理が可能となるコード情報（例えば、買上商品の登録情報を２次元コード化した２次元コード、又は、買上商品の登録情報を特定するための取引番号等をコード化したバーコード等）等を印刷した紙媒体である。

図１５（Ｂ）において、画面左下の状況ボタンＢＴ０１は、精算装置２０ａの状況（状態）に関するボタンである。状況ボタンＢＴ０１の上面には、当該精算装置２０ａが釣銭ニアエンドになっている旨の文言「釣銭ニアエンド」が表示されている。また、状況ボタンＢＴ０１を操作（タッチ）した場合には、釣銭ニアエンドに関する詳細情報（例えば、どの貨幣がどの位のニアエンドの状況になるか等を認識可能な情報）を示した画面（非図示）が表示される。

図１５（Ｂ）において、画面左下の状況ボタンＢＴ０２は、精算装置２０ｂの状況（状態）に関するボタンである。当該状況ボタンＢＴ０２が操作された場合には、特定の取引データの詳細を表示（例えば、図６（Ａ）の特定取引一覧を表示）が表示される。状況ボタンＢＴ０２の上面には、当該精算装置２０ａについて、特定の取引データ（管理者の承認が必要な取引データ）が存在する旨のメッセージ「管理者承認取引有」が表示されている。これにより、閉店処理の開始前の時点（例えば、登録処理が行われているようなとき）において、いずれの精算装置２０について、管理者の承認が必要であるか（管理者の承認が必要な取引データがあるか）を認識することができる。

以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、発明の要旨を逸脱しない範囲の設計等も含まれる。

例えば、図４及び図５に示したデータ構成は一例であって、例えば、ポイント情報、クレジット決済等の決済情報等を含むものであってもよい。

また、図５（Ｄ）に示した例では、管理者承認状況は、承認状況区分、確認日時、店員コードを有するが、管理者承認状況は、上記に加えて、管理者承認状況は、他の情報（例えば、承認（又は、承認の省略）を求めた装置の識別情報、承認（又は、承認の省略）を求めた日時、承認（又は、承認の省略）が行われた装置の識別情報のうち少なくとも１つ）を有するものであってもよい。

また、図４及び図５に示した例では、取引データ内に管理者承認状況が含まれるが（管理者承認状況は取引データの一要素であるが）、管理者承認状況は、取引データとは別のデータとして記憶（管理）されるもであってもよい。具体的には、取引番号と管理者承認状況とを含むデータを、取引データとは別に記憶（管理）するようにしてもよい。

また、上記実施形態では、特定の取引データ（承認が必要な取引データ）として、手入力による割引を含む取引データ、返品に係る取引データ、両替に係る取引データ等であると説明したが、特定の取引データは上記に限定されない。例えば、所定の金額（例えば、年間を通して１取引としては最大の買上金額の数倍の金額等）を超える取引データや、所定の数量（例えば、年間を通して１取引としては最大の買上数量の数倍の数量等）を超える取引データ等や、所定の消費ポイント数（例えば、年間を通して１取引としては最大の消費ポイント数の数倍の消費ポイント数）を超える取引データ等を、特定の取引データとしてもよい。

なお、管理者が関与（操作）した取引の取引データは、特定の取引データから除外してもよい。例えば、管理者の手入力による割引を含む取引データ、管理者による返品に係る取引データ、管理者が登録時に操作した両替に係る取引データ等は、特定の取引データから除外してもよい。

また、上記実施形態では、特定の取引データを承認するのは管理者とし、特定の取引データの承認を省略するのは非管理者としていたが、管理者は、特定の取引データの承認に加え、特定の取引データの承認を省略することもできるようにしてもよい。

また、上記実施形態では、特定の取引データの承認を省略する操作が可能になるのは、所定時間の経過後であったが、直ちに（例えば承認要求情報の送信のタイミングから）、特定の取引データの承認を省略する操作を可能にしてもよい。

また、上記実施形態では、特定の取引データが承認された後と、特定の取引データの承認が省略された後とでは、両者は履歴上において区別しているものの（承認状況区分に記憶する値を異ならせているものの）、他の点において区別していない。しかしながら、両者を他の点においても区別するようにしてもよい。例えば、承認が省略されて閉店処理を実行する場合には、閉店処理の開始時、実行中、又は終了時に、承認が省略された特定の取引データを外部に出力（表示、送信、印刷）してもよい。例えば、管理者等が使用する装置（例えば、登録装置１０、監視装置４０、タブレット等）に承認が省略された特定の取引データを送信し、表示または印刷させてもよい。

また、上記実施形態では、承認が必要な特定の取引データが最終的になくなった場合（管理者による承認か、または、店員（非管理者）による承認省略がなされた場合）に、閉店処理（釣銭再精査、実在高確定、残置金確定、釣銭回収、レジ閉設処理）を開始している。つまり、上記実施形態では、特定の取引データの承認等（承認または承認省略）を待っている間は、閉店処理を開始しない。換言すれば、閉店処理の実行開始タイミングは、特定の取引データの承認等の終了タイミングよりも遅いタイミングである。しかしながら、特定の取引データの承認等と、閉店処理の実行とは、下記（１）～（３）のようにしてもよい。

（１）特定の取引データの承認等の開始→釣銭再精査の実行開始→特定の取引データの承認等の終了（又は、釣銭再精査の終了）
つまり、特定の取引データの承認等が終わる前に、閉店処理の最初の工程である釣銭再精査を先行して実行してもよい。
（２）釣銭再精査の実行開始→特定の取引データの承認等の開始→特定の取引データの承認等の終了（又は、釣銭再精査の終了）
つまり、先ずは閉店処理の最初の工程である釣銭再精査を実行し、釣銭再精査中に特定の取引データの承認等が開始してもよい。
（３）上記（１）（２）は、閉店処理の初めの方（閉店処理の最初の工程である釣銭再精査）において、特定の取引データの承認等を終わらせるものであるが、閉店処理全体が完了する前に（つまりレジ閉設処理が完了する迄の間に）、特定の取引データの承認等が終わるようにしてもよい。

つまり、図９～図１４のフローチャート等においては閉店処理の開始に先立って特定の取引データについて管理者に承認等を求める例を説明したが、閉店処理の実行中に閉店処理を一時中断し特定の取引データについて管理者に承認等を求めるようにしてもよい。

また、上記では、閉店処理と、管理者への承認等とを区別しているが、管理者への承認等を閉店処理の一部であると見做してもよい。つまり、例えば、図９（Ａ）及び図９（Ｂ）に示した処理全体を閉店処理と称してもよい。すなわち、閉店処理は、「釣銭再精査」、「実在高確定」、「残置金確定」、「釣銭回収」、「レジ閉設処理」に加え、「特定の取引データの承認等」から構成されるものであってもよい。なお、定義上の問題ではあるが、「釣銭再精査」以降に「特定の取引データの承認等」が行われることについて、管理者への承認等を閉店処理の一部と見做さないときには「閉店処理を中断して管理者への承認等を実行する」と言えるが、管理者への承認等を閉店処理の一部と見做すときには「閉店処理を中断して管理者への承認等を実行する」とは言えない。

なお、応答として不承認を設ける態様の場合、例えば、図６（Ａ）に示すように「承認」ボタンの近傍（例えば、「承認」ボタンと同一画面上に）に「不承認」ボタンを設けるようにしてもよい。承認と同様、不承認も、管理者に与えられた権限である。但し、承認の権限と不承認の権限とは全く同一でなくてもよい。例えば、承認は、承認／不承認を求めるような特殊な取引について処理を進行させるものであるため、承認の権限を不承認の権限よりも高い権限としてもよい（例えば、承認は店長のみ、不承認は店長を含む管理者としてもよい）。あるいは、不承認は、少なくとも現状のまま（現在の情報のまま）では処理を進行させないものであるため、不承認の権限を承認の権限よりも高い権限としてもよい（例えば、不承認は店長のみ、承認は店長を含む管理者としてもよい）。承認、不承認の権限については画面上から店長権限などにより設定できるようにしてもよい。

なお、不承認となった取引については、当該取引がなかったものとして閉店処理を実行してもよいし、当該取引内の情報等を修正して閉店処理を実行してもよい。不承認とした後に、当該取引をどのように処理するか（なかったものとして処理するか、修正するか等）をボタン等により選択させるようにしてもよい。

また、不承認が評価の対象になるようにしてもよい。例えば、不承認とされた取引を担当者（登録時の担当者等）別に集計し、不承認とされた取引を行った担当者の人事考課に反映できるようにしてもよい（少なくとも参考のために確認可能であればよい）。なお、集計の一例は、担当者別被不承認取引件数、担当者別被不承認取引件数、担当者別被不承認取引割合（全取引に対する割合、承認／不承認の割合）、担当者別被不承認金額等を算出するものであってもよい。また、複数の店舗がある場合には、担当者別に代えて又は加えて店舗別に集計し、各店舗の責任者（人事担当者等）の人事考課に反映できるようにしてもよい。但し、不承認者が上記責任者でもある場合には、不承認の応答に対するブレーキにならないように不承認と応答とすべき場合に承認と応答した場合に比べ軽度のマイナス査定になるようにしてもよい。

なお、上述の評価に関する内容は、不承認の履歴情報を活用した例であるが、不承認の履歴情報は、他の用途に用いてもよい。例えば、不承認の履歴情報に基づいて特別の処理を実行するようにしてもよい。具体的には、過去（入社迄遡って現在以前に、又は、過去所定（設定）期間内に）、所定回数（１回以上の設定回数）、不承認とされた取引の担当者であった者（特定担当者）による「特定の取引」を禁止してもよい。なお、「特定の取引」とは、権限者による確認（承認）が必要な取引（図５、図６等に示した手入力による割引を含む取引、返品に係る取引、両替に係る取引等）である。なお、当該禁止は、特定担当者以外（必ずしも管理者でなくてもよい）による確認（代理）の操作（ログイン後のＯＫキー押下等）によって解除され、「特定の取引」が行われるようにしてもよい。管理者以外の者による確認の操作によって「特定の取引」の禁止が解除され、「特定の取引」が行われた場合には、管理者は関与していないものの少なくとも２名が関与しているため（相互の監視がなされているため）、処理の効率化の観点から閉店処理時における管理者の承認を行わないようにしてもよい（例えば、「特定の取引」ではないものとして取り扱ってもよいし、「特定の取引」であるが、承認済として取り扱ってもよい）。

あるいは、特定担当者による「特定の取引」を禁止迄はしないものの、特定担当者による「特定の取引」については、閉店処理の際ではなく当該取引の時点において、管理者の承認が必要になるようにしてもよいし、特定担当者以外（必ずしも管理者でなくてもよい）による確認の操作が必要になるようにしてもよい。取引の時点において管理者以外の者による確認の操作が行われた場合には、上述の管理者以外の者による解除の場合と同様、管理者は関与していないものの少なくとも２名が関与しているため、閉店処理時における管理者の承認を行わないようにしてもよい。

以下、付記１～付記７を開示する。
（付記１）
権限者（例えば、店長等の管理者）による確認（承認）が必要な確認必要取引（例えば、「特定の取引」）か否かを判別する判別手段と、
前記確認必要取引について権限者による確認を要求する確認要求手段と
を備え、
前記確認要求手段は、
前記判別手段によって判定された前記確認必要取引について、閉店処理において、権限者による確認を要求することを特徴とする商品データ処理装置（例えば、登録装置、精算装置、監視装置、タブレット等）。
上記によれば、閉店処理において権限者に確認を要求するため、権限者の負担が軽減する。

（付記２）
権限者による確認が必要な確認必要取引か否かを判別する判別手段と、
前記確認必要取引について権限者による確認を要求する確認要求手段と、
閉店処理の実行を制御する閉店処理制御手段と、
を備え、
前記閉店処理制御手段は、
前記確認要求手段が、前記判別手段によって判定された前記確認必要取引について権限者による確認を要求した後に、閉店処理の実行を制御することを特徴とする商品データ処理装置。
上記によれば、好適に（権限者による確認の要求後の取引を用いて）、閉店処理を実行することができる。

（付記３）
前記確認要求手段は、
前記確認必要取引について権限者による確認を要求した後に、前記確認必要取引について確認した旨の応答を受付可能であり、
前記閉店処理制御手段は、
前記確認要求手段が、前記確認必要取引について確認した旨の応答を受け付けた後に、閉店処理の実行を制御することを特徴とする付記２に記載の商品データ処理装置。
上記によれば、より好適に（権限者による確認がなされた取引を用いて）、閉店処理を実行することができる。

（付記４）
前記閉店処理制御手段は、
前記確認要求手段が、前記確認必要取引について確認した旨の応答を受け付けなかった場合であっても、所定の入力（例えば「承認省略」の操作）があった場合には、閉店処理の実行を制御することを特徴とする付記３に記載の商品データ処理装置。
上記によれば、必要に応じて迅速に（権限者による確認を待つことなく、柔軟に）、閉店処理を実行することができる。

（付記５）
権限者による確認が必要な取引は、
置数入力による値引き操作、返品に係る操作、両替に係る操作のうちの少なくとも１つの操作がなされた取引であることを特徴とする付記１乃至付記４の何れかに記載の商品データ処理装置。
上記によれば、置数入力による値引き操作などについて、的確に、管理者の確認をとることができる。

（付記６）
前記確認要求手段は、
他装置に確認用の画面を表示させるための情報を送信する（例えば、図９において承認要求情報を送信すれば承認用画面が表示される。つまり、図９では、承認用画面を表示させるための承認要求情報を送信する）ことを特徴とする付記１乃至付記５の何れかに記載の商品データ処理装置。
上記によれば、他装置において簡便に確認することができる。

（付記７）
商品データ処理装置としてコンピュータを機能させるプログラムであって、
前記コンピュータを、
権限者による確認が必要な確認必要取引か否かを判別する判別手段、
前記確認必要取引について権限者による確認を要求する確認要求手段
として機能させ、
前記確認要求手段は、
前記判別手段によって判定された前記確認必要取引について、閉店処理において、権限者による確認を要求することを特徴とするプログラム。

なお、上述のＰＯＳシステム１、登録装置１０、精算装置２０、監視装置４０などとしての機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより上述のＰＯＳシステム１などとしての処理を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ－ＲＯＭ等の非一過性の記録媒体であってもよい。

また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部または外部に設けられた記録媒体も含まれる。配信サーバの記録媒体に記憶されるプログラムのコードは、端末装置で実行可能な形式のプログラムのコードと異なるものでもよい。すなわち、配信サーバからダウンロードされて端末装置で実行可能な形でインストールができるものであれば、配信サーバで記憶される形式は問わない。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に端末装置で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

１…ＰＯＳシステム、１０…登録装置、２０…精算装置、３０…ストアコントローラ、４０…監視装置、１０１…ＣＰＵ、１０２…記憶部、１０３…ＲＡＭ、１０４…スキャナ部、１０５…店員用表示部、１０６…客用表示部、１０７…ハードディスク、１０８…キー操作部、１０９…通信部、１１０…ブザー、１１１…印刷部、２０１…ＣＰＵ、２０２…記憶部、２０３…ＲＡＭ、２０４…スキャナ部、２０５…表示部、２０７…ハードディスク、２０９…通信部、２１０…ブザー、２１１…印刷部、２１２…釣銭機、２１３…サインポール

Claims (4)

1. 客が購入する商品を店員が操作して登録処理を実行する登録装置と前記商品の登録データに基づいて客が自ら操作して精算処理を実行する精算装置とを含むシステムにおける登録装置であって、
   商品を登録する登録画面を表示する表示手段と、
   前記精算装置に閉店処理を実行させる実行指示操作を受け付ける操作受付手段と、
   前記閉店処理において処理される取引のなかに権限者による確認が必要な確認必要取引が存在するか否かを判定する判定手段と、
   前記操作受付手段によって前記実行指示操作を受け付けた後に、前記判定手段によって存在すると判定された前記確認必要取引について、権限者による確認を要求する確認要求手段と
   を備え、
   前記表示手段は、
   前記登録画面において前記閉店処理において処理される取引のなかに前記確認必要取引が存在する旨を表示可能である
   ことを特徴とする登録装置。
2. 客が購入する商品を店員が操作して登録処理を実行する登録装置と前記商品の登録データに基づいて客が自ら操作して精算処理を実行する精算装置とを含むシステムであって、
   前記登録装置は、
   商品を登録する登録画面を表示する表示手段と、
   前記精算装置に閉店処理を実行させる実行指示操作を受け付ける操作受付手段と、
   前記閉店処理において処理される取引のなかに権限者による確認が必要な確認必要取引が存在するか否かを判定する判定手段と、
   前記操作受付手段によって前記実行指示操作を受け付けた後に、前記判定手段によって存在すると判定された前記確認必要取引について、権限者による確認を要求する確認要求手段と、
   前記閉店処理の実行を制御する制御情報を送信することにより前記閉店処理の実行を制御する閉店処理制御手段と、
   を備え、
   前記精算装置は、
   前記閉店処理制御手段によって送信された前記制御情報に基づいて前記閉店処理を実行する閉店処理実行手段
   を備え、
   前記表示手段は、
   前記登録画面において前記閉店処理において処理される取引のなかに前記確認必要取引が存在する旨を表示可能であり、
   前記確認要求手段は、
   前記確認必要取引について権限者による確認を要求した後に前記確認必要取引について確認した旨の応答を受付可能であり、
   前記閉店処理制御手段は、
   前記確認要求手段が前記確認必要取引について確認した旨の応答を受け付けた後に前記制御情報を送信する
   ことを特徴とするシステム。
3. 客が購入する商品を店員が操作して登録処理を実行する登録装置と前記商品の登録データに基づいて客が自ら操作して精算処理を実行する精算装置とを含むシステムにおける登録装置としてコンピュータを機能させるプログラムであって、
   前記コンピュータを、
   商品を登録する登録画面を表示する表示手段、
   前記精算装置に閉店処理を実行させる実行指示操作を受け付ける操作受付手段、
   前記閉店処理において処理される取引のなかに権限者による確認が必要な確認必要取引が存在するか否かを判定する判定手段、
   前記操作受付手段によって前記実行指示操作を受け付けた後に、前記判定手段によって存在すると判定された前記確認必要取引について、権限者による確認を要求する確認要求手段
   として機能させ、
   前記表示手段は、
   前記登録画面において前記閉店処理において処理される取引のなかに前記確認必要取引が存在する旨を表示可能である
   ことを特徴とするプログラム。
4. 客が購入する商品を店員が操作して登録処理を実行する登録装置と前記商品の登録データに基づいて客が自ら操作して精算処理を実行する精算装置とを含むシステムにおける前記登録装置として第１のコンピュータを機能させ、前記精算装置として第２のコンピュータを機能させるプログラムであって、
   前記第１のコンピュータを、
   商品を登録する登録画面を表示する表示手段、
   前記第２のコンピュータに閉店処理を実行させる実行指示操作を受け付ける操作受付手段、
   前記閉店処理において処理される取引のなかに権限者による確認が必要な確認必要取引が存在するか否かを判定する判定手段、
   前記操作受付手段によって前記実行指示操作を受け付けた後に、前記判定手段によって存在すると判定された前記確認必要取引について、権限者による確認を要求する確認要求手段、
   前記閉店処理の実行を制御する制御情報を送信することにより前記閉店処理の実行を制御する閉店処理制御手段、
   として機能させ、
   前記第２のコンピュータを、
   前記閉店処理制御手段によって送信された前記制御情報に基づいて前記閉店処理を実行する閉店処理実行手段
   として機能させ、
   前記表示手段は、
   前記登録画面において前記閉店処理において処理される取引のなかに前記確認必要取引が存在する旨を表示可能であり、
   前記確認要求手段は、
   前記確認必要取引について権限者による確認を要求した後に前記確認必要取引について確認した旨の応答を受付可能であり、
   前記閉店処理制御手段は、
   前記確認要求手段が前記確認必要取引について確認した旨の応答を受け付けた後に前記制御情報を送信する
   ことを特徴とするプログラム。

Images