JP2019040480A - 帳票処理装置、帳票処理システム、帳票処理方法およびプログラム - Google Patents

帳票処理装置、帳票処理システム、帳票処理方法およびプログラム Download PDF

Info

Publication number
JP2019040480A
JP2019040480A JP2017162891A JP2017162891A JP2019040480A JP 2019040480 A JP2019040480 A JP 2019040480A JP 2017162891 A JP2017162891 A JP 2017162891A JP 2017162891 A JP2017162891 A JP 2017162891A JP 2019040480 A JP2019040480 A JP 2019040480A
Authority
JP
Japan
Prior art keywords
type
accepted
processing apparatus
unit
financial institution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017162891A
Other languages
English (en)
Inventor
拓磨 神戸
Takuma Kambe
拓磨 神戸
克仁 栗岡
Katsuto Kurioka
克仁 栗岡
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Glory Ltd
Original Assignee
Glory Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Glory Ltd filed Critical Glory Ltd
Priority to JP2017162891A priority Critical patent/JP2019040480A/ja
Publication of JP2019040480A publication Critical patent/JP2019040480A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Character Discrimination (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Character Input (AREA)

Abstract

【課題】顧客や係員にとって、帳票の処理の負担を軽減する帳票処理装置を提供する。【解決手段】帳票処理装置1は、金融機関に設置され、受け入れた帳票から得られたデータを用いて精算処理を実行する。帳票処理装置1は、制御部12と、操作表示部16とを備える。制御部12は、受け入れた帳票の種別を判定し、受け入れた帳票が、帳票処理装置1において取引可能である第1の種別の帳票であると判定した場合、精算処理を行い、受け入れた帳票が、帳票処理装置1が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合、精算処理を行わずに、当該金融機関において取り扱えない旨を操作表示部16に報知させる。【選択図】図1

Description

本発明は、帳票処理装置、帳票処理システム、帳票処理方法およびプログラムに関する。
従来、銀行等の金融機関等に設置され、税金や公共料金等の払込取引を自動的に行う自動取引装置がある。例えば、特許文献1には、受け入れた払込書等の帳票の画像をスキャナで読み取り、読み取った画像から帳票に記載されている口座番号や金額、納付期限等の情報(記載情報)の文字認識を行い、文字認識によって得られたデータを用いて払込処理等の取引を実行する自動取引装置が記載されている。文字認識を行う手順としては、特許文献2に記載されているように、記憶部に記憶された帳票のフォーマット等の情報と読み取った帳票の画像とを照合することにより、帳票の種別を判定した後に、当該フォーマット等の情報に基づいて当該帳票が含む記載情報を文字認識するという方法が一般的である。
ここで、金融機関が収入代行契約を行っていない払込票発行会社が発行した帳票等、金融機関にて取扱いが行えない種別の帳票(以下、取扱不可の帳票という)については、該帳票のフォーマット等の情報が自動取引装置の記憶部に記憶されていないことが一般的である。このため、取扱不可の帳票を受け入れた場合、上記の自動取引装置は、当該帳票を文字認識するための種別の判定を行えず、受け入れた帳票を返却し、当該帳票の取引を行わない。
特開2003−85618号公報 特開平6−119491号公報
しかしながら、帳票の種類は、膨大なものである。金融機関で取り扱える全ての帳票のフォーマット等の情報を自動取引装置の記憶部に記憶することは、困難を極める。このため、金融機関で取り扱いは可能であるが、フォーマット等の情報が自動取引装置の記憶部に記憶されていない帳票も存在する。自動取引装置が、受け入れた帳票について返却を行った場合、自動取引装置の操作を行った顧客からすると、取扱不可の帳票であり、当該金融機関で取扱は行えないため、他の金融機関へ向かえば良いのか、それとも、自動取引装置では取り扱えなかったが、当該金融機関にて取り扱えるものであるため、振込手続が行われる窓口へ向かえば良いのか、不明である。このため、当該顧客は、取り扱い不可の帳票であっても、他の金融機関へ向かう前に確認のため、まずは窓口へ向かうこととなり、このような作業は、顧客にとって煩雑である。
更に、自動取引装置にて返却された帳票を顧客が窓口に持ち込んできた場合、窓口の係員は、金融機関にて取扱不可であるのか、それとも、自動取引装置においては処理が行えなかったが、窓口であれば処理をして良い帳票であるのか、を確認しなければならない。この作業は窓口の係員にしても煩雑である。
上記課題に鑑み、本発明は顧客や係員にとって、帳票の処理の負担を軽減する帳票処理装置、帳票処理システム、帳票処理方法およびプログラムを提供することを目的とする。
本発明の第1の態様は、金融機関に設置され、受け入れた帳票から得られたデータを用いて精算処理を実行する帳票処理装置に関する。本態様に係る帳票処理装置は、制御部と、報知部と、を備える。この場合、前記制御部は、前記受け入れた帳票の種別を判定し、前記受け入れた帳票が、当該帳票処理装置において取引可能である第1の種別の帳票であると判定した場合、前記精算処理を行い、前記受け入れた帳票が、当該帳票処理装置が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合、前記精算処理を行わずに、当該金融機関において取り扱えない旨を報知部に報知させる。
上記の構成によれば、顧客からすると、精算処理が行われずに帳票処理装置から帳票が返却された場合において、窓口で確認を行うべきか、別の金融機関に行くべきか否かを判断できる。更に、窓口の係員からすると、取扱不可の帳票について対応をしなくて済む。よって、上記構成によれば、顧客や係員にとって、帳票の処理の負担を軽減することができる。
また、本態様に係る帳票処理装置において、前記制御部は、前記受け入れた帳票が前記第1の種別の帳票および前記第2の種別の帳票とは異なる第3の種別の帳票であると判定した場合、前記精算処理を行わずに、前記第2の種別の帳票であると判定した場合と異なる態様にて前記報知部に報知させる。
上記の構成によれば、顧客は、第3の種別の帳票について、窓口へ問い合わせるなど、報知部で報知された態様に従った行動をとることができる。
また、本態様に係る帳票処理装置は、受付番号を付した媒体を出力する受付番号出力部を更に備え得る。この場合、前記制御部は、前記受け入れた帳票が前記第3の種別の帳票である場合、前記受付番号出力部に、受付番号を付した媒体を出力させる。
上記の構成によれば、番号札が発行されることにより、顧客は、返却された帳票を持って窓口に行けばよいことが明確となる。
また、本態様に係る帳票処理装置は、呼出報知部を更に備える。この場合、前記制御部は、前記受け入れた帳票が前記第3の種別の帳票であると判定した場合には、前記呼出報知部に係員を呼び出すための呼出報知を行わせる。
上記の構成によれば、第3の種別の帳票であると判定された場合に係員が呼び出される。この場合、例えば、取扱可能である帳票であるにも関わらず、帳票の向き、表裏が誤っていた場合などに、係員が、顧客をフォローすることができる。これにより、顧客が窓口に行く手間を削減することができる。
また、本態様に係る帳票処理装置は、前記帳票処理装置が管理される管理装置へ情報を送信する送信部を更に備え得る。この場合、前記制御部は、前記受け入れた帳票が前記第2の種別の帳票である場合、当該帳票に関する情報のうち、少なくとも帳票の画像データについては、前記送信部に前記管理装置への送信を行わせない。
上記の構成によれば、第2の種別の帳票に関する情報のうち、少なくとも画像データが送信されないので、管理装置を有するセンター側では、第2の種別の帳票について、帳票のフォーマット等の情報を作成しなくとも良くなる。これにより、センター側での精査業務を削減できる。
また、本態様に係る帳票処理装置において、前記帳票に関する情報は、前記帳票の画像データの他、帳票の種別を特定するための種別情報を含み得る。この場合、前記制御部は、前記受け入れた帳票が前記第2の種別の帳票である場合、前記送信部に前記種別情報を送信させる。
上記の構成によれば、取扱不可の帳票の受け入れがどの程度あったのかを、種別ごとに、送信された回数から把握することができ、送信された回数が多い種別の帳票について、収入代行契約を今後行うべきかどうかの検討を行う際に役立つ。送信された回数が多い種別の帳票の方が、顧客が取り扱いたい帳票であると推定されるためである。
本発明の第2の態様は、受け入れた帳票から得られたデータを用いて、金融機関において精算処理を実行する帳票処理システムに関する。本態様に係る帳票処理システムは、制御部と、報知部と、を備える。この場合、前記制御部は、前記受け入れた帳票の種別を判定し、前記受け入れた帳票が、当該帳票処理システムにおいて取引可能である第1の種別の帳票であると判定した場合、前記精算処理を行い、前記受け入れた帳票が、当該帳票処理システムが実行される金融機関において取り扱えない第2の種別の帳票であると判定した場合、前記精算処理を行わず、当該金融機関において取り扱えない旨を報知部に報知させる。
上記の構成によれば、第1の態様に係る帳票処理装置と同様の効果を奏し得る。
本発明の第3の態様は、受け入れた帳票から得られたデータを用いて帳票処理装置が精算処理を実行するための帳票処理方法に関する。本態様に係る帳票処理方法は、前記受け入れた帳票の種別を判定し、前記受け入れた帳票が前記帳票処理装置において取引可能である第1の種別の帳票であると判定した場合には前記精算処理を行い、前記受け入れた帳票が、前記帳票処理装置が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合には、前記精算処理を行わずに、当該金融機関において取り扱えない旨を報知部に報知させる。
上記の構成によれば、第1の態様に係る帳票処理装置と同様の効果を奏し得る。
本発明の第4の態様は、受け入れた帳票から得られたデータを用いて精算処理を実行する帳票処理装置のコンピュータに付与するプログラムに関する。本態様に係るプログラムは、前記受け入れた帳票の種別を判定する機能と、前記受け入れた帳票が前記帳票処理装置において取引可能である第1の種別の帳票であると判定した場合には前記精算処理を行う機能と、前記受け入れた帳票が、前記帳票処理装置が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合には、前記精算処理を行わずに、当該金融機関において取り扱えない旨を報知部に報知させる機能と、が付与される。
上記の構成によれば、第1の態様に係る帳票処理装置と同様の効果を奏し得る。
本発明によれば、顧客や係員にとって、帳票の処理の負担を軽減することができる。
本発明の効果ないし意義は、以下に示す実施形態の説明により更に明らかとなろう。ただし、以下に示す実施形態は、あくまでも、本発明を実施化する際の一つの例示であって、本発明は、以下の実施形態に記載されたものに何ら制限されるものではない。
図1は、実施形態に係る、帳票処理システムの構成を示すブロック図である。 図2は、実施形態に係る、帳票処理装置の外観構成を示す図である。 図3は、実施形態に係る、取引選択画面と、この画面に続く、帳票受入画面である。 図4は、実施形態に係る、受け入れた帳票の読取中画面と、この画面に続く、精算画面である。 図5(a)は、実施形態に係る、帳票処理装置が設置された金融機関では取り扱い不可能な帳票であることを通知するための通知画面であり、図5(b)は、実施形態に係る、窓口への顧客の誘導を行うための通知画面である。 図6は、実施形態に係る、帳票処理のフローチャートである。 図7は、変更例1に係る、帳票処理システムの構成を示すブロック図である。 図8は、変更例1に係る、学習データを作成するためのフローチャートである。 図9は、変更例1に係る、帳票処理のフローチャートである。 図10は、スマートフォンを用いた帳票処理システムの環境ブロック図である。
以下、本発明の実施形態について、図面を参照して説明する。
図1は、実施形態に係る、帳票処理システムの構成を示すブロック図である。
帳票処理装置1は、銀行等の金融機関の店舗内に設置されており、通信部13を介して管理サーバー2とLAN等の有線または無線の通信回線で接続され、これらとともに帳票処理システム3を構成している。また、帳票処理システム3は、銀行窓口に設置されている窓口端末4とも接続されている。
帳票処理装置1は、顧客が銀行に持ち込んだ帳票を受け入れて、帳票の画像を画像読取部14で読み取り、読み取った画像から、文字認識を行うことにより、帳票に含まれた記載情報を得る。ここで、記載情報とは、帳票に記載された情報であって、金額情報、納付期限など、帳票処理装置1で払込処理等の取引処理を行うために必要となる情報である。帳票処理装置1は、文字認識によって得られた記載情報を用いて払込処理等の取引処理を実行する。
管理サーバー2は、金融機関の事務センターや、外部アウトソーシングセンターに設置されている。管理サーバー2は、取引可能帳票データベース231(以下、「取引可能帳票DB231」と称する)で、帳票処理装置1を設置した金融機関で取引可能である帳票のフォーマット等の情報を、帳票の種別ごとに管理する。当該フォーマット等の情報には、帳票の種別を特定するために用いられる種別特定参照データと、帳票の記載情報を文字認識するために用いられる文字認識参照データが含まれる。種別特定参照データとは、例えば、帳票の罫線レイアウトや、帳票のタイトル情報といった帳票のフォーマットの特徴を示すデータである。文字認識参照データとは、座標など帳票において記載情報が記載されている領域を示すデータである。また、管理サーバー2は、取引不可能帳票データベース232(以下、「取引不可能帳票DB232」と称する)で、帳票処理装置1を設置した金融機関で取引不可能である帳票のフォーマット等の情報(種別特定参照データ、文字認識参照データ)を、帳票の種別ごとに管理する。取引可能帳票DB231および取引不可能帳票DB232における帳票のフォーマット等の情報は、各金融機関(銀行)の帳票処理装置1に送信される。
次に、帳票処理装置1の内部構成について説明する。帳票処理装置1は、記憶部11、制御部12、通信部13、画像読取部14、収納部15、操作表示部16、報知部17およびプリンター18を備える。記憶部11は、ROM(Read Only Memory)、RAM(Random Access Memory)やハードディスク等の記憶媒体を備え、制御部12の動作プログラムを記憶し、また、制御部12の制御処理の際にワーク領域として利用される。当該動作プログラムは、帳票画像処理プログラム115であり、たとえば、CD−ROM(Compact Disc Read Only Memory)やUSBメモリ〔USB(Universal Serial Bus) flash drive〕などの外部記憶媒体を介して、記憶部11に記憶される。
また、記憶部11は、取引可能帳票データベース111(以下、「取引可能帳票DB111」と称する)と、取引不可能帳票データベース112(以下、「取引不可能帳票DB112」と称する)と、画像データベース113(以下、「画像DB113」と称する)と、受入回数データベース114(以下、「受入回数DB114」)とを記憶している。取引可能帳票DB111は、管理サーバー2から受信した、帳票処理装置1が設置された銀行にて取引可能である帳票のフォーマット等の情報(種別特定参照データ、文字認識参照データ)を、帳票の種別ごとに管理する。取扱可能である帳票は、銀行ごと、または、営業店ごとに異なる場合がある。取引不可能帳票DB112は、管理サーバー2から受信した、帳票処理装置1が設置された銀行にて取引不可能である帳票の種別をフォーマット等の情報(種別特定参照データ、文字認識参照データ)を、帳票の種別ごとに管理する。画像DB113は、後述する画像読取部14によって、取得した帳票の画像を管理する。受入回数DB114は、帳票処理装置1が取引不可能である帳票を受け入れた回数を、帳票の種別ごとに定められた帳票のID(以下、帳票IDという)に対応付けて記憶する。当該受け入れた回数は営業日ごとや所定期間経過に応じ、消去される。
制御部12は、CPU(Central Processing Unit)等の演算回路を備え、記憶部11に記憶された帳票画像処理プログラム115に従って、通信部13、画像読取部14、収納部15、操作表示部16、報知部17、プリンター18等の各構成部を制御する。通信部13は、管理サーバー2と窓口端末4との間で通信回線を介した信号(情報)の送受信を行う。制御部12は、通信部13を介して、取引可能帳票DB231や取引不可能帳票DB232等から各種情報を受信し、記憶部11中の取引可能帳票DB111や取引不可能帳票DB112等に記憶することも可能である。また、制御部12は、通信部13を介して、帳票処理装置1から管理サーバー2に対し、画像DB113に記憶された画像を送信する。すなわち、通信部13は、情報を送信する送信部として機能する。
画像読取部14は、イメージスキャナ等により構成され、受け入れた帳票の画像を取得する。
収納部15は、紙幣や硬貨を金種別に収納する複数の金種別収納トレイから構成される。
操作表示部16は、ディスプレイに各種の画像(画面)を表示するとともに、ディスプレイに対するユーザのタッチ操作をタッチセンサにより検出する。該画面は帳票処理装置1の操作者に対する通知であることからも、操作表示部16は操作者に対する報知を行うための報知部としても機能する。
報知部17は、スピーカー、LED(Light Emitting Diode)等により、構成され、帳票処理装置1を操作する顧客または、該装置を設置した銀行の係員に対し、各種報知を行う。
プリンター18は、帳票処理装置1において、受け入れた帳票の種類を識別できなかった場合に、窓口の待ち順番を示す受付番号札を出力する。すなわち、プリンター18は、受付番号を付した媒体を出力する受付番号出力部として機能する。
次に、管理サーバー2の内部構成について説明する。管理サーバー2は、通信部21、制御部22、記憶部23、操作部24および表示部25を備える。記憶部23は、ROM(Read Only Memory)、RAM(Random Access Memory)やハードディスク等の記憶媒体を備え、制御部22の動作プログラムを記憶し、また、制御部22の制御処理の際にワーク領域として利用される。記憶部23は、上述した取引可能帳票DB231および取引不可能帳票DB232の他、画像データベース233(以下、「画像DB233」と称する)と、受入回数データベース234(以下、「受入回数DB234」)とを記憶している。画像DB233は、通信部21を介して帳票処理装置1から送信された帳票の画像を管理する。受入回数DB234は、通信部21を介して帳票処理装置1から送信された、帳票処理装置1が取り不可能である帳票を受け入れた回数を、帳票IDに対応付けて記憶する。受入回数DB234は、各銀行の営業店に設置された帳票処理装置1から帳票IDが送信されると、その帳票IDに対応付けられた帳票処理装置1が受け入れた回数を1つ増加させる。例えば、受入回数DB234が、帳票IDが001の帳票を受け入れた回数を10回と記憶しているものとする。この場合、帳票処理装置1から001の帳票IDの送信があると、制御部22は、受入回数DB234にて管理されている帳票IDが001の帳票の受け入れた回数を1回分増加させ、10回から11回へと更新する。また、管理サーバー2では、帳票処理装置1を設置している銀行、または、銀行の営業店についても、帳票IDや受け入れた回数に紐付けて管理をしている。
操作部24は、キーボードやマウス等の操作手段を備える。操作部24は、ディスプレイに対するオペレーターの操作を受け付ける。表示部25は、ディスプレイで構成される。表示部25は、ディスプレイに各種の画像(画面)を表示する。管理サーバー2のオペレーターは、画像DB223に記憶されている帳票の画像から、当該画像に対応する種別の帳票について、種別を特定し、取引可能帳票DB231や取引不可能帳票DB232に記憶される帳票のフォーマット等の情報(種別特定参照データ、文字認識参照データ)を作成する。具体的には、オペレーターは、表示部25に表示された帳票の画像を参照しながら操作部24を操作して、公知の技術や手法によって、フォーマット等の情報(種別特定参照データ、文字認識参照データ)を生成する。
図2は、実施形態に係る、帳票処理装置1の外観構成を示す図である。図2に示すように、帳票処理装置1には、正面上部に操作表示部16が設けられる。また、操作表示部16の下方に帳票の投出入部110とプリンター18の出力口18aが並ぶように設けられる。さらに、帳票処理装置1は、正面中央部に硬貨収受部101と、紙幣収受部102とを有する。
投出入部110は、操作者からの帳票の挿入を受け入れる。また、投出入部110は、例えば、特開2017-113844号公報に記載された公知の機構により、精算が行われた後の帳票から領収書部分を切り離し、返却する。
硬貨収受部101は、操作者からの紙幣の投入を受け入れるとともに、操作者に対するお釣りを払い出す。紙幣収受部102は、操作者からの紙幣の投入を受け入れるとともに、操作者に対するお釣りを払い出す。
次に、顧客が、図1に示した帳票処理装置1において、帳票を用いて払込取引等の取引処理を実行するときの処理手順を説明する。
図3ないし図5は、顧客が帳票を用いて払込取引等の取引処理を実行する際の帳票処理装置1での画面遷移を示す図である。
図3に示すように、操作表示部16には、最初に、顧客である操作者が持ち込んだ帳票を用いて精算を行う取引を選択するための取引選択画面SC11が表示される。取引選択画面SC11において、「自動車税」、「住民税」などの各種取引に関する項目を記載したボタン表示部IC111の中から、例えば、「住民税」のボタンIC112が押下されると、同じく図3に示す帳票受入画面SC12に画面遷移する。
図3に示す帳票受入画面SC12は、操作者に対し、帳票の投出入部110への帳票の投入を促すための画面である。操作者により帳票の投出入部110に、帳票が投入されると、帳票処理装置1は、帳票の投出入部110から機内へと帳票を取り込み、帳票を受け入れる。これにより、操作表示部16の画面表示は、図4に示す読取中画面SC13へと画面遷移する。
なお、帳票受入画面SC12において、取消ボタンIC123が押下されれば、取引処理は全て取り消され、取引選択画面SC11へと画面遷移する。また、帳票の投出入部110に帳票が投入されている状態であれば、帳票処理装置1の機内にある帳票が投出入部110から返却される。以下、他の画面においても、適宜、取消ボタンが配置されるが、これらの機能は、取消ボタンIC123と同様である。
図4に示す読取中画面SC13は、操作者に対し、受け入れた帳票を読取中である旨を表示する画面である。受け入れられた帳票は、その種別が特定され、その特定結果に基づいて、受け入れられた帳票が、第1の種別の帳票、第2の種別の帳票および第3の種別の帳票の何れであるかが判定される。ここで、第1の種別の帳票は、帳票処理装置1において、取扱可能である種別の帳票である。すなわち、取引可能帳票DB231に記憶されている種別の帳票である。次に、第2の種別の帳票は帳票処理装置1が設置された金融機関にて取り扱えない種別の帳票である。すなわち、取引不可能帳票DB232に記憶された種別の帳票である。次に、第3の種別の帳票は、第1の種別の帳票にも、第2の種別の帳票にも該当しない種別の帳票である。すなわち、取引可能帳票DB231および取引不可能帳票DB232に記憶されておらず、種別が特定できない帳票である。受け入れられた帳票が第1の種別の帳票であると判定された場合には、文字認識により帳票から記載情報が取得され、同じく図4に示す精算画面SC14に遷移する。
なお、受け入れられた帳票が、帳票処理装置1を設置した金融機関で取引不可能である帳票、即ち第2の種別の帳票と判定した場合、後述する図5(a)に示す通知画面SC15へ画面遷移する。また、受け入れられた帳票の種別を特定できなかった場合、即ち受け入れられた帳票が第3の種別の帳票である場合、後述する図5(b)に示す通知画面SC16へ画面遷移する。
図4に示す精算画面SC14は、文字認識した記載情報を操作者に対して提示し、精算を促す画面である。操作者が、紙幣収受部102や硬貨収受部101に紙幣や硬貨を投入することにより、帳票に関する精算を行う。なお、記載情報のうち、例えば、金額情報などに操作者にとって疑義がある場合は、操作者は納付書確認ボタンIC141を押下することにより、操作者は、別途表示される図示しない確認画面で画像読取部14が読み取った帳票の画像を確認することができる。
図5(a)に示す通知画面SC15は、帳票処理装置1を設置した金融機関では取り扱えない旨及び帳票の返却をする旨を表示する画面である。投出入部110から帳票が返却され、操作者は、返却された帳票を受け取る。
図5(b)に示す通知画面SC16は、帳票処理装置1では帳票の種別を特定できなかったことから、窓口に問合せして欲しい旨および受付番号札と連携する旨を表示する。操作者は、投出入部110から返却された帳票およびプリンター18で印刷された番号札を手にとり、窓口へ行くようになる。
次に、帳票処理装置1において帳票を用いた取引処理を行うために制御部12が実行する帳票処理手順について説明する。図6は、実施形態に係る、帳票処理のフローチャートである。
まず、制御部12は、帳票受入処理を行う(S101)。すなわち、制御部12は、操作表示部16に図3に示すような取引選択画面SC11を表示する。取引に関する項目が選択されたのであれば、制御部12は、同じく図3に示す帳票受入画面SC12を表示し、操作者に対し、投出入部110への帳票の投入を促す。以上が帳票受入処理(S101)である。
次に、帳票が受け入れられたのであれば、制御部12は、画像読取処理を行う(S102)。すなわち、制御部12は、受け入れられた帳票を画像読取部14で読み取ることにより、帳票の画像を取得する。それに際し、制御部12は、操作表示部16に図4に示す読取中画面SC13を表示する。なお、制御部12は、取得した帳票の画像を画像DB113に記憶する。
次に、制御部12は、ステップS102にて取得した帳票の画像を用いて、投入された帳票の帳票種別判定処理を行う(S103)。具体的には、制御部12は、取引可能帳票DB111および取引不可能帳票DB112に記憶されている個々の帳票の種別特定参照データと、受け入れた帳票の画像に含まれた種別特定参照データに対応するテータとのマッチングを行うことにより、受け入れた帳票の種別を特定する。帳票の種別を特定できた場合、つまり、受け入れた帳票の種別が、取引可能帳票DB111または取引不可能帳票DB112に記憶された(登録された)帳票の種別であると判定した場合(S104:YES)、制御部12は、当該特定した帳票の種別が、取引可能帳票DB111に記憶された種別であるか否かを判定する(S105)。特定した帳票の種別が、取引可能帳票DB111に記憶された種別である場合(S105:YES)、その帳票が帳票処理装置1にて取引可能であることから、制御部12は、その帳票の種別について取引可能帳票DB111に記憶されている文字認識参照データを用いて、受け入れた帳票の記載情報を文字認識する(S106)。即ち、制御部12は、帳票における、文字認識参照データが示す領域に記載された記載情報を、文字認識によって取得する。
ステップS106にて文字認識が行えた場合(S107:YES)、制御部12は、精算処理を行う(S108)。すなわち、制御部12は、操作表示部16に、図4に示すような精算画面SC14を表示する。操作者による紙幣や貨幣の投入により、精算が完了すれば、帳票に対し、領収印を押印し、領収書部分を切り離し、投出入部110より、操作者に領収書を返却する。投入された紙幣や硬貨は、収納部に収納され、お釣りが紙幣収受部102や硬貨収受部101に払い出される。こうして、制御部12による帳票の処理が終了する。
一方、ステップS103において、帳票の種別を特定できた(S104:YES)ものの、受け入れた帳票の種別が、取引可能帳票DB111に記憶された帳票の種別でなかった場合(S105:NO)、すなわち、受け入れた帳票の種別が、取引不可能帳票DB112に記憶された帳票の種別であった場合、制御部12は、取扱不可メッセージ表示処理をする(S109)。すなわち、制御部12は、操作表示部16に、図5(a)に示すような通知画面SC15を操作者に対し表示する。これと同時に、制御部12は、投出入部110から、受け入れた帳票を返却する。
次に、制御部12は、当該判別した帳票について、種別IDを、種類情報として、通信部13を介し、管理サーバー2へ送信する(S110)。なお、管理サーバー2の制御部22は、受信した種別IDを用いて、受入回数DB234内の受信した種別IDに紐付く、当該種別IDを受け入れた回数を更新する。この場合は、制御部22は、受信した種別IDに紐付く、当該種別IDを受け入れた回数を1回分加算する。取扱不可能の種別の帳票について、帳票処理装置1が受け入れた回数を種別ごとに把握できることにより、管理サーバー2のオペレーターや、銀行の担当者は、回数が多い帳票については、金融機関にて取引を行えるようにすべきか検討をすることができる。なお、制御部12は、取扱不可能の種別の帳票について、S102の画像読取処理で読み取った画像のデータ(画像データ)を、管理サーバー2に送信しない。これにより、管理サーバー2を有するセンター側では、取扱不可能の種別の帳票について、帳票のフォーマット等の情報を作成しなくとも良くなり、センター側での精査業務を削減できる。
ステップS103において、帳票の種別を特定できなかった場合(S104:NO)、または、ステップS106にて文字認識が行えなかった場合(S107:NO)、制御部12は、窓口案内処理を行う(S111)。すなわち、制御部12は、操作表示部16に、図5(b)に示すような通知画面SC16を表示する。同時に、制御部12は、投出入部110から帳票を返却するとともに、プリンター18から受付番号札を発行する(S112)。
次に、制御部12は、当該判別した帳票の画像データを、通信部13を介し、管理サーバー2へ送信する(S113)。なお、管理サーバー2の制御部22は、受信した画像を画像DB113に記憶する。金融機関で取引可能であるにも関わらず、取引可能帳票DB231に登録できていなかった場合がある。このような場合に、管理サーバー2のオペレーターは、当該種別の特定が行えなかった帳票について、追加でフォーマット等の情報を作成して、取引可能帳票DB231に登録することができる。この場合、登録された情報は、通信部21を介して帳票処理装置1の取引可能帳票DB111に追加登録されることとなる。種別が特定できなかった帳票が、金融機関で取引不可能である帳票であった場合も、同様に、オペレーターが、取引不可能帳票DB232にフォーマット等の情報を登録し、帳票処理装置1の取引可能帳票DB111に追加登録すれば良い。
なお、ステップS110では、帳票を返却した都度、受け入れた帳票の種別IDを管理サーバー2へ送信していた。しかしながら、これに限らず、帳票処理装置1の受入回数DB114が、帳票IDごとに当該帳票処理装置1が受け入れた回数を管理し、制御部12が、金融機関の営業時間外などにまとめて、受入回数DB114が管理している情報を管理サーバー2に対して送信しても良い。この場合、管理サーバー2の制御部22は、帳票処理装置1から受信した、受け入れた回数に応じ、受入回数DB234を更新する。例えば、受入回数DB234が、帳票IDが001の帳票を受け入れた回数を10回と記憶しているものとする。この場合、帳票処理装置1から帳票IDが001の帳票を5回受け入れたという旨の送信があると、制御部22は、受入回数DB234にて管理されている帳票IDが001の帳票を受け入れた回数を5回分加算し、10回から15回へと更新する。なお、制御部12は、管理サーバー2へ帳票IDに紐付く回数の送信を行った後は、受入回数DB114に記憶された受け入れた回数を消去しても良い。
なお、ステップS113では、帳票を返却した後に該帳票から取得した画像の送信を行っている。これに限らず、金融機関の営業時間外などにまとめて、その日の営業時間分の種別を特定できなかった帳票の画像データを、管理サーバー2へ送信しても良い。
なお、ステップS111では、帳票の種別が特定できなかった場合、顧客に対する報知を行っていたが、これと同時に、制御部12は、窓口案内処理の一部として、金融機関の係員の携帯電話機に、特定できなかった帳票があった旨を、通信部13を通じて報知しても良い。この報知は、係員を呼び出すための呼出報知であり、この場合、金融機関の係員は、直ちに帳票処理装置1に向かい、顧客をサポートすることができる。なお、この例では、通信部13が、呼出報知のための呼出報知部として機能する。
なお、ステップS110では、帳票を返却した後に帳票のID情報の送信を行っており、画像データについては送信を行っていない。しかしながら、画像データの送信も行うようにしてもよい。但し、送信に際する通信容量の都合上、少なくとも容量の大きい画像データについては、送信しないことが望ましい。
なお、帳票の種別の特定が行えず(S104:NO)、ステップS112において、プリンター18から受付番号札を発券する場合には、当該番号札には、帳票処理装置1において種別を特定できなかった旨を明示しても良い。また、種別を特定できたものの、文字認識が行えなかった場合(S107:NO)、プリンター18から受付番号札を発券する場合には、当該番号札には、種別を特定できたが、文字認識が行えなかった旨を明示しても良い。
なお、ステップS109の処理において、制御部12は、報知部17であるスピーカーやLEDから、顧客または、帳票処理装置1が設置された銀行の係員に対し、受け入れた帳票がその銀行で取扱い不可能である旨を報知しても良い。報知部17がスピーカーである場合は、「取り扱いが行なえません」という音声を発しても良い。また、報知部17がLEDである場合は、そのLEDを赤色にLEDを点灯させるといった報知態様でも良い。
なお、ステップS111またはステップS112の処理においても、同様に、御部12は、報知部17であるスピーカーやLEDから、顧客または、帳票処理装置1を設置した銀行の係員に対し、受け入れた帳票が帳票処理装置1において取扱い不可能である旨を報知しても良い。この場合、報知部17がスピーカーである場合は、「番号札をお取りいただき、窓口までお越しください。」という音声を発しても良い。また、報知部17がLEDである場合は、そのLEDを上述したステップS109にて赤色にLEDを点灯させる場合とは異なる態様にて点灯させると良い。例えば、制御部12は、LEDを緑色に点灯させたり、赤色に点滅させたりしても良い。
<実施形態の効果>
本実施形態によれば、以下の効果が奏される。
(1)帳票処理装置1が受け入れた帳票が、第2の種別の帳票であると判別した場合に、当該帳票処理装置1が設置された金融機関ではこの帳票の取り扱いが行えない旨を表示することにより、顧客からすると、帳票処理装置1から帳票を返却された場合において、窓口で確認を行うべきか、別の金融機関に行くべきかを判断できる。更に、窓口の係員からすると、取扱不可の帳票について対応をしなくて済む。
(2)更に、帳票処理装置1が受け入れた帳票が帳票の種別が特定できなかった第3の種別の帳票である場合は、第2の種別の帳票である場合と異なる態様にて操作者に通知することから、操作者は窓口に行くべきことがより分かりやすくなる。
なお、本発明は、上記実施形態によって何ら制限されるものではなく、また、本発明の実施形態も、以下に示す通り、上記以外に種々の変更が可能である。
<変更例1>
変更例1に係る帳票処理装置1においては、帳票処理装置1では特定できず窓口への問合せが必要となる帳票の種別を特定するための学習データが記憶部11に記憶されている。そして、帳票処理装置1では、ステップS103において、取引可能帳票DB111に記憶された帳票の種別特定参照データと、取引不可能帳票DB112に記憶された帳票の種別特定参照データとを用いて種別の特定が行われる前に、学習DB116に記憶された学習データにより特定される帳票の種別と、受け入れられた帳票の種別が同一であるかが確認される。
取引可能帳票DB111および取引不可能帳票DB112に記憶された帳票の種別の件数が膨大である場合には、それら帳票と受け入れた帳票を照合するには時間がかかる。本変更例においては、取引可能帳票DB111および取引不可能帳票DB112に記憶された帳票と受け入れた帳票を照合する前に、受け入れた帳票の種別が、取引可能帳票DB111および取引不可能帳票DB112に記憶された帳票の種別には含まれていない種別であることを判別できるようにする。これにより、学習データにより特定されることとなる種別の帳票について、帳票処理の時間を短縮できる。すなわち、帳票を返却するまでの操作者(顧客)の待ち時間の短縮を図ることができる。
例えば、新年度に入ってすぐに、新年度にてフォーマットが変わった水道料金の帳票を用いて、水道料金の精算を行おうとする顧客がいる。当該顧客が精算を行おうにも、新年度の帳票について、管理サーバー2でのフォーマット等の情報の登録が間に合っていない場合がある。この場合、帳票処理装置1は、新年度の帳票が投入される度に、取引可能帳票DB111および取引不可能帳票DB112に記憶された帳票の種別でないか、照合を行った後、種別が特定できないとしてその帳票を返却することになる。上述の通り、受け入れた帳票と取引可能帳票DB111および取引不可能帳票DB112に記憶された帳票との照合には、長い時間が掛かり得るので、新年度の帳票が持ち込まれる都度、顧客を長く待たせてしまうことが生じ得る。本変更例においては、取引可能帳票DB111および取引不可能帳票DB112に記憶されていない種別の帳票を受け入れた場合においても、早急に顧客に返却することが可能であるので、上記のように帳票のフォーマットが変更されたときに、多くの顧客を長く待たせるようなことを防止できる。
図7は、変更例1に係る、帳票処理システム3の構成を示すブロック図である。このブロック図では、図2の場合に比べて、学習データベース116(以下、「学習DB116」と称する)が記憶部11に記憶されている。学習データベース116には、帳票処理の際に帳票の種別を特定できなかった(S104でNOの判定)帳票の画像に基づいて作成された学習データが保存されている。
図8は、変更例1に係る、学習データの作成するための作成処理を示すフローチャートである。制御部12は、操作者による操作がなされていないときや、帳票が投出入部110に投入されていないときなどの、帳票処理装置1が待機状態にあるときに学習データの作成処理を行う。
制御部12は、画像DB113から、帳票処理の際に帳票の種別を特定できなかった画像を抽出する(S201)。そして、制御部12は、特徴が同じ帳票を集約する(S202)。例えば、制御部12は、罫線レイアウトが同一である帳票を集約する。
次に、制御部12は、集約した帳票の画像のグループについて所定の枚数以上の画像が集約しているか確認する(S203)。
所定の枚数以上の画像が集約されていれば(S203:YES)、グループ内の各画像の共通部分を抽出する(S204)。当該抽出処理により、一致する罫線レイアウトはもちろんのこと、帳票のタイトル情報なども抽出される。この抽出された共通部分に関するデータが学習データとなる。
以上が、学習データ作成のフローとなる。作成された学習データは、学習DB116に記憶されることとなる。
なお、ステップS203において、集約した画像の枚数を判定した結果、集約した画像の枚数が所定の枚数未満である場合は(S203:NO)、その画像のグループの学習データを作成せず、処理は終了する。
なお、ステップS202において、画像を集約するために使用する帳票の特徴としては、罫線レイアウトの他にも帳票の下地の色、帳票の左上近辺に記載されていると想定されるタイトルの文字などでも良い。
なお、罫線レイアウト等のみならず記載情報までが同じ帳票が連続で帳票処理装置1に投入され、それらの画像が画像DB113に記憶されている場合がある。このように記載情報までが同一の帳票については、ステップS203で枚数を判定するときに、複数枚の画像でも、まとめて1枚として計数しても良い。
なお、ステップS201にて抽出する対象となる帳票の画像とは、画像DB113に記憶された全ての帳票の画像ではなく、帳票の種別を特定できなかった直近の複数枚(100枚など)の画像であってもよい。また、ステップS201にて抽出する対象となる帳票の画像は、所定の期間内(たとえば、直近2週間)において帳票の種別を特定できなかった画像であってもよい。
なお、上記変更例において、所定の枚数以上の同じ特徴を有する画像のグループについて学習データを作成していた。これに限らず、例えば、複数のグループに集約された帳票の画像のうち、帳票の枚数が多い上位数件のグループに対し、学習データを作成してもよい。
図9は、変更例1に係る、帳票処理のフローチャートである。このフローチャートでは、図6の場合と比べ、ステップS114、S115が追加されている。以下、追加されたステップにおける処理について、説明を行う。
制御部12は、受け入れた帳票から画像を取得する画像取得処理(S102)を行った後、学習DB116に記憶された学習データと取得した画像から得られる特徴が一致するか照合をする(S114)。学習データと得られた特徴とが一致する場合(S114:YES)、制御部12は、窓口案内処理(S111)を行う。受け入れた帳票は、その種別を特定できない可能性が高いので、S103およびS104の処理を行わずとも、速やかに窓口で問い合わせることが望ましいためである。一方、学習データと得られた特徴とが一致しない場合(S114:NO)、制御部12は、帳票種別判定処理を行い(S103)、取引可能帳票DB111および取引不可能帳票DB112に記憶されている帳票の種別を特定するためのデータを用いて受け入れた帳票の種別を特定する。
以上、本変更例の構成によれば、過去に種別の特定ができなかった帳票について、その特徴を学習させて学習データとして学習DB116に保存し、受け入れた帳票から得られた画像の特徴と学習データとを照合することで、受け入れた帳票が種別の特定ができない帳票であるかを判別するようにしている。これにより、取引可能帳票DB111および取引不可能帳票DB112に記憶されている帳票の種別を特定するためのデータと受け入れた帳票から得られた画像とを照合するよりも短い時間で、受け入れた帳票が種別の特定ができない帳票であるかを判別でき、種別の特定できず精算処理が行えない帳票を早急に顧客に返却することが可能となる。
<その他の変更例>
上記、実施形態において、説明の便宜上、取引可能帳票DB111と取引不可能帳票DB112は別個のものであるように記述をした。これに限らず、1つのデータベース内において、取引可能である帳票の種別を特定するためのデータと、取引不可能である帳票の種別を特定するためのデータと、帳票の記載情報を文字認識するためのデータとを、帳票の種別ごとに管理しても良い。この場合、同データベースには、帳票の種別ごとに取引の可否に関するフラグを設けても良い。取引可能帳票DB231と取引不可能帳票DB232についても同様である。
図10は、スマートフォン6を用いた帳票処理システム5の環境ブロック図である。帳票処理システム5は、スマートフォン6と管理サーバー2とを含む。スマートフォン6は、帳票処理装置として機能する。帳票を用いて各種料金の支払いを行いたい人物(以下、支払人)は、スマートフォン6に搭載されたカメラ(図示せず)にて帳票を撮影する。これにより、スマートフォン6は帳票の画像を取得する(S1)。次に、スマートフォン6は、操作者からの操作に応じ、ステップS1で取得した帳票の画像を、インターネット7を介して管理サーバー2に対し送信する(S2)。管理サーバー2の制御部22は、受信した帳票の画像についての種別を判定する(S3)。管理サーバー2は、判定の結果、種別が特定できれば、金額等の記載情報を文字認識する(S4)。管理サーバー2は、インターネット7を介して、文字認識した結果を送信する(S5)。スマートフォン6は、その表示部6aに文字認識した結果を表示し、操作者は当該表示内容に基づき、精算処理を行う(S6)。
以上、この帳票処理システム5では、支払人は、金融機関に向かわずとも、帳票による支払いを行うことができる。
その他、本発明の実施形態は、特許請求の範囲に記載の範囲で適宜変更可能である。
1 帳票処理装置(帳票処理装置)
2 管理サーバー(管理装置)
11 記憶部(記憶部)
12 制御部(制御部)
13 通信部(送信部、呼出報知部)
16 操作表示部(操作表示部、報知部)
17 報知部(呼出報知部)
18 プリンター(受付番号出力部)

Claims (9)

  1. 金融機関に設置され、受け入れた帳票から得られたデータを用いて精算処理を実行する帳票処理装置において、
    制御部と、
    報知部と、
    を備え、
    前記制御部は、
    前記受け入れた帳票の種別を判定し、
    前記受け入れた帳票が、当該帳票処理装置において取引可能である第1の種別の帳票であると判定した場合、前記精算処理を行い、
    前記受け入れた帳票が、当該帳票処理装置が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合、前記精算処理を行わず、当該金融機関において取り扱えない旨を報知部に報知させる、
    ことを特徴とする帳票処理装置。
  2. 前記制御部は、前記受け入れた帳票が前記第1の種別の帳票および前記第2の種別の帳票とは異なる第3の種別の帳票であると判定した場合、前記精算処理を行わず、前記第2の種別の帳票であると判定した場合と異なる態様にて前記報知部に報知させる、
    ことを特徴とする請求項1記載の帳票処理装置。
  3. 受付番号を付した媒体を出力する受付番号出力部を更に備え、
    前記制御部は、前記受け入れた帳票が前記第3の種別の帳票である場合、前記受付番号出力部に、受付番号を付した媒体を出力させる、
    ことを特徴とする請求項2に記載の帳票処理装置。
  4. 呼出報知部を更に備え、
    前記制御部は、
    前記受け入れた帳票が前記第3の種別の帳票であると判定した場合には、前記呼出報知部に係員を呼び出すための呼出報知を行わせる、
    ことを特徴とする請求項2または3に記載の帳票処理装置。
  5. 前記帳票処理装置が管理される管理装置へ情報を送信する送信部を更に備え、
    前記制御部は、前記受け入れた帳票が前記第2の種別の帳票である場合、当該帳票に関する情報のうち、少なくとも帳票の画像データについては、前記送信部に前記管理装置への送信を行わせない、
    ことを特徴とする請求項1ないし4いずれか一項に記載の帳票処理装置。
  6. 前記帳票に関する情報は、前記帳票の画像データの他、帳票の種別を特定するための種別情報を含み、
    前記制御部は、前記受け入れた帳票が前記第2の種別の帳票である場合、前記送信部に前記種別情報を送信させる、
    ことを特徴とする請求項5記載の帳票処理装置。
  7. 受け入れた帳票から得られたデータを用いて、金融機関において精算処理を実行する帳票処理システムにおいて、
    制御部と、
    報知部と、
    を備え、
    前記制御部は、
    前記受け入れた帳票の種別を判定し、
    前記受け入れた帳票が、当該帳票処理システムにおいて取引可能である第1の種別の帳票であると判定した場合、前記精算処理を行い、
    前記受け入れた帳票が、精算処理を実行する金融機関において取り扱えない第2の種別の帳票であると判定した場合、前記精算処理を行わず、当該金融機関において取り扱えない旨を報知部に報知させる、
    ことを特徴とする帳票処理システム。
  8. 受け入れた帳票から得られたデータを用いて帳票処理装置が精算処理を実行するための帳票処理方法であって、
    前記受け入れた帳票の種別を判定し、
    前記受け入れた帳票が前記帳票処理装置において取引可能である第1の種別の帳票であると判定した場合には前記精算処理を行い、
    前記受け入れた帳票が、前記帳票処理装置が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合には、前記精算処理を行わずに、当該金融機関において取り扱えない旨を報知部に報知させる、
    ことを特徴とする帳票処理方法。
  9. 受け入れた帳票から得られたデータを用いて精算処理を実行する帳票処理装置のコンピュータに、
    前記受け入れた帳票の種別を判定する機能と、
    前記受け入れた帳票が前記帳票処理装置において取引可能である第1の種別の帳票であると判定した場合には前記精算処理を行う機能と、
    前記受け入れた帳票が、前記帳票処理装置が設置された金融機関において取り扱えない第2の種別の帳票であると判定した場合には、前記精算処理を行わずに、当該金融機関において取り扱えない旨を報知部に報知させる機能と、
    を付与するプログラム。
JP2017162891A 2017-08-25 2017-08-25 帳票処理装置、帳票処理システム、帳票処理方法およびプログラム Pending JP2019040480A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017162891A JP2019040480A (ja) 2017-08-25 2017-08-25 帳票処理装置、帳票処理システム、帳票処理方法およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017162891A JP2019040480A (ja) 2017-08-25 2017-08-25 帳票処理装置、帳票処理システム、帳票処理方法およびプログラム

Publications (1)

Publication Number Publication Date
JP2019040480A true JP2019040480A (ja) 2019-03-14

Family

ID=65725770

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017162891A Pending JP2019040480A (ja) 2017-08-25 2017-08-25 帳票処理装置、帳票処理システム、帳票処理方法およびプログラム

Country Status (1)

Country Link
JP (1) JP2019040480A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020161970A (ja) * 2019-03-26 2020-10-01 グローリー株式会社 書類処理装置、書類処理システムおよび書類処理方法
JP2022062458A (ja) * 2020-10-08 2022-04-20 株式会社 みずほ銀行 支払支援システム、支払支援方法及び支払支援プログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167228A1 (en) * 2000-05-31 2003-09-04 Toshiyuki Waida Payment form discrimination method and apparatus
JP2007018165A (ja) * 2005-07-06 2007-01-25 Hitachi Electronics Service Co Ltd 金融端末、原因判定方法、及び、原因判定プログラム
JP2015005156A (ja) * 2013-06-21 2015-01-08 グローリー株式会社 顧客誘導システム及び顧客誘導方法
JP2017037376A (ja) * 2015-08-07 2017-02-16 グローリー株式会社 自動機システム及び貨幣処理方法
JP2017054385A (ja) * 2015-09-10 2017-03-16 グローリー株式会社 納付書処理システム及び納付書処理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167228A1 (en) * 2000-05-31 2003-09-04 Toshiyuki Waida Payment form discrimination method and apparatus
JP2007018165A (ja) * 2005-07-06 2007-01-25 Hitachi Electronics Service Co Ltd 金融端末、原因判定方法、及び、原因判定プログラム
JP2015005156A (ja) * 2013-06-21 2015-01-08 グローリー株式会社 顧客誘導システム及び顧客誘導方法
JP2017037376A (ja) * 2015-08-07 2017-02-16 グローリー株式会社 自動機システム及び貨幣処理方法
JP2017054385A (ja) * 2015-09-10 2017-03-16 グローリー株式会社 納付書処理システム及び納付書処理方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020161970A (ja) * 2019-03-26 2020-10-01 グローリー株式会社 書類処理装置、書類処理システムおよび書類処理方法
JP7143241B2 (ja) 2019-03-26 2022-09-28 グローリー株式会社 書類処理装置、書類処理システムおよび書類処理方法
JP2022062458A (ja) * 2020-10-08 2022-04-20 株式会社 みずほ銀行 支払支援システム、支払支援方法及び支払支援プログラム
JP7063963B2 (ja) 2020-10-08 2022-05-09 株式会社 みずほ銀行 支払支援システム、支払支援方法及び支払支援プログラム

Similar Documents

Publication Publication Date Title
JP2021044026A (ja) 登録装置、会計装置、及びプログラム
EP2690609A1 (en) Settlement system, settlement method, and cash settlement device
JP6679206B2 (ja) 取引受付システム及び取引受付方法
KR20130084645A (ko) 은행원 서포트형 창구 접수 시스템 및 창구 처리 방법
JP4903500B2 (ja) 自動契約受付機、自動契約受付システムおよびプログラム
JP5205215B2 (ja) 窓口呼出装置
JP2019040480A (ja) 帳票処理装置、帳票処理システム、帳票処理方法およびプログラム
JP2014119792A (ja) Posシステム
JP2022058880A (ja) システム、登録装置及びプログラム
JP2003168001A (ja) 現金管理システム、現金管理方法、現金管理方法をコンピュータに実行させるためのプログラム、このプログラムを記録した記録媒体
JP6688016B2 (ja) 電子記帳システム及び伝票起票方法
JP7028438B2 (ja) 商品販売データ処理装置、システム、及び、プログラム
JP7017705B2 (ja) 商品販売データ処理装置、システム、及び、プログラム
JP2016130982A (ja) 受付呼出システム及び受付呼出方法
KR100453469B1 (ko) 창구 업무 장치 및 창구 업무 관리 방법
JP6303397B2 (ja) 精算システム及びプログラム
JP2013186496A (ja) 販売管理システム、販売管理装置及び販売管理方法
JP2017117241A (ja) 配当金支払管理システム及び配当金支払管理方法
JP5551643B2 (ja) 通帳繰越装置
JP2017037376A (ja) 自動機システム及び貨幣処理方法
JP4553686B2 (ja) 情報処理方法、コンピュータ・システム及び自動現金預払機用入金カード
JP6522950B2 (ja) 電子記帳システム及び伝票情報管理方法
JP6154214B2 (ja) 顧客誘導システム、電子記帳機及び顧客誘導方法
JP6753751B2 (ja) 紙葉類処理システム及び紙葉類処理方法
JP2015005156A (ja) 顧客誘導システム及び顧客誘導方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200407

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210222

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210309

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20211012