以下、図面に基き、本発明の最良の実施の形態を説明する。なお、本実施形態に係る公金収納管理システムは、本発明に係る公金収納管理システムを構成し、本実施形態に係る公金収納管理システムが行う動作は、本発明に係る公金収納管理方法の実施の形態を構成し、本実施形態に係る公金収納管理システムに搭載されているプログラムは、本発明に係る公金収納管理システム用プログラムの実施の形態を構成する。
図1に示すように、本実施形態に係る公金収納管理システム(以下単に「システム」という)10は、例えば自治体の公金収納業務を代行するために設立された機関である公金収納管理センター(以下単に「センター」という)に備えられている。このシステム10は、銀行や郵便局の窓口、コンビニエンスストア、インターネットバンキング及びクレジットカードのWEB収納サイト等の、複数の公金取扱機関を介しての公金収納に対応可能なものである。
システム10は、コンピュータで構成され、CPU等の中央処理装置11、外部から情報を入力するためのキーボード等の入力装置12、外部へ情報を出力するためのディスプレイやプリンタ等の出力装置13、外部機器との情報通信を管理するための通信装置14、及び、各種プログラムやデータを記録するためのメインメモリやROM、RAM等の記録装置15等が、バスを介して相互に接続されている。
記録装置15は、プログラムが記録されるプログラム記録部15aと、データが記録されるデータ記録部15bとを有し、データ記録部15bには、基本情報DB(データベース:以下同じ)、納付情報DB、及び資金化日DBが格納されている。
システム10は、例えば専用のコンピュータネットワーク31を介して、自治体の通信サーバ22ないし基幹システム21と相互に情報通信可能に接続されている。同様に、システム10は、コンピュータネットワーク32〜35を介して、自治体指定金融機関、コンビニエンスストア収納代行会社、MPN(マルチペイメントネットワーク)収納センター、及びクレジット収納センターと相互に情報通信可能に接続されている。
次に、図2〜図4を参照して各DBの構造を説明する。なお、以下の図2〜図4、図14、及び図16〜図27において、基本的に、具体例を示した欄以外の「(空欄)」は未入力欄(現在はデータが入力されていないが将来データが入力される欄)であることを示し、「−」は非入力欄(将来もデータが入力されない欄)であることを示し、「---」は何等かの種々様々なデータが入力されている欄であることを示す。
まず、基本情報DB(基本情報記録手段を構成する)は、公金の収納に必要な基礎的データを登録しておくもので、図2に示すように、自治体側で案件毎に付与された納付書コード(符号ア:以下、異なる図面で同じ符号が付されているデータ同士が相互に対応していることを示す)をキーとして、自治体コード(符号イ)、納付科目、センター側で案件毎に乱数を用いて採番した納付番号(符号ウ)、コンビニ収納キー(公金取扱機関がコンビニエンスストアのときにキーとなるバーコード情報で、少なくとも前記納付番号を包含したもの(換言すれば、前記納付番号を含んでさえいれば、該納付番号のみからなるものでもよいし、他の情報、例えば納付金額や自治体名等の付加的情報を含むものでもよい)である:符号エ)、窓口収納キー(公金取扱機関が金融機関の窓口のときにキーとなるOCR(optical character reader:光学式文字読取装置)情報で、少なくとも前記納付番号を包含したもの(換言すれば、前記納付番号を含んでさえいれば、該納付番号のみからなるものでもよいし、他の情報、例えば納付金額や自治体名等の付加的情報を含むものでもよい)である:符号オ)、納付金額、及び納付期限といった基礎的データの他、納付者氏名(カナ、漢字)、住所、生年月日、性別、個人番号、及び世帯コードといった納付者個人に関する情報が、検索可能に体系的に登録されている。なお、この図2に示した具体例は、後述する図41及び図42に記載した例を採用したものであるが、本実施形態を限定するものではない。
また、納付情報DB(納付情報記録手段を構成する)は、各案件につき公金の納付状況に関するデータを登録しておくもので、図3に示すように、納付番号(符号ウ)をキーとして、コンビニ収納キー(符号エ)、窓口収納キー(符号オ)、納付金額(符号カ)、納付手続日(符号キ)、状況区分(符号ク)、収納チャンネル(符号ケ)、収納会社(符号コ)、手続情報受信日(符号サ)、確認情報受信日(符号シ)、及び資金化日(符号ス)といった各種の情報が、検索可能に体系的に登録されている。なお、この図3に示した具体例は、後述する図41及び図42並びに図6に記載した例を採用したものであるが、本実施形態を限定するものではない。
一方、資金化日DB(資金化日記録手段を構成する)は、金融機関やコンビニエンスストアあるいはクレジット会社等の各公金取扱機関毎に、納付者による納付手続があってから(納付手続日)、その納付した資金がいつ自治体の口座に入金されるか(資金化日)に関するデータを予め登録しておくもので、図4に示すように、収納会社(符号コ)をキーとして、収納チャンネル(符号ケ)、自治体コード(符号イ)、納付科目、資金化日タイプ、納付手続日後日数、速報通知日後日数、納付手続日範囲(開始)、納付手続日範囲(終了)、及び資金化日といった各種の情報が、検索可能に体系的に登録されている。
ここで、図4に例示した資金化日DBの登録内容の意味を説明する。まず、A銀行は、自治体指定金融機関であり、A銀行の窓口で直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、納付済通(図8、図9参照)のデータ化時に指定されることが登録されている。例えば、図5に示すように、A銀行の窓口に公金が5月20日に納められたとすると(納付手続日)、翌日の5月21日にその資金が自治体の口座に入金される(資金化日)。そして、この5月21日という情報が納付済通のデータ化時に指定されるのである。また、図6に示すように、A銀行の窓口に公金が5月30日に納められたとすると(納付手続日)、翌日の5月31日にその資金が自治体の口座に入金される(資金化日)。そして、この5月31日という情報が納付済通のデータ化時に指定されるのである。
次に、B銀行は、非指定金融機関であり、B銀行の窓口で直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、納付手続日の2営業日後であることが登録されている。例えば、図5に示すように、B銀行の窓口に公金が5月20日に納められたとすると(納付手続日)、2日後の5月22日にその資金が自治体の口座に入金される(資金化日)。また、図6に示すように、B銀行の窓口に公金が5月29日に納められたとすると(納付手続日)、2日後の5月31日にその資金が自治体の口座に入金される(資金化日)。
次に、コンビニエンスストアであるCコンビニで直接公金の納付手続をすると、その資金が自治体の口座に入金される資金化日は、予め月間スケジュールによって決まっていることが登録されている。例えば、図5に示すように、Cコンビニに公金が5月20日に納められたとすると(納付手続日)、5月20日は5月15日から5月25日までの範囲内にあるから、5月31日にその資金が自治体の口座に入金される(資金化日)。図4には、納付手続日が2007年5月15日から2007年5月25日までの範囲内にあるとき、資金化日が2007年5月31日になることのみ示したが、納付手続日がこれ以外の範囲内にあるときについても併せて登録されている。なお、図5及び図6に記されている「速報通知日」及び「確報通知日」の意味は後ほど明らかになるであろう(図10、図11、図19、図21参照)。
次に、D銀行は、納付者が口座を有する金融機関であり、WEB収納サイトを介してインターネットバンキングで電子納付手続をすると、その資金が自治体の口座に入金される資金化日は、速報通知日の3営業日後であることが登録されている。例えば、図5に示すように、インターネットバンキングにより、D銀行の納付者の口座から資金を引き落とす手続が5月20日にとられたとすると(納付手続日)、3日後の5月23日にその引き落とされた資金が自治体の口座に入金される(資金化日)。また、図6に示すように、インターネットバンキングにより、D銀行の納付者の口座から資金を引き落とす手続が5月28日にとられたとすると(納付手続日)、3日後の5月31日にその引き落とされた資金が自治体の口座に入金される(資金化日)。
次に、Eクレジットは、納付者がカード契約を交わしているクレジット会社であり、WEB収納サイトを介してクレジットカードで電子納付手続をすると、それに応じた資金が自治体の口座に入金される資金化日は、速報通知日の3営業日後であることが登録されている。例えば、図5に示すように、クレジットカードにより、公金の納付手続が5月20日にとられたとすると(納付手続日)、3日後の5月23日にそれに応じた資金が自治体の口座に入金される(資金化日)。また、図6に示すように、クレジットカードにより、公金の納付手続が5月28日にとられたとすると(納付手続日)、3日後の5月31日にそれに応じた資金が自治体の口座に入金される(資金化日)。
なお、図5は、公金の納付手続がすべて同じ日(5/20)にとられた場合でも、公金取扱機関が異なると資金化日が異なる例を示すものである。これに対し、図6は、公金の納付手続が異なる日にとられた場合に、資金化日が同じ日(5/31)に揃う例を示している。
次に、システム10が行う動作を含め、センター(ひいてはシステム10)による公金収納管理業務を各公金取扱機関毎に説明する。まず、図7を参照して、納付通知書の作成動作を説明する。図7に符号(1)で示すように、自治体の側からセンターへ基本情報がネットワーク31を介して送信される。
この基本情報は、図14に示すように、自治体の側で付与された納付書コード(符号ア)をキーとして、納付科目、納付金額、納付期限、納付者氏名(カナ)、納付者氏名(漢字)、住所、生年月日、性別、個人番号、及び世帯コードといった各種の情報を含んでいる。なお、この図14に示した具体例は、図2に記載した例を採用したものであるが、本実施形態を限定するものではない。
システム10は、この基本情報を受信すると、その内容を案件毎に基本情報DBに登録する。次いで、システム10は、この基本情報DBの登録内容に基いて納付通知書を作成し、センターは、これを各納付者へ送付する(符号(2))。
この納付通知書は、図15に示すように、システム10が案件毎に乱数を用いて採番した納付番号、コンビニ収納キー(前記納付番号を包含したバーコード情報)、窓口収納キー(前記納付番号を包含したOCR情報)、納付金額、納付期限、自治体名、納付科目、及び納付者氏名といった各種の情報が記載されている。
ここで、システム10は、案件毎に基本情報DBを作成すると共に、その基本情報DBの登録内容に基いて、納付情報DBを案件毎に作成する(図3において1つ目の矢印の前の状態:状況区分は「0」である)。
次に、図8を参照して、納付者が指定金融機関の窓口で公金納付手続をする場合を説明する。まず、納付者は、納付通知書を携えて指定金融機関に出向き、窓口で公金を現金納付する(符号(1))。指定金融機関は、この納付者の納付手続を受けて、納付通知書から切り離した納付済通をセンターに届ける(符号(2))。センターでは、この納付済通に記載されている情報をシステム10に入力し、データ化する。データ化された情報は、窓口納付情報となって、案件毎に納付情報DBに登録される(図3において1つ目の矢印のように変化した後の状態:状況区分が「0」から「1」に更新される)。
この窓口納付情報は、図16に示すように、窓口収納キー(符号オ)をキーとして、収納会社(符号コ)、納付金額(符号カ)、納付手続日(符号キ)、及び資金化日(符号ス)といった各種の情報を含んでいる。なお、この図16に示した具体例は、図6に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図16と図3とは窓口収納キー(符号オ)で紐付けされる。
ここで、資金化日(符号ス)は、納付者がした納付手続に係る資金が自治体の口座に移動する日である。図4に示した資金化日DBを参照すると、自治体指定金融機関の場合、資金化タイプが「4」で、資金化日は納付済通のデータ化時に指定と登録されている。したがって、センターで納付済通に記載されている内容をシステム10に入力し、データ化する際に、資金化日が決定される。この場合、納付者が現金納付をした金融機関が指定金融機関であるから、その納付手続日の次の営業日に自治体の口座に資金が振り込まれることが分かっている。例えば、納付済通が納付手続日(図5の5/20)の当日にセンターに届けられて情報がデータ化される場合は、納付済通がセンターに届けられた日(5/20)の翌日(5/21)が資金化日とされ、一方、納付済通が納付手続日(図5の5/20)の翌日にセンターに届けられて情報がデータ化される場合は、納付済通がセンターに届けられた日(5/21)の当日(5/21)が資金化日とされる。いずれにせよ、センターでのデータ化時には、資金化日(符号ス)は、図5の例では、5/21と入力される。
図8に戻り、資金化日になると、符号(3)で示すように、指定金融機関からシステム10へ入金情報が送信される。この入金情報は、図示しないが、例えば全国銀行協会のフォーマットに準じるものであり、各公金取扱機関から自治体の口座に入金された資金の公金取扱機関別入金情報である。
システム10は、この入金情報を受信すると、その入金額と、今日が資金化日である案件の納付情報DBの登録データに含まれる納付金額(図3の符号(カ))とを突合し、両金額同士が一致していることを確認したうえで、自治体へ消込情報を送信する(符号(4))。
この消込情報は、図17に示すように、納付書コード(符号ア)をキーとして、納付科目、納付金額(符号カ)、納付手続日(符号キ)、収納確認日(符号シ)、納付者氏名(カナ)、納付者氏名(漢字)、状況区分(符号ク)、収納チャネル(符号ケ)、収納会社(符号コ)、及び資金化日(符号ス)といった各種の情報を含んでいる。ここで、この消込情報は、図示したように、自治体へ報告する情報が、収納チャネルや収納会社が何であるかに関わらず(すなわち、収納チャネルや収納会社が案件毎に異なっていても)、所定の統一された形式で作成されている。なお、この消込情報においては、状況区分(符号ク)は「3」である(図3において3つ目の矢印のように変化した後の状態:状況区分が「2」から「3」に更新されている)。また、この図17に示した具体例は、図3に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図17と図3と図2とは納付番号(符号ウ)及び納付書コード(符号ア)で紐付けされる。
また、図17に示すように、消込情報には、納付者の口座情報やクレジットカード情報等は含まれていない。なお、本実施形態では、前述したように、図3の納付情報DBに、納付者の口座情報やクレジットカード情報等が記録されないようになっているが、たとえ納付情報DB等に納付者の口座情報やクレジットカード情報等が記録される場合であっても、つまり、システム10が納付者の口座情報やクレジットカード情報等を保有している場合であっても、消込情報には、納付者の口座情報やクレジットカード情報等が含まれないようになっているのである。
図8に符号(5)で示すように、資金化日には、指定金融機関から自治体へ入金情報が送信されており、自治体は、この指定金融機関からの入金情報と、システム10からの消込情報とを突合して、自治体が保有する自治体独自の基本情報DB及び/又は納付情報DBの登録データの消込みを行うこととなる。その際、消込情報に含まれる収納金額(符号カ)が入金情報に含まれる入金額と一致していることが既にシステム10の側でチェック済みなので、自治体における前記消込作業が極めて円滑に行われることとなる。
次に、図9を参照して、納付者が非指定の金融機関の窓口で公金納付手続をした場合を説明する。ただし、図8の場合と比べて異なる部分のみ説明を加える。図9の場合が図8の場合と比べて異なる部分は、図9に符号(2)で示すように、納付済通が指定金融機関からではなく非指定金融機関からセンターへ届けられる点である。また、図9に符号(3)で示すように、納付者が納付手続を行った非指定金融機関から、自治体の口座がある指定金融機関へ、資金化日までに資金移動が発生する点である。
そして、資金化日(図16の符号ス)は、図4に示した資金化日DBを参照すると、非指定金融機関の場合、資金化タイプが「1」で、資金化日は、納付者が納付手続を行った日の2営業日後と登録されている。例えば、納付済通が納付手続日(図5の5/20)の当日にセンターに届けられた場合は、納付済通がセンターに届けられた日(5/20)の翌々日(5/22)が資金化日とされ、一方、納付済通が納付手続日(5/20)の翌日にセンターに届けられた場合は、納付済通がセンターに届けられた日(5/21)の翌日(5/22)が資金化日とされる。いずれにせよ、資金化日(符号ス)は、図5の例では、5/22と入力される。この入金予定日(符号ス)は、システム10の側で資金化日DBを参照して決定される。
次に、図10を参照して、納付者がコンビニエンスストアで公金納付手続をした場合を説明する。まず、図9に符号(1)で示すように、納付者は、納付通知書を携えてコンビニエンスストアに出向き、公金を現金納付する。コンビニエンスストアは、この納付者の納付手続を受けて、コンビニエンスストア収納代行会社へ、納付手続のあったことを、必要事項と共に通知する(符号(2))。コンビニエンスストア収納代行会社は、この通知を受けると、コンビニ納付手続情報(つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報)をセンターへ送信する(符号(3))。
このコンビニ納付手続情報は、図18に示すように、コンビニ収納キー(符号エ)をキーとして、収納会社(符号コ)、納付金額(符号カ)、納付手続日(符号キ)、資金化日(符号ス)、及び収納確認フラグ(符号セ)といった各種の情報を含んでいる。なお、この図18に示した具体例は、図6に記載した例を採用したものであるが、本実施形態を限定するものではない。
システム10は、コンビニ納付手続情報を受信すると、その内容を案件毎に納付情報DBに登録する。その場合、資金化日(図3の符号ス)は、図4に示した資金化日DBを参照すると、コンビニエンスストアの場合、資金化タイプが「3」で、資金化日は、月間スケジュールで決まると登録されている。例えば、納入手続が5/20にあったとすると、5/20は図4の納付手続日範囲(開始)〜(終了)に入っているから、資金化日(符号ス)は、図5の例では、5/31と入力される。この資金化日(符号ス)は、システム10の側で資金化日DBを参照して決定される。なお、図18と図3とはコンビニ収納キー(符号エ)で紐付けされる。
次いで、システム10は、この納付情報DBの登録内容に基いて仮消込情報(速報)を作成し、これを自治体へ送信する(符号(4))。なお、図5の例では、この仮消込情報(速報)は納付手続日の翌日(5/21)に通知されている。
この仮消込情報(速報)は、図19に示すように、納付書コード(符号ア)をキーとして、納付科目、納付金額(符号カ)、納付手続日(符号キ)、納付者氏名(カナ)、納付者氏名(漢字)、個人番号、状況区分(符号ク)、収納チャネル(符号ケ)、収納会社(符号コ)、及び資金化日(符号ス)といった各種の情報を含んでいる。これにより、自治体の側で、早い段階で、案件毎に納付手続の有無を確認することができ、納付者が納付手続をしたのに自治体から督促状が送られてきた、というような不具合が未然に防止される。ここで、この仮消込情報(速報)は、図示したように、案件毎に記載内容が異なっていても、所定の統一された形式で作成されている。また、納付者の口座情報やクレジットカード情報等は含まれていない。なお、この図19に示した具体例は、図3に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図19と図3と図2とは納付番号(符号ウ)及び納付書コード(符号ア)で紐付けされる。
次いで、図10に符号(5)で示すように、納付者が納付手続をしたコンビニエンスストアからコンビニエンスストア収納代行会社へ前記納付手続に係る資金が移動する。コンビニエンスストア収納代行会社は、この資金移動に応じて、コンビニ納付確認情報(つまり、自治体の口座へ入金する資金が準備されたという確認情報)をセンターへ送信する(符号(6))。
このコンビニ納付確認情報は、図20に示すように、コンビニ収納キー(符号エ)をキーとして、収納会社(符号コ)、納付金額(符号カ)、収納確認日(納付手続に係る資金がコンビニエンスストア収納代行会社へ移動した日:符号シ)、資金化日(符号ス)、及び収納確認フラグ(符号セ)といった各種の情報を含んでいる。これにより、資金化日(符号ス)に自治体の口座に資金が確実に入金されることが約束されたことになる。なお、この図20に示した具体例は、図6に記載した例を採用したものであるが、本実施形態を限定するものではない。
システム10は、コンビニ納付確認情報を受信すると、その内容を案件毎に納付情報DBに登録する。その場合、状況区分が「1」から「2」に更新される(図3の2つ目の矢印)。なお、図20と図3とはコンビニ収納キー(符号エ)で紐付けされる。
次いで、システム10は、この納付情報DBの登録内容に基いて仮消込情報(確報)を作成し、これを自治体へ送信する(符号(7))。なお、図5の例では、この仮消込情報(確報)は5/26に通知されている。
この仮消込情報(確報)は、図21に示すように、納付書コード(符号ア)をキーとして、納付科目、納付金額(符号カ)、収納確認日(納付手続に係る資金がコンビニエンスストア収納代行会社へ移動した日:符号シ)、納付者氏名(カナ)、納付者氏名(漢字)、個人番号、状況区分(「2」に更新されている:符号ク)、収納チャネル(符号ケ)、収納会社(符号コ)、及び資金化日(符号ス)といった各種の情報を含んでいる。ここで、この仮消込情報(確報)は、図示したように、案件毎に記載内容が異なっていても、所定の統一された形式で作成されている。また、納付者の口座情報やクレジットカード情報等は含まれていない。なお、この図21に示した具体例は、図3に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図21と図3と図2とは納付番号(符号ウ)及び納付書コード(符号ア)で紐付けされる。
次いで、図10に符号(8)で示すように、コンビニエンスストア収納代行会社から自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号(9)で示すように、指定金融機関からシステム10へ入金情報が送信されるのであるが、これ以降の符号(9)〜(11)は、図8の符号(3)〜(5)と同じであるので、その説明は省略する。
次に、図11を参照して、納付者がインターネットバンキングのWEBサイト上で納付手続をした場合を説明する。まず、図11に符号(1)で示すように、納付者は、自己の保有するPC等を用いて、MPN(マルチペイメントネットワーク)収納センターのWEB収納サイトにアクセスする。このとき納付者のPCに表れる初期画面W1を図38に例示する。納付者は納付通知書に記載されている納付番号(図15参照)等、必要事項を入力して納付手続ボタンをクリックすると、図39に示すように、納付手続の続行画面W2に変わるので、納付者は自己の口座番号を入力して口座情報確認ボタンをクリックする。これにより、図11に符号(2)で示すように、口座情報が納付者取引金融機関に送られ、符号(3)で示すように、確認情報が返信される。そして、符号(4)で示すように、納付者に対して、納付手続画面(図示せず)が表示されるので、納付者は、その画面上で納付手続を行うこととなる。MPN収納センターは、納付者によるこの納付手続に応じて、インターネットバンキング納付手続情報(つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報)をセンターへ送信する(符号(5))。
なお、納付者が図38に例示した初期画面W1上で、納付番号等の必要事項を入力して納付手続ボタンをクリックしたとき、すでにこの件の納付手続が済んでいる場合は、二重納付を防止するため、図40に示すように、納付手続が済んでいることを示す納付状況を表示して今のこの納付手続を中止するようになっている(二重納付防止画面W3:確認ボタンをクリックすると初期画面W1に戻る)。
前記インターネットバンキング納付手続情報は、図22に示すように、納付番号(符号ウ)をキーとして、収納会社(符号コ)、納付金額(符号カ)、納付手続日(符号キ)、資金化日(符号ス)、及び収納確認フラグ(符号セ)といった各種の情報を含んでいる。なお、この図22に示した具体例は、図6に記載した例を採用したものであるが、本実施形態を限定するものではない。
システム10は、インターネットバンキング納付手続情報を受信すると、その内容を案件毎に納付情報DBに登録する。その場合、資金化日(図3の符号ス)は、図4に示した資金化日DBを参照すると、インターネットバンキング(MPN収納センター)の場合、資金化タイプが「2」で、資金化日は、速報通知日の3営業日後と登録されている。例えば、納付手続が5/20にあり、当日に自治体の側へ速報が通知されるとすると、資金化日(符号ス)は、図5の例では、5/23と入力される。この資金化日(符号ス)は、システム10の側で資金化日DBを参照して決定される。なお、図22と図3とは納付番号(符号ウ)で紐付けされる。
次いで、システム10は、この納付情報DBの登録内容に基いて仮消込情報(速報)を作成し、これを自治体へ送信する(符号(6))。なお、図5の例では、この仮消込情報(速報)は納付手続日の当日(5/20)に通知されている。ただし、この仮消込情報(速報)は、前述の図19に示した通りであるので、ここでは説明を繰り返さない。
次いで、図11に符号(7)で示すように、納付者取引金融機関からMPN収納センターへ前記納付手続に係る資金が移動する。MPN収納センターは、この資金移動に応じて、インターネットバンキング納付確認情報(つまり、自治体の口座へ入金する資金が準備されたという確認情報)をセンターへ送信する(符号(8))。
このインターネットバンキング納付確認情報は、図23に示すように、納付番号(符号ウ)をキーとして、収納会社(符号コ)、納付金額(符号カ)、収納確認日(符号シ)、資金化日(符号ス)、及び収納確認フラグ(符号セ)といった各種の情報を含んでいる。これにより、資金化日(符号ス)に自治体の口座に資金が確実に入金されることが約束されたことになる。なお、この図23に示した具体例は、図6に記載した例を採用したものであるが、本実施形態を限定するものではない。
システム10は、インターネットバンキング納付確認情報を受信すると、その内容を案件毎に納付情報DBに登録する。その場合、状況区分が「1」から「2」に更新される(図3の2つ目の矢印)。なお、図23と図3とは納付番号(符号ウ)で紐付けされる。
次いで、システム10は、この納付情報DBの登録内容に基いて仮消込情報(確報)を作成し、これを自治体へ送信する(符号(9))。なお、図5の例では、この仮消込情報(確報)は5/21に通知されている。ただし、この仮消込情報(確報)は、前述の図21に示した通りであるので、ここでは説明を繰り返さない。
次いで、図11に符号(10)で示すように、MPN収納センターから自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号(11)で示すように、指定金融機関からシステム10へ入金情報が送信されるのであるが、これ以降の符号(11)〜(13)は、図8の符号(3)〜(5)と同じであるので、その説明は省略する。
最後に、図12を参照して、納付者がクレジットカードのWEBサイト上で納付手続をした場合を説明する。全体の動作の流れは、図11の場合と類似している。ただし、図11の場合と異なる部分は、図12に符号(5)で示すように、収納センターからセンターへ送信されるのは納付手続兼確認情報であり、それに応じて、図11に符号(6)で示すように、センターから自治体へ送信されるのは、仮消込情報(速報兼確報)である点である。
まず、図12に符号(1)で示すように、納付者は、自己の保有するPC等を用いて、クレジット収納センターのWEB収納サイトにアクセスする。このとき納付者のPCには前述のインターネットバンキングの場合の図38の初期画面W1に類似の画面が表れるが、ここではその図示は省略する。納付者は納付通知書に記載されている納付番号(図15参照)や自己のカード番号等を入力する。これにより、符号(2)で示すように、カード情報が納付者が契約するクレジット会社に送られ、符号(3)で示すように、認証情報が返信される。そして、符号(4)で示すように、納付者に対して、納付手続画面が表示されるので、納付者は、その画面上で納付手続を行うこととなる。クレジット収納センターは、納付者によるこの納付手続に応じて、クレジット納付手続兼確認情報(つまり、納付者が公金取扱機関を介して公金の納付手続をしたという手続情報であり、かつ、自治体の口座へ入金する資金が準備されたという確認情報)をセンターへ送信する(符号(5))。
このクレジット納付手続兼確認情報は、図24に示すように、納付番号(符号ウ)をキーとして、収納会社(符号コ)、納付金額(符号カ)、納付手続兼収納確認日(符号シ)、資金化日(符号ス)、及び収納確認フラグ(符号セ)といった各種の情報を含んでいる。なお、この図24に示した具体例は、図6に記載した例を採用したものであるが、本実施形態を限定するものではない。
システム10は、クレジット納付手続兼確認情報を受信すると、その内容を案件毎に納付情報DBに登録する。その場合、資金化日(図3の符号ス)は、図4に示した資金化日DBを参照すると、クレジット決済(クレジット収納センター)の場合、資金化タイプが「2」で、資金化日は、速報通知日の3営業日後と登録されている。例えば、納付手続が5/20にあり、当日に自治体の側へ速報が通知されるとすると、資金化日(符号ス)は、図5の例では、5/23と入力される。この資金化日(符号ス)は、システム10の側で資金化日DBを参照して決定される。また、状況区分が「0」から「2」に更新される(図3の1つ目の矢印及び2つ目の矢印)。なお、図24と図3とは納付番号(符号ウ)で紐付けされる。
次いで、システム10は、この納付情報DBの登録内容に基いて仮消込情報(速報兼確報)を作成し、これを自治体へ送信する(符号(6))。なお、図5の例では、この仮消込情報(速報兼確報)は納付手続日の当日(5/20)に通知されている。ただし、この仮消込情報(速報兼確報)は、前述の図21に示した仮消込情報(確報)に準じて同様なので、ここでは説明を繰り返さない。
次いで、図12に符号(7)で示すように、クレジット会社からクレジット収納センターへ前記納付手続に係る資金が移動する。これにより、資金化日(符号ス)に自治体の口座に資金が確実に入金されることが約束されたことになる。
次いで、図12に符号(8)で示すように、クレジット収納センターから自治体指定金融機関へ納付手続に係る資金が移動する。そして、資金化日になると、符号(9)で示すように、指定金融機関からシステム10へ入金情報が送信されるのであるが、これ以降の符号(9)〜(11)は、図8の符号(3)〜(5)と同じであるので、その説明は省略する。
ただし、このクレジット決済で公金を納付する場合の特徴として、図12に符号(16)で示すように、後日、クレジット会社から納付者の元へ利用代金明細書が送付され、これに伴い、符号(17)で示すように、クレジット契約に従って納付者の口座から納付手続に係る資金が引き落とされることは、いうまでもない。
以上の基本的動作に加えて、本実施形態においては、図8〜図12に符号(99)で示すように、自治体の側からセンターの側へ納付済情報が送信されることがある。つまり、納付者のなかには、納付通知書を携えて、自治体の庁舎へ直接出向き、公金の納付手続をする者がある。この場合、センターには公金取扱機関からの手続情報が入らないので、自治体とセンターとで情報の連携を図るために、自治体の側からセンターの側へ納付済情報が送信されるのである。
この納付済情報は、図25に示すように、納付書コード(符号ア)をキーとして、納付金額(符号カ)、納付手続日(符号キ)、納付者氏名(カナ)、納付者氏名(漢字)、収納チャネル(符号ケ)、及び収納会社(符号コ)といった各種の情報を含んでいる。システム10は、この納付済情報を受信すると、その内容を納付情報DBに登録することとなる。なお、図25と図3と図2とは納付番号(符号ウ)及び納付書コード(符号ア)で紐付けされる。
さらに、本実施形態においては、図13に示すように、センターとMPN収納センター(クレジット収納センターでも同じ)との間、及び、センターと自治体との間で、問合せ情報及び回答情報が遣り取りされることがある。次に、この納付状況の問合せ動作を説明する。
つまり、納付者のなかには、公金の二重納付を避けるために、WEB収納サイトを通して、収納センターに自己の納付状況を問い合せる者がある(a)。この場合、収納センターでは他の公金取扱機関を介しての納付状況が判らないから、納付者からの問合せを受けると、さらにセンターへ問合せを行うこととなる(b)。その結果、センターの側から収納センターの側へ、納付状況の問合せに対する回答として回答情報が送信されることとなる(c)。この回答情報は収納センターから納付者に示される(d)。
同様に、納付者のなかには、公金の二重納付を避けるために、自治体(の職員)に自己の納付状況を問い合せる者がある(e)。この場合、納付通知書には、図15に図示したように、自治体が付与した納付書コード(符号ア)が記載されておらず、代わりに、センターが採番した納付番号(符号ウ)が記載されているので、納付者はこの納付番号で問合せを行うこととなる。しかし、自治体の側では納付番号が判らないから、納付者からの問合せを受けると、さらにセンターへ問合せを行うこととなる(f)。その結果、センターの側から自治体の側へ、納付状況の問合せに対する回答として回答情報が送信されることとなる(g)。この回答情報は自治体から納付者に伝達される(h)。
このうち、公金取扱機関へ送られる回答情報(c)は、図26に示すように、納付番号(符号ウ)をキーとして、納付者氏名、状況区分(符号ク)、納付金額(符号カ)、納付手続日(符号キ)、収納チャネル(符号ケ)、及び収納会社(符号:コ)といった各種の情報を含んでいる。ただし、納付者の住所や生年月日、電話番号や個人場号、あるいは世帯コードといった、納付者に関する情報のうちの特定の情報は一切含まれていない。このようにデータを分散することにより、公金取扱機関に対する不必要なデータの漏洩リスクの低減が図られている。なお、この図26に示した具体例は、図3に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図26と図3とは納付番号(符号ウ)で紐付けされる。
一方、自治体へ送られる回答情報(g)は、図27に示すように、納付書コード(符号ア)をキーとして、納付科目、納付者氏名(カナ、漢字)、状況区分(符号ク)、納付金額(符号カ)、納付手続日(符号キ)、収納チャネル(符号ケ)、収納会社(符号コ)、及び資金化日(符号ス)といった各種の情報を含んでいる。ただし、納付者の口座情報やクレジットカード情報は一切含まれていない。このようにデータを分散することにより、自治体に対する不必要なデータの漏洩リスクの低減が図られている。なお、この図27に示した具体例は、図3に記載した例を採用したものであるが、本実施形態を限定するものではない。また、図27と図3と図2は納付番号(符号ウ)及び納付書コード(符号ア)で紐付けされる。
なお、本実施形態では、前述したように、図3の納付情報DBに、納付者の口座情報やクレジットカード情報等が記録されないようになっているが、たとえ納付情報DB等に納付者の口座情報やクレジットカード情報等が記録される場合であっても、つまり、システム10が納付者の口座情報やクレジットカード情報等を保有している場合であっても、自治体への回答情報(g)には、納付者の口座情報(図11の符号(2))やクレジットカード情報(図12の符号(2))等が一切含まれないようになっているのである。
一方、本実施形態では、前述したように、図2の基本情報DBに、納付者氏名の他、住所や生年月日等の納付者個人に関する各種の情報が記録されるようになっているが、このように基本情報DB等に納付者個人に関する各種の情報が記録される場合であっても、つまり、システム10が納付者個人に関する各種の情報を保有している場合であっても、公金取扱機関への回答情報(c)には、納付者個人に関する各種の情報のうちの特定の情報が一切含まれないようになっているのである(図26の例では、納付者氏名だけが含まれている)。
ここで、納付者が自己の保有するPC等を用いて、収納センターのWEB収納サイトにアクセスしたときに(a)、納付者のPCに表れる初期画面W1は図38に例示したものと同様である。すなわち、納付者は納付通知書に記載されている納付番号(図15参照)等、必要事項を入力して納付状況問合せボタンをクリックすると、未納付のときは、図39の納付手続続行画面W2に移動し、納付済みのときは、図40の二重納付防止画面(回答情報)W3に移動する(d)。
また、図41に、自治体(の職員)が納付者からの問合せを受けてセンターに照会する場合に(f)、自治体のシステムに表れる検索条件指定画面W4を例示し、図42に、センターからの回答情報(図28)を受けて自治体のシステムに表れる検索結果画面(検索日付時刻付)W5を例示した(g)。
なお、図41及び図42は、納付番号(つまり案件)を指定しないで、納付者だけで検索した場合を示すが、図41の検索条件指定画面W4で納付番号(納付者から聞いて)を指定すると、図42の検索結果画面W5ではその案件のみの結果が表示されるようになっている。
以下、図28〜図37のフローチャートに従って、前記システム10の具体的動作をさらに詳しく説明する。これらのフローチャートは、本発明に係る公金収納管理システム用プログラムの実施の形態をフローチャートの態様で提供するものである。
まず、図28は、システム10が基本情報の受信時に行う動作のフローチャートである。すなわち、ステップS11で、基本情報を受信すると、ステップS12で、受信した案件毎に乱数を用いて納付番号を採番し、ステップS13で、受信した基本情報に納付番号とコンビニ収納キー(納付番号を含んでいる)と窓口収納キー(納付番号を含んでいる)とを追加して案件毎に基本情報DBに登録する。次いで、ステップS14で、基本情報DBに基き納付通知書を作成した後、ステップS15で、基本情報DBの登録内容に基き納付情報DBを案件毎に作成する。
次に、図29は、システム10が窓口収納情報の登録時に行う動作のフローチャートである。すなわち、ステップS21で、納付済通の記載内容を入力した後、ステップS22で、入力した情報(つまり窓口納付情報)を窓口収納キーをキーにして納付情報DBに登録する。
次に、図30は、システム10が消込情報の送信時に行う動作のフローチャートである。すなわち、ステップS31で、公金取扱機関別の入金情報を自治体指定の金融機関から受信したうえで、ステップS32で、今日が資金化日である全案件を納付情報DBから抽出し、ステップS33で、抽出した案件の納付情報に含まれている納付金額を公金取扱機関別に合計する。次いで、ステップS34で、合計した公金取扱機関別の納付金額と、公金取扱機関別の入金情報とを突合し、差異の無いことを確認する。そして、ステップS35で、納付番号にて基本情報DBを検索し、各案件の納付書コードを読み出した後、ステップS36で、読み出した納付書コードを付して、今日が資金化日の全案件を統合した消込情報を所定の統一された形式で作成して、自治体側へ送信する。
次に、図31は、システム10がコンビニ収納の場合において仮消込情報(速報)の送信時に行う動作のフローチャートである。すなわち、ステップS41で、コンビニ納付手続情報を受信すると、ステップS42で、受信した情報をコンビニ収納キーをキーにして納付情報DBに登録する。次いで、ステップS43で、今日、コンビニ納付手続情報を受信した全案件を納付情報DBから抽出し、ステップS44で、抽出した案件を公金取扱機関(この場合はコンビニエンスストア)毎に統合する。そして、ステップS45で、納付番号にて基本情報DBを検索し、各案件の納付書コードを読み出した後、ステップS46で、読み出した納付書コードを付して、今日、コンビニ納付手続情報を受信した全案件を公金取扱機関(この場合はコンビニエンスストア)毎に統合した仮消込情報(速報)を所定の統一された形式で作成して、自治体側へ送信する。
次に、図32は、システム10が資金化日の決定時に行う動作のフローチャートである。すなわち、ステップS51で、公金納付手続日と資金化日との関係を公金取扱機関毎に資金化日DBに記録し、ステップS52で、公金取扱機関から受信した納付情報に資金化日が含まれているか否かを判定し、含まれているときはそのままエンドとなるが、含まれていないときは、ステップS53で、納付情報に含まれている納付手続日及び公金取扱機関と、資金化日DBに記録されている公金納付手続日と資金化日との関係とから、資金化日を決定する。
次に、図33は、システム10がコンビニ収納の場合において仮消込情報(確報)の送信時に行う動作のフローチャートである。すなわち、ステップS61で、コンビニ収納確認情報を受信すると、ステップS62で、受信した情報をコンビニ収納キーをキーにして納付情報DBに登録する。次いで、ステップS63で、今日、コンビニ納付確認情報を受信した全案件を納付情報DBから抽出し、ステップS64で、抽出した案件を公金取扱機関(この場合はコンビニエンスストア)毎に統合する。そして、ステップS65で、納付番号にて基本情報DBを検索し、各案件の納付書コードを読み出した後、ステップS66で、読み出した納付書コードを付して、今日、コンビニ納付確認情報を受信した全案件を公金取扱機関(この場合はコンビニエンスストア)毎に統合した仮消込情報(確報)を所定の統一された形式で作成して、自治体側へ送信する。
次に、図34は、システム10が同じくインターネットバンキングによるWEB電子収納の場合において仮消込情報(速報)の送信時に行う動作のフローチャートである。すなわち、ステップS71で、インターネットバンキング納付手続情報を受信すると、ステップS72で、受信した情報を納付番号をキーにして納付情報DBに登録する。次いで、ステップS73で、今日、インターネットバンキング納付手続情報を受信した全案件を納付情報DBから抽出し、ステップS74で、抽出した案件を公金取扱機関(この場合は納付者取引金融機関)毎に統合する。そして、ステップS75で、納付番号にて基本情報DBを検索し、各案件の納付書コードを読み出した後、ステップS76で、読み出した納付書コードを付して、今日、インターネットバンキング納付手続情報を受信した全案件を公金取扱機関(この場合は納付者取引金融機関)毎に統合した仮消込情報(速報)を所定の統一された形式で作成して、自治体側へ送信する。
次に、図35は、システム10が同じくインターネットバンキングによるWEB電子収納の場合において仮消込情報(確報)の送信時に行う動作のフローチャートである。すなわち、ステップS81で、インターネットバンキング納付確認情報を受信すると、ステップS82で、受信した情報を納付番号をキーにして納付情報DBに登録する。次いで、ステップS83で、今日、インターネットバンキング納付確認情報を受信した全案件を納付情報DBから抽出し、ステップS84で、抽出した案件を公金取扱機関(この場合は納付者取引金融機関)毎に統合する。そして、ステップS85で、納付番号にて基本情報DBを検索し、各案件の納付書コードを読み出した後、ステップS86で、読み出した納付書コードを付して、今日、インターネットバンキング納付確認情報を受信した全案件を公金取扱機関(この場合は納付者取引金融機関)毎に統合した仮消込情報(確報)を所定の統一された形式で作成して、自治体側へ送信する。
次に、図36は、システム10が同じくクレジットカードによるWEB電子収納の場合において仮消込情報(速報兼確報)の送信時に行う動作のフローチャートである。すなわち、ステップS91で、クレジット納付手続兼確認情報を受信すると、ステップS92で、受信した情報を納付番号をキーにして納付情報DBに登録する。次いで、ステップS93で、今日、クレジット納付手続兼確認情報を受信した全案件を納付情報DBから抽出し、ステップS94で、抽出した案件を公金取扱機関(この場合はクレジット会社)毎に統合する。そして、ステップS95で、納付番号にて基本情報DBを検索し、各案件の納付書コードを読み出した後、ステップS96で、読み出した納付書コードを付して、今日、クレジット納付手続兼確認情報を受信した全案件を公金取扱機関(この場合はクレジット会社)毎に統合した仮消込情報(速報兼確報)を所定の統一された形式で作成して、自治体側へ送信する。
最後に、図37は、システム10が同じく納付状況の問合せ受信時に行う動作のフローチャートである。すなわち、ステップS101で、収納センター又は自治体から納付状況の問合せを受信すると、ステップS102で、問合せの納付番号にて納付情報DBを検索し、そして、ステップS103で、納付者からの問合せが公金取扱機関(MPN収納センター又はクレジット収納センター)経由のときは、納付者の特定情報を含まない回答情報を作成し、一方、納付者からの問合せが自治体経由のときは、納付者の口座情報及びクレジットカード情報を含まない回答情報を作成して、ステップS104で、作成した回答情報を問合せ元(収納センター又は自治体)へ送信する。
以上のように、本実施形態に係る公金収納管理システム10においては、自治体の公金収納を管理するにあたり、基本情報受取手段(S11)が、公金を収納するために必要な情報(図14参照)を自治体から受け取り、基本情報記録手段(S13)が、基本情報受取手段が受け取った情報を案件毎(納付書コード毎)に記録するから(図2参照)、基本情報記録手段には、納付者氏名や納付金額、納付期限等の公金を収納するために必要な基本情報が案件毎に記録されることとなる。次いで、納付情報受取手段(S21、S41、S61、S71、S81、S91)が、納付者が公金取扱機関を介して公金の納付手続をした案件に関する納付情報(図16、図18、図20、図22、図23、図24参照)を公金取扱機関から受け取り、納付情報記録手段(S22、S42、S62、S72、S82、S92)が、基本情報記録手段に記録されている案件のうち、納付情報受取手段で納付情報が受け取られた案件について、該納付情報を、自治体の口座へ資金が移動する資金化日(符号ス)を含めて記録するから(図3参照)、納付情報記録手段には、納付者が公金取扱機関を介して公金の納付手続をした案件に関する、例えば、納付金額(符号カ)、納付手続日(符号キ)、公金取扱機関(窓口収納、コンビニ収納、WEB電子収納等:符号ケ)、収納会社(銀行、郵便局、コンビニエンスストア、インターネットバンキングによる銀行、クレジット会社等:符号コ)等の納付情報が資金化日(符号ス)と共に記録されることとなる。次いで、抽出手段(S32)が、納付情報記録手段に記録されている案件のうち資金化日が同じである案件を抽出するから、たとえ納付者が公金の納付手続をした公金取扱機関が異なっていても、あるいは納付者が公金の納付手続をした納付手続日が異なっていても、資金化日が同じである案件が抽出されることとなる。そして、消込情報作成手段(S36)が、抽出手段で抽出された案件について、納付情報記録手段に記録されている納付情報を統合することにより自治体へ報告する消込情報(図17参照)を作成し、消込情報送り手段(S36)が、消込情報作成手段で作成された消込情報(図17参照)を自治体へ送るから、自治体としては、資金化日が同じである複数の案件(納付書コード:符号ア)の消込情報をまとめて受け取ることができ、従来のように、公金取扱機関が相異なる納付情報や、納付手続日が相異なる収納情報、あるいは資金化日が相異なる納付情報等を、それぞれバラバラのタイミングで受け取ることがなくなる。その結果、自治体の側で受け取った納付情報の取扱いが円滑となり、資金化日に自治体の口座へ資金が移動したときに自治体の側で行う消込作業が容易となって、当該公金収納管理システム10の信頼性ないし商品性の向上が図られることとなる。なお、消込情報送り手段が消込情報を自治体へ送る時期は特に限定されるものではないが、自治体から要望があればそれに従えばよく、また、一般に、資金化日を含む資金化日に近い時期が好ましい。
また、本実施形態に係る公金収納管理システム10においては、資金化日記録手段(S51)が、公金の納付手続日と資金化日との関係を公金取扱機関毎に記録し(図4参照)、資金化日決定手段(S53)が、納付情報(図16、図18、図22、図24参照)を公金取扱機関から受け取ったときに該納付情報に資金化日が含まれていないときは(S52でNOのときは)、前記納付情報受取手段で受け取られた納付情報に含まれている納付手続日(符号キ又は符号シ)及び公金取扱機関(符号コ)と、前記資金化日記録手段に記録されている前記関係(図4参照)とから、資金化日を決定するから、たとえ納付情報に資金化日が含まれていないとき(公金取扱機関の側で記入していないとき)であっても、納付情報受取手段が納付情報を公金取扱機関から受け取った時点で、その案件についての資金化日が適正に判明し、このように当該公金収納管理システム10の側で決定した資金化日(符号ス)を納付情報と共に納付情報記録手段に記録することが可能となる(図3参照)。
また、本実施形態に係る公金収納管理システム10においては、入金情報受取手段(S31)が、各公金取扱機関から自治体の口座に入金された資金の公金取扱機関別入金情報(図8の符号(3)、図9の符号(4)、図10の符号(9)、図11の符号(11)、図12の符号(9))を該口座のある金融機関、つまり自治体指定金融機関から受け取り、突合手段(S33〜S34)が、抽出手段で抽出された案件の納付情報(図3参照)に含まれている納付金額(符号カ)を公金取扱機関(符号コ)別に合計し(S33)、この合計した公金取扱機関別の納付金額と、入金情報受取手段で受け取られた公金取扱機関別入金情報とを突合し(S34)、そして、消込情報送り手段(S36)が、突合手段の突合の後に、消込情報(図17参照)を自治体へ送るから、自治体としては、公金取扱機関別に、自治体の口座に入金された資金の額との突合が既に済んでいる消込情報を当該公金収納管理システム10から受け取ることとなり、自治体の側で行う消込作業がより一層円滑化し容易となる。
また、本実施形態に係る公金収納管理システム10においては、納付情報受取手段(S41、S71)が、納付情報として、納付者が公金の納付手続を行ったという手続情報(図18、図22)を受け取り、納付情報記録手段(S42、S72)が、基本情報記録手段に記録されている案件のうち、納付情報受取手段で手続情報(図18、図22)が受け取られた案件について、該手続情報を記録するから(図3参照)、納付情報記録手段には、納付者が公金取扱機関を介して公金の納付手続を行なったという、例えば、納付手続日(符号キ)や公金取扱機関(符号コ)等を含む手続情報が、納付者が納付手続を行った時点で記録されることとなる。次いで、第2抽出手段(S43、S73)が、納付情報記録手段に手続情報が記録された後、手続情報に含まれている納付手続日(符号キ)及び公金取扱機関(符号コ)が同じである案件を抽出するから、たとえ納付者や納付手続をした時間等が相異なっていても、納付手続日及び公金取扱機関が同じである案件が抽出されることとなる。そして、速報情報作成手段(S46,S76)が、第2抽出手段で抽出された案件について、納付情報記録手段に記録されている手続情報を統合することにより自治体へ報告する速報情報(図19)を作成し、速報情報送り手段(S46,S76)が、速報情報作成手段で作成された速報情報を自治体へ送るから、自治体としては、納付手続日(符号キ)及び公金取扱機関(符号コ)が同じである複数の案件(複数の納付書コード)の速報情報(納付者が公金取扱機関を介して公金の納付手続を行ったという情報)をまとめて早い時期(納付者が公金の納付手続を行ってから早い時期)に受け取ることができ(手続情報が納付情報記録手段に記録された後に、前記抽出、作成、送りが行われるから)、従来のように、納付手続をした時間が相異なる納付情報をバラバラのタイミングで受け取ることがなくなる。その結果、自治体がすでに公金の納付手続をした納付者に誤って督促状を出してしまう、という問題が解消されるばかりでなく、自治体が当該公金収納管理システム10から速報情報を受け取る頻度が減って、自治体の側で受け取った情報の取扱いの煩雑さが抑制され、この点でも、当該公金収納管理システム10の信頼性ないし商品性の向上が図られることとなる。加えて、納付手続日(符号キ)と公金取扱機関(符号コ)とが同じ案件は、資金化日(符号ス)も同じとなるので(図4〜図6参照)、自治体は、この複数の案件が統合された速報情報(図19)に基いて、複数の案件の資金化日の登録処理をまとめて行うことができ、この点でも、自治体側で行う作業の円滑化、容易化が図られることとなる。
なお、前記実施形態は、本発明の最良の実施形態であるが、特許請求の範囲を逸脱しない限り、さらに種々の変更や改良を加えることができることはいうまでもない。