JP6035275B2 - 商品販売データ処理装置およびその制御プログラム - Google Patents

Description

本発明の実施形態は、商品取引の決済で使用される商品販売データ処理装置およびプロ
グラムに関する。

店と顧客との間で一取引が行なわれると、例えば、ＰＯＳ（Ｐｏｉｎｔ−ｏｆ−ｓａｌｅｓ）端末等の商品販売データ処理装置にて、この一取引で売り上げた売上データを印字したレシート用紙が発行される。

ところで、近年、環境負荷の低減を図るために売上データが印字されたレシートを発行する際に、レシート用紙に取引データが開示されているインターネットのＵＲＬ情報を合わせて印字して、短縮したレシートを発行するＰＯＳ端末等はすでに知られている。

しかしながら、レシート用紙にインターネットのＵＲＬ等を印字する上記のＰＯＳ端末等は、常にＵＲＬが記載されたレシート用紙を発行するものであるため、例えば、一取引が少ない商品点数等で行なわれた場合、短いレシートの長さで発行できるにもかかわらず、ＵＲＬ等の情報をレシートに印字する必要があるため、余分にレシートを印字発行してしまうことがあった。

特開２０００−３０１５４号公報

このため、本発明の実施形態が解決しようとする課題は、レシートの節約を図るとともに取引の態様に応じて印字発行されるレシートの印字フォーマットを変更する商品販売データ処理装置およびプログラムを提供することである。

本実施形態の商品データ処理装置は、商品に対応付けられた商品コードを入力する入力部と、この入力部により入力された商品コードに基づいて一取引の合計金額を含む取引データを生成する生成手段と、この生成手段により生成された取引データをウェブサーバに送信する送信手段と、前記一取引で取引される商品の合計金額が予め定められた金額を超えているか否かを判定する判定手段と、前記合計金額が予め定められた金額を超えていると前記判定手段が判定した場合に、前記合計金額及び前記一取引の取引データが保管される前記ウェブサーバ上の開示先を示す情報を含めて、顧客に表示するためのレシートデータを生成する制御部と、を備える。

また、本実施形態のプログラムは、商品に対応付けられた商品コードを入力する入力部を備えた商品販売データ処理装置のコンピュータに、前記入力部により入力された商品コードに基づいて一取引の合計金額を含む取引データを生成する機能と、前記取引データを生成する機能により生成された取引データをウェブサーバに送信する機能と、前記一取引で取引される商品の合計金額が予め定められた金額を超えているか否かを判定する機能と、前記合計金額が予め定められた金額を超えていると前記判定する機能が判定した場合に、前記合計金額及び前記一取引の取引データが保管される前記ウェブサーバ上の開示先を示す情報を含めて、顧客に表示するためのレシートデータを生成する機能と、を実現させる。

本実施形態のレシート提供システムの全体構成を示すブロック図。 本実施形態のウェブサーバの構成を示す図。 第１の実施形態の商品販売データ処理の流れを示すフローチャート。 第１の実施形態のサーバが実行する処理の流れを示すフローチャート。 第１の実施形態のウェブサーバが実行するレシート情報の閲覧処理を示す図。 第１の実施形態の第１のレシートフォーマットで印字されたレシートを示す図。 第１の実施形態の第２のレシートフォーマットでウェブページ上に表示されるレシート情報を示す図。 第１の実施形態の第１のレシートフォーマットで印字されたレシートを示す図。 第１の実施形態のウェブサーバ上で表示されるレシート情報を示す図。 第１の実施形態の第１のレシートフォーマットで印字されたレシートを示す図。 第２の実施形態の商品販売データ処理の流れを示すフローチャート。 第２の実施形態のサーバが実行する処理の流れを示すフローチャート。 本実施形態のＰＯＳ端末のＨＤＤが記憶する支払種別マスタファイルのデータ構造を示す図 第２の実施形態の第３のレシートフォーマットで印字されたレシートを示す図。 第２の実施形態のウェブサーバ上で表示されるレシート情報を示す図。 第２の実施形態の第４のレシートフォーマットで印字されたレシートを示す図。 第２の実施形態のウェブサーバ上で表示されるレシート情報を示す図。

以下、添付図面を参照して、本発明の実施形態に係る商品販売データ処理装置を詳細に説明する。なお、本実施形態では、商品販売データ処理装置としてＰＯＳ端末を例として説明する。

（第１の実施形態）
第1の実施形態に於ける商品販売データ処理装置は、顧客が購入した商品の点数が予め定められた点数より多い場合又は／及び購入した商品の金額が予め定められた所定の金額よりも高い場合に、印字発行するレシートの印字フォーマットを変更する構成及びウェブサーバ上に詳細なレシートデータを開示する構成を有する。

図１はレシート提供システム１の全体構成を示すブロック図である。レシート提供システム１は、インターネット５０に接続されたウェブサーバ３０とＰＯＳ（Ｐｏｉｎｔ−Ｏｆ−Ｓａｌｅｓ）システム４０とを主体に構成される。

ＰＯＳシステム４０は、ＰＯＳ端末（商品販売データ処理装置）１０とストアコンピュータ（サーバ）２０とを有する。ＰＯＳ端末１０は、店舗のレジカウンタに複数台個別に設置される。ストアコンピュータ２０は、ＰＯＳ端末１０に例えばインターネット５０でデータ送受信可能にネットワーク接続される。

図１において、ＰＯＳ端末１０は、制御部本体としてＣＰＵ（Central Processing Unit）１０１が実装されている。このＣＰＵ１０１に、アドレスバス，データバス等のバスライン１０５を介して、ＲＯＭ（Read Only Memory）１０２及びＲＡＭ（Random AccessMemory）１０３のメモリ部、ＨＤＤ（Hard Disk Drive）１０４、後述する各入出力機器１０７〜１１２とのインターフェイス部（I/F）１０６、ストアコンピュータ２０との間のデータ通信を制御する通信コントローラ１１２等が接続される。

以下に、入出力機器の説明をする。プリンタ１０７は、所謂印字部であり、ＣＰＵ１１の制御により、１取引で販売された商品の品名，価格や合計金額等の取引明細データが印字されたレシートを発行する。

キーボード１０８は、外部からの入力を受け付ける入力部の一部であり、数値データを置数するための「００」および「０」〜「９」の置数キー、この置数キーによって置数された数値データがＰＬＵ（Price Look Up）コードであることを指令するＰＬＵキー、数値データが乗数であることを指令する×キー、数値データが割引率であることを指令する割引キー、数値データが値引額であることを指令する値引キー、数値データのクリア等を指令するクリアキー、１取引の小計出力を指令する小計キー、１取引の現金締めを指令する預／現計キー、販売商品をポイント計算から除外することを宣言する除外キー等を有する。

スキャナ１０９は、同様に入力部の一部であり、各商品に付されたバーコードを読取る。各商品には、その商品固有の商品コードを示すバーコードが付されている。スキャナ１０９は、商品識別データの入力手段として機能する。なお、例えば、バーコードが付されていない商品の商品コードは、ＰＬＵコードとしてキーボード１０８の置数キーとＰＬＵキーとにより入力することもできる。

カードリーダ１１０は、例えばポイントカードに記録された顧客コードを含むカードデータを読取る。

ディスプレイ１１１は、ＰＯＳ端末１０のオペレータに対し、スキャナにより取り込んだ一取引として販売される商品の品名，価格や合計金額等を表示する。また、客用表示器１１２は、この一取引の顧客に対してディスプレイ１１１と同様の情報を表示する。

また、ＰＯＳ端末１０は、ＨＤＤ１０４を有する。ＨＤＤ１０４は、例えば、商品マスタファイル１０４１、支払種別マスタファイル１０４２（図９に示す）を記憶する。商品マスタファイル１０４１は、商品毎に設定された商品識別データである固有の商品コードに、その部門コード、商品の名称（品名）やその商品一点あたりの価格である単価、が対応付けて記憶されている。

支払種別マスタファイル１０４２は、一取引の締め手段である例えば「現金」、「クレジット」、「電子マネー」のそれぞれに対応してレシートの印字フォーマットの態様及びデータ送信の有無が対応付けて定められている（図９参照）。例えば、「現金」による支払いにて一取引が締められた場合、発行されるレシートが、いずれの印字フォーマットで印字発行されるかが対応付けて定められている。

本実施の形態のＰＯＳ端末１０は、商品販売データ処理の実行に伴って、一取引毎に、後述するレシートデータがＣＰＵ１０１によって生成される。レシートデータには固有のレシートコードが含まれる。

「レシートコード」は、ＰＯＳ端末１０を識別する「ＰＯＳ端末コード」と一取引を識別する取引コードとの組み合わせで構成される。例えば、「ＰＯＳ端末コード」が「０１」であり、「取引コード」が「０００１」の場合、「レシートコード」は、「ＰＯＳ端末コード」と「取引コード」が組み合わされて「０１０００１」となる。なお、「取引コード」は一取引が行なわれる毎にＣＰＵ１０１によってインクリメントされる。つまり、次の一取引で生成される「レシートコード」は「０１０００２」となる。

図２は、ウェブサーバ３０を示す図である。ウェブサーバ３０は、一般的なサーバコンピュータの形態を有しており、例えば、インターネットサービスプロバイダのサーバルームなどに設置される。

図２に示すごとく、ウェブサーバ３０は、制御部本体としてＣＰＵ３０１が実装されている。このＣＰＵ３０１に、アドレスバス，データバス等のバスライン３０６を介して、ＲＯＭ３０２及びＲＡＭ３０３のメモリ部、ＨＤＤ３０４、インターネットに接続してサーバと外部機器との間のデータ通信を制御する通信コントローラ３０５が接続される。

ＲＯＭ３０２は、固定データを固定的に記憶する。ＲＡＭ３０３は、可変データを書き換え自在に記憶してワークエリアとして使用される。

ＨＤＤ３０４は、インターネット５０で用いられるウェブによる情報送信機能を有するウェブサーバソフトウェアが記憶される。また、ＨＤＤ３０４には、ウェブページのデータが記憶される。ＨＤＤ３０４に記憶されるウェブページのデータは所定の外部機器が有するブラウザ機能によって取得される。そして、ブラウザ機能によって所定の外部機器の表示部にウェブページが表示される。このような外部機器は、例えば、家庭用のパーソナルコンピュータや携帯電話などの通信端末等が想定される。

図３は、商品販売データ処理の流れを示すフローチャートである。図１および図２を参照して説明する。図３（a）に示すように、図１に示すＰＯＳ端末１０のＣＰＵ１０１は、キーボード１０８またはスキャナ１０９の入力手段を介して商品コードが入力されるまで待機する（Ａｃｔ３０１）。ＣＰＵ１０１は、商品コードが入力されたと判断すると（Ａｃｔ３０１のＹ）、入力された商品コードをＲＡＭ１０３に一時記憶する。そして、この一時記憶された商品コードに対応する商品情報をＨＤＤ１０４の商品マスタファイル１０４１から取得する（Ａｃｔ３０２）。

ＣＰＵ１０１は、取得した商品情報をＲＡＭ１０３に一時記憶する。そして、ＣＰＵ１０１は、キーボード１０８の仮締めキーである「小計キー」が押されるまで待機する（Ａｃｔ３０３）。例えばこの状態で、ＣＰＵ１０１は、仮締めキーである「小計キー」が押されることなく、スキャナ１０９から商品コードが入力されたことを検知すると（Ａｃｔ３０３のＮ）、Ａｃｔ３０１、Ａｃｔ３０２の処理に戻り、これらの処理を実行する。このＡｃｔ３０１からＡｃｔ３０３までの処理が入力部により入力された商品コードに基づいて一取引の取引データを生成する生成手段に相当する。

他方、Ａｃｔ３０３にて、ＣＰＵ１０１は、仮締めキーである「小計キー」が押されたと判断すると（Ａｃｔ３０３のＹ）、ＲＡＭ１０３に記憶されている単価等の金額を合計することにより一取引の決済金額（合計金額）を算出する（Ａｃｔ３０４）。基本的には、決済金額（合計金額）は各商品の単価の合計金額となる。なお、値引き金額が含まれている場合は、値引きされた金額が反映された形として決済金額、すなわち一取引の合計金額となる。

次に、ＣＰＵ１０１は、キーボード１０８の「預／現計」と表示された締めキーが押されるまで待機する（Ａｃｔ３０５）。ＣＰＵ１０１は、締めキーが押されたと判断すると（Ａｃｔ３０５のＹ）、今回の一取引における購入商品の合計点数が予め定められた所定点数よりも多いか否かを判断する（Ａｃｔ３０６）。このＡｃｔ３０６の処理は第1判定手段に相当する。なお、ここでの「予め定められた所定点数」とは、例えば、（１）同一の商品コードが割り当てられた同一商品を３点購入した場合、（２）異なる商品コードが割り当てられた商品を３点購入した場合である。いずれにおいても区別することなく、購入点数は、３点として取り扱っても良い。また、（１）の場合と（２）の場合とを区別してもよい。また、点数は、３点に限定されない。なお、本実施の形態では、（１）の場合を例に以降の説明を続ける。

Ａｃｔ３０６にて、ＣＰＵ１０１が予め定められた所定の点数より、顧客が購入した購入点数の方が多いと判断した場合（Ａｃｔ３０６のＹ）、レシートデータを生成して、この生成したレシートデータをウェブサーバ３０に送信する（Ａｃｔ３０７）。ここで、ウェブサーバ３０に送信されるレシートデータは、ＲＡＭ１０３に一時記憶されている例えば、全ての商品情報、決済金額、預かり金額、釣銭金額、取引日時を特定する現在時刻を含んだデータである。また、このレシートデータには、固有の「レシートコード」も含まれる。その後、ＣＰＵ１０１は、Ａｃｔ３０７にて送信したレシートデータに基づいて生成されたウェブページを特定する情報を、ウェブサーバ３０から受信するまで待機する（Ａｃｔ３０８）。

次に、図３（b）に示すように、図２に示すウェブサーバ３０のＣＰＵ３０１は、ＰＯＳ端末１０から送信されたレシートデータを通信コントローラ３０５を介して受信する（Ａｃｔ４０１のＹ）。そして、受信したレシートデータに基づくレシート情報を記載したウェブページのデータを生成する（Ａｃｔ４０２）。ウェブページのデータは、レシートデータが含む商品情報、決済金額、預かり金額、釣銭金額、取引日時の情報のテキストデータやＨＴＭＬによるレイアウト情報によって構成されている。生成したウェブページのデータは、ウェブサーバ３０のＨＤＤ３０４に記憶される。

ウェブサーバ３０のＣＰＵ３０１は、生成したウェブページのデータを特定するためのＵＲＬ情報をＰＯＳ端末１０に送信する（Ａｃｔ４０３）。このＵＲＬ情報は、例えば、英数字のテキストによって構成され、「ｈｔｔｐ：／／ｘｘｘ．ｃｏ．ｊｐ／ｒｅｃｅｉｐｔ／０１０００１」となる。ＵＲＬ中の「ｘｘｘ．ｃｏ．ｊｐ／」は、ホストであるウェブサーバ３０を示すホスト名であり、「／ｒｅｃｅｉｐｔ／０１０００１」は、ウェブサーバ３０に格納されたウェブページを特定するための情報である。

図３（a）に戻り、ＰＯＳ端末１０のＣＰＵ１０１は、ウェブサーバ３０から送信されたＵＲＬ情報を通信コントローラ１１２を介して受信すると（Ａｃｔ３０８のＹ）、ＣＰＵ１０１は、先に生成したレシートデータにウェブサーバ３０から送信されたＵＲＬ情報を付加してレシートデータを生成する（Ａｃｔ３０９）。そして、ＣＰＵ１０１は、プリンタ１０７を動作させることにより生成されたレシートデータを印字する（Ａｃｔ３０９）。図５（a）に、印字されるレシートの一例を示す。詳細については後述する。

他方、Ａｃｔ３０６にて、ＣＰＵ１０１が、顧客が購入した購入点数より予め定められた所定の点数（３点）の方が多いと判断した場合（Ａｃｔ３０６のＮ）、Ａｃｔ３１１の処理に進む。ＣＰＵ１０１は、顧客が購入した購入金額と予め定められた所定金額との比較を行い、顧客が購入した金額が予め定められた所定金額よりも高いか否かを判断する（Ａｃｔ３１１）。Ａｃｔ３１１の処理は第２判定手段に相当する。

ＣＰＵ１０１にて、顧客が購入した金額が予め定められた所定金額よりも高いと判断した場合（Ａｃｔ３１１のＹ）、先のＡｃｔ３０７の処理と同様に、レシートデータを生成して、この生成したレシートデータをウェブサーバ３０に送信する（Ａｃｔ３１２）。他方、顧客が購入した金額が予め定められた所定金額よりも低いと判断した場合（Ａｃｔ３１１のＮ）、ＲＡＭ１０３に一時記憶されている商品情報、決済金額、預かり金額、釣銭金額、取引日時を特定する現在時刻に基づいてレシートデータが生成される（Ａｃｔ３１３）。

Ａｃｔ３１３にてレシートデータが生成された後、ＣＰＵ１０１は、プリンタ１０７を動作させることにより生成されたレシートデータを印字する（Ａｃｔ３０９）。図７（ａ）に、印字されるレシートの一例を示す。詳細については後述する。

図４は、ウェブサーバ３０が実行するレシート情報の閲覧処理を示す図である。ウェブサーバ３０のＣＰＵ３０１は、レシートデータの閲覧要求を受信するまで待機する（Ａｃｔ５０１）。例えば、顧客がパーソナルコンピュータなどの外部機器を介して、レシートに印字されたＵＲＬ情報を入力すると共にレシートに印字されているパスワードを入力してインターネットを介して、ウェブサーバ３０にアクセスした場合、すなわち、顧客からレシートデータの閲覧要求を受信すると（Ａｃｔ５０１のＹ）、ウェブサーバ３０のＨＤＤ３０４に記憶されている一取引毎に記憶されているレシートデータのウェブページのデータを検索する（Ａｃｔ５０２）。

そして、顧客のパーソナルコンピュータから入力されたＵＲＬ情報のレシートデータと一致するレシートデータがＨＤＤ３０４に記憶されているか否かを判断し（Ａｃｔ５０３）、一致するレシートデータが存在した場合（Ａｃｔ５０３のＹ）、入力されたパスワードが一致するか否かを判断する（Ａｃｔ５０４）。ＣＰＵ３０１は、パスワードが一致すると判断した場合（Ａｃｔ５０４のＹ）、ＣＰＵ３０１は、レシートデータを開示する。
これにより、顧客は、取引日時を特定する現在時刻、購入した各商品名称及び購入点数、各商品の単価、決済金額、預かり金額、釣銭金額の詳細な取引情報レシートデータを受信することにより、パーソナルコンピュータの表示画面などにて詳細なレシート情報を閲覧する。

他方、Ａｃｔ５０４にて、ＣＰＵ３０１はパスワードが一致しないと判断した場合（Ａｃｔ５０４のＮ）、エラー処理を行う（Ａｃｔ５０６）。ここでの「エラー処理」は例えば、顧客のパーソナルコンピュータに対して要求されたレシート情報は開示できない旨の情報を送信して終了する。なお、Ａｃｔ５０３にて、ＣＰＵ３０１はＨＤＤ３０４に一致するレシートデータが存在しないと判断した場合も（Ａｃｔ５０３のＮ）、エラー処理を実施する（Ａｃｔ５０６）。

以下に、図５、図６、図７に示すレシート表示例について詳細を説明する。
ここで、図５（ａ）を用いて、図３のＡｃｔ３０６にて、今回の一取引における購入商品の合計点数が予め定められた所定点数よりも多いと判定された場合（Ａｃｔ３０６のＹ）、印字発行されるレシートのイメージについて説明する。例えば、Ａｃｔ３０６の判断基準となる予め定められた所定点数が、「５点」と定められているとする。この場合、顧客が、「商品Ａ」を「２点」、「商品Ｂ」を「１点」、「商品Ｃ」を「１点」、「商品Ｄ」を「１点」、「商品Ｅ」を「６点」、「商品Ｆ」を「１点」、合計１２点を購入したとする。この場合、Ａｃｔ３０６にてＣＰＵ１０１は、実際に顧客が購入した商品点数「１２点」が予め定められた所定点数「５点」よりも多いと判断し、図３のＡｃｔ３１０にて発行されるレシートは、図５（ａ）に示す短縮した第１のレシートフォーマットのレシートＲＴ１を印字発行する。

図５（ａ）に示される第１のレシートフォーマットのレシートＲＴ１は、第1のレシート領域Ｔ１、第２のレシート領域Ｔ２および第３のレシート領域Ｔ３を含む複数のレシート領域を有する。レシートＲＴ１における第1のレシート領域Ｔ１には、取引日時「ＹＹＹＹ年ＭＭ月ＤＤ日」、取引コード「Ｎｏ．０１０００１」が印字され、レシートＲＴ１の第２のレシート領域Ｔ２には、商品点数「１２点」、決済金額（合計）「１１,５８０円」、預かり金額（現金）「１２,０００円」、釣銭金額（お釣）「４２０円」が印字される。そして、レシートＲＴ１の第３のレシート領域Ｔ３には、詳細なレシート情報（商品毎の購入点数、単価などの詳細情報）のアクセス先のＵＲＬ情報と、照合番号「０１０００１」、アクセスパスワード「ａａａａａ１」とが印字される。

図５（ｂ）は、顧客が例えばパーソナルコンピュータを介して、レシート用紙ＲＴ１の第３のレシート領域Ｔ３に印字されたＵＲＬのアクセス先にアクセスして取得したレシート情報を示す図である。ここでは、図５（ｂ）に示すように、第１のレシートフォーマットとは異なる第２のレシートフォーマットの形式にて、各商品の購入点数、単価、商品毎の金額などの詳細な取引情報が、パーソナルコンピュータの画面を通してウェブページＷＰ１に開示される。

次に、図６（ａ）を用いて、ＣＰＵ１０１が、図３のＡｃｔ３０６にて今回の一取引における購入商品の合計点数が予め定められた所定点数よりも少ないと判定された場合（Ａｃｔ３０６のＮ）であって、顧客が購入した金額が予め定められた所定金額よりも高いと判断した場合（Ａｃｔ３１１のＹ）、に発行されるレシート用紙のイメージを説明する。

例えば、Ａｃｔ３０６の判断基準となる予め定められた所定点数が、「５点」と定められ、Ａｃｔ３１１の判断基準となる予め定められた所定金額が「１０,０００円」と定められているとする。この場合において、顧客が、単価「３,０００円」の「商品Ｆ」を「４点」購入したとする。この場合、ＣＰＵ１０１は、Ａｃｔ３０６にて、顧客による購入点数「４点」と予め定められた所定点数「５点」とを比較する（Ａｃｔ３０６）。ＣＰＵ１０１は、所定点数よりも購入点数が少ないと判定し（Ａｃｔ３０６のＮ）、Ａｃｔ３１１にて、購入金額（ここでは「１２,０００円」）と予め定められた所定金額（ここでは「１０,０００円」）とを比較する（Ａｃｔ３１１）。ＣＰＵ１０１は、Ａｃｔ３１１にて、顧客により購入した購入金額が予め定められた所定金額よりも高いと判定し、図６（ａ）に示す第1のレシートフォーマットのレシートを印字発行する。

この場合、印字発行されるレシートＲＴ２は、図６（ａ）に示すように第１のレシートフォーマットの形式にて、レシートＲＴ２の第1のレシート領域Ｒ１に、取引日時「ＹＹＹＹ年ＭＭ月ＤＤ日」、取引コード「Ｎｏ．０１０００２」が印字され、レシートＲＴ２の第２のレシート領域Ｒ２に、商品点数「４点」、決済金額「１２,０００円」、預かり金額「１２,０００円」、釣銭金額「０円」が印字される。そして、レシートＲＴ２の第３のレシート領域Ｒ３に、詳細なレシート情報のアクセス先のＵＲＬ情報、照合番号「０１０００２」、アクセスパスワード「ａａａａａ２」と、が印字される。

図６（ｂ）は、顧客が例えばパーソナルコンピュータを介して、レシート用紙ＲＴ２の第３のレシート領域Ｒ３に印字されたＵＲＬのアクセス先にアクセスして取得したレシート情報を示す図である。ここでは、図６（ｂ）に示すように、第１のレシートフォーマットとは異なる第２のレシートフォーマットの形式にて、各商品の購入点数、単価、商品毎の金額などの詳細な取引情報が、パーソナルコンピュータの画面を通してウェブページＷＰ２に開示される。

次に、図７を用いて、ＣＰＵ１０１が、Ａｃｔ３０６にて今回の一取引における購入商品の合計点数が予め定められた所定点数よりも少ないと判定された場合（Ａｃｔ３０６のＮ）であって、顧客が購入した金額が予め定められた所定金額よりも低いと判断した場合（Ａｃｔ３１１のＮ）、に発行されるレシート用紙のイメージを説明する。

顧客が、「商品Ａ」を「１点」、「商品Ｂ」を「１点」、「商品Ｃ」を「１点」、「商品Ｄ」を「１点」、合計４点、合計「３,０８０円」の取引を行なったとする。この場合、Ａｃｔ３０６にて今回の一取引における購入商品の合計点数（４点）が予め定められた所定点数（例えば５点）よりも少ないと判定され（Ａｃｔ３０６のＮ）、かつ、顧客が購入した金額（３，０８０円）が予め定められた所定金額（例えば１０，０００円）よりも低いと判定される（Ａｃｔ３１１のＮ）。Ａｃｔ３１３にて生成されるレシートデータに基づいてＡｃｔ３１０にて発行されるレシートＲＴ３は、図７にて示されるレシートイメージとなる。すなわち、第1のレシートフォーマットのレシートとは異なる第２のレシートフォーマットにて印字される。具体的には、レシート領域Ｒ４に、取引の明細情報（商品名、商品の単価、決済金額、預かり金額、釣銭金額など）が各種印字される。この場合に印字発行されるレシートフォーマットは、先に説明したウェブサーバ３０にて開示されるレシートフォーマット（第２のレシートフォーマット）と同様の印字形態である。

以上、第１の実施形態によれば、顧客が実際に購入した商品点数が予め定められた所定点数より多いと判定された場合に、通常よりも短縮された第１のレシートフォーマットにて印字を行なうこととなるので、レシート用紙の節約が出来る。また、一取引において、常に短縮されたレシートが印字発行されるわけでなく、購入した点数に応じてレシートのフォーマットが変更されるので、所定の点数の範囲を超えて買物を行なった場合は、短縮したレシートを得ることが出来るとともに、顧客に対して所定の点数を超える商品を購入したことを意識させることが可能となる。

また、短縮したレシートには別途コンピュータによりアクセス可能なＵＲＬ情報が記載されているため、顧客は、レシートに印字されたＵＲＬにアクセスすることで詳細なレシート情報を取得することが出来る。

また、一取引における購入商品の合計点数が予め定められた所定点数よりも少ないと判定された場合であって、顧客が購入した金額が予め定められた所定金額よりも高いと判定した場合においても、短縮されたレシートが発行される。このため、レシート用紙の節約を図ると共に、レシートフォーマット態様の違いにより所定金額を超える買物を行なったことを顧客に意識させることが可能となる。

以上、第１の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。例えば、第１の実施形態は、顧客が実際に購入した商品点数が予め定められた所定点数より多い場合、及び、顧客が実際に購入した商品点数が予め定められた所定点数より少ない場合であっても、一取引での決済金額が予め定められた所定金額よりも高い場合に、短縮したレシートを印字発行する形態について説明しているが、いずれか一方の条件を満たした場合に、短縮されたレシートを発行するように設定してもよい。

（第２の実施形態）
次に第２の実施形態について説明する。本実施形態が第１の実施形態と異なる点は以下の点である。すなわち、第２の実施形態では、一取引の締め処理手段の種別に応じて、短縮レシートの発行を実行するか否かを判定し、この判定結果に基づいて、所定のレシート発行理が実行される。以降の説明では、第1の実施形態と共通する構成・処理については、説明を省略し、異なる部分について説明を行なう。

図８を用いて第2の実施形態のレシート発行処理について説明する。なお、第１の実施形態と第2の実施形態とで異なる点は、Ａｃｔ８０５にて実行された締め処理の種別を判定するＡｃｔ８０６の処理が追加された点、及びＡｃｔ８０６の判定処理後、支払種別マスタファイル１０４２（図９参照）を参照して、この支払種別に応じた形で、印字発行するレシートのフォーマットの態様及びウェブサーバ３０へのデータ送信の有無が決定される点である。

図８（a）において、Ａｃｔ８０１〜Ａｃｔ８０５までの処理は第1の実施形態と同様であるので説明は省略する。Ａｃｔ８０５にてＣＰＵ１０１は、締め処理がなされたと判定すると（Ａｃｔ８０５のＹ）、Ａｃｔ８０５にて指定された締め処理が、図９に示す支払種別マスタファイル１０４２の中のいずれの締め操作であるかを判定する（Ａｃｔ８０６）。

例えば、顧客により現金にて一取引の支払が実施された場合、オペレータは「預／現計キー」を操作する。この場合、ＣＰＵ１０１は、Ａｃｔ８０５にて、締め処理があったと判定し、「預／現計キー」が押された情報を元に図９の支払種別マスタファイル１０４２を参照する。そして、支払種別マスタファイル１０４２に、支払種別と対応付けて記憶されているレシート種別情報と、データ送信の有無の情報とを取得する。この場合、支払種別マスタファイル１０４２には、支払種別「現金」に対応づけて、印字発行するレシート種別は各商品の点数や単価を詳細にレシートに印字する第2のレシートフォーマットＲＴ３（図７参照）、ウェブサーバへのデータ送信を実行しない「無」、がそれぞれ対応付けて記憶されているので、ＣＰＵ１０１は、これらの情報を取得する。そして、ＣＰＵ１０１は、これらの情報を基に印字発行を実施する。即ち、このケースの場合には、支払いが現金であるので、取引データが印刷されたレシートのみが発行される。

次のケースとして、ＣＰＵ１０１が、印字発行するレシートの例を図１０（ａ）に示し、ウェブサーバ３０にて閲覧可能となるレシート表示を図１０（ｂ）を例として、レシート発行について説明する。

例えば、顧客が、「商品Ａ」を「１点」、「商品Ｂ」を「１点」、「商品Ｃ」を「１点」、「商品Ｄ」を「１点」、「商品Ｅ」を「１点」、合計５点、合計「５,０８０円」の取引を行なったとし、顧客はクレジットカードを用いて決済処理を実行したとする。この場合、ＣＰＵ１０１は、図８（a）のＡｃｔ８０６にて支払がされた種別が、「現金」、「電子マネー」、「クレジット」のいずれかであるかをＨＤＤ１０４に記憶されている支払種別マスタファイル１０４２を参照して判定する（Ａｃｔ８０６）。このＡｃｔ８０６の処理は第1判定手段に相当する。判定の結果、支払種別が「クレジット」であるため、ＣＰＵ１０１は支払種別マスタファイル１０４２から支払種別「クレジット」に対応して記憶されているレシート種別情報と、ウェブサーバへのデータ送信の有無情報を取得する。ここでは、「レシート種別情報」は、第３のレシートフォーマット、「ウェブサーバ３０へのデータ送信の有無情報」は「有」とされていることから、これらの情報に基づいて、図８の以降の処理が実行される。

すなわち、この場合に印字されるレシートＲＴ４は、図１０（ａ）に示すようにこのレシートＲＴ４の第1のレシート領域Ｒ１に、取引日時「ＹＹＹＹ年ＭＭ月ＤＤ日」、取引コード「Ｎｏ．０１０００４」が印字され、レシートＲＴ１の第２のレシート領域Ｒ２に、商品点数「５点」、決済金額「５,０８０円」、支払種別である「クレジット払い」の文字が印字される。また、レシートＲＴ１の第３のレシート領域Ｔ３に、詳細なレシート情報（商品毎の購入点数、単価などの情報が記載される。）のアクセス先のＵＲＬ情報と、照合番号「０１０００４」、アクセスパスワード「ａａａａａ４」とが印字される。先に示した第１のレシートフォーマットと異なる点は、第１のレシートフォーマットの第２のレシート領域Ｔ２に印字される支払金額及び釣銭金額の印字が、第３のレシートフォーマットでは、「クレジット払い」の文字に置き換わった点である。

また、図１０（ｂ）は、顧客がパーソナルコンピュータなどを介して、レシート用紙ＲＴ４の第３のレシート領域Ｒ３に印字されたＵＲＬのアクセス先にアクセスして取得したレシート情報を示す図である。図１０（ｂ）に示すように、第１のレシートフォーマットとは異なる第２のレシートフォーマットの形式にて、各商品の購入点数、単価、商品毎の金額などの詳細な取引情報が、パーソナルコンピュータの画面を通してウェブページＷＰ４に開示される。

図１１（ａ）は、上記と異なる決済手段（電子マネー）による取引を実施した結果、印字発行される第４のレシートフォーマットを示した図である。印字されるレシートＲＴ５は、このレシートＲＴ５の第1のレシート領域Ｒ１及び第３のレシート領域Ｒ３は、第１のレシートフォーマットと同様である。つまり、第1のレシート領域Ｒ１には、取引日時、取引コードが印字され、第３のレシート領域Ｒ３には、アクセス先のＵＲＬ情報と、照合番号、アクセスパスワードとが印字される。第１のレシートフォーマットと異なる点は、第２のレシート領域Ｒ２であり、この領域Ｒ２には、決済金額と、電子マネーの残高金額が印字される点である。図１１（ｂ）は、顧客がパーソナルコンピュータなどを介して、レシート用紙ＲＴ５の第３のレシート領域Ｒ３に印字されたＵＲＬのアクセス先にアクセスして取得したレシート情報を示す図である。図１１（ｂ）に示すように、第４のレシートフォーマットとは異なる第２のレシートフォーマットの形式にて、各商品の購入点数、単価、商品毎の金額などの詳細な取引情報が、パーソナルコンピュータの画面を通してウェブページＷＰ５に開示される。

以上、第２の実施形態によれば、一取引の支払種別の方法により、発行されるレシートの種別が予め対応付けて定められている。このため、顧客は、短縮されたレシートの印字発行を希望する場合は、この短縮されたレシートが発行されるように予め定められている支払種別の方法で支払を行なうことにより、希望する形態のレシートを受け取ることが可能となる。

例えば、第２の実施形態で使用される支払種別マスタファイル１０４２に対応付けて記憶されるレシート種別及びデータ送信の有無は必ずしも、この対応付けられた形式に限られることはなく、適宜、オペレータの設定により変更可能である。変更する一例として、例えば、ＰＯＳ端末１０の業務モードを点検モードに設定し、この点検モードの下で、それぞれ、支払種別に対応するレシート種別を適宜変更することが可能である。

以上、本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１０ ＰＯＳ端末 （商品販売データ処理装置）
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ ＨＤＤ
２０ ストアコンピュータ
３０ ウェブサーバ
１０４１ 商品マスタファイル
１０４２ 支払種別マスタファイル

Claims (6)

1. 商品に対応付けられた商品コードを入力する入力部と、
   この入力部により入力された商品コードに基づいて一取引の合計金額を含む取引データを生成する生成手段と、
   この生成手段により生成された取引データをウェブサーバに送信する送信手段と、
   前記一取引で取引される商品の合計金額が予め定められた金額を超えているか否かを判定する判定手段と、
   前記合計金額が予め定められた金額を超えていると前記判定手段が判定した場合に、前記合計金額及び前記一取引の取引データが保管される前記ウェブサーバ上の開示先を示す情報を含めて、顧客に表示するためのレシートデータを生成する制御部と、
   を備える商品データ処理装置。
2. 商品に対応付けられた商品コードを入力する入力部と、
   この入力部により入力された商品コードに基づいて一取引の合計金額を含む取引データを生成する生成手段と、
   この生成手段により生成された取引データをウェブサーバに送信する送信手段と、
   前記一取引での支払い方法が予め定められた方法であるか否かを判定する判定手段と、
   前記支払い方法が予め定められた方法であると前記判定手段が判定した場合に、前記支払い方法及び前記一取引の取引データが保管される前記ウェブサーバ上の開示先を示す情報を含めて、顧客に表示するためのレシートデータを生成する制御部と、
   を備える商品データ処理装置。
3. 前記開示先を示す情報はＵＲＬ情報である、請求項１または２に記載の商品データ処理装置。
4. 商品に対応付けられた商品コードを入力する入力部を備えた商品販売データ処理装置のコンピュータに、
   前記入力部により入力された商品コードに基づいて一取引の合計金額を含む取引データを生成する機能と、
   前記取引データを生成する機能により生成された取引データをウェブサーバに送信する機能と、
   前記一取引で取引される商品の合計金額が予め定められた金額を超えているか否かを判定する機能と、
   前記合計金額が予め定められた金額を超えていると前記判定する機能が判定した場合に、前記合計金額及び前記一取引の取引データが保管される前記ウェブサーバ上の開示先を示す情報を含めて、顧客に表示するためのレシートデータを生成する機能と、
   を実現させる制御プログラム。
5. 商品に対応付けられた商品コードを入力する入力部を備えた商品販売データ処理装置のコンピュータに、
   前記入力部により入力された商品コードに基づいて一取引の合計金額を含む取引データを生成する機能と、
   前記取引データを生成する機能により生成された取引データをウェブサーバに送信する機能と、
   前記一取引での支払い方法が予め定められた方法であるか否かを判定する機能と、
   前記支払い方法が予め定められた方法であると前記判定する機能が判定した場合に、前記支払い方法及び前記一取引の取引データが保管される前記ウェブサーバ上の開示先を示す情報を含めて、顧客に表示するためのレシートデータを生成する機能と、
   を実現させる制御プログラム。
6. 前記開示先を示す情報はＵＲＬ情報である、請求項４または５に記載の制御プログラム。

Images