JP4110790B2

JP4110790B2 - 伝票処理システムおよびそのプログラム

Info

Publication number: JP4110790B2
Application number: JP2002035486A
Authority: JP
Inventors: 雅浩福田
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2002-02-13
Filing date: 2002-02-13
Publication date: 2008-07-02
Anticipated expiration: 2022-02-13
Also published as: JP2003242365A

Description

【０００１】
【発明の属する技術分野】
本発明は、金融機関の伝票精査における伝票処理システムおよびそのプログラムに関する。
【０００２】
【従来の技術】
従来、金融機関の営業店では、営業店の窓口端末において勘定ホストコンピュータが行う顧客情報の更新等の取引処理の結果（以下、ホスト処理結果という。）を顧客が記載した伝票に印字し、その日の取引の締上時に伝票記載内容とホスト処理結果の印字内容とを目視で精査して勘定取引の精査（以下、伝票精査事務という。）を行っている。
【０００３】
【発明が解決しようとする課題】
しかしながら、上述した従来の伝票精査事務においては、全ての伝票の全ての項目について伝票の記載内容とホスト処理結果の印字内容とを突合せて確認する必要があり、これに要する労力が過大となって伝票精査事務を行う係員の負担が大きいと共に長時間が費やされるという問題がある。
【０００４】
一方、近年の画像データによる認識技術の発達に伴い、営業店の窓口端末の伝票処理システムにこれを導入し、認識した伝票記載内容と窓口の担当者の入力内容を突合せて確認を行う突合確認によって自動的に伝票の精査を行うシステムの開発が要望されており、これを各金融機関が個々に保有する精査システムに適合させることが期待されている。
【０００５】
そこで、本発明は、各金融機関が個々に有する精査システムに適合し、かつ伝票精査事務を行う係員の負担を軽減する伝票処理システムを構築することを目的とする。
【０００６】
【課題を解決するための手段】
本発明は、上記課題を解決するために、営業店に設置され、画像の読取手段と、入力手段と、印字手段とを有する窓口端末を備えた伝票処理システムにおいて、前記窓口端末は、前記読取手段で読取った伝票の画像データから、前記伝票の記載内容を文字認識する手段と、担当者が入力手段で入力した前記伝票の記載内容の入力を受付ける手段と、前記伝票の記載内容と前記担当者の入力内容との突合確認を行うときの突合確認項目毎に、２つの突合対象項目からなる複数の判定条件、および前記判定条件に基づく判定の順序を設定すると共に、前記各判定条件に、締上時の精査の要否を設定した精査要否判定情報を格納する手段と、前記精査要否判定情報の判定条件に基づき、前記判定の順序に従って、前記突合確認項目の記載内容の前記文字認識結果と前記入力内容とを突合せて突合確認を行う手段と、前記突合確認結果が一致した場合に、前記精査要否判定情報から、当該判定条件の前記精査の要否を読出す手段と、該読出した精査の要否を記憶する手段と、該記憶した精査の要否を読出して、前記印字手段で、前記精査の要否を前記伝票に印字する手段と、を備えることを特徴とする。
【０００７】
また、画像の読取手段と、入力手段と、印字手段とを有し、伝票の記載内容と担当者の入力内容との突合確認を行うときの突合確認項目毎に、２つの突合対象項目からなる複数の判定条件、および前記判定条件に基づく判定の順序を設定すると共に、前記各判定条件に、締上時の精査の要否を設定した精査要否判定情報を格納した窓口端末の制御部を、前記読取手段で読取った前記伝票の画像データから、前記伝票の記載内容を文字認識する認識手段と、担当者が入力手段で入力した前記伝票の記載内容の入力を受付ける受付手段と、前記精査要否判定情報の判定条件に基づき、前記判定の順序に従って、前記突合確認項目の記載内容の前記認識手段による文字認識結果と前記受付手段による入力内容とを突合せて突合確認を行う突合確認手段と、前記突合確認結果が一致した場合に、前記精査要否判定情報から、当該判定条件の前記精査の要否を読出す読出手段と、該読出手段により読出した精査の要否を記憶する記憶手段と、該記憶手段に記憶した精査の要否を読出して、前記印字手段で、前記精査の要否を前記伝票に印字する精査要否印字手段として機能させることを特徴とする。
【０００８】
【発明の実施の形態】
以下に、図面を参照して本発明による伝票処理システムの実施の形態について説明する。
図１は本発明の伝票処理システムを示すフローチャート、図２は本発明の実施の形態を示すブロック図である。
【０００９】
図２において、１は勘定ホストコンピュータであり、金融機関のセンタ等に設置される。
２はデータベースであり、勘定ホストコンピュータ１と接続して顧客の暗証番号や口座番号、預金残高、印影認識結果等の顧客情報を格納する。
３は窓口端末であり、金融機関の営業店の各取引窓口に設置されており、インターネットまたは専用の通信回線等の通信ネットワークによって勘定ホストコンピュータ１と接続している。
【００１０】
４は営業店のサーバであり、各窓口端末３とＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）によって接続されており、図示しない記憶装置が装備されている。
５は窓口端末３の制御部であり、通信部６によって通信ネットワークを介して勘定ホストコンピュータ１と、ＬＡＮによって営業店のサーバ４と接続しており、窓口端末３内の各部を制御すると共にデータ通信等も制御する。
【００１１】
７はハードディスク等の記憶部であり、制御部５が実行するプログラム等が記憶されている他、制御部５による処理結果を保存する。
なお、記憶部７は窓口端末３の外部に設置した記憶装置であってもよい。
８はＣＲＴまたはＬＣＤ等の表示部であり、処理結果の表示や窓口端末３を操作する担当者（以下、単に担当者という。）への入力内容等を表示する。
【００１２】
９は金融キーボードまたはＪＩＳキーボード等の入力部であり、これを用いて担当者が伝票の記載内容や処理内容等を入力する。
１０は画像認識部であり、窓口端末３に接続または内蔵されたスキャナ１１によって伝票の記載内容を画像データとして読取り、これを基に文字や記号、図形等を認識する。
【００１３】
１２は印字部であり、通帳伝票プリンタ１３によって処理結果等を伝票等に印字する。
上述した構成の作用について説明する。
本実施の形態例の伝票処理システムの適用にあたっては、予め突合確認項目表と精査要否判定表とからなる精査要否判定情報を設定する。
【００１４】
突合確認項目表の例を表１に示す。
【００１５】
【表１】

表１は、取引内容毎の顧客が記載する伝票の記載順序を示したものであり、例えば出金取引の場合は、最上位に記載された数字が項目１に相当する「店番」であり、次の行の数字が項目２に相当する「科目」、以下同様に「口座番号」、「金額」の順に記載されていることを示している。
【００１６】
すなわち、制御部５が伝票に記載された数字を画像認識部１０によって文字認識し、その記載されていた位置によってどの内容に相当するかを認識するための内容が示されている。
なお、これらの項目は、伝票の記載内容に該当する領域をその座標によって指示するようにしてもよい。
【００１７】
精査要否判定表の例を表２に示す。
【００１８】
【表２】

表２は、顧客の記載内容もしくは担当者の入力した内容と担当者の入力内容等の突合対象項目に対してなされた突合確認結果に基づいてなされる取引処理の続行可否と締上時の精査要否について、突合確認項目表に示す各項目で共通に用いる判定基準を示したものである。
【００１９】
例えば、出金取引の項目４「金額」について、認識文字の誤認識または認識不可能文字がある場合等に適用される判定条件３の場合は、担当者の最初の入力値とその後の再入力値を突合確認した結果が一致した場合には、取引処理続行は許可されるが、後の精査が必要であることを示している。
すなわち、判定条件１で認識文字と担当者の入力値が不一致であり、判定条件２で認識文字と担当者の再入力値が不一致である場合に、判定条件３の担当者の入力値と再入力値とが一致すれば、取引は続行されるが、後にその内容が精査されることを示している。
【００２０】
または、この場合に取引処理続行を不許可として、再処理を行うように設定することも可能である。この場合は判定条件３の取引処理続行可否欄を「否」とすればよい。
このようにすることによって、個々の金融機関の精査内容に関する考え方が異なっている場合に、突合対象項目とこれに対応する取引処理続行可否および精査要否等の精査要否判定情報をその考え方にそって設定することができ、各金融機関で独自の伝票処理システムとすることが可能となる。
【００２１】
なお、各欄に記述する内容は、予め定めた所定のコードを用いて記述するようにしてもよい。
また、上記の精査要否判定表は、突合確認項目表に示す各項目に共通するものとして示したが、項目毎に別々に設定するようにしてもよい。
上記の精査要否判定情報は、予め各金融機関により設定され窓口端末３の記憶部７に格納される。また制御部５が実行するプログラムは、記憶部７に格納されている。
【００２２】
以下に、図１に示すフローチャートを用い、Ｓで示すステップに従って顧客が窓口によって出金取引を行う場合を例に説明する。
取引窓口の担当者が使用する窓口端末３の表示部８には、担当者が行う業務を選択するメニュー画面が表示されている。
Ｓ１、顧客が図３に示す出金伝票の所定の欄に該当内容を記載して窓口の担当者に提出する。この場合は図３に示す伝票精査項目記載欄およびホスト処理結果記載欄は空白の状態になっている。
【００２３】
これを受領した担当者は、メニュー画面から「出金取引」を選び、スキャナ１１に伝票を装填して入力部９によって画像データの取得指令を入力する。
この入力を受付けた窓口端末３の制御部５は、スキャナ１１によって画像データを読取って画像認識部１０に転送し、記憶部７に格納されている突合確認項目表に示す突合確認項目表を参照してそれぞれ項目について文字認識を行う。
【００２４】
なお、この場合にメニュー画面から「出金取引」を選び、この確定操作を画像データの取得指令とするようにしてもよい。
Ｓ２、制御部５は、文字認識を終えたデータを認識不可能文字も含めて、記憶部７へ格納する。
文字認識データが記憶部７へ格納されると、制御部５は表示部８に文字データが格納された旨の文言を表示して伝票記載内容の入力待ちの状態になる。
【００２５】
Ｓ３、担当者は顧客の伝票記載内容を入力部９によって入力し、完了キーを押下する。
Ｓ４、完了キーの押下信号を受付けた制御部５は、記憶部７に格納されている表２の精査要否判定表を参照して判定条件１の突合対象項目について突合確認を行う。表２の例では、認識文字と担当者の入力値とを突合せる。
【００２６】
同様にして突合確認項目表に示す他の全ての突合確認項目について突合確認を行い、全ての突合確認結果が一致し、その取引処理続行可否が「可」であれば、担当者の入力内容を取引確定データとしてステップＳ８へ移行する。
各突合確認項目の突合確認結果が一つでも不一致であれば、その旨と再入力を促す文言を表示部８に表示してステップＳ５へ移行する。
【００２７】
Ｓ５、再入力を要請された担当者は、伝票の記載内容を確認して再入力を行い、完了キーを押下する。
Ｓ６、再入力を受付けた制御部５は、精査要否判定を参照して判定条件２の突合対象項目について突合確認を行う。表２の例では、認識文字と担当者の再入力値とを突合せる。この結果が不一致の場合は、判定条件３についても突合確認を行い、更に判定条件がある場合は順次突合確認を行う。
【００２８】
同様にして他の全ての突合確認項目について突合確認を行い、全ての突合確認項目について取引処理続行可否が「可」となる判定条件があれば、担当者の再入力内容を取引確定データとしてステップＳ８へ移行する。
突合確認項目について取引処理続行可否が一つでも「否」であれば、その旨と項目、判定条件の番号および取引処理の続行または中止を問合せる文言を表示部８に表示してステップＳ７へ移行する。
【００２９】
Ｓ７、続行判断を要請された担当者は、伝票の記載内容を再度確認し、受領した伝票の記載内容の目視結果と自己の再入力値とが一致していると判断した場合は取引処理続行のために用意されたコード番号を入力部９によって入力し、完了キーを押下する。
取引処理続行コードを受付けた制御部５は、精査要否を「要」として担当者の再入力内容を取引確定データとしてステップＳ８へ移行する。
【００３０】
担当者が自己の入力値および再入力値が間違いであると確認した場合は訂正入力のために用意されたコード番号を入力部９によって入力し、完了キーを押下する。
訂正入力コードを受付けた制御部５はステップＳ３へ分岐し、担当者が上記ステップＳ３によって訂正入力を行う。その後の動作は上記と同様である。
【００３１】
受領した伝票の記載内容が目視にても読取りにくい場合や、金融機関の精査に関する業務処理規定によって担当者独自の続行判断が禁止されている場合は、再処理のために用意されたコード番号を入力部９によって入力し、完了キーを押下する。
再処理コードを受付けた制御部５は取引処理を中止し、「開始」に戻って待機し、担当者は業務処理規定に従って顧客との間で調整を行う等の再処理を行う。
【００３２】
Ｓ８、制御部５は、突合確認項目毎の突合確認結果を基に記憶部７に格納されている精査要否判定表を参照して精査要否を判定し、取引通番や取引内容、取引処理続行可否が「可」となった判定条件の番号、精査の要否等を精査項目要否管理情報として窓口端末３の記憶部７に格納する。
これと同時に、同様のデータを通信部６によって営業店のサーバ４に転送し、サーバ４に装備された図示しない記憶装置に格納する。このデータは、窓口端末３の障害時の復旧用や、営業店全体の精査項目要否一覧表を作成する場合等に使用する。
【００３３】
精査項目要否管理情報の例を表３に示す。
【００３４】
【表３】

表３において、取引通番には使用された窓口端末３が区別できるように記号「Ａ」が付されている。また突合確認項目欄には取引処理続行が「可」となった判定条件の番号が記載されている。
【００３５】
例えば、取引通番「Ａ００４」の出金取引の場合は、項目１と項目２、つまり突合確認項目表の「店番」と「科目」は判定条件２、つまり精査要否判定表の認識文字と再入力値との突合せが一致したことを示している。
また、項目４「金額」は判定条件３の最初の入力値と再入力値が一致した結果、取引処理続行が「可」となったことを示しており、精査要否判定表によればこの場合の精査が「要」であるので、精査項目要否管理情報の精査要否欄には「要」と記録される。
【００３６】
なお、取引通番「Ａ００５」の為替振込の場合は、全ての項目が最初の入力によって取引処理続行が「可」となったが、突合確認項目表のその他目視検査欄に受取人のカナ表記の目視確認が必要である旨が記載されているので、精査項目要否管理情報のその他欄には「あり」と精査要否欄には「要」と記録されている。また、ステップＳ７で担当者の判断で取引処理続行とした場合は、取引処理続行可否を「可」とした判定条件の番号が存在しないため、該当部分を空欄もしくは「＊」等の記号、または存在しない判定条件の番号、表２の例では「４」（Ａ００３の項目４）等とし、精査要否を「要」として精査項目要否管理情報に記録するようにする。
【００３７】
Ｓ９、制御部５は、勘定ホストコンピュータ１との間で取引処理を実行する。すなわち、取引確定データ等を記載した電文を作成し、通信部６によって通信ネットワークを介して金融機関のセンタ等に設置された勘定ホストコンピュータ１に送信する。
これを受信した勘定ホストコンピュータ１は、該当する顧客情報を更新して取引処理を行い、ホスト処理結果を電文として窓口端末へ送信する。
【００３８】
Ｓ１０、電文を受信した窓口端末３の制御部５は、記憶部７に格納されている精査項目要否管理情報を参照して、図３に示す伝票の伝票精査項目記載欄に精査の要否や突合対象項目の突合確認結果等を印字するための端末印字項目の編集を行う。
この時、突合対象項目の中で精査が必要な項目に対しては、印字の色を変更することによって、または視認可能な記号等の識別子、図３の例では「＃」を付与することによって他の項目と区別できるようにする。
【００３９】
なお、担当者はステップＳ８〜Ｓ１０の間に伝票を通帳伝票プリンタ１３に装填する。
Ｓ１１、制御部５は、編集された端末印字項目を印字部１２によって通帳伝票プリンタ１３に装填されている伝票の伝票精査項目記載欄に印字する。
図３の例では、精査要否、店番、科目、口座番号、金額の各項目が印字されている。
【００４０】
なお、金額の先頭に付された識別子「＃」は、精査項目要否管理情報の取引通番「Ａ００４」の項目４が精査「要」と判定されているために付されたものである。
Ｓ１２、制御部５は、ステップＳ１１と同様にして、勘定ホストコンピュータ１から受信したホスト処理結果の内容をホスト処理記載欄に印字する。
【００４１】
図３の例では、取引通番、処理年月日、処理時刻、取引内容、店番、科目、口座番号、金額が一致している旨が印字されている。
以上によって、本実施の形態による出金取引の処理が終了する。他の取引の場合も同様の処理を行う。
締上時の精査の場合は、「精査要」と印字された伝票を選び出し、目視によって伝票の記載内容とホスト処理結果の印字内容を比較確認して精査を行う。
【００４２】
これによって、伝票の記載内容の画像データによる認識結果と担当者の入力内容とを項目毎に判定して精査の要否を伝票に印字することによって、精査が必要な伝票のみを選んで精査を行うことが可能となり、伝票精査事務を行う係員の負担を軽減し、業務効率を向上することが可能となる。
また、精査が必要な項目に識別マークを付与することによって、その精査項目を絞り込んで精査することができ、伝票精査事務を行う係員の負担を更に軽減し、更なる効率化が可能となる。
【００４３】
更に、伝票処理システムのプログラムを各金融機関で共通なプログラムとし、精査要否判定情報を金融機関が個々に設定することによって、金融機関毎に画像データを用いた伝票処理システムのプログラムを開発することが不要となり、効率よく各金融機関の考え方に沿った独自の伝票処理システムを構築することが可能となる。
【００４４】
なお、上記実施の形態例では、精査要否判定情報を窓口端末に格納するとして説明したが、これを営業店のサーバに格納して各窓口端末からそれぞれ参照するようにしてもよい。
これによって、精査要否判定情報の変更等の場合に一度で全ての窓口端末の変更等を行うことができ、入力ミスや設定ミスによる混乱を防止して円滑な伝票処理システムの運用が可能になる。
【００４５】
また、精査要否判定情報の例を表１、表２に示したが、その内容は表１、表２の例に限るものではなく、これらを統合して一つのものとしてもよく、他の項目を加えて用いるようにしてもよい。
【００４６】
【発明の効果】
以上説明したように、本発明は、伝票の記載内容の画像データによる認識結果と担当者の入力内容とを精査要否判定情報に基づいて判定し、精査の要否を伝票に印字することによって、精査が必要な伝票のみを選んで精査を行うことが可能となり、伝票精査事務を行う係員の負担を軽減することができる。
【００４７】
また、精査要否判定情報を金融機関が個々に設定することによって、各金融機関の考え方に沿った独自の伝票処理システムを構築することができるという効果が得られる。
【図面の簡単な説明】
【図１】本発明の伝票処理システムを示すフローチャート
【図２】本発明の実施の形態を示すブロック図
【図３】本発明の伝票の印字例を示す説明図
【符号の説明】
１勘定ホストコンピュータ
２データベース
３窓口端末
４サーバ
５制御部
６通信部
７記憶部
８表示部
９入力部
１０画像認識部
１１スキャナ
１２印字部
１３通帳伝票プリンタ

Claims

営業店に設置され、画像の読取手段と、入力手段と、印字手段とを有する窓口端末を備えた伝票処理システムにおいて、
前記窓口端末は、
前記読取手段で読取った伝票の画像データから、前記伝票の記載内容を文字認識する手段と、
担当者が入力手段で入力した前記伝票の記載内容の入力を受付ける手段と、
前記伝票の記載内容と前記担当者の入力内容との突合確認を行うときの突合確認項目毎に、２つの突合対象項目からなる複数の判定条件、および前記判定条件に基づく判定の順序を設定すると共に、前記各判定条件に、締上時の精査の要否を設定した精査要否判定情報を格納する手段と、
前記精査要否判定情報の判定条件に基づき、前記判定の順序に従って、前記突合確認項目の記載内容の前記文字認識結果と前記入力内容とを突合せて突合確認を行う手段と、
前記突合確認結果が一致した場合に、前記精査要否判定情報から、当該判定条件の前記精査の要否を読出す手段と、
該読出した精査の要否を記憶する手段と、
該記憶した精査の要否を読出して、前記印字手段で、前記精査の要否を前記伝票に印字する手段と、を備えることを特徴とする伝票処理システム。
請求項１において、
前記精査要否判定情報の前記各判定条件に、取引処理続行の可否を設定しておくことを特徴とする伝票処理システム。
請求項１または請求項２において、
前記突合確認結果が一致の場合であって、当該判定条件の前記精査の要否が要のときに、当該突合確認項目に、識別マークを付与して印字することを特徴とする伝票処理システム。
請求項１から請求項３のいずれか一項において、
前記窓口端末に、営業店のサーバを接続し、
前記サーバは、前記精査要否判定情報を格納する手段を備え、
前記窓口端末は、前記サーバから、前記精査要否判定情報を取得する手段を備えることを特徴とする伝票処理システム。
画像の読取手段と、入力手段と、印字手段とを有し、伝票の記載内容と担当者の入力内容との突合確認を行うときの突合確認項目毎に、２つの突合対象項目からなる複数の判定条件、および前記判定条件に基づく判定の順序を設定すると共に、前記各判定条件に、締上時の精査の要否を設定した精査要否判定情報を格納した窓口端末の制御部を、
前記読取手段で読取った前記伝票の画像データから、前記伝票の記載内容を文字認識する認識手段と、
担当者が入力手段で入力した前記伝票の記載内容の入力を受付ける受付手段と、
前記精査要否判定情報の判定条件に基づき、前記判定の順序に従って、前記突合確認項目の記載内容の前記認識手段による文字認識結果と前記受付手段による入力内容とを突合せて突合確認を行う突合確認手段と、
前記突合確認結果が一致した場合に、前記精査要否判定情報から、当該判定条件の前記精査の要否を読出す読出手段と、
該読出手段により読出した精査の要否を記憶する記憶手段と、
該記憶手段に記憶した精査の要否を読出して、前記印字手段で、前記精査の要否を前記伝票に印字する精査要否印字手段として機能させることを特徴とする伝票処理システムのプログラム。