JP2023023221A - 入金管理装置、入金管理方法および入金管理プログラム - Google Patents

Abstract

【課題】入金管理業務において預り金が発生した場合の対応処理を効率的に行い、しかも事務過誤を防止することのできる入金管理装置、入金管理方法および入金管理プログラムを提供する。【解決手段】入金管理装置１００は、制御部１０２を備える。制御部１０２は、支払期日が複数回にわたる支払い義務を有する債務者からの入金日および入金額を認識する入金認識部１０２ａと、入金認識部１０２ａで得られた入金額と入金日における支払義務額とを比較し、入金額が支払義務額を上回る場合に差額を預り金として計上する預り金計上部１０２ｂと、預り金計上部１０２ｂが預り金を計上した日の後で最初の支払期日に、その時点で計上されている預り金を、その時点の支払義務額の一部または全部として充当させる充当部１０２ｃとを備える。【選択図】図１

Description

本発明は、入金管理装置、入金管理方法および入金管理プログラムに関する。

特許文献１には、代金を既に支払った利用者が通信販売アイテムの購入を取り消した場合、新たな購入を希望する通信販売アイテムを受付け、その支払金額はその返金予定額分を自動的に減算することが記載されている。

特開２００５－３１６７５３号公報

金融業界の債権管理業務（クレジット、融資、リース）においては、債務者が複数回にわたる支払期日に支払いを行うことに対して、債務者から返済期日前の入金や請求額を超える過入金が発生した場合に、差額を預り金として管理する業務がある。また、家賃や月謝などの入金管理にも同様の業務がある。預り金が発生した際、システム管理外の運用や都度個別対応が必要な運用としているためオペレータの作業に時間がかかり、事務過誤が発生する懸念もある。

特許文献１記載の技術では、通信販売アイテム購入を取り消した場合でしかも利用者が別途新たに購入を希望するという場合に適用されるのであって、債務者が複数回にわたる支払期日に支払いを行うことに対しての入金管理には適用することができない。

本発明は、上記に鑑みてなされたものであって、入金管理業務において預り金が発生した場合の対応処理を効率的に行い、しかも事務過誤を防止することのできる入金管理装置、入金管理方法および入金管理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る入金管理装置は、制御部を備える入金管理装置であって、前記制御部は、支払期日が複数回にわたる支払い義務を有する契約者からの入金日および入金額を認識する入金認識手段と、前記入金認識手段で得られた前記入金額と前記入金日における支払義務額とを比較し、前記入金額が前記支払義務額を上回る場合に差額を預り金として計上する預り金計上手段と、前記預り金計上手段が預り金を計上した日の後で最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額の一部または全部として充当させる充当手段と、を備えることを特徴とする。

前記預り金計上手段は、前記契約者からの入金日が前記支払期日であったときに、前記入金額が該支払期日における支払義務額を上回る場合に差額を預り金として計上してもよい。

前記預り金計上手段は、前記契約者からの入金日が前記支払期日前であって支払義務額が発生していないときに、前記入金額の全額を預り金として計上してもよい。

前記支払義務額は元金と利息とに区分され、前記充当手段は、前記最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額のうち前記利息を優先して充当させてもよい。

また、本発明に係る入金管理方法は、制御部を備える入金管理装置の前記制御部で実行される入金管理方法であって、前記制御部で実行される、支払期日が複数回にわたる支払い義務を有する契約者からの入金日および入金額を認識する入金認識ステップと、前記入金認識ステップで得られた前記入金額と前記入金日における支払義務額とを比較し、前記入金額が前記支払義務額を上回る場合に差額を預り金として計上する預り金計上ステップと、前記預り金計上ステップで預り金を計上した日の後で最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額の一部または全部として充当させる充当ステップと、を含むことを特徴とする。

また、本発明に係る入金管理プログラムは、制御部を備える入金管理装置の前記制御部に実行させるための入金管理プログラムであって、前記制御部に、支払期日が複数回にわたる支払い義務を有する契約者からの入金日および入金額を認識する入金認識ステップと、前記入金認識ステップで得られた前記入金額と前記入金日における支払義務額とを比較し、前記入金額が前記支払義務額を上回る場合に差額を預り金として計上する預り金計上ステップと、前記預り金計上ステップで預り金を計上した日の後で最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額の一部または全部として充当させる充当ステップと、を実行させることを特徴とする。

本発明によれば、入金管理業務において預り金が発生した場合の対応処理を効率的に行い、しかも事務過誤を防止するという効果を奏する。

図１は、入金管理装置１００の構成の一例を示す図である。 図２は、契約データを示す図である。 図３は、返済予定データを示す図である。 図４は、債務者が支払期日に支払義務額を上回る入金をした場合に設定される取引データを示す図であり（ａ）はその支払期日に設定される取引データを示す図であり、（ｂ）はその後の最初の支払期日に設定される取引データを示す図である。 図５は、債務者が支払義務の生じていない支払期日前に所定額を入金した場合に設定される取引データを示す図であり（ａ）は入金日に設定される取引データを示す図であり、（ｂ）はその後の最初の返済日に設定される取引データを示す図である。 図６は、充当部１０２ｃによる預り金の充当処理時にモニタ１１４に表示される確認画面４００を示す図である。

以下に、本発明に係る入金管理装置、入金管理方法および入金管理プログラムの実施形態を、図面に基づいて詳細に説明する。なお、本実施形態により本発明が限定されるものではない。

［１．構成］
本実施形態に係る発明装置（本発明に係る発明装置を含む）の構成の一例について、図１等を参照して説明する。図１は、入金管理装置１００の構成の一例を示すブロック図である。

入金管理装置１００は、市販のデスクトップ型パーソナルコンピュータを基に構築したものである。なお、入金管理装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置を基に構築したものに限らず、市販のノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォンまたはタブレット型パーソナルコンピュータなどの携帯型情報処理装置を基に構築したものであってもよい。

入金管理装置１００は、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。入金管理装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部１０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、入金管理装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、入金管理装置１００とサーバ装置２００とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。なお、記憶部１０６に格納されるデータは、例えばサーバ装置２００に格納されてもよい。

入出力インターフェース部１０８には、入力装置１１２および出力装置１１４が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。

記憶部１０６には、各種のデータベース（以下、ＤＢと記す）、テーブルおよびファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、および光ディスク等を用いることができる。

制御部１０２は、入金管理装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。

制御部１０２は、機能概念的に、入金認識部（入金認識手段）１０２ａ、預り金計上部（預り金計上手段）１０２ｂ、充当部（充当手段）１０２ｃなどを備える。

記憶部１０６には、取引情報ＤＢ１０６ａ、契約情報ＤＢ１０６ｂ、返済予定情報ＤＢ１０６ｃなどが格納される。

入金管理装置１００は、例えば金融業界の債権管理業務（クレジット、融資、リース）や、自動引き落としでない家賃や月謝などの入金管理に用いられる。入金を行う契約者は、入金管理装置１００によって入金の管理をする管理者に対して、複数回にわたる支払期日に所定の支払義務額の支払いを行う契約を締結しているものとする。以下の例では、入金管理装置１００が債務管理に適用されるものとして説明する。この場合、契約者が債務者であり、管理者が債権者およびその使用人であり、入金は返済に相当する。

図２は、契約データを示す図である。契約データは個々の契約ごとに作成されるデータであり、契約情報ＤＢ１０６ｂに格納されている。図２に示す例は、商品コード１０００にかかる契約であり、ある債務者の債権番号９００にかかる契約データとなっている。商品コードは各商品の識別番号である。債権番号は個別の契約を識別する番号である。

図３は、返済予定データを示す図である。返済予定データは個々の債権番号に基づいて作成されて返済予定情報ＤＢ１０６ｃに格納されている。図３に示す例では、債権番号９００にかかる返済予定が示されている。この返済予定は商品コードや債務契約内容によって決められている。返済予定データには、返済日、返済額、元金、利息、返済前残高、返済後残高が含まれている。返済日は支払期日でありこの場合は複数回にわたっている。すなわち、２０２１年（以下、同年とする）５月２５日が初回の返済日であり、その後毎月２５日が返済日となっている。返済額は返済日ごとの支払義務額であり、この場合は毎月１０万円となっている。返済額は元金と利息とに区分され、それぞれ対応する欄に示されている。この場合、初回の元金は６万円であって、その後５千円ずつ増えていくように設定されている。利息は初回が４万円であって、その後５千円ずつ減っていくように設定されている。返済前残高は対応する返済日における返済前の残高である。ここでは初回の返済前残高が１００万円となっている。返済後残高は対応する返済日における返済後の残高である。返済後残高は返済前残高－元金になる。

図２で示される契約データの契約をしている債務者は、図３で示される返済予定データにしたがって毎月の返済をすることになる。この返済予定データによれば、「返済日」で示される支払期日に、「返済額」で示される支払義務額が生じていることになる。換言すれば、債務者は契約に基づく義務として、支払期日に支払義務額を所定口座に入金すれば足りる。ところが、債務者によっては、支払期日に支払義務額を上回る入金をする場合や、支払義務の生じていない（換言すると支払義務額が発生していない）支払期日前に所定額を入金する場合がある。これらは、主に返済方法が「振込」の商品の場合に生じる。また、返済方法が「引落」の商品の場合、延滞時の振込の返済に対して、支払義務額を超える過入金のケースで預り金が発生することがある。

これらの場合に、債務者側としては支払義務を越える入金については預り金として取り扱うことになる。預り金には様々な取り扱いがあり得るが、本願では、入金管理装置１００により、次回返済まで預り金をプールしておき、次回返済日が到来した時点で充当（消込）する。このような運用は債権者との契約内容（例えば図２に示す契約データ）に予め含まれているものとする。

入金管理装置１００では、このような運用を実現するために、入金認識部１０２ａが債務者からの入金日および入金額を認識する。入金認識部１０２ａは、基本的には毎日入金の有無を確認し、または口座システムからの入金通知情報に連動して入金確認処理をする。

そして、預り金計上部１０２ｂが、入金認識部１０２ａで得られた入金額と入金日における支払義務額とを比較し、入金額が支払義務額を上回る場合に差額を預り金として計上する。また、預り金計上部１０２ｂは、債務者からの入金日が支払期日であったときに、入金額が該支払期日における支払義務額を上回る場合に差額を預り金として計上する。預り金計上部１０２ｂは、さらに債務者からの入金日が支払期日前であって支払義務額が発生していないときに、入金額の全額を預り金として計上する。預り金計上部１０２ｂは、基本的には入金認識部１０２ａが入金を確認した時点で預り金の有無を確認して処理を行う。

充当部１０２ｃは、債務者からの入金額を元金・利息に充当する処理部であるが、その時点で計上されている預り金があれば、該預り金をその時点の支払義務額の一部または全部として元金・利息に充当させる。充当部１０２ｃは、基本的には支払期日に処理を行う。つまり、充当部１０２ｃは預り金計上部１０２ｂが預り金を計上した日の後で最初の支払期日に、預り金を元金・利息に充当することになる。充当部１０２ｃは複数の契約に関する充当をバッチ処理で一括して行う。

［２．処理の具体例］
ここでは、入金管理装置１００で実行される処理の具体例１および具体例２を説明する。それぞれの例では、上記の図２の契約データに基づく契約が締結されていて、図３の返済予定データに基づく返済が予定されているものとする。

（具体例１）
債務者が支払期日に支払義務額を上回る入金をする場合の例について説明する。
図４は、債務者が支払期日に支払義務額を上回る入金をした場合に設定される取引データを示す図であり（ａ）はその支払期日に設定される取引データを示す図であり、（ｂ）はその後の最初の支払期日に設定される取引データを示す図である。

ここでは、債権番号９００の債権に対して残高が１００万円であり、毎月１０万円ずつの返済予定であるにもかかわらず、支払期日である５月２５日に１５万円の入金があったものとする。つまり、５万円分の過入金が発生している。

入金管理装置１００では図４（ａ）に示す取引データが作成される。取引データは取引情報ＤＢ１０６ａに記録・管理される。「ＤＡＴＡ区分」の欄は取引内容を識別コードと文字情報とで示している。「取引日」の欄は、この場合は入金日である。「充当日」の欄は、返済が充当された日であり、この場合は支払期日かつ入金日である。

上記のとおり入金日および入金額は入金認識部１０２ａによって認識される。そして、預り金計上部１０２ｂは、入金額（この場合１５万円）が該支払期日における支払義務額（この場合１０万円）を上回るとことから、差額の５万円を預り金として計上する。この預り金は取引データの「預り金」欄に計上される。

充当部１０２ｃは、上記のとおり債務者からの入金額を元金・利息に充当する処理部である。この場合は、５月２５日よりも前には預り金がなく、しかも５月２５日には支払義務額である１０万円を満たすだけの入金があることから返済予定（図３参照）にしたがって充当処理を行う。この場合、入金額の１５万円から預り金の５万円を差し引いた１０万円のうち、６万円が「充当元金」に充てられて該当欄に計上され、残る４万円が「充当利息」に充てられて該当欄に計上される。「残高」の欄は、充当部１０２ｃによる充当処理がなされた後の残高を示し、この場合は返済前残高の１００万円から充当元金の６万円を差し引いた９４万円となって計上される。次回の支払期日は６月２５日であり、「次回返済日」の欄に記録される。

次回の支払期日６月２５日は、預り金が計上された後の最初の支払期日に相当する。この日には図４（ｂ）に示す取引データが作成される。この取引データは、図４（ａ）に示す取引データに対して、６月２５日の取引にかかる情報（主に太字で示す情報）が追加・更新されたものである。

ここでは、債務者からの入金がなかったものとする。債務者からの入金がない場合であっても、６月２５日は支払期日であることから充当部１０２ｃはバッチ処理を行う。債務者からの入金はないが、充当部１０２ｃはその時点で計上されている預り金の５万円を、その時点の支払義務額１０万円のうちの一部として充当させる。この場合、預り金の５万円は支払義務額１０万円に満たないことから、充当部１０２ｃは、その時点の支払義務額の元金と利息のうち利息を優先して充当させる。６月２５日における返済予定（図３参照）は、元金が６万５千円で、利息が３万５千円であることから、充当部１０２ｃは、預り金の５万のうち３万５千円を利息に充当させ、残る１万５千円を元金に充当させ、それぞれ該当欄に計上する。この時点で預り金は０になり、該当欄に記録される。

返済予定では６月２５日の残高は８７万５千円になるはずであったが（図３参照）、この場合は預り金による充当だけでは不足しており、残高が９２万５千円となり所定欄に計上される。また、充当が支払義務額に不足していることから、債務者に対して所定の督促通知を行う。督促通知は充当部１０２ｃを介して自動で行ってもよいし、オペレータを介して行ってもよい。

６月２５日における取引は通常の入金に基づくものではなく、それ以前に計上されていた預り金に基づくものであり、「ＤＡＴＡ区分」の欄にはその旨の識別コードおよび文字情報が記録される。

また、充当部１０２ｃは、支払期日における預り金が支払義務額と等しい場合には、該預り金の全部を支払義務額に充当させる。さらに、充当部１０２ｃは、支払期日における預り金が支払義務額を越えている場合には、該預り金を支払義務額に充当させるとともに超過分については預り金としてそのまま計上しておく。預り金が支払義務額を大きく超えている場合には、債務者への注意通知などの処理を行ってもよい。注意通知は充当部１０２ｃを介して自動で行ってもよいし、オペレータを介して行ってもよい。

なお、支払期日６月２５日に債務者からの入金があった場合、充当部１０２ｃはその入金額と予め計上されていた預り金との合計額に基づいて充当処理を行えばよい。その際、取引データには、支払期日６月２５日の入金に基づく充当処理とその時点の預り金に基づく充当処理とを区分けして記録してもよいし、まとめて記載してもよい。

充当部１０２ｃによる預り金の充当処理は、基本的には支払期日に自動的にバッチ処理で行われるが、必要に応じてモニタ１１４に確認画面（図６参照）を表示してオペレータが確認してもよい。

（具体例２）
債務者が支払義務の生じていない支払期日前に所定額を入金した場合の例について説明する。
図５は、債務者が支払義務の生じていない支払期日前に所定額を入金した場合に設定される取引データを示す図であり（ａ）は入金日に設定される取引データを示す図であり、（ｂ）はその後の最初の返済日に設定される取引データを示す図である。図５（ａ），（ｂ）の取引データは、図４（ａ），（ｂ）に示すものと同じ形式である。

ここでは、債権番号９００の債権に対して残高が１００万円であり、毎月２５日が支払期日であるにもかかわらず、それ以前の５月２０日に１０万円の入金があったものとする。債務者の支払義務は、支払期日に支払義務額を入金することであり、支払期日以前には支払義務がないと見做される。したがって、入金日である５月２０日には元金・利息への充当は行われず、残高は１００万円のまま維持されている。

入金管理装置１００では図５（ａ）に示す取引データが作成される。入金日および入金額は入金認識部１０２ａによって認識される。そして、預り金計上部１０２ｂは、入金額（この場合１０万円）が該入金日には支払義務額が発生していないことから、全額を預り金として計上する。

そして、その後の最初の支払期日である５月２５日には、図５（ｂ）に示す取引データが作成される。この取引データは、図５（ａ）に示す取引データに対して、５月２５日の取引にかかる情報（主に太字で示す情報）が追加・更新されたものである。

ここでは、債務者からの入金がなかったものとする。債務者からの入金がない場合であっても、５月２５日は支払期日であることから充当部１０２ｃはバッチ処理を行う。債務者からの入金はないが、充当部１０２ｃはその時点で計上されている預り金の１０万円を、その時点の支払義務額１０万円の全部として充当させる。充足の内訳は返済予定データ（図３参照）のとおり、元金が６万円で利息が４万円である。この時点で預り金は０になり、該当欄に記録される。５月２５日における取引は通常の入金に基づく充当ではなく、それ以前に計上されていた預り金に基づくものであり、「ＤＡＴＡ区分」の欄にはその旨の識別コードおよび文字情報が記録される。

図６は、充当部１０２ｃによる預り金の充当処理時にモニタ１１４に表示される確認画面４００を示す図である。確認画面４００は、上記の具体例１および具体例２に共通である。確認画面４００は、支払期日で充当部１０２ｃがバッチ処理を行う際に使用される。この画面の中で、商品コード欄４０１には契約データにおける商品コード、次回返済日欄４０２には取引データにおける次回返済日を指定する。そしてオペレータが実行ボタン４０３を操作することにより自動充当処理が実行される。画面を閉じる場合は、閉じるボタン４０４を操作する。処理進行状況欄４０５には充当部１０２ｃによる処理の状況が表示される。充当部１０２ｃによる処理対象が複数であるときには、その下に合計件数および合計金額が表示される。なお、確認画面４００におけるタイトル名の「預り金自動入金処理」とは充当部１０２ｃによる充当処理を示している。

上記のように本実施形態では、入金認識部１０２ａが入金日および入金額を認識すると、預り金計上部１０２ｂが入金額と支払義務額とを比較し、入金額が支払義務額を上回る場合に差額を預り金として計上する。そして、預り金計上部１０２ｂが預り金を計上した日の後で最初の支払期日に、充当部１０２ｃがその時点で計上されている預り金を、その時点の支払義務額の一部または全部として充当させる。したがって、入金管理業務において預り金が発生した場合に従来行われていた都度個別の入金処理が不要となり、オペレータの作業負荷が軽減されて作業時間が短縮されるとともに、事務過誤の防止が図られ管理精度が向上し、効率的なシステム運用が可能になる。

［３．国連が主導する持続可能な開発目標（ＳＤＧｓ）への貢献］
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８及び９に貢献することが可能となる。

また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、ＳＤＧｓの目標１２、１３及び１５に貢献することが可能となる。

また、本実施形態により、統制、ガバナンス強化に寄与することができるので、ＳＤＧｓの目標１６に貢献することが可能となる。

［４．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、入金管理装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、入金管理装置１００が備える処理機能、特に制御部にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて入金管理装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、このコンピュータプログラムは、入金管理装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。

また、入金管理装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、入金管理装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

本発明は、特に融資、クレジット、リースなどの入金管理において有用である。

１００ 入金管理装置
１０２ 制御部
１０２ａ 入金認識部
１０２ｂ 預り金計上部
１０２ｃ 充当部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 取引情報ＤＢ
１０６ｂ 契約情報ＤＢ
１０６ｃ 返済予定情報ＤＢ
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ装置
３００ ネットワーク

Claims (6)

1. 制御部を備える入金管理装置であって、
   前記制御部は、
   支払期日が複数回にわたる支払い義務を有する契約者からの入金日および入金額を認識する入金認識手段と、
   前記入金認識手段で得られた前記入金額と前記入金日における支払義務額とを比較し、前記入金額が前記支払義務額を上回る場合に差額を預り金として計上する預り金計上手段と、
   前記預り金計上手段が預り金を計上した日の後で最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額の一部または全部として充当させる充当手段と、
   を備えることを特徴とする入金管理装置。
2. 前記預り金計上手段は、前記契約者からの入金日が前記支払期日であったときに、前記入金額が該支払期日における支払義務額を上回る場合に差額を預り金として計上する
   ことを特徴とする請求項１に記載の入金管理装置。
3. 前記預り金計上手段は、前記契約者からの入金日が前記支払期日前であって支払義務額が発生していないときに、前記入金額の全額を預り金として計上する
   ことを特徴とする請求項１に記載の入金管理装置。
4. 前記支払義務額は元金と利息とに区分され、
   前記充当手段は、前記最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額のうち前記利息を優先して充当させる
   ことを特徴とする請求項１～３のいずれか１項に記載の入金管理装置。
5. 制御部を備える入金管理装置の前記制御部で実行される入金管理方法であって、
   前記制御部で実行される、
   支払期日が複数回にわたる支払い義務を有する契約者からの入金日および入金額を認識する入金認識ステップと、
   前記入金認識ステップで得られた前記入金額と前記入金日における支払義務額とを比較し、前記入金額が前記支払義務額を上回る場合に差額を預り金として計上する預り金計上ステップと、
   前記預り金計上ステップで預り金を計上した日の後で最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額の一部または全部として充当させる充当ステップと、
   を含むことを特徴とする入金管理方法。
6. 制御部を備える入金管理装置の前記制御部に実行させるための入金管理プログラムであって、
   前記制御部に、
   支払期日が複数回にわたる支払い義務を有する契約者からの入金日および入金額を認識する入金認識ステップと、
   前記入金認識ステップで得られた前記入金額と前記入金日における支払義務額とを比較し、前記入金額が前記支払義務額を上回る場合に差額を預り金として計上する預り金計上ステップと、
   前記預り金計上ステップで預り金を計上した日の後で最初の前記支払期日に、その時点で計上されている前記預り金を、その時点の前記支払義務額の一部または全部として充当させる充当ステップと、
   を実行させることを特徴とする入金管理プログラム。

Images