(57)【要約】【課題】本部が運営する会員組織の会員が、本部とあらかじめ契約した提携企業から仕入れを行った場合の提携企業による仕入代金の回収を本部が代行する、という代金回収代行ビジネスに用いる代金回収管理システムを実現する。【解決手段】集金員４が係る携帯端末２０所定の出力ボタンを押下すると、集金予定出力処理部１５は、まず、該集金員４が担当する集金ルートに含まれる会員２を契約情報データベースＤＢ１の蓄積内容に基づいて抽出する。入金予定データベースＤＢ２に蓄積されている該当する全ての会員２についての入金予定テーブルを参照し、ログイン日付当日の入金予定内容のうち集金対象となるものをそれぞれの入金予定テーブルから抽出する。抽出内容を所定のフォーマットにて再編集することにより、該集金員４がその日に行うべき集金内容を記述した集金テーブルを生成する。生成された集金テーブルがログイン元の携帯端末２０へと送信される。【選択図】図３
2008123264.tif 000002
【特許請求の範囲】
【請求項１】
本部が運営する会員組織の会員が、前記本部とあらかじめ契約した提携企業から仕入れを行った場合の前記提携企業による仕入代金の回収を本部が代行する、という代金回収代行ビジネスに用いる代金回収管理システムであって、
前記本部に設けられた管理サーバーと、
前記本部に属する複数の集金員に所持され、無線通信で前記管理サーバーにアクセス可能な複数の携帯端末と、
前記会員を識別するための番号や前記会員が属する集金ルートに関する情報を含む契約情報を蓄積する契約情報データベースと、
前記会員からの毎日の現金の入金予定を記述した前記会員ごとの入金予定テーブルが蓄積される入金予定データベースと、
を有してなり、
前記管理サーバーが、
所定の入力手段によって入力される前記契約情報を前記契約情報データベースに蓄積させる契約情報処理手段と、
前記提携企業から提供されて所定の入力手段によって入力される売掛情報に基づいて前記会員ごとの仕入実績を記述した仕入実績テーブルを前記入金予定データベースに蓄積させる売掛情報処理手段と、
前記会員ごとの仕入実績テーブルに基づいて所定期間における前記会員ごとの毎日の入金予定を記述した入金予定テーブルを作成する入金予定作成処理手段と、
前記管理サーバーへログインする前記携帯端末を特定するログイン処理手段と、
前記ログイン処理手段によって特定された前記携帯端末から与えられる所定の実行指示に応答して、当該ログイン日に当該携帯端末を所持する前記集金員が行うべき前記会員からの集金内容を記述した集金テーブルを生成し、当該携帯端末に出力させる集金予定出力処理手段と、
を備え、
前記集金テーブルの生成は、前記集金員が担当する集金ルートに含まれる会員を前記契約情報データベースの蓄積内容に基づいて抽出したうえで、該当する全ての会員についての前記入金予定テーブルを参照して、前記ログイン日の入金予定内容をそれぞれの入金予定テーブルから抽出し、当該抽出内容を所定のフォーマットにて再編集することにより行う、
ことを特徴とする代金回収管理システム。
【請求項２】
請求項１に記載の代金回収管理システムであって、
前記会員からの毎日の現金の入金実績を記述した前記会員ごとの入金台帳テーブルが蓄積される入金台帳データベース、
をさらに備えるとともに、
前記管理サーバーが、
前記集金員によって前記携帯端末から送信される集金実績情報に基づいて前記入金台帳テーブルを更新する入金台帳処理手段、
をさらに備える、
ことを特徴とする代金回収管理システム。
【請求項３】
請求項２に記載の代金回収管理システムであって、
前記集金予定出力処理手段が、前記集金テーブルを生成する際に、ある会員についての前記入金予定テーブルに記述されている前記ログイン日の予定残高額と前記入金台帳テーブルに記述されている前記ログイン日の残高額とを比較し前者の方が小さい場合には前記会員についての前記ログイン日における入金予定内容を抽出しない、
ことを特徴とする代金回収管理システム。
【請求項４】
請求項１ないし請求項３のいずれかに記載の代金回収管理システムであって、
前記会員の休業日を特定する情報が前記契約情報として前記契約情報データベースに蓄積されており、
前記入金予定作成処理手段は、前記休業日以外に入金が行われるように前記入金予定テーブルを作成する、
ことを特徴とする代金回収管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、代金回収代行ビジネスの運営に好適な代金回収管理システムに関する。
【背景技術】
【０００２】
従来より、１００日以上の返済期間を設けるとともに、毎日集金を行うことを前提として、主として飲食店などの個人事業主を対象に、特例で高金利での貸し付けを行うことが認められた日賦貸金業者が存在する。毎日の売上金の中から少額ずつを返済すればよいため、個人事業主にとって、係る日賦貸金業者からの借り入れは、金利負担感が少ないとされている。こうした日賦貸金業者においては、通常、これに属する集金員があらかじめ定められた担当地域に存在する貸付先を毎日巡回することによって集金を行う。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、一部業者の問題ある態様により、昨今においては、こうした日賦貸金業者が引き続き上記のような業務形態を維持していくことが厳しい世情となっている。そこで、日賦貸金業者が有する人的システムを引き続き活用することができ、かつ、従来からの顧客層にとっても単なる借り入れを行う以上のメリットが生じ得る新たなビジネスモデルが案出された。本発明は、この新たなビジネスモデルに好適な代金回収管理システムを実現することを目的とする。
【課題を解決するための手段】
【０００４】
上記課題を解決するため、請求項１の発明は、本部が運営する会員組織の会員が、前記本部とあらかじめ契約した提携企業から仕入れを行った場合の前記提携企業による仕入代金の回収を本部が代行する、という代金回収代行ビジネスに用いる代金回収管理システムであって、前記本部に設けられた管理サーバーと、前記本部に属する複数の集金員に所持され、無線通信で前記管理サーバーにアクセス可能な複数の携帯端末と、前記会員を識別するための番号や前記会員が属する集金ルートに関する情報を含む契約情報を蓄積する契約情報データベースと、前記会員からの毎日の現金の入金予定を記述した前記会員ごとの入金予定テーブルが蓄積される入金予定データベースと、を有してなり、前記管理サーバーが、所定の入力手段によって入力される前記契約情報を前記契約情報データベースに蓄積させる契約情報処理手段と、前記提携企業から提供されて所定の入力手段によって入力される売掛情報に基づいて前記会員ごとの仕入実績を記述した仕入実績テーブルを前記入金予定データベースに蓄積させる売掛情報処理手段と、前記会員ごとの仕入実績テーブルに基づいて所定期間における前記会員ごとの毎日の入金予定を記述した入金予定テーブルを作成する入金予定作成処理手段と、前記管理サーバーへログインする前記携帯端末を特定するログイン処理手段と、前記ログイン処理手段によって特定された前記携帯端末から与えられる所定の実行指示に応答して、当該ログイン日に当該携帯端末を所持する前記集金員が行うべき前記会員からの集金内容を記述した集金テーブルを生成し、当該携帯端末に出力させる集金予定出力処理手段と、を備え、前記集金テーブルの生成は、前記集金員が担当する集金ルートに含まれる会員を前記契約情報データベースの蓄積内容に基づいて抽出したうえで、該当する全ての会員についての前記入金予定テーブルを参照して、前記ログイン日の入金予定内容をそれぞれの入金予定テーブルから抽出し、当該抽出内容を所定のフォーマットにて再編集することにより行う、ことを特徴とする。
【０００５】
請求項２の発明は、請求項１に記載の代金回収管理システムであって、前記会員からの毎日の現金の入金実績を記述した前記会員ごとの入金台帳テーブルが蓄積される入金台帳データベース、をさらに備えるとともに、前記管理サーバーが、前記集金員によって前記携帯端末から送信される集金実績情報に基づいて前記入金台帳テーブルを更新する入金台帳処理手段、をさらに備える、ことを特徴とする。
【０００６】
請求項３の発明は、請求項２に記載の代金回収管理システムであって、前記集金予定出力処理手段が、前記集金テーブルを生成する際に、ある会員についての前記入金予定テーブルに記述されている前記ログイン日の予定残高額と前記入金台帳テーブルに記述されている前記ログイン日の残高額とを比較し前者の方が小さい場合には前記会員についての前記ログイン日における入金予定内容を抽出しない、ことを特徴とする。
【０００７】
請求項４の発明は、請求項１ないし請求項３のいずれかに記載の代金回収管理システムであって、前記会員の休業日を特定する情報が前記契約情報として前記契約情報データベースに蓄積されており、前記入金予定作成処理手段は、前記休業日以外に入金が行われるように前記入金予定テーブルを作成する、ことを特徴とする。
【発明の効果】
【０００８】
請求項１ないし請求項４の発明によれば、本部が運営する会員組織の会員が、前記本部とあらかじめ契約した提携企業から仕入れを行った場合の前記提携企業による仕入代金の回収を本部が代行する、という代金回収代行ビジネスを行う場合において、前記本部による仕入代金の回収を、一定期間の間に毎日一定額ずつ、本部に属する集金員が行う場合の各集金員の集金予定を、効率的かつ実効的なものとすることができ、毎日の入金状況に応じた柔軟な集金ルートの設定を行うことができる。
【０００９】
特に、請求項２および請求項３の発明によれば、実際の入金額と集金実績および入金台帳テーブルとを照合することで、集金および入金が正しく行われていることが確認できる。
【００１０】
特に、請求項３の発明によれば、会員がその日の集金予定額のみならず翌日以降分の集金予定額の分までもまとめて入金する、前倒し入金を行った場合には、前倒し状態が解消されるまで該会員を集金対象から除外することが確実かつ容易に行える。これにより、集金対象ではない会員のところに集金員が出向くという無駄の発生が抑制される。
【００１１】
特に、請求項４の発明によれば、休業日である会員を集金対象から除外することが確実かつ容易に行える。これにより、休業日である会員のところに集金員が出向くという無駄の発生が抑制される。
【発明を実施するための最良の形態】
【００１２】
＜本発明の適用対象となるビジネスモデルの概要＞
本発明の実施形態の説明に先立ち、その適用対象となるビジネスモデルの概要について説明する。図１は、係るビジネスモデルを説明するための関係図である。本発明の適用対象となるビジネスモデルとは、概略的にいえば、本部１が個人事業主を中心とする会員組織を設立・運営し、会員２が本部１と契約した提携企業３から仕入れを行った場合の提携企業３による仕入代金の回収を、本部１が代行する、代金回収代行ビジネスである。より具体的には、次のような流れで運用される。
【００１３】
（１）該会員組織に加入した個人事業主である会員２は、本部１と契約した、好ましくは複数の提携企業３に商品を注文し、提携企業３が該商品を会員２に配送する（つまりは、会員２は提携企業３から商品を仕入れる）；
（２）提携企業３は、会員２から注文があった商品の代金の請求を、本部１に対して行う；
（３）本部１は、この仕入代金を所定の締日ごとに毎月集計し、本部１に属する集金員が、所定の集金期間に会員２から日掛集金（原則として一定額を毎日集金）を行う；
（４）集金期間が経過した後、提携企業３は本部１が集金した仕入代金のうち、商品毎にあらかじめ定められた仕切価格相当額の金額を回収する。
【００１４】
図２は、この代金回収代行ビジネスの適用事例を示す図である。図２に示す事例では、７月２１日から８月２０日までの１ヶ月間（３０日間）に会員２が提携企業から商品を仕入れた仕入代金は６０万円であり、集金期間が９月１日から９月３０日までの１ヶ月間（３０日間）であるので、集金期間においては、毎日２万円ずつ、本部の集金員が会員２から仕入代金の回収を行うことになる。
【００１５】
ここで、上記（３）においては、本部１の集金員はあらかじめ定められた担当地域に存在する会員２を毎日巡回して、各会員２からの集金を行う。集金した現金は適宜、本部１が所定の金融機関に有する口座へと預け入れられる。金融機関から本部１へと与えられる預け入れに係る情報と、集金員からもたらされる集金報告とによって、各会員２からの毎日の入金が確認される。
【００１６】
従って、係る代金回収代行ビジネスにおいて、本部１と会員２との関係は、従来からの日賦貸金業者と、該日賦貸金業者から資金を借り入れる顧客との関係に類似している。すなわち、本部１においては集金員が毎日集金を行うことから、日賦貸金業者が現在保有する人的システムをそのまま活かすことができる。また、会員２においては、日賦貸金業者から借り入れを行った場合と同様、毎日の売上金の中から、少額ずつの支払を行えばよいことになる。
【００１７】
ちなみに、会員２の立場から見れば、提携企業３と単に直接に取り引きをするのではなく、本部１が介在することで本部１が提携企業３に対して一種の信用保証を与えたうえで会員２と提携企業３とが取り引きを行うことになるので、信用が低くても掛け売りでの仕入を行うことが可能となることや、多数の会員２が提携企業３から仕入を行うことで、結果的に該提携企業から大量仕入を行うのと同じ状態となるので、個人単位で仕入を行うよりも仕入れ価格が安くなることにもなる、などのメリットがある。
【００１８】
一方、提携企業３の立場から見れば、本部１が代金回収を代行することで、直接に取り引きを行う場合よりも売掛金回収リスクが小さくなる。よって、従来は難しかった個人事業主との取引が行いやすくなるので、マーケットにおける需要拡大というメリットが得られる。また、代金の回収は本部１から一括して行うので、多数の個人事業主と直接取引する場合には避けられない、煩雑な入金照合が不要となるというメリットもある。
【００１９】
＜代金回収管理システムの構成概要＞
図３は、本発明の実施の形態に係る代金回収管理システム１００の構成の概略を示す図である。代金回収管理システム１００は、上述した代金回収代行ビジネスを行うのに好適なシステムである。代金回収管理システム１００は、本部１に設けられる代金回収管理サーバー１０と、本部１に属する集金員４（４ａ、４ｂ、・・・４ｘ・・・）が所持する携帯端末２０（２０ａ、２０ｂ、・・・２０ｘ・・・）とを含む、一種のクライアントサーバーシステムである。
【００２０】
代金回収管理サーバー１０は、契約情報データベースＤＢ１と、入金予定データベースＤＢ２と、入金台帳データベースＤＢ３と接続され、それぞれとの間で、所定のデータの入出力が可能とされてなる。契約情報データベースＤＢ１と、入金予定データベースＤＢ２と、入金台帳データベースＤＢ３とはいずれも、後述する所定の処理部（代金回収管理サーバー１０の機能的構成要素）によって適宜にアクセス可能とされてなる。好ましくは、いずれもリレーショナル型のデータベースとして構成されてなる。
【００２１】
代金回収管理サーバー１０は、いわゆるサーバーコンピュータによって実現される。すなわち、代金回収管理サーバー１０は、ＣＰＵ、ＲＯＭ、ＲＡＭなどからなり該サーバーの各部を制御する制御部、ハードディスクなどからなる記憶部、キーボードやマウスなどからなる入力部、ディスプレイなどの制御部、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒなどの種々の可搬性の記録媒体との間でデータのリード／ライトを行うインターフェースであるリード／ライト部、有線／無線によるインターネット／イントラネット接続のインターフェースとしての通信部など（いずれも図示を省略）を備える。
【００２２】
好ましくは、代金回収管理サーバー１０における種々のデータ入出力処理は、ＧＵＩによって実現される。また、代金回収管理サーバー１０には中継局１７が接続され、該中継局１７を介して、代金回収管理サーバー１０と携帯端末２０との間で無線通信が可能とされてなる。
【００２３】
携帯端末２０は、例えばＷｅｂ閲覧可能な携帯電話やノートブック型あるいはパームトップ型の小型コンピュータなど、ネットワーク接続機能およびデータ閲覧・編集機能を有する可搬性の情報端末装置である。集金員４は、通常、該携帯端末２０を携帯し、該携帯端末２０に表示される集金予定表の内容に基づいて集金ルートに含まれる会員２を巡回し、集金を行うことになる。
【００２４】
なお、本実施の形態においては、原則として、「集金」という語は、会員２から集金員４が現金を集める行為を指し示す文言として用い、「入金」という語は、集金された現金を本部１が保有する行為およびその状態を指し示す文言として用いるものとする。
【００２５】
＜代金回収管理サーバーの構成＞
代金回収管理サーバー１０においては、ＲＯＭやハードディスクにあらかじめ記憶された所定の代金回収管理プログラムが実行されることにより、制御部、記憶部、入力部、表示部などの作用によって、機能的構成要素として、契約情報処理部１１と、売掛情報処理部１２と、入金予定作成処理部１３と、ログイン処理部１４と、集金予定出力処理部１５と、入金台帳処理部１６とが主として実現される。
【００２６】
契約情報処理部１１は、会員２を識別するための契約番号（会員ＩＤ）や、該会員２属する集金ルート、該会員２の休業日などといった、それぞれの会員２に係る契約情報Ｉ１を取得し、契約情報データベースＤＢ１に対し、それぞれの会員２の情報を識別可能に蓄積する処理を担う。具体的には、会員２となった者から提供される、本部１のオペレータが、上記のような内因２に関する種々の情報を、契約情報処理部１１の作用によって図示しない表示部に表示される契約情報入力メニューに基づいて入力することで、契約情報Ｉ１が契約情報データベースＤＢ１に蓄積される。あるいは、会員２自体が所定の登録用Ｗｅｂサイトにアクセスして、上記内容の登録を自ら行うことによって、契約情報Ｉ１が蓄積される態様であってもよい。
【００２７】
売掛情報処理部１２は、提携企業３を識別するための識別番号（企業ＩＤ）や、提携企業３から提供される、会員２が提携企業３から仕入れを行った際の商品、数量、売掛金額などを含む売掛情報Ｉ２を取得し、入金予定データベースＤＢ２に対し、会員２ごとに蓄積する処理を担う。係る蓄積は、会員２ごとの受注実績テーブルＴＢＬ１（図４、図５参照）を生成することによって行われる。
【００２８】
入金予定作成処理部１３は、売掛情報処理部１２によって入金予定データベースＤＢ２に蓄積された、会員２ごとの受注実績テーブルＴＢＬ１に基づいて、所定の集金期間における入金予定を表す入金予定テーブルＴＢＬ２を会員２ごとに作成し、入金予定データベースＤＢ２に記憶する処理を担う。例えば、図２のように毎月２０日が締め日で翌月の一ヶ月間で支払いを行うように取り決めた場合には、その一ヶ月間の毎日の集金額を演算して、入金予定テーブルＴＢＬ２（図６参照）を作成する。
【００２９】
ログイン処理部１４は、集金員４が所持する携帯端末２０（２０ａ、２０ｂ、・・・２０ｘ）から代金回収管理サーバー１０に対しログインする際の認証処理（つまりは各携帯端末２０をさらにはその所持者である集金員４を特定する処理）や、ログイン日付を特定する処理、さらには、携帯端末２０を所持する集金員４が担当する集金ルート（集金担当地域）に関する情報を取得する処理などを担う。なお、集金ルートに関する情報の取得は、携帯端末２０とこれを所持する集金員４との関連付け情報をログイン処理部１４があらかじめ参照可能とされていてもよいし、携帯端末２０から集金ルートを特定する情報を入力することで代金回収管理サーバー１０がこれを特定できる態様であってもよい。
【００３０】
集金予定出力処理部１５は、ログインしてきた携帯端末２０からの出力指示に応答して、該携帯端末２０を所持する集金員４がログイン日付当日に行うべき集金内容を記述した集金テーブルＴＢＬ３を生成し、ログイン元の携帯端末２０へと送信する処理を担う。
【００３１】
入金台帳処理部１６は、集金員４からもたらされる集金実績情報Ｉ４と、金融機関５から提供される、本部１の所定の入金口座への入金情報Ｉ５とに基づいて、入金台帳データベースＤＢ３に会員２ごとに設けられている入金台帳テーブルＴＢＬ４（図８参照）を更新する処理を担う。
【００３２】
＜入金予定の作成＞
次に、売掛情報Ｉ２の取得とこれに基づく入金予定テーブルＴＢＬ２の作成について説明する。
【００３３】
図４は、提携企業３からの売掛情報Ｉ２の取得と入金予定データベースＤＢ２への蓄積について説明する図である。図４においては、会員２（会員ａ〜会員ｇ）による発注内容を示す売掛情報Ｉ２（Ｉ２ア、Ｉ２イ、Ｉ２ウ）が、３つの提携企業ア、提携企業イ、および提携企業ウから提供される場合を例示している。この場合、本部１のオペレータが、係る売掛情報Ｉ２を、売掛情報処理部１２の作用によって図示しない表示部に表示される売掛情報入力メニューに基づいて入力する度に、会員２ごとの受注実績テーブルＴＢＬ１（ＴＢＬ１ａ〜ＴＢＬ１ｇ）が作成・更新され、入金予定データベースＤＢ２に蓄積されることになる。あるいは、提携企業３自体からネットワーク経由で直接に売掛情報Ｉ２の入力がなされる態様であってもよい。提携企業３からの売掛情報Ｉ２の提供は、毎日なされる態様であってもよいし、適宜の日数ごとにまとめてなされてもよい。
【００３４】
図５は、「シスクリ太郎」という氏名の会員２（契約番号XXXXX-X-XXX）についての受注実績テーブルＴＢＬ１を例示する図である。なお、図５以降の各図における金額の単位は全て「円」である。図５においては８／２０を締め日とする受注実績テーブルＴＢＬ１を例示している。すなわち、受注実績テーブルＴＢＬ１は、その日前の１ヶ月間に「シスクリ太郎」という会員２がいくつかの提携企業３に対して行った商品の仕入れ実績を示すものである。図５の場合、「シスクリ太郎」という会員２は７／２１から８／２０の間に合計で２６５，０００円の仕入を提携企業３から行ったことになる。なお、図５で示す受注実績テーブルＴＢＬ１のフォーマットはあくまで例示であって、これに限定されるものではない。
【００３５】
受注実績テーブルＴＢＬ１は、上述した売掛情報Ｉ２の入力に応じて、適宜のタイミングで更新される。そして、その一定期間ごとの内容を対象に、入金予定作成処理部１３による入金予定テーブルＴＢＬ２の作成が行われることになる。
【００３６】
図６は、入金予定テーブルＴＢＬ２を例示する図である。図６においては、上述の「シスクリ太郎」という会員２の７／２１から８／２０に行った仕入について、９／１から９／３０の３０日間に集金を行う場合の入金予定テーブルを例示している。「入金予定額」欄に、各日において集金が予定されている額が記述されている。「予定残高額」という欄には、その日の入金が行われる前の残高が記述されている。なお、図６においては、「シスクリ太郎」という会員２の休業日である毎週木曜日には入金を行わないように（入金予定額が０円に）設定されている。これは、会員２が休業日の集金を希望しない場合に、休業日に係る情報についてもあらかじめ契約情報Ｉ１の一項目として取得しておくことで可能となる。従って、入金予定作成処理部１３は、３０日間から休業日の４日を差し引いた２６日間で２６５，０００円の入金が行われるように、「シスクリ太郎」という会員２についての入金予定テーブルＴＢＬ２を作成する。
【００３７】
なお、一ヶ月の集金額を単純に集金日数で等分割すると、小銭のやりとりが必要となる１，０００円未満の端数が出ることが頻繁に生じうるが、係る端数を含む徴収は、集金人４にとって煩雑なものとなる。そこで、本実施の形態に係る代金回収管理サーバー１０においては、係る煩雑さを避けるため、入金予定作成処理部１３がこうした端数が生じないように適宜に入金予定額を調整する処理を行う。図６においては、初日である９／１の入金予定額だけを他の日よりも高くすることで、係る端数が生じないように調整されてなる場合が例示されている。なお、図６の場合であれば、これに代わり、最初の５回分の入金額を１１，０００円とするようにしてもよい。これは、入金予定作成処理部１３の作用によって図示しない表示部に表示される所定の処理条件設定メニューにおいて、一日あたりの最小集金金額を設定することで適宜に調整可能とされる。
【００３８】
作成された会員２ごとの入金予定テーブルＴＢＬ２は、次述する集金予定出力の作成に用いられる。
【００３９】
＜集金テーブルの取得＞
次に、集金員４が日々の集金を行う際に参照する集金テーブルの取得について説明する。集金員４は、毎日の業務開始に際して、自身が所持する携帯端末２０から代金回収管理サーバー１０にアクセスして、その日、自身が行うべき集金の内容を記述した集金テーブルＴＢＬ３（後述する）を取得し、携帯端末２０の図示しない表示画面に表示させる。
【００４０】
具体的には、まず、携帯端末２０の図示しない表示画面に所定のログインメニューを表示させ、これに備わる所定のログインボタンを押下する。すると、これに対応する信号が代金回収管理サーバー１０へと送信される。ログイン処理部１４は、これに応答して、該携帯端末２０の認証処理を行う。認証処理が正しく完了すると、携帯端末２０の表示画面には所定の集金予定出力メニューが表示される。
【００４１】
続いて、集金員４が係るメニューにおいて所定の出力ボタンを押下すると、これに応答して、集金予定出力処理部１５は、まず、該集金員４が担当する集金ルートに含まれる会員２を契約情報データベースＤＢ１の蓄積内容に基づいて抽出する。そして、該当する全ての会員２についての入金予定テーブルＴＢＬ２を参照し、ログイン日付当日の入金予定内容のうち集金対象となるものをそれぞれの入金予定テーブルＴＢＬ２から抽出する。抽出内容を所定のフォーマットにて再編集することにより、該集金員４がその日に行うべき集金内容を記述した集金テーブルＴＢＬ３（図７参照）を生成する。生成された集金テーブルＴＢＬ３がログイン元の携帯端末２０へと送信される。
【００４２】
図７は、ある集金員４が担当する集金ルートについてのある日の集金テーブルＴＢＬ３を例示する図である。なお、図７に示す集金テーブルＴＢＬ３はあくまで例示であって、携帯端末２０における実際の表示態様はこの限りではない。なお、集金テーブルＴＢＬ３においては、各会員のその日の集金額が「一回返済額」という項目に記述されている。この集金テーブルＴＢＬ３によれば、この集金員４はその日、「シスクリ  太郎」、「エスシー  一郎」、「日本  花子」という３名の会員２のところを巡回して、「シスクリ  太郎」のところで１０，０００円を集金し、「エスシー  一郎」のところで５，０００円を集金し、「日本  花子」のところで１２，０００を集金することが求められていることになる。
【００４３】
集金員４は、係る集金テーブルＴＢＬ３を参照して、自らの集金先である会員２を巡回し、その日の集金を行うことになる。なお、その日が休業日であることが契約情報Ｉ１に基づいて特定される会員２については、集金の対象から除外されることになるので、集金員４が休業日の会員２のところに出向くという無駄の発生が抑制される。すなわち、集金テーブルＴＢＬ３に記述されている集金先さえ巡回すれば、効率的かつ実効的に集金を行うことができることになる。
【００４４】
＜入金の確認＞
図７に示した集金テーブルＴＢＬ３には、「集金額」という欄が設けられており、集金員４が携帯端末２０を操作することにより実際にそれぞれの会員２から集金した額を入力可能となっている。集金人４は、それぞれの会員２からの集金が終わるとその集金額を「集金額」欄に入力する。そして、携帯端末２０において所定の送信ボタンを押下すると、その入力内容が集金実績情報Ｉ４として、携帯端末２０から中継局１７を介して代金回収管理サーバー１０へと送信される。
【００４５】
代金回収管理サーバー１０においては、このようにして取得された集金実績情報Ｉ４の内容に基づき、入金台帳処理部１６が入金台帳テーブルＴＢＬ４を生成・更新する。
【００４６】
図８は、入金台帳テーブルＴＢＬ４を例示する図である。図８においては、「シスクリ  太郎」なる会員２についての入金台帳テーブルＴＢＬ４が例示されている。ここで、「入金実績額」欄には、携帯端末２０から取得した集金実績情報Ｉ４に記述された「シスクリ  太郎」についての集金額が記述されることになる。図８においては、９／９までの入金実績が「入金実績額」欄に記述されている。なお、「残高額」欄は、各日における入金がなされるまでの残高額が記述されている。なお、図８で示す入金台帳テーブルＴＢＬ４のフォーマットはあくまで例示であって、これに限定されるものではない。
【００４７】
その一方で、集金人４は、集金が終了した後、会員２から集金した現金の入金（預入）を、本部１が所有するある金融機関５の口座に対して行う。係る入金の内容は、該金融機間５から入金情報Ｉ５として本部１へ提供されるので、本部１のオペレータが、入金台帳処理部１６の作用によって実現される図示しない入金台帳入力メニューに基づいてこれを入力することで、入金台帳テーブルが更新されることになる。集金員４から入力された集金実績情報Ｉ４に基づく各会員２の入金実績がその日の入金予定額（一回返済額）と整合し、さらに集金実績情報Ｉ４と金融機関から提供された入金情報Ｉ５とが整合すれば、集金および入金が正しく行われていることになる。
【００４８】
なお、上述の集金テーブルの取得に係る説明において、「ログイン日付当日の入金予定内容のうち集金対象となるもの（入金予定）を・・・・抽出する」とは、入金予定テーブルＴＢＬ２ではその日に集金することが予定されていたものの、それ以前の集金日にすでにその日の分の入金が行われていたような場合（繰り上げ入金がされていた場合）には、その日の集金対象から除外するという趣旨である。具体的には、集金予定出力処理部１５が集金テーブルＴＢＬ３を生成する際には常に、入金予定テーブルＴＢＬ２の予定残高額と入金台帳テーブルＴＢＬ４の残高額とを比較し、後者の方が小さい場合には、たとえその日の入金予定が入金予定テーブルに記述されていた（０円ではない）としても、入金予定テーブルＴＢＬ２からの集金対象としての抽出を行わないように、処理がなされる。
【００４９】
これをさらに具体的に説明する。まず、図８に示した入金台帳テーブルＴＢＬ４の例では、９／９までは入金予定テーブルＴＢＬ２に記述された予定通りの入金があったことになる。この場合、翌９／１０の集金テーブルの出力に際して、集金予定出力処理部１５は、入金予定テーブルＴＢＬ２に記述されている予定残高額と入金台帳テーブルＴＢＬ４に記述されている残高額とがともに１８０，０００円で一致するので、入金予定テーブルＴＢＬ２に記述されている９／１０分の集金予定を抽出して集金テーブルＴＢＬ３にその内容を記述することになる。
【００５０】
一方、図９は、図８と対比的に示す、前倒し（繰り上げ）入金（集金）が実施される場合の入金台帳テーブルＴＢＬ４’を例示する図である。具体的には、入金台帳テーブルＴＢＬ４’では、９／９の入金実績額が２０，０００円となっているとともに、９／１０以降の残高額が１７０，０００円となっている点で、図８の入金台帳テーブルＴＢＬ４と相違する。入金台帳テーブルＴＢＬ４’の例では、９／９には入金予定テーブルＴＢＬ２に記述されている入金予定の計２日分の入金が行われたことになる。この場合、翌９／１０の集金テーブルの生成に際して、集金予定出力処理部１５は、入金予定テーブルＴＢＬ２に記述されている予定残高額と入金台帳テーブルＴＢＬ４に記述されている残高額とを比較すると、前者が１８０，０００円であるのに対して後者が１７０，０００円と小さいために、入金予定テーブルＴＢＬ２に記述されている９／１０分の集金予定の抽出を行わないことになる。
【００５１】
すなわち、ある会員２から翌日以降分の入金が先立って行われた場合には、予定残高額と残高額とが一致するまで、つまりは前倒し状態が解消されるまでその会員２を集金ルートから除外することが、確実かつ容易に行うことができることになる。集金員４が集金対象ではない会員２のところに出向くという無駄の発生が抑制される。ゆえに、効率的かつ実効的な集金が行えるようになる。
【００５２】
以上、説明したように、本実施の形態に係る代金回収管理システムによれば、「本部が個人事業主を中心とする会員組織を設立・運営し、会員が本部と契約した提携企業から仕入れを行った場合の提携企業による仕入代金の回収を、該本部が代行する」という、代金回収代行ビジネスにおいて、本部による仕入代金の回収を、原則として、一定期間の間に毎日、一定額ずつ、集金員が直接会員から集金するという態様で行う場合に、係る集金員の集金予定を効率的かつ実効的なものとすることができる。例えば、休業日であったり、その日に巡回する必要のない会員のところに出向くという無駄が抑制される。
【００５３】
＜変形例＞
代金回収管理サーバー１０や携帯端末２０にプリンタが接続されてなり、それぞれからの所定の実行指示に応答して集金予定表が出力できるようになっていてもよい。代金回収管理サーバー１０の場合は、各ルートの集金予定表を選択的に出力可能であるだけでなく、全ルートの集金予定表を一括して出力可能とされてなるのが好ましい。
【００５４】
また、代金回収管理サーバー１０において所定の実行指示が与えられることにより、複数の携帯端末２０に対して、それぞれを所持する集金員４が担当する集金ルートについての集金予定を、一括して送信することができる態様であってもよい。
【００５５】
代金回収管理サーバー１０が、契約情報データベースＤＢ１や入金予定データベースＤＢ２に蓄積されたデータに基づいて、個々の集金員４についてのその日その日の最適な集金順序および会員２への訪問時間などを決定し、集金予定表と併せて携帯端末２０に表示させる態様であってもよい。休業日の会員２への訪問を除外する場合など、日々の集金先が異なるような場合であっても、効率的な移動によって、迅速な集金が可能となり、本部１の集金コストも抑制されることになる。
【００５６】
入金予定データベースＤＢ２に蓄積されている受注実績テーブルＴＢＬ１や入金台帳データベースＤＢ３に蓄積されている入金台帳を、会員２が閲覧可能になっていてもよい。係る閲覧を行うことにより、会員２が自らの仕入状況および入金状況を把握することが可能になる。
【００５７】
また、上述の実施の形態においては、代金回収管理システム１００の適用対象となる代金回収ビジネスに対応すべく、代金回収管理サーバー１０における入金予定の作成を、１または複数の提携企業３から提供を受けた売掛情報Ｉ２に基づいて行う態様にて説明しているが、本部１が直接に売掛情報Ｉ２を生成・蓄積できる状況であれば、本部が蓄積した売掛情報に基づき入金予定を作成する態様であってもよい。この場合であっても、集金員４による集金予定の取得や、入金の確認に関する処理は、上述の実施の形態と同様に行うことができる。
【図面の簡単な説明】
【００５８】
【図１】本実施の形態に係る発明の適用対象となるビジネスモデルを説明するための関係図である。
【図２】代金回収代行ビジネスの適用事例を示す図である。
【図３】本発明の実施の形態に係る代金回収管理システム１００の構成の概略を示す図である。
【図４】提携企業３からの売掛情報Ｉ２の取得と入金予定データベースＤＢ２への蓄積について説明する図である。
【図５】受注実績テーブルＴＢＬ１を例示する図である。
【図６】入金予定テーブルＴＢＬ２を例示する図である。
【図７】集金テーブルＴＢＬ３を例示する図である。
【図８】入金台帳テーブルＴＢＬ４を例示する図である。
【図９】繰り上げ入金が実施される場合の入金台帳テーブルＴＢＬ４’を例示する図である。
【符号の説明】
【００５９】
１０  代金回収管理サーバー
１１  契約情報処理部
１２  売掛情報処理部
１３  入金予定作成処理部
１４  ログイン処理部
１５  集金予定出力処理部
１６  入金台帳処理部
１７  中継局
２０  携帯端末
１００  代金回収管理システム
ＤＢ１  契約情報データベース
ＤＢ２  入金予定データベース
ＤＢ３  入金台帳データベース
ＴＢＬ１  受注実績テーブル
ＴＢＬ２  入金予定テーブル
ＴＢＬ３  集金テーブル
ＴＢＬ４  入金台帳テーブル
【図１】
2008123264.tif 000003
【図２】
2008123264.tif 000004
【図３】
2008123264.tif 000005
【図４】
2008123264.tif 000006
【図５】
2008123264.tif 000007
【図６】
2008123264.tif 000008
【図７】
2008123264.tif 000009
【図８】
2008123264.tif 000010
【図９】
2008123264.tif 000011