JP2019070917A - 情報処理装置およびプログラム - Google Patents

Abstract

【課題】電子マネーの未了取引について、データ管理業務の効率を向上することができる情報処理装置およびプログラムを提供することである。【解決手段】実施形態の情報処理装置は、テナントの情報処理装置から、電子マネーの未了取引の取引データを受信する受信手段と、前記未了取引の取引データを一覧表示する一覧画面を生成し、表示出力する一覧画面表示手段と、前記未了取引の取引データに対する編集操作を受付ける編集受付手段と、取引が成立していた前記未了取引の取引データに対し、電子マネーブランドが発番する伝票番号とは構成の異なる伝票番号を発番する発番手段と、を備える。【選択図】図１０

Description

本発明の実施形態は、情報処理装置およびプログラムに関する。

従来一般的に、ショッピングセンターにおいて電子マネー取引データは、電子マネーリーダライタが取引完了後に伝票番号を自動発番し、テナントのＰＯＳ端末または店舗サーバ等が一時保管する。そして、店舗閉店時の精算業務時に、ＰＯＳ端末または店舗サーバは、電子マネー取引データを１日分の取引データとともに、ショッピングセンターのデベロッパのサーバ（テナント管理サーバともいう）に送信する。デベロッパ側の担当者は、各テナントから送信された取引データに基づいて、各テナントの売上額等を算出し精算業務に利用する。

ところで、非接触ＩＣを利用した電子マネー取引においては、カードや携帯端末のかざし方によってはリーダライタとの通信が処理途中で途切れ、取引が完了しない「未了取引（未了、処理未了ともいう）」が発生する場合がある。稀ではあるが、ショッピングセンター内のテナントにおいても、電子マネーの未了取引が発生しうる。未了取引の取引データについては、デベロッパ側の担当者が、電子マネーの管理会社（電子マネーブランド）に取引額の引き去りがなされたか否かを１件１件問合せる。そして、問合せの結果、取引額の引き去りがなされ、取引が成立していたことが判明した未了取引については、テナントの売上として計上することとなる。

未了取引の問合せ業務の管理、問合せ結果の管理、および、取引成立と判明した取引データを取引データファイルに追加登録する作業については、従来手入力で行われており、業務の効率化および作業負担の軽減が望まれていた。また、未了取引を扱うデータ管理方法や業務手順についても、デベロッパ側に多くが委ねられているというのが現状である。また、取引成立と判明した取引データに対しては、未了取引に対しては伝票番号が発行されていないので、取引成立が判明した場合には、当該取引に新たな伝票番号を付して取引データファイルに追加登録する必要がある。このような作業に関しても、従来は担当者が適宜伝票番号を付して、取引データをデータファイルに手入力する作業を行っていた。

従来、このような背景において、電子マネーの未了取引についてデータ管理業務を簡便化したいという要望があった。

本発明が解決しようとする課題は電子マネーの未了取引について、データ管理業務の効率を向上することができる情報処理装置およびプログラムを提供することである。

実施形態の情報処理装置は、テナントの情報処理装置から、電子マネーの未了取引の取引データを受信する受信手段と、前記未了取引の取引データを一覧表示する一覧画面を生成し、表示出力する一覧画面表示手段と、前記未了取引の取引データに対する編集操作を受付ける編集受付手段と、取引が成立していた前記未了取引の取引データに対し、電子マネーブランドが発番する伝票番号とは構成の異なる伝票番号を発番する発番手段と、を備える。

図１は、本実施形態にかかる電子マネー決済システムの構成図である。 図２は、ＰＯＳ端末のハードウェア構成を示すブロック図である。 図３は、店舗サーバのハードウェア構成および機能構成を示すブロック図である。 図４は、テナント管理サーバのハードウェア構成および機能構成を示すブロック図である。 図５は、電子マネー未了明細確認画面の画面構成例を示す図である。 図６は、電子マネー未了明細確認画面の画面構成例を示す図である。 図７は、展開されたプルダウンメニューの表示例を示す図である。 図８は、電子マネー未了明細確認画面の画面構成例を示す図である。 図９は、電子マネー取引明細入力画面の画面構成例を示す図である。 図１０は、電子マネー取引明細入力画面の画面構成例を示す図である。 図１１は、電子マネー取引明細入力画面の画面構成例を示す図である。 図１２は、電子マネー取引明細表示画面の画面構成例を示す図である。 図１３は、テナント管理サーバにおける取引データ管理業務の動作例を示すフローチャートである。

図１は、本実施形態にかかる電子マネー決済システム１００の構成図である。電子マネー決済システム１００において、ショッピングセンターの各テナント１０ａ〜１０ｃ…（以降、特に区別しない場合はテナント１０と称する）は、それぞれ店舗決済システムを構築している。例えば、テナント１０ａでは、店舗サーバ２ａと、ＰＯＳ端末３ａ、３ｂとを接続し、ＰＯＳ端末３ａには電子マネーＲＷ（リーダライタ）４ａを接続し、ＰＯＳ端末３ｂには電子マネーＲＷ４ｂを接続した店舗決済システムとしている。テナント１０ｂでは、店舗サーバは用いず、ＰＯＳ端末３ｃ、３ｄにそれぞれ電子マネーＲＷ４ｃ、４ｄを接続した店舗決済システムを採用している。また、テナント１０ｃでは、１台のＰＯＳ端末３ｅに１台の電子マネーＲＷ４ｅを接続した店舗決済システムを用いている。このように、店舗決済システムは各テナントによりその構成を適宜変更可能なものとする。

以降、テナントごとに機器を区別しない場合には、店舗サーバ２ａ他を店舗サーバ２と称し、ＰＯＳ端末３ａ、３ｂ、３ｃ、３ｄ、３ｅ…をＰＯＳ端末３と称し、電子マネーＲＷ４ａ、４ｂ、４ｃ、４ｄ、４ｅ…を電子マネーＲＷ４と称する。

各テナント１０の店舗サーバ２またはＰＯＳ端末３は、ショッピングセンター内の有線または無線ＬＡＮ（Local Area Network）等の接続回線５により、デベロッパが管理するテナント管理サーバ１と接続されている。テナント管理サーバ１は、ショッピングセンター内のテナント１０の売上管理を行い、賃料精算等を行う情報処理装置である。また、テナント管理サーバ１は、各テナント１０で発生した電子マネー決済、クレジットカード決済等の決済データを統括管理する。

また、テナント管理サーバ１は、電子マネー管理会社の電子マネーサーバ８と専用回線６で接続されている。また、ショッピングセンター内の電子マネーＲＷ４もそれぞれ、接続回線５および専用回線６等を介して、電子マネーサーバ８に接続されている。尚、図１では簡単のため、電子マネー決済システム１００が電子マネーサーバ８を１つ備えた例を図示した。実際には、電子マネー決済システム１００は、電子マネー管理会社（即ち、電子マネーのブランド）ごとに複数の電子マネーサーバ８を備え、テナント管理サーバ１は各電子マネーサーバ８とそれぞれ接続してデータ通信を行う。

電子マネーＲＷ４は、電子マネー機能を搭載した非接触式ＩＣチップを内蔵した、ＩＣカードあるいは携帯端末との間でデータ通信を行って電子マネーによる決済処理を行う。

即ち、電子マネーＲＷ４は、電子マネー機能を搭載したＩＣチップから、電子マネーの残高情報（引き去り前残高、あるいは、取引前残高ともいう）を受信し、決済金額が残高より多く支払できない場合にはエラーを出力する。決済金額が残高以下であれば、電子マネーＲＷ４は、決済金額をＩＣチップに送信し、ＩＣチップ内の電子マネー残高情報を書き換える。電子マネーＲＷ４は、ＩＣチップとの間のデータ送受信が正常に完了すると、当該取引を特定するために電子マネー取引の伝票番号を発番し、ＩＣチップから読み取った残高情報、決済金額、ＩＣチップの識別情報、電子マネーＲＷ４を特定する機器情報等を含む電子マネー取引データを生成し、自装置が接続するＰＯＳ端末３に送信する。

ＰＯＳ端末３は、店舗の営業終了時等のタイミングに行われる精算業務において、自装置に保存された電子マネー取引データをまとめ、テナント管理サーバ１に送信する。尚、テナント１０内に店舗サーバ２が設けられる場合には、店舗サーバ２が各ＰＯＳ端末３のデータを集計し、集計結果をテナント管理サーバ１に送信する。

次に、各装置の機能構成例について説明する。まず、ＰＯＳ端末３について説明する。

図２は、ＰＯＳ端末３のハードウェア構成を示すブロック図である。ＰＯＳ端末３は、ＣＰＵ、ＲＯＭ、ＲＡＭ等で構成されるコンピュータ構成の制御部３０を備える。また、制御部３０にはバス３２及びＩ／Ｏ機器制御部３４を介して、キーボード３５、スキャナ３６、磁気カードＲＷ３７、店員用表示器３８、客用表示器３９、プリンタ３１１、ＨＤＤ３１２等が接続されている。店員用表示器３８は、例えば液晶ディスプレイなどの表示装置である。店員用表示器３８の表示画面上には、タッチパネル３８１が積層されている。

ＨＤＤ３１２には、制御部３０が実行する各種プログラムの他、商品マスタ、取引データを格納する取引データファイル３１３が格納されている。

また、制御部３０には、バス３２及びＩ／Ｏ機器制御部３４を介して、電子マネーＲＷ４が接続される。電子マネーＲＷ４は、ＮＦＣ（Near Field Communication）のアンテナ４１と、制御チップで構成されるデータ通信部４２とを備えている。データ通信部４２は、非接触式ＩＣカード、あるいは、非接触式ＩＣチップを搭載した携帯型電子機器に対してデータの読み書きを行う。

制御部３０は、通信Ｉ／Ｆ３３及び接続回線５を介してテナント管理サーバ１との間でデータ通信を行う。また、制御部３０は、専用回線６を更に介して電子マネーサーバ８との間でデータ通信を行う。更に、制御部３０は、電子マネーＲＷ４から電子マネー取引データを受信し、取引データファイル３１３に格納する。制御部３０は、店舗営業終了時に行う精算業務等で、取引データファイル３１３に格納されている電子マネー取引データをまとめ、店舗サーバ２またはテナント管理サーバ１に送信する。

次に、店舗サーバ２について説明する。

図３は、店舗サーバ２のハードウェア構成および機能構成を示すブロック図である。店舗サーバ２は、ＣＰＵ、ＲＯＭ、ＲＡＭ等で構成されるコンピュータ構成の制御部２１を備える。制御部２１には、バス２２により通信Ｉ／Ｆ２３１、２３２が接続されている。また、制御部２１には、バス２２およびＩ／Ｏ機器制御部２４を介して、キーボード２５、表示器２６、ＨＤＤ２７等が接続されている。ＨＤＤ２７は、テナント内のＰＯＳ端末３から送信された電子マネー取引データを格納する取引データファイル２７１を備えている。

制御部２１は、通信Ｉ／Ｆ２３１および専用回線６を介して電子マネーサーバ８との間でデータ通信を行う。また、制御部２１は、通信Ｉ／Ｆ２３２および接続回線５を介して、ＰＯＳ端末３、電子マネーＲＷ４との間でデータ通信を行う。制御部２１は、店舗営業終了時に行う精算業務等で、取引データファイル２７１に格納されている電子マネー取引データをまとめ、テナント管理サーバ１に送信する。

次に、テナント管理サーバ１について説明する。

図４は、テナント管理サーバ１のハードウェア構成および機能構成を示すブロック図である。テナント管理サーバ１は、ＣＰＵ、ＲＯＭ、ＲＡＭ等で構成されるコンピュータ構成の制御部１１を備える。制御部１１には、バス１２により通信Ｉ／Ｆ１３１、１３２が接続されている。制御部１１は、通信Ｉ／Ｆ１３１および専用回線６を介して電子マネーサーバ８との間でデータ通信を行う。また、制御部１１は、通信Ｉ／Ｆ１３２および接続回線５を介して、店舗サーバ２、ＰＯＳ端末３、電子マネーＲＷ４との間でデータ通信を行う。

また、制御部１１には、バス１２およびＩ／Ｏ機器制御部１４を介して、キーボード１５、表示器１６、プリンタ１７、ＨＤＤ１８等が接続されている。ＨＤＤ１８は、ショッピングセンター内の店舗サーバ２またはＰＯＳ端末３から送信された電子マネー取引データを格納する取引データファイル１８１を備えている。次に、テナント管理サーバ１の制御部１１が実行する本実施形態のプログラムについて説明する。

なお、本実施形態のテナント管理サーバ１で実行されるプログラムは、ＲＯＭ等に予め組み込まれて提供される。本実施形態のテナント管理サーバ１で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

さらに、本実施形態のテナント管理サーバ１で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態のテナント管理サーバ１で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

本実施形態のテナント管理サーバ１で実行されるプログラムは、図４に示すように、表示制御部５１、データ受信部５２、入力受付部５３、データ管理部５４を含むモジュール構成となっている。実際のハードウェアとしてはＣＰＵが上記記憶媒体（ＲＯＭ）から本実施形態のプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされる。そして、ＣＰＵが主記憶装置上に上記各部を生成する。次に、各部の機能について概略的に説明する。

表示制御部５１は、表示器１６に出力する表示データを生成し、各種表示画面の表示動作を制御する。例えば、表示制御部５１は、業務内容を選択する業務選択画面、電子マネー未了明細確認画面２０１（図５、図６、図８参照）、電子マネー取引明細入力画面２０２（図９、図１０、図１１参照）、電子マネー取引明細表示画面２０３（図１２参照）等の表示処理を制御する。表示画面の構成例および画面遷移例については後述する。

データ受信部５２は、ショッピングセンター内の店舗サーバ２、ＰＯＳ端末３から送信された電子マネー取引データを受信し、取引データファイル１８１に格納する。

入力受付部５３は、キーボード１５に対する入力操作、あるいはマウス等、その他の入力インタフェースを介した入力操作を受付ける。また、入力受付部５３は、表示制御部５１が表示する各種ＵＩ（ユーザインタフェース）画面に対する入力操作、編集操作を受付ける。

データ管理部５４は、データ受信部５２が受信した電子マネー取引データを管理する処理を実行する。また、データ管理部５４（発番手段）は、取引が成立していた未了取引の取引データに対し、電子マネーブランドが発番する伝票番号とは構成の異なる伝票番号を発番する。

次に、テナント管理サーバ１が生成する表示画面の構成例と、画面遷移例について説明する。

・電子マネー未了明細確認画面２０１の構成例
図５、図６、図８は、電子マネー未了明細確認画面２０１の画面構成例を示す図である。電子マネー未了明細確認画面２０１は、未了取引の取引データ（即ち、明細）を一覧表示する一覧画面である。デベロッパの担当者は、当該画面を表示させることにより、ショッピングセンター内で所定期間内に発生した未了取引を全件確認することができ、また、当該画面を用いて、電子マネーブランドへの問合せ業務の進行状況を管理することができる。

図５に示すように、電子マネー未了明細確認画面２０１には、表示対象とする取引データの取引日時の入力を受付ける取引日時入力欄２０１０が設けられている。また、同画面には、未了取引に関する確認状態別に取引データを表示させるために、確認状態の選択を受付けるチェックボックス２０１１が設けられている。

なお、「確認状態」とは、デベロッパが電子マネーブランドに未了取引に関する問合せをする際に、その問合せの進行状況を示す情報のことである。即ち、未了取引が実際は成立していたか不成立であったかについて、デベロッパが電子マネーブランドに確認を取る業務に際して、その確認作業の進行状況を「確認状態」という。

例えば、デベロッパの担当者が未了取引について電子マネーブランドに何らアクションを起こしていない段階に対しては、未処理を示す「未」を確認状態として設定すればよい。また、デベロッパの担当者が未了取引について電子マネーブランドに問合せをし、電子マネーブランドからの回答を待っている段階に対しては、確認状態として「待ち（回答待ち）」と設定すればよい。また、デベロッパの担当者が未了取引について電子マネーブランドに問い合わせた結果、電子マネーブランドから当該取引は電子マネーの引き去りがあったと応答を受けた場合には、確認状態として、確認が取れたことを示す「済」とともに、「済（引去有り）」などと設定すればよい。あるいは問合せの結果、電子マネーの引き去りが行われなかった場合、即ち、料金授受が成立しなかったことが判別した場合には、確認状態として「済（引去無し）」などと設定すればよい。

また、電子マネー未了明細確認画面２０１には、未了取引の発生場所を選択する発生場所選択欄２０１２が設けられている。発生場所の選択肢としては、例えばテナント全てを選択する選択肢、あるいは、分野別（レストラン、アパレル等）、あるいは、フロア別にテナントを選択する選択肢、あるいは、テナントを個別に選択する選択肢などがある。また、電子マネー未了明細確認画面２０１には、未了取引が発生した電子マネーブランドの名称（企業名称）を選択する選択欄２０１３が設けられている。

尚、各選択肢のデフォルト表示としては、取引日時入力欄２０１０に当日の営業時間が設定され、確認状態としてはすべてのチェックボックス２０１１にチェックが入り、発生場所選択欄２０１２および選択欄２０１３はすべての選択肢を含む「全て」が選択された状態としておくとよい。

テナント管理サーバ１のオペレータは、取引日時入力欄２０１０、チェックボックス２０１１、発生場所選択欄２０１２、選択欄２０１３のそれぞれに選択操作を行った後、表示ボタン２０１４を操作する。

入力受付部５３は、表示ボタン２０１４の操作を受付けると、電子マネー未了明細確認画面２０１の各選択項目で設定された検索条件を受付ける。データ管理部５４は、受付けた検索条件を用いて取引データファイル１８１内の電子マネー未了取引にかかるデータを検索する。取引データファイル１８１には正常成立した取引データも併せて格納されているので、データ管理部５４は、伝票番号が付されていない、未了取引の取引データに限定して検索処理を行う。表示制御部５１は、検索結果として抽出された未了取引の取引データ（未了取引データ）を検索結果表示領域２０１５に表示する。

図５に示すように、検索結果表示領域２０１５には、伝票番号の付されていない未了取引の取引データが１行ずつ表示される。データ構成は特に限定されないが、図５の例では、取引データとして、上述した「確認状態」、電子マネーＲＷ４の識別コードである「ＩＦ機器コード」、取引日時、業務区分が含まれる。また、取引データとして、「取引金額」、引き去り前の電子マネー残高である「取引前金額」、電子マネーブランドを識別するための「企業コード」、電子マネーブランドの名称である「企業名称」が含まれる。また、取引データとして、電子マネーユーザの識別情報である「会員番号」、電子マネー媒体の識別情報である「ＲＷＩＤ」、電子マネーＲＷの名称である「ＩＦ機器名称」などが含まれる。

テナント管理サーバ１のオペレータが、編集したい取引データ２０１６をキーボード１５のカーソル移動などによって選択し、キーボード１５のリターンキー等で確定すると、表示制御部５１は、カーソルが置かれた行の取引データを編集受付領域２０１７に表示する。

図６は、選択された取引データ２０１６を編集受付領域２０１７にコピー表示した例を示す図である。編集受付領域２０１７に移転表示された各項目は、キーボード１５等の入力インタフェースを介して編集可能に構成されている。入力受付部５３は、編集受付領域２０１７の各項目への編集操作、入力操作を受付け、表示制御部５１は受付けた編集内容を表示に反映する。また、編集受付領域２０１７の「確認状態」の項目には、プルダウンメニュー２０１８が設けられている。

図７は、展開されたプルダウンメニュー２０１８の表示例を示す図である。プルダウンメニュー２０１８は、上述した各確認状態を選択する選択肢として、「未」、「待ち」、「済（引去有り）」、「済（引去無し）」の選択項目を設けておくことができる。尚、図７に示した選択項目以外の項目を増設したり、選択項目の表示名を上記４つ以外に変更可能に構成したりしてもよい。このようにプルダウンメニュー２０１８を介して確認状態を設定できるとしたので、デベロッパで複数の担当者が交替で業務を行うような場合であっても、統一された選択肢により進行状況を分かり易く管理することができ、業務の効率向上を図ることができる。

また、本実施形態では、編集受付領域２０１７を検索結果表示領域２０１５の下部に設けて、検索結果とは表示領域を別にして編集対象とする取引データを見やすくし、これにより作業負担の軽減を図った。テナント管理サーバ１のオペレータは、編集受付領域２０１７に移行したデータに集中して、取引データの編集作業を行うことができるので、作業効率の向上と負担軽減とを図ることができる。

尚、ここでは、編集受付領域２０１７を検索結果表示領域２０１５の下部に設け、検索結果とは表示領域を別に設けたが、実施形態はこれに限らない。その他の例として、入力受付部５３は、検索結果表示領域２０１５の各行から直接、編集を受付けるとしてもよい。

図６において、入力受付部５３は、確定ボタン２０１９の選択操作を受付けると、編集受付領域２０１７に設定された各項目の入力を確定する。表示制御部５１は、図８に示すように、確定された各項目の入力内容を、検索結果表示領域２０１５における元の（即ち編集対象として選択されていた）取引データ２０１６に反映して表示を更新する。また、表示制御部５１は、編集受付領域２０１７の表示をクリアする。

即ち、図６〜図８の例では、図６の検索結果表示領域２０１５の８行目において、確認状態は「未」であったが、プルダウンメニュー２０１８から確認状態を「済（引去有り）」と変更した編集内容が、図８の検索結果表示領域２０１５の８行目の確認状態に反映されている。

・電子マネー取引明細入力画面２０２（図９、図１０、図１１参照）の構成例
図９、図１０、図１１は、電子マネー取引明細入力画面２０２の画面構成例を示す図である。電子マネー取引明細入力画面２０２は、取引データ（取引明細）の入力業務を支援するＵＩ画面であり、データ受信部５２が受信した取引データを編集可能であるとともに、新たな取引データを手入力にて入力できるＵＩ画面である。

電子マネーブランドへの問合せによって、電子マネーの引き去りがあり、未了とラベリングされていた取引が成立していたことの確認がとれると、デベロッパは当該取引データを、正常取引として扱い、その売上を売上合計に組み込む必要がある。従って、上述のように、確認状態を「済（引去有り）」とした未了取引の取引データは、新たな正常取引の取引データとしてデータファイルに編入する必要がある。

従来は、取引データの入力画面から取引データを新規に入力し、登録していたが、本実施形態では当該業務の効率化、簡便化を図り、電子マネー未了明細確認画面２０１の入力ボタン２０３０が操作された際に、電子マネー取引明細入力画面２０２をワンアクションで開くとした。即ち、図８に示すように、８行目の取引データ２０１６が選択された状態で入力ボタン２０３０が選択操作されると、表示制御部５１は、図９に示す電子マネー取引明細入力画面２０２に表示を切替える。

尚、電子マネーの引き去りがあった場合にのみ、取引データの入力業務を行なえばよいので、入力ボタン２０３０は、確認状態のプルダウンメニュー２０１８が「済（引き去り有り）」である場合にのみ選択可能とするとよい。

図９に示すように、電子マネー取引明細入力画面２０２においては、電子マネーの取引明細、即ち、電子マネー取引データについて、入力を行うことができる。図９に例示するように、電子マネー取引明細入力画面２０２では、勘定日付を選択し（行数の２行目を参照）、選択した勘定日付の取引データを一括して管理し、入力、編集を受付けることができる。

表示制御部５１は、電子マネー未了明細確認画面２０１（図８参照）で選択された状態で入力ボタン２０３０が操作された未了取引の取引データ２０１６を、電子マネー取引明細入力画面２０２の入力受付領域２０２１に移行して表示する。入力受付領域２０２１では、取引データの入力、編集を受付けることができる。編集可能な項目としては、図９に示すように、白背景の項目は編集可能な項目である。例えば、電子マネーＲＷ４の識別情報である「ＩＦ機器コード」、電子マネーブランドの識別情報である「企業コード」、電子マネーの識別情報である「ＲＷＩＤ」、テナントで客がＩＣカード等をタッチした日時である「取引日時」、「業務区分」、「取引金額」、「メモ」等について編集可能とすればよい。尚、編集可能な項目は、デベロッパ側で適宜変更可能とし、設定を変更できるように構成してもよい。

尚、入力受付領域２０２１にて、「精算日時」とは、テナントのＰＯＳ端末３または店舗サーバ２が精算業務を行って、例えば１日分の取引データをテナント管理サーバ１に送信した日時のことである。当該日時については、送信日時を示すものであるからデータは固定とし編集は受付けなくてよい。

入力受付領域２０２１はメモ入力欄２０２４を備える。上述のように電子マネー未了明細確認画面２０１から移行された取引データに関しては、メモ入力欄２０２４に「未了明細から入力」などと当該データが未了取引であったことを示す情報をデフォルトとして予め入力しておくとよい。

また、図９に示すように、入力受付領域２０２１には、伝票番号を入力する伝票番号入力欄２０２２が設けられ、当該入力欄に併設して発番ボタン２０２３が設けられている。入力受付部５３が発番ボタン２０２３の選択操作を受付けると、データ管理部５４は、入力受付領域２０２１に表示された取引データに、当該取引データを一意に特定する伝票番号を発番する。表示制御部５１は、データ管理部５４が発行した伝票番号を、図９に示すように、伝票番号入力欄２０２２に表示出力する。

このように、本実施形態では、未了取引から移行された未発番の取引データに対して、当該取引を一意に特定する伝票番号を自動的に発番する。従来、伝票番号の発番は、デベロッパが独自に定めた発番ルール等に従って担当者が逐一決定し入力していた。これに対して、本実施形態によれば、発番にかかる手間を省くことができ、未了取引を他の正常取引の取引データのデータファイルに組み込む際の業務を簡便化することができる。

・伝票番号の発番方法
従来一般的に、電子マネー取引に対しては、電子マネーＲＷ４あるいは電子マネーサーバ８が、正常取引の取引データを生成時に伝票番号を発番する。尚、以下では簡単のため、このような伝票番号を「電子マネーブランドが発番した伝票番号」と総称することとする。正常取引の伝票番号は、電子マネーブランドがそれぞれ独自の伝票番号構成および発番ルールを運用しているものの、伝票番号の桁数は電子マネーブランドによらず１０桁以下の英数字と統一されている。

そこで、本実施形態では、電子マネーブランドが発番する最大１０桁の伝票番号と、テナント管理サーバ１で発番する伝票番号が重複しないよう、１１桁の伝票番号を新たに生成し、未了取引の伝票番号に対して発番する。

一例として、データ管理部５４は、伝票番号の先頭の１桁に所定の英数字（例えば、「１」）を用い、その後の１０桁に所定年月日から発番ボタン２０２３を操作した時間までの経過秒数を含めて伝票番号を生成する。例えば、先頭１桁目の英数字として数字の「１」を用いる場合は、１１桁の１００００００００００に経過秒数を加算した値を伝票番号とすればよい。尚、経過秒数が１１桁であれば、加算の結果、先頭１桁目は「２」となる。

例えば、経過秒数をカウントする基準日時を２０００年１月１日の０：００：００と設定した場合であって、発番ボタン２０２３を操作した日時が２０１７年８月１７日１０：０５：１８であれば、経過秒数は、５５６７１１５１８秒（９桁）である。この場合にデータ管理部５４は、１１桁の１００００００００００に５５６７１１５１８（９桁）を加算して、伝票番号を１０５５６７１１５１８（１１桁）として発番する。

また別の例として、発番ボタン２０２３の操作日時が２１００年１月１日０：０１：０１であれば、経過秒数は、３１５５７６００６１秒（１０桁）である。この場合にデータ管理部５４は、１１桁の１００００００００００に３１５５７６００６１（１０桁）を加算して、伝票番号を１３１５５７６００６１（１１桁）として発番する。

尚、発番する伝票番号は１１桁以上であってもよい。本実施形態では、電子マネーブランド各社が発番する伝票番号より多い桁数で伝票番号を発番するため、電子マネーブランド（あるいは電子マネーＲＷ４）が発番する伝票番号と重複せず、かつ、取引データを一覧表示した際に識別しやすくできる。

また別の例として、電子マネーブランドが発番する伝票番号とは異なるデータ構成の伝票番号を発番し、重複を避けるとともに、識別しやすくするとしてもよい。例えば、桁数変更によらず、先頭または末尾の英数字に、未了取引であることを識別可能な文字（例えば、Ｄなど）を含め、電子マネーブランドが発番する伝票番号との重複を避けてもよい。例えば、先頭文字にＤを用い、未了取引に対して通番を付番するとすれば、伝票番号はＤ００００００１２３（１０桁）となる。

以上のように、本実施形態では、電子マネーＲＷ４あるいは電子マネーサーバ８が伝票番号を発行できず伝票番号を有していなかった未了取引の取引データに対して、発番ボタン２０２３を操作すれば当該取引を一意に特定でき、かつ、正常取引とは識別が容易な伝票番号を自動的に生成することができる。

入力受付部５３は、図１０において確定ボタン２０２５の選択操作を受付けると、入力受付領域２０２１に表示されている取引データの入力を確定し、各項目の入力を受付ける。表示制御部５１は入力が確定された取引データ２０２６（図１１参照）を、図１１に示すように、電子マネー取引明細入力画面２０２の取引明細一覧領域２０２７に表示し、入力受付領域２０２１の各項目については表示をクリアする。

上述のように伝票番号が発番された取引データは、成立した取引に対する処理の対象として扱われ、以下に示す電子マネー取引明細表示画面２０３（図１２参照）にて他の取引データとともに表示されることとなる。

・電子マネー取引明細表示画面２０３（図１２参照）の画面構成例
図１２は、電子マネー取引明細表示画面２０３の画面構成例を示す図である。電子マネー取引明細表示画面２０３には、検索条件入力欄２０３１から設定された検索条件に合致する取引データが一覧表示される。即ち、入力受付部５３は、検索条件入力欄２０３１に入力された検索条件を受付ける。データ管理部５４は、入力受付部５３が受付けた検索条件に合致する取引データを、取引データファイル１８１から抽出する。表示制御部５１は、データ管理部５４が抽出した取引データを、一覧表示領域２０３２に表示出力する。上述のように、電子マネー取引明細入力画面２０２にて伝票番号が発番された取引データ２０３３は、図１２に示すように電子マネー取引明細表示画面２０３の一覧表示領域２０３２に表示される。

本実施形態において、未了取引由来の取引データに対して発番される伝票番号は電子マネーブランドが発番する最大１０桁の伝票番号より多い１１桁で構成される。従って、図１１の電子マネー取引明細入力画面２０２の取引明細一覧領域２０２７、および、図１２の電子マネー取引明細表示画面２０３の一覧表示領域２０３２において、伝票番号を見れば、データ管理部５４が発番した伝票番号であることを容易に判別することができる。

即ち、本実施形態の発番方法によれば、伝票番号を見ればその伝票番号がテナント管理サーバ１により独自に発番された伝票番号であることを容易に判別可能である。

また、図１２に示すように、電子マネー取引明細表示画面２０３には、一覧表示領域２０３２に表示された取引データ全件分の、合計件数と、取引合計金額とが明細情報２０３４として表示される。即ち、電子マネー取引明細表示画面２０３には、上述した処理を経て、未了取引であった電子マネー取引のうち、決済が成立している取引が移行されて表示される。そして、データ管理部５４は、このような未了取引由来の取引についても、検索条件入力欄２０３１に設定した検索条件で抽出した他の取引と合わせて、合計件数と取引合計金額とを合算する。

このように、本実施形態によれば、未了取引由来の取引データであっても、他の正常取引の取引データと同様に、各種売上データ処理の処理対象として含めることができる。

次に、テナント管理サーバ１の動作例について説明する。

図１３は、テナント管理サーバ１における取引データ管理業務の動作例を示すフローチャートである。テナント管理サーバ１の表示制御部５１は、業務選択画面（不図示）を表示器１６に表示する（ステップＳ１）。業務選択画面には、選択可能な業務メニューとして、電子マネーの未了明細確認業務、電子マネーの取引明細入力業務、電子マネーの明細表示業務などの業務を選択するメニューボタンが設けられている。入力受付部５３は、キーボード１５等の入力インタフェースを介していずれかのメニューボタンの選択操作を受付ける（ステップＳ２、Ｓ６、Ｓ９）。

入力受付部５３が電子マネーの未了明細確認業務のメニューボタンの選択操作を受付けると（ステップＳ２：Ｙｅｓ）、表示制御部５１は、電子マネーの電子マネー未了明細確認画面２０１（図５、図６、図８参照）を表示器１６に表示し、同画面に対する入力に基づき当該業務に関する処理を実行する（ステップＳ３）。データ管理部５４は上述したように、編集受付領域２０１７（図６参照）を介して、未了取引の取引データに対する編集操作を受付ける。

ステップＳ２：ＮｏであればステップＳ６に移行し、入力受付部５３が電子マネーの取引明細入力業務のメニューボタンの選択操作を受付ける（ステップＳ６：Ｙｅｓ）と、表示制御部５１は、電子マネーの電子マネー取引明細入力画面２０２（図９、図１０、図１１参照）を表示器１６に表示し、同画面に対する入力に基づき当該業務に関する処理を実行する（ステップＳ７）。

電子マネー未了明細確認画面２０１（図５、図６、図８参照）において終了ボタン２０３５（例えば、図５参照）が操作されると（ステップＳ４：Ｙｅｓ）、表示制御部５１は、業務選択画面に表示を戻す（ステップＳ１）。ステップＳ４：Ｎｏであり、入力受付部５３が電子マネー未了明細確認画面２０１において入力ボタン２０３０（例えば、図８参照）の選択操作を受付けると（ステップＳ５：Ｙｅｓ）、表示制御部５１は電子マネーの電子マネー取引明細入力画面２０２（図９参照）に表示を遷移する（ステップＳ７）。この際に、表示制御部５１は、電子マネー未了明細確認画面２０１（図８参照）で選択されている取引データ２０１６を、電子マネー取引明細入力画面２０２の入力受付領域２０２１に移行して表示する。データ管理部５４は、入力受付領域２０２１を介して取引データの入力、編集を受付ける。また、データ管理部５４は、入力受付領域２０２１の発番ボタン２０２３が操作されると、上述した発番方法により未了取引由来の取引データに伝票番号を発番する（ステップＳ７）。

電子マネー取引明細入力画面２０２において、終了ボタン２０３５（図１１参照）が操作されると（ステップＳ８：Ｙｅｓ）、表示制御部５１は、業務選択画面に表示を戻す（ステップＳ１）。ステップＳ８：ＮｏならばステップＳ７に戻る。

ステップＳ６：Ｎｏであり、入力受付部５３が業務選択画面において、電子マネーの明細表示業務のメニューボタンの選択操作を受付けると（ステップＳ９：Ｙｅｓ）、表示制御部５１は、電子マネー取引明細表示画面２０３（図１２参照）を表示器１６に表示する。表示制御部５１は、検索条件入力欄２０３１に設定された検索条件に基づき、検索条件入力欄２０３１に検索結果の取引データを一覧表示する。また、データ管理部５４は、検索条件に合致した取引の件数と取引合計金額を算出する。表示制御部５１は、明細情報２０３４に算出された合計件数と取引合計金額を表示する（ステップＳ１０）。

ステップＳ９：Ｎｏであれば、ステップＳ１に移行する。電子マネー取引明細表示画面２０３において、終了ボタン２０３５（図１２参照）が操作されると（ステップＳ１１：Ｙｅｓ）、表示制御部５１は、業務選択画面に表示を戻す（ステップＳ１）。ステップＳ１１：ＮｏであればステップＳ１０に戻る。

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

例えば、上述では、入力受付領域２０２１に発番ボタン２０２３を設けて、入力受付領域２０２１に表示された一の取引データに対して発番の指示操作を受付けるとしたが、実施形態はこれに限定されない。その他の例として、検索結果表示領域２０１５の各行にそれぞれ発番ボタンを設けて、発番の指示操作を受付けるとしてもよい。

以上説明した通り、本実施形態によれば、電子マネーの未了取引という電子マネー取引特有の事態が発生した際に、当該未了取引の取引データを管理する際のデベロッパ側の担当者の業務を簡便化し、業務の効率向上と負担軽減とを図ることができる。また、電子マネーブランドへの問合せの結果、取引が成立していた未了取引について、電子マネーＲＷ４から送信された伝票番号未発番の取引データを利用して、正常取引時の取引データを効率よく生成し、他の取引データと同様に利用可能な状態にすることができる。このように、上記実施形態によれば、電子マネーの未了取引について、データ管理業務の効率を向上することができる。

１ テナント管理サーバ
５１ 表示制御部
５２ データ受信部
５３ 入力受付部
５４ データ管理部
１８１ 取引データファイル
２０１ 電子マネー未了明細確認画面
２０２ 電子マネー取引明細入力画面
２０３ 電子マネー取引明細表示画面
２０１７ 編集受付領域
２０２１ 入力受付領域
２０２２ 伝票番号入力欄
２０２３ 発番ボタン

特開２０１３−１８６６６６号公報

Claims (6)

1. テナントの情報処理装置から、電子マネーの未了取引の取引データを受信する受信手段と、
   前記未了取引の取引データを一覧表示する一覧画面を生成し、表示出力する一覧画面表示手段と、
   前記未了取引の取引データに対する編集操作を受付ける編集受付手段と、
   取引が成立していた前記未了取引の取引データに対し、電子マネーブランドが発番する伝票番号とは構成の異なる伝票番号を発番する発番手段と、
   を備える情報処理装置。
2. 前記発番手段は、前記未了取引の取引データに対し、電子マネーブランドが発番する伝票番号より桁数の多い伝票番号を発番する、請求項１に記載の情報処理装置。
3. 前記一覧画面において、編集対象とする前記取引データの選択を受付ける選択受付手段と、
   前記選択受付手段が選択を受付けた前記取引データを、編集操作を受付ける編集領域に移行して表示する編集領域表示手段と、
   前記編集領域に移行して表示した前記取引データに対し、前記伝票番号を発番する指示操作を受付ける発番指示受付手段と、を更に備え、
   前記発番手段は、前記発番指示受付手段が前記指示操作を受付けると、前記編集領域に移行して表示した前記取引データに対し、電子マネーブランドが発番する伝票番号とは構成の異なる伝票番号を発番する、請求項１または２に記載の情報処理装置。
4. 前記発番手段は、前記取引データに付す伝票番号を、電子マネーが発番する伝票番号より１桁多い伝票番号とし、基準年月日からの経過秒数を用いて当該伝票番号を構成する、請求項１ないし３のいずれか１つに記載の情報処理装置。
5. 前記編集領域において、前記選択受付手段が選択を受付けた前記取引データについて、電子マネーブランドへの確認状況を選択入力する選択入力手段を更に備えた、請求項３に記載の情報処理装置。
6. 情報処理装置を制御するプログラムを、
   テナントの情報処理装置から、電子マネーの未了取引の取引データを受信する受信手段と、
   前記未了取引の取引データを一覧表示する一覧画面を生成し、表示出力する一覧画面表示手段と、
   前記未了取引の取引データに対する編集操作を受付ける編集受付手段と、
   取引が成立していた前記未了取引の取引データに対し、電子マネーブランドが発番する伝票番号とは構成の異なる伝票番号を発番する発番手段と、
   して機能させるプログラム。

Images