JP7312076B2 - 支払管理データ生成装置、支払管理データ生成方法、及び支払管理データ生成プログラム - Google Patents

Description

本発明は、支払管理データ生成装置、支払管理データ生成方法、及び支払管理データ生成プログラムに関する。

特許文献１には、工事請負出来高管理システムにおいて、受注者が「出来高数量」「出来高率」を入力することにより、「支払金額」が出来高金額の９０％として計算され、残額１０％が保留金ファイルへ保留されることが開示されている（段落［００１３］及び図３（ｂ））。また、特許文献１には、保留金の支払が工事完了後に一括で支払われることが記載されている（段落［００１３］）。

特許文献２には、工事代金処理装置において、検収時に保留金を分割管理するために、保留金額のマイナス明細とプラス明細を登録し、マイナス明細の支払い予定日に当初の支払予定日を設定し、プラス明細の支払予定日に未来日付を設定すること（段落［００３７］、［００４１］）、及び、ＵＩを介したユーザ操作に応答して支払いの保留が解除された場合、プラス明細の未来日付を実際の支払予定日に変更すること（段落［００４２］～［００４３］）が開示されている。

特開２００７－０４７９４８号公報 特開２０１９－０３２７７９号公報

ここで、保留金は、工事完了後に一括で支払われるとは限られない。すなわち、任意のタイミングで保留金の一部又は全部について支払（取崩）が行われることもある。この点、特許文献２に記載の技術では、保留金は、未来日付で管理がなされており、任意のタイミングで保留金の解除を行うべく、未来日付を支払予定日に変更することが可能である。

しかしながら、装置上で保留金を日付だけで管理した場合、ユーザにとっては、例えば、保留金の解除から実際の支払までの間の支払予定金額が、通常の支払（例えば月額分の支払い）であるのか、それとも保留解除による支払であるのかが把握しにくいという問題や、保留金の解除後において保留金に残高があるのかそれとも残高がないのか把握しにくいという問題がある。このような問題は、債務を管理する場合に同様に生じる。

したがって、保留金又は保留金の解除が生じ得る債権者への支払内容の管理の利便性を向上させることが求められているという第１の課題がある。斯かる第１の課題が解決されれば、債権者及び債務者間の保留金又は保留金の解除に係る連絡（例えば、債権者から債務者への保留解除金の問合せや、債務者から債権者への保留解除金の通知）が円滑に行われることが期待される。

また、保留金の一部又は全部の解除が生じた場合に、その保留解除金の管理の利便性を向上させることが求められているという第２の課題がある。斯かる第２の課題が解決されれば、保留解除金が保留金の一部であるのか全部であるのかに関わらずその管理が適切に行われることが期待される。

本発明は、上述の課題に鑑みてなされたものであって、債権者への支払内容の管理の利便性を向上させることができる支払管理データ生成装置、支払管理データ生成方法、及び支払管理データ生成プログラムを提供することを第１の目的とする。

本発明は、上述の課題に鑑みてなされたものであって、保留金の一部又は全部の解除が生じた場合に、その保留解除金の管理の利便性を向上させることができる支払保留データ管理装置、支払保留データ管理方法、及び支払保留データ管理プログラムを提供することを第２の目的とする。

上述した課題を解決し、第１の目的を達成するために、本発明に係る支払管理データ生成装置は、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを生成するための、制御部を備える支払管理データ生成装置であって、前記制御部は、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る支払管理データを生成する支払管理データ生成手段を含み、前記支払管理データ生成手段は、前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含む債務設定データが、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードを追加することにより、前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データを生成することを特徴とする。

また、本発明に係る支払管理データ生成装置は、前記支払管理データは、さらに、前記単位債務を識別する情報を含むことを特徴とする。

また、本発明に係る支払管理データ生成装置は、前記支払管理データ生成手段は、前記支払管理データに基づき、前記債権者のレコードを集約した集約データを所定のフォーマットで生成することを特徴とする。

さらに、本発明に係る支払管理データ生成装置は、支払予定データ、前記支払管理データ及び集約データは、前記支払予定金額情報に対応する支払予定金額、前記支払保留金額情報に対応する支払保留金額及び前記支払保留解除金額情報に対応する支払保留解除金額についての支払済若しくは未支払を示す支払状態情報を含むことを特徴とする。

さらにまた、本発明に係る支払管理データ生成装置は、前記支払管理データ生成手段は、前記支払管理データに含まれる前記支払状態情報が未支払を示す前記債権者のレコードを集約した未払金集約データを前記集約データとして生成することを特徴とする。

さらにまた、本発明に係る支払管理データ生成装置は、前記支払管理データ生成手段は、前記支払管理データに含まれる前記支払保留状態情報を含む前記債権者のレコードを集約した支払保留金集約データを前記集約データとして生成することを特徴とする。

さらにまた、本発明に係る支払管理データ生成装置は、前記制御部は、データを出力する出力手段をさらに備え、前記出力手段は、前記集約データを当該集約データに応じて予め設定された帳票データとして出力することを特徴とする。

さらにまた、本発明に係る支払管理データ生成装置は、前記プロジェクトは、複数の単位事業を含む請負業務であり、前記一又は複数の単位債務の債務者は、前記請負業務の請負人であり、かつ、前記債権者は、前記単位事業の下請負人であり、前記債務設定データは、前記プロジェクトの出来高検収の結果を示す出来高検収データであることを特徴とする。

また、本発明に係る支払管理データ生成方法は、制御部を備えた情報処理装置において実行される、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを生成するための支払管理データ生成方法であって、前記制御部において実行される、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る支払管理データを生成する支払管理データ生成ステップを含み、前記支払管理データ生成ステップでは、前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含む債務設定データが、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードを追加することにより、前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データを生成することを特徴とする。

また、本発明に係る支払管理データ生成プログラムは、制御部を備えた情報処理装置において実行される、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを生成するための支払管理データ生成プログラムであって、前記制御部において実行させるための、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る支払管理データを生成する支払管理データ生成ステップを含み、前記支払管理データ生成ステップでは、前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含む債務設定データが、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードを追加することにより、前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データを生成することを特徴とする。

上述した課題を解決し、第２の目的を達成するために、本発明に係る支払保留データ管理装置は、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払の支払保留金額に関する支払保留データを管理するための、制御部を備える支払保留データ管理装置であって、前記制御部は、前記債権者への支払を保留する支払保留金額の一部又は全部に対する支払保留解除金額又は支払保留金額の総額に対する支払保留対象割合に関する支払保留解除金額情報が設定された場合に、前記支払保留データにおいて当該支払保留金額に関する支払保留金額情報を含む対象支払保留レコードの更新を行う支払保留データ更新手段を備え、前記支払保留データ更新手段は、前記対象支払保留レコードに含まれる前記支払保留金額に関する支払保留金額情報に代えて、前記設定された支払保留解除金額情報がセットされ、かつ、支払保留状態情報として支払保留解除を示す情報がセットされた支払保留解除レコードを少なくとも生成することにより、前記支払保留データの更新を行うことを特徴とする。

また、本発明に係る支払保留データ管理装置は、前記支払保留データ更新手段は、前記支払保留解除レコードに、前記支払保留解除金額情報に対応する支払保留解除の計上日又は計上予定日に関する日付情報をセットすることを特徴とする。

また、本発明に係る支払保留データ管理装置は、前記支払保留データ更新手段は、前記支払保留解除金額が前記支払保留金額の一部である場合には、前記支払保留金額から前記支払保留解除金額の差額を支払保留金額情報として含む差額支払保留レコードを新たに生成することを特徴とする。

さらに、本発明に係る支払保留データ管理装置は、前記支払保留データ更新手段は、前記差額支払保留レコードに、支払保留解除の計上日又は計上予定日が定まっていないことを示す計上不可情報をセットすることを特徴とする。

また、本発明に係る支払保留データ管理装置は、前記支払保留データ更新手段は、前記支払保留データに、前記対象支払保留レコードが一つ又は複数存在する場合には、当該１群の対象支払保留レコードの各々に、予め設定された複数の優先度の中から選ばれた優先度を設定することを特徴とする。

さらに、本発明に係る支払保留データ管理装置は、前記複数の優先度は、前記支払保留金額の計上日が近い順、又は、前記支払保留金額が前記支払保留解除金額の全額に近い順、又は、それらの組み合わせにより決定される順序を含むことを特徴とする。

また、本発明に係る支払保留データ管理装置は、前記支払保留データ更新手段は、前記支払保留データの更新が完了した場合に、前記対象支払保留レコードを削除することを特徴とする。

また、本発明に係る支払保留データ管理装置は、前記制御部は、前記支払保留金額の総額を超える支払保留解除金額に関する支払保留解除金額情報が設定されることを規制する保留解除規制手段をさらに含むことを特徴とする。

また、本発明に係る支払保留データ管理装置は、前記プロジェクトは、複数の単位事業を含む請負業務であり、前記一又は複数の単位債務の債務者は、前記請負業務の請負人であり、かつ、前記債権者は、前記単位事業の下請負人であり、前記債務設定データは、前記プロジェクトの出来高検収の結果を示す出来高検収データであることを特徴とする。

また、本発明に係る支払保留データ管理方法は、制御部を備えた情報処理装置において実行される、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払の支払保留金額に関する支払保留データを管理するための支払保留データ管理方法であって、前記制御部において実行される、前記債権者への支払を保留する支払保留金額の一部又は全部に対する支払保留解除金額又は支払保留金額の総額に対する支払保留対象割合に関する支払保留解除金額情報が設定された場合に、前記支払保留データにおいて当該支払保留金額に関する支払保留金額情報を含む対象支払保留レコードの更新を行う支払保留データ更新ステップを含み、前記支払保留データ更新ステップでは、前記対象支払保留レコードに含まれる前記支払保留金額に関する支払保留金額情報に代えて、前記設定された支払保留解除金額情報がセットされ、かつ、支払保留状態情報として支払保留解除を示す情報がセットされた支払保留解除レコードを少なくとも生成することにより、前記支払保留データの更新を行うことを特徴とする。

また、本発明に係る支払保留データ管理プログラムは、制御部を備えた情報処理装置において実行される、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払の支払保留金額に関する支払保留データを管理するための支払保留データ管理プログラムであって、前記制御部において実行させるための、前記債権者への支払を保留する支払保留金額の一部又は全部に対する支払保留解除金額又は支払保留金額の総額に対する支払保留対象割合に関する支払保留解除金額情報が設定された場合に、前記支払保留データにおいて当該支払保留金額に関する支払保留金額情報を含む対象支払保留レコードの更新を行う支払保留データ更新ステップを含み、前記支払保留データ更新ステップでは、前記対象支払保留レコードに含まれる前記支払保留金額に関する支払保留金額情報に代えて、前記設定された支払保留解除金額情報がセットされ、かつ、支払保留状態情報として支払保留解除を示す情報がセットされた支払保留解除レコードを少なくとも生成することにより、前記支払保留データの更新を行うことを特徴とする。

本発明によれば、同一種類の物品であって管理目的が互いに異なる物品であっても適切に支払管理データ生成を行うことができ、ユーザの手間を軽減することができるという効果を奏する。

図１は、本発明の実施形態に係る支払管理データ生成装置を含む支払管理データ生成システムの構成の一例を示すブロック図である。 図２は、図１の支払管理データ生成システム１０００において、支払管理データ生成装置１００が実行する支払管理データ生成方法の処理手順を示すフローチャートである。 図３は、図２のステップＳ２０２で登録されるプロジェクトマスタの構成例を模式的に示す図である。 図４は、図２のステップＳ２０３で登録される債権に対応する債権データの構成例を模式的に示す図である。 図５は、図２のステップＳ２０４で債務設定が行われる場合に起動される債務設定画面の構成例を示す図である。 図６は、図２のステップＳ２０５において実行される債務設定受付処理の詳細を示すサブルーチンである。 図７は、図６のステップＳ６１０で生成される債務設定データの構成を模式的に示す図である。 図８は、図２のステップＳ２０６の支払管理データ生成処理の詳細を示すサブルーチンである。 図９は、図２のステップＳ８０２及びＳ８０３で生成されるレコードを含む支払管理データの構成例を模式的に示す図である。 図１０は、図９に示した支払管理データの一部のレコードの支払状態情報が、図２のステップＳ２０９の処理の結果、支払済に更新された例を示す図である。 図１１は、図２のステップＳ２１１及びＳ２１２の処理を説明するために用いられる図であり、図１１（ａ）は、図２のステップＳ２１１で集計対象となる１群のレコードの一例を示しており、図１１（ｂ）は、図２のステップＳ２１２の処理の結果生成される支払保留取崩可能額を管理するためのデータの構成例を模式的に示す図である。 図１２は、図７に示した出来高検収データとは別の出来高検収データであって、翌月の出来高検収の結果の一例を模式的に示す図である。 図１３は、図１２に示す出来高検収データに基づき生成される支払管理データを模式的に示す図である。 図１４は、図１２に示す出来高検収データに基づき、図８のステップＳ８０７の処理の結果生成された支払保留解除レコードの一例を模式的に示す図である。 図１５は、図８のステップＳ８０７の処理の結果読み出された１群の対象支払保留レコードを模式的に示す図である。 図１６は、図１５に示した１群の対象支払保留レコードに優先度が付与された状態を模式的に示す図である。 図１７は、図８のステップＳ８０９において、図１６に示す１群の対象支払保留レコードの中から、３番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図１７（ａ）は、選択された対象支払保留レコードを模式的に示し、図１７（ｂ）は、図８のステップＳ８１０で、図１７（ａ）の対象支払保留レコードに対応して生成される支払保留解除レコードを模式的に示す図である。 図１８は、図８のステップＳ８０９において、図１６に示す１群の対象支払保留レコードの中から、１番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図１８（ａ）は、選択された対象支払保留レコードを模式的に示し、図１８（ｂ）は、図８のステップＳ８１０で、図１８（ａ）の対象支払保留レコードに対応して生成される支払保留解除レコードと、図８のステップＳ８１２で、差額に応じて生成される支払保留レコードとを模式的に示す図である。 図１９は、図８のステップＳ８０９において、図１６に示す１群の対象支払保留レコードの中から、２番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図１９（ａ）は、選択された対象支払保留レコードを模式的に示し、図１９（ｂ）は、図８のステップＳ８１０で、図１９（ａ）の対象支払保留レコードに対応して生成される支払保留解除レコードと、図８のステップＳ８１２で、差額に応じて生成される支払保留レコードとを模式的に示す図である。 図２０は、例示的な出来高検収データを模式的に示す図である。 図２１は、図２０の出来高検収データに基づき読み出された２つの対象支払保留レコードであって優先度が設定されたものを模式的に示す図である。 図２２は、図２１に示す２つの対象支払保留レコードの更新を説明するための図であり、図２２（ａ）は、更新前の２つの対象支払保留レコードを模式的に示し、図２２（ｂ）は、図２２（ａ）の２つの対象支払保留レコードに対応して更新後に生成される２つの支払保留解除レコードを模式的に示す図である。 図２３は、発注データの例を模式的に示す図である。 図２４は、出来高検収データの例を模式的に示す図である。 図２５は、図２４に示す出来高検収データに基づき生成される支払管理データの例を模式的に示す図である。 図２６は、図２４に示す出来高検収データ及び図２５に示す支払管理データから得られる支払保留金集約データの例を模式的に示す図である。 図２７は、図２４に示した支払管理データの更新後を模式的に示す図である。 図２８は、図２のステップＳ２２１で作成される集約データの第１の例を模式的に示す図である。 図２９は、図２８に示す集約データに基づき作成される帳票の構成例を示す図である。 図３０は、図２のステップＳ２２１で作成される集約データの第２の例を模式的に示す図である。 図３１は、図３０に示す集約データに基づき作成される帳票の構成例を示す図である。 図３２は、図２のステップＳ２２１で作成される集約データの第３の例を模式的に示す図である。 図３３は、図３２に示す集約データに基づき作成される帳票の構成例を示す図である。 図３４は、図２のステップＳ２２１で作成される集約データの第４の例を模式的に示す図である。 図３５は、図３４に示す集約データに基づき作成される帳票の構成例を示す図であり、図３５（ａ）は、第１の支払先に対する支払通知書の例を示し、図３５（ｂ）は、第２の支払先に対する支払通知書の例を示し、図３５（ｃ）は、第３の支払先に対する支払通知書の例を示す図である。 図３６は、図２のステップＳ２２１で作成される集約データの第５の例を模式的に示す図である。 図３７は、図３６に示す集約データに基づき作成される帳票の構成例を示す図であり、図３７（ａ）は、第１の支払先に対する支払通知書の例を示し、図３７（ｂ）は、第２の支払先に対する支払通知書の例を示し、図３７（ｃ）は、第３の支払先に対する支払通知書の例を示す図である。 図３８は、図２のステップＳ２２１で作成される集約データの第６の例を模式的に示す図である。 図３９は、図３８に示す集約データに基づき作成される集約データを模式的に示す図であり、図３９（ａ）は、第１の単位事業に関する集約データの例を示し、図３９（ｂ）は、第２の単位事業に関する集約データの例を示す図である。

本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。

［１．構成］
本実施形態に係る支払管理データ生成装置を含む支払管理データ生成システムの構成の一例について、図１を参照して説明する。図１は、本発明の実施形態に係る支払管理データ生成装置を含む支払管理データ生成システムの構成の一例を示すブロック図である。なお、本発明の実施形態に係る支払管理データ生成装置は、支払保留データ管理装置としても機能する情報処理装置の一例である。

図１に示す支払管理データ生成システム１０００は、情報処理装置としての支払管理データ生成装置１００と、サーバ２００と、支払管理データ生成装置１００及びサーバ２００を通信可能に接続するネットワーク３００とを含んでいる。

支払管理データ生成装置１００は、複数の会計月にまたがり得る一又は複数の単位債務（単位工事）を生じるプロジェクト（例えば建築工事）について一又は複数の債権者（受注者）への支払内容に関する支払管理データを生成するための情報処理装置であり、例えば市販のデスクトップ型パーソナルコンピュータで構成される。この支払管理データ生成装置１００は、例えば、現場の管理部門といった、事業者においてプロジェクトの進捗を管理する部署、特に現場において出来高検収を行う部署（例えば現場監督部門）に１台設置されている。なお、支払管理データ生成装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。また、支払管理データ生成装置１００は、支払管理データ生成システム１０００内において複数台設置されていてもよく、複数台の支払管理データ生成装置１００の間で同期をとることで１台の支払管理データ生成装置１００として機能してもよい。支払管理データ生成装置１００は、現場の管理部門に設置することに代えて、現場から離れた部署（例えば、支払管理を行う会計部門又は建築業法のコンプライアンスを徹底する法務部門）に設置されてもよい。

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

通信インターフェース部１０４は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、支払管理データ生成装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、支払管理データ生成装置１００とサーバ２００とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。したがって、通信インターフェース部１０４は、他の部門等が管理している情報処理装置や発注先（例えば取引先）の情報処理装置からの入力情報等を、ネットワーク３００を介して又はネットワーク３００及びサーバ２００を介して受け付けることが可能に構成されているとともに、所定の情報処理装置に対して所定の情報を出力することが可能に構成されている。

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

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

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

さらに図１を参照しながら、記憶部１０６及び制御部１０２の構成について詳述する。

記憶部１０６は、図１に示されるように、プロジェクトマスタ１０６ａと、債権者マスタ１０６ｂと、債務設定データ記憶領域１０６ｃと、支払管理データ記憶領域１０６ｄと、集約データ記憶領域１０６ｅとを含む。また、記憶部１０６は、その他のマスタやデータ記憶領域を備えていてもよい。

プロジェクトマスタ１０６ａは、プロジェクトに関する情報を登録するためのマスタである。債権者マスタ１０６ｂは、債権者（取引先、支払先）に関する情報を登録するためのマスタである。

債務設定データ記憶領域１０６ｃ、支払管理データ記憶領域１０６ｄ、及び集約データ記憶領域１０６ｅは、それぞれ、後述する債務設定データ、債務設定データ、及び集約データを記憶するための領域であり、必要に応じて各データを出力可能に保持する。

制御部１０２は、図１に示されるように、複数のモジュールを備えている。図１に示す例では、制御部１０２は、保留解除規制部１０２Ａと、支払管理データ生成部１０２Ｂと、出力部１０２Ｃとを備えている。支払管理データ生成部１０２Ｂは、支払保留データ更新部１０２ｂを含む。

保留解除規制部１０２Ａは、支払保留金額の総額を超える支払保留解除金額に関する支払保留解除金額情報が設定されることを規制する保留解除規制手段として機能するモジュールである。支払管理データ生成部１０２Ｂは、支払管理データを生成する支払管理データ生成手段として機能するモジュールである。支払保留データ更新部１０２ｂは、支払保留データの更新を行う支払保留データ更新手段として機能するモジュールである。出力部１０２Ｃは、データを出力する出力手段として機能するモジュールである。各部の機能は、後述する処理内容を実現する機能を含む。

［２．処理］
次に、図１に示す支払管理データ生成システム１０００において実行される支払管理データ生成方法を例示的に説明する。

図２は、図１の支払管理データ生成システム１０００において、支払管理データ生成装置１００が実行する支払管理データ生成方法の処理手順を示すフローチャートである。

この図２に示す処理は、概略的には、複数の会計月にまたがる一又は複数の単位債務（例えば、下請負人に対する単位工事の業務発注による債務）を生じるプロジェクト（例えば、請負事業としての建設工事）について一又は複数の債権者への支払内容に関する支払管理データを生成するというものであり、本処理の大部分は、支払管理データ生成装置１００の制御部１０２において実行される。

なお、以下では、建設工事のプロジェクトについて複数の下請負人に対して単位工事（例えば、基礎工事、電気設備工事等）を発注し、その債務に応じた支払（債権）の一部保留又は当該支払保留の解除を許容しながら会計月単位で行う場合を例に挙げて説明する。ここで、支払の保留は、下請負人の倒産リスクや瑕疵担保を目的として、支払対象金額の一部を保留金として預かる（控除する）場合等に生じる。また、支払保留の解除（取崩）は、通常、下請負人の工事進捗や期間を鑑みて実施される。保留及びその解除は、建設業法を順守して実施される必要がある（例えば、下請負人が同じであっても異なるプロジェクトの単位工事についての支払の保留及びその解除は禁止されており、また、支払の保留を行う場合にあっても長期間にわたる保留が禁止されている）ため、その管理は適切に行われる必要がある。

図２において、まず、ステップＳ２０１では、マスタ登録を受け付ける。登録対象のマスタとして、管理対象となる事項に関する情報を登録したマスタ等が用意される。例えば、登録対象のマスタとしては、図１に示した債権者マスタが挙げられる。債権者マスタには、プロジェクトの単位工事の発注先となり得る取引先（下請負人）の取引先名と当該取引先を識別するための識別情報（例えば取引先コード）が登録され、好ましくは、取引先の支払先（入金先）が当該取引先と異なる場合には、当該支払先を特定するための情報がさらに紐づけられた状態で登録される。また、別のマスタとしては、例えば単位工事とその工事内容を登録したマスタを用意してもよい。さらに、後述するステップＳ２０２で登録されるプロジェクトマスタをステップＳ２０１で併せて登録してもよい。また、用意すべきマスタが既に構築されている場合には、ステップＳ２０１において、ユーザ入力に基づいた修正や新規登録等の編集が行われてもよい。また、他のマスタのデータを読み出してコピー又は上書きすることによって新規のマスタが構築されたり既存のマスタの更新が行われたりしてもよく、また、これに代えて、外部記憶装置に記録された他のマスタへ支払管理データ生成装置１００をアクセス可能に構成し、アクセス可能になった時点でマスタが新規に構築されたとみなしてもよい。

そして、ステップＳ２０２では、プロジェクトマスタの登録を受け付ける。本処理は、通常、新規のプロジェクトの内容が定まった段階で行われる。そのため、既存のプロジェクトマスタが存在する場合には、当該マスタに新規のプロジェクトの内容が新たに追加される。本明細書において、プロジェクトとは、通常、複数の会計月にまたがり得る一又は複数の単位債務（単位事業）を生じる一連の事業をさす。なお、プロジェクト又は単位事業の中止若しくは大幅な工期短縮により、個々の又は全ての単位債務の会計月が単数となってもよい。

図３は、図２のステップＳ２０２で登録されるプロジェクトマスタの構成例を模式的に示す図である。

図３に示すプロジェクトマスタには、例えば、プロジェクトのプロジェクト名と当該プロジェクトを識別するためのプロジェクト識別情報（例えば、プロジェクト番号）が少なくとも登録され、さらに、必要に応じて、取引先情報として、取引先の取引先名又は当該取引先を識別するための識別情報が登録される。ここにいうプロジェクトの取引先とは、プロジェクトの主体（代表）であって、例えば、施工主又は発注元（他社）であってもよいし、主体が複数社に及ぶ場合にはその代表となる１社であってもよいし、自社又はその関連会社であってもよい。

続くステップＳ２０３では、債権の登録が行われる。ここでいう債権とは、例えば、プロジェクトを構成する一又は複数の単位事業を一又は複数の下請負人（債権者）に発注した場合の発注内容であり、下請負人にとってのプロジェクト完了までの債権（下請負人が受注した業務の遂行に応じて発注元から受け取ることができる金額の総額、すなわち受注金額）であり、発注元（自社）にとってのプロジェクト完了までの債務（発注元が発注した業務の下請負人の遂行に応じて生じる支払金額の総額、すなわち発注金額）である。そのため、発注内容を示す発注データが存在する場合には、当該発注データを読み出すことによって債権の登録が行われてもよいし、発注データ又は発注伝票に基づきユーザが債権を登録してもよい。債権の登録は、プロジェクト識別情報を含むように行われ、かつ、債権者（下請負人）ごとに行われる。これにより、単位事業ごとの債権が登録されることになる。ここで、例えば、プロジェクト識別情報に付加情報（例えば枝番）を付けることで、個々の単位事業に複数の債権者（下請負人）を設定するようにしてもよい。これにより、単位事業ごとにも債務を登録することが可能となる。そして、このステップＳ２０３で登録された債権は、債権データとして読み出し可能に保存される。

図４は、図２のステップＳ２０３で登録される債権に対応する債権データの構成例を模式的に示す図である。

図４に示す債権データの例では、債権を識別するための債権識別情報（例えば発注番号）と、債権者を識別するための債権者識別情報（例えば取引先名）と、プロジェクト識別番号と、発注金額の総額に関する発注金額情報と、支払保留の設定の有無を示す支払保留有無情報と、支払保留金控除率に関する支払保留金控除率情報とを含んで構成されている。

発注金額情報としては、プロジェクト完了までを管理するため、発注金額の総額が登録される。支払保留有無情報とは、発注者（ここでは債務者）と受注者（ここでは債権者）との契約（取決め）により、支払（債務）の保留が建設業法上許容される期間又はそれよりも短い期間にわたり許容されているかどうかを示す情報をいう。支払保留金控除率とは、債権者へ支払う予定の支払予定金額に対して保留（控除）すべき金額の割合（百分率）をいう。なお、債権データは、支払保留金控除率情報に代えて、支払保留すべき保留金額に関する保留金額情報を含んでいてもよいし、双方のうちの一方を含んでいてもよい。好ましくは、債権識別情報は、債権発生日（発注日）に関する情報を含むことが好ましく、これにより、支払の保留がなされた期間の起算日を管理することができる。

そして、ステップＳ２０４では、債務設定が行われるかどうかを判別する。具体的には、図５に示すような債務設定画面が起動されて、ユーザによる入力が開始されるかどうかを判別する。債務設定は、通常、会計月ごとに、支払予定日よりも前に実施され、必要に応じて任意のタイミングで実施されてもよい。ここにいう債務の例は、プロジェクトを構成する単位事業の進捗に関する出来高検収が行われた結果決定された、債権者に対し支払うべき支払対象金額、当該支払対象金額から保留（控除）すべき金額又はその割合、保留金がある場合の当該保留金の一部又は全部につき解除すべき金額又はその割合が挙げられる。支払対象金額は、出来高検収の結果決定された全債権に対する割合に応じた金額であってもよい。ここで、支払対象金額及び保留解除に係る金額をプラスの金額で管理し、保留（控除）に係る金額をマイナスの金額で管理することで、プラスの金額であってもマイナスの金額であっても債務として管理することができる。

ステップＳ２０４の判別の結果、債務設定が行われる場合には（ステップＳ２０４でＹｅｓ）、ステップＳ２０５の処理に進む。他方、ステップＳ２０４の判別の結果、債務設定が行われない場合には（ステップＳ２０４でＮｏ）、ステップＳ２０５～Ｓ２０６をスキップして、ステップＳ２０７以降の判別処理に進む。

ステップＳ２０５では、債務設定受付処理を行う。債務設定受付処理は、例えば、図５に示したような入力画面を介して入力された情報（出来高検収の結果決定された情報）のユーザによる入力を受け付けが行われる。

図６は、図２のステップＳ２０５において実行される債務設定受付処理の詳細を示すサブルーチンである。

まず、図６のステップＳ６０１では、図５に示したような入力画面を介してプロジェクト及び債権者の指定を受け付ける。プロジェクト及び債権者の指定は、各種マスタに登録されている識別番号で行われてもよい。これにより、債務設定対象のプロジェクト識別情報と債権者情報が取得されることになる。

そして、ステップＳ６０２では、ステップＳ６０１で取得したプロジェクト識別情報と債権者情報に基づき、入力画面上でデフォルト表示を行う。例えば、図４に示した債権データに基づき、発注金額（契約額）や支払保留金控除率に関する情報が入力画面上に表示される。また、前回の会計月の支払金額又は検収金額に関する情報や、前回の会計月まで支払金額の累計も併せて入力画面上に表示することが好ましい。このように入力画面にさまざまな情報を表示することで、ユーザは、前回までの金額情報と比較しながら当月分の債務設定を行うことができるようになる。

続いて、ステップＳ６０３では、支払対象金額情報の入力を受け付ける。支払対象金額（以下、「支払対象金額（ａ）」ともいう）とは、例えば、当月分の出来高検収の結果決定された支払対象金額（当月検収額）である。通常、下請負人による単位事業の遂行には会計月ごとの進捗があることから、支払対象金額はプラスの金額である。また、出来高検収の結果、進捗がないと認められた場合、支払対象金額は通常ゼロである。ただし、例えば、取り決めや出来高検収時の交渉（例えば、発注元の都合による単位工事の遅延）等に応じて、支払対象金額として、ゼロ未満の金額、すなわちマイナスの金額を控除金額として入力することも可能である。そして、支払対象金額情報の入力を受け付けると、支払保留金控除率に基づき、支払保留金情報が入力画面にデフォルト表示される。ここで表示される支払保留金情報が示す保留金は、例えば、支払対象金額に支払保留金控除率が示す割合を乗算することにより算出される。支払保留金控除率が設定されていない場合には、保留金はゼロとしてデフォルト表示される。

次に、ステップＳ６０４では、ユーザによる入力の結果、保留金に変更があるかどうかを判別する。保留金は、ステップＳ６０３の処理の結果デフォルト表示された保留金である。ステップＳ６０４の処理の結果、保留金に変更があった場合又はデフォルト表示の結果、保留金にゼロを超える金額がセットされている場合（ステップＳ６０４でＹｅｓ）、ステップＳ６０５以降の処理に進んで、変更後の保留金又はデフォルト表示の保留金（以下、これら保留金をまとめて「保留金（ｂ）」ともいう）に関するエラーチェックを行う。他方、保留金に変更がない場合又は保留金にゼロがセットされている場合（ステップＳ６０４でＮｏ）、ステップＳ６０７の処理に進む。

保留金（ｂ）に関するエラーチェックに際し、まず、ステップＳ６０５及びＳ６０６では、ステップＳ６０３で受け付けた支払対象金額（ａ）がゼロを超える金額であるかどうか、並びに、ステップＳ６０４で取得した保留金（ｂ）が支払対象金額（ａ）以下であるかどうかを判別する。これら判別処理により、支払対象金額（ａ）がプラスの金額でもないのに新たに保留金を設定するものでないこと、また、支払対象金額（ａ）がプラスの金額であっても当該プラスの金額を上回る保留金が設定するものでないこと、すなわち、設定された保留金（ｂ）の妥当性が確認される。

ステップＳ６０５の判別の結果、支払対象金額（ａ）がゼロを超える金額でない場合には（ステップＳ６０５でＮｏ）、保留金（ｂ）としてゼロしか入力できないように規制すべく、まず、ステップＳ６２０で保留金（ｂ）がゼロであるかどうかを判別し、斯かる判別の結果、保留金（ｂ）がゼロでない場合には（ステップＳ６２０でＮｏ）、保留金（ｂ）につきゼロへの変更入力を促すべく、第１のエラー表示（例えば、「０のみ入力可能です」の旨の警告表示）を行い（ステップＳ６２１)、ステップＳ６０３の処理に戻って、支払対象金額（ａ）及び保留金（ｂ）の一方又は双方が変更されるのを待機する。ステップＳ６２０の判別の結果、保留金（ｂ）がゼロである場合には（ステップＳ６２０でＹｅｓ）、ステップＳ６０６の処理に進む。

ステップＳ６０６の判別の結果、保留金（ｂ）が支払対象金額（ａ）以下でない場合には（ステップＳ６０６でＮｏ）、支払対象金額（ａ）を上回る保留金（ｂ）が入力されないように規制すべく、ステップＳ６３０で第２のエラー表示（例えば、「当月検収額を超える金額は指定できません」の旨の警告表示）を行って、ステップＳ６０３の処理に戻り、支払対象金額（ａ）及び保留金（ｂ）の一方又は双方が変更されるのを待機する。

そして、ステップＳ６０５及びＳ６０６において、ステップＳ６０４で設定された保留金（ｂ）の妥当性が確認されたら（ステップＳ６０５でＹｅｓかつステップＳ６０６でＹｅｓ）、ステップＳ６０７へ進む。

ステップＳ６０７～Ｓ６０９では、保留解除金に関するエラーチェックを行う。具体的には、まず、ステップＳ６０７において、保留解除金としてゼロでない金額の入力がなされているかどうかを判別する。ステップＳ６０７の判別の結果、保留解除金の入力がなされていない場合又は保留解除金にゼロがセットされている場合には（ステップＳ６０７でＮｏ）、ステップＳ６１０に進む。他方、ステップＳ６０７の判別の結果、保留解除金の入力がなされている場合には（ステップＳ６０７でＹｅｓ）、入力がなされた保留解除金（以下、「保留解除金（ｃ）」ともいう）を取得し、ステップＳ６０８に進む。

ステップＳ６０８では、支払保留取崩可能額（以下、「支払保留取崩可能額（ｄ）」ともいう）がゼロを上回る金額であるかどうか（すなわち支払保留金に残高があるかどうか）を判別する。支払保留取崩可能額とは、支払保留金額から取崩を行うことができる金額の上限をいい、通常は、当月の支払保留金額の総額である。支払保留取崩可能額は、支払処理が行われるたびに変動するので、後述する処理により更新がなされるようになっている。

ステップＳ６０８の判別の結果、支払保留取崩可能額がゼロを上回る金額である場合には（ステップＳ６０８でＹｅｓ）、取崩対象の保留金額が存在することになるので、ステップＳ６０９へ進む。続くステップＳ６０９では、ステップＳ６０７で取得した保留解除金（ｃ）が支払保留取崩可能額（ｄ）以下の金額であるかどうかを判別する。ステップＳ６０９の判別の結果、保留解除金（ｃ）が支払保留取崩可能額（ｄ）以下の金額である場合には、保留解除金（ｃ）が、取崩対象の保留金額の上限を超えるものではないことが確認されたことになるので、ステップＳ６１０に進む。

他方、ステップＳ６０８の判別の結果、支払保留取崩可能額がゼロ上回る金額でない場合には（ステップＳ６０８でＮｏ）、支払保留金額に取崩対象となる残高がないことになるので、保留解除金（ｃ）としてゼロしか入力できないように規制すべく、まず、ステップＳ６４０で保留解除金（ｃ）がゼロであるかどうかを判別し、斯かる判別の結果、保留解除金（ｃ）がゼロでない場合には（ステップＳ６４０でＮｏ）、保留解除金（ｃ）につきゼロへの変更入力を促すべく、第３のエラー表示（例えば、「０のみ入力可能です」の旨の警告表示）を行い（ステップＳ６４１)、ステップＳ６０７の処理に戻って、保留解除金（ｃ）が変更されるのを待機する。ステップＳ６４０の判別の結果、保留解除金（ｃ）がゼロである場合には（ステップＳ６４０でＹｅｓ）、ステップＳ６０９の処理に進む。

ステップＳ６０９の判別の結果、保留解除金（ｃ）が支払保留取崩可能額（ｄ）以下の金額でない場合には（ステップＳ６０９でＮｏ）、支払保留取崩可能額（ｄ）を上回る保留解除金（ｃ）が入力されないように規制すべく、ステップＳ６５０で第４のエラー表示（例えば、「当月保留金解除が保留金以上の金額です」の旨の警告表示）を行って、ステップＳ６０７の処理に戻って、保留解除金（ｃ）が変更されるのを待機する。

そして、ステップＳ６０８及びＳ６０９において、ステップＳ６０７で取得した保留解除金（ｃ）の妥当性が確認されたら（ステップＳ６０８でＹｅｓかつステップＳ６０９でＹｅｓ）、ステップＳ６１０へ進む。

そして、ステップＳ６１０では、ステップＳ６０３で取得した支払対象金額（ａ）、ステップＳ６０４で取得した保留金（ｂ）、及びステップＳ６０７で取得した保留解除金（ｃ）に関する情報を債務設定情報として取得する。なお、債務設定情報の各々は、金額がゼロであることを示す情報であってもよい。このステップＳ６１０の処理は、例えば、図５に示した入力画面において図示しない「確定」ボタンの押下により実行される。そして、ステップＳ６１０で取得した各債務設定情報は、例えば債務設定データとして読み出し可能に保存される。そして、図６に示した処理を完了して、図２の処理にリターンして、ステップＳ２０６の処理に進む。

図７は、図６のステップＳ６１０で生成される債務設定データの構成を模式的に示す図である。

図７に示す債務設定データの例は、出来高検収の結果を示す出来高検収データである。図７に示すように、出来高検収データは、出来高検収を識別するための検収識別情報（例えば検収番号）と、債権識別情報（例えば発注番号）と、計上日（例えば出来高検収の実施日）に関する情報と、支払予定日（例えば翌月又は翌々月の会計日）に関する情報と、支払先に関する情報と、プロジェクト識別情報、支払対象金額（検収金額）に関する情報とを含み、さらに、図４に示した債権設定データに含まれる一部の情報とを含む。図４に示した債権設定データに含まれる一部の情報としては、支払保留有無情報、支払保留金控除率情報などがあり、これらの情報は、図４に示した債権設定データから取得してもよい。したがって、出来高検収データが存在する場合には、ステップＳ２０５の処理に代えて、出来高検収データから読み出した情報から、各債務設定情報を取得するようにしてもよい。又は、各債務設定情報を出来高検収データに反映させるべく、例えば、保留解除金（ｃ）に関する情報を出来高検収データに追加してもよい。

図２に戻り、ステップＳ２０６では、支払管理データ生成処理が行われる。支払管理データ生成処理では、ステップＳ２０５（図６）の債務設定受付処理の結果取得した支払対象金額（ａ）、保留金（ｂ）及び保留解除金（ｃ）に関する債務設定情報を用いて支払管理データが生成される。図８は、図２のステップＳ２０６の支払管理データ生成処理の詳細を示すサブルーチンである。

図８において、まず、ステップＳ８０１では、支払対象金額がゼロ以上であるかどうかを判別する。該判別の結果、支払対象金額がゼロ以上であれば（ステップＳ８０１でＹｅｓ）、ステップＳ８０２で内訳区分「０」のレコード（以下、「通常レコード」ともいう）を生成し、ステップＳ８０４へ進む。なお、支払対象金額がゼロの場合には、通常レコードの生成を省略してもよく、これによりデータ容量を削減することができる。他方、該判別の結果、支払対象金額がゼロ未満すなわちマイナスである場合には（ステップＳ８０１でＮｏ）、ステップＳ８０３で内訳区分「１」のレコード（以下、「控除レコード」ともいう）を生成し、ステップＳ８０４へ進む。内訳区分については後述する。ステップＳ８０２及びＳ８０３で生成されるレコードは、本処理で生成される支払管理データの一部を構成するレコードである。

図９は、図２のステップＳ８０２及びＳ８０３で生成されるレコードを含む支払管理データの構成例を模式的に示す図である。

図９に示される支払管理データは、債権者への債務履行のための支払予定金額に関する支払予定金額情報を含むレコードで構成される。支払予定金額は、プラス（出金）であってもマイナス（控除）であってもよい。図９に示すように、支払管理データは、支払予定金額情報のほかに、各レコードを識別するための識別情報（例えば、連番で付与される支払予定番号）、支払予定日に関する支払予定日情報、取引先の支払先に関する情報（例えば、支払先名）、債務設定情報に含まれる債務を識別するための債務識別情報（例えば、元伝票番号）、各レコードの区分（分類）を特定するための分類情報（例えば、内訳区分又はその区分名）及び支払予定金額の支払状態情報（例えば、支払状態名）を含んで構成される。支払予定日情報には、通常、出来高検収データにおける計上日に対して予め設定された会計月（例えば、翌会計月又は翌々会計月）の指定日がセットされる。ただし、後述するように、支払予定日情報として、計上予定日が定まっていないことを示す計上不可情報（例えば未来日付）をセットすることも可能である。また、債務識別情報として用いることが可能な元伝票番号は、出来高検収データにおける元伝票番号である。支払管理データが上述した情報を含むことにより、各レコードの支払予定金額について、その支払予定日や支払状態を把握することが可能となる。支払状態情報は、支払済及び未支払の一方から選択される。各レコードが生成された時点においては、支払状態情報として未支払がセットされ、各レコードの支払予定金額が支払予定日に支払を完了することで支払状態情報として支払済がセットされるようになっている。

ここで、内訳区分は、支払管理データにおいて、各レコードの区分（分類）を特定するための分類情報として各レコードにセットされる。内訳区分「０」は、支払対象金額（ａ）がプラスのレコード（通常の支払に関するレコード）を特定するための分類情報に該当する。したがって、ステップＳ８０２で生成される内訳区分「０」の通常レコードは、予め設定された会計月の債務履行対象（出金対象）となるレコードである。内訳区分「１」は、支払対象金額（ａ）がマイナスのレコード（控除に関するレコード）を特定するための分類情報に該当する。したがって、ステップＳ８０３で生成される内訳区分「１」の控除レコードは、予め設定された会計月の控除対象となるレコードである。内訳区分「２」及び「３」は、後述するように、保留金の保留状態を示す保留状態情報として機能する。そのため、支払管理データが保留状態情報を含むことにより、各レコードの保留金について、その保留状態を速やかに把握することが可能となり、また、後述するように集約データの生成を容易に行うことができるようになる。

続いて、ステップＳ８０４では、保留金レコードの生成が必要であるかどうかを判別する。具体的には、保留金（ｂ）がゼロ超であるかどうかを判別する。ステップＳ８０４の判別の結果、保留金レコードの生成が必要でない場合には（ステップＳ８０４でＮｏ）、以下に説明するステップＳ８０５の処理をスキップして、ステップＳ８０６へ進む。

ステップＳ８０４の判別の結果、保留金に関するレコードの生成が必要である場合には（ステップＳ８０４でＹｅｓ）、ステップＳ８０５に進んで、内訳区分「１」のレコード（すなわち控除に関するレコード）と、内訳区分「２」のレコード（以下、「支払保留レコード」ともいう）の１対のレコードを生成し、ステップＳ８０６へ進む。なお、図６を用いて説明したように、支払対象金額（ａ）がマイナスの場合には、保留金（ｂ）にはゼロがセットされるため、ステップＳ８０４において、保留金レコードの生成が必要であると判断されないようになっており、これにより、支払管理データにおいて、マイナスの支払対象金額（ａ）に由来する控除レコードと、保留金（ｂ）に由来する控除レコードとが併存しないようになっている。

ここで、ステップＳ８０５で生成される内訳区分「２」の支払保留レコードについて説明する。内訳区分「２」の支払保留レコードは、支払が保留状態にあることを示すレコードである。ステップＳ８０５では、保留金（ｂ）に由来して控除レコードが生成されるが、控除レコードの支払予定金額情報が示すマイナスの金額は、支払予定日が到来することにより保留金として積み上げられることになる。そこで、ステップＳ８０５では、保留金として積み上げられる金額（すなわちプラスの金額）を支払予定金額情報として登録した支払保留レコードが控除レコードと対となるように生成される。したがって、内訳区分「２」の支払保留レコードに含まれる支払予定金額情報が示すプラスの金額は、支払先への出金予定額ではなく、支払保留取崩可能額へ積み上げる予定の加算額に該当する。

また、ステップＳ８０６では、支払の保留解除金（ｃ）があるかどうかを判別する。具体的には、保留解除金（ｃ）がゼロ超であるかどうかを判別する。

ステップＳ８０６の判別の結果、保留解除金（ｃ）がある場合には（ステップＳ８０６でＹｅｓ）、ステップＳ８０７～Ｓ８１４において、保留解除金（ｃ）に基づき支払保留レコードの更新処理が行われる。この支払保留レコードの更新の結果、内訳区分「３」のレコード（以下、「支払保留解除レコード」ともいう）が生成される。支払保留レコードの更新処理の詳細については、後述する。そして、支払保留レコードの更新処理が完了したら、本処理を終了して図２へリターンして、ステップＳ２０７へ進む。

他方、ステップＳ８０６の判別の結果、保留解除金（ｃ）がない場合には（ステップＳ８０６でＮｏ）、ステップＳ８０７～Ｓ８１４の支払保留レコードの更新処理をスキップして、本処理を終了して図２へリターンして、ステップＳ２０７へ進む。

図８を用いて説明したように各レコードが追加されて支払管理データが生成されると、図２に戻り、ステップＳ２０７では、問合せ回答書又は支払通知書が必要であるかどうかを判別する。具体的には、ユーザによる必要書面の指示入力を待機する。ここで、問合せ回答書は、出来高検収を受けた債権者が、支払予定日までの間に、債務者に対して、当月又は翌月の支払予定金額（債権者にとっては入金見込金額）について問合せを行った場合に債務者が回答するための書面であり、この書面を受領することにより、債権者は、支払予定日前に、支払予定金額に出来高検収の結果が反映されていることを確認することができる。支払通知書は、債務者が支払（出金）を行う金額を債権者に対して通知するための書面であり、これにより、債権者が債務者に対して問合せを行う手間を省くことができる。

ステップＳ２０７の判別の結果、問合せ回答書又は支払通知書が必要である場合には（ステップＳ２０７でＹｅｓ）、ステップＳ２２１～Ｓ２２３で必要書面の作成処理を行い、ステップＳ２０８に進む。必要書面の作成処理については、後述する。他方、ステップＳ２０７の判別の結果、問合せ回答書又は支払通知書が必要でない場合には（ステップＳ２０７でＮｏ）、ステップＳ２２１～Ｓ２２３で必要書面の作成処理をスキップして、ステップＳ２０８に進む。

次に、ステップＳ２０８では、支払管理データに含まれる各レコードの支払予定金額につき、支払予定日が到来して、支払が完了したかどうかを判別する。支払の完了は、例えば、ファームバンキング（ＦＢ）による振込完了データを読み出して、支払管理データに含まれる情報（支払予定番号、支払予定日、支払先、支払予定金額等の情報）を検索することにより把握することができる。そして、ステップＳ２０８の判別の結果、支払が完了していない場合、例えば支払予定日がまだ到来していない場合には（ステップＳ２０８でＮｏ）、ステップＳ２０４に戻って、別の債務設定の受け付けを待機する。他方、支払が完了されたレコードがあった場合には（ステップＳ２０８でＹｅｓ）、ステップＳ２０９で当該レコードの支払状態情報に支払済をセット（すなわち未支払を支払済に更新）し、ステップＳ２１０の処理に進む。図１０には、図９に示した支払管理データの一部のレコードの支払状態情報が、図２のステップＳ２０９の処理の結果、支払済に更新された例が示されている。

ステップＳ２１０では、支払管理データに未支払のレコードがあるかどうかを判別する。未支払のレコードは、通常、支払保留レコードである。これは、先述のとおり、支払保留レコードの支払予定金額は、支払先への入金額（振込額）ではないからである。ステップＳ２１０の判別の結果、未支払のレコードがある場合には（ステップＳ２１０でＹｅｓ）、ステップＳ２１１で、取引先（支払先）ごとに未支払レコードの集計を行って、ステップＳ２１２で、支払保留のレコードの集計結果に基づき、支払保留取崩可能額を更新する。したがって、支払保留取崩可能額は、支払完了がなされるたびに更新されるので、支払保留取崩可能額を超える金額の保留解除（取崩）が実施されることを抑止することができる。

図１１は、図２のステップＳ２１１及びＳ２１２の処理を説明するために用いられる図であり、図１１（ａ）は、図２のステップＳ２１１で集計対象となる１群のレコードの一例を示しており、図１１（ｂ）は、図２のステップＳ２１２の処理の結果生成される支払保留取崩可能額を管理するためのデータの構成例を模式的に示す図である。図１１（ａ）に示した１群のレコードは、図１０における未支払のレコードで構成されている。図１１（ｂ）に示すように、図２のステップＳ２１２の処理が行われるたびに保留取崩可能額を管理するためのデータを生成・更新することが好ましく、これにより、任意のタイミングで読み出し可能に保存することができる。

そして、ステップＳ２１２で支払保留取崩可能額の更新がなされると、ステップＳ２０４の処理に戻り、別の債務設定、必要書面の要否、支払完了の各判別処理を待機する。他方、ステップＳ２１０の判別の結果、未支払のレコードがない場合には（ステップＳ２１０でＮｏ）、全てのレコードにつき支払が完了したことになるので、図２に示した処理を完了する。

なお、上述した図２、図６及び図８を用いた説明において、例えば、マスタ登録（メンテナンス）（ステップＳ２０１）、プロジェクト登録（ステップＳ２０２）、債権登録（ステップＳ２０３）、債務設定（ステップＳ２０４及び図６）、問合せ回答書又は支払通知書の作成（ステップＳ２２１～Ｓ２２３）は、任意のタイミングで実行されてもよく、つまり割込み処理可能な処理である。また、図８のステップＳ８０７～Ｓ８１４の支払保留レコードの更新処理は、支払保留データ管理装置として機能する他の情報処理装置において実行してもよい。

また、上述した説明では、１月に実施された出来高検収の結果が反映された支払管理データを新たに生成し、２月に支払保留レコード以外の支払完了する例を説明したが、翌月以降も継続して、同様の処理を適用することができる。

図１２は、図７に示した出来高検収データとは別の出来高検収データであって、翌月の出来高検収の結果の一例を模式的に示す図である。図１３は、図１２に示す出来高検収データに基づき生成される支払管理データを模式的に示す図である。ただし、図１３に示す支払管理データからは、便宜上、保留解除レコードは除かれている。このように、翌月についても、上述した説明と同様に支払管理データが生成される。

ここで、図１２に示す出来高検収データに示すように、支払保留取崩額（ｃ）が設定された場合、すなわち、図８のステップＳ８０６で支払保留解除があると判断された場合（ステップＳ８０６でＹｅｓ）について、図８を用いて説明する。

図８において、支払保留解除があると判断された場合（ステップＳ８０６でＹｅｓ）、支払保留解除レコードを生成するとともに（この時点で内訳区分は付加されていなくてもよく、また、支払予定日は任意の日付であってもよい）、既存の支払管理データの中から、対応する一又は複数の支払保留レコードの読み出しを行う（ステップＳ８０７）。対応する支払保留レコードとは、生成した支払保留解除レコードに含まれる発注番号、支払先及びプロジェクト番号が共通する支払保留レコード（以下、「対象支払保留レコード」ともいう）である。図１４は、図１２に示す出来高検収データに基づき、図８のステップＳ８０７の処理の結果生成された支払保留解除レコードの一例を模式的に示す図である。図１５は、図８のステップＳ８０７の処理の結果読み出された１群の対象支払保留レコードを模式的に示す図である。

続くステップＳ８０８では、ステップＳ８０７で読み出した１群の対象支払保留レコードの各々に、予め設定された複数の優先度（例えば、優先度の高い順に設定された「１」、「２」、「３」）の中から選ばれた優先度を設定する。図１６は、図１５に示した１群の対象支払保留レコードに優先度が付与された状態を模式的に示す図である。

優先度は、保留金額の計上日（出来高検収データにおける計上日）が近い順、又は、保留解除金額が保留金額の全額に近い順、又は、それらの組み合わせにより決定される順序を含み、さらに、支払予定日番号が示す数字が近い順を組み合わせて決定される順序であってもよい。例えば、対象支払保留レコードの保留金額の計上日（出来高検収データにおける計上日）が近い場合、対象支払保留レコードの支払予定金額（すなわち保留金額）が支払保留解除レコードの保留解除金額と同額又はそれ未満の金額である場合に、対象支払保留レコードに優先度「１」が設定される。また、対象支払保留レコードの保留金額の計上日（出来高検収データにおける計上日）が近くない場合（例えば、当月ではなく前月の出来高検収データに基づき生成した支払保留レコード）には、当該対象支払保留レコードに優先度「２」が設定される。

続いて、ステップＳ８０９では、優先度が設定された１群の対象支払保留レコードの中から優先度が高い一の対象支払保留レコードを選択する。同じ優先度が設定された複数の対象支払保留レコードがある場合には、任意の又は計上日若しくは保留金額が近い一の対象支払保留レコードが選択される。

そして、対象支払保留レコードが選択されると、当該対象支払保留レコード（内訳区分「２」）に含まれる保留金額情報に代えて、設定された保留解除金額情報がセットされ、かつ、保留状態情報として支払保留解除を示す情報（内訳区分「３」）がセットされた支払保留解除レコードを生成する（ステップＳ８１０）。さらに、この支払保留解除レコードには、支払予定日情報として、保留解除金額情報に対応する保留解除の計上日又は計上予定日に関する日付情報がセットされる。したがって、対象支払保留レコードには、通常、支払予定日情報として計上不可情報（未来日付）がセットされているのとは異なり、支払保留レコードには、支払予定日情報として実際の支払予定日に関する情報がセットされる。

図１７は、図８のステップＳ８０９において、図１６に示す１群の対象支払保留レコードの中から、３番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図１７（ａ）は、選択された対象支払保留レコードを模式的に示し、図１７（ｂ）は、図８のステップＳ８１０で、図１７（ａ）の対象支払保留レコードに対応して生成される支払保留解除レコードを模式的に示す図である。

続いて、ステップＳ８１１では、支払保留解除レコードの保留解除金額と対象支払保留レコードの保留金額の間にゼロ超の差額があるかどうかを判別する。ステップＳ８１１の処理の結果、ゼロ超の差額がない場合、つまり同額である場合、以下に説明するステップＳ８１２をスキップして、ステップＳ８１３の処理に進む。図１７に示した例では、対象支払保留レコードの支払予定金額と、支払保留解除レコードの支払予定金額は同額であるから、ステップＳ８１２の処理は行われない。

他方、ステップＳ８１１の処理の結果、ゼロ超の差額がある場合、すなわち保留金額が保留解除金額の一部である場合（ステップＳ８１１でＹｅｓ）、ステップＳ８１２で、保留解除金額から前記保留金額の差額を保留金額情報として含む支払保留レコード（以下、「差額支払保留レコード」ともいう）を新たに生成する。この差額支払保留レコードには、本実施形態では、内訳区分「２」がセットされる。このように差額支払保留レコードが生成されることにより、対象支払保留レコードの支払予定金額と、一対の支払保留解除レコード及び差額支払保留レコードの支払予定金額の合計とが同額となる。

図１８は、図８のステップＳ８０９において、図１６に示す１群の対象支払保留レコードの中から、１番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図１８（ａ）は、選択された対象支払保留レコードを模式的に示し、図１８（ｂ）は、図８のステップＳ８１０で、図１８（ａ）の対象支払保留レコードに対応して生成される支払保留解除レコードと、図８のステップＳ８１２で、差額に応じて生成される支払保留レコードとを模式的に示す図である。図１９は、図８のステップＳ８０９において、図１６に示す１群の対象支払保留レコードの中から、２番目の対象支払保留レコードが選択された場合における支払管理データの更新を説明するための図であり、図１９（ａ）は、選択された対象支払保留レコードを模式的に示し、図１９（ｂ）は、図８のステップＳ８１０で、図１９（ａ）の対象支払保留レコードに対応して生成される支払保留解除レコードと、図８のステップＳ８１２で、差額に応じて生成される支払保留レコードとを模式的に示す図である。図１８及び図１９にも示されるように、対象支払保留レコードの支払予定金額と、一対の支払保留解除レコード及び差額支払保留レコードの支払予定金額の合計とは同額である。

ステップＳ８１３では、対象支払保留レコードの削除を行う。図１７～図１９に示した例では、図１７（ａ）に示す対象支払保留レコード、図１８（ａ）に示す対象支払保留レコード及び図１９（ａ）に示す対象支払保留レコードが削除される。これにより、支払保留解除レコードを生成したことにともなう支払保留レコードの更新（対象支払保留レコードの削除及び差額支払保留レコードの生成）が完了する。そして、ステップＳ８１４の処理に進み、他の対象支払保留レコードがある場合には（ステップＳ８１４でＹｅｓ）、ステップＳ８０９に戻って、他の対象支払保留レコードを選択して、上述したステップＳ８１０～Ｓ８１４の処理を行う。そして、他の対象支払保留レコードがなくなった場合には（ステップＳ８１４でＮｏ）、本処理を完了して、図２にリターンし、ステップＳ２０７以降の処理を行う。

ここで、２つの対象支払保留レコードの支払予定金額が１つの支払保留解除レコードの支払予定金額と同額となる場合の例外的な処理について、図２０～図２２を用いて説明する。

図２０は、例示的な出来高検収データを模式的に示す図である。図２１は、図２０の出来高検収データに基づき読み出された２つの対象支払保留レコードであって優先度が設定されたものを模式的に示す図である。図２２は、図２１に示す２つの対象支払保留レコードの更新を説明するための図であり、図２２（ａ）は、更新前の２つの対象支払保留レコードを模式的に示し、図２２（ｂ）は、図２２（ａ）の２つの対象支払保留レコードに対応して更新後に生成される２つの支払保留解除レコードを模式的に示す図である。

図２０～図２２に示す例では、出来高検収データにおける支払保留取崩額「３１，０００」が、更新前に存在した支払予定金額「１，０００」及び「３０，０００」の２つの対象支払保留レコードに応じて、更新後には、支払保留解除金額「１，０００」と、支払保留解除金額「３０，０００」の２つの支払保留解除レコードとして生成されている。上述した図８の説明によれば、優先度に基づき、２つの対象支払保留レコードを順次更新することになるため、中間的には、支払保留解除金額「１，０００」の支払保留解除レコードと、支払予定金額「３０，０００」の差額支払保留レコードが生成されるものの、前者の差額支払保留レコードも対象支払保留レコードとして選択される結果、最終的には、支払保留解除金額「３０，０００」の支払保留解除レコードが生成し、差額支払保留レコードは削除されることとなり、結果的に、図２２（ｂ）に示す２つの支払保留解除レコードが生成される。そこで、上述した図８の処理に代えて、中間的に生成されうる差額支払保留レコードに対応する優先度が低い対象支払保留レコード（図２１に示す２番目の優先度「２」のレコード）において、支払予定日及び内訳区分を変更することにより、最終的に生成されうる支払保留解除レコード（図２２（ｂ）に示す２番目のレコード）を生成するように処理を行ってもよい。これにより、更新処理に係る負荷を軽減することができる。

続いて、図２のステップＳ２２１～Ｓ２２３で実行される必要書面の作成処理について説明する。この処理は、ステップＳ２０７の判別の結果、必要書面（問合せ回答書又は支払通知書）の作成が必要な場合（ステップＳ２０７でＹｅｓ）、具体的にはユーザにより必要書面の作成が指示された場合に実行される。

まず、ステップＳ２２１では、支払管理データに基づき、必要書面に応じた集約データを所定のフォーマットで生成する。集約データとは、支払管理データの中から、指定された債権者のレコードを集約したデータである。

続いて、ステップＳ２２２では、ステップＳ２２１で生成した集約データの出力を行うかどうか判別する。具体的には、ユーザによる出力指示を待機する。ステップＳ２２２の判別の結果、集約データの出力を行わない場合には（ステップＳ２２２でＮｏ）、必要に応じて集約データを読み出し可能に保存し、ステップＳ２０８以降の判別処理を行う。他方、ステップＳ２２２の判別の結果、集約データの出力を行う場合には（ステップＳ２２２でＹｅｓ）、ステップＳ２２３で集約データの出力を行い、その後、ステップＳ２０８以降の判別処理を行う。

ここで、集約データの出力とは、印刷、無線又は有線を介した送信及び所定の表示画面への表示を含む。集約データは出力されることにより、当該集約データに応じて予め設定された帳票データとして出力されることになる。帳票データとしては、問合せ回答書又は支払通知書に対応する帳票データが挙げられる。ただし、帳票の名称は任意である。そのため、問合せ回答書に対応する帳票データを、例えば未払金集約データと称してもよいし、支払通知書に対応する帳票データを、例えば支払保留金集約データと称してもよい。すなわち、支払管理データから集約データを生成することにより、任意の管理データ又は帳票データを出力することが可能である。本実施形態では、支払管理データが、支払保留状態情報及び支払状態情報を含むので、それらの一方又は双方を含む集約データを生成することが可能である。そのような情報を含む集約データを生成することにより、ユーザは出力することでそれら情報の一覧性を向上させることができる。例えば、支払保留解除に関する情報を含む帳票は、それを受領した債権者（単位事業の受注者）にとって単位事業の出来高が評価されたこと又はその進捗が良好であることを視覚的に把握できることになるという点で、支払保留解除金額が単に支払予定金額に上乗せされた従来の帳票に比べて好ましい。また、支払済又は未支払に関する情報を含む帳票は、例えば、管理者が支払（振込）の進捗管理を行ううえで利点がある。

以上詳細に説明したように、図２、図６及び図８に示した一連の処理によれば、支払管理データ生成装置１００は、債権設定データ（例えば所定の入力画面を介して受け付けた情報、又は、出来高検収データ）に基づいて（ステップＳ２０５）、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを自動的に生成する（ステップＳ２０６）（支払管理データ生成手段）。ここで、支払管理データは、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を少なくとも含み、前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る。そして、債務設定データは、前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含んでおり、当該債務設定データが、さらに、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードが追加されて（ステップＳ８０５又はステップＳ８１０）、前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データが生成される。したがって、支払管理データには支払保留状態情報が含まれているので、ユーザにとっては、支払保留状態情報を個別に又は別途に管理する必要がなくなり、債権者への支払内容の管理の利便性を向上させることができる。

さらに利便性を向上させるために、支払管理データに、さらに、前記単位債務を識別する情報（例えば、プロジェクト番号に枝番等の付加情報）を含ませることが可能であり、これにより、単位債務（単位事業）ごとの管理も行うことができる。また、さらに利便性を向上させるために、支払予定データ、前記支払管理データ及び集約データに、前記支払予定金額情報に対応する支払予定金額、前記支払保留金額情報に対応する支払保留金額及び前記支払保留解除金額情報に対応する支払保留解除金額についての支払済若しくは未支払を示す支払状態情報を含ませることが可能であり、支払状態も管理することが可能である。

また、さらに利便性を向上させるために、支払管理データに基づき、前記債権者のレコードを集約した集約データ（後述する未払金集約データや支払保留金集約データ）を所定のフォーマットで生成することも可能であり(ステップＳ２２１)、これにより、さまざまな出力結果を得ることが可能となる（ステップＳ２２３）（出力手段）。

また、図８に示したステップＳ８０６～Ｓ８１４の一連の支払保留レコードの更新処理によれば、支払保留データ管理装置としても機能する支払管理データ生成装置１００は、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払の支払保留金額に関する支払保留データを管理するに際し、前記債権者への支払を保留する支払保留金額の一部又は全部に対する支払保留解除金額又は支払保留金額の総額に対する支払保留対象割合に関する支払保留解除金額情報が設定された場合に、前記支払保留データにおいて当該支払保留金額に関する支払保留金額情報を含む対象支払保留レコードの更新を行う（支払保留データ更新手段）。支払保留データの更新に際し、前記対象支払保留レコードに含まれる前記支払保留金額に関する支払保留金額情報に代えて、前記設定された支払保留解除金額情報がセットされ、かつ、支払保留状態情報として支払保留解除を示す情報がセットされた支払保留解除レコードが少なくとも自動的に生成される（ステップＳ８１０）。したがって、ユーザは、保留金の一部又は全部の解除が生じた場合に、その保留解除金の管理の利便性を向上させることができる。

ここで、上述のとおり、支払管理データ生成装置１００は、支払保留データ管理装置としても機能するので、支払保留データ管理装置としての機能（例えば、ステップＳ８０６～Ｓ８１４の一連の支払保留レコードの更新処理を実行する機能）を他の情報処理装置が実現してもよい。すなわち、支払保留データ管理装置は、単独の情報処理装置として提供されてもよい。この場合、対象支払保留レコード及び支払保留解除レコードは、支払保留状態情報を含んでいなくてもよい。支払保留データ管理装置が提供されるのと同様に、支払保留データ管理方法、及び支払保留データ管理プログラムも提供される。

さらに利便性を向上させるために、前記支払保留解除レコードに、前記支払保留解除金額情報に対応する支払保留解除の計上日又は計上予定日に関する日付情報がセットされる（ステップＳ８１０）。

さらに利便性を向上させるために、前記支払保留解除金額が前記支払保留金額の一部である場合には（ステップＳ８１１でＹｅｓ）、前記支払保留金額から前記支払保留解除金額の差額を支払保留金額情報として含む差額支払保留レコードが新たに生成される（ステップＳ８１２）。

さらに利便性を向上させるために、前記差額支払保留レコードに、支払保留解除の計上日又は計上予定日が定まっていないことを示す計上不可情報がセットされる（ステップＳ８１２）。

また、支払保留データの更新に際し、前記支払保留データに、前記対象支払保留レコードが一つ又は複数存在する場合には、当該１群の対象支払保留レコードの各々に、予め設定された複数の優先度の中から選ばれた優先度が設定される。これにより優先度の高い対象支払保留レコードから処理が進められることになる。ここで、前記複数の優先度は、前記支払保留金額の計上日が近い順、又は、前記支払保留金額が前記支払保留解除金額の全額に近い順、又は、それらの組み合わせにより決定される順序を含む。これにより、効率的に処理を進めることができる。

また、前記支払保留データの更新が完了した場合に、前記対象支払保留レコードが削除される（ステップＳ８１３）。これにより、データ容量を削減することができる。

また、図６の処理によれば、前記支払保留金額の総額を超える支払保留解除金額に関する支払保留解除金額情報が設定されることが規制される（ステップＳ６０９でＮｏ及びステップＳ６５０）（保留解除規制手段）。これにより、適正な支払保留解除金額の支払保留解除レコードについて図８に示したステップＳ８０６～Ｓ８１４の一連の支払保留レコードの更新処理を実行することができる。

なお、上述した説明では、前記プロジェクトが複数の単位事業を含む請負業務であり、前記一又は複数の単位債務の債務者が前記請負業務の請負人であり、かつ、前記債権者が前記単位事業の下請負人であり、前記債務設定データが前記プロジェクトの出来高検収の結果を示す出来高検収データである場合を例に挙げたがこれに限られることはなく、支払管理上、支払保留又は支払保留の解除（取崩）が生じる場面において適用可能である。

続いて、上述した一連の処理の具体例を、図面を用いながら説明する。

図２３に示すような発注データがあるプロジェクトにおいて（ステップＳ２０２～Ｓ２０３）、図２４に示すような出来高検収データがある場合（ステップＳ２０４）、図２５に示すような支払管理データが生成される。ここで、図２４に示す出来高検収データでは、図７に示した出来高検収データとは異なり、支払保留取崩額の設定がなされており、これに応じて、図２５に示す支払管理データには、支払保留解除レコードが含まれている。なお、図２５に示す支払管理データには、前会計月の支払完了にともない支払状態情報が支払済を示すレコードも含まれている。

ここで、図２５に示す支払管理データに含まれる内訳区分「２」及び「３」のレコード（すなわち支払保留状態情報を含むレコードのみ）を集約し、さらに図２４に示した出来高検収データに含まれる情報を結合することにより、図２６に示すような支払保留金集約データを得ることができる（ステップＳ２２１）。支払保留金集約データは、図２６に示されるように、計上日、内訳区分及び支払状態に関する情報を含むので、例えば、未支払のレコードにおいて、支払保留が長期にわたっていないかどうかをチェックすることができるようになる。

そして、支払完了が確認されると、図２４に示した支払管理データは、図２７に示すように更新される。

以下に、集約データ及び対応する帳票の複数の例を説明する。

図２８は、図２のステップＳ２２１で作成される集約データの第１の例を模式的に示す図である。図２９は、図２８に示す集約データに基づき作成される帳票の構成例を示す図である。図２８に示す集約データは、支払保留金集約データであり、支払保留及び未支払がセットされたレコードを集約することにより得ることができる。図２９に示す帳票は、図２８に示す集約データに含まれる情報をプロジェクト単位でかつ債権者単位（支払先単位）に並べたものである。このような帳票を出力することにより、ユーザは、支払保留の状況を速やかに確認することができるようになる。また、このような帳票の一部を出力することにより、債権者からの問合せ回答書を速やかに用意することが可能となる。これに代えて、問合せのあった債権者のレコードを集約することによっても問合せ回答書を速やかに用意することが可能となる。

図３０は、図２のステップＳ２２１で作成される集約データの第２の例を模式的に示す図である。図３１は、図３０に示す集約データに基づき作成される帳票の構成例を示す図である。図３０に示す集約データは、図２８に示したのと同様に支払保留及び未支払がセットされたレコードを集約することにより得ることができる支払保留金集約データであり、この例では、さらに、支払保留解除がセットされたレコードを含む。したがって、図３１に示す帳票も支払保留解除に関する情報を含む。このような帳票を出力することにより、ユーザは、支払保留解除がなされた単位事業を把握することができるようになるので、例えば、プロジェクトを構成する複数の単位事業の中から、進捗が良好な単位事業（支払保留解除が実施された単位事業）を速やかに把握することができる。

図３２は、図２のステップＳ２２１で作成される集約データの第３の例を模式的に示す図である。図３３は、図３２に示す集約データに基づき作成される帳票の構成例を示す図である。図３２に示す集約データは、図３０に示したのと同様に支払保留、支払保留解除及び未支払がセットされたレコードを集約することにより得ることができる支払保留金集約データであり、この例では、さらに、支払済がセットされたレコードを含む。したがって、図３３に示す帳票も支払済に関する情報を含む。このような帳票を出力することにより、ユーザは、支払済の支払先を容易に把握することができ、支払管理を適切に行うことができるようになる。また、このような帳票を出力することにより、ユーザは、債権者から支払済かどうかの問合せがあった場合に、容易に回答することができる。

図３４は、図２のステップＳ２２１で作成される集約データの第４の例を模式的に示す図である。図３５は、図３４に示す集約データに基づき作成される帳票の構成例を示す図であり、図３５（ａ）は、第１の支払先に対する支払通知書の例を示し、図３５（ｂ）は、第２の支払先に対する支払通知書の例を示し、図３５（ｃ）は、第３の支払先に対する支払通知書の例を示す図である。図３４に示す集約データは、支払保留金集約データであり、支払管理データと出来高検収データとを結合したデータから、支払予定日が２月２０日となる会計期間に計上日（出来高検収データに含まれる計上日）があるレコードを集約することにより得ることができる。これにより、支払予定日情報に計上不可情報がセットされている支払保留レコードも集約することができる。このため、図３５（ａ）、図３５（ｂ）及び図３５（ｃ）に示すように、各支払先への支払通知書に少なくとも保留金の控除額を含ませることができるようになる。

図３６は、図２のステップＳ２２１で作成される集約データの第５の例を模式的に示す図である。図３７は、図３６に示す集約データに基づき作成される帳票の構成例を示す図であり、図３７（ａ）は、第１の支払先に対する支払通知書の例を示し、図３７（ｂ）は、第２の支払先に対する支払通知書の例を示し、図３７（ｃ）は、第３の支払先に対する支払通知書の例を示す図である。図３６に示す集約データは、図３４に示した支払保留金集約データと同様に生成することが可能であり、図３６に示す例では、さらに支払保留解除レコードも集約されている。このため、図３５（ａ）、図３５（ｂ）及び図３５（ｃ）に示すように、各支払先への支払通知書に保留金の控除額及び解除額の双方を含ませることができるようになる。

図３８は、図２のステップＳ２２１で作成される集約データの第６の例を模式的に示す図である。図３９は、図３８に示す集約データに基づき作成される集約データを模式的に示す図であり、図３９（ａ）は、第１の単位事業に関する集約データの例を示し、図３９（ｂ）は、第２の単位事業に関する集約データの例を示す図である。図３８に示す集約データは、プロジェクトを構成する単位事業ごとに支払金を集計することにより生成される。図３９（ａ）及び図３９（ｂ）に示す集約データは、図３８に示す集約データの一部（単位事業ごとの集約データ）を抽出することにより生成される。図３８及び図３９に示すように、本実施形態によれば、単位事業ごとの支払金も容易に把握することができるようになる。

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

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

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

また、支払管理データ生成装置１００及び支払管理データ生成システム１０００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

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

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

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

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

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

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

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

本発明は、支払管理を行う際において有用であり、特に支払保留又は支払保留解除を含む支払管理を行う際において有用である。

１００ 支払管理データ生成装置
１０２ 制御部
１０２Ａ 保留解除規制部
１０２Ｂ 支払管理データ生成部
１０２ｂ 支払保留データ更新部
１０２Ｃ 出力部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ プロジェクトマスタ
１０６ｂ 債権者マスタ
１０６ｃ 債務設定データ記憶領域
１０６ｄ 支払管理データ記憶領域
１０６ｅ 集約データ記憶領域
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク
１０００ 支払管理データ生成システム

Claims (10)

1. 複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを生成するための、制御部を備える支払管理データ生成装置であって、
   前記制御部は、
   前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る支払管理データを生成する支払管理データ生成手段
   を含み、
   前記支払管理データ生成手段は、
   前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含む債務設定データが、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、
   前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードを追加することにより、
   前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データを生成する
   ことを特徴とする支払管理データ生成装置。
2. 前記支払管理データは、さらに、前記単位債務を識別する情報を含む
   ことを特徴とする請求項１に記載の支払管理データ生成装置。
3. 前記支払管理データ生成手段は、
   前記支払管理データに基づき、前記債権者のレコードを集約した集約データを所定のフォーマットで生成する
   ことを特徴とする請求項１又は２に記載の支払管理データ生成装置。
4. 支払予定データ、前記支払管理データ及び集約データは、前記支払予定金額情報に対応する支払予定金額、前記支払保留金額情報に対応する支払保留金額及び前記支払保留解除金額情報に対応する支払保留解除金額についての支払済若しくは未支払を示す支払状態情報を含む
   ことを特徴とする請求項３に記載の支払管理データ生成装置。
5. 前記支払管理データ生成手段は、
   前記支払管理データに含まれる前記支払状態情報が未支払を示す前記債権者のレコードを集約した未払金集約データを前記集約データとして生成する
   ことを特徴とする請求項４に記載の支払管理データ生成装置。
6. 前記支払管理データ生成手段は、
   前記支払管理データに含まれる前記支払保留状態情報を含む前記債権者のレコードを集約した支払保留金集約データを前記集約データとして生成する
   ことを特徴とする請求項３又は４に記載の支払管理データ生成装置。
7. 前記制御部は、
   データを出力する出力手段
   をさらに備え、
   前記出力手段は、
   前記集約データを当該集約データに応じて予め設定された帳票データとして出力する
   ことを特徴とする請求項３～６のいずれか１項に記載の支払管理データ生成装置。
8. 前記プロジェクトは、複数の単位事業を含む請負業務であり、
   前記一又は複数の単位債務の債務者は、前記請負業務の請負人であり、かつ、
   前記債権者は、前記単位事業の下請負人であり、
   前記債務設定データは、前記プロジェクトの出来高検収の結果を示す出来高検収データである
   ことを特徴とする請求項１～７のいずれか１項に記載の支払管理データ生成装置。
9. 制御部を備えた情報処理装置において実行される、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを生成するための支払管理データ生成方法であって、
   前記制御部において実行される、
   前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る支払管理データを生成する支払管理データ生成ステップ
   を含み、
   前記支払管理データ生成ステップでは、
   前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含む債務設定データが、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、
   前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードを追加することにより、
   前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データを生成する
   ことを特徴とする支払管理データ生成方法。
10. 制御部を備えた情報処理装置において実行される、複数の会計月にまたがり得る一又は複数の単位債務を生じるプロジェクトについて一又は複数の債権者への支払内容に関する支払管理データを生成するための支払管理データ生成プログラムであって、
    前記制御部において実行させるための、
    前記プロジェクトについて前記債権者へ支払う予定の支払予定金額又は控除予定金額に関する支払予定金額情報を含む支払管理データであって、前記債権者への支払を保留する支払保留金額に関する支払保留金額情報及び当該支払保留金額の支払保留又は支払保留解除を示す支払保留状態情報を含み得る支払管理データを生成する支払管理データ生成ステップ
    を含み、
    前記支払管理データ生成ステップでは、
    前記プロジェクトについて任意の又は特定のタイミングで決定された前記債権者へ支払うべき支払対象金額又は当該支払対象金額に対する支払対象割合に関する支払対象金額情報を少なくとも含む債務設定データが、前記タイミングで決定された前記債権者への支払を保留する支払保留金額又は前記支払対象金額に対する支払保留対象割合に関する支払保留金額情報、及び、前記タイミングで決定された支払保留解除金額又は支払保留金額の総額に対する支払保留解除対象割合に関する支払保留解除金額情報の少なくとも一方を含む場合には、
    前記支払予定金額情報を少なくとも含むレコードに加えて、前記支払保留金額情報及び前記支払保留状態情報が支払保留を示す情報を含む支払保留レコード、又は、前記支払保留解除金額情報及び前記支払保留状態情報が支払保留解除を示す情報を含む支払保留解除レコードを追加することにより、
    前記支払管理データとして、前記支払保留状態情報を含むレコードを含む支払管理データを生成する
    ことを特徴とする支払管理データ生成プログラム。

Images