本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。
[1.構成]
本実施形態に係る支払管理データ生成装置を含む支払管理データ生成システムの構成の一例について、図1を参照して説明する。図1は、本発明の実施形態に係る支払管理データ生成装置を含む支払管理データ生成システムの構成の一例を示すブロック図である。なお、本発明の実施形態に係る支払管理データ生成装置は、支払保留データ管理装置としても機能する情報処理装置の一例である。
図1に示す支払管理データ生成システム1000は、情報処理装置としての支払管理データ生成装置100と、サーバ200と、支払管理データ生成装置100及びサーバ200を通信可能に接続するネットワーク300とを含んでいる。
支払管理データ生成装置100は、複数の会計月にまたがり得る一又は複数の単位債務(単位工事)を生じるプロジェクト(例えば建築工事)について一又は複数の債権者(受注者)への支払内容に関する支払管理データを生成するための情報処理装置であり、例えば市販のデスクトップ型パーソナルコンピュータで構成される。この支払管理データ生成装置100は、例えば、現場の管理部門といった、事業者においてプロジェクトの進捗を管理する部署、特に現場において出来高検収を行う部署(例えば現場監督部門)に1台設置されている。なお、支払管理データ生成装置100は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、PDA(Personal Digital Assistants)、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。また、支払管理データ生成装置100は、支払管理データ生成システム1000内において複数台設置されていてもよく、複数台の支払管理データ生成装置100の間で同期をとることで1台の支払管理データ生成装置100として機能してもよい。支払管理データ生成装置100は、現場の管理部門に設置することに代えて、現場から離れた部署(例えば、支払管理を行う会計部門又は建築業法のコンプライアンスを徹底する法務部門)に設置されてもよい。
支払管理データ生成装置100は、制御部102と、通信インターフェース部104と、記憶部106と、入出力インターフェース部108とを備えている。支払管理データ生成装置100が備えている各部は、任意の通信路を介して通信可能に接続されている。
通信インターフェース部104は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、支払管理データ生成装置100をネットワーク300に通信可能に接続する。通信インターフェース部104は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク300は、支払管理データ生成装置100とサーバ200とを相互に通信可能に接続する機能を有し、例えばインターネットやLAN(Local Area Network)等である。したがって、通信インターフェース部104は、他の部門等が管理している情報処理装置や発注先(例えば取引先)の情報処理装置からの入力情報等を、ネットワーク300を介して又はネットワーク300及びサーバ200を介して受け付けることが可能に構成されているとともに、所定の情報処理装置に対して所定の情報を出力することが可能に構成されている。
記憶部106には、各種のデータベース、テーブル、及びファイルなどが格納される。記憶部106には、OS(Operating System)と協働してCPU(Central Processing Unit)に命令を与えて各種処理を行うためのコンピュータプログラム(本発明のプログラムを含む)が記録される。記憶部106として、例えば、RAM(Random Access Memory)・ROM(Read Only Memory)等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、及び光ディスク等を用いることができる。また、この記憶部106には、本発明のプログラムを実施するために用いられる各種のデータが書き出し/読み出し可能に格納されている。
入出力インターフェース部108には、入力装置112及び出力装置114が接続されている。出力装置114には、モニタ(家庭用テレビを含む)の他、スピーカやプリンタを用いることができる。入力装置112には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。
制御部102は、支払管理データ生成装置100を統括的に制御するCPU等である。制御部102は、OS等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。
さらに図1を参照しながら、記憶部106及び制御部102の構成について詳述する。
記憶部106は、図1に示されるように、プロジェクトマスタ106aと、債権者マスタ106bと、債務設定データ記憶領域106cと、支払管理データ記憶領域106dと、集約データ記憶領域106eとを含む。また、記憶部106は、その他のマスタやデータ記憶領域を備えていてもよい。
プロジェクトマスタ106aは、プロジェクトに関する情報を登録するためのマスタである。債権者マスタ106bは、債権者(取引先、支払先)に関する情報を登録するためのマスタである。
債務設定データ記憶領域106c、支払管理データ記憶領域106d、及び集約データ記憶領域106eは、それぞれ、後述する債務設定データ、債務設定データ、及び集約データを記憶するための領域であり、必要に応じて各データを出力可能に保持する。
制御部102は、図1に示されるように、複数のモジュールを備えている。図1に示す例では、制御部102は、保留解除規制部102Aと、支払管理データ生成部102Bと、出力部102Cとを備えている。支払管理データ生成部102Bは、支払保留データ更新部102bを含む。
保留解除規制部102Aは、支払保留金額の総額を超える支払保留解除金額に関する支払保留解除金額情報が設定されることを規制する保留解除規制手段として機能するモジュールである。支払管理データ生成部102Bは、支払管理データを生成する支払管理データ生成手段として機能するモジュールである。支払保留データ更新部102bは、支払保留データの更新を行う支払保留データ更新手段として機能するモジュールである。出力部102Cは、データを出力する出力手段として機能するモジュールである。各部の機能は、後述する処理内容を実現する機能を含む。
[2.処理]
次に、図1に示す支払管理データ生成システム1000において実行される支払管理データ生成方法を例示的に説明する。
図2は、図1の支払管理データ生成システム1000において、支払管理データ生成装置100が実行する支払管理データ生成方法の処理手順を示すフローチャートである。
この図2に示す処理は、概略的には、複数の会計月にまたがる一又は複数の単位債務(例えば、下請負人に対する単位工事の業務発注による債務)を生じるプロジェクト(例えば、請負事業としての建設工事)について一又は複数の債権者への支払内容に関する支払管理データを生成するというものであり、本処理の大部分は、支払管理データ生成装置100の制御部102において実行される。
なお、以下では、建設工事のプロジェクトについて複数の下請負人に対して単位工事(例えば、基礎工事、電気設備工事等)を発注し、その債務に応じた支払(債権)の一部保留又は当該支払保留の解除を許容しながら会計月単位で行う場合を例に挙げて説明する。ここで、支払の保留は、下請負人の倒産リスクや瑕疵担保を目的として、支払対象金額の一部を保留金として預かる(控除する)場合等に生じる。また、支払保留の解除(取崩)は、通常、下請負人の工事進捗や期間を鑑みて実施される。保留及びその解除は、建設業法を順守して実施される必要がある(例えば、下請負人が同じであっても異なるプロジェクトの単位工事についての支払の保留及びその解除は禁止されており、また、支払の保留を行う場合にあっても長期間にわたる保留が禁止されている)ため、その管理は適切に行われる必要がある。
図2において、まず、ステップS201では、マスタ登録を受け付ける。登録対象のマスタとして、管理対象となる事項に関する情報を登録したマスタ等が用意される。例えば、登録対象のマスタとしては、図1に示した債権者マスタが挙げられる。債権者マスタには、プロジェクトの単位工事の発注先となり得る取引先(下請負人)の取引先名と当該取引先を識別するための識別情報(例えば取引先コード)が登録され、好ましくは、取引先の支払先(入金先)が当該取引先と異なる場合には、当該支払先を特定するための情報がさらに紐づけられた状態で登録される。また、別のマスタとしては、例えば単位工事とその工事内容を登録したマスタを用意してもよい。さらに、後述するステップS202で登録されるプロジェクトマスタをステップS201で併せて登録してもよい。また、用意すべきマスタが既に構築されている場合には、ステップS201において、ユーザ入力に基づいた修正や新規登録等の編集が行われてもよい。また、他のマスタのデータを読み出してコピー又は上書きすることによって新規のマスタが構築されたり既存のマスタの更新が行われたりしてもよく、また、これに代えて、外部記憶装置に記録された他のマスタへ支払管理データ生成装置100をアクセス可能に構成し、アクセス可能になった時点でマスタが新規に構築されたとみなしてもよい。
そして、ステップS202では、プロジェクトマスタの登録を受け付ける。本処理は、通常、新規のプロジェクトの内容が定まった段階で行われる。そのため、既存のプロジェクトマスタが存在する場合には、当該マスタに新規のプロジェクトの内容が新たに追加される。本明細書において、プロジェクトとは、通常、複数の会計月にまたがり得る一又は複数の単位債務(単位事業)を生じる一連の事業をさす。なお、プロジェクト又は単位事業の中止若しくは大幅な工期短縮により、個々の又は全ての単位債務の会計月が単数となってもよい。
図3は、図2のステップS202で登録されるプロジェクトマスタの構成例を模式的に示す図である。
図3に示すプロジェクトマスタには、例えば、プロジェクトのプロジェクト名と当該プロジェクトを識別するためのプロジェクト識別情報(例えば、プロジェクト番号)が少なくとも登録され、さらに、必要に応じて、取引先情報として、取引先の取引先名又は当該取引先を識別するための識別情報が登録される。ここにいうプロジェクトの取引先とは、プロジェクトの主体(代表)であって、例えば、施工主又は発注元(他社)であってもよいし、主体が複数社に及ぶ場合にはその代表となる1社であってもよいし、自社又はその関連会社であってもよい。
続くステップS203では、債権の登録が行われる。ここでいう債権とは、例えば、プロジェクトを構成する一又は複数の単位事業を一又は複数の下請負人(債権者)に発注した場合の発注内容であり、下請負人にとってのプロジェクト完了までの債権(下請負人が受注した業務の遂行に応じて発注元から受け取ることができる金額の総額、すなわち受注金額)であり、発注元(自社)にとってのプロジェクト完了までの債務(発注元が発注した業務の下請負人の遂行に応じて生じる支払金額の総額、すなわち発注金額)である。そのため、発注内容を示す発注データが存在する場合には、当該発注データを読み出すことによって債権の登録が行われてもよいし、発注データ又は発注伝票に基づきユーザが債権を登録してもよい。債権の登録は、プロジェクト識別情報を含むように行われ、かつ、債権者(下請負人)ごとに行われる。これにより、単位事業ごとの債権が登録されることになる。ここで、例えば、プロジェクト識別情報に付加情報(例えば枝番)を付けることで、個々の単位事業に複数の債権者(下請負人)を設定するようにしてもよい。これにより、単位事業ごとにも債務を登録することが可能となる。そして、このステップS203で登録された債権は、債権データとして読み出し可能に保存される。
図4は、図2のステップS203で登録される債権に対応する債権データの構成例を模式的に示す図である。
図4に示す債権データの例では、債権を識別するための債権識別情報(例えば発注番号)と、債権者を識別するための債権者識別情報(例えば取引先名)と、プロジェクト識別番号と、発注金額の総額に関する発注金額情報と、支払保留の設定の有無を示す支払保留有無情報と、支払保留金控除率に関する支払保留金控除率情報とを含んで構成されている。
発注金額情報としては、プロジェクト完了までを管理するため、発注金額の総額が登録される。支払保留有無情報とは、発注者(ここでは債務者)と受注者(ここでは債権者)との契約(取決め)により、支払(債務)の保留が建設業法上許容される期間又はそれよりも短い期間にわたり許容されているかどうかを示す情報をいう。支払保留金控除率とは、債権者へ支払う予定の支払予定金額に対して保留(控除)すべき金額の割合(百分率)をいう。なお、債権データは、支払保留金控除率情報に代えて、支払保留すべき保留金額に関する保留金額情報を含んでいてもよいし、双方のうちの一方を含んでいてもよい。好ましくは、債権識別情報は、債権発生日(発注日)に関する情報を含むことが好ましく、これにより、支払の保留がなされた期間の起算日を管理することができる。
そして、ステップS204では、債務設定が行われるかどうかを判別する。具体的には、図5に示すような債務設定画面が起動されて、ユーザによる入力が開始されるかどうかを判別する。債務設定は、通常、会計月ごとに、支払予定日よりも前に実施され、必要に応じて任意のタイミングで実施されてもよい。ここにいう債務の例は、プロジェクトを構成する単位事業の進捗に関する出来高検収が行われた結果決定された、債権者に対し支払うべき支払対象金額、当該支払対象金額から保留(控除)すべき金額又はその割合、保留金がある場合の当該保留金の一部又は全部につき解除すべき金額又はその割合が挙げられる。支払対象金額は、出来高検収の結果決定された全債権に対する割合に応じた金額であってもよい。ここで、支払対象金額及び保留解除に係る金額をプラスの金額で管理し、保留(控除)に係る金額をマイナスの金額で管理することで、プラスの金額であってもマイナスの金額であっても債務として管理することができる。
ステップS204の判別の結果、債務設定が行われる場合には(ステップS204でYes)、ステップS205の処理に進む。他方、ステップS204の判別の結果、債務設定が行われない場合には(ステップS204でNo)、ステップS205~S206をスキップして、ステップS207以降の判別処理に進む。
ステップS205では、債務設定受付処理を行う。債務設定受付処理は、例えば、図5に示したような入力画面を介して入力された情報(出来高検収の結果決定された情報)のユーザによる入力を受け付けが行われる。
図6は、図2のステップS205において実行される債務設定受付処理の詳細を示すサブルーチンである。
まず、図6のステップS601では、図5に示したような入力画面を介してプロジェクト及び債権者の指定を受け付ける。プロジェクト及び債権者の指定は、各種マスタに登録されている識別番号で行われてもよい。これにより、債務設定対象のプロジェクト識別情報と債権者情報が取得されることになる。
そして、ステップS602では、ステップS601で取得したプロジェクト識別情報と債権者情報に基づき、入力画面上でデフォルト表示を行う。例えば、図4に示した債権データに基づき、発注金額(契約額)や支払保留金控除率に関する情報が入力画面上に表示される。また、前回の会計月の支払金額又は検収金額に関する情報や、前回の会計月まで支払金額の累計も併せて入力画面上に表示することが好ましい。このように入力画面にさまざまな情報を表示することで、ユーザは、前回までの金額情報と比較しながら当月分の債務設定を行うことができるようになる。
続いて、ステップS603では、支払対象金額情報の入力を受け付ける。支払対象金額(以下、「支払対象金額(a)」ともいう)とは、例えば、当月分の出来高検収の結果決定された支払対象金額(当月検収額)である。通常、下請負人による単位事業の遂行には会計月ごとの進捗があることから、支払対象金額はプラスの金額である。また、出来高検収の結果、進捗がないと認められた場合、支払対象金額は通常ゼロである。ただし、例えば、取り決めや出来高検収時の交渉(例えば、発注元の都合による単位工事の遅延)等に応じて、支払対象金額として、ゼロ未満の金額、すなわちマイナスの金額を控除金額として入力することも可能である。そして、支払対象金額情報の入力を受け付けると、支払保留金控除率に基づき、支払保留金情報が入力画面にデフォルト表示される。ここで表示される支払保留金情報が示す保留金は、例えば、支払対象金額に支払保留金控除率が示す割合を乗算することにより算出される。支払保留金控除率が設定されていない場合には、保留金はゼロとしてデフォルト表示される。
次に、ステップS604では、ユーザによる入力の結果、保留金に変更があるかどうかを判別する。保留金は、ステップS603の処理の結果デフォルト表示された保留金である。ステップS604の処理の結果、保留金に変更があった場合又はデフォルト表示の結果、保留金にゼロを超える金額がセットされている場合(ステップS604でYes)、ステップS605以降の処理に進んで、変更後の保留金又はデフォルト表示の保留金(以下、これら保留金をまとめて「保留金(b)」ともいう)に関するエラーチェックを行う。他方、保留金に変更がない場合又は保留金にゼロがセットされている場合(ステップS604でNo)、ステップS607の処理に進む。
保留金(b)に関するエラーチェックに際し、まず、ステップS605及びS606では、ステップS603で受け付けた支払対象金額(a)がゼロを超える金額であるかどうか、並びに、ステップS604で取得した保留金(b)が支払対象金額(a)以下であるかどうかを判別する。これら判別処理により、支払対象金額(a)がプラスの金額でもないのに新たに保留金を設定するものでないこと、また、支払対象金額(a)がプラスの金額であっても当該プラスの金額を上回る保留金が設定するものでないこと、すなわち、設定された保留金(b)の妥当性が確認される。
ステップS605の判別の結果、支払対象金額(a)がゼロを超える金額でない場合には(ステップS605でNo)、保留金(b)としてゼロしか入力できないように規制すべく、まず、ステップS620で保留金(b)がゼロであるかどうかを判別し、斯かる判別の結果、保留金(b)がゼロでない場合には(ステップS620でNo)、保留金(b)につきゼロへの変更入力を促すべく、第1のエラー表示(例えば、「0のみ入力可能です」の旨の警告表示)を行い(ステップS621)、ステップS603の処理に戻って、支払対象金額(a)及び保留金(b)の一方又は双方が変更されるのを待機する。ステップS620の判別の結果、保留金(b)がゼロである場合には(ステップS620でYes)、ステップS606の処理に進む。
ステップS606の判別の結果、保留金(b)が支払対象金額(a)以下でない場合には(ステップS606でNo)、支払対象金額(a)を上回る保留金(b)が入力されないように規制すべく、ステップS630で第2のエラー表示(例えば、「当月検収額を超える金額は指定できません」の旨の警告表示)を行って、ステップS603の処理に戻り、支払対象金額(a)及び保留金(b)の一方又は双方が変更されるのを待機する。
そして、ステップS605及びS606において、ステップS604で設定された保留金(b)の妥当性が確認されたら(ステップS605でYesかつステップS606でYes)、ステップS607へ進む。
ステップS607~S609では、保留解除金に関するエラーチェックを行う。具体的には、まず、ステップS607において、保留解除金としてゼロでない金額の入力がなされているかどうかを判別する。ステップS607の判別の結果、保留解除金の入力がなされていない場合又は保留解除金にゼロがセットされている場合には(ステップS607でNo)、ステップS610に進む。他方、ステップS607の判別の結果、保留解除金の入力がなされている場合には(ステップS607でYes)、入力がなされた保留解除金(以下、「保留解除金(c)」ともいう)を取得し、ステップS608に進む。
ステップS608では、支払保留取崩可能額(以下、「支払保留取崩可能額(d)」ともいう)がゼロを上回る金額であるかどうか(すなわち支払保留金に残高があるかどうか)を判別する。支払保留取崩可能額とは、支払保留金額から取崩を行うことができる金額の上限をいい、通常は、当月の支払保留金額の総額である。支払保留取崩可能額は、支払処理が行われるたびに変動するので、後述する処理により更新がなされるようになっている。
ステップS608の判別の結果、支払保留取崩可能額がゼロを上回る金額である場合には(ステップS608でYes)、取崩対象の保留金額が存在することになるので、ステップS609へ進む。続くステップS609では、ステップS607で取得した保留解除金(c)が支払保留取崩可能額(d)以下の金額であるかどうかを判別する。ステップS609の判別の結果、保留解除金(c)が支払保留取崩可能額(d)以下の金額である場合には、保留解除金(c)が、取崩対象の保留金額の上限を超えるものではないことが確認されたことになるので、ステップS610に進む。
他方、ステップS608の判別の結果、支払保留取崩可能額がゼロ上回る金額でない場合には(ステップS608でNo)、支払保留金額に取崩対象となる残高がないことになるので、保留解除金(c)としてゼロしか入力できないように規制すべく、まず、ステップS640で保留解除金(c)がゼロであるかどうかを判別し、斯かる判別の結果、保留解除金(c)がゼロでない場合には(ステップS640でNo)、保留解除金(c)につきゼロへの変更入力を促すべく、第3のエラー表示(例えば、「0のみ入力可能です」の旨の警告表示)を行い(ステップS641)、ステップS607の処理に戻って、保留解除金(c)が変更されるのを待機する。ステップS640の判別の結果、保留解除金(c)がゼロである場合には(ステップS640でYes)、ステップS609の処理に進む。
ステップS609の判別の結果、保留解除金(c)が支払保留取崩可能額(d)以下の金額でない場合には(ステップS609でNo)、支払保留取崩可能額(d)を上回る保留解除金(c)が入力されないように規制すべく、ステップS650で第4のエラー表示(例えば、「当月保留金解除が保留金以上の金額です」の旨の警告表示)を行って、ステップS607の処理に戻って、保留解除金(c)が変更されるのを待機する。
そして、ステップS608及びS609において、ステップS607で取得した保留解除金(c)の妥当性が確認されたら(ステップS608でYesかつステップS609でYes)、ステップS610へ進む。
そして、ステップS610では、ステップS603で取得した支払対象金額(a)、ステップS604で取得した保留金(b)、及びステップS607で取得した保留解除金(c)に関する情報を債務設定情報として取得する。なお、債務設定情報の各々は、金額がゼロであることを示す情報であってもよい。このステップS610の処理は、例えば、図5に示した入力画面において図示しない「確定」ボタンの押下により実行される。そして、ステップS610で取得した各債務設定情報は、例えば債務設定データとして読み出し可能に保存される。そして、図6に示した処理を完了して、図2の処理にリターンして、ステップS206の処理に進む。
図7は、図6のステップS610で生成される債務設定データの構成を模式的に示す図である。
図7に示す債務設定データの例は、出来高検収の結果を示す出来高検収データである。図7に示すように、出来高検収データは、出来高検収を識別するための検収識別情報(例えば検収番号)と、債権識別情報(例えば発注番号)と、計上日(例えば出来高検収の実施日)に関する情報と、支払予定日(例えば翌月又は翌々月の会計日)に関する情報と、支払先に関する情報と、プロジェクト識別情報、支払対象金額(検収金額)に関する情報とを含み、さらに、図4に示した債権設定データに含まれる一部の情報とを含む。図4に示した債権設定データに含まれる一部の情報としては、支払保留有無情報、支払保留金控除率情報などがあり、これらの情報は、図4に示した債権設定データから取得してもよい。したがって、出来高検収データが存在する場合には、ステップS205の処理に代えて、出来高検収データから読み出した情報から、各債務設定情報を取得するようにしてもよい。又は、各債務設定情報を出来高検収データに反映させるべく、例えば、保留解除金(c)に関する情報を出来高検収データに追加してもよい。
図2に戻り、ステップS206では、支払管理データ生成処理が行われる。支払管理データ生成処理では、ステップS205(図6)の債務設定受付処理の結果取得した支払対象金額(a)、保留金(b)及び保留解除金(c)に関する債務設定情報を用いて支払管理データが生成される。図8は、図2のステップS206の支払管理データ生成処理の詳細を示すサブルーチンである。
図8において、まず、ステップS801では、支払対象金額がゼロ以上であるかどうかを判別する。該判別の結果、支払対象金額がゼロ以上であれば(ステップS801でYes)、ステップS802で内訳区分「0」のレコード(以下、「通常レコード」ともいう)を生成し、ステップS804へ進む。なお、支払対象金額がゼロの場合には、通常レコードの生成を省略してもよく、これによりデータ容量を削減することができる。他方、該判別の結果、支払対象金額がゼロ未満すなわちマイナスである場合には(ステップS801でNo)、ステップS803で内訳区分「1」のレコード(以下、「控除レコード」ともいう)を生成し、ステップS804へ進む。内訳区分については後述する。ステップS802及びS803で生成されるレコードは、本処理で生成される支払管理データの一部を構成するレコードである。
図9は、図2のステップS802及びS803で生成されるレコードを含む支払管理データの構成例を模式的に示す図である。
図9に示される支払管理データは、債権者への債務履行のための支払予定金額に関する支払予定金額情報を含むレコードで構成される。支払予定金額は、プラス(出金)であってもマイナス(控除)であってもよい。図9に示すように、支払管理データは、支払予定金額情報のほかに、各レコードを識別するための識別情報(例えば、連番で付与される支払予定番号)、支払予定日に関する支払予定日情報、取引先の支払先に関する情報(例えば、支払先名)、債務設定情報に含まれる債務を識別するための債務識別情報(例えば、元伝票番号)、各レコードの区分(分類)を特定するための分類情報(例えば、内訳区分又はその区分名)及び支払予定金額の支払状態情報(例えば、支払状態名)を含んで構成される。支払予定日情報には、通常、出来高検収データにおける計上日に対して予め設定された会計月(例えば、翌会計月又は翌々会計月)の指定日がセットされる。ただし、後述するように、支払予定日情報として、計上予定日が定まっていないことを示す計上不可情報(例えば未来日付)をセットすることも可能である。また、債務識別情報として用いることが可能な元伝票番号は、出来高検収データにおける元伝票番号である。支払管理データが上述した情報を含むことにより、各レコードの支払予定金額について、その支払予定日や支払状態を把握することが可能となる。支払状態情報は、支払済及び未支払の一方から選択される。各レコードが生成された時点においては、支払状態情報として未支払がセットされ、各レコードの支払予定金額が支払予定日に支払を完了することで支払状態情報として支払済がセットされるようになっている。
ここで、内訳区分は、支払管理データにおいて、各レコードの区分(分類)を特定するための分類情報として各レコードにセットされる。内訳区分「0」は、支払対象金額(a)がプラスのレコード(通常の支払に関するレコード)を特定するための分類情報に該当する。したがって、ステップS802で生成される内訳区分「0」の通常レコードは、予め設定された会計月の債務履行対象(出金対象)となるレコードである。内訳区分「1」は、支払対象金額(a)がマイナスのレコード(控除に関するレコード)を特定するための分類情報に該当する。したがって、ステップS803で生成される内訳区分「1」の控除レコードは、予め設定された会計月の控除対象となるレコードである。内訳区分「2」及び「3」は、後述するように、保留金の保留状態を示す保留状態情報として機能する。そのため、支払管理データが保留状態情報を含むことにより、各レコードの保留金について、その保留状態を速やかに把握することが可能となり、また、後述するように集約データの生成を容易に行うことができるようになる。
続いて、ステップS804では、保留金レコードの生成が必要であるかどうかを判別する。具体的には、保留金(b)がゼロ超であるかどうかを判別する。ステップS804の判別の結果、保留金レコードの生成が必要でない場合には(ステップS804でNo)、以下に説明するステップS805の処理をスキップして、ステップS806へ進む。
ステップS804の判別の結果、保留金に関するレコードの生成が必要である場合には(ステップS804でYes)、ステップS805に進んで、内訳区分「1」のレコード(すなわち控除に関するレコード)と、内訳区分「2」のレコード(以下、「支払保留レコード」ともいう)の1対のレコードを生成し、ステップS806へ進む。なお、図6を用いて説明したように、支払対象金額(a)がマイナスの場合には、保留金(b)にはゼロがセットされるため、ステップS804において、保留金レコードの生成が必要であると判断されないようになっており、これにより、支払管理データにおいて、マイナスの支払対象金額(a)に由来する控除レコードと、保留金(b)に由来する控除レコードとが併存しないようになっている。
ここで、ステップS805で生成される内訳区分「2」の支払保留レコードについて説明する。内訳区分「2」の支払保留レコードは、支払が保留状態にあることを示すレコードである。ステップS805では、保留金(b)に由来して控除レコードが生成されるが、控除レコードの支払予定金額情報が示すマイナスの金額は、支払予定日が到来することにより保留金として積み上げられることになる。そこで、ステップS805では、保留金として積み上げられる金額(すなわちプラスの金額)を支払予定金額情報として登録した支払保留レコードが控除レコードと対となるように生成される。したがって、内訳区分「2」の支払保留レコードに含まれる支払予定金額情報が示すプラスの金額は、支払先への出金予定額ではなく、支払保留取崩可能額へ積み上げる予定の加算額に該当する。
また、ステップS806では、支払の保留解除金(c)があるかどうかを判別する。具体的には、保留解除金(c)がゼロ超であるかどうかを判別する。
ステップS806の判別の結果、保留解除金(c)がある場合には(ステップS806でYes)、ステップS807~S814において、保留解除金(c)に基づき支払保留レコードの更新処理が行われる。この支払保留レコードの更新の結果、内訳区分「3」のレコード(以下、「支払保留解除レコード」ともいう)が生成される。支払保留レコードの更新処理の詳細については、後述する。そして、支払保留レコードの更新処理が完了したら、本処理を終了して図2へリターンして、ステップS207へ進む。
他方、ステップS806の判別の結果、保留解除金(c)がない場合には(ステップS806でNo)、ステップS807~S814の支払保留レコードの更新処理をスキップして、本処理を終了して図2へリターンして、ステップS207へ進む。
図8を用いて説明したように各レコードが追加されて支払管理データが生成されると、図2に戻り、ステップS207では、問合せ回答書又は支払通知書が必要であるかどうかを判別する。具体的には、ユーザによる必要書面の指示入力を待機する。ここで、問合せ回答書は、出来高検収を受けた債権者が、支払予定日までの間に、債務者に対して、当月又は翌月の支払予定金額(債権者にとっては入金見込金額)について問合せを行った場合に債務者が回答するための書面であり、この書面を受領することにより、債権者は、支払予定日前に、支払予定金額に出来高検収の結果が反映されていることを確認することができる。支払通知書は、債務者が支払(出金)を行う金額を債権者に対して通知するための書面であり、これにより、債権者が債務者に対して問合せを行う手間を省くことができる。
ステップS207の判別の結果、問合せ回答書又は支払通知書が必要である場合には(ステップS207でYes)、ステップS221~S223で必要書面の作成処理を行い、ステップS208に進む。必要書面の作成処理については、後述する。他方、ステップS207の判別の結果、問合せ回答書又は支払通知書が必要でない場合には(ステップS207でNo)、ステップS221~S223で必要書面の作成処理をスキップして、ステップS208に進む。
次に、ステップS208では、支払管理データに含まれる各レコードの支払予定金額につき、支払予定日が到来して、支払が完了したかどうかを判別する。支払の完了は、例えば、ファームバンキング(FB)による振込完了データを読み出して、支払管理データに含まれる情報(支払予定番号、支払予定日、支払先、支払予定金額等の情報)を検索することにより把握することができる。そして、ステップS208の判別の結果、支払が完了していない場合、例えば支払予定日がまだ到来していない場合には(ステップS208でNo)、ステップS204に戻って、別の債務設定の受け付けを待機する。他方、支払が完了されたレコードがあった場合には(ステップS208でYes)、ステップS209で当該レコードの支払状態情報に支払済をセット(すなわち未支払を支払済に更新)し、ステップS210の処理に進む。図10には、図9に示した支払管理データの一部のレコードの支払状態情報が、図2のステップS209の処理の結果、支払済に更新された例が示されている。
ステップS210では、支払管理データに未支払のレコードがあるかどうかを判別する。未支払のレコードは、通常、支払保留レコードである。これは、先述のとおり、支払保留レコードの支払予定金額は、支払先への入金額(振込額)ではないからである。ステップS210の判別の結果、未支払のレコードがある場合には(ステップS210でYes)、ステップS211で、取引先(支払先)ごとに未支払レコードの集計を行って、ステップS212で、支払保留のレコードの集計結果に基づき、支払保留取崩可能額を更新する。したがって、支払保留取崩可能額は、支払完了がなされるたびに更新されるので、支払保留取崩可能額を超える金額の保留解除(取崩)が実施されることを抑止することができる。
図11は、図2のステップS211及びS212の処理を説明するために用いられる図であり、図11(a)は、図2のステップS211で集計対象となる1群のレコードの一例を示しており、図11(b)は、図2のステップS212の処理の結果生成される支払保留取崩可能額を管理するためのデータの構成例を模式的に示す図である。図11(a)に示した1群のレコードは、図10における未支払のレコードで構成されている。図11(b)に示すように、図2のステップS212の処理が行われるたびに保留取崩可能額を管理するためのデータを生成・更新することが好ましく、これにより、任意のタイミングで読み出し可能に保存することができる。
そして、ステップS212で支払保留取崩可能額の更新がなされると、ステップS204の処理に戻り、別の債務設定、必要書面の要否、支払完了の各判別処理を待機する。他方、ステップS210の判別の結果、未支払のレコードがない場合には(ステップS210でNo)、全てのレコードにつき支払が完了したことになるので、図2に示した処理を完了する。
なお、上述した図2、図6及び図8を用いた説明において、例えば、マスタ登録(メンテナンス)(ステップS201)、プロジェクト登録(ステップS202)、債権登録(ステップS203)、債務設定(ステップS204及び図6)、問合せ回答書又は支払通知書の作成(ステップS221~S223)は、任意のタイミングで実行されてもよく、つまり割込み処理可能な処理である。また、図8のステップS807~S814の支払保留レコードの更新処理は、支払保留データ管理装置として機能する他の情報処理装置において実行してもよい。
また、上述した説明では、1月に実施された出来高検収の結果が反映された支払管理データを新たに生成し、2月に支払保留レコード以外の支払完了する例を説明したが、翌月以降も継続して、同様の処理を適用することができる。
図12は、図7に示した出来高検収データとは別の出来高検収データであって、翌月の出来高検収の結果の一例を模式的に示す図である。図13は、図12に示す出来高検収データに基づき生成される支払管理データを模式的に示す図である。ただし、図13に示す支払管理データからは、便宜上、保留解除レコードは除かれている。このように、翌月についても、上述した説明と同様に支払管理データが生成される。
ここで、図12に示す出来高検収データに示すように、支払保留取崩額(c)が設定された場合、すなわち、図8のステップS806で支払保留解除があると判断された場合(ステップS806でYes)について、図8を用いて説明する。
図8において、支払保留解除があると判断された場合(ステップS806でYes)、支払保留解除レコードを生成するとともに(この時点で内訳区分は付加されていなくてもよく、また、支払予定日は任意の日付であってもよい)、既存の支払管理データの中から、対応する一又は複数の支払保留レコードの読み出しを行う(ステップS807)。対応する支払保留レコードとは、生成した支払保留解除レコードに含まれる発注番号、支払先及びプロジェクト番号が共通する支払保留レコード(以下、「対象支払保留レコード」ともいう)である。図14は、図12に示す出来高検収データに基づき、図8のステップS807の処理の結果生成された支払保留解除レコードの一例を模式的に示す図である。図15は、図8のステップS807の処理の結果読み出された1群の対象支払保留レコードを模式的に示す図である。
続くステップS808では、ステップS807で読み出した1群の対象支払保留レコードの各々に、予め設定された複数の優先度(例えば、優先度の高い順に設定された「1」、「2」、「3」)の中から選ばれた優先度を設定する。図16は、図15に示した1群の対象支払保留レコードに優先度が付与された状態を模式的に示す図である。
優先度は、保留金額の計上日(出来高検収データにおける計上日)が近い順、又は、保留解除金額が保留金額の全額に近い順、又は、それらの組み合わせにより決定される順序を含み、さらに、支払予定日番号が示す数字が近い順を組み合わせて決定される順序であってもよい。例えば、対象支払保留レコードの保留金額の計上日(出来高検収データにおける計上日)が近い場合、対象支払保留レコードの支払予定金額(すなわち保留金額)が支払保留解除レコードの保留解除金額と同額又はそれ未満の金額である場合に、対象支払保留レコードに優先度「1」が設定される。また、対象支払保留レコードの保留金額の計上日(出来高検収データにおける計上日)が近くない場合(例えば、当月ではなく前月の出来高検収データに基づき生成した支払保留レコード)には、当該対象支払保留レコードに優先度「2」が設定される。
続いて、ステップS809では、優先度が設定された1群の対象支払保留レコードの中から優先度が高い一の対象支払保留レコードを選択する。同じ優先度が設定された複数の対象支払保留レコードがある場合には、任意の又は計上日若しくは保留金額が近い一の対象支払保留レコードが選択される。
そして、対象支払保留レコードが選択されると、当該対象支払保留レコード(内訳区分「2」)に含まれる保留金額情報に代えて、設定された保留解除金額情報がセットされ、かつ、保留状態情報として支払保留解除を示す情報(内訳区分「3」)がセットされた支払保留解除レコードを生成する(ステップS810)。さらに、この支払保留解除レコードには、支払予定日情報として、保留解除金額情報に対応する保留解除の計上日又は計上予定日に関する日付情報がセットされる。したがって、対象支払保留レコードには、通常、支払予定日情報として計上不可情報(未来日付)がセットされているのとは異なり、支払保留レコードには、支払予定日情報として実際の支払予定日に関する情報がセットされる。
図17は、図8のステップS809において、図16に示す1群の対象支払保留レコードの中から、3番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図17(a)は、選択された対象支払保留レコードを模式的に示し、図17(b)は、図8のステップS810で、図17(a)の対象支払保留レコードに対応して生成される支払保留解除レコードを模式的に示す図である。
続いて、ステップS811では、支払保留解除レコードの保留解除金額と対象支払保留レコードの保留金額の間にゼロ超の差額があるかどうかを判別する。ステップS811の処理の結果、ゼロ超の差額がない場合、つまり同額である場合、以下に説明するステップS812をスキップして、ステップS813の処理に進む。図17に示した例では、対象支払保留レコードの支払予定金額と、支払保留解除レコードの支払予定金額は同額であるから、ステップS812の処理は行われない。
他方、ステップS811の処理の結果、ゼロ超の差額がある場合、すなわち保留金額が保留解除金額の一部である場合(ステップS811でYes)、ステップS812で、保留解除金額から前記保留金額の差額を保留金額情報として含む支払保留レコード(以下、「差額支払保留レコード」ともいう)を新たに生成する。この差額支払保留レコードには、本実施形態では、内訳区分「2」がセットされる。このように差額支払保留レコードが生成されることにより、対象支払保留レコードの支払予定金額と、一対の支払保留解除レコード及び差額支払保留レコードの支払予定金額の合計とが同額となる。
図18は、図8のステップS809において、図16に示す1群の対象支払保留レコードの中から、1番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図18(a)は、選択された対象支払保留レコードを模式的に示し、図18(b)は、図8のステップS810で、図18(a)の対象支払保留レコードに対応して生成される支払保留解除レコードと、図8のステップS812で、差額に応じて生成される支払保留レコードとを模式的に示す図である。図19は、図8のステップS809において、図16に示す1群の対象支払保留レコードの中から、2番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図19(a)は、選択された対象支払保留レコードを模式的に示し、図19(b)は、図8のステップS810で、図19(a)の対象支払保留レコードに対応して生成される支払保留解除レコードと、図8のステップS812で、差額に応じて生成される支払保留レコードとを模式的に示す図である。図18及び図19にも示されるように、対象支払保留レコードの支払予定金額と、一対の支払保留解除レコード及び差額支払保留レコードの支払予定金額の合計とは同額である。
ステップS813では、対象支払保留レコードの削除を行う。図17~図19に示した例では、図17(a)に示す対象支払保留レコード、図18(a)に示す対象支払保留レコード及び図19(a)に示す対象支払保留レコードが削除される。これにより、支払保留解除レコードを生成したことにともなう支払保留レコードの更新(対象支払保留レコードの削除及び差額支払保留レコードの生成)が完了する。そして、ステップS814の処理に進み、他の対象支払保留レコードがある場合には(ステップS814でYes)、ステップS809に戻って、他の対象支払保留レコードを選択して、上述したステップS810~S814の処理を行う。そして、他の対象支払保留レコードがなくなった場合には(ステップS814でNo)、本処理を完了して、図2にリターンし、ステップS207以降の処理を行う。
ここで、2つの対象支払保留レコードの支払予定金額が1つの支払保留解除レコードの支払予定金額と同額となる場合の例外的な処理について、図20~図22を用いて説明する。
図20は、例示的な出来高検収データを模式的に示す図である。図21は、図20の出来高検収データに基づき読み出された2つの対象支払保留レコードであって優先度が設定されたものを模式的に示す図である。図22は、図21に示す2つの対象支払保留レコードの更新を説明するための図であり、図22(a)は、更新前の2つの対象支払保留レコードを模式的に示し、図22(b)は、図22(a)の2つの対象支払保留レコードに対応して更新後に生成される2つの支払保留解除レコードを模式的に示す図である。
図20~図22に示す例では、出来高検収データにおける支払保留取崩額「31,000」が、更新前に存在した支払予定金額「1,000」及び「30,000」の2つの対象支払保留レコードに応じて、更新後には、支払保留解除金額「1,000」と、支払保留解除金額「30,000」の2つの支払保留解除レコードとして生成されている。上述した図8の説明によれば、優先度に基づき、2つの対象支払保留レコードを順次更新することになるため、中間的には、支払保留解除金額「1,000」の支払保留解除レコードと、支払予定金額「30,000」の差額支払保留レコードが生成されるものの、前者の差額支払保留レコードも対象支払保留レコードとして選択される結果、最終的には、支払保留解除金額「30,000」の支払保留解除レコードが生成し、差額支払保留レコードは削除されることとなり、結果的に、図22(b)に示す2つの支払保留解除レコードが生成される。そこで、上述した図8の処理に代えて、中間的に生成されうる差額支払保留レコードに対応する優先度が低い対象支払保留レコード(図21に示す2番目の優先度「2」のレコード)において、支払予定日及び内訳区分を変更することにより、最終的に生成されうる支払保留解除レコード(図22(b)に示す2番目のレコード)を生成するように処理を行ってもよい。これにより、更新処理に係る負荷を軽減することができる。
続いて、図2のステップS221~S223で実行される必要書面の作成処理について説明する。この処理は、ステップS207の判別の結果、必要書面(問合せ回答書又は支払通知書)の作成が必要な場合(ステップS207でYes)、具体的にはユーザにより必要書面の作成が指示された場合に実行される。
まず、ステップS221では、支払管理データに基づき、必要書面に応じた集約データを所定のフォーマットで生成する。集約データとは、支払管理データの中から、指定された債権者のレコードを集約したデータである。
続いて、ステップS222では、ステップS221で生成した集約データの出力を行うかどうか判別する。具体的には、ユーザによる出力指示を待機する。ステップS222の判別の結果、集約データの出力を行わない場合には(ステップS222でNo)、必要に応じて集約データを読み出し可能に保存し、ステップS208以降の判別処理を行う。他方、ステップS222の判別の結果、集約データの出力を行う場合には(ステップS222でYes)、ステップS223で集約データの出力を行い、その後、ステップS208以降の判別処理を行う。
ここで、集約データの出力とは、印刷、無線又は有線を介した送信及び所定の表示画面への表示を含む。集約データは出力されることにより、当該集約データに応じて予め設定された帳票データとして出力されることになる。帳票データとしては、問合せ回答書又は支払通知書に対応する帳票データが挙げられる。ただし、帳票の名称は任意である。そのため、問合せ回答書に対応する帳票データを、例えば未払金集約データと称してもよいし、支払通知書に対応する帳票データを、例えば支払保留金集約データと称してもよい。すなわち、支払管理データから集約データを生成することにより、任意の管理データ又は帳票データを出力することが可能である。本実施形態では、支払管理データが、支払保留状態情報及び支払状態情報を含むので、それらの一方又は双方を含む集約データを生成することが可能である。そのような情報を含む集約データを生成することにより、ユーザは出力することでそれら情報の一覧性を向上させることができる。例えば、支払保留解除に関する情報を含む帳票は、それを受領した債権者(単位事業の受注者)にとって単位事業の出来高が評価されたこと又はその進捗が良好であることを視覚的に把握できることになるという点で、支払保留解除金額が単に支払予定金額に上乗せされた従来の帳票に比べて好ましい。また、支払済又は未支払に関する情報を含む帳票は、例えば、管理者が支払(振込)の進捗管理を行ううえで利点がある。
以上詳細に説明したように、図2、図6及び図8に示した一連の処理によれば、支払管理データ生成装置100は、債権設定データ(例えば所定の入力画面を介して受け付けた情報、又は、出来高検収データ)に基づいて(ステップS205)、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを自動的に生成する(ステップS206)(支払管理データ生成手段)。ここで、支払管理データは、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を少なくとも含み、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る。そして、債務設定データは、前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含んでおり、当該債務設定データが、さらに、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードが追加されて(ステップS805又はステップS810)、前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データが生成される。したがって、支払管理データには支払保留状態情報が含まれているので、ユーザにとっては、支払保留状態情報を個別に又は別途に管理する必要がなくなり、債権者への支払内容の管理の利便性を向上させることができる。
さらに利便性を向上させるために、支払管理データに、さらに、前記単位債務を識別する情報(例えば、プロジェクト番号に枝番等の付加情報)を含ませることが可能であり、これにより、単位債務(単位事業)ごとの管理も行うことができる。また、さらに利便性を向上させるために、支払予定データ、前記支払管理データ及び集約データに、前記支払予定金額情報に対応する支払予定金額、前記支払保留金額情報に対応する支払保留金額及び前記支払保留解除金額情報に対応する支払保留解除金額についての支払済若しくは未支払を示す支払状態情報を含ませることが可能であり、支払状態も管理することが可能である。
また、さらに利便性を向上させるために、支払管理データに基づき、前記債権者のレコードを集約した集約データ(後述する未払金集約データや支払保留金集約データ)を所定のフォーマットで生成することも可能であり(ステップS221)、これにより、さまざまな出力結果を得ることが可能となる(ステップS223)(出力手段)。
また、図8に示したステップS806~S814の一連の支払保留レコードの更新処理によれば、支払保留データ管理装置としても機能する支払管理データ生成装置100は、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払の支払保留金額に関する支払保留データを管理するに際し、前記債権者への支払を保留する支払保留金額の一部又は全部に対する支払保留解除金額又は支払保留金額の総額に対する支払保留対象割合に関する支払保留解除金額情報が設定された場合に、前記支払保留データにおいて当該支払保留金額に関する支払保留金額情報を含む対象支払保留レコードの更新を行う(支払保留データ更新手段)。支払保留データの更新に際し、前記対象支払保留レコードに含まれる前記支払保留金額に関する支払保留金額情報に代えて、前記設定された支払保留解除金額情報がセットされ、かつ、支払保留状態情報として支払保留解除を示す情報がセットされた支払保留解除レコードが少なくとも自動的に生成される(ステップS810)。したがって、ユーザは、保留金の一部又は全部の解除が生じた場合に、その保留解除金の管理の利便性を向上させることができる。
ここで、上述のとおり、支払管理データ生成装置100は、支払保留データ管理装置としても機能するので、支払保留データ管理装置としての機能(例えば、ステップS806~S814の一連の支払保留レコードの更新処理を実行する機能)を他の情報処理装置が実現してもよい。すなわち、支払保留データ管理装置は、単独の情報処理装置として提供されてもよい。この場合、対象支払保留レコード及び支払保留解除レコードは、支払保留状態情報を含んでいなくてもよい。支払保留データ管理装置が提供されるのと同様に、支払保留データ管理方法、及び支払保留データ管理プログラムも提供される。
さらに利便性を向上させるために、前記支払保留解除レコードに、前記支払保留解除金額情報に対応する支払保留解除の計上日又は計上予定日に関する日付情報がセットされる(ステップS810)。
さらに利便性を向上させるために、前記支払保留解除金額が前記支払保留金額の一部である場合には(ステップS811でYes)、前記支払保留金額から前記支払保留解除金額の差額を支払保留金額情報として含む差額支払保留レコードが新たに生成される(ステップS812)。
さらに利便性を向上させるために、前記差額支払保留レコードに、支払保留解除の計上日又は計上予定日が定まっていないことを示す計上不可情報がセットされる(ステップS812)。
また、支払保留データの更新に際し、前記支払保留データに、前記対象支払保留レコードが一つ又は複数存在する場合には、当該1群の対象支払保留レコードの各々に、予め設定された複数の優先度の中から選ばれた優先度が設定される。これにより優先度の高い対象支払保留レコードから処理が進められることになる。ここで、前記複数の優先度は、前記支払保留金額の計上日が近い順、又は、前記支払保留金額が前記支払保留解除金額の全額に近い順、又は、それらの組み合わせにより決定される順序を含む。これにより、効率的に処理を進めることができる。
また、前記支払保留データの更新が完了した場合に、前記対象支払保留レコードが削除される(ステップS813)。これにより、データ容量を削減することができる。
また、図6の処理によれば、前記支払保留金額の総額を超える支払保留解除金額に関する支払保留解除金額情報が設定されることが規制される(ステップS609でNo及びステップS650)(保留解除規制手段)。これにより、適正な支払保留解除金額の支払保留解除レコードについて図8に示したステップS806~S814の一連の支払保留レコードの更新処理を実行することができる。
なお、上述した説明では、前記プロジェクトが複数の単位事業を含む請負業務であり、前記一又は複数の単位債務の債務者が前記請負業務の請負人であり、かつ、前記債権者が前記単位事業の下請負人であり、前記債務設定データが前記プロジェクトの出来高検収の結果を示す出来高検収データである場合を例に挙げたがこれに限られることはなく、支払管理上、支払保留又は支払保留の解除(取崩)が生じる場面において適用可能である。
続いて、上述した一連の処理の具体例を、図面を用いながら説明する。
図23に示すような発注データがあるプロジェクトにおいて(ステップS202~S203)、図24に示すような出来高検収データがある場合(ステップS204)、図25に示すような支払管理データが生成される。ここで、図24に示す出来高検収データでは、図7に示した出来高検収データとは異なり、支払保留取崩額の設定がなされており、これに応じて、図25に示す支払管理データには、支払保留解除レコードが含まれている。なお、図25に示す支払管理データには、前会計月の支払完了にともない支払状態情報が支払済を示すレコードも含まれている。
ここで、図25に示す支払管理データに含まれる内訳区分「2」及び「3」のレコード(すなわち支払保留状態情報を含むレコードのみ)を集約し、さらに図24に示した出来高検収データに含まれる情報を結合することにより、図26に示すような支払保留金集約データを得ることができる(ステップS221)。支払保留金集約データは、図26に示されるように、計上日、内訳区分及び支払状態に関する情報を含むので、例えば、未支払のレコードにおいて、支払保留が長期にわたっていないかどうかをチェックすることができるようになる。
そして、支払完了が確認されると、図24に示した支払管理データは、図27に示すように更新される。
以下に、集約データ及び対応する帳票の複数の例を説明する。
図28は、図2のステップS221で作成される集約データの第1の例を模式的に示す図である。図29は、図28に示す集約データに基づき作成される帳票の構成例を示す図である。図28に示す集約データは、支払保留金集約データであり、支払保留及び未支払がセットされたレコードを集約することにより得ることができる。図29に示す帳票は、図28に示す集約データに含まれる情報をプロジェクト単位でかつ債権者単位(支払先単位)に並べたものである。このような帳票を出力することにより、ユーザは、支払保留の状況を速やかに確認することができるようになる。また、このような帳票の一部を出力することにより、債権者からの問合せ回答書を速やかに用意することが可能となる。これに代えて、問合せのあった債権者のレコードを集約することによっても問合せ回答書を速やかに用意することが可能となる。
図30は、図2のステップS221で作成される集約データの第2の例を模式的に示す図である。図31は、図30に示す集約データに基づき作成される帳票の構成例を示す図である。図30に示す集約データは、図28に示したのと同様に支払保留及び未支払がセットされたレコードを集約することにより得ることができる支払保留金集約データであり、この例では、さらに、支払保留解除がセットされたレコードを含む。したがって、図31に示す帳票も支払保留解除に関する情報を含む。このような帳票を出力することにより、ユーザは、支払保留解除がなされた単位事業を把握することができるようになるので、例えば、プロジェクトを構成する複数の単位事業の中から、進捗が良好な単位事業(支払保留解除が実施された単位事業)を速やかに把握することができる。
図32は、図2のステップS221で作成される集約データの第3の例を模式的に示す図である。図33は、図32に示す集約データに基づき作成される帳票の構成例を示す図である。図32に示す集約データは、図30に示したのと同様に支払保留、支払保留解除及び未支払がセットされたレコードを集約することにより得ることができる支払保留金集約データであり、この例では、さらに、支払済がセットされたレコードを含む。したがって、図33に示す帳票も支払済に関する情報を含む。このような帳票を出力することにより、ユーザは、支払済の支払先を容易に把握することができ、支払管理を適切に行うことができるようになる。また、このような帳票を出力することにより、ユーザは、債権者から支払済かどうかの問合せがあった場合に、容易に回答することができる。
図34は、図2のステップS221で作成される集約データの第4の例を模式的に示す図である。図35は、図34に示す集約データに基づき作成される帳票の構成例を示す図であり、図35(a)は、第1の支払先に対する支払通知書の例を示し、図35(b)は、第2の支払先に対する支払通知書の例を示し、図35(c)は、第3の支払先に対する支払通知書の例を示す図である。図34に示す集約データは、支払保留金集約データであり、支払管理データと出来高検収データとを結合したデータから、支払予定日が2月20日となる会計期間に計上日(出来高検収データに含まれる計上日)があるレコードを集約することにより得ることができる。これにより、支払予定日情報に計上不可情報がセットされている支払保留レコードも集約することができる。このため、図35(a)、図35(b)及び図35(c)に示すように、各支払先への支払通知書に少なくとも保留金の控除額を含ませることができるようになる。
図36は、図2のステップS221で作成される集約データの第5の例を模式的に示す図である。図37は、図36に示す集約データに基づき作成される帳票の構成例を示す図であり、図37(a)は、第1の支払先に対する支払通知書の例を示し、図37(b)は、第2の支払先に対する支払通知書の例を示し、図37(c)は、第3の支払先に対する支払通知書の例を示す図である。図36に示す集約データは、図34に示した支払保留金集約データと同様に生成することが可能であり、図36に示す例では、さらに支払保留解除レコードも集約されている。このため、図35(a)、図35(b)及び図35(c)に示すように、各支払先への支払通知書に保留金の控除額及び解除額の双方を含ませることができるようになる。
図38は、図2のステップS221で作成される集約データの第6の例を模式的に示す図である。図39は、図38に示す集約データに基づき作成される集約データを模式的に示す図であり、図39(a)は、第1の単位事業に関する集約データの例を示し、図39(b)は、第2の単位事業に関する集約データの例を示す図である。図38に示す集約データは、プロジェクトを構成する単位事業ごとに支払金を集計することにより生成される。図39(a)及び図39(b)に示す集約データは、図38に示す集約データの一部(単位事業ごとの集約データ)を抽出することにより生成される。図38及び図39に示すように、本実施形態によれば、単位事業ごとの支払金も容易に把握することができるようになる。
[3.他の実施形態]
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。
例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。
また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。
また、支払管理データ生成装置100及び支払管理データ生成システム1000に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。
例えば、支払管理データ生成装置100が備える処理機能、特に制御部にて行われる各処理機能については、その全部または任意の一部を、CPUおよび当該CPUにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて支払管理データ生成装置100に機械的に読み取られる。すなわち、ROMまたはHDD(Hard Disk Drive)などの記憶部などには、OSと協働してCPUに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、RAMにロードされることによって実行され、CPUと協働して制御部を構成する。
また、このコンピュータプログラムは、支払管理データ生成装置100に対して任意のネットワーク(例えばネットワーク300)を介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。
また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、USB(Universal Serial Bus)メモリ、SD(Secure Digital)カード、フレキシブルディスク、光磁気ディスク、ROM、EPROM(Erasable Programmable Read Only Memory)、EEPROM(登録商標)(Electrically Erasable and Programmable Read Only Memory)、CD-ROM(Compact Disk Read Only Memory)、MO(Magneto-Optical disk)、DVD(Digital Versatile Disk)、および、Blu-ray(登録商標) Disc等の任意の「可搬用の物理媒体」を含むものとする。したがって、本明細書で説明した処理を実行するためのプログラムを格納した記録媒体もまた本発明を構成することとなる。
また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、OSに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。
記憶部106に格納される各種のデータベース等は、RAM、ROM等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、及び、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、及び、ウェブページ用ファイル等を格納する。
また、支払管理データ生成装置100は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、支払管理データ生成装置100は、当該装置に本明細書で説明した処理を実現させるソフトウェア(プログラムまたはデータ等を含む)を実装することにより実現してもよい。
更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。