【文献】
松本康幸,"迫る 電子記録債権の時代〜「でんさいネット」、全国規模の新社会インフラ",月刊金融ジャーナル,金融ジャーナル社,2011年 5月 1日,第52巻,第5号,pp.16-19
【文献】
森俊二,"迫る 電子記録債権の時代〜<みずほ>における電子記録債権への取り組みと今後の展開",月刊金融ジャーナル,金融ジャーナル社,2011年 5月 1日,第52巻,第5号,pp.28-31
(58)【調査した分野】(Int.Cl.,DB名)
前記第1の電子記録債権の発生記録請求は、CSV、TXT、またはXMLの形式のファイルであって、1以上の整数であるN件分の前記発生記録請求に係わる情報を、1つのファイルに指定した発生記録請求ファイルであって、
前記分割部は、前記受信した発生記録請求ファイルを解析し、前記発生記録請求ファイルに含まれる前記N件分の発生記録請求に係わる情報から、1件ずつ前記発生記録請求に係わる情報を抽出することにより、N個のファイルに分割する
ことを特徴とする請求項1のシステム。
【背景技術】
【0002】
企業間取引の決済手段として、しばしば手形が用いられる。手形決済では、手形を振り出した債務者は、支払期日までに所定の口座に資金を入金すればよく、一方、債権者は、支払期日以降に手形を取引先の金融機関(以下、「取引銀行」という。)に持ち込むことで資金の支払を受けることができる。
【0003】
ところで、平成20年12月1日に電子記録債権法が施行され、従来の紙ベースの手形や売掛債権に代わる新たな決済手段として、電子記録債権(以下、「電子債権」という)が導入された。電子債権によると、利用者は取引銀行を通じて、全国銀行協会によって設立された電子債権記録機関である全銀電子債権ネットワーク(以下、「でんさいネット(登録商標)」という)の記録原簿に電子的な記録を行うことで、債権の発生や譲渡、支払などの手続きを行うことができる。例えば、債務者が、発生させる電子債権の債権金額、支払期日、債権者などを指定し、自身の取引銀行を通じて発生記録請求を行うと、でんさいネットの記録原簿に電子債権の「発生記録」が記録される。これにより、電子債権が発生し、支払期日になると、指定した債権金額が支払企業の口座から自動的に引き落されて、債権者である受取企業の口座に自動的に入金されることとなる。
【0004】
電子債権の発生方法は、「債務者請求方式」が基本であるが、でんさいネットにおいては、債権者が債務者を特定した上で発生記録請求を行う、いわゆる、「債権者請求方式」を行うことができる。「債権者請求方式」の場合は、債権者が口座情報などで債務者を特定し、取引銀行を通じて、でんさいネットに対し、債権の発生記録請求を行う。でんさいネットは発生記録請求を受けると、債権者の請求内容を、取引銀行を通じて債務者に通知をする。通知を受けた債務者は、その内容を確認し、内容に問題がない場合は、通知日を含め5営業日以内に承諾をすることにより、発生記録が成立する。
【0005】
取引銀行によっては、振込による支払人の特定を、振込専用の口座番号で行うことが可能な振込処理管理サービスを提供する(特許文献1参照)。振込処理管理サービスにおいては、債務者と関連づけた口座(以下、「決済口座」という。)を債務者ごとに用意し、決済口座に振り込まれた資金を、受取人の取りまとめを行う口座(以下、「入金指定口座」という。)に入金することが可能となる。入金指定口座に入金された際には、債務者に対応する決済口座の口座番号が入金明細に記録されるため、債務者を即座に特定することができ、入金照合作業を効率化することが可能となる。
【発明を実施するための形態】
【0013】
以下、図面を参照しながら本発明の実施形態について詳細に説明する。
【0014】
図1は、本発明に係る全体的なシステム環境を示すブロック図である。
図1の例において、債権者端末1は、送受信部101と、データ作成部102と、債権管理DB103を備える。
【0015】
債権管理DB103は、債務者、金額、期限、決済口座など、所有する個々の債権に関する情報を管理するデーターベースである。債権管理DB103において、保有する決済口座を各債務者に対応付けて管理しておくことにより、決済口座に振込があった際に、債務者からの送金を容易に確認することが可能となる。
【0016】
データ作成部102は、でんさいネット標準フォーマットに準拠した、TXT、CSV、XMLなどの形式の、発生記録請求ファイルを作成する機能を有する。作成される発生記録請求ファイルのヘッダーレコードには、債権者が保有する決済口座を指定して、1つの発生記録請求ファイルに複数ヘッダーレコードを指定することができる。データ作成部102は、債権管理DB103から所定の情報を自動的に抽出して、自動化された手段でファイルを作成する機能を有していてもよい。
【0017】
送受信部101は、銀行システム2の送受信部201に対し、作成された発生記録請求ファイルを、ネットワーク経由で送信する。
【0018】
銀行システム2は、でんさいネット3の利用者の取引銀行のシステムであり、でんさいネット連携システム(DRS)20、送受信部201、ファイル分割部202、でんさい顧客管理DB203、振込処理管理DB204を備える。
【0019】
DRS20は、でんさいネット3と連携する機能を有するシステムであり、でんさいネットにおける電子債権情報を管理する。DRS20は、でんさいネット3と債権者端末1との間に位置し、でんさいネット3および債権者端末1とネットワークを介して接続される。でんさいネット3は、上記した電子債権記録機関であり、利用者は、DRS20を通じて、でんさいネット3が提供するサービスを利用することができる。DRS20は、例えば、債権者端末1から電子債権に関する記録請求(例えば、発生記録請求など)を受信し、受信した当該記録請求をでんさいネット3に送信する。これにより、電子債権の発生などがでんさいネット3の記録原簿304に記録される。
【0020】
送受信部201は、債権者端末1から、発生記録請求を受信する。また、送受信部201は、後述するファイル分割部により分割された複数の発生記録請求を、でんさいネット3に送信する。
【0021】
ファイル分割部202は、受信した発生記録請求ファイルを解析し、発生記録請求ファイルに含まれる決済口座N個分の発生記録請求に係わる情報から、決済口座1つ分の発生記録請求に係わる情報を抽出することにより、N個のファイルに分割する。後述するように、でんさいネット3は、決済口座は1つを含める形態しか対応していない。したがって、このファイル分割部202の機能により、債権者は1つのファイルに、複数ヘッダーレコードを指定して、複数件分決済口座に関わる発生記録請求を指定して送ることができるようになる。
【0022】
DRS20は、銀行システム2を通じてでんさいネット3を利用する企業についての、企業名、口座情報などの一般的な情報、および、電子債権情報を格納するでんさい顧客管理DB203を有する。でんさい顧客管理DB203は、銀行システム2を通じて記録原簿への記録が行われた電子債権に関する各種情報、例えば、各電子債権の記録番号、債権金額、支払期日、債権者および原債務者の情報(例えば、名前、決済口座など)、などを格納する。
【0023】
振込処理管理DB204は、債務者を識別する情報、債務者に関連づけられた決済口座の情報、および当該決済口座に対応付けられる入金指定口座の情報などを保有するデーターベースで構成される。
【0024】
でんさいネット3は、記録受付部301と、通知送受信部302と、記録原簿登録部303と、記録原簿DB304を備える。
【0025】
記録受付部301は、DRS20の送受信部201から送信される、電子債権に関する発生記録請求と、発生記録請求ファイルを受信する。
【0026】
通知送受信部302は、記録受付部301から発生記録請求の受信の通知を受けると、受信した発生記録請求および発生記録請求ファイルに基づき、債権者の請求内容を、債務者の取引銀行5を通じて債務者に通知を行う。また、通知送受信部302は、通知を受けた債務者が、内容を確認し承諾を行う旨の通知を、債務者の取引銀行5を通じて受信する。さらに、債務者が承諾した旨の通知を、DRS20の送受信部201に対して送信する。
【0027】
記録原簿登録部303は、債務者による承諾を行う旨の通知に基づき、記録原簿DB304に、債権に関する情報を登録する。
【0028】
記録原簿DB304は、発生記録、譲渡記録、支払等記録などの記録を格納するものであり、発生記録においては、債権金額、支払期日、債権者・債務者などの情報を格納する。
【0029】
債務者端末4は、送受信部401などによって構成され、送受信部401は、債権者による発生記録請求がなされたことの通知を受信し、また、当該発生記録の承諾を行う旨の通知を送信する。
【0030】
なお、本実施形態の債権者端末1および債務者端末4、銀行システム2およびDRS20を構成する各種サーバーはプロセッサ、メモリなどを備えた通常のコンピューターであって、ネットワークに接続するための機能のほか、必要に応じて記憶装置や、LCDなどの表示装置、あるいはキーボード、マウス、音声入力装置などの入力機器を備える。これに限られず、本技術分野で知られた様々なハードウェアを内蔵あるいは接続することができる。また、顧客(債権者)端末1および債務者端末4や各種サーバーには、OSや様々なドライバーまたはアプリケーションがインストールされ、本発明における実施形態で後述する様々の処理を全体として実行する。
【0031】
図2は、でんさいネット標準フォーマットに準拠した発生記録請求ファイルのデータ構造を示す図である。
【0032】
発生記録請求ファイルは、請求者(債権者)の利用者番号、請求者名、取引銀行番号、取引銀行名、取引支店番号、取引支店名、決済口座の口座番号などを指定するヘッダーレコード1021と、取引相手(債務者)の利用者番号、取引銀行番号、取引銀行名、取引支店番号、取引支店名、債務者口座の口座番号などを指定する1つまたは複数のデータレコード1022と、データレコード1022の件数などを指定するトレーラレコード1023と、エンドレコード1024から構成される。
【0033】
上述したように、振込処理管理サービスを利用する大企業においては、振込処理管理サービスを利用して、複数の債務者と関連づけた複数の決済口座を利用する利用形態を採用していることも多い。振込処理管理サービスを利用して、債権者に帰属するが債務者ごとに割り当ててられる決済口座を用いて発生記録請求を行う場合、ヘッダーレコード1021に債権者の口座番号として決済口座を指定する必要がある。
【0034】
でんさいネット3の仕様上の理由から、ヘッダーレコード1021において、請求者(債権者)の口座を複数指定することはできない。また、1つのファイルに複数のヘッダーレコード1021を含めることはできない。したがって、原則、1ファイルにつき、請求者(債権者)の1つの口座を指定することが求められる。
【0035】
したがって、従来は、例えば、でんさいネット3に対して、N人の債務者に対する、N回分の発生記録請求を行う際には、N個ファイルを作成し、N回ファイルを取引銀行に送信させなければならなかった。もしくは、1のファイルで発生記録請求を複数件分一括請求する場合は、データレコード1022を請求する件数分指定し、トレーラレコード1023に件数および合計金額を設定していた。すなわち、N件分の発生記録請求を行う際には、データレコード1022にN件分の情報を指定して、トレーラレコード1023にN件とその合計債権金額を指定することにより行っていた。
【0036】
しかしながら、上記いずれの方式も、債務者と関連づけられ、債権者に帰属する決済口座を指定して発生記録請求を行う利用形態において、ヘッダーレコード1021に決済口座を指定して、N件分の決済口座に係わる発生記録請求を1のファイルで送信することを許容しない。
【0037】
そこで、本発明においては、債権者が、ヘッダーレコード1021に決済口座を指定した、複数の決済口座に係わるN件分の発生記録請求を、1のファイルにまとめることを可能にすべく、以下の方法を採用する。また、債権者が、データレコード1022にN件分の債務者情報を指定して1のファイルでN件分の発生記録請求を行った際にも、適宜ファイルを分割させ、ヘッダーレコード1021に対応する決済口座を指定して、N件分の発生記録請求をでんさいネット3に対して行い得るよう構成する。
【0038】
図3は、本発明の一実施形態に係るファイル分割イメージを示す図である。債権者は、債権者端末1を通じて、DRS20に対して発生記録請求を行う際に、N件(Nは2以上の整数)分の発生記録請求を1つのファイル1120にまとめて指定する。この発生記録請求ファイル1120には、ヘッダーレコード1021、データレコード1022、トレーラレコード1023を、1つの発生記録請求の単位(以下、「1単位」という。)として指定する。例えば、N件分の発生記録請求を指定する場合は、いわゆる、1ファイル中にヘッダーレコード1021が複数存在するマルチヘッダー形式で、1単位がN個、1つのファイル中に含まれる。発生記録請求ファイル1120は、TXTおよびCSVや、取引銀行が対応する場合は、XMLなどの形式で作成される。
【0039】
債権者端末1から、N件分の発生記録請求情報が1つのファイルに指定された発生記録請求ファイル1120が銀行システム2に送信される。DRS20は、ファイルを受信すると、内容を解析して、1つの発生記録請求ファイル1120を個別(N件分)のシングルヘッダーファイルの状態に分割させる。ファイル分割部202は、ファイル中の1単位を識別し、1単位ずつ抽出して、エンドレコード1024を付加した上で、1ファイル1121として保存する。すなわち、受信した1ファイル1120を複数のファイル1121に分割し、図示しないメモリまたはバッファなどに保存する処理を行う。上記の例においては、ファイル分割部202は、N個のファイルを作成し保存する。DRS20は、分割されたN個分の発生記録請求ファイル1121をでんさいネット3に対して送信する。
【0040】
なお、データレコード1022を件数分繰り返し、トレーラレコード1023に件数および合計金額を設定する、発生記録請求を一括して行う方式に対応させてもよい。
図4は、本発明の一実施形態に係る、複数件分データレコードを指定した発生記録請求ファイルのファイル分割イメージを示す図である。本実施の形態の前提として、でんさい顧客管理DB203および振込処理管理システムDB204には、債務者(および/または債権情報)と発生記録請求時に利用する決済口座とを紐づけた情報が予め格納されているものとする。債権者端末1から、シングルヘッダー(マルチデータレコード)形式で、発生記録請求ファイルがDRS20に送信される。この際、データレコード1022において、債務者の決済口座を指定しておいてもよいし、データレコード1022に含まれる情報から決済口座を判別する構成としてもよい。
【0041】
DRS20は、N件分のデータレコード1022に含まれる情報(例えば、債権金額、取引相手_利用者番号、取引相手_口座番号など)から、でんさい顧客管理DB203および振込処理管理システムDB204を参照して、各データレコード1022に対応する指定すべき決済口座を判別する。
【0042】
ファイル分割部202は、N件分のデータレコード1022に対応するようにファイル分割させる。
【0043】
ファイル分割部202は、分割させた各ファイル中のヘッダーレコード1021に上記処理で判別した決済口座を指定する。
【0044】
ファイル分割部202は、トレーラレコード1023も1件ごとの情報に書き換えて、分割させた各ファイル中に追加する。
【0045】
ファイル分割部202は、各ファイルにエンドレコード1024を付与して、分割させた発生記録請求ファイルを送受信部201を介してでんさいネット3に送信する。
【0046】
なお、債権者が、データレコード1022に、予め債務者の決済口座を指定して一括請求した場合、ファイル分割部202は、データレコード1022に指定された当該決済口座を、分割した各ファイルのヘッダーレコード1021の口座番号として指定しなおした上で、でんさいネット3に送信させてもよい。
【0047】
図5は、本発明の一実施形態に係る処理を説明するフローチャートである。当該処理の前提として、債権者は、振込処理管理サービスにおける決済口座を保有し、各決済口座が各債務者に対して、割り当ておよび対応付けられているものとする。
【0048】
債権者は、債権者端末1を通じて、取引銀行のDRS20のログイン情報を入力し、DRS20にアクセスすると処理が開始する。ログイン情報には、例えばパスワードなどが含まれる。DRS20は、ログイン情報に基づいて、利用者(債権者)の利用者番号および利用者の名前などを特定して利用者の認証処理を行うと、債権者端末1にでんさいネットのメニュー画面情報を送信する。メニュー画面情報には、でんさいネットにおいて実行可能な取引項目(例えば、発生記録請求、譲渡(分割)記録請求、割引依頼など)が含まれ、ステップS801において、利用者は、端末1に表示されるメニュー画面から発生記録請求の取引項目を選択する。
【0049】
DRS20は、ステップS802において、債権者端末1から発生記録請求の画面の要求を受け、各種指定が可能な画面を債権者端末1に提示するとともに、ファイルをアップロードするための画面を債権者端末1に送信する。
【0050】
ステップS803において、利用者(債権者)が、債権者端末1において作成済のファイルを選択し、でんさいネット3への送信を承諾すると、債権者端末1は、送受信部101を介して、発生記録請求ファイルをアップロードする。なお、この際アップロードされる発生記録請求ファイルは、上述のとおり、1つの発生記録請求ファイルに、複数の発生記録請求に係る情報(債権者、債務者、金額、前記債務者に割り当てられた決済口座など)が指定される、マルチヘッダー形式で作成されたファイルである。
【0051】
DRS20の送受信部201は債権者端末1から発生記録請求ファイルを受信すると、受信した発生記録請求ファイルを、ファイル分割部202に渡す。
【0052】
ステップS804において、ファイル分割部202は、発生記録請求ファイルを解析し、シングルヘッダーのファイル形式に分割する。ファイル分割部202は、ヘッダーレコード1021、データレコード1022、トレーラレコード1023を、1つの発生記録請求の単位として識別する。その後、識別した1つの発生記録請求の単位ごとに、前記発生記録請求ファイルから抽出し、それぞれを1ファイルとして分割するとともに、エンドレコード1024を各ファイルに付与する。
【0053】
ステップS805において、DRS20の送受信部201は、分割された1ファイルずつを、でんさいネット3に続けて送信する。
【0054】
でんさいネット3の記録受付部301は、発生記録請求ファイルを受信すると、ステップS806において、該当する債務者に発生記録請求の通知を行う。債務者端末4における送受信部401を介して、発生記録請求がなされたことの通知を受領すると、ステップS807において、債務者は、発生記録請求を承諾するか決定する。
【0055】
債務者が承諾する旨を、送受信部401を介してでんさいネット3に対して通知を行うと、でんさいネット3の通知送受信部302が通知を受信し、その後、ステップS808において、発生予定日にでんさい(登録商標)が発生するとともに、当該でんさいの発生記録が記録原簿DB304に登録される。
【0056】
ステップS809において、その後、支払期日が到来すると、取引銀行5にある債務者の口座から当該債務者に対応付けられた決済口座に、指定された金額の口座間送金決済が行われる。当該決済口座は、上述したように債権者が保有する口座である。そして、ステップS810において、指定された金額が決済口座宛に振り込まれる。決済口座に対する振込が行われると、ステップS811において、入金指定口座に入金が行われる。ステップS812において、銀行システム2によって入金指定口座の入出金明細に決済口座の口座番号が記録される。債権者は、決済口座の口座番号の記録により、債権管理DB103等を参照して、売掛金、買掛金の消込を容易に行うことができる。
【0057】
一方、ステップS807において、債務者が債務者端末4を介して、発生記録請求の承諾を拒否すると、拒否通知はステップS813において、債務者の取引銀行5経由で、でんさいネット3に送信される。ステップS814において拒否通知がでんさいネット3から、債権者の取引銀行2に送信され、債権者に通知される。
【0058】
なお、本実施形態においては、発生記録請求ファイルを予め、債権者端末1で作成することを前提として記載したが、DRS20が提示する画面に必要事項を入力することにより、作成してもよい。すなわち、DRS20が提示する画面において、債権者、債務者等の情報を指定することにより、発生記録請求ファイルを作成してもよい。
【0059】
以上説明したように、本発明によれば、でんさいネット3に対して、1の発生記録請求で複数件分の発生記録請求を行うことが可能となり、債権者における作業の効率性および利便性を高めるとともに、通信コストも削減することが可能になる。なお、本発明は、銀行システム2などのコンピュータシステムにおいて実装することができ、あるいはまた各情報処理をコンピューターに実行させるプログラムとしても実装することができる。