JP3773883B2

JP3773883B2 - Transfer processing method

Info

Publication number: JP3773883B2
Application number: JP2002231652A
Authority: JP
Inventors: 伸一間舘; 博之米原
Original assignee: みずほＥｂサービス株式会社
Priority date: 2002-08-08
Filing date: 2002-08-08
Publication date: 2006-05-10
Anticipated expiration: 2022-08-08
Also published as: JP2004070822A

Description

【０００１】
【発明の属する技術分野】
本発明は、預金口座を利用して振込処理を行なう場合に用いる振込処理方法に関するものである。
【０００２】
【従来の技術】
今日、金融機関の預金口座を用いて各種の支払いを行なうことが多い。例えば、企業においても、社員に対して給与や出張旅費を支払う場合、企業の預金口座から社員の預金口座への振込サービスを利用する。この場合、企業はまず振込先口座や払出口座に関するデータを含む振込データを生成する。そして、金融機関のホストシステムに接続されたクライアント端末を利用して金融機関に送信する。複数の振込先口座への振込を行なう場合には、振込毎に振込処理の依頼を行なう。このような振込サービスを利用することにより、企業は効率的に支払いを行なうことができる。
【０００３】
【発明が解決しようとする課題】
しかし、このような振込サービスには利用できる時間の制限が課せられている場合がある。すなわち、金融機関のホストシステムがクライアント端末から振込依頼を受け付けている時間（振込サービスを提供して時間）が決められており、この時間内に企業は振込データの送信を完了する必要がある。
【０００４】
一方、金融機関のホストシステムに振込データを送信し、振込処理が実行され、その結果が返送されてくるまでには、所定の時間がかかる。従って、振込依頼件数が集中した場合、振込サービスの利用可能時間内に振込処理を完了することが困難な場合もある。この場合には、再度振込依頼を実行する必要があり、支払の遅延が生じる。
【０００５】
本発明は、上記問題点を解決するためになされたものであり、その目的は、複数の払出口座を用いて、効率的に振込処理を行なうことができる振込処理方法を提供することにある。
【０００６】
【課題を解決するための手段】
上記問題点を解決するために、請求項１に記載の発明は、複数の払出口座毎に割り振られ金融機関ホストシステムに接続して振込処理を実行する各振込処理端末と、所定周期に振込依頼をまとめて一つの振込依頼ファイルを生成する企業システムと、前記企業システムから受信した振込依頼ファイルを受付データファイルとして記録する依頼受付データ記憶手段と、前記振込依頼の振込処理を行なうための振込実行データファイルを記録する振込依頼データ記憶手段と、振込依頼毎に振込処理結果を記録する処理結果データ記憶手段と、各手段に接続された管理コンピュータとを有する口座管理システムを用いて振込処理を行なう方法であって、前記管理コンピュータが、前記依頼受付データ記憶手段に記録された受付データファイルを抽出し、前記受付データファイルに含まれる振込依頼の件数を把握する段階と、前記受付データファイルに含まれる前記振込依頼の件数が所定件数を越える場合は、前記管理コンピュータが、前記受付データファイルに含まれる振込依頼を前記所定件数毎に区切り、この区切毎に分割した振込実行データファイルを生成し、前記受付データファイルに含まれる前記振込依頼の件数が所定件数を越えない場合には、この分割処理をスキップし、前記振込実行データファイルを前記振込依頼データ記憶部に記録するとともに、前記依頼受付データ手段に記録された受付データファイルを削除する段階と、複数の振込処理端末が、順次、一定時間の間隔で振込依頼データ記憶手段の検索を行ない、振込依頼データ記憶手段に振込実行データファイルが記録されている場合には、振込処理端末はそのファイルの転送を受け、振込実行データファイルに含まれる振込依頼に関して、前記各振込処理端末に対応付けられた払出口座を用いて、順次、金融機関ホストシステムに対して振込処理を行なう段階と、前記振込実行データファイルの中の振込依頼について、金融機関ホストシステムから、振込処理結果として振込処理を実行できなかった旨の回答を受信した場合、前記振込処理端末が前記振込依頼に対して「エラー」フラグを付した処理結果データファイルを振込処理結果として前記処理結果データ記憶手段に記録し、前記企業システムが、定期的に前記処理結果データ記憶手段に記録された処理結果データファイルを回収し、「エラー」フラグの付加された振込依頼については、再度、振込処理を指示することを要旨とする。
【００１９】
本発明によれば、振込実行データファイルは、受付データファイルに含まれる振込依頼を前記所定件数毎に区切り、この区切毎に分割することにより生成される。このため、比較的簡単に所定件数以下の振込依頼を含む振込実行データファイルを生成することができる。
【００２０】
本発明によれば、管理コンピュータが、前記受付データファイルに含まれる振込依頼の件数を把握する。分割処理は、前記振込依頼の件数が所定件数を越える場合のみ実行される。必要な場合のみ分割処理が実行されるので、効率的に振込処理を実行することができる。
【００２１】
本記載の発明によれば、管理コンピュータは、払出口座を有する口座名義人が管理する支払管理システムに接続される。依頼受付データ記憶手段に記録された受付データファイルは、前記支払管理システムから受信した振込依頼に関するデータである。このため、口座管理システムは受付データファイルを効率的に取得でき、より迅速に振込処理を行なうことができる。
【００２２】
本発明によれば、口座管理システムには、各振込依頼に対する振込処理結果を記録する処理結果データ記憶手段をさらに有する。管理コンピュータは、振込処理端末が行なった振込処理結果を処理結果データ記憶手段に記録する。このため、口座管理システムは、払出口座を有する口座名義人に振込処理状況を提供することができる。
【００２３】
本発明によれば、振込処理結果には、振込処理を行なった前記振込処理端末に対応する払出口座の口座識別子を含める。このため、払出口座を有する口座名義人に、複数用意された払出口座の各口座の状況を提供することができる。
【００２４】
【発明の実施の形態】
以下、本発明を具体化した一実施形態を、図１〜図７に従って説明する。本実施形態では、金融機関に預金口座を保有する企業が、社員の預金口座に振込処理を行なうことにより、諸費用を支払う場合に用いる振込処理方法及び振込処理プログラムとして説明する。この振込処理には、金融機関が提供するネットワークを利用しての振込サービスを利用する。この処理は、口座管理システム２０、振込処理端末としてのクライアント端末（１０、１１）を用いて行なわれる。
【００２５】
図１に示すように、口座管理システム２０はネットワークＮ１を介して、支払管理システムとしての企業システム４０に接続されている。この企業システム４０は、社員に支払うべき各種費用を管理し、振込依頼のためのデータファイルを生成する。そして、企業システム４０は、ネットワークＮ１を介して口座管理システム２０と通信を行なうことにより、生成した振込依頼データファイルを送信したり、口座管理システム２０から振込処理結果を受信したりする。
【００２６】
口座管理システム２０は、振込処理の管理を行なうコンピュータシステムである。この口座管理システム２０は、図１に示すように、管理コンピュータ２１を備えている。管理コンピュータ２１は、図示しない制御手段（ＣＰＵ）、記憶手段（ＲＡＭ、ＲＯＭ、ハードディスク等）やデータ送受信手段等を有する。この管理コンピュータ２１は、振込依頼に関して後述する処理手順（振込実行データファイルを生成する段階、振込処理端末に振込処理を実行させる段階、振込依頼の件数を把握する段階、振込処理結果を記録する段階等を含む）のための振込処理プログラムを実行する。これにより、管理コンピュータ２１は、振込実行データファイルを生成する手段、振込処理端末に振込処理を実行させる手段、振込依頼の件数を把握する手段、振込処理結果を記録する手段等の各手段として機能する。
【００２７】
この管理コンピュータ２１には、クライアント端末（１０、１１）が接続されている。これらのクライアント端末（１０、１１）は、ネットワークＮ２を介して金融機関ホストシステム３０に接続されている。金融機関ホストシステム３０は企業の預金口座を管理する金融機関のホストコンピュータシステムである。この金融機関ホストシステム３０は、クライアント端末（１０、１１）からの振込指示に基づいて、払出口座から他の預金口座（ここでは、社員は指定する預金口座）への振込処理を行なう。
【００２８】
管理コンピュータ２１には、依頼受付データ記憶手段としての依頼受付データ記憶部２３、振込依頼データ記憶手段としての振込依頼データ記憶部２４及び処理結果データ記憶手段としての処理結果データ記憶部２５がそれぞれ接続されている。
【００２９】
依頼受付データ記憶部２３には、図２に示すように、ネットワークＮ１を介して企業システム４０から受信した振込依頼に関して受付データファイル２３０が記録されている。この受付データファイル２３０は、口座管理システム２０が企業システム４０から振込依頼を受信した場合に記録される。受付データファイル２３０は、各振込依頼に対応するレコードを含むデータテーブルから構成されている。一度に複数回の預金口座への振込を依頼するため、一つの受付データファイル２３０には複数の振込依頼を含めることが可能である。そのため、受付データファイル２３０には複数のレコードを含めることができる。受付データファイル２３０の各レコードは振込依頼毎に依頼番号、振込先口座識別子、受取人名、及び金額に関するデータフィールドが設定され、それぞれのデータが相互に関連づけられて記録される。
【００３０】
依頼番号データフィールドには、各振込依頼を識別するために割り振られた番号に関するデータが記録される。
振込先口座識別子データフィールドには、振込先の預金口座を特定するための識別子に関するデータが記録される。本実施形態では、振込先口座識別子は、社員が指定した預金口座に関して金融機関コード、支店コード、預金種目コード及び口座番号に関するデータを含んで構成される。本実施形態では、振込先口座識別子として「ａａａ」〜「ｍｍｍ」を用いて説明する。
【００３１】
受取人名データフィールドには、振込先の預金口座の名義人を特定するための名前に関するデータが記録される。本実施形態では、受取人名として「Ａ」〜「Ｍ」を用いて説明する。
【００３２】
金額データフィールドには、振込処理を行なう金額に関するデータが記録される。この金額は、企業が支払を行なう各種費用の金額である。
本実施形態では、受付データファイル２３０として、受付データファイル２３１と受付データファイル２３２とを用いて説明する。
【００３３】
振込依頼データ記憶部２４には、図３に示すように、金融機関ホストシステム３０に対して振込指示を行なうために、クライアント端末（１０、１１）に提供する振込実行データファイル２４０が記録されている。この振込実行データファイル２４０は、管理コンピュータ２１が依頼受付データ記憶部２３に記録された受付データファイル２３０を確認した場合に記録される。本実施形態では、振込実行データファイル２４０は、受付データファイル２３０と同様に、各振込依頼に対応するレコードを含むデータテーブルから構成されている。そして、各レコードは振込依頼毎に依頼番号、振込先口座識別子、受取人名及び金額に関するデータフィールドが設定され、それぞれのデータが相互に関連づけられて記録される。
【００３４】
但し、受付データファイル２３０と振込実行データファイル２４０とでは、１ファイルに含まれる最大レコード数が異なる。本実施形態では、受付データファイル２３０にはレコード数に制限はない。一方、振込実行データファイル２４０においては、１ファイルに含まれるレコード数に制限が設定されている。本実施形態では、最大レコード数を１０件とする。
【００３５】
処理結果データ記憶部２５には、図４に示すように、クライアント端末（１０、１１）を介して行なわれた振込処理の結果に関する処理結果データファイル２５０が記録されている。この処理結果データファイル２５０は、クライアント端末（１０、１１）を介して金融機関ホストシステム３０から振込処理結果を受信した場合に記録される。本実施形態では、処理結果データファイル２５０には、振込依頼毎に依頼番号、振込先口座識別子、受取人名、金額、払出口座識別子及び処理結果に関するフィールドが設定され、それぞれのデータが相互に関連づけられて記録される。
【００３６】
処理結果データファイル２５０に含まれる依頼番号、振込先口座識別子、受取人名、金額は、受付データファイル２３０に含まれる依頼番号、振込先口座識別子、受取人名、金額に対応する。
【００３７】
払出口座識別子データフィールドには、振込元の預金口座を特定するための識別子に関するデータが記録される。本実施形態では、企業が保有する預金口座に関して金融機関コード、支店コード、預金種目コード及び口座番号に関するデータを含んで構成される。本実施形態では、払出口座識別子として「ｙｙｙ」及び「ｚｚｚ」を用いて説明する。
【００３８】
処理結果データフィールドには、振込処理の結果に関するデータが記録される。本実施形態では、振込指示どおりに振込処理が完了した場合には、処理結果データフィールドに「正常」フラグが設定される。一方、金融機関ホストシステム３０が振込処理を完了できなかった場合には、処理結果データフィールドに「エラー」フラグが設定される。
【００３９】
次に、上記のように構成されたシステムにおいて、企業が社員指定の預金口座への振込処理を行なう場合の手順を説明する。ここでは、払出口座の設定処理、企業システム４０の振込依頼処理及び口座管理システム２０での振込管理処理の順に説明する。
【００４０】
（払出口座の設定処理）
まず、企業は複数の払出口座を金融機関に開設する。そして、払出口座に対応したクライアント端末（１０、１１）を設置する。これらのクライアント端末（１０、１１）は、対応付けられた払出口座を用いて振込処理を実行する。本実施形態では、企業は払出口座として２つの預金口座を開設する場合を想定する。以下、口座識別子「ｙｙｙ」の預金口座を口座「ｙｙｙ」と呼び、口座識別子「ｚｚｚ」の預金口座を口座「ｚｚｚ」と呼ぶ。そして、クライアント端末１０は口座「ｙｙｙ」を用いての振込処理、クライアント端末１１は口座「ｚｚｚ」を用いての振込処理を実行するように設定する。
【００４１】
また、クライアント端末（１０、１１）を用いて各払出口座から振込処理を行なう場合、１日の１口座あたりの振込総額、振込総件数に関して上限値が設定されている。本実施形態では、口座「ｙｙｙ」に対しては上限金額として２０００円、上限件数として１０００件が設定されている。また、口座「ｚｚｚ」に対しては上限金額として３０００円、上限件数として７００件が設定されている。
【００４２】
（企業システム４０での振込依頼処理）
次に、企業システム４０が口座管理システム２０に対して振込依頼を行なう場合の処理を説明する。例えば、社員が出張旅費等の各種経費を清算する場合、要した費用を上司に申請し承認を受ける。そして、企業システム４０は承認処理が完了した振込依頼を蓄積しておく。この場合、複数の経費に関する承認がなされた場合には、複数の振込処理依頼が蓄積される。
【００４３】
そして、企業システム４０は所定周期（例えば１時間おき）に振込依頼をまとめて一つの振込依頼ファイルを生成する。そして、企業システム４０は、口座管理システム２０にネットワークＮ１を介して振込依頼ファイルを送信する。振込依頼ファイルを受信した口座管理システム２０は、このファイルを、受付データファイル２３０として依頼受付データ記憶部２３に記録する。
【００４４】
（振込管理処理）
次に、振込管理処理について図５を用いて説明する。管理コンピュータ２１は、金融機関ホストシステム３０が稼働している運用時間帯に、この処理を実行する。
【００４５】
まず、管理コンピュータ２１は、依頼受付データ記憶部２３のファイル状況の確認する（Ｓ１−１）。この処理は予め設定された周期で定期的に行なわれる。具体的には、管理コンピュータ２１は、依頼受付データ記憶部２３に受付データファイル２３０があるかどうかを確認する。依頼受付データ記憶部２３に受付データファイル２３０が記録されていない場合（ステップ（Ｓ１−２）において「Ｎｏ」の場合）、ステップ（Ｓ１−１）を再度、実行する。
【００４６】
本実施形態では、図２に示すように受付データファイル２３１、受付データファイル２３２の２つの受付データファイル２３０が、依頼受付データ記憶部２３に記録されている場合を想定する。このように、依頼受付データ記憶部２３に受付データファイル２３０が記録されている場合（ステップ（Ｓ１−２）において「Ｙｅｓ」の場合）、管理コンピュータ２１は１ファイルの中に含まれる振込依頼件数（レコード数）の確認を行なう（Ｓ１−３）。本実施形態では、受付データファイル２３１には、依頼番号「１」〜「１２」に関する１２件のレコードが含まれる。一方、受付データファイル２３２には、依頼番号「１３」〜「１７」に関する５件のレコードが含まれる。
【００４７】
１ファイルの振込依頼件数が、予め設定された設定件数より多い場合（ステップ（Ｓ１−４）において「Ｙｅｓ」の場合）、管理コンピュータ２１は、設定件数内に収まるように受付データファイル２３０を分割する（Ｓ１−５）。本実施形態では、設定件数として「１０件」が設定されている。本実施形態では、受付データファイル２３１には１２件のレコードが含まれており設定件数（１０件）より多い。そこで、管理コンピュータ２１は、依頼番号順に１０件で分割する。この場合、受付データファイル２３１を依頼番号「１」〜「１０」の１０件のレコードから構成されたファイル（後述する振込実行データファイル２４１）と、「１１」〜「１２」の２件のレコードから構成されたファイル（後述する振込実行データファイル２４２）とに分割される。
【００４８】
一方、１ファイルの振込依頼件数が予め設定された設定件数以下の場合（ステップ（Ｓ１−４）において「Ｎｏ」の場合）、ステップ（Ｓ１−５）をスキップする。本実施形態では、受付データファイル２３２は５件のレコードから構成されており、設定件数（１０件）より少ないため分割されない。
【００４９】
そして、管理コンピュータ２１は、受付データファイル２３０又は分割された受付データファイル２３０を、振込実行データファイル２４０として振込依頼データ記憶部２４に記録する（Ｓ１−６）。振込依頼データ記憶部２４にファイルを記録する場合、管理コンピュータ２１は依頼受付データ記憶部２３に記録された受付データファイル２３０を削除する。
【００５０】
そして、本実施形態では、図３に示すように、振込依頼データ記憶部２４には受付データファイル２３１から分割生成した振込実行データファイル２４１、振込実行データファイル２４２及び受付データファイル２３２を移管した振込実行データファイル２４３が記録される。このように、各振込実行データファイル２４０は振込依頼データ記憶部２４に記録されることにより振込処理の待ち状態となる。
【００５１】
クライアント端末（１０、１１）は、振込処理終了後、一定時間の間隔で振込依頼データ記憶部２４の検索を行なう。振込依頼データ記憶部２４に振込実行データファイル２４０が記録されている場合には、クライアント端末（１０、１１）はそのファイルの転送を受ける（Ｓ１−７）。そして、クライアント端末（１０、１１）は、ネットワークＮ２を介して振込処理を行なう。具体的には、クライアント端末（１０、１１）は、取得した振込実行データファイル２４０に基づいて金融機関ホストシステム３０に振込指示を送信する。
【００５２】
この振込処理の様子を図６及び図７を用いて説明する。図６は払出口座「ｙｙｙ」の振込金額残枠、振込件数残枠の残枠推移５００を示している。一方、図７は払出口座「ｚｚｚ」の振込金額残枠、振込件数残枠の残枠推移５１０を示している。
【００５３】
図６、図７に示すように残枠（５０１、５０２、５１１〜５１３）には振込金額残枠と振込件数残枠とがある。振込金額残枠とは振込金額総額が上限金額に達するまでに残りの余裕枠であり、振込件数残枠とは振込総件数が上限件数に達するまでに残りの余裕枠である。
【００５４】
まず、クライアント端末１０に対応した払出口座「ｙｙｙ」の推移について説明する。図６の残枠５０１に示すように、本実施形態の振込処理を行なう前には、振込金額残枠は１０００円、振込件数残枠は５００件とする。クライアント端末１０は振込依頼データ記憶部２４を検索し、振込実行データファイル２４１を取得する。そして、クライアント端末１０は、払出口座「ｙｙｙ」を用いて、振込実行データファイル２４１に含まれる振込依頼に関して、依頼番号「１」から順次、振込処理を行なう。ここで、払出口座「ｙｙｙ」の振込金額残枠は１０００円であるため、依頼番号「１」〜「７」の処理を行なった段階で９１０円の振込処理を行なったことになり、この時点で振込金額残枠は、残枠５０２に示すように９０円になる。依頼番号「８」は１７０円の振込依頼であるため、この振込処理を行なうと上限金額を超えることになる。
【００５５】
このため、クライアント端末１０がネットワークＮ２を介して金融機関ホストシステム３０に対して振込指示を行なっても、残枠不足のため振込処理を実行できず、その旨の回答を金融機関ホストシステム３０から受信する。従って、依頼番号「８」〜「１０」は振込処理を実行できず「エラー」となる。
【００５６】
そして、クライアント端末１０は、管理コンピュータ２１に処理結果を通知する。管理コンピュータ２１は、処理結果データ記憶部２５に、この処理結果を記録する（Ｓ１−８）。この場合、図４に示すように、処理結果データ記憶部２５には処理結果データファイル２５１が記録される。この振込処理はクライアント端末１０が行なったため、払出口座識別子としてクライアント端末１０に対応した「ｙｙｙ」が記録される。
【００５７】
次に、クライアント端末１１に対応した払出口座「ｚｚｚ」の処理について説明する。ここでは、クライアント端末１０が振込実行データファイル２４１を取得後に、クライアント端末１１が振込依頼データ記憶部２４を検索した場合を想定する。この場合、振込依頼データ記憶部２４には振込実行データファイル２４２と振込実行データファイル２４３とが残っている。そこで、クライアント端末１１は振込実行データファイル２４２を取得し、振込処理を行なう。
【００５８】
ここで、図７の残枠５１１に示すように、振込処理を行なう前には、払出口座「ｚｚｚ」の振込金額残枠は２５００円、振込件数残枠は６件とする。払出口座「ｚｚｚ」の処理を行なうクライアント端末１１が振込依頼データ記憶部２４から振込実行データファイル２４２を取得した場合、依頼番号「１１」から順次処理を行なう。ここで、振込実行データファイル２４２に含まれる振込処理を実行後、払出口座「ｚｚｚ」の振込金額残枠は、残枠５１２に示すように２０９０円、振込件数残枠は４件になる。
【００５９】
そして、クライアント端末１１は、管理コンピュータ２１に処理結果を通知する。管理コンピュータ２１は、処理結果データ記憶部２５にこの処理結果を記録する（Ｓ１−８）。この場合、図４に示すように、処理結果データ記憶部２５には処理結果データファイル２５２が記録される。この振込処理はクライアント端末１１が行なったため、払出口座識別子として、クライアント端末１１に対応した「ｚｚｚ」が記録される。
【００６０】
さらに、クライアント端末１１が振込依頼データ記憶部２４を検索する。ここでは、クライアント端末１０が振込実行データファイル２４１の処理を完了しておらず、振込依頼データ記憶部２４には振込実行データファイル２４３がまだ残っている場合を想定する。そこで、クライアント端末１１は振込実行データファイル２４３を取得し、振込処理を行なう。
【００６１】
この段階では、残枠５１２に示すように、振込処理を行なう前には、振込金額残枠は２０９０円、振込件数残枠は４件となっている。クライアント端末１１が振込実行データファイル２４３の振込処理を実行する場合、依頼番号「１３」から順次処理を行なう。ここで、払出口座「ｙｙｙ」の振込件数残枠は４件であるため、依頼番号「１３」〜「１６」の処理を行なった段階で、残枠５１３に示すように、振込件数残枠は０件になる。従って、依頼番号「１７」に関する振込処理は実行できず「エラー」となる。
【００６２】
そして、クライアント端末１１は、管理コンピュータ２１に処理結果を通知する。管理コンピュータ２１は、処理結果データ記憶部２５にこの処理結果を記録する（Ｓ１−８）。この場合、図４に示すように、処理結果データ記憶部２５には処理結果データファイル２５３が記録される。この振込処理はクライアント端末１１が行なったため、払出口座識別子としてクライアント端末１１に対応した「ｚｚｚ」が記録される。以上により、振込管理処理を終了する。
【００６３】
企業システム４０は、定期的に処理結果データ記憶部２５に記録された処理結果データファイル２５０を回収する。振込処理が完了していないもの（「エラー」フラグの付加された振込依頼）については、再度、振込処理を指示する。
【００６４】
以上、本実施形態によれば、以下に示す効果を得ることができる。
・上記実施形態では、１ファイルの振込依頼件数が、予め設定された設定件数より多い場合、管理コンピュータ２１はファイルを設定件数で分割して、振込実行データファイル２４０を生成する。このため、クライアント端末（１０、１１）は、一度に実行する振込処理を所定件数以下に抑えることができる。従って、企業システム４０から一度に多くの振込依頼を含む振込依頼が送られてきた場合においても振込処理を分散し、特定のクライアント端末（１０、１１）の過負荷を防止できる。特に、本実施形態ではファイルの分割という簡単な処理により、クライアント端末（１０、１１）の負荷分散を図ることができる。
【００６５】
・上記実施形態では、クライアント端末（１０、１１）は、複数の振込依頼を含む振込実行データファイル２４０を用いて振込処理を行なう。このため、クライアント端末（１０、１１）は、振込依頼データ記憶部２４から取得した振込実行データファイル２４０を用いて、複数の振込処理を効率的に行なうことができる。
【００６６】
・上記実施形態では、振込依頼データ記憶部２４には、クライアント端末（１０、１１）は、振込処理を完了後、定期的に振込依頼データ記憶部２４から振込実行データファイル２４０を順次取得し、振込処理を実行する。このため、振込処理を完了していないクライアント端末（１０、１１）を除き、振込処理を終えたクライアント端末（１０、１１）が順次振込処理を行なう。従って、クライアント端末（１０、１１）を効率的に利用することができる。
【００６７】
・上記実施形態では、企業は複数の払出口座を金融機関に開設し、この払出口座に対応したクライアント端末（１０、１１）を設置する。これらのクライアント端末（１０、１１）は、対応付けられた払出口座を用いて振込処理を実行する。振込依頼件数が多い場合、一つの払出口座からの振込処理を行なっていたのでは時間がかかり、所定期間内（金融機関ホストシステム３０の運用期間内）に完了しない場合もある。複数の払出口座に対応した複数のクライアント端末（１０、１１）を設けることにより、例えば、旅費の清算処理のように、金額自身は小さいが件数が非常に多い振込処理に対しても対応することができる。
【００６８】
・上記実施形態では、処理結果データ記憶部２５には、クライアント端末１０、クライアント端末１１を介して行なわれた振込処理の結果に関する処理結果データファイル２５０が記録されている。処理結果データファイル２５０には、振込依頼毎に依頼番号、振込先口座識別子、受取人名、金額、払出口座識別子及び処理結果に関するファールドが設定され、それぞれのデータが相互に関連づけられて記録される。このため、企業システム４０は各振込処理依頼の結果を把握することができる。
【００６９】
なお、上記実施形態は、以下の態様に変更してもよい。
・上記実施形態では、企業は払出口座として２つの預金口座（口座「ｙｙｙ」及び口座「ｚｚｚ」）を開設する。さらに多くの払出口座を設けてもよい。その場合にこれに対応した数のクライアント端末（１０、１１）を設ける。上記実施形態では、管理コンピュータ２１は、受付データファイル２３０に基づいて、所定件数内に分割した振込実行データファイル２４０を振込依頼データ記憶部２４に記録するだけなので、クライアント端末（１０、１１）の数の変更に容易に対応できる。
【００７０】
・上記実施形態では、金融機関に預金口座を保有する企業が、社員の預金口座に振込処理を行なうことにより、諸費用を支払う場合に用いる振込処理方法及び振込処理プログラムとして説明する。支払者が振込サービスを利用して、複数の口座への振込により支払を行なうものであれば、支払者としての企業、受取人としての社員にかかわらず適用可能である。
【００７１】
・上記実施形態では、１ファイルの振込依頼件数が、予め設定された設定件数より多い場合、管理コンピュータ２１は、設定件数内に収まるように受付データファイル２３０を分割する。設定件数として「１０件」が設定されている。これに代えて、他の件数で分割してもよい。この件数は、クライアント端末（１０、１１）の台数や振込処理に要する時間を勘案して決定する。
【００７２】
・上記実施形態では、企業システム４０は所定周期に振込依頼をまとめて一つの振込依頼ファイルを生成する。そして、企業システム４０は、口座管理システム２０にネットワークＮ１を介して振込依頼ファイルを送信する。そして、振込依頼ファイルを受信した口座管理システム２０は、このファイルを、受付データファイル２３０として依頼受付データ記憶部２３に記録する。これに代えて、企業からＭＴ形式等の記録媒体で持ち込まれた振込依頼ファイルを受付データファイル２３０として依頼受付データ記憶部２３に記録してもよい。
【００７３】
・上記実施形態では、クライアント端末（１０、１１）は、管理コンピュータ２１に処理結果を通知する。管理コンピュータ２１は、処理結果データ記憶部２５に処理結果を記録する。これに代えて、クライアント端末（１０、１１）が直接、処理結果を処理結果データ記憶部２５に記録するようにしてもよい。
【００７４】
【発明の効果】
以上詳述したように、本発明によれば、複数の払出口座を用いて、効率的に振込処理を行なうことができる。
【図面の簡単な説明】
【図１】本発明の実施形態のシステム概略図。
【図２】依頼受付データ記憶部に記録されたデータの説明図。
【図３】振込依頼データ記憶部に記録されたデータの説明図。
【図４】処理結果データ記憶部に記録されたデータの説明図。
【図５】本発明の実施形態の処理手順の説明図。
【図６】口座の残高推移の説明図。
【図７】口座の残高推移の説明図。
【符号の説明】
１０，１１…振込処理端末としてのクライアント端末、２０…口座管理システム、２１…管理コンピュータ、２３…依頼受付データ記憶手段としての依頼受付データ記憶部、２３０，２３１，２３２…受付データファイル、２４…振込依頼データ記憶手段としての振込依頼データ記憶部、２４０，２４１，２４２，２４３…振込実行データファイル、２５…処理結果データ記憶手段としての処理結果データ記憶部、４０…支払管理システムとしての企業システム。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a transfer processing method used when performing a transfer process using a deposit account. To the law It is related.
[0002]
[Prior art]
Today, various payments are often made using a deposit account of a financial institution. For example, even in a company, when paying a salary or a business trip expense to an employee, a transfer service from the account of the company to the account of the employee is used. In this case, the company first generates transfer data including data relating to the transfer destination account and the payout account. And it transmits to a financial institution using the client terminal connected to the host system of the financial institution. When making a transfer to a plurality of transfer destination accounts, a request for a transfer process is made for each transfer. By using such a transfer service, a company can pay efficiently.
[0003]
[Problems to be solved by the invention]
However, there are cases where such a transfer service imposes restrictions on the time available. In other words, a time during which a host system of a financial institution accepts a transfer request from a client terminal (time for providing a transfer service) is determined, and the company needs to complete transmission of the transfer data within this time.
[0004]
On the other hand, it takes a predetermined time until the transfer data is transmitted to the host system of the financial institution, the transfer process is executed, and the result is returned. Therefore, when the number of transfer requests is concentrated, it may be difficult to complete the transfer process within the available time of the transfer service. In this case, it is necessary to execute the transfer request again, resulting in a delay in payment.
[0005]
The present invention has been made to solve the above-described problems, and its purpose is to provide a transfer processing method that can efficiently perform a transfer process using a plurality of payout accounts. The law It is to provide.
[0006]
[Means for Solving the Problems]
In order to solve the above-mentioned problems, the invention described in claim 1 is characterized in that each transfer processing terminal that is allocated to each of a plurality of payout accounts and is connected to a financial institution host system and executes a transfer process, and a transfer request at a predetermined cycle System for generating a single transfer request file together, request reception data storage means for recording the transfer request file received from the company system as a reception data file, and transfer execution for performing the transfer processing of the transfer request Transfer processing is performed using an account management system having a transfer request data storage means for recording a data file, a processing result data storage means for recording a transfer processing result for each transfer request, and a management computer connected to each means. The management computer extracts a reception data file recorded in the request reception data storage means. The comprising the steps of grasping the number of transfer requests that are included in the reception data file, if the number of the transfer request that is included in the reception data file exceeds a predetermined number Is The management computer divides a transfer request included in the received data file into the predetermined number of cases, and divides into each of the divisions. did Generate a transfer execution data file, If the number of transfer requests included in the received data file does not exceed a predetermined number, the division process is skipped and the transfer execution data file is changed to the transfer execution data file. Recording in the transfer request data storage unit and deleting the received data file recorded in the request received data means; Multiple shakes Embedded processing terminal Sequentially When the transfer request data storage means is searched at regular time intervals, and the transfer execution data file is recorded in the transfer request data storage means, the transfer processing terminal receives the transfer of the file and stores it in the transfer execution data file. Regarding the transfer request included, Using the payout account associated with each transfer processing terminal, From the financial institution host system, the step of sequentially performing the transfer process to the financial institution host system and the transfer request in the transfer execution data file, As a result of the transfer process The transfer process could not be executed Effect When the response is received, the transfer processing terminal records the processing result data file with the “error” flag attached to the transfer request as the transfer processing result in the processing result data storage means, and the company system periodically The processing result data file recorded in the processing result data storage means is collected, and the transfer request with the “error” flag added is instructed to transfer again.
[0019]
Book According to the invention, the transfer execution data file is generated by dividing the transfer request included in the received data file into the predetermined number of pieces and dividing the transfer request into the divided pieces. For this reason, a transfer execution data file including transfer requests of a predetermined number or less can be generated relatively easily.
[0020]
Book According to the invention, the management computer grasps the number of transfer requests included in the received data file. The division process is executed only when the number of transfer requests exceeds a predetermined number. Since the dividing process is executed only when necessary, the transfer process can be executed efficiently.
[0021]
Book According to the described invention, the management computer is connected to a payment management system managed by an account holder having a payout account. The reception data file recorded in the request reception data storage means is data relating to the transfer request received from the payment management system. For this reason, the account management system can acquire the reception data file efficiently, and can perform a transfer process more rapidly.
[0022]
Book According to the invention, the account management system further includes processing result data storage means for recording a transfer processing result for each transfer request. The management computer records the transfer processing result performed by the transfer processing terminal in the processing result data storage means. For this reason, the account management system can provide the transfer processing status to the account holder having the payout account.
[0023]
Book According to the invention, the transfer process result includes the account identifier of the payout account corresponding to the transfer processing terminal that performed the transfer process. For this reason, the account holder having a payout account can be provided with the status of each of the multiple payout accounts.
[0024]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment embodying the present invention will be described with reference to FIGS. This embodiment will be described as a transfer processing method and a transfer processing program used when a company that holds a deposit account in a financial institution pays various expenses by performing a transfer process on an employee's deposit account. This transfer process uses a transfer service using a network provided by a financial institution. This process is performed using the account management system 20 and the client terminals (10, 11) as transfer processing terminals.
[0025]
As shown in FIG. 1, the account management system 20 is connected to a company system 40 as a payment management system via a network N1. The company system 40 manages various expenses to be paid to employees and generates a data file for a transfer request. Then, the enterprise system 40 communicates with the account management system 20 via the network N1, thereby transmitting the generated transfer request data file or receiving a transfer processing result from the account management system 20.
[0026]
The account management system 20 is a computer system that manages the transfer process. The account management system 20 includes a management computer 21 as shown in FIG. The management computer 21 includes control means (CPU), storage means (RAM, ROM, hard disk, etc.), data transmission / reception means, etc., not shown. This management computer 21 is a processing procedure (steps for generating a transfer execution data file, a step for causing the transfer processing terminal to execute a transfer process, a step for grasping the number of transfer requests, and a step for recording the transfer process result) Etc.) is executed. Thereby, the management computer 21 functions as each means such as a means for generating a transfer execution data file, a means for causing the transfer processing terminal to execute a transfer process, a means for grasping the number of transfer requests, and a means for recording the result of the transfer process. To do.
[0027]
Client terminals (10, 11) are connected to the management computer 21. These client terminals (10, 11) are connected to the financial institution host system 30 via the network N2. The financial institution host system 30 is a host computer system of a financial institution that manages corporate deposit accounts. The financial institution host system 30 performs a transfer process from the payout account to another deposit account (here, a deposit account designated by the employee) based on a transfer instruction from the client terminal (10, 11).
[0028]
Connected to the management computer 21 are a request acceptance data storage unit 23 as a request acceptance data storage unit, a transfer request data storage unit 24 as a transfer request data storage unit, and a processing result data storage unit 25 as a processing result data storage unit. Has been.
[0029]
In the request acceptance data storage unit 23, as shown in FIG. 2, a receipt data file 230 is recorded regarding the transfer request received from the company system 40 via the network N1. The received data file 230 is recorded when the account management system 20 receives a transfer request from the company system 40. The reception data file 230 is composed of a data table including a record corresponding to each transfer request. In order to request transfer to a deposit account a plurality of times at a time, a single acceptance data file 230 can include a plurality of transfer requests. Therefore, the reception data file 230 can include a plurality of records. Each record of the reception data file 230 has a request number, a transfer destination account identifier, a payee name, and a data field related to the amount for each transfer request, and the respective data are recorded in association with each other.
[0030]
In the request number data field, data relating to a number assigned to identify each transfer request is recorded.
In the transfer account identifier data field, data relating to an identifier for specifying the deposit account of the transfer destination is recorded. In the present embodiment, the bank account identifier includes data relating to a financial institution code, a branch code, a deposit type code, and an account number for a deposit account designated by an employee. In the present embodiment, description will be made using “aaa” to “mmm” as transfer account identifiers.
[0031]
In the payee name data field, data relating to a name for identifying the holder of the deposit account at the transfer destination is recorded. In the present embodiment, description will be made using “A” to “M” as recipient names.
[0032]
In the money amount data field, data relating to the money amount to be transferred is recorded. This amount is the amount of various expenses paid by the company.
In the present embodiment, the reception data file 230 will be described using a reception data file 231 and a reception data file 232.
[0033]
As shown in FIG. 3, a transfer execution data file 240 provided to the client terminal (10, 11) is recorded in the transfer request data storage unit 24 in order to give a transfer instruction to the financial institution host system 30. Yes. This transfer execution data file 240 is recorded when the management computer 21 confirms the reception data file 230 recorded in the request reception data storage unit 23. In the present embodiment, the transfer execution data file 240 is composed of a data table including records corresponding to each transfer request, like the received data file 230. Each record has a request number, a transfer destination account identifier, a payee name, and a data field related to the amount for each transfer request, and the respective data are recorded in association with each other.
[0034]
However, the maximum number of records included in one file differs between the reception data file 230 and the transfer execution data file 240. In the present embodiment, the received data file 230 has no limit on the number of records. On the other hand, in the transfer execution data file 240, a limit is set on the number of records included in one file. In this embodiment, the maximum number of records is 10.
[0035]
In the processing result data storage unit 25, as shown in FIG. 4, a processing result data file 250 relating to the result of the transfer processing performed through the client terminals (10, 11) is recorded. This processing result data file 250 is recorded when the transfer processing result is received from the financial institution host system 30 via the client terminal (10, 11). In the present embodiment, in the processing result data file 250, fields for request number, transfer destination account identifier, recipient name, amount, payout account identifier and processing result are set for each transfer request, and the respective data are associated with each other. Recorded.
[0036]
The request number, transfer destination account identifier, recipient name, and amount included in the processing result data file 250 correspond to the request number, transfer destination account identifier, recipient name, and amount included in the reception data file 230.
[0037]
In the payout account identifier data field, data relating to an identifier for specifying the deposit account of the transfer source is recorded. In the present embodiment, the deposit account held by the company includes data relating to the financial institution code, the branch code, the deposit type code, and the account number. In the present embodiment, “yyy” and “zzz” are used as payout account identifiers.
[0038]
In the processing result data field, data relating to the result of the transfer process is recorded. In the present embodiment, when the transfer process is completed according to the transfer instruction, a “normal” flag is set in the process result data field. On the other hand, if the financial institution host system 30 cannot complete the transfer process, an “error” flag is set in the process result data field.
[0039]
Next, in the system configured as described above, a procedure when a company performs a transfer process to a deposit account designated by an employee will be described. Here, the payout account setting process, the transfer request process of the company system 40, and the transfer management process in the account management system 20 will be described in this order.
[0040]
(Payment account setting process)
First, a company opens multiple payout accounts at a financial institution. Then, client terminals (10, 11) corresponding to the payout account are installed. These client terminals (10, 11) execute a transfer process using the associated payout account. In the present embodiment, it is assumed that the company opens two deposit accounts as payout accounts. Hereinafter, the deposit account with the account identifier “yyy” is called an account “yyy”, and the deposit account with the account identifier “zzz” is called an account “zzz”. Then, the client terminal 10 is set to execute the transfer process using the account “yyy”, and the client terminal 11 is set to execute the transfer process using the account “zzz”.
[0041]
Moreover, when performing a transfer process from each payout account using a client terminal (10, 11), the upper limit is set regarding the total transfer amount per day and the total number of transfers. In the present embodiment, 2000 yen is set as the upper limit amount and 1000 cases are set as the upper limit number for the account “yyy”. For the account “zzz”, an upper limit amount of 3000 yen and an upper limit number of 700 are set.
[0042]
(Transfer request processing in the corporate system 40)
Next, processing when the company system 40 makes a transfer request to the account management system 20 will be described. For example, when an employee clears various expenses such as business trip expenses, he / she applies to the supervisor for the required expenses and receives approval. Then, the company system 40 accumulates the transfer request for which the approval process has been completed. In this case, when approvals regarding a plurality of expenses are made, a plurality of transfer processing requests are accumulated.
[0043]
Then, the enterprise system 40 collects the transfer requests at a predetermined cycle (for example, every one hour) and generates one transfer request file. Then, the company system 40 transmits the transfer request file to the account management system 20 via the network N1. Upon receiving the transfer request file, the account management system 20 records this file in the request reception data storage unit 23 as a reception data file 230.
[0044]
(Transfer management processing)
Next, the transfer management process will be described with reference to FIG. The management computer 21 executes this processing during an operation time when the financial institution host system 30 is operating.
[0045]
First, the management computer 21 confirms the file status of the request acceptance data storage unit 23 (S1-1). This process is periodically performed at a preset cycle. Specifically, the management computer 21 confirms whether or not the reception data file 230 exists in the request reception data storage unit 23. When the received data file 230 is not recorded in the request received data storage unit 23 (in the case of “No” in step (S1-2)), step (S1-1) is executed again.
[0046]
In the present embodiment, it is assumed that two received data files 230, that is, a received data file 231 and a received data file 232 are recorded in the request received data storage unit 23 as shown in FIG. As described above, when the reception data file 230 is recorded in the request reception data storage unit 23 (in the case of “Yes” in step (S1-2)), the management computer 21 determines the number of transfer requests included in one file. The (number of records) is confirmed (S1-3). In the present embodiment, the reception data file 231 includes 12 records related to the request numbers “1” to “12”. On the other hand, the reception data file 232 includes five records relating to the request numbers “13” to “17”.
[0047]
If the number of transfer requests for one file is greater than the preset number of cases (“Yes” in step (S1-4)), the management computer 21 divides the received data file 230 so that it falls within the set number of cases. (S1-5). In the present embodiment, “10” is set as the number of settings. In the present embodiment, the received data file 231 includes 12 records, which is larger than the set number (10). Therefore, the management computer 21 divides into 10 items in the order of request numbers. In this case, the received data file 231 includes a file (transfer execution data file 241 to be described later) composed of 10 records with request numbers “1” to “10” and two records “11” to “12”. Are divided into files (transfer execution data file 242 described later).
[0048]
On the other hand, when the number of transfer requests for one file is less than or equal to the preset number of cases (“No” in step (S1-4)), step (S1-5) is skipped. In this embodiment, the reception data file 232 is composed of five records and is not divided because it is smaller than the set number (10).
[0049]
Then, the management computer 21 records the received data file 230 or the divided received data file 230 as the transfer execution data file 240 in the transfer request data storage unit 24 (S1-6). When recording a file in the transfer request data storage unit 24, the management computer 21 deletes the received data file 230 recorded in the request received data storage unit 23.
[0050]
In the present embodiment, as shown in FIG. 3, the transfer request data storage unit 24 transfers the transfer execution data file 241, the transfer execution data file 242, and the reception data file 232 that are divided and generated from the reception data file 231. An execution data file 243 is recorded. As described above, each transfer execution data file 240 is recorded in the transfer request data storage unit 24, and is placed in a waiting state for the transfer process.
[0051]
The client terminals (10, 11) search the transfer request data storage unit 24 at regular time intervals after the transfer process is completed. When the transfer execution data file 240 is recorded in the transfer request data storage unit 24, the client terminal (10, 11) receives the transfer of the file (S1-7). Then, the client terminals (10, 11) perform a transfer process via the network N2. Specifically, the client terminal (10, 11) transmits a transfer instruction to the financial institution host system 30 based on the acquired transfer execution data file 240.
[0052]
The state of this transfer process will be described with reference to FIGS. FIG. 6 shows a remaining frame transition 500 of the transfer amount remaining frame and the transfer number remaining frame of the payout account “yyy”. On the other hand, FIG. 7 shows a remaining frame transition 510 of the transfer amount remaining frame and the transfer number remaining frame of the payout account “zzz”.
[0053]
As shown in FIGS. 6 and 7, the remaining frames (501, 502, 511 to 513) include a transfer amount remaining frame and a transfer number remaining frame. The transfer amount remaining frame is the remaining margin frame until the total transfer amount reaches the upper limit amount, and the transfer number remaining frame is the remaining margin frame until the total number of transfer cases reaches the upper limit number.
[0054]
First, the transition of the payout account “yyy” corresponding to the client terminal 10 will be described. As shown in the remaining frame 501 of FIG. 6, before performing the transfer process of the present embodiment, it is assumed that the remaining amount of transfer amount is 1000 yen and the remaining number of transfer cases is 500. The client terminal 10 searches the transfer request data storage unit 24 and acquires the transfer execution data file 241. Then, the client terminal 10 sequentially performs the transfer process from the request number “1” with respect to the transfer request included in the transfer execution data file 241 using the payout account “yyy”. Here, since the balance of the transfer amount of the payout account “yyy” is 1000 yen, the transfer process of 910 yen was performed at the stage where the processing of the request numbers “1” to “7” was performed. As shown in the remaining frame 502, the transfer amount remaining frame is 90 yen. Since the request number “8” is a transfer request of 170 yen, if this transfer process is performed, the upper limit amount will be exceeded.
[0055]
For this reason, even if the client terminal 10 issues a transfer instruction to the financial institution host system 30 via the network N2, the transfer process cannot be executed due to a shortage of remaining frames, and a response to that effect is sent from the financial institution host system 30. Receive. Therefore, the request numbers “8” to “10” cannot execute the transfer process and are “error”.
[0056]
Then, the client terminal 10 notifies the management computer 21 of the processing result. The management computer 21 records the processing result in the processing result data storage unit 25 (S1-8). In this case, as shown in FIG. 4, a processing result data file 251 is recorded in the processing result data storage unit 25. Since this transfer process is performed by the client terminal 10, “yyy” corresponding to the client terminal 10 is recorded as a payout account identifier.
[0057]
Next, processing of the payout account “zzz” corresponding to the client terminal 11 will be described. Here, it is assumed that the client terminal 11 searches the transfer request data storage unit 24 after the client terminal 10 acquires the transfer execution data file 241. In this case, the transfer execution data file 242 and the transfer execution data file 243 remain in the transfer request data storage unit 24. Therefore, the client terminal 11 acquires the transfer execution data file 242 and performs a transfer process.
[0058]
Here, as shown in the remaining frame 511 in FIG. 7, before the transfer process, the transfer amount remaining frame of the payout account “zzz” is 2500 yen, and the remaining number of transfers is 6. When the client terminal 11 that processes the payout account “zzz” acquires the transfer execution data file 242 from the transfer request data storage unit 24, the processing is sequentially performed from the request number “11”. Here, after the transfer process included in the transfer execution data file 242 is executed, the transfer amount remaining frame of the payout account “zzz” is 2090 yen as shown in the remaining frame 512, and the transfer number remaining frame is 4 cases.
[0059]
Then, the client terminal 11 notifies the management computer 21 of the processing result. The management computer 21 records the processing result in the processing result data storage unit 25 (S1-8). In this case, as shown in FIG. 4, a processing result data file 252 is recorded in the processing result data storage unit 25. Since this transfer process is performed by the client terminal 11, “zzz” corresponding to the client terminal 11 is recorded as a payout account identifier.
[0060]
Further, the client terminal 11 searches the transfer request data storage unit 24. Here, it is assumed that the client terminal 10 has not completed the processing of the transfer execution data file 241 and the transfer execution data file 243 still remains in the transfer request data storage unit 24. Therefore, the client terminal 11 acquires the transfer execution data file 243 and performs a transfer process.
[0061]
At this stage, as shown in the remaining frame 512, before the transfer process is performed, the transfer amount remaining frame is 2090 yen, and the number of transfer number remaining frames is 4. When the client terminal 11 executes the transfer processing of the transfer execution data file 243, the processing is sequentially performed from the request number “13”. Here, since the remaining number of deposits for the payout account “yyy” is four, the number of deposits remaining as shown in the remaining frame 513 at the stage of processing the request numbers “13” to “16” is as follows. 0. Therefore, the transfer process relating to the request number “17” cannot be executed, resulting in an “error”.
[0062]
Then, the client terminal 11 notifies the management computer 21 of the processing result. The management computer 21 records the processing result in the processing result data storage unit 25 (S1-8). In this case, as shown in FIG. 4, the processing result data file 253 is recorded in the processing result data storage unit 25. Since this transfer process is performed by the client terminal 11, “zzz” corresponding to the client terminal 11 is recorded as a payout account identifier. Thus, the transfer management process is completed.
[0063]
The enterprise system 40 periodically collects the processing result data file 250 recorded in the processing result data storage unit 25. If the transfer process has not been completed (transfer request with an “error” flag added), the transfer process is instructed again.
[0064]
As described above, according to the present embodiment, the following effects can be obtained.
In the above-described embodiment, when the number of transfer requests for one file is greater than the preset number of settings, the management computer 21 divides the file by the set number and generates the transfer execution data file 240. For this reason, the client terminal (10, 11) can suppress the transfer process executed at a time to a predetermined number or less. Therefore, even when transfer requests including a large number of transfer requests are sent from the enterprise system 40 at once, the transfer processing can be distributed and the overload of specific client terminals (10, 11) can be prevented. In particular, in this embodiment, the load distribution of the client terminals (10, 11) can be achieved by a simple process of dividing a file.
[0065]
In the above embodiment, the client terminal (10, 11) performs the transfer process using the transfer execution data file 240 including a plurality of transfer requests. For this reason, the client terminal (10, 11) can efficiently perform a plurality of transfer processes using the transfer execution data file 240 acquired from the transfer request data storage unit 24.
[0066]
In the above embodiment, after completing the transfer process, the client terminal (10, 11) periodically acquires the transfer execution data file 240 from the transfer request data storage unit 24 in the transfer request data storage unit 24, Execute the transfer process. For this reason, except for the client terminals (10, 11) that have not completed the transfer process, the client terminals (10, 11) that have completed the transfer process sequentially perform the transfer process. Therefore, the client terminals (10, 11) can be used efficiently.
[0067]
In the above embodiment, the company opens a plurality of payout accounts in a financial institution and installs client terminals (10, 11) corresponding to the payout accounts. These client terminals (10, 11) execute a transfer process using the associated payout account. When the number of transfer requests is large, it takes time to transfer money from one payout account, and it may not be completed within a predetermined period (within the operation period of the financial institution host system 30). By providing a plurality of client terminals (10, 11) corresponding to a plurality of payout accounts, for example, it is possible to cope with a transfer process with a small amount of money but a very large number of cases, such as a travel expense clearing process. Can do.
[0068]
In the above embodiment, the processing result data storage unit 25 records the processing result data file 250 related to the result of the transfer processing performed via the client terminal 10 and the client terminal 11. In the processing result data file 250, a request number, a transfer destination account identifier, a payee name, an amount, a payout account identifier, and a field related to a processing result are set for each transfer request, and each data is recorded in association with each other. For this reason, the enterprise system 40 can grasp the result of each transfer processing request.
[0069]
In addition, you may change the said embodiment into the following aspects.
In the above embodiment, the company opens two deposit accounts (account “yyy” and account “zzz”) as payout accounts. Many more payout accounts may be provided. In that case, a corresponding number of client terminals (10, 11) are provided. In the above embodiment, since the management computer 21 only records the transfer execution data file 240 divided into the predetermined number based on the received data file 230 in the transfer request data storage unit 24, the management computer 21 stores the transfer execution data file 240. Can easily cope with changing number.
[0070]
In the above embodiment, a description will be given of a transfer processing method and a transfer processing program used when a company that holds a deposit account in a financial institution pays various expenses by performing a transfer process on an employee's deposit account. If the payer uses the transfer service and pays by transferring to a plurality of accounts, it is applicable regardless of the company as the payer and the employee as the payee.
[0071]
In the above embodiment, when the number of transfer requests for one file is greater than the preset number of cases, the management computer 21 divides the received data file 230 so that it falls within the set number. “10” is set as the setting number. Instead, it may be divided by other numbers. This number is determined in consideration of the number of client terminals (10, 11) and the time required for the transfer process.
[0072]
In the above embodiment, the company system 40 generates a single transfer request file by collecting transfer requests at a predetermined cycle. Then, the company system 40 transmits the transfer request file to the account management system 20 via the network N1. And the account management system 20 which received the transfer request file records this file in the request reception data storage part 23 as the reception data file 230. FIG. Instead, a transfer request file brought in from a company in a recording medium such as an MT format may be recorded in the request reception data storage unit 23 as a reception data file 230.
[0073]
In the above embodiment, the client terminal (10, 11) notifies the management computer 21 of the processing result. The management computer 21 records the processing result in the processing result data storage unit 25. Instead, the client terminal (10, 11) may directly record the processing result in the processing result data storage unit 25.
[0074]
【The invention's effect】
As described above in detail, according to the present invention, a transfer process can be efficiently performed using a plurality of payout accounts.
[Brief description of the drawings]
FIG. 1 is a system schematic diagram of an embodiment of the present invention.
FIG. 2 is an explanatory diagram of data recorded in a request acceptance data storage unit.
FIG. 3 is an explanatory diagram of data recorded in a transfer request data storage unit.
FIG. 4 is an explanatory diagram of data recorded in a processing result data storage unit.
FIG. 5 is an explanatory diagram of a processing procedure according to the embodiment of this invention.
FIG. 6 is an explanatory diagram of account balance transition.
FIG. 7 is an explanatory diagram of account balance transition.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 10,11 ... Client terminal as a transfer processing terminal, 20 ... Account management system, 21 ... Management computer, 23 ... Request reception data storage part as request reception data storage means, 230, 231, 232 ... Reception data file, 24 ... Transfer request data storage unit as a transfer request data storage unit, 240, 241, 242, 243 ... Transfer execution data file, 25 ... Processing result data storage unit as a processing result data storage unit, 40 ... Enterprise system as a payment management system .

Claims

Each transfer processing terminal that is allocated to each of a plurality of payout accounts and connects to a financial institution host system to execute a transfer process, a company system that collects transfer requests at a predetermined cycle and generates one transfer request file, and the company system Request acceptance data storage means for recording the transfer request file received from the transfer request data storage means, transfer request data storage means for recording the transfer execution data file for performing the transfer processing of the transfer request, and transfer processing for each transfer request A method for performing a transfer process using an account management system having a processing result data storage means for recording results and a management computer connected to each means,
The management computer extracts the reception data file recorded in the request reception data storage means, and grasps the number of transfer requests included in the reception data file;
When said number of said transfer request included in the reception data file exceeds a predetermined number, the management computer, separate the remittance included in the reception data file for each of the predetermined number, the transfer execution divided per the delimiter When the data file is generated and the number of transfer requests included in the received data file does not exceed the predetermined number, this division process is skipped,
Recording the transfer execution data file in the transfer request data storage unit and deleting the received data file recorded in the request received data means;
A plurality of vibration write processing terminal sequentially performs a search of the transfer request data storage means at intervals of a predetermined time, when the transfer action data file is recorded in the transfer request data storage means, the transfer processing terminal that file In response to the transfer request, with respect to the transfer request included in the transfer execution data file, using the payout account associated with each transfer processing terminal, sequentially performing a transfer process to the financial institution host system;
When the transfer request in the transfer execution data file is received from the financial institution host system that the transfer process could not be executed as a transfer process result , the transfer processing terminal responds to the transfer request with an "error" ”Flagged processing result data file is recorded in the processing result data storage means as the transfer processing result,
The enterprise system periodically collects the processing result data file recorded in the processing result data storage means, and instructs the transfer processing again for the transfer request with the “error” flag added thereto. Transfer processing method.