JPH063603B2 - 取引処理デ−タ管理方式 - Google Patents

Description

【発明の詳細な説明】 ＜産業上の利用分野＞ 本発明は、金融機関等におけるオンライン処理システム
において、センタ側で一括処理する取引データのうち、
取引処理が正常に行えなかった取引データを効率よく管
理できる取引処理データ管理方式に関する。

例えば銀行におけるオンラインシステムは、センターに
設置されるコンピュータと複数の営業店（支店，営業所
等）とが回線で接続される。そして各営業店に設置され
る端末装置（窓口装置，自動取引装置等）から入力され
る取引情報がセンターコンピュータに逐次送出される。
センターコンピユータでは、この取引情報に基いて顧客
マスタファイル（顧客及び顧客の持つ口座に関する情報
を格納するファイル）の更新等の取引情報を行う。

一方センターにおいては、これらオンラインによる取引
処理と平行して、センター側独自で一括して取引処理を
行う。このセンターにおける一括処理としては、例えば
公共料金支払，期日指定の振込等にみられる自動振替処
理が該当する。即ち、毎月予め定められた日までに顧客
の口座より所定の金額を引落す処理が行われる。

このようにオンラインシステムにおいては、センターコ
ンピュータによるオンライン取引処理と，一括処理（通
常、バッチ処理）とが平行して行われる。この時、一括
処理において取引処理が未完了のままで終った取引デー
タの取扱いが問題となる。つまり上述の如く一括処理さ
れる取引データは期日指定のある取引処理である。従っ
て、センタによる一括処理においてシステムエラー等の
原因で未処理のままとなった取引データについて、何ら
かの形で再処理を行う必要がある。

このように、センターでの一括処理にてシステムエラー
等によって異常終了となった取引データに対する迅速で
且つ適切な対応策が要望されている。

＜従来の技術＞ 上述したシステムにおいてセンター一括処理における異
常終了（未処理）の取引データが発生した場合、従来で
はセンター側にてこの未処理分の取引データのリスト出
力が可能なよう構成されている。そしてセンタ管理者が
このリストを見て、未処理のままの取引データを再処理
するよう試みている。つまり異常終了となった原因を究
明し、一括処理を行うシステム（プログラム）の障害で
あればその障害を修正し取引データの再処理を試みるも
のである。

＜発明が解決しようとする問題点＞ しかしながら上述したエラー対処法であると、センター
管理者による一括処理プログラムのデバッグ等の作業が
必要となる。この結果、エラー発生時のエラー解析の為
の莫大な労力及び時間がかかる問題点がある。更には、
一括処理にて当日までに処理すべき取引データのうちの
未処理となった取引データの当日内での処理が不可能に
なる問題点がある。

＜問題点を解決するための手段＞ 本発明は上述した従来の問題点を解決することを目的と
している。即ち、センタ一括処理にて未処理（処理不
能）になった取引データについては、その取引データの
処理を必要とする営業店側にて把握できるようにして、
未処理分データに対する営業店側での迅速な対処が可能
となる取引処理データ管理方式を提供しようというもの
である。

そしてその為に本発明においては、一括処理において異
常終了となった取引データを収集する収集ファイルを設
け、営業店の端末装置からの要求に応答して、この収集
ファイルを参照し、当該営業店に関連する未処理データ
を返送できるように構成したものである。

＜作用＞ 後述する如く、センターにて一括処理する取引データと
は、あくまで各営業店が取扱っている取引データをセン
ター側で一括して処理するようにしたものである。従っ
て、センター一括処理で未処理となった取引データを営
業店側に通知できるようにすれば、営業店側での未処理
データに対する適切な処置が可能となる。

つまり本発明では、顧客マスタファイルをアクセスする
ルートとしてセンタ一括処理と、オンライン取引処理と
が存在する点に着目したものである。そしてセンタ一括
処理にて異常終了となったものについては、各営業店か
らのオンライン取引入力について再処理を試みられるよ
うにしたものである。これにより、センターでの一括処
理部の障害（プログラムエラー）によって未処理となっ
たデータについて、オンライン取引による取引処理リカ
バリが可能となるものである。以下、実施例を用いて本
発明を詳述する。

＜実施例＞ 第１図及び第２図は本発明を銀行のオンライン処理シス
テムに適用した場合の一実施例を示す図であり、第１図
はセンター側の具体的構成を示す図、第２図はシステム
全体の構成を示すブロック図である。両図において共通
する部分には各々同一の符号を附すものとする。

図中、１はセンタコンピュータ，３は営業店，１１はシ
ステム制御部（ＯＳ），１２は通信制御部（ＮＣＰ，Ｖ
ＴＡＭ），１３はデータベース制御部（ＡＩＭ），１４
はバッチ処理支援部，１５はオンライン入出金処理部
（以下、単にオンライン処理部と称す），１６はセンタ
一括処理制御部（以下、単に一括処理部と称す），１７
は異常処終了データ管理部（以下、異常管理部と称
す），１８はフォーマット変換部，１９は異常処理部，
２０は顧客マスタファイル（以下、単にマスタファイル
と称す），２１は一括処理ファイル，２２は管理ファイ
ル，２３は異常終了データ収集ファイル（以下収集ファ
イルと称す）をそれぞれ示す。

図においてセンターコンピュータ１を構成する各部１
１，１３〜１９は、それぞれコンピュータが動作する機
能部分であり、本実施例では各々独立したプログラムパ
ッケージとして実現している。そして、システム制御部
１１，データベース制御部１はオンラインシステムを構
築するためのベースプログラムであり、メーカ提供基本
ソフトウェア及びパッケージとして実現しているもので
ある。オンライン処理部１５，一括処理部１６及び異常
管理部１７、銀行業務を行うためのユーザ・アプリケー
ションプログラムと考えてよい。

オンライン処理部１５及び一括処理部１６は、データベ
ース制御部の制御のもとに各々独立してマスタファイル
２０をアクセスできるよう構成される。このうちオンラ
イン処理部１５は、営業店３における窓口装置や自動取
引装置などの端末装置３３から入力される取引情報を通
信制御部１２を介して受信する。受信する取引情報に
は、入金取引，出金取引、或いは為替取引に関する情報
（口座番号，取引種別，金額等）が含まれる。オンライ
ン処理部１５は、この取引情報に応じてマスタファイル
２０をアクセスし、取引遂行の可否を判断するととも
に、取引遂行可能であれば該当する口座における残高等
の更新及び取引内容の履歴をとる。そして取引可否情
報，取引結果，印字データを当該端末装置３３に返送す
る。端末装置３３では受信した情報に基いて伝票３４を
出力し、顧客に渡すことにとって１つの取引を終了する
ことになる。

一方、一括処理部１６では、上述の如く自動振替処理を
行う。この一括処理部１６での取引処理は、銀行窓口業
務終業後（例えば夜間）にバッチ処理にて行われる。或
いはオンライン処理部１５によるオンライン取引処理と
並行したバッチ処理にて行われる。

第１図に示す如く、センタにて一括処理を行うべき取引
データ（自動振替データ）は、磁気テープ（ＭＴ）２４
に格納される。例えば処理すべき毎月の期日期限毎に一
括して別々の磁気テープ２４に格納されている。つまり
各営業店３にて顧客との間で取決めた自動振替に関する
データが処理期日毎に一括して格納される。そして、図
示しないコンソールからオペレータ（センタ管理者等）
が指示することにより、以下に述べる一括処理が起動さ
れる。

まずデータベース制御部１３が、この磁気テープ２４に
格納される取引データを読込む。そしてフオーマット変
換部変換部１８にて読込んだ取引データのフォーマット
を揃え一括処理ファイル２１に順次格納する。この取引
データには、例えば自動振替を行うべき口座番号情報，
振替金額，期日，及び取扱営業店コードが含まれる。フ
ォーマット変換部１８は、この取引データを所定個（例
えば１００件分の取引データ）ずつを１つの一括処理フ
ァイル２１として、更にレコード番号Ｒを付して１つの
取引データＴＲ₁，ＴＲ₂，…として格納する。

次に制御部１３における異常処理部１９が、フォーマッ
ト変換部１８にて生成された一括処理ファイル２１に各
々対応した管理ファイル２２を生成する。これら各ファ
イル２１，２２はセンタコンピュータ１の持つ図示しな
い主記憶或いは補助記憶装置上に割付けられる記憶エリ
アと考えてよい。そしてこれらのファイル２１，２２は
それぞれ一連のファイル番号にて一対一に対応付けて管
理されることは云うまでもない。

一括処理ファイル２１及び管理ファイル２２の生成終了
により、制御部１３のバッチ処理支援部１４が起動す
る。バッチ処理支援部１４には一括処理ファイル２１に
格納された取引データを１レコード（１取引データ）毎
に読出し、一括処理部１６を起動し読出した取引データ
を送出する。そして取引データの内容に従って一括処理
部１６がマスタファイル２０をアクセスし、指定された
振替処理を遂行することになる。与えられた取引データ
の処理が正常に終了すると、一括処理部１６は正常終了
の旨をバッチ処理支援部１４に通知する。これにより支
援部１４は次のレコードの取引データをファイル２１か
ら読出して一括処理部１６に与えられることになる。こ
のようにして一括処理ファイル２１の各レコードの取引
データが順次処理されることになる。

一方、与えられた取引データに対する処理が異常終了と
なった場合、一括処理部１６は異常終了の旨をデータベ
ース制御部１３に返送する。この異常終了の原因として
は、プログラム（一括処理部１６）でのデータ例外，デ
ータベース（マスタファイル）のアクセスエラー等があ
る。一括処理部１６からの異常終了通知は制御部１３の
異常処理部１９に受付けられる。

異常終了の通知を受けた異常処理部１９は、異常終了と
なった取引データを格納していた一括処理ファイル２１
に対応した管理ファイル２２上に、当該取引データの格
納されるファイルのレコード番号を記録する。この後一
括処理を継続する場合は図示しないコンソールより再度
リスタート指定で起動コマンドを投入する。すると、バ
ッチ処理支援部１４は次のレコードの取引データを読出
し、一括処理部１６による後続データの処理を続行せし
める。このようにして１つの一括処理ファイル２１中の
全取引データ（上述の例では１００件分のデータ）の処
理を実行することになる。

一括処理ファイル２１の処理終了により、オペレータは
コンソール（図示せず）を操作し、異常終了となった取
引データ（以下、異常終了データと略称する）の収集指
示を行う。この収集指示により、データベース制御部１
３のバッチ処理支援部１４が異常管理部１７を起動す
る。

異常管理部１７は、まず管理ファイル２２を参照し、異
常終了となったレコード番号Ｒを読出す。そしてこのレ
コード番号Ｒを用いて一括処理ファイル２１をアクセス
する。第２図に示すように、異常管理部１７は各ファイ
ル２１〜２３をアクセス可能なよう構成されている。異
常管理部１７は各ファイル２１，２２のアクセスにより
異常終了データとなった取引データＴＲＩを読出す。そ
して取引データ中に含まれる営業店コードに従って、各
営業店０１，０２，……毎に異常終了データを編集し、
編集結果を収集ファイル２３に格納する。以上の動作に
より１つの一括処理ファイル２１中の各取引データの処
理、及び一括処理にて異常終了となった取引データの収
集が行われる。

尚、従来においてセンタ側にて行っていた異常終了デー
タのリスト出力とは、この管理ファイル２２に記録され
るレコード番号及び入力データのリスト出力である。本
実施例では、収集ファイル２３中に、異常終了となった
取引データを各営業店毎にまとめて書出すものである。
更に、以下に述べる如く、この収集ファイル２３をデー
タベース制御部１３によって参照可能に設けるものであ
る。これにより、各営業店からの問合せに従って、異常
終了データをオンラインにて返送できるものである。

一括処理部１６にて一括処理が行われる時間帯は各銀行
システムにて予め定められている。したがって、各営業
店ではセンターによる一括処理の終了を見計って、セン
ターに対して異常終了データの参照（照会）要求を行
う。即ち各営業店３においては、自己の端末装置３１を
用いて要求を行う。この異常終了データの参照要求の為
の電文送出は、端末装置３１上の所定のキーに参照要求
指示機能を割付けることで容易に実現できる。

端末装置３１からの照会要求により、データベース制御
部１３は収集ファイル２３を参照する。この収集ファイ
ル２３のアクセスは、異常管理部１７を介して行われ
る。そして照会要求のあった端末装置１３の設置される
営業店に関連する異常終了データが読出される。読出さ
れた異常終了データは、データベース制御部１３及び通
信制御部１２を介し端末装置３１に返送される。

異常終了データを受信した端末装置３１は、自己のプリ
ンタ等によって、この受信データを照会票３２として出
力することになる。この照会票３２を見ることにより、
各営業店３において未処理のままとなっている取引デー
タ（この場合振替データ）を把握できる。そしてこの未
処理データのうち、即日（当日中）処理が必要なものに
ついては、上述した端末装置３３によるオンライン取引
処理にて遂行することになる。或いは営業店内でのオフ
ライン取引にて処理される場合もある。

以上の如く本実施例においては、センタ一括処理にて未
処理（以上終了）となった取引データについてその管理
・運用を各営業店にて分散できる。これにより、センタ
管理者による未処理データ発生に対する負荷を軽減でき
る。

また、未処理となった取引データを各営業店にて再処理
（オンライン，或いはオフライン処理）できるため、こ
の未処理データを対する迅速且つ適切な処理が可能とな
る。特に未処理データをオンライン取引にて処理する場
合、センタにおけるマスタファイルのアクセスを一括処
理部と別個に動作するオンライン処理部にて行うことに
なる。この為、一括処理部自体に障害が発生して未処理
となったデータについて、確実にリカバリ処理できるこ
とになる。

尚、上述した実施例において異常終了データの照会を行
う端末装置とオンライン取引の端末装置とを別個に設け
る如く説明したが、これは便宜上のものであって、両機
能を１つの端末装置で行えることは云うまでもない。ま
た、実施例ではセンタ一括処理として自動振替処理を例
にとったが、営業店にてオンラインで取扱う取引以外の
ものをセンターにて一括処理する場合に本発明が適用で
きることも勿論である。

〔発明の効果〕

以上のように本発明によれば、センターにて一括処理を
行う取引データ中に未処理（異常終了）のものが発生し
た場合、未処理の取引データを営業店側に通知できる。
従って、その取引データに対する処理を各営業店にて分
散して実行することが可能となり、異常終了となった取
引データに対する迅速且つ適切な対処が可能となる。

【図面の簡単な説明】

第１図及び第２図は本発明を銀行のオンラインシステム
に適用した場合の一実施例を示すもので、第１図はセン
ターでの一括処理システムの構成を示す図，第２図はシ
ステム全体の構成を示す図である。１はセンターコンピ
ュータ，３は営業店，１５はオンライン処理部，１６は
一括処理部，１７は異常管理部である。

Claims (1)

【特許請求の範囲】
1. 【請求項１】取引情報が入力される端末装置に接続さ
   れ、端末装置からの入力情報に基いて取引処理を行うオ
   ンライン取引処理部と、このオンライン取引処理部と別
   個に設けられオンライン取引以外の所定の取引を一括し
   て行う一括処理部とを備えたオンライン処理システムに
   おいて、前記一括処理部の処理中にエラーが発生した取
   引データに関連する情報を記憶する管理ファイルと、こ
   の管理ファイルに記憶された情報に基いて前記一括処理
   部にて異常終了となった取引データを収集する収集ファ
   イルとを備え、前記端末装置からの要求に応じてこの収
   集ファイルを参照し、端末装置の設置される営業店に関
   連する異常終了データを返送することを特徴とする取引
   処理データ管理方式。