【解決手段】口座の入出金を入出金時点と共に登録する手段と、前記口座の入出金予定を入出金予定時点と共に登録する手段と、任意の時点における口座残高を算出する手段と、特定の時点における口座残高を所定の額に調整する手段と、を有するキャッシュフロー管理システム。
複数の前記口座について、時間軸上の少なくとも1以上の時点において、算出される前記口座残高が正の値である場合には0から正方向に積み上げ棒グラフとして、算出される前記口座残高が負の値である場合には0から負方向に積み上げ棒グラフとして、複数の前記口座が互いに区別できる態様で示すとともに、
前記時点における複数の前記口座の算出される前記口座残高の総計をグラフ上に示す、
口座残高の推移をグラフ化する手段を有する、
請求項1〜7のいずれか1項に記載のキャッシュフロー管理システム。
【発明を実施するための形態】
【0016】
以下、本発明の実施形態に係るキャッシュフロー管理システム100を、図面を参照して説明する。
【0017】
図1は、キャッシュフロー管理システム100の概念図である。キャッシュフロー管理システム100は、コンピュータを利用した情報処理システムであり、単体のコンピュータにより(すなわち、スタンドアロンにより)実現することもできるが、本実施形態では、情報通信ネットワークNを介したサーバ=クライアントシステムとして実現されている例を示す。すなわち、主たる情報処理及びユーザに紐づけられたデータの保持はネットワークNに接続されたサーバ2によりなされ、サーバ2と情報通信可能にネットワークNに接続されたクライアント端末3では、キャッシュフロー管理システム100を利用するユーザに対するインタフェースを主として提供する。
【0018】
ネットワークNは情報通信可能なコンピュータネットワークであればその態様は特に限定されず、どのようなものであってもよいが、本例ではインターネットであり、上述の態様により、キャッシュフロー管理システム100は、クライアント端末3を使用するユーザに対して、いわゆるクラウドコンピューティングにより、SaaS(Software as a Service)として提供されることになる。
【0019】
なお、
図1では、サーバ2を1台、クライアント端末3を3台示したが、これは一例であり、サーバ2を複数台用意し、分散コンピューティングの手法により動作させ、あるいはミラーリングを行ってもよい。クライアント端末3の数は限定されず、サーバ2を複数のユーザが利用できるようになっている。ただし、相異なるユーザ同士が互いの情報を参照することができないよう、各ユーザに発行されたアカウントによりアクセス権限に制限が設けられるほか、いわゆるテナントシステムにより、ユーザ毎に使用するサーバ2上の領域を区分し、他のユーザに割り当てられた領域にアクセスできないようにすることで、情報セキュリティを確保するようにしてよい。
【0020】
また、
図1では、金融機関サーバ4がネットワークNに接続されている様子が同時に示されている。金融機関サーバ4はキャッシュフロー管理システム100には含まれないため、金融機関サーバ4とネットワークNとの接続を破線で示しているが、キャッシュフロー管理システム100は、金融機関が公開しているAPI(Application Programable Interface)を利用することにより金融機関サーバ4と通信し、ユーザの口座情報等を取得することができる。
【0021】
図2はサーバ2およびクライアント端末3の物理構成を示す一般的なコンピュータ1の構成図である。基本的には、サーバ2およびクライアント端末3は標準的なコンピュータであり、その差は情報処理能力と記憶容量の違いである。ただし、クライアント端末3としてどのようなコンピュータを使用するかはユーザの任意であるため、サーバ2に匹敵するあるいはこれを上回る処理能力を有するコンピュータを用意することも可能であるが、本例では、クラウドコンピューティングにより主要な情報処理及びデータの記憶はサーバ2が担うため、ユーザは、クライアント端末3として安価で処理能力の低いコンピュータを利用できる。
【0022】
コンピュータ1は、CPU(Central Processing Unit)1a、RAM(Random Access Memory)1b、外部記憶装置1c、GC(Graphics Controller)1d、入力デバイス1e及びI/O(Inpur/Output)1fがデータバス1gにより相互に電気信号のやり取りができるよう接続されている。ここで、外部記憶装置1cはHDD(Hard Disk Drive)やSSD(Solid State Drive)等の静的に情報を記録できる装置である。またGC1dからの信号はCRT(Cathode Ray Tube)やいわゆるフラットパネルディスプレイ等の、使用者が視覚的に画像を認識するモニタ1hに出力され、画像として表示される。入力デバイス1eはキーボードやマウス、タッチパネル等の、ユーザが情報を入力するための機器であり、I/O1fはコンピュータ1が外部の機器と情報をやり取りするためのインタフェースである。CPU1aはコンピュータ1が必要とする情報処理の負荷に応じて、複数用意されて並列演算がなされるように構成されていてもよい。
【0023】
コンピュータ1をサーバ2あるいはクライアント端末3として機能させるためのアプリケーションプログラムは外部記憶装置1cにインストールされ、必要に応じてRAM1bに読みだされてCPU1aにより実行される。また、かかるプログラムは、適宜の光ディスク、光磁気ディスク、フラッシュメモリ等の適宜のコンピュータ可読情報記録媒体に記録されて提供されても、インターネット等の情報通信回線を介して提供されてもよい。コンピュータ1をクライアント端末3として機能させるアプリケーションに関しては、webブラウザのような汎用のソフトウェアを用い、I/O1fを介してサーバ2により機能が提供される、いわゆるクラウドコンピューティングにより提供されてもよい。
【0024】
図3は、キャッシュフロー管理システム100の機能的構成を示す機能ブロック図である。同図に示したキャッシュフロー管理システム100の各機能は、サーバ2あるいはクライアント端末3のCPU1aがRAM1b上に展開されたプログラムコードを読み込み実行し、あるいはRAM1b又は外部記憶装置1cの所定の領域が特定の機能に割り当てられ、もしくはその両方等により実現されるものであり、同図に示す各機能ブロックは、そのようにして実現されるキャッシュフロー管理システム100の機能を概念的に示したものである。
【0025】
ユーザ情報データベース10は、キャッシュフロー管理システム100を利用しようとするユーザ毎に確保される情報記憶領域であり、そのユーザに関する登録情報など各種の情報が記憶されるとともに、少なくとも1以上の口座データベース11を含む。
【0026】
口座データベース11は、ユーザが現実に利用する口座における金銭の収受を記録するものであり、1の口座データベース11は1の現実の口座に対応している。そのため、ユーザが現実の複数の口座について、キャッシュフロー管理システム100により管理しようとするならば、同数の複数の口座データベース11が用意される。
【0027】
なお、本明細書で「口座」は、ユーザが金融機関にて開設した口座だけでなく、ユーザが金銭の収受を把握しようとする単位を含むより広い概念を意味している。例えば、ユーザが管理する現金も「口座」の一種として把握される(いわゆる「現金口座」)。その他にも、クレジットカードの利用、POSシステムや各種決済サービスなどを「口座」として取り扱っても差し支えない。口座データベース11に登録される情報の詳細については後ほど説明する。
【0028】
キャッシュフロー管理システム100には、さらに、ユーザが選択した口座の入出金を入出金時点と共に登録する入出金登録部12、口座の入出金予定を入出金予定時点と共に登録する入出金予定登録部13、口座の実入出金記録を登録済みの入出金予定と対応付け、入出金として再登録する入出金対応付部14、特定の時点における口座残高を所定の額に調整する残高調整部15、任意の時点における口座残高を算出する口座残高算出部16、口座残高の推移をグラフ化するグラフ化部17及び、金融機関サーバ4と通信をする通信部18が設けられる。グラフ化部17により生成されたグラフは、モニタ1hに表示され、ユーザに視認される。
【0029】
図4は、口座データベース11に含まれる情報の例を、便宜的に図表の形式で示したものである。口座データベース11には、その指し示す口座自身を示す情報の部分(図中、Aで示した部分)と、その口座に関して時系列を伴って蓄積される入出金その他の記録に関する情報の部分(図中、Bで示した)が含まれる。Aの部分の情報は、特別な事情がない限りは通常は変化せず、キャッシュフロー管理システム100により管理しようとする口座を登録して口座データベース11を新規に作成する際にユーザにより入力される。
図4では、口座名と口座の種類を示す口座種別のみをAの部分の情報として示しているが、これ以外の情報、例えば口座番号や銀行・支店コードなどの口座自身に関する情報のほか、ユーザのメモや、その口座に関して金融機関サーバ4にアクセスしてAPIを利用するための識別情報やパスワードが含まれていてよい。
【0030】
Bの部分の情報は、口座データベース11により管理される口座について生じた事象を逐次記録していくものであるから、そのような事象が生じるごとに情報が追加され蓄積されていくことになる。
図4では、そのような情報として、期首残高、入出金及び入出金予定、振替及び調整額を示している。各情報の種類は種別の欄に示され、同表の横方向の一行が一の情報に対応している。
【0031】
期首残高は、口座を登録して口座データベース11を新規に作成した際の初期残高を指定するものである。キャッシュフロー管理システム100において、ある時点における特定の口座の残高は、この期首残高の金額に対して、登録された事象における金額の変動を時系列に沿って合算することにより求められることになる。
【0032】
入金及び出金は、その入出金時点において口座に現実に生じた金銭の増減を記録するものである。
図4では入出金時点として、日時を年月日及び時分まで記録しているが、年月日のみであってもよいし、秒まで記録するものであってもよい。後述するように、APIを利用して入出金を登録するのでなければ、オペレータがマニュアルで入出金を登録することになるが、その際に時分(秒)までの登録がむつかしければ、時分(秒)の指定がなければその日の午前0時をデフォルトで登録するなどしてもよい。また、金額はここでは口座残高が増加するものを正、減少するものを負として記録しているが、これを絶対額で記録するようにしてもよい。また、
図4に示された入出金や振替先のほか、他の情報を合わせて記録するようにしてもよい。
【0033】
振替は、キャッシュフロー管理システム100に登録されている口座間での金銭の移動を示し、
図4に示したものは、○○銀行の口座から50万円が引き出され、現金口座、すなわち、ユーザの手元現金に移動したことを示している。
図4には示していないが、現金口座に対応する口座データベース11においては、同じ日時にて同額の金額の増加が同じく「振替」として登録されることになる。
【0034】
入金予定及び出金予定は、その入出金予定時点において、口座に将来的に生じるであろう金銭の増減を記録するものである。具体的には、商取引その他の取引や契約に伴う金銭の収受は、取引等の成立時点ではなく後日なされることは一般的に広く行われており、このような入出金の予定をあらかじめ登録しておくことで、将来的な口座残高の変化を予測することができる。いわゆる手形取引や小切手の決済等も入出金の予定として把握できる。入出金の予定が現実の金銭の収受として実行されなかった場合には、貸し倒れあるいは不渡りが発生することになる。
【0035】
調整額は特殊な記録であり、特定の時点における口座残高を所定の額に調整するものである。調整額の作用と実用上の意義を説明するため、
図5に、
図4に示した口座の口座残高の推移を、調整額が記録されている場合と記録されていない場合についてグラフで示した。
【0036】
同グラフ中実線は、調整額が記録されていないとした場合の
図4に示した口座の口座残高の推移を日付に対し示したものである。2020/1/1時点の期首残高である100万円から出発し、過去及び将来にわたり入出金及び入出金予定により口座残高がどのように変化するかが示されており、このグラフからは、2020/11/30の出金予定により一時的に口座残高は10万円にまで減少するものの、その後入金が予定されており、2020/2/1時点で110万円になることがわかる。
【0037】
ところが、キャッシュフロー管理システム100に登録されていない出金があり、現実には2020/1/24の時点で口座残高が40万円であったとすると、実際に生じるであろう口座残高の推移は、
図5の破線に示した通りとなり、2020/1/30の時点で口座残高がマイナスとなる。すなわち、2020/2/1には十分な資金的余裕が確保できるもの、2020/1/30においてはこの口座は資金ショートを起こし、支払いの不能が発生することになる。したがって、口座の管理者である事業者は、2020/1/30の支払い前に振替などにより資金の手当てをしておかなければならないことになる。
【0038】
このように、入出金及び入出金予定の登録のみしかしていない状態では、それらの登録が正確でかつリアルタイムに全てなされていなければ、口座残高の将来的な推移を正確に把握することができないことになるが、そのような登録を完全に実行することは非現実的である。そのため、キャッシュフロー管理システム100では、
図4に示したように調整額を登録し、口座データベース11上で把握される口座残高と、現実の口座残高を一致させる。
【0039】
すなわち、口座の管理者が口座情報を確認するなどし、口座残高の現実の値を調整額として口座データベース11に登録することにより、口座データベース11上で把握される口座残高と、現実の口座残高は一致する。そのため、口座データベース11により把握される口座残高は
図5の破線に示したものとなり、正確な口座残高の将来的な推移を把握できるようになる。
【0040】
ここで、調整額として登録されるのは、
図4に示した指定調整額であり、これは現実の口座残高の額であって、口座データベース11上で把握される口座残高との差ではない。現実の口座残高と口座データベース11上で把握される口座残高の差、すなわち、口座データベース11上で口座残高の変化量として把握される額(
図4の「金額」にあたる額)は残高調整部15により自動的に計算され登録される。
【0041】
すなわち、残高調整部15は、所定の額、すなわち、指定調整額を口座残高の目標値として、口座残高がその所定の額に一致するように調整する。そのため、口座データベース11に登録される調整額の情報には、所定の額、すなわち、指定調整額が含まれる。
【0042】
これは、調整額が、本来口座データベース11に登録されるべき入出金が登録されていないことに起因する、現実の口座残高と口座データベース11上把握される口座残高との不一致を解消するための情報であり、後から、正しい入出金の登録が改めてなされることを前提としているためである。すなわち、調整額は、後から正しい入出金の登録がなされた場合にも、調整額が登録された時点における正しい口座残高の額に、口座データベース11上把握される口座残高を一致させるように作用する。
【0043】
そのため、
図3に示したように、残高調整部15には、再計算部19が設けられており、調整額の登録の後から、正しい入出金や入出金予定の登録が改めてなされた場合に、調整額の「金額」をその登録に係る日時において、口座残高が指定調整額に一致するように再計算する。
【0044】
具体例で説明すると、
図4に示した口座データベース11の状態から、2020/1/20に10万円の出金があったことが、改めて登録されたものとする。その場合には、すでに登録済みの調整額について、再計算部19による再計算がなされ、調整額における「金額」の値が更新されて、
図6に示すような状態となる。すなわち、調整額が登録された2020/1/24 9:03の時点において、口座残高が指定調整額である40万円に一致するように金額が変化する。
【0045】
このように、再計算部19が、調整額の金額を、その登録された特定の時点より以前の時点において、口座残高を変動させる要素である、入出金や入出金予定などの登録があったときに再計算することにより、常に口座データベース11より把握される口座残高を、現実の口座残高に正しく一致させることができる。なお、登録された調整額の日時より以後の時点における入出金等の登録は、調整額に影響を与えなないため、これは考慮する必要はない。
【0046】
理想的には、全ての入出金及び入出金予定が正しく登録されたならば、それらから把握される口座残高と、現実の口座残高とは一致するはずである。関係する全ての登録がなされたならば、登録された調整額の「金額」は0円になることとなる。この時、再計算部19により再計算された調整額の額が0円であった場合に、かかる調整額を不要として削除するようにしてもよいし、そのまま残しておいてもよい。本実施形態に係るキャッシュフロー管理システム100では、口座データベース11に登録された調整額は、オペレータが明示的に削除しない限りは、たとえその金額が0円となっても自動的に削除することはしていない。なぜなら、たとえ調整額の金額が0円になったとしても、さらに後から別の登録がなされる可能性があるためである。
【0047】
以上の説明では、入出金及び調整額の登録は、主としてオペレータが個別にそれらの情報をキャッシュフロー管理システム100に登録するものとして説明したが、前述したように、キャッシュフロー管理システム100が金融機関より口座の情報を取得することにより、自動登録がなされるようにしてもよい。
【0048】
自動登録には、オペレータの操作に基づいて行う自動登録と、あらかじめ定めておいたタイミングで行う自動登録の2種があってよい。オペレータの操作に基づいて行う自動登録は、オペレータがクライアント端末3を操作してキャッシュフロー管理システム100に自動登録を指示することにより行われる。
【0049】
自動登録の指示が入出金の登録に対してなされた場合、
図3に示す入出金登録部12は通信部18を通じて金融機関サーバ4にアクセスし、当該金融機関より公開されているAPIを用いて指示のあった口座の現実の入出金の記録(以降、「実入出金記録」と称する。)を取得し、対応する口座データベース11に入出金を登録する。
【0050】
また、自動登録の指示が口座残高の調整に対してなされた場合、
図3に示す残高調整部15は通信部18を通じて金融機関サーバ4にアクセスし、当該金融機関より公開されているAPIを用いて指示のあった口座の現実の残高(以降、「実残高」と称する。)を取得し、対応する口座データベース11に調整額を登録する。この時、口座データベース11により把握される口座残高と、実残高が一致している場合においても調整額を登録するようにしてもよい。その場合、調整額の金額は0円として登録されることになるが、その後、例えばオペレータの入力ミスなどにより実在しない過去の入出金などが誤って登録された場合にも、口座データベース11により把握される口座残高と実残高とが食い違う事態を防止する効果がある。
【0051】
一方、あらかじめ定めておいたタイミングで行う自動登録では、オペレータがあらかじめ自動登録を行う日時を指定しておくことにより、キャッシュフロー管理システム100は指定された日時に自動登録を行う。日時の指定は、入出金の自動登録及び調整額の自動登録ごとに独立に指定できてよく、また、口座ごとに異なる日時を指定してよい。日時はあらかじめ特定の期日を指定するものであってよいほか、定期的に繰り返される日時の指定ができるものであることが望ましい(例えば、毎月1日の午前0時や、毎週金曜日の午後5時等)。
【0052】
このようにあらかじめ定めておいたタイミングで自動登録を実行することにより、事業者が気づかぬうちに、口座データベース11により把握される口座残高と実残高が食い違う事態を防止することができる。
【0053】
さらに、キャッシュフロー管理システム100は、
図3に示す入出金対応付部14を有していてよい。口座データベース11に登録された入出金予定は、登録された予定通りに現実に入出金がなされれば、登録された日時における入出金となるはずであるが、諸事情により現実の入出金の日時は前後するなど、必ずしも事前の予定通りであるとは限らない。
【0054】
このように入出金予定が登録された予定のとおりに実行されなかった場合には、上に述べた、未登録の入出金などと同様に、口座残高を正確に把握するうえでの妨げとなる。そのため、入出金対応付部14は、現実の口座に対する入出金と、口座データベース11に登録された入出金予定とを対応付ける。現実の入出金と対応付けられた入出金予定は、すでに「予定」ではないため、入出金の記録に登録を改められる。
【0055】
入出金対応付部14における動作は、オペレータによる人為的な対応付けに加え、キャッシュフロー管理システム100による自動対応付けがなされてよい。
【0056】
オペレータによる人為的な対応付けは、現実の口座の記録をもとにオペレータが登録済みの入出金予定を一件一件確認していけばよく、現実の入出金があったことを入力すれば、入出金予定の登録を入出金の登録へと更新し、またその際に、入出金日時等の予定からの変更があれば、オペレータからの入力に基づいて登録内容を訂正すればよいことになる。
【0057】
キャッシュフロー管理システム100による自動対応付けは、先に説明した自動登録と同様に、オペレータの操作に基づいて行う自動対応付けと、あらかじめ定めておいたタイミングで行う自動対応付けの2種があってよい。
【0058】
オペレータの操作に基づいて行う自動対応付けは、オペレータがクライアント端末3を操作してキャッシュフロー管理システム100に自動対応付けを指示することにより行われる。
図3に示す入出金対応付部15は通信部18を通じて金融機関サーバ4にアクセスし、当該金融機関より公開されているAPIを用いて指示のあった口座の実入出金記録を取得し、得られた実入出金記録と、口座データベース11に登録されている入出金予定との対応付けを所定のアルゴリズムに基づいて行う。
【0059】
このアルゴリズムとしてどのようなものを採用するかは任意であるが、基本的には、登録済みの入出金予定と入出金の日時(あるいは日のみの一致でよい)、入出金の金額、及び入出金先が一致する実入出金記録は互いに対応するものとみなしてよい。両者が一致せず、対応関係の不明なものについては、クライアント端末3の画面に適宜のダイアログを表示するなどして、オペレータに確認を要求すればよい。
【0060】
この際、登録済みの入出金予定と実入出金記録との類似性に応じて、オペレータに対する確認の有無及び処理を変えてよい。例えば、類似性の高い入出金予定と実入出金記録(日時のみが異なり、金額及び入出金先が一致するもの等)については、対応関係にあるものと推定されるため、ユーザに対応候補として示し、確認のみ要求すればよい。類似性が低い実入出金記録(日時が遠い、金額、入出金先のいずれかが一致しない等)については、通常は入出金予定と対応するものとは考えられないため、入出金登録部12により、新規の入出金として登録すればよい。また、入出金予定日が到来しているにもかかわらず、対応する現実の入出金が見つからない入出金予定については、ユーザに別途注意喚起を行う。
【0061】
また、かかる入出金の自動対応付けは、オペレータがあらかじめ自動対応付けを行う日時を指定しておくことにより、キャッシュフロー管理システム100が指定された日時に自動的に実行してよい。自動対応付けの動作自体は、先に説明したオペレータの操作に基づいて行う自動対応付けの場合と同様でよいが、オペレータが不在であると考えられるため、対応関係が推定される入出金予定と実入出金記録についての確認や、対応する現実の入出金の記録が見つからない入出金予定についての注意喚起を、自動対応付けの実行時点で行うことができない。そのため、これらについての確認や注意喚起等は、次にオペレータがキャッシュフロー管理システム100にアクセスした際に表示するシステムメッセージや、電子メール等の種々の手段によりオペレータに通知するとよい。
【0062】
自動対応付けを行う日時の指定もまた、定期的に繰り返される日時の指定ができるものであることが望ましい。かかる自動対応付けを例えば、毎日あるいは毎週の決まった時点で実行することにより、より正確に口座残高を把握できるとともに、入出金予定が実行されていないことを速やかに発見できる。
【0063】
このようにキャッシュフロー管理システム100が自動対応付けを行うことにより、オペレータによる実際の確認を要し、また情報の修正入力を必要とする入出金予定の総数を大幅に減じ、作業効率の格段の向上とヒューマンエラーの低減がなされると同時に、口座残高のより正確な把握が可能となる。
【0064】
以上説明した、入出金の登録、残高調整及び入出金の対応付けを自動で行うタイミングの設定は、入出金登録部12、入出金対応付部13及び残高調整部15にそれぞれ設けられたタイミング設定部20、21及び22によりなされる。タイミング設定部20、21及び22はそれぞれ、適宜のユーザインタフェースをクライアント端末2の画面に表示し、オペレータに所望のタイミングの設定を促す。
【0065】
図7は、入出金登録部12及び入出金予定登録部13がオペレータに提示するユーザインタフェースの例である。本実施形態に係るキャッシュフロー管理システム100では、入出金の登録と、入出金予定の登録に共通のユーザインタフェースを用いているが、これを別々に設けてもよい。図示したユーザインタフェースはクライアント端末3のモニタに表示され、オペレータは適宜の入力デバイス1eを用いて、必要事項を入力し登録する。
【0066】
同ユーザインタフェースにおいて、最上部にある「確定」及び「予定」は、オペレータがこのいずれかを選択することにより、登録しようとする情報が入出金であるのか、入出金予定であるのかを指定するものである。オペレータは、さらに、入出金日時(入出金予定が選択されている場合は入出金予定日時を指す)、入金/出金の別、入出金先、入出金がなされる口座、入出金の金額といった必要な情報を入力し、最下部に配置された「登録」を選択することにより、入出金又は入出金予定が指定された口座についての口座データベース11に登録される。
【0067】
入出金及び入出金予定には、さらに追加の情報が登録できてよい。
図7の例では、入出金の内容が管理の便宜のため登録できるようになっているが、このほかにも、金銭の移動を伴う入出金日時とは別に取引が成立した日、入出金の会計科目といった事項を登録できるようにしておくことで、後から、口座データベース11に登録された情報から会計資料を作成できるようにしておいてもよい。
【0068】
図8は、入出金登録部12による処理の一例を示すフロー図である。オペレータによる操作、又は、タイミング設定部20により設定されたタイミングが到来したことを契機として入出金登録部12のソフトウェアコンポーネントが呼び出され実行される。
【0069】
まず入出金登録部12はステップS101において、入出金登録の実行が、タイミング設定部20により設定されたタイミングが到来したことに基づいてなされたか否かを判別する。予定のタイミングが到来していた場合には、ステップS105へと進み、そうでなければステップS102へと進む。ステップS102では、さらに、ユーザが自動登録を要求しているか否かを判定する。自動登録の指示がなされている場合には、ステップS105へと進み、そうでなければステップS103へと進む。
【0070】
ステップS103以降の処理は、
図7に示したユーザインタフェースを用いた入出金のオペレータによる登録である。ステップS103にてオペレータから必要な情報の入力を受け付け、登録の指示に基づいて、ステップS104にて入出金を指定された口座データベース11に登録し、処理を終える。
【0071】
一方、ステップS101及びステップS102でYの場合には、ステップS105以降の処理へと進み、自動登録を行う。ステップS105では、金融機関サーバ4にAPIを利用して接続し、必要な(又は全ての)口座についての実入出金記録を取得する。この時、これまでに既に実入出金記録を取得した期間の情報については、重複する情報を取得する必要はないため、取得しない、すなわち、金融機関サーバ4に要求しないようにしてもよい。
【0072】
続くステップS106へと進み、取得した実入出金記録のうち、まだ未着目の1つに着目する。最初にステップS106を実行する際には、取得した実入出金記録の全てがまだ未着目である。次にステップS107へと進み、着目中の実入出金記録が、口座データベース11に既に登録されている入出金と一致するかを判定する。一致している場合には、注目中の実入出金記録に係る入出金が、オペレータにより、又は、以前の自動登録により既に口座データベース11に登録されていることを意味するため、特に何もする必要はなく、ステップS109へと進む。ステップS107において一致しない場合は、ステップS108へと進み、実入出金記録に基づいて入出金を口座データベース11に登録する。
【0073】
入出金を登録したかしないかのいずれにせよ、ステップS109へと進み、取得した実入出金記録のうち、まだ未着目のものが残っているかを判定する。未着目の実入出金記録があれば、ステップS106へと戻り、取得した全ての実入出金記録が着目され、入出金を登録するかしないか、いずれかの処理がなされるまで繰り返す。取得した実入出金記録について未着目のものがなく、全ての処理が終了していたならば、入出金登録部12はその処理を終える。
【0074】
図9は、入出金予定登録部13による処理の一例を示すフロー図である。入出金予定登録部13のソフトウェアコンポーネントは、オペレータによる操作を契機として呼び出され実行され、その処理は、
図7に示したユーザインタフェースを用いた入出金予定のオペレータによる登録である。
【0075】
すなわち、ステップS201にてオペレータから必要な情報の入力を受け付け、登録の指示に基づいて、ステップS202にて入出金予定を指定された口座データベース11に登録し、処理を終える。
【0076】
なお、
図4に示した口座データベース11のBの部分に含まれる「振替」は、キャッシュフロー管理システム100により管理される口座間の金銭の移動を意味しており、それは振替元の口座の出金と振替先の口座の入金として把握されるため、入出金の一種である。ただし、実務上は単純な入出金とは区別され、また、オペレータに対となる出金と入金とを別々に入力することを要求するのは不合理であるため、入出金登録部12及び入出金予定登録部13は振替の登録の場合は、
図7に示したものとは異なる専用のユーザインタフェースをクライアント端末3の画面上に示すようにしてよい。
【0077】
図10は振替として入出金の登録を行う際に入出金登録部12及び入出金予定登録部13が共通で使用するユーザインタフェースの一例を示す図である。ここでは、振替元の口座と振替先の口座及び、日時と金額を指定することで、それぞれの口座に係る口座データベース11に対応する入金及び出金が同時に登録されるようになっている。また、
図7に示したものと同様に、現実の振替はもちろん、振替予定を登録することも可能である。
【0078】
図11は、残高調整部15がオペレータに提示するユーザインタフェースの例である。同ユーザインタフェースにおいて、オペレータは、現実の口座の実残高をもとに、残高調整を行う日時、口座及び指定調整額(ユーザインタフェース上では単に「金額」として示されている)を入力し登録する。
【0079】
図12は、残高調整部15による処理の一例を示すフロー図である。残高調整部15のソフトウェアコンポーネントは、オペレータによる操作、又は、タイミング設定部21により設定されたタイミングが到来したことを契機として呼び出され、実行される。
【0080】
まず残高調整部15はステップS301において、残高調整の実行が、タイミング設定部21により設定されたタイミングが到来したことに基づいてなされたか否かを判別する。予定のタイミングが到来していた場合には、ステップS306へと進み、そうでなければステップS302へと進む。ステップS302では、さらに、ユーザが自動登録を要求しているか否かを判定する。自動登録の指示がなされている場合には、ステップS306へと進み、そうでなければステップS303へと進む。
【0081】
ステップS303以降の処理は、
図11に示したユーザインタフェースを用いた入出金のオペレータによる登録である。ステップS303にてオペレータから必要な情報の入力を受け付けたのち、続くステップS304にて口座残高算出部16により、オペレータにより指定された、残高調整すべき日時における該当口座の口座残高を、口座データベース11に基づいて算出し、その差額を金額として算出する。
【0082】
その後ステップS305にて、調整額を算出された金額と共に指定された口座データベース11に登録し、処理を終える。
【0083】
一方、ステップS301及びステップS302でYの場合には、ステップS306以降の処理へと進み、自動登録を行う。ステップS306では、金融機関サーバ4にAPIを利用して接続し、その時点における実残高を取得する。
【0084】
さらに、ステップS307では、指定された口座に係る口座データベース11に基づいて、実残高の取得時点における口座残高を、口座残高算出部16により算出し、実残高との差額を金額として算出する。この実残高の取得時点は、金融機関サーバ4の応答速度や通信環境にも依存するものの、通常は、残高調整部15による処理が実行される時点とは高々数秒程度の差しかないと考えられるため、この差を無視できる場合には、現時点、あるいは、自動登録のタイミングにおける口座残高を算出するようにしてもよい。
【0085】
その後処理をステップS305へと移し、調整額を算出された金額と共に指定された口座データベース11に登録し、処理を終える。
【0086】
図13は残高調整部15の再計算部19による処理の一例を示すフロー図である。再計算部19のソフトウェアコンポーネントは、口座データベース11のBの部分(
図4参照)に含まれる情報に何らかの変更が加えられたことを契機として呼び出され、実行される。ここでいう変更には、新規の何らかの情報の追加、削除のほか、登録内容の変更が含まれる。
【0087】
まず再計算部19はステップS401において、何らかの変更がなされた口座データベース11において、未着目の調整額が残存しているか否かを判定する。ステップS401が最初に実行される時点においては、まだ着目された調整額は存在していないから、調整額の登録が1件もなされていない場合を除き、この判定は肯定となり、ステップS402へと進む。調整額の登録がなされていなければ、この判定は否定となり、再計算部19は処理を終了する。
【0088】
ステップS402では、口座データベース11に含まれる未着目の調整額のうち、最先のもの、すなわち、日時が最も古いものに着目する。そして、続くステップS403において、口座データベース11に加えられた変更の日時が、着目中の調整額の日時より以前であるか否かを判定する。
【0089】
これは、登録されている調整額の日時より以前の情報に変化があると、調整額の金額が変動する可能性があるためである。ステップS403において肯定の場合、ステップS404へと進み、着目中の調整額の金額を再計算し、登録内容を修正する。この再計算は、調整額の登録時点において行ったものと同じ手法でよく、すなわち、着目中の調整額の日時における口座残高を口座残高算出部16により算出し、着目中の調整額に含まれる指定調整額との差額を新たな金額として算出する。なお、この金額の再計算の際には、調整時点における実残高は、すでに指定調整額として口座データベース11に記憶されているため、改めてオペレータに実残高の入力を要求したり、金融機関サーバ4から取得したりする必要はない。
【0090】
金額の再計算がある場合(ステップS404)、ない場合(ステップS403で否定)のいずれの場合であっても、ステップS401へと処理を戻し、未着目の調整額がなくなるまで以上の処理を繰り返す。これにより、自動的に登録されている全ての調整額の金額が正しいものに修正されるため、後から過去の入出金などの情報を入力したり、修正や削除を行ったりした場合であっても、将来にわたる口座残高の推移を正確なものとして把握できることになる。
【0091】
図14は入出金対応付部14がオペレータに提示するユーザインタフェースの例である。オペレータが登録済みの入出金予定を選択することにより、同ユーザインタフェースがクライアント端末3の画面に表示され、入出金予定の登録内容が示される。オペレータは、実際の入出金を表示された入出金予定の登録内容と対照し、誤りがなければ「確認して登録」を選択する。これにより、登録された入出金予定は、登録内容はそのままに、入出金として再登録される。また、入出金の登録内容に変更がある場合には、オペレータは「登録内容の修正」を選択し、必要な修正を加える。この場合には、入出金対応付部14は
図7に示したユーザインタフェースと類似のユーザインタフェースを改めて提示し、必要な情報の入力を受け付ければよい。
【0092】
また、
図15は入出金対応付部14が自動対応付けの際に、対応関係にあると推定される入出金予定と実入出金記録の対応関係の確認をオペレータに要求する際に提示するユーザインタフェースの例である。入出金対応付部14が完全に一致はしないが対応関係にあるものと推定した入出金の登録内容がユーザインタフェースの左側に、金融機関サーバ4より取得した実入出金記録がユーザインタフェースの右側に、対比しやすいよう各項目の位置を揃えて表示されている。
【0093】
オペレータは提示された入出金予定と実入出金記録を確認し、両者が対応するものであれば、「確認して次へ」を選択する。その場合、入出金予定は、実入出金記録と相違する情報を正しい情報(実入出金記録における情報)に改め、入出金として再登録される。また、オペレータは、提示された入出金予定と実入出金記録とが対応せず、異なるものであれば、「両者は異なります」を選択する。この場合、入出金記録に変更はなされず、対応関係が推定された実入出金記録は、新しい入出金として入出金登録部12により口座データベース11に登録される。
【0094】
入出金対応付部14は金融機関サーバ4より取得した実入出金記録のうち、登録済みの入出金予定と対応関係が推定されるものが存在する間はこのユーザインタフェースを繰り返し提示し、オペレータによる確認を要求する。
【0095】
図16は、入出金対応付部14による処理の一例を示すフロー図である。オペレータによる操作、又は、タイミング設定部22により設定されたタイミングが到来したことを契機として入出金対応付部14のソフトウェアコンポーネントが呼び出され実行される。
【0096】
まず入出金対応付部14はステップS401において、対応付けの実行が、タイミング設定部21により設定されたタイミングが到来したことに基づいてなされたか否かを判別する。予定のタイミングが到来していた場合には、ステップS405へと進み、そうでなければステップS402へと進む。ステップS402では、さらに、ユーザが自動登録を要求しているか否かを判定する。自動対応付けの指示がなされている場合には、ステップS405へと進み、そうでなければステップS403へと進む。
【0097】
ステップS403以降の処理は、
図14に示したユーザインタフェースを用いた入出金予定のオペレータによる確認である。ステップS403にてオペレータからの確認及び、必要な修正情報の入力を受け付け、ステップS404にて指定された入出金予定を入出金として再登録し、処理を終える。
【0098】
一方、ステップS401及びステップS402でYの場合には、ステップS405以降の処理へと進み、自動対応づけを行う。ステップS405では、金融機関サーバ4にAPIを利用して接続し、必要な(又は全ての)口座についての実入出金記録を取得する。この時にも、これまでに既に実入出金記録を取得した期間の情報については、重複する情報を取得する必要はないため、取得しない、すなわち、金融機関サーバ4に要求しないようにしてもよい。
【0099】
続くステップS406へと進み、取得した実入出金記録のうち、まだ未着目の1つに着目する。最初にステップS406を実行する際には、取得した実入出金記録の全てがまだ未着目である。次にステップS407へと進み、着目中の実入出金記録が、口座データベース11に既に登録されている入出金予定のいずれかと一致するかを判定する。一致している場合には、注目中の実入出金記録に係る入出金と、一致する入出金予定との対応関係は明らかであるから、ステップS413へと進み、該当する入出金予定を入出金として再登録する。
【0100】
ステップS407において、着目中の実入出金記録が、口座データベース11に既に登録されている入出金予定のいずれとも一致しない場合には、ステップS408へと済み、着目中の実入出金記録に含まれる情報が、口座データベース11に既に登録されている入出金予定のいずれかに含まれる情報と相当程度に共通しており、両者の対応関係が推定されるか否かを判定する。
【0101】
この判定が肯定、すなわち、着目中の実入出金記録と対応することが推定される入出金予定が存在する場合には、ステップS409にて、
図15に示したようなユーザインタフェースを提示して、オペレータによる確認を要求する。なお、ステップS401において、予定したタイミングが到来したことにより処理が実行されている場合には、ステップS409における確認は保留しておき、オペレータがキャッシュフロー管理システム100にアクセスした時点で改めて確認後の処理を実行するようにしておく。
【0102】
続くステップS410において、オペレータの確認結果が、対応関係有であった場合、ステップS413へと進み、該当する入出金予定を入出金として再登録する。これに対し、オペレータの確認結果が、対応関係無であった場合、ステップS411へと進み、入出金登録部12により、着目中の実入出金記録を新規の入出金として登録する。
【0103】
また、ステップS408における判定が否定、すなわち、着目中の実入出金記録と対応することが推定される入出金予定が存在しない場合には、かかる実入出金記録と対応する入出金予定は存在しないと考えられるため、ステップS411へと進み、着目中の実入出金記録を新規の入出金として登録する。
【0104】
ステップS411における新規の入出金登録及びステップS413における入出金としての再登録のいずれがなされたとしても、ステップS412へと進み、取得した実入出金記録のうち、まだ未着目のものが残っているかを判定する。未着目の実入出金記録があれば、ステップS406へと戻り、取得した全ての実入出金記録が着目され、処理がなされるまで繰り返す。取得した実入出金記録について未着目のものがなく、全ての処理が終了していたならば、入出金対応付部14はその処理を終える。
【0105】
さらに
図2に戻り、キャッシュフロー管理システム100は、口座残高の推移をグラフ化するグラフ化部17を備えている。グラフ化部17により示されるグラフは公知の種々のものであってよいが、より、キャッシュフロー管理システム100により管理・把握される口座についての残高の将来にわたる推移の把握を容易にするものとして、次の
図17に例示するグラフが少なくとも含まれるものであってよい。
【0106】
図17は、グラフ化部17により示されるグラフの一例を示す図である。このグラフでは、直交する一方の軸(
図17の例では横軸)を口座残高の推移を示す時間軸、他方の軸(
図17の例では縦軸)を金額としており、時間軸上の任意の1以上の時点における、キャッシュフロー管理システム100により管理・把握される各口座の残高を積み上げ棒グラフとし、各口座の残高の総計を点で示したものである。
【0107】
図17には、口座A、口座B及び口座Cの口座残高の2020年1月から3月までの1月ごとの推移が示されている。この時、時間軸上のそれぞれの時点における各口座残高が正の値である場合には、金額が0を示す軸を起点として、正方向に積み上げ棒グラフとして示す(図中、2020年1月及び2020年2月)。これに対して、ある時点における口座残高が負の値である場合には、負の値を示す口座の残高を、やはり金額が0を示す軸を起点として、負方向に積み上げ棒グラフとして示す(図中、2020年3月における口座Bが相当する)。
【0108】
そして、各口座残高の総計は総合として、グラフ上にこれを示すとともに、
図17の例では、積み上げ棒グラフが示された時点間における各口座残高の総計の推移を実線により示すようにしている。また、各口座残高は、互いに色分けあるいは相異なるハッチングが施され、一瞥して区別できる態様で示される。
【0109】
このように、グラフ化部17は、各口座毎に、特定時点における口座残高が負の場合には、金額が0を示す軸に対して負方向に延びる積み上げ棒グラフとして、口座残高が正の口座と明確に区別できるように示す。これは、
図17に示したグラフを見たオペレータあるいは管理者にとり、2020年3月の時点において、口座Bが残高不足を起こし、資金全体では余裕があるにもかかわらず資金ショートを生じると予測されることを示している。
【0110】
したがって、このグラフを見たオペレータあるいは管理者は、負方向に積み上げられた棒グラフ及び総計をグラフから読み取り、手持ちの資金の余裕や、資金ショートを防ぐための口座間の資金の移動の必要性を直ちに把握することができる。また、各口座を示すグラフから読み取った残高およびその推移をもとに、口座間の資金を移動させる際に、どの口座からどの口座へと資金を移動させるべきか、その意思決定を迅速に行うことができる。
【0111】
さらに、各口座残高の推移を個別に見ていると分かりにくい各口座残高の総計の将来における変化が可視化されるため、資金調達や投資のタイミングなどの意思決定に役立てることができる。これらの効果は、上述した調整額の登録により、将来的な口座残高の正確な把握が可能となることにより、より効果的となる。
複数の前記口座について、時間軸上の少なくとも1以上の時点において、算出される前記口座残高が正の値である場合には0から正方向に積み上げ棒グラフとして、算出される前記口座残高が負の値である場合には0から負方向に積み上げ棒グラフとして、複数の前記口座が互いに区別できる態様で示すとともに、
前記時点における複数の前記口座の算出される前記口座残高の総計をグラフ上に示す、
口座残高の推移をグラフ化する手段を有する、
請求項1〜6のいずれか1項に記載のキャッシュフロー管理システム。
本発明の一側面に係るキャッシュフロー管理システムは、口座の入出金を入出金時点と共に登録する手段と、前記口座の入出金予定を入出金予定時点と共に登録する手段と、任意の時点における口座残高を算出する手段と、特定の時点における口座残高を
本発明の一側面に係るキャッシュフロー管理システムは、さらに、金融機関サーバと通信をする通信部を備え、前記調整する手段は、前記通信部を介して前記金融機関サーバより取得した前記口座の実残高を前記