(57)【要約】【課題】電子エントリの導入環境下において、伝票の取扱い業務を効率的で的確なものとする。【解決手段】伝票管理システム１００において、伝票に基づく金融取引情報を格納する記憶装置１０１と、顧客持参の伝票に印字されたコードの読み取り結果を所定装置より取得し、この読み取り結果が示す当該伝票の識別情報を取引情報データベース１２５の金融取引情報それぞれに照合して、当該識別情報の登録未済を判定し、該当識別情報が取引情報データベース１２５に登録済みであった場合、当該伝票に関する金融取引の所定手続を回避する処理を実行する演算装置１０４とを含む構成とする。【選択図】図２
2018151817.tif 000002
【特許請求の範囲】
【請求項１】
伝票に基づく金融取引情報を格納する記憶装置と、
顧客持参の伝票に印字されたコードの読み取り結果を所定装置より取得し、前記読み取り結果が示す当該伝票の識別情報を、前記金融取引情報に照合して、当該識別情報の登録未済を判定し、該当識別情報が登録済みであった場合、当該伝票に関する金融取引の所定手続を回避する処理を実行する演算装置と、
を含むことを特徴とする伝票管理システム。
【請求項２】
前記演算装置は、
前記判定の結果、該当識別情報が未登録であった場合、前記読み取り結果が示す取引内容と、当該識別情報とを対応付け、前記金融取引情報として記憶装置に格納する処理を更に実行するものである、
ことを特徴とする請求項１に記載の伝票管理システム。
【請求項３】
前記演算装置は、
顧客持参の複数の伝票それぞれに関する前記読み取り結果の取得機会ごとの、前記金融取引情報の格納に際し、前記識別情報である、当該伝票を一意に特定する管理情報と、当該伝票による金融取引を含む一連の金融取引群に関するグループ情報と、前記金融取引群における当該伝票による金融取引の処理順序の情報とを、前記取引内容と対応付けて、前記金融取引情報として記憶装置に格納し、
前記記憶装置に格納した前記金融取引情報のうち、グループ情報が同一の金融取引情報それぞれにおける前記処理順序の情報が、所定の整合性を示すか判定し、前記整合性の判定結果に応じて、当該金融取引群に関する所定処理を実行するものである、
ことを特徴とする請求項２に記載の伝票管理システム。
【請求項４】
前記演算装置は、
前記金融取引群に関する所定処理に際し、
前記整合性の判定結果が、前記金融取引群のいずれかの金融取引に対応した伝票の金融取引情報の未登録に基づく不整合を示すものであった場合、所定の警告情報を所定装置に出力して、前記不整合を許容する旨の通知を所定装置から取得した場合、前記金融取引群の金融取引のうち所定のもの、または前記不整合の原因となった金融取引以外のものに関して所定処理を実行するものである、
ことを特徴とする請求項３に記載の伝票管理システム。
【請求項５】
伝票に基づく金融取引情報を格納する記憶装置を備えた情報処理システムが、
顧客持参の伝票に印字されたコードの読み取り結果を所定装置より取得し、前記読み取り結果が示す当該伝票の識別情報を、前記金融取引情報に照合して、当該識別情報の登録未済を判定し、該当識別情報が登録済みであった場合、当該伝票に関する金融取引の所定手続を回避する処理を実行する、
ことを特徴とする伝票管理方法。
【請求項６】
前記情報処理システムが、
前記判定の結果、該当識別情報が未登録であった場合、前記読み取り結果が示す取引内容と、当該識別情報とを対応付け、前記金融取引情報として記憶装置に格納する処理を更に実行する、
ことを特徴とする請求項５に記載の伝票管理方法。
【請求項７】
前記情報処理システムが、
顧客持参の複数の伝票それぞれに関する前記読み取り結果の取得機会ごとの、前記金融
取引情報の格納に際し、前記識別情報である、当該伝票を一意に特定する管理情報と、当該伝票による金融取引を含む一連の金融取引群に関するグループ情報と、前記金融取引群における当該伝票による金融取引の処理順序の情報とを、前記取引内容と対応付けて、前記金融取引情報として記憶装置に格納し、
前記記憶装置に格納した前記金融取引情報のうち、グループ情報が同一の金融取引情報それぞれにおける前記処理順序の情報が、所定の整合性を示すか判定し、前記整合性の判定結果に応じて、当該金融取引群に関する所定処理を実行する、
ことを特徴とする請求項６に記載の伝票管理方法。
【請求項８】
前記情報処理システムが、
前記金融取引群に関する所定処理に際し、
前記整合性の判定結果が、前記金融取引群のいずれかの金融取引に対応した伝票の金融取引情報の未登録に基づく不整合を示すものであった場合、所定の警告情報を所定装置に出力して、前記不整合を許容する旨の通知を所定装置から取得した場合、前記金融取引群の金融取引のうち所定のもの、または前記不整合の原因となった金融取引以外のものに関して所定処理を実行する、
ことを特徴とする請求項７に記載の伝票管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、伝票管理システムおよび伝票管理方法に関するものであり、具体的には、電子エントリの導入環境下において、伝票の取扱い業務を効率的で的確なものとする技術に関する。
【背景技術】
【０００２】
金融機関の営業店において、事務効率化や顧客満足度向上の施策の一環として、従来の紙伝票への記入方式に代わり、電子記帳台による電子エントリを導入する動きがある。
【０００３】
このような事務効率化や顧客満足度向上に関連する従来技術としては、例えば、営業店に設置された顧客が操作する入力端末及び窓口係が操作する窓口端末と、ホストコンピュータからなる取引受付システムであって、前記入力端末には、取引要求を行う顧客の本人認証情報を受け付けて、前記ホストコンピュータに前記本人認証情報の認証要求を送信する認証要求送信手段と、前記ホストコンピュータから、前記認証要求に対する認証結果を受信する認証結果受信手段と、取引要求の入力画面を表示して、前記顧客が要求する取引内容と、前記取引内容を識別するために顧客が指定した識別番号の入力を受け付ける取引内容受付手段と、前記認証結果が本人であると認証されたものである場合には、前記取引内容及び前記識別番号を、前記ホストコンピュータに送信する取引内容送信手段と、前記取引内容が前記ホストコンピュータにおいて処理可能として受け付けられると、前記ホストコンピュータから前記取引内容を識別するための取引番号を受信する取引番号受信手段と、前記取引番号を受信すると、持ち運び可能な外部記憶媒体に前記取引番号を記憶させること、又は取引用伝票に前記取引番号を示す識別用コードを印字することにより、前記取引番号を出力する取引番号出力手段と、を備え、前記窓口端末には、前記外部記憶媒体から読み出した取引番号、又は前記識別用コードを読み取って認識した取引番号を受け付ける取引番号受付手段と、前記顧客が指定した識別番号を受け付ける識別番号受付手段と、前記取引番号及び前記識別番号を、前記ホストコンピュータに送信する取引番号送信手段と、前記ホストコンピュータから、前記取引番号に対応する取引内容を受信する取引内容受信手段と、を備え、前記ホストコンピュータは、前記認証要求送信手段から認証要求を受信すると、前記本人認証情報により本人認証を行った認証結果を前記入力端末に送信する認証結果送信手段と、前記取引内容送信手段から取引内容を受信すると、前記取引内容の受け付けの可否を判定して、受け付けが可能である場合には前記取引内容を識別するための取引番号を採番し、前記取引番号を前記入力端末に送信する取引番号送信手段と、前記取引番号が付された取引内容について、前記取引番号と、前記取引内容送信手段から受信した識別番号とを関連付けて格納する取引内容格納手段と、前記取引番号送信手段から取引番号及び識別番号を受信すると、前記識別番号を前記取引内容格納手段において前記取引番号に関連付けられた識別番号と対比し、識別番号が一致する場合には前記取引番号に関連付けられた取引内容の処理を可能と判定して、前記取引内容を前記窓口端末に送信する取引内容送信手段と、を備えることを特徴とする取引受付システム（特許文献１参照）などが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１３３５２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述のように電子エントリの仕組みを導入することで、従来には無かっ
た懸念も生じている。
【０００６】
この場合、顧客は電子記帳台を利用して所望の取引内容を入力し、一方、電子記帳台は、この顧客が入力した取引内容を所定のデータベースに登録すると共に、当該取引内容に応じた伝票データを伝票用紙に印字・出力する。上述の顧客は、こうして出力された伝票を窓口まで持参し、テラーによる手続に供する。
【０００７】
ところが、顧客によっては一度に持参する伝票枚数が数十枚規模になるケースもあり、区別のつきにくい多くの伝票中から誤った伝票をテラーに手交してしまい、同じ伝票が重複して処理対象とされるなど手違いが生じる恐れがあった。
【０００８】
また、複数枚の伝票を一連の正しい順序で処理すべき状況（例：口座に「入金」が完了後、該当口座から「振込」を実行、など）であるにも関わらず、顧客が一部の伝票を持参しなかった場合、該当顧客の所望取引は完遂出来ない事態になる。
そこで本発明の目的は、電子エントリの導入環境下において、伝票の取扱い業務を効率的で的確なものとする技術を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決する本発明の伝票管理システムは、伝票に基づく金融取引情報を格納する記憶装置と、顧客持参の伝票に印字されたコードの読み取り結果を所定装置より取得し、前記読み取り結果が示す当該伝票の識別情報を、前記金融取引情報に照合して、当該識別情報の登録未済を判定し、該当識別情報が登録済みであった場合、当該伝票に関する金融取引の所定手続を回避する処理を実行する演算装置と、を含むことを特徴とする。
【００１０】
また、本発明の伝票管理方法は、伝票に基づく金融取引情報を格納する記憶装置を備えた情報処理システムが、顧客持参の伝票に印字されたコードの読み取り結果を所定装置より取得し、前記読み取り結果が示す当該伝票の識別情報を、前記金融取引情報に照合して、当該識別情報の登録未済を判定し、該当識別情報が登録済みであった場合、当該伝票に関する金融取引の所定手続を回避する処理を実行する、ことを特徴とする。
【発明の効果】
【００１１】
本発明によれば、電子エントリの導入環境下において、伝票の取扱い業務を効率的で的確なものとできる。
【図面の簡単な説明】
【００１２】
【図１】本実施形態の伝票管理システムを含むネットワーク構成図である。
【図２】本実施形態における伝票管理システムのハードウェア構成例を示す図である。
【図３】本実施形態の取引情報データベースのデータ構成例を示す図である。
【図４】本実施形態における伝票管理方法のフロー例１を示す図である。
【図５】本実施形態における画面例１を示す図である。
【図６】本実施形態のユニークキーのデータ構成例を示す図である。
【図７】本実施形態の伝票の構成例を示す図である。
【図８】本実施形態における伝票管理方法のフロー例２を示す図である。
【図９】本実施形態における伝票管理方法のフロー例３を示す図である。
【発明を実施するための形態】
【００１３】
−−−システム構成−−−
【００１４】
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の
伝票管理システムたる取引情報サーバ１００を含むネットワーク構成図である。図１に示す取引情報サーバ１００は、電子エントリの導入環境下において、伝票の取扱い業務を効率的で的確なものとするコンピュータシステムである。
本実施形態の取引情報サーバ１００は、セキュアなネットワーク１０を介して、金融機関の営業店におけるテラー端末４００と通信可能に接続されている。
【００１５】
このテラー端末４００は、顧客持参の伝票５０上に印字されたコード（例：二次元コード）に対し、所定の読取り装置４１０によるスキャン処理を実行し、当該コードが示す各種情報を取得する端末である。この各種情報とは、伝票５０に記載された取引内容と、詳細は後述するユニークキーとを含む情報である。テラー端末４００は、こうした各種情報を、取引情報（金融取引情報）として、上述の取引情報サーバ１００にアップロードする。
【００１６】
なお、上述の伝票５０は、顧客により事前作成されたものである。この場合の顧客は、ユーザ端末２００を操作し、インターネットなどの適宜なネットワーク１１を介してサービス提供サーバ３００にアクセスし、その機能を利用することで、当該伝票５０を作成する。なお、ユーザ端末２００としては、顧客の居所等に配置されたＰＣ等に限定せず、携帯端末や、或いは営業店内に設置の電子記帳台であってもよい。
【００１７】
他方、上述の顧客に対して、伝票作成サービスを提供するのがサービス提供サーバ３００である。このサービス提供サーバ３００は、アクセスしてきたユーザ端末２００に対し、顧客所望の金融取引に関する情報入力画面を送信し、この情報入力画面を介して、伝票５０に印字すべき取引内容等の情報を取得する。
【００１８】
また、サービス提供サーバ３００は、ユーザ端末２００から得た各種情報のうち予め定めたもの（取引内容や現在日時等の各値のうち少なくともいずれか）を、所定ルールに沿って加工し、上述のユニークキーを生成する。サービス提供サーバ３００は、こうして得た、取引内容の情報（以後、取引情報）とユニークキーとを、適宜なコードジェネレータ３１０に与え、コードの印字用データを生成する。サービス提供サーバ３００は、上述の取引情報およびコードの印字用データを、ユーザ端末２００に送信することとなる。
【００１９】
この場合、ユーザ端末２００は、取引情報およびコードの印字用データを得て、これを、適宜な印刷装置に送信して伝票５０を出力する。当然ながら、印刷装置には伝票５０の印字用シートがセットされており、この印字用シート上、上述の取引情報とコードとが印字されることとなる。
−−−ハードウェア構成−−−
【００２０】
また、伝票管理システムたる取引情報サーバ１００のハードウェア構成は以下の如くとなる。図２は本実施形態の取引情報サーバ１００のハードウェア構成例を示す図である。
【００２１】
この場合、取引情報サーバ１００は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１０と接続してテラー端末４００との通信処理を担う通信装置１０５、を備える。
【００２２】
なお、記憶装置１０１内には、本実施形態の伝票管理システムとして必要な機能を実装する為のプログラム１０２に加えて、取引情報データベース１２５が少なくとも記憶されている。この取引情報データベース１２５の詳細については後述する。
−−−データ構造例−−−
【００２３】
続いて、本実施形態の伝票管理システム１００が用いるデータベース類について説明する。図３に、本実施形態における取引情報データベース１２５の一例を示す。
【００２４】
本実施形態の取引情報データベース１２５は、テラー端末４００によって上述の伝票５０上のコードから読み取られた情報であって、伝票５０に記載された取引情報およびユニークキーを格納するデータベースである。
【００２５】
そのデータ構造は、伝票５０それぞれを一意に特定する案件管理番号５２１をキーとして、当該伝票５０の取引情報５１が含む、入金や出金といった取引種類５１１、取引対象の口座番号５１２、および、取引対象の金額５１３と、ユニークキー５２が含む、グループ番号５２２および処理順序情報５２３と、ステータス５３０、といったデータを対応付けたレコードの集合体である。
【００２６】
なお、上述の値のうちステータス５３０は、当該レコードに対応する伝票５０に関する金融取引の処理状況を示す値である。例えば、「伝票登録待ち」、「勘定処理待ち」、「勘定処理中」、「勘定処理済」、といった値をとることになるが、その遷移概念については後述する。
−−−フロー例１−−−
【００２７】
以下、本実施形態における伝票管理方法の実際手順について図に基づき説明する。以下で説明する伝票管理方法に対応する各種動作は、伝票管理システム１００がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００２８】
図４は、本実施形態における伝票管理方法のフロー例１を示す図である。ここではまず、本実施形態の伝票管理方法の事前手順として、金融機関の顧客がユーザ端末２００を操作し、サービス提供サーバ３００の機能を利用して、伝票５０を作成する手順について説明する。
【００２９】
ここで、上述の顧客は、ユーザ端末２００を操作し、ネットワーク１１を介してサービス提供サーバ３００にアクセスしたとする。この時、サービス提供サーバ３００は、ユーザ端末２００に対して、顧客所望の金融取引に関して情報入力を受け付けるための画面（図５の画面５００）を送信する（ｓ１０）。
【００３０】
一方、ユーザ端末２００は、上述の画面５００を受信してディスプレイ等の所定の表示装置に表示させ、顧客からの取引情報の入力を受け付ける（ｓ１１）。この取引情報には、取引対象の口座番号、希望する取引種類、取引の金額、一連の取引中での処理順序といった情報が含まれる。
【００３１】
また、ここで顧客が情報入力の対象とする取引は、１件のみとは限らず、顧客の保持する口座のうち或る口座Ａからの「出金」と、もう１つの口座Ｂからの「出金」と、これら各出金により得た合計金額の、もう１つの口座Ｃへの「入金」と、といった取引群のように、順次処理されるべき複数の取引も対象となる。
【００３２】
以後、本実施形態では、順次処理されるべき３件の取引について、当該顧客が情報入力したものとして説明を行う。この場合、顧客は、ユーザ端末２００を操作し、該当画面５００において、順次処理されるべき取引の件数「３」と、この３件の取引における各取引の処理順序とを、入力するものとする。
次に、ユーザ端末２００は、ｓ１１で得た、複数の取引それぞれに関する取引情報を、サービス提供サーバ３００に返信する（ｓ１２）。
【００３３】
他方、サービス提供サーバ３００は、上述のユーザ端末２００から複数の取引それぞれに関する取引情報を受信し、これら取引情報のメタデータから例えば現在日時の値を所定桁数だけ抽出し、これを該当取引情報に関する案件管理番号とする（ｓ１３）。このｓ１３の処理により、上述の一連の３つの取引それぞれの案件管理番号として、「００３４５」、「００３４６」、「００３４７」、の各値が特定されたとする。
【００３４】
また、サービス提供サーバ３００は、上述のように一連の取引として顧客から入力を受け付けた取引情報らに対し、所定ルールにてグループ番号を採番する（ｓ１４）。この採番のルールは、採番機会ごとに初期値をインクリメントするといった一般的なものを想定出来る。
【００３５】
次に、サービス提供サーバ３００は、ここまでの処理で得た、案件管理番号、グループ番号、および処理順序、の各値を連結させ、一連の取引それぞれのユニークキー（図６参照）を生成する（ｓ１５）。
【００３６】
続いてサービス提供サーバ３００は、ユーザ端末２００から各取引に関して得た、取引情報および上述のユニークキーとを、コードジェネレータ３１０に与え、一連の取引それぞれに関してコードの印字用データを生成する（ｓ１６）。
また、サービス提供サーバ３００は、一連の取引それぞれに関する、上述の取引情報およびコードの印字用データを、ユーザ端末２００に送信する（ｓ１７）。
【００３７】
一方、ユーザ端末２００は、取引情報およびコードの印字用データをサービス提供サーバ３００から受信し、これを、適宜な印刷装置に送信して伝票５０（図７参照）を出力する（ｓ１８）。上述の例の場合、ユーザ端末２００は、３件の取引それぞれに関する取引情報およびコードの印字用データを受信したため、３枚の伝票５０を印刷装置で出力することになる。このユーザ端末２００を操作していた顧客は、上述のように３枚の伝票５０を得て、金融機関の営業店に赴く。
−−−フロー例２−−−
【００３８】
続いて、上述のフロー例１のごとく作成された伝票５０に基づく、伝票管理方法の処理について説明する。この場合、計３枚の伝票５０を作成した上述の顧客は、金融機関の営業店を訪れ、持参の伝票５０を窓口のテラーに手交する。一方、このテラーは、顧客から受け取った伝票５０を、テラー端末４００の読取り装置４１０にセットし、伝票５０の紙面上に印字されたコード５３の読取り動作を行う。
【００３９】
図８は、本実施形態における伝票管理方法のフロー例２を示す図である。この場合、テラー端末４００は、最初に読取り対象となった１枚の伝票５０に関して、その紙面上に印字されたコード５３の読み取り結果を、読取り装置４１０から取得し、これを取引情報サーバ１００に送信する（ｓ１００）。
なお、上述の読取り結果には、該当伝票５０の、案件管理番号、グループ番号、および処理順序の各情報からなるユニークキーと、取引内容とを含んでいる。
【００４０】
次に、取引情報サーバ１００は、上述のテラー端末４００から読み取り結果を受信し、この読取り結果のうち、ユニークキーが含む当該伝票５０の案件管理番号を、取引情報データベース１２５に照合して、当該案件管理番号の登録未済を判定する（ｓ１０１）。
【００４１】
上述の判定の結果、該当案件管理番号が登録済みであった場合（ｓ１０２：ｎ）、取引
情報サーバ１００は、当該伝票５０に関する取引情報データベース１２５への登録処理を回避し、処理をｓ１０１に戻す。
【００４２】
他方、上述の判定の結果、該当案件管理番号が未登録であった場合（ｓ１０２：ｙ）、取引情報サーバ１００は、上述の読取り結果が示す取引内容とユニークキーとを対応付けてレコードを生成し、これを金融取引情報１２５１として取引情報データベース１２５に格納する（ｓ１０３）。
【００４３】
続いて取引情報サーバ１００は、上述の伝票５０に関して得た読取り結果のうち、ユニークキーから、処理順序の情報が示す取引の件数「３」と、グループ番号とを読取ると共に、該当グループ番号が付与されている伝票５０が、取引の件数「３」件のうち、何件登録済みか、取引情報データベース１２５で検索する（ｓ１０４）。
【００４４】
上述の検索の結果、該当グループ番号が付与されている伝票５０の登録数が、取引の件数「３」件と一致した場合（ｓ１０５：ｙ）、取引情報サーバ１００は、取引情報データベース１２５における、該当グループ番号の各伝票５０のレコードのステータス５３０を、「勘定処理待ち」に更新する（ｓ１０６）。
【００４５】
他方、上述の検索の結果、該当グループ番号が付与されている伝票５０の登録数が、取引の件数「３」件より少ない値であった場合（ｓ１０５：ｎ）、取引情報サーバ１００は、次の伝票５０に関する読み取り動作を勧めるメッセージを、テラー端末４００に送信する（ｓ１０７）。これに応じて、テラー端末４００では、読取り装置４１０による、２枚目の伝票５０に対する読み取り結果が取得されることとなる。
この２枚目の伝票５０に関する読取り結果の取得に伴い、上述のｓ１００〜ｓ１０４が同様に実行される。このことは３枚目の伝票５０に関しても同様である。
【００４６】
ここで、３枚目の伝票５０に関する読取り結果が、テラー端末４００から取引情報サーバ１００に送信されたことに伴い、ｓ１０１〜ｓ１０３が問題無く実行され、取引情報サーバ１００において、ｓ１０３と同じく、当該伝票５０に関する読取り結果が示す取引内容とユニークキーとを対応付けてレコードを生成し、金融取引情報１２５１として取引情報データベース１２５に格納したとする。
【００４７】
取引情報サーバ１００は、上述と同様にｓ１０４を実行し、３枚目の伝票５０に関して得た読取り結果のうち、ユニークキーから、処理順序の情報が示す取引の件数「３」と、グループ番号とを読取ると共に、該当グループ番号が付与されている伝票５０が、取引の件数「３」件のうち、何件登録済みか、取引情報データベース１２５で検索する。
【００４８】
上述の検索の結果、該当グループ番号が付与されている伝票５０の登録数が、取引の件数「３」件と一致するため（ｓ１０５：ｙ）、取引情報サーバ１００は、取引情報データベース１２５における、該当グループ番号の各伝票５０のレコードのステータス５３０を、「勘定処理待ち」に更新する（ｓ１０６）。
−−−フロー例３−−−
【００４９】
図９は本実施形態の伝票管理方法のフロー例３を示す図である。上述のフロー例２の後、取引情報サーバ１００は、例えば、ユーザ端末２００から、勘定処理を行いたい伝票群（一連の金融取引群）の指定を、グループ番号により受けたとする（ｓ１０８）。
【００５０】
取引情報サーバ１００は、指定を受けたグループ番号をキーに、取引情報データベース１２５で検索を実行し、該当レコードの処理順序情報５２３が示す取引の件数「３」と、該当グループ番号が付与されているレコード数（すなわち登録された伝票５０の数）とが
、一致しているか判定する（ｓ１０９）。
【００５１】
なお、ｓ１０８以降の処理は、取引情報サーバ１００が、取引情報データベース１２５にて同じグループ番号の各レコードのステータス５３０が全て「勘定処理待ち」となっている取引群（一連の金融取引群）を検知したことをトリガーに行うとしてもよい。
【００５２】
上述の判定の結果、取引の件数と登録レコード数とが一致している場合（ｓ１１０：ｙ）、取引情報サーバ１００は、該当レコードにおけるステータス５３０の値を、「勘定処理中」に更新して、当該グループ番号の各伝票５０に関する所定の勘定処理を実行し（ｓ１１１）、この勘定処理の完了に応じて各レコードのステータス５３０の値を「勘定処理済」に更新し（ｓ１１２）、処理を終了する。
【００５３】
他方、上述の判定の結果、取引の件数と登録レコード数とが一致していない場合（ｓ１１０：ｎ）、すなわち、指定されたグループ番号の取引群のいずれかの取引に対応した伝票の金融取引情報の未登録に基づく不整合を検知した場合、取引情報サーバ１００は、「未登録の伝票がありますが、このまま勘定処理を続行しますか？」といった警告情報を、テラー端末４００に送信する（ｓ１１３）。
【００５４】
また、取引情報サーバ１００は、上述のテラー端末４００から、上述の不整合を許容しない、すなわち勘定処理を中止する旨のテラーまたは顧客の意思通知を受信した場合（ｓ１１４：ｎ）、取引情報サーバ１００は、未登録の伝票５０に関する読み取り動作を勧めるメッセージを、テラー端末４００に送信する（ｓ１１５）。
【００５５】
一方、上述のテラー端末４００から、上述の不整合を許容する旨のテラーまたは顧客の意思通知を受信した場合（ｓ１１４：ｙ）、取引情報サーバ１００は、上述の取引群の取引のうちテラー端末４００から指定を受けたもの、または不整合の原因となった未登録取引以外のもの、に関して、所定の勘定処理を実行し（ｓ１１６）、この勘定処理の完了に応じて各レコードのステータス５３０の値を「勘定処理済」に更新し（ｓ１１２）、処理を終了する。
【００５６】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、電子エントリの導入環境下において、伝票の取扱い業務を効率的で的確なものとできる。
【００５７】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の伝票管理システムにおいて、前記演算装置は、前記判定の結果、該当識別情報が未登録であった場合、前記読み取り結果が示す取引内容と、当該識別情報とを対応付け、前記金融取引情報として記憶装置に格納する処理を更に実行するものである、としてもよい。
これによれば、既に登録済みの伝票に関して、重複登録が発生することを回避可能となる。
【００５８】
また、本実施形態の伝票管理システムにおいて、前記演算装置は、顧客持参の複数の伝票それぞれに関する前記読み取り結果の取得機会ごとの、前記金融取引情報の格納に際し、前記識別情報である、当該伝票を一意に特定する管理情報と、当該伝票による金融取引を含む一連の金融取引群に関するグループ情報と、前記金融取引群における当該伝票による金融取引の処理順序の情報とを、前記取引内容と対応付けて、前記金融取引情報として記憶装置に格納し、前記記憶装置に格納した前記金融取引情報のうち、グループ情報が同一の金融取引情報それぞれにおける前記処理順序の情報が、所定の整合性を示すか判定し、前記整合性の判定結果に応じて、当該金融取引群に関する所定処理を実行するものであ
る、としてもよい。
【００５９】
これによれば、顧客がまとめて手続を行って欲しい一連の金融取引に関して、当該顧客が窓口で提示した伝票の抜けがあった場合、そのまま一連の金融取引に関する手続を実行して取引失敗等の不具合が生じることを防止出来る。
【００６０】
また、本実施形態の伝票管理システムにおいて、前記演算装置は、前記金融取引群に関する所定処理に際し、前記整合性の判定結果が、前記金融取引群のいずれかの金融取引に対応した伝票の金融取引情報の未登録に基づく不整合を示すものであった場合、所定の警告情報を所定装置に出力して、前記不整合を許容する旨の通知を所定装置から取得した場合、前記金融取引群の金融取引のうち所定のもの、または前記不整合の原因となった金融取引以外のものに関して所定処理を実行するものである、としてもよい。
【００６１】
これによれば、上述のように伝票の抜けがあったとしても、顧客やテラーからすればそれ以外の金融取引に関しては手続を進めても問題無いと認識する状況に対応して、一連の金融取引に関する手続を実行するといった、柔軟な対応で金融取引を効率良く行うことが出来る。
【００６２】
また、本実施形態の伝票管理方法において、前記情報処理システムが、前記判定の結果、該当識別情報が未登録であった場合、前記読み取り結果が示す取引内容と、当該識別情報とを対応付け、前記金融取引情報として記憶装置に格納する処理を更に実行する、としてもよい。
【００６３】
また、本実施形態の伝票管理方法において、前記情報処理システムが、顧客持参の複数の伝票それぞれに関する前記読み取り結果の取得機会ごとの、前記金融取引情報の格納に際し、前記識別情報である、当該伝票を一意に特定する管理情報と、当該伝票による金融取引を含む一連の金融取引群に関するグループ情報と、前記金融取引群における当該伝票による金融取引の処理順序の情報とを、前記取引内容と対応付けて、前記金融取引情報として記憶装置に格納し、前記記憶装置に格納した前記金融取引情報のうち、グループ情報が同一の金融取引情報それぞれにおける前記処理順序の情報が、所定の整合性を示すか判定し、前記整合性の判定結果に応じて、当該金融取引群に関する所定処理を実行する、としてもよい。
【００６４】
また、本実施形態の伝票管理方法において、前記情報処理システムが、前記金融取引群に関する所定処理に際し、前記整合性の判定結果が、前記金融取引群のいずれかの金融取引に対応した伝票の金融取引情報の未登録に基づく不整合を示すものであった場合、所定の警告情報を所定装置に出力して、前記不整合を許容する旨の通知を所定装置から取得した場合、前記金融取引群の金融取引のうち所定のもの、または前記不整合の原因となった金融取引以外のものに関して所定処理を実行する、としてもよい。
【符号の説明】
【００６５】
１０  ネットワーク
１１  ネットワーク
５０  伝票
５１  取引情報
５１１  取引種類
５１２  口座番号
５１３  金額
５２  ユニークキー（識別情報）
５２１  案件管理番号（管理情報）
５２２  グループ番号（グループ情報）
５２３  処理順序情報
５３  コード
５３０  ステータス
１００  取引情報サーバ（伝票管理システム）
１０１  記憶装置
１０２  プログラム
１０３  メモリ
１０４  演算装置
１０５  通信装置
１２５  取引情報データベース
１２５１  金融取引情報
２００  ユーザ端末
３００  サービス提供サーバ
３１０  コードジェネレータ
４００  テラー端末
４１０  読取り装置
【図１】
2018151817.tif 000003
【図２】
2018151817.tif 000004
【図３】
2018151817.tif 000005
【図４】
2018151817.tif 000006
【図５】
2018151817.tif 000007
【図６】
2018151817.tif 000008
【図７】
2018151817.tif 000009
【図８】
2018151817.tif 000010
【図９】
2018151817.tif 000011