(57)【要約】【課題】クレジットカード発行業者による承認が行われていない未成立取引に対する承認番号確認作業を、クレジット決済を処理する店側で容易に行えるようにする。【解決手段】クレジット決済が処理された商取引のクレジット明細データをデータファイルに保存する。データファイルに保存されたクレジット明細データに基づいてクレジットカード発行業者からの承認が得られていない未成立取引を選択する。選択された未成立取引のクレジット明細データを例えば表示出力する。【選択図】      図７
2006221553.tif 000002
【特許請求の範囲】
【請求項１】
商品販売データを処理した商取引に対してクレジット支払が指示されると、回線接続されたホストにクレジットの承認問合せを行い、承認応答を受けると当該商取引のクレジット決済を処理する商品販売データ処理装置において、
クレジット決済が処理された商取引のクレジット明細データをデータファイルに保存する明細保存手段と、
前記データファイルに保存されたクレジット明細データに基づいてクレジット業者からの承認が得られていない未成立取引を選択する未成立取引選択手段と、
この未成立取引選択手段により選択された未成立取引のクレジット明細データを出力する未成立取引明細出力手段と、
を具備したことを特徴とする商品販売データ処理装置。
【請求項２】
前記未成立取引明細出力手段により出力されたクレジット明細データに、前記クレジット業者からの承認が得られた際に発番される承認番号を追加する承認番号追加手段と、
この承認番号追加手段により承認番号が追加されたクレジット明細データを前記データファイルに保存する追加明細保存手段と、
をさらに具備したことを特徴とする請求項１記載の商品販売データ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クレジット決済を処理可能なＰＯＳ（Point Of Sales）端末等の商品販売データ処理装置に関する。
【背景技術】
【０００２】
クレジットカードによるクレジット決済が可能なショッピングセンタでは、通常、センタの管理会社であるデベロッパの本部に設置された本部サーバに、クレジット専用のネットワークを介して、クレジット管理機能を有するホストコンピュータが接続されている。また、本部サーバには、センタ内の専用ネットワークを介して、各テナント店舗にそれぞれ設置されているＰＯＳ端末が接続されている。ＰＯＳ端末は、商品販売データ処理装置の一態様であり、特に、クレジットカードのデータを読取ることができるカード読取部や、クレジットの支払方法等を入力するための入力部等を備えたクレジット決済対応のものである。
【０００３】
しかして、客からクレジットカードによる支払の申し出を受けたテナント店舗では、店員は、ＰＯＳ端末にて当該客が買い上げる商品の販売データを登録処理した後、クレジットカードによる支払宣言キーを操作する。次いで、当該客から提出されたクレジットカードのカードデータを読取らせるとともに、一括払い，分割払い，リボルビング払い等のクレジット支払方法を入力する。
【０００４】
そうすると、ＰＯＳ端末では、クレジットカードのカードデータとともに支払金額，支払方法に対応した支払区分等のデータが組み込まれたクレジット承認問合せ伝文が作成される。この問合せ伝文は、ネットワークを介して本部サーバに送信される。
【０００５】
ここで、本部サーバとクレジット管理機能を有するホストコンピュータとの接続が確立されている場合には、問合せ伝文がホストコンピュータに転送される。ホストコンピュータでは、カードデータや支払金額等に基づいてクレジットを承認するか否かが判定される。そして、その判定結果を示す応答伝文が、本部サーバを介して問合せ元のＰＯＳ端末に返信される。これに対し、本部サーバとホストコンピュータとの接続が確立されていない場合には、本部サーバで支払金額等に基づいてクレジットを承認するか否かが判定される。そして、その判定結果を示す応答伝文が問合せ元のＰＯＳ端末に返信される。
【０００６】
クレジットを承認する応答伝文を受信したＰＯＳ端末では、クレジットカード発行業者への報告用，客控え用及び本部控え用の３種類のクレジット伝票が作成される。これらのクレジット伝票には、ＰＯＳ端末から一意的に発番される伝票番号が印刷される。また、ホストコンピュータにてクレジットが承認された商取引に対しては、ホストコンピュータから一意的に発番される承認番号も印刷される。
【０００７】
その後、ＰＯＳ端末では、クレジット決済が処理された商取引のクレジット明細項目を示すクレジット明細データが作成される。そして、このクレジット明細データが、ネットワークを介して本部サーバに送信される。
【０００８】
本部サーバでは、各ＰＯＳ端末から送られてくるクレジット明細データがデータファイル上で保存される。また、各テナント店舗から本部に本部控え用のクレジット伝票が届けられる。そこで本部の業務担当者は、毎営業日の精算時刻になると、データファイル上で保存されたクレジット明細データと、各テナント店舗から回収されたクレジット伝票との突合せ作業を実施して、クレジット明細データを精査していた。この際、コンピュータとの通信トラブル等に起因して本部サーバ内で承認された取引、つまりはホストコンピュータでの承認がまだ行われていない未成立取引については、クレジットカード発行業者から承認番号の発番を受ける等の面倒な作業が要求されていた。
【０００９】
なお、ショッピングセンタ向けのシステムとして、各店舗における日々の売上情報を確定する際のデータ突合せ作業を自動化した売上管理システムは、すでに知られている。しかし、この売上管理システムを用いても、本部にて実施されているクレジット明細データの精査作業に要する負担を軽減することはできなかった（例えば、特許文献１参照）。
【特許文献１】特開平９−１４７２３８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述したように従来は、本部サーバの管理部署で行われるクレジット明細データの精査作業の中で、クレジットカード発行業者による承認がまだ行われていない未成立取引に対する承認番号の取得作業を行っていたので、大規模なショッピングセンタのように数多くのテナント店舗で処理されたクレジット決済の明細データを精査する必要があるデベロッパ本部などでは、精査作業に要する人的負荷が非常に大きいという問題があった。
【００１１】
このような問題は、クレジット決済を処理する店側で未成立取引の承認番号取得作業を行えるようになれば、サーバ管理部署での精査作業に要する人的負荷が軽減されて解決されると考える。
【００１２】
本発明はこのような事情に基づいてなされたもので、その目的とするところは、クレジットカード発行業者による承認が行われていない未成立取引に対する承認番号確認作業を、クレジット決済を処理する店側で容易に行うことを支援できる商品販売データ処理装置を提供しようとするものである。
【課題を解決するための手段】
【００１３】
本発明は、商品販売データを処理した商取引に対してクレジット支払が指示されると、回線接続されたホストにクレジットの承認問合せを行い、承認応答を受けると当該商取引のクレジット決済を処理する商品販売データ処理装置、例えばクレジット決済対応のＰＯＳ端末において、クレジット決済が処理された商取引のクレジット明細データをデータファイルに保存する明細保存手段と、データファイルに保存されたクレジット明細データに基づいてクレジット業者からの承認が得られていない未成立取引を選択する未成立取引選択手段と、この未成立取引選択手段により選択された未成立取引のクレジット明細データを出力する未成立取引明細出力手段とを備えたものである。未成立取引選択手段は、例えばクレジット業者からの承認が得られた場合には自動的に発番される承認番号が設定されていないクレジット明細データに対応した商取引を未成立取引として選択する。未成立取引明細出力手段は、例えば未成立取引のクレジット明細データを一覧で示す画面を構成し、この画面を表示部に表示出力する。
【発明の効果】
【００１４】
かかる手段を講じた本発明によれば、クレジットカード発行業者による承認が行われていない未成立取引に対する承認番号確認作業を、クレジット決済を処理する店側で容易に行うことを支援できる商品販売データ処理装置を提供できる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明を実施するための最良の形態について、図面を用いて説明する。  
なお、この実施の形態は、クレジットカードシステムが構築されたショッピングセンタの各テナント店舗にそれぞれ設置されているＰＯＳシステムに、本発明を適用した場合である。
【００１６】
図１は本実施の形態におけるクレジットカードシステムの全体構成図である。各テナント店舗（テナントＡ，テナントＢ，…）には、それぞれＰＯＳシステムが構築されている。ＰＯＳシステムは、店舗内に設置されている複数台のＰＯＳ端末１と、店舗の事務所などに設置されている店舗サーバ２とを、ＬＡＮ（Local Area Network）等の通信回線３で接続して構成されている。
【００１７】
デベロッパの本部には、本部サーバ４が設置されている。そして、この本部サーバ４に、センタ内の専用ネットワーク５を介して、各テナント店舗の店舗サーバ２が接続されている。また、クレジット専用のネットワーク６を介して、クレジット管理機能を有するホストコンピュータ７が本部サーバ４に接続されている。
【００１８】
ＰＯＳ端末１は、販売登録された商品の販売データを処理して商取引の合計を算出する機能、商取引の合計に対して入力された支払いデータを処理して商取引を決済する機能等を有するもので、特に、クレジットカードによるクレジット支払を処理できるクレジット決済対応のものである。
【００１９】
店舗サーバ２は、各ＰＯＳ端末１で販売登録された商品の品名，単価等の商品データを管理する機能、各ＰＯＳ端末１で処理された商品販売データを集計して店舗全体の日計データを管理する機能、各ＰＯＳ端末１と本部サーバ４との間の通信を中継する機能等を有するものである。
【００２０】
本部サーバ４は、各店舗サーバ２で確定された日計データを収集し分析して各店舗の売上実績を管理する機能、クレジット管理機能を有するホストコンピュータ７との間の回線状況を監視し、接続が確立されていない場合にはクレジットの承認判定を行う機能等を有するものである。
【００２１】
そして本部サーバ４には、各テナント店舗のＰＯＳ端末１でクレジット決済が処理された商取引のクレジット明細項目からなるクレジット明細データを保存するためのマスターファイル８が設けられている。また、各ＰＯＳ端末１には、それぞれ自機でクレジット決済が処理された商取引のクレジット明細データを保存するためのローカルファイル９が設けられている。
【００２２】
上記クレジット明細データの項目レイアウトの一例を図２に示す。同図において、テナントコードは、デベロッパが各テナント店舗に対して割当設定した識別用のコードである。ＰＯＳ番号は、テナント店舗が自店舗内の各ＰＯＳ端末１に割当設定した識別用の番号である。一連番号は、ＰＯＳ端末１からクレジット決済を処理する毎に発番される連続番号である。カードデータはクレジットカードに記録されている生データである。会社識別コードは、クレジットカード発行業者に対して予め設定された識別用のコードである。カード番号は、クレジットカード発行業者が自社で発行した各クレジットカードに割当設定した番号である。取引日時は、クレジット決済が成立した日時である。伝票番号は、クレジット伝票に付された取引識別番号である。売上区分は、売上取引に対するクレジット明細データなのか取消取引に対するクレジット明細データなのかを区分するデータである。支払区分は、クレジットの支払方法（一括，分割，リボルビングなど）を区分するデータである。支払金額は、クレジットでの支払い金額である。承認番号は、クレジットカード発行業者からクレジット決済が承認される毎に発番される番号である。
【００２３】
図４はＰＯＳ端末１の要部構成を示すブロック図である。ＰＯＳ端末１には、制御部本体としてＣＰＵ（Central Processing Unit）１１が搭載されている。また、プログラム等の固定的データが予め格納されたＲＯＭ（Read Only Memory）１２、商品販売データを登録処理するためのメモリエリア等が形成されるＲＡＭ（Random Access Memory）１３、現在の日付及び時刻を計時する時計部１４、通信回線３を介して接続された店舗サーバ２とのデータ通信を制御するＬＡＮコントローラ１５の他、キーボードコントローラ１６，タッチパネルコントローラ１７，表示コントローラ１８，プリンタコントローラ１９，カードリーダコントローラ２０，Ｉ／Ｏポート２１等が搭載されている。そしてＣＰＵ１１と、ＲＯＭ１２，ＲＡＭ１３，時計部１４，ＬＡＮコントローラ１５，キーボードコントローラ１６，タッチパネルコントローラ１７，表示コントローラ１８，プリンタコントローラ１９，カードリーダコントローラ２０及びＩ／Ｏポート２１とは、アドレスバス，データバス等のバスライン２２で接続されている。
【００２４】
キーボードコントローラ１６は、キーボード２３からキー操作に対応したキーデータを入力し、ＣＰＵ１１に通知する。キーボード２３は、置数キー，ＰＬＵキー，小計キー，預／現計キー，取消キー，クリアキー等の他、クレジット支払を宣言するクレジット計キーと、クレジット支払方法を選択する支払方法選択キーとが配設されたものである。
【００２５】
タッチパネルコントローラ１７は、表示データをタッチパネル２４の画面に表示させる。また、タッチパネル２４のタッチ操作を検知し、その座標データをＣＰＵ１１に通知する。タッチパネル２４は、オペレータ（キャッシャ）に対する表示部及び操作部として機能する。表示コントローラ１８は、表示データをディスプレイ２５に表示させる。ディスプレイ２５は、客用表示器として機能する。プリンタコントローラ１９は、印字データをプリンタ２６に供給して印字動作を行わせる。プリンタ２６は、レシート用紙にデータを印字するもので、クレジット決済が成立した際にはレシート用紙を用いてクレジットカード発行業者への報告用，客控え用及び本部控え用の３種類のクレジット伝票を印字発行する。カードリーダコントローラ２０は、カードリーダ２７で読取られたカードデータを取り込み、ＣＰＵ１１に通知する。カードリーダ２７は、クレジットカードに記録されているデータの読み取りに対応したものである。Ｉ／Ｏポート２１は、現金などを収容するためのドロワ２８に対して駆動信号を出力する。ドロワ２８は、駆動信号の入力に応じて開放動作するようになっている。
【００２６】
かかる構成のＰＯＳ端末１において、前記ローカルファイル９はＲＡＭ１３に形成されている。また、図３に示すように、クレジット決済された商取引の回数Ａ０及び金額Ｂ０を合計するエリアと、クレジット決済された商取引のうちクレジットカード発行業者によって承認された成立取引の回数Ａ１及び金額Ｂ１を合計するエリアと、クレジットカード発行業者による承認が行われていない未成立取引の回数Ａ２及び金額Ｂ２を合計するエリアとが形成されたクレジット合計テーブル３０がＲＡＭ１３に形成されている。
【００２７】
しかしてＣＰＵ１１は、キーボード２３の操作により客が買い上げる商品の販売データが入力されると、その商品販売データを登録処理する。また、商品名，価格等の登録商品データをタッチパネル２４及びディスプレイ２５に表示させる。こうして、１商取引として売り上げる全ての商品の販売データが登録処理された後、キーボード２３のクレジット計キー操作によりクレジット支払が指示されると、ＣＰＵ１１は、図５の流れ図に示す締め業務処理を実行する。
【００２８】
すなわちＣＰＵ１１は、ＳＴ（ステップ）１として１商取引の締め入力がクレジット計キーであることを確認すると、ＳＴ２としてカードリーダ２７で読取られたカードデータと支払区分及び支払金額とから承認問合せ伝文を作成し、この承認問合せ伝文をＬＡＮコントローラ１５から送信して、ホストコンピュータ７にクレジットの承認を問い合わせる。なお、承認問合せ伝文には、予め設定されたテナントコード及びＰＯＳ番号と、クレジット計キーが押下される毎に累進発番される一連番号がヘッダデータとして付加されている。
【００２９】
この承認問合せ伝文は、通信回線３を介して店舗サーバ２に送信され、さらにネットワーク５を経由して本部サーバ４に送信される。本部サーバ４では、ホストコンピュータ７との回線が接続されているか否かが判断される。回線が接続されている場合には、承認問合せ伝文は、ネットワーク６を介してホストコンピュータ７に送信される。ホストコンピュータ７では、承認問合せ伝文を受信すると、その伝文中のカードデータや支払金額等からクレジット決済を承認するか否かが判断される。そして承認する場合には、問合せ伝文中のカードデータや支払データに新たな承認番号（＞０）が付された承認応答伝文が返信される。この承認応答伝文は、本部サーバ４及び店舗サーバ２を経由して問合せ伝文送信元のＰＯＳ端末１に送信される。
【００３０】
一方、例えばホストコンピュータ７がダウンしており、本部サーバ４とホストコンピュータ７との回線が接続されていない場合には、本部サーバ４において支払金額等からクレジット決済を承認するか否かが判断される。そして承認する場合には、問合せ伝文中のカードデータや支払データに承認番号＝０が付された承認応答伝文が返信される。この承認応答伝文は、店舗サーバ２を経由して問合せ伝文送信元のＰＯＳ端末１に送信される。
【００３１】
そこで、ホストコンピュータ７にクレジットの承認問合せを行ったＰＯＳ端末１のＣＰＵ１１は、この問合せに対する応答を待機する。そして、ＳＴ３として承認応答伝文を受信したとすると、ＣＰＵ１１は、ＳＴ４としてプリンタ２６を動作させて、クレジットカード発行業者への報告用，客控え用及び本部控え用の３種類のクレジット伝票を発行させる。また、ＳＴ５として図２に示すデータレイアウトのクレジット明細データを作成し、自己のローカルファイル９に格納する（明細保存手段）。
【００３２】
しかる後、ＣＰＵ１１は、ＳＴ６として承認応答伝文に含まれた承認番号が“０”か否かを判断する。ここで、承認番号が“０”でない場合には、クレジット決済された商取引はクレジットカード発行業者によって承認された成立取引なので、ＣＰＵ１１は、ＳＴ７としてクレジット合計テーブル３０のクレジット計エリア及び成立取引計エリアに、回数＝１と支払金額とをそれぞれ加算する。
【００３３】
これに対し、承認番号が“０”であった場合には、クレジット決済された商取引はクレジットカード発行業者による承認がまだ行われていない未成立取引なので、ＣＰＵ１１は、ＳＴ８としてクレジット合計テーブル３０のクレジット計エリア及び未成立取引計エリアに、回数＝１と支払金額とをそれぞれ加算する。以上で、今回のクレジット決済された商取引に対する処理を終了する。
【００３４】
またＣＰＵ１１は、１営業日の販売業務終了後に実施される日報業務のモードにおいて、図６の流れ図に示すクレジット精査処理を実行できるようになっている。
【００３５】
すなわちＣＰＵ１１は、日報業務モードのメニューからいずれかの業務が選択されると、この処理を開始する。そして、ＳＴ１１として選択された業務がクレジット精査処理の業務であることを確認すると、ＣＰＵ１１は、ＳＴ１２として図８に示す画面レイアウトの明細対象選択画面４０を編集し、タッチパネル２４に表示させる。図示するように、明細対象選択画面４０には、クレジット合計テーブル３０に記憶されているクレジット計，成立取引計及び未成立取引計の各合計点数及び合計金額と、クレジット計の合計点数及び合計金額から成立取引計の合計点数及び合計金額をそれぞれ減算した差が表示されている。また、成立取引に関する明細情報の確認を指示する成立明細確認ボタン４１と、未成立取引に関する明細情報の確認を指示する未成立明細確認ボタン４２と、終了ボタン４３とが、タッチボタンとして表示されている。
【００３６】
次に、ＣＰＵ１１は、ＳＴ１３としてクレジット合計テーブル３０の未成立取引合計点数が“０”か“１”以上かを判断する。そして、未成立取引合計点数が“０”の場合には、未成立明細確認ボタン４２の選択不可フラグを記憶する。これに対し、未成立取引合計点数が“１”の場合には、未成立明細確認ボタン４２の選択可フラグを記憶する。そして、未成立明細確認ボタン４２が選択可能であることをオペレータに報知するように、例えばボタンの背景色を変更する。
【００３７】
次に、ＣＰＵ１１は、ＳＴ１６として明細対象選択画面４０のタッチボタン４１〜４３がタッチ操作されるのを待機する。ここで、ＳＴ１７としてタッチパネルコントローラ１７から入力されたタッチ座標データにより終了ボタン４３がタッチ操作されたことを検知した場合には、ＣＰＵ１１は、ローカルファイル９のデータを店舗サーバ２を介して本部サーバ４に送信して、このクレジット精査処理を終了する。
【００３８】
これに対し、ＳＴ１８として成立明細確認ボタン４１がタッチ操作されたことを検知した場合には、ＣＰＵ１１は、ローカルファイル９から承認番号が“１”以上のクレジット明細データを成立取引明細データとして抽出する。そして、図９に示す画面レイアウトの成立取引明細確認画面５０を編集し、タッチパネル２４に表示させる。図示するように、成立取引明細確認画面５０には、ローカルファイル９から抽出された各成立取引明細データのＰＯＳ番号、会社識別コードに対応するクレジットカード発行業者の会社名称、売上区分、支払区分、取引日時、支払金額、伝票番号及び承認番号の各項目一覧表が表示されている。また、一覧表に表示される成立取引明細データの前頁表示を指示する前頁ボタン５１及び次頁表示を指示する次頁ボタン５２と、終了ボタン５３とがタッチボタンとして表示されている。そして、終了ボタン５３がタッチ操作されたことを検知すると、ＣＰＵ１１は、ＳＴ１２の処理に戻り、再度、明細対象選択画面４０を編集してタッチパネル２４に表示させるものとなっている。
【００３９】
また、ＳＴ１９として未成立明細確認ボタン４２がタッチ操作されたことを検知した場合には、ＣＰＵ１１は、ＳＴ２０として未成立明細確認ボタン４２の選択可フラグを記憶しているか否かを判断する。ここで、選択可フラグを記憶していない、すなわち選択不可フラグを記憶している場合には、未成立明細確認ボタン４２の操作が禁止されているので、ＣＰＵ１１は、ＳＴ１６の処理に戻り、次のボタン操作を待機する。
【００４０】
これに対し、未成立明細確認ボタン４２の選択可フラグを記憶している場合には、ＣＰＵ１１は、図７で具体的に示す未成立明細精査処理を実行する。先ず、ＳＴ２１としてローカルファイル９から承認番号が“０”のクレジット明細データを未成立取引明細データとして抽出する（未成立取引選択手段）。そしてＳＴ２２として、図１０に示す画面レイアウトの未成立取引明細確認画面６０を編集し、タッチパネル２４に表示させる（未成立取引明細出力手段）。
【００４１】
図示するように、未成立取引明細確認画面６０には、ローカルファイル９から抽出された未成立取引の各クレジット明細データのＰＯＳ番号、会社識別コードに対応するクレジットカード発行業者の会社名称、売上区分、支払区分、取引日時、支払金額、伝票番号及び承認番号の各項目一覧表が表示されている。また、一覧表に表示される成立取引明細データの前頁表示を指示する前頁ボタン６１及び次頁表示を指示する次頁ボタン６２と、編集ボタン６３と、終了ボタン６４とがタッチボタンとして表示されている。なお、抽出されたクレジット明細データは承認番号が全て“０”なので、承認番号の欄は空欄になっている。
【００４２】
ここで、ＳＴ２３として終了ボタン６４がタッチ操作されたことを検知した場合には、ＣＰＵ１１は、ＳＴ１２の処理に戻り、再度、明細対象選択画面４０を編集してタッチパネル２４に表示させる。
【００４３】
これに対し、ＳＴ２４として編集ボタン６３がタッチ操作されたことを検知した場合には、ＣＰＵ１１は、ＳＴ２５として一覧表に表示されている未成立取引のクレジット明細データのなかからいずれかのデータが選択されるのを待機する。ここで、タッチパネルコントローラ１７から入力されたタッチ座標データにより一覧表の中のいずれかの項目データ表示欄がタッチ操作されたことを検知すると、その欄に表示されているクレジット明細データが選択されたので、ＣＰＵ１１は、ＳＴ２６としてこの選択された未成立取引のクレジット明細データをローカルファイル９から取得する。また、図１１に示すように、ＳＴ２７として未成立取引明細確認画面６０における一覧表の当該クレジット明細データが表示されている行の承認番号欄にカーソル６５を表示させ、この欄への入力可能状態にあることをオペレータに知らしめる。
【００４４】
そして、ＳＴ２８としてキーボード２３の置数キー操作により承認番号に相当する数値データが入力されたならば、ＣＰＵ１１は、この数値データを該当する承認番号欄に表示させるとともに、ＳＴ２９として該当するクレジット明細データの取引日時と承認番号を、それぞれ時計部１４にて計時されている現日時とキー入力された承認番号とに更新する（承認番号追加手段）。そして、ＳＴ３０として取引日時と承認番号が更新されたクレジット明細データをローカルファイル９に追加する（追加明細保存手段）。また、ＳＴ３１としてクレジット合計テーブル３０における成立取引計エリアに回数＝１と、当該クレジット明細データの支払金額を加算する。さらに、ＳＴ３２としてクレジット合計テーブル３０における未成立取引計エリアから回数＝１と、当該クレジット明細データの支払金額を減算する。
【００４５】
しかる後、タッチパネル２４のタッチ操作により他の未成立取引のクレジット明細データが選択されたことを検知した場合には、ＣＰＵ１１は、前記ＳＴ２６〜ＳＴ３２の処理を再度実行する。また、ＳＴ３３として終了ボタン６４がタッチ操作されたことを検知した場合には、ＣＰＵ１１は、ＳＴ１２の処理に戻り、再度、明細対象選択画面４０を編集してタッチパネル２４に表示させるものとなっている。
【００４６】
このように構成された本実施の形態においては、各テナント店舗での商取引に対してクレジット支払が発生すると、テナントコード，ＰＯＳ番号，一連番号をヘッダデータとし、使用されたクレジットカードのカードデータ，会社識別コード及びカード番号や取引日時，伝票番号，売上区分，支払区分，支払金額，承認番号等の項目データを付加したクレジット明細データが、当該商取引を処理したＰＯＳ端末１のローカルファイル９に保存される。ここで、ＰＯＳ端末１からのクレジット問合せに対してホストコンピュータ７にて承認されたクレジット明細データについては、“１”以上の承認番号が設定されている。これに対して、例えばホストコンピュータ７がダウンしており承認不能であったために本部サーバ４にて承認されたクレジット明細データについては、承認番号が“０”である。
【００４７】
また、各ＰＯＳ端末１のクレジット合計テーブル３０では、自己のＰＯＳ端末でクレジット決済が処理された商取引の回数及び金額と、その中でホストコンピュータ７にて承認された成立商取引の回数及び金額と、本部サーバ４にて承認された未成立商取引の回数及び金額が合計されている。
【００４８】
さて、各テナント店舗では、１日の営業が終了すると、その日の売上分をデベロッパに通知するために日報業務を実施する。この日報業務のなかで、店長などの業務責任者は、クレジット精査処理を実行する。すなわち、ＰＯＳ端末１の日報業務メニューからクレジット精査処理を選択する。そうすると、ＰＯＳ端末１のタッチパネル２４に明細対象選択画面４０が表示される。
【００４９】
ここで、当該ＰＯＳ端末１でクレジット決済により処理された商取引の中に未成立取引が存在していた場合、すなわち承認番号が“０”のクレジット明細データがローカルファイル９に保存されていた場合には、例えば未成立明細確認ボタン４２の背景色が変更されることにより未成立明細確認ボタン４２が選択可能であることが報知される。
【００５０】
未成立明細確認ボタン４２が選択可能であることを認識した業務責任者は、この未成立明細確認ボタン４２をタッチ操作する。そうすると、ローカルファイル９から未成立取引のクレジット明細データが選択され、このデータの一覧を示す未成立取引明細確認画面６０がタッチパネル２４に表示される。これにより、業務責任者は、未成立取引のクレジットカード発行業者，支払金額，支払区分等の詳細な情報を確認することができる。
【００５１】
未成立取引の明細情報を確認した業務責任者は、該当するクレジットカード発行業者に電話をかけて未成立取引に対する承認番号を要求する。そして、承認番号を取得できたならば、未成立取引明細確認画面６０の該当クレジット明細データ表示欄をタッチ操作する。そうすると、このクレジット明細データ表示欄の承認番号欄にカーソル６５が表示されるので、業務担当者はクレジットカード発行業者から取得した承認番号を置数入力する。そうすると、該当クレジット明細データの各項目のうち取引日時と承認番号とが更新された成立取引のクレジット明細データが作成される。そして、このクレジット明細データがローカルファイル９に追加される。また、クレジット合計テーブル３０における成立取引計エリアに回数＝１と当該クレジット明細データの支払金額が加算され、未成立取引計エリアから同数及び同額が減算される。
【００５２】
その後、明細対象選択画面４０の終了ボタン４３がタッチ操作されてクレジット精査処理の終了が宣言されると、ローカルファイル９のデータが本部サーバ４に送信され、マスターファイル８に保存される。したがってマスターファイル８には、クレジット決済時にストアコンピュータ７で承認されなかった商取引のクレジット明細データに関して、テナントコード，ＰＯＳ番号及び一連番号が一致するデータが２種類保存されることになる。そのうち、取引日付が古い方は承認番号が“０”の未成立取引のデータであり、取引日付が新しい方は承認番号が“１”以上の成立取引のデータである。そこで本部サーバ４では、テナントコード，ＰＯＳ番号及び一連番号が一致するクレジット明細データが２種類存在する場合には、取引日付が古いデータを無効扱いにし、新しいデータを優先することによって、精査対象のマスターファイル８から未成立取引のクレジット明細データを減らすことができる。
【００５３】
このように、各テナント店舗でそれぞれクレジット精査処理を実行して未成立取引の承認番号取得作業を分担することによって、本部サーバ４のマスターファイル８に保存されるクレジット明細データの中から未成立取引のクレジット明細データが減少するようになるので、本部サーバ４の管理部署であるデベロッパ側で行う精査作業の作業負荷を大幅に軽減できる効果を奏する。
【００５４】
なお、この発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。
【００５５】
例えば前記実施の形態では、各テナント店舗のＰＯＳ端末１にローカルファイル９を設けたが、店舗サーバ２にローカルファイル９を設けて、該店舗サーバ２に接続された各ＰＯＳ端末１がローカルファイル９を共用してもよい。こうすることにより、１つのテナント店舗においてクレジット精査処理はいずれか１台のＰＯＳ端末１で行えばよく、テナント店舗での業務負担を軽減できる効果を奏する。
【００５６】
また、前記実施の形態では承認番号が“０”のクレジット明細データを未成立取引のデータとして選択したが、未成立取引のデータを選択する方法はこれに限定されるものではなく、例えばクレジット明細データに承認応答の発信先を示す情報を付加して、発信先がホストコンピュータ７であった場合には成立取引と認識し、本部サーバ４であった場合には未成立取引と認識して、未成立取引のクレジット明細データを選択するようにしてもよい。
【００５７】
また、前記実施の形態ではオペレータ用の表示部としてタッチパネル２４を用いたが、タッチパネル２４はあくまでも一例であり、ディスプレイとマウスなどのポインティングデバイスを用いて各種画面の表示及びその画面上のボタン入力等を行えるようにしてもよい。
【００５８】
また、本発明はショッピングセンタのクレジットカードシステムに使用されるＰＯＳ端末等の商品販売データ処理装置に限定されるものではなく、例えば地域内の複数のチェーン店舗の売上などをその地域の本部で統括管理するチェーンストアのクレジットカードシステムに使用される商品販売データ処理装置などにも同様に適用できるものである。
【００５９】
この他、前記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を組合わせてもよい。
【図面の簡単な説明】
【００６０】
【図１】本発明の一実施の形態であるクレジットカードシステムの全体構成図。
【図２】同実施の形態で処理されるクレジット明細データのデータ構造を示す模式図。
【図３】同実施の形態においてＰＯＳ端末のＲＡＭに形成されるクレジット合計テーブルのエリア構造を示す模式図。
【図４】同実施の形態におけるＰＯＳ端末の要部構成を示すブロック図。
【図５】同実施の形態におけるＰＯＳ端末のＣＰＵが実行する締め業務処理の要部手順を示す流れ図。
【図６】同実施の形態におけるＰＯＳ端末のＣＰＵが実行する日報業務処理の要部手順を示す流れ図。
【図７】図６における未成立明細精査処理の具体的手順を示す流れ図。
【図８】同実施の形態におけるＰＯＳ端末の日報業務処理実行によりタッチパネルに表示される明細対象選択画面の一例を示す模式図。
【図９】同実施の形態におけるＰＯＳ端末の日報業務処理実行によりタッチパネルに表示される成立取引明細画面の一例を示す模式図。
【図１０】同実施の形態におけるＰＯＳ端末の日報業務処理実行によりタッチパネルに表示される未成立取引明細画面の一例を示す模式図。
【図１１】上記未成立取引明細画面の未成立取引選択時の状態を示す模式図。
【符号の説明】
【００６１】
１…ＰＯＥ端末、２…店舗サーバ、４…本部サーバ、７…ホストコンピュータ、８…マスターファイル、９…ローカルファイル、３０…クレジット合計テーブル、４０…明細対象選択画面、５０…成立取引明細確認画面、６０…未成立取引明細確認画面。
【図１】
2006221553.tif 000003
【図２】
2006221553.tif 000004
【図３】
2006221553.tif 000005
【図４】
2006221553.tif 000006
【図５】
2006221553.tif 000007
【図６】
2006221553.tif 000008
【図７】
2006221553.tif 000009
【図８】
2006221553.tif 000010
【図９】
2006221553.tif 000011
【図１０】
2006221553.tif 000012
【図１１】
2006221553.tif 000013