JP7356314B2 - Payment pending data management device, payment pending data management method, and payment pending data management program - Google Patents

Description

The present invention relates to a payment reservation data management device, a payment reservation data management method, and a payment reservation data management program.

Patent Document 1 states that in a construction contract performance management system, when a contractor inputs the "volume quantity" and "volume rate", the "payment amount" is calculated as 90% of the volume amount, and the remaining 10% is a retained amount. It is disclosed that the information is retained in a file (paragraph [0013] and FIG. 3(b)). Further, Patent Document 1 states that the retention money is paid in a lump sum after the construction is completed (paragraph [0013]).

Patent Document 2 discloses that in a construction payment processing device, in order to divide and manage the retained money at the time of acceptance inspection, negative details and positive details of the retained amount are registered, and the initial scheduled payment date is set on the scheduled payment date of the negative details. , setting a future date for the scheduled payment date of the Plus statement (paragraphs [0037], [0041]), and setting the future date of the Plus statement when the payment hold is released in response to a user operation via the UI. Changing the date to the actual scheduled payment date (paragraphs [0042]-[0043]) is disclosed.

JP2007-047948A JP 2019-032779 Publication

Here, the retention money is not necessarily paid in a lump sum after the construction is completed. In other words, part or all of the retained money may be paid (reversed) at any timing. In this regard, in the technology described in Patent Document 2, the retained money is managed using a future date, and it is possible to change the future date to the scheduled payment date in order to release the retained money at any time. be.

However, if the hold money is managed only by date on the device, for the user, for example, the scheduled payment amount between the release of the hold money and the actual payment is a normal payment (for example, a monthly payment). There are problems in that it is difficult to ascertain whether the payment is due to the release of the hold, or whether there is a balance in the hold money after the hold money is released, or whether there is a balance in the hold money or not. Such problems similarly arise when managing debt.

Therefore, the first problem is that there is a need to improve the convenience of managing the details of payments to creditors that may cause retention money or release of retention money. Once the first issue is resolved, there will be no communication between creditors and debtors regarding the retention money or the release of the retention money (e.g., the creditor will contact the debtor with an inquiry about the retention release money, or the debtor will contact the debtor with regard to the release of the retention money). It is hoped that notifications of suspension cancellation fees to those who are eligible for suspension will be carried out smoothly.

In addition, there is a second problem in that when part or all of the hold money is released, it is required to improve the convenience of managing the hold release money. If the second problem is solved, it is expected that the suspension release money will be managed appropriately regardless of whether it is part or all of the suspension money.

The present invention has been made in view of the above-mentioned problems, and provides a payment management data generation device, a payment management data generation method, and payment management data that can improve the convenience of managing payment details to creditors. The first purpose is to provide a generation program.

The present invention has been made in view of the above-mentioned problems, and the present invention is based on payment hold data that can improve the convenience of managing hold release money when part or all of hold money is released. A second object of the present invention is to provide a management device, a payment reservation data management method, and a payment reservation data management program.

In order to solve the above-mentioned problems and achieve the first objective, the payment management data generation device according to the present invention generates one or more debts for a project that generates one or more unit debts that can span multiple accounting months. A payment management data generation device comprising a control unit for generating payment management data regarding payment details to a person, the control unit is configured to generate payment management data regarding payment details to the creditor for the project, and the control unit is configured to generate payment management data regarding payment details to the creditor for the project. Payment management data including scheduled payment amount information regarding the payment suspension amount for which payment to the creditor is suspended, and payment suspension status information indicating payment suspension or release of payment suspension for the payment suspension amount. The payment management data generation means generates payment management data that may include payment management data, and the payment management data generation means generates a payment amount to be paid to the creditor determined at any or a specific timing for the project or the payment amount The debt setting data, which includes at least information on the amount to be paid regarding the ratio of the amount to be paid to the amount, is a payment retention amount for suspending payment to the creditor determined at the timing, or a payment retention amount regarding the ratio of the payment retention target to the amount to be paid. information, and at least one of the payment hold release amount information regarding the payment hold release amount determined at the timing or the payment hold release amount information regarding the ratio of the payment hold release target to the total payment hold amount, a record that includes at least the scheduled payment amount information. In addition, the payment hold record includes information in which the hold amount information and the payment hold status information indicate payment hold, or the payment hold release amount information and the payment hold status information include information indicating payment hold release. By adding a hold release record, payment management data including a record including the payment hold status information is generated as the payment management data.

Furthermore, the payment management data generation device according to the present invention is characterized in that the payment management data further includes information identifying the unit obligation.

Further, the payment management data generation device according to the present invention is characterized in that the payment management data generation means generates aggregated data in which the records of the creditors are aggregated in a predetermined format based on the payment management data. .

Furthermore, in the payment management data generation device according to the present invention, the payment schedule data, the payment management data, and the aggregate data include a scheduled payment amount corresponding to the scheduled payment amount information, and a payment reservation amount corresponding to the payment reservation amount information. and payment status information indicating whether the payment hold release amount corresponding to the payment hold release amount information has been paid or unpaid.

Furthermore, in the payment management data generation device according to the present invention, the payment management data generation means generates outstanding accounts aggregation data that is aggregation of records of the creditors in which the payment status information included in the payment management data indicates unpaid. It is characterized in that it is generated as the aggregated data.

Furthermore, in the payment management data generation device according to the present invention, the payment management data generation means generates payment retention money aggregate data that aggregates records of the creditors including the payment retention state information included in the payment management data. It is characterized in that it is generated as the aggregated data.

Furthermore, in the payment management data generation device according to the present invention, the control section further includes an output means for outputting data, and the output means converts the aggregated data into preset form data according to the aggregated data. It is characterized by outputting as .

Furthermore, in the payment management data generation device according to the present invention, the project is a contract work including a plurality of unit projects, and the debtor of the one or more unit debts is a contractor of the contract work, Further, the creditor is a subcontractor of the unit business, and the debt setting data is performance acceptance data indicating the result of performance inspection of the project.

Further, the payment management data generation method according to the present invention is performed in an information processing device equipped with a control unit, and is provided to one or more creditors for a project that generates one or more unit debts that can span multiple accounting months. A payment management data generation method for generating payment management data regarding payment details, wherein the payment management data generation method is executed in the control unit, and is executed in the control unit, and the payment management data generation method is executed in the control unit, and is executed in the control unit. Payment management data including information, which may include payment retention amount information regarding the payment retention amount for which payment to the creditor is withheld, and payment retention status information indicating payment retention or release of the payment retention amount for the payment retention amount. The payment management data generation step includes a payment management data generation step that generates data, and in the payment management data generation step, the amount to be paid to the creditor determined for the project at any time or at a specific timing, or the amount to be paid for the amount to be paid. Debt setting data including at least information on the amount to be paid regarding the ratio, the amount to be suspended for which the payment to the creditor is to be withheld determined at the timing, or information on the amount to be suspended for payment regarding the ratio of the amount to be paid to the amount to be paid, and If it includes at least one of the payment hold release amount information regarding the payment hold release amount determined at the timing or the ratio of the payment hold release target to the total payment hold amount, in addition to the record that includes at least the scheduled payment amount information, A payment hold record including information in which the hold amount information and the payment hold status information indicate payment hold, or a payment hold release record including information in which the payment hold release amount information and the payment hold status information indicate payment hold release. By adding, payment management data including a record including the payment pending state information is generated as the payment management data.

Further, the payment management data generation program according to the present invention is executed in an information processing device equipped with a control unit, and is provided to one or more creditors for a project that generates one or more unit debts that can span multiple accounting months. A payment management data generation program for generating payment management data regarding payment details, the program being executed by the control unit, for generating a payment schedule regarding the scheduled payment amount or scheduled deduction amount to be paid to the creditor regarding the project. Payment management data that includes amount information, which may include payment retention amount information regarding the payment retention amount for which payment to the creditor is withheld, and payment retention status information indicating payment retention or release of the payment retention amount for the payment retention amount. A payment management data generation step for generating management data, wherein the payment management data generation step includes a payment amount to be paid to the creditor determined at any or a specific timing for the project, or a payment for the payment amount. Debt setting data including at least payment target amount information regarding the target ratio, the payment retention amount for withholding payment to the creditor determined at the timing, or the payment retention amount information regarding the payment retention target ratio for the payment target amount, and , if it includes at least one of the payment hold release amount information determined at the timing or the payment hold release amount information regarding the ratio of the payment hold release target to the total payment hold amount, in addition to the record that includes at least the scheduled payment amount information. , a payment hold record including information in which the hold amount information and the payment hold status information indicate payment hold, or a payment hold release record including information in which the payment hold release amount information and the payment hold status information indicate payment hold release. By adding , payment management data including a record including the payment pending state information is generated as the payment management data.

In order to solve the above-mentioned problems and achieve the second objective, the payment retention data management device according to the present invention manages one or more debts for a project that generates one or more unit debts that can span multiple accounting months. A payment reservation data management device comprising a control section for managing payment reservation data regarding a payment reservation amount for a payment to the creditor, the control section managing one of the payment reservation amounts for which payment to the creditor is withheld. When the payment hold release amount information regarding the payment hold release amount for part or all or the payment hold target ratio to the total payment hold amount is set, the target payment that includes the payment hold amount information regarding the payment hold amount in the payment hold data. The payment hold data update means updates the hold record, and the payment hold data update means updates the set payment hold release in place of the payment hold amount information regarding the payment hold amount included in the target payment hold record. The payment suspension data is updated by at least generating a payment suspension release record in which amount information is set and information indicating payment suspension release is set as payment suspension state information.

Further, in the payment hold data management device according to the present invention, the payment hold data updating means adds date information regarding the recording date or scheduled recording date of the payment hold release corresponding to the payment hold release amount information to the payment hold release record. It is characterized by setting.

Further, in the payment hold data management device according to the present invention, when the payment hold release amount is a part of the payment hold release amount, the payment hold release amount is changed from the payment hold release amount to the payment hold release amount. The present invention is characterized in that a difference payment reservation record is newly generated that includes the difference in amount as payment reservation amount information.

Furthermore, in the payment retention data management device according to the present invention, the payment retention data updating means sets, in the difference payment retention record, non-accountable information indicating that the recording date or scheduled recording date of release of payment retention is not determined. It is characterized by

Further, in the payment pending data management device according to the present invention, when the payment pending data updating means includes one or more target payment pending records in the payment pending data, the payment pending data management device updates one or more target payment pending records. The present invention is characterized in that a priority selected from among a plurality of preset priorities is set for each payment reservation record .

Furthermore, in the payment hold data management device according to the present invention, the plurality of priorities are set in the order of the closest recording date of the payment hold amount, or the order in which the payment hold amount is closer to the full amount of the payment hold release amount, or , an order determined by a combination thereof.

Further, the payment reservation data management device according to the present invention is characterized in that the payment reservation data updating means deletes the target payment reservation record when updating of the payment reservation data is completed.

Further, in the payment hold data management device according to the present invention, the control unit further includes a hold release regulation means that restricts setting of payment hold release amount information regarding a payment hold release amount that exceeds the total amount of the payment hold amounts. It is characterized by containing.

Further, in the payment pending data management device according to the present invention, the project is a contract work including a plurality of unit projects, and the debtor of the one or more unit debts is a contractor of the contract work, and , the creditor is a subcontractor of the unit business.

Further, the payment pending data management method according to the present invention is executed in an information processing device equipped with a control unit, and is performed to one or more creditors regarding a project that generates one or more unit debts that can span multiple accounting months. A payment pending data management method for managing payment pending data regarding a payment pending amount of a payment, the method being executed in the control unit, for a part or all of the payment pending amount for which payment to the creditor is to be withheld. When payment hold release amount information regarding the payment hold release amount or the payment hold target ratio to the total payment hold amount is set, updating the target payment hold record that includes the payment hold amount information regarding the payment hold amount in the payment hold data. In the payment hold data update step, the set payment hold release amount information is set in place of the payment hold amount information regarding the payment hold amount included in the target payment hold record. The present invention is characterized in that the payment suspension data is updated by generating at least a payment suspension release record in which information indicating payment suspension release is set as payment suspension status information.

Further, the payment reservation data management program according to the present invention is executed in an information processing device equipped with a control unit, and is provided to one or more creditors regarding a project that generates one or more unit debts that can span multiple accounting months. A payment retention data management program for managing payment retention data regarding the payment retention amount of the payment, the program being executed by the control unit, part or all of the payment retention amount for which payment to the creditor is suspended. When the payment hold release amount information regarding the payment hold release amount or the payment hold target ratio to the total payment hold amount is set, the target payment hold record that includes the payment hold amount information regarding the payment hold amount in the payment hold data is set. It includes a payment hold data update step for updating, and in the payment hold data update step, the set payment hold release amount information is used instead of the payment hold amount information regarding the payment hold amount included in the target payment hold record. The payment suspension data is updated by generating at least a payment suspension release record in which information indicating payment suspension release is set as payment suspension state information.

Advantageous Effects of Invention According to the present invention, payment management data can be appropriately generated even for items of the same type but with different management purposes, and the effort of the user can be reduced.

FIG. 1 is a block diagram showing an example of the configuration of a payment management data generation system including a payment management data generation device according to an embodiment of the present invention. FIG. 2 is a flowchart showing the processing procedure of a payment management data generation method executed by the payment management data generation device 100 in the payment management data generation system 1000 of FIG. FIG. 3 is a diagram schematically showing a configuration example of the project master registered in step S202 of FIG. 2. FIG. 4 is a diagram schematically showing a configuration example of debt data corresponding to the debt registered in step S203 of FIG. 2. FIG. 5 is a diagram showing a configuration example of a debt setting screen that is activated when debt setting is performed in step S204 of FIG. FIG. 6 is a subroutine showing details of the debt setting acceptance process executed in step S205 of FIG. FIG. 7 is a diagram schematically showing the structure of the debt setting data generated in step S610 of FIG. 6. FIG. 8 is a subroutine showing details of the payment management data generation process in step S206 in FIG. FIG. 9 is a diagram schematically showing a configuration example of payment management data including records generated in steps S802 and S803 of FIG. 2. FIG. 10 is a diagram showing an example in which the payment status information of some records of the payment management data shown in FIG. 9 is updated to paid as a result of the process in step S209 of FIG. FIG. 11 is a diagram used to explain the processing in steps S211 and S212 in FIG. 2, and FIG. 11(a) shows an example of a group of records to be aggregated in step S211 in FIG. FIG. 11(b) is a diagram schematically showing an example of the structure of data for managing the payable reversible amount generated as a result of the process of step S212 in FIG. FIG. 12 is a diagram schematically showing an example of the results of the next month's output inspection, which is output inspection data different from the output inspection data shown in FIG. 7. FIG. 13 is a diagram schematically showing payment management data generated based on the output inspection data shown in FIG. 12. FIG. 14 is a diagram schematically showing an example of a payment hold release record generated as a result of the process in step S807 in FIG. 8 based on the performance inspection data shown in FIG. 12. FIG. 15 is a diagram schematically showing a group of target payment pending records read as a result of the process in step S807 in FIG. FIG. 16 is a diagram schematically showing a state in which priority is given to the group of target payment pending records shown in FIG. 15. FIG. 17 is a diagram for explaining the update of payment management data when the third target payment pending record is selected from the group of target payment pending records shown in FIG. 16 in step S809 of FIG. 8. 17(a) schematically shows the selected target payment pending record, and FIG. 17(b) corresponds to the target payment pending record in FIG. 17(a) in step S810 of FIG. FIG. 2 is a diagram schematically showing a payment hold release record generated by the payment hold release record. FIG. 18 is a diagram for explaining the update of payment management data when the first target payment pending record is selected from the group of target payment pending records shown in FIG. 16 in step S809 of FIG. 18(a) schematically shows the selected target payment pending record, and FIG. 18(b) corresponds to the target payment pending record in FIG. 18(a) in step S810 of FIG. 9 is a diagram schematically showing a payment suspension release record generated in step S812 of FIG. 8 and a payment suspension record generated according to the difference in amount. FIG. FIG. 19 is a diagram for explaining the update of payment management data when the second target payment pending record is selected from the group of target payment pending records shown in FIG. 16 in step S809 of FIG. 19(a) schematically shows the selected target payment pending record, and FIG. 19(b) corresponds to the target payment pending record in FIG. 19(a) in step S810 of FIG. 9 is a diagram schematically showing a payment suspension release record generated in step S812 of FIG. 8 and a payment suspension record generated according to the difference in amount. FIG. FIG. 20 is a diagram schematically showing exemplary output inspection data. FIG. 21 is a diagram schematically showing two target payment pending records read out based on the output inspection data of FIG. 20 and to which priorities are set. FIG. 22 is a diagram for explaining the update of the two subject payment pending records shown in FIG. 21, and FIG. 22(a) schematically shows the two subject payment pending records before update, and FIG. b) is a diagram schematically showing two payment hold release records generated after updating corresponding to the two target payment hold records in FIG. 22(a). FIG. 23 is a diagram schematically showing an example of order data. FIG. 24 is a diagram schematically showing an example of output inspection data. FIG. 25 is a diagram schematically showing an example of payment management data generated based on the output inspection data shown in FIG. 24. FIG. 26 is a diagram schematically showing an example of payment retention money aggregate data obtained from the performance inspection data shown in FIG. 24 and the payment management data shown in FIG. 25. FIG. 27 is a diagram schematically showing the payment management data shown in FIG. 24 after being updated. FIG. 28 is a diagram schematically showing a first example of the aggregated data created in step S221 of FIG. 2. FIG. 29 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 28. FIG. 30 is a diagram schematically showing a second example of the aggregated data created in step S221 of FIG. 2. FIG. 31 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 30. FIG. 32 is a diagram schematically showing a third example of the aggregated data created in step S221 of FIG. 2. FIG. 33 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 32. FIG. 34 is a diagram schematically showing a fourth example of the aggregated data created in step S221 of FIG. 2. FIG. 35 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 34. FIG. 35(a) shows an example of a payment notice for the first payee, ) shows an example of a payment notice for the second payee, and FIG. 35(c) shows an example of a payment notice for the third payee. FIG. 36 is a diagram schematically showing a fifth example of the aggregated data created in step S221 of FIG. 2. FIG. 37 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 36. FIG. ) shows an example of a payment notice for the second payee, and FIG. 37(c) shows an example of a payment notice for the third payee. FIG. 38 is a diagram schematically showing a sixth example of the aggregated data created in step S221 of FIG. 2. FIG. 39 is a diagram schematically showing aggregated data created based on the aggregated data shown in FIG. 38. FIG. 39(a) shows an example of aggregated data regarding the first unit business, ) is a diagram showing an example of aggregated data regarding the second unit business.

Embodiments of the present invention will be described in detail based on the drawings. Note that the present invention is not limited to this embodiment.

[1. composition]
An example of the configuration of a payment management data generation system including a payment management data generation device according to this embodiment will be described with reference to FIG. 1. FIG. 1 is a block diagram showing an example of the configuration of a payment management data generation system including a payment management data generation device according to an embodiment of the present invention. Note that the payment management data generation device according to the embodiment of the present invention is an example of an information processing device that also functions as a payment reservation data management device.

A payment management data generation system 1000 shown in FIG. 1 includes a payment management data generation device 100 as an information processing device, a server 200, and a network 300 that communicably connects the payment management data generation device 100 and the server 200. There is.

The payment management data generation device 100 generates payments related to payment details to one or more creditors (contractors) for a project (for example, construction work) that generates one or more unit obligations (unit works) that can span multiple accounting months. This is an information processing device for generating management data, and is configured with, for example, a commercially available desktop personal computer. One payment management data generation device 100 is installed in a department in a company that manages the progress of a project, such as a site management department, and particularly in a department that performs finished product acceptance on site (for example, a site supervision department). Note that the payment management data generation device 100 is not limited to a stationary information processing device such as a desktop personal computer, but can also be used for commercially available notebook personal computers, PDAs (Personal Digital Assistants), smartphones, tablet personal computers, etc. It may also be a portable information processing device. Further, a plurality of payment management data generation devices 100 may be installed in the payment management data generation system 1000, and by synchronizing the plurality of payment management data generation devices 100, one payment management data generation device 100 may be installed. It may function as the generation device 100. The payment management data generation device 100 may be installed in a department away from the site (for example, an accounting department that manages payments or a legal department that ensures compliance with construction industry laws) instead of being installed in the management department of the site. good.

The payment management data generation device 100 includes a control section 102, a communication interface section 104, a storage section 106, and an input/output interface section 108. Each unit included in the payment management data generation device 100 is communicably connected via an arbitrary communication path.

The communication interface unit 104 communicably connects the payment management data generation device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via a communication line. Here, the network 300 has a function of connecting the payment management data generation device 100 and the server 200 so that they can communicate with each other, and is, for example, the Internet or a LAN (Local Area Network). Therefore, the communication interface unit 104 receives input information from information processing devices managed by other departments and information processing devices of suppliers (for example, business partners) via the network 300 or between the network 300 and the server 200. The information processing apparatus is configured to be able to receive predetermined information via a predetermined information processing apparatus, and to output predetermined information to a predetermined information processing apparatus.

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 stores computer programs (including the program of the present invention) for providing instructions to a CPU (Central Processing Unit) to perform various processes in cooperation with an OS (Operating System). As the storage unit 106, for example, a memory device such as a RAM (Random Access Memory) or a ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, etc. can be used. Further, various data used for implementing the program of the present invention are stored in the storage unit 106 in a writable/readable manner.

An input device 112 and an output device 114 are connected to the input/output interface unit 108 . As the output device 114, in addition to a monitor (including a home television), a speaker or a printer can be used. As the input device 112, in addition to a keyboard, a mouse, and a microphone, a monitor that cooperates with the mouse to realize a pointing device function can be used.

The control unit 102 is a CPU or the like that controls the payment management data generation device 100 in an integrated manner. The control unit 102 has an internal memory for storing control programs such as an OS, programs specifying various processing procedures, required data, etc., and performs various information processing based on these stored programs. Execute.

Furthermore, with reference to FIG. 1, the configurations of the storage unit 106 and the control unit 102 will be described in detail.

As shown in FIG. 1, the storage unit 106 includes a project master 106a, a creditor master 106b, a debt setting data storage area 106c, a payment management data storage area 106d, and an aggregated data storage area 106e. Furthermore, the storage unit 106 may include other master and data storage areas.

The project master 106a is a master for registering information regarding a project. The creditor master 106b is a master for registering information regarding creditors (business partners, payees).

The debt setting data storage area 106c, the payment management data storage area 106d, and the aggregate data storage area 106e are areas for storing debt setting data, debt setting data, and aggregate data, which will be described later, respectively. Hold each data so that it can be output.

The control unit 102 includes a plurality of modules, as shown in FIG. In the example shown in FIG. 1, the control unit 102 includes a hold release regulation unit 102A, a payment management data generation unit 102B, and an output unit 102C. The payment management data generation unit 102B includes a payment pending data update unit 102b.

The hold release regulation unit 102A is a module that functions as a hold release regulation unit that restricts setting of payment hold release amount information regarding a payment hold release amount that exceeds the total payment hold amount amount. The payment management data generation unit 102B is a module that functions as a payment management data generation means that generates payment management data. The payment pending data update unit 102b is a module that functions as a payment pending data update unit that updates payment pending data. The output unit 102C is a module that functions as an output means for outputting data. The functions of each part include functions to realize the processing contents described later.

[2. process]
Next, a payment management data generation method executed in the payment management data generation system 1000 shown in FIG. 1 will be exemplified.

FIG. 2 is a flowchart showing the processing procedure of a payment management data generation method executed by the payment management data generation device 100 in the payment management data generation system 1000 of FIG.

The process shown in FIG. 2 is generally a project that generates one or more unit debts (for example, debts due to work orders for unit works to subcontractors) that span multiple accounting months (for example, a project as a contract project). The purpose of this process is to generate payment management data regarding payment details to one or more creditors for construction work), and most of this processing is executed by the control unit 102 of the payment management data generation device 100.

In addition, in the following, we will order unit works (for example, foundation work, electrical equipment work, etc.) to multiple subcontractors for a construction work project, and suspend a portion of the payment (receivables) corresponding to the obligation or An example will be explained in which the cancellation of payment suspension is allowed and performed on an accounting month basis. Here, withholding of payment occurs when a part of the amount to be paid is kept (deducted) as a retention money for the purpose of subcontractor's bankruptcy risk or defect coverage. In addition, the release (cancellation) of payment suspension is usually carried out in consideration of the subcontractor's construction progress and period. Suspension and its release must be carried out in compliance with the Construction Business Act (for example, it is prohibited to withhold and release payments for unit works of different projects even if the subcontractor is the same; , even if payment is withheld, it is prohibited to hold it for a long period of time), so it is necessary to manage it appropriately.

In FIG. 2, first, in step S201, master registration is accepted. As a master to be registered, a master etc. in which information regarding matters to be managed is registered is prepared. For example, the master to be registered includes the creditor master shown in FIG. 1. In the creditor master, the name of a business partner (subcontractor) who can be a contractor for unit construction of a project and identification information for identifying the business partner (for example, a business partner code) are registered, and preferably, If the payment destination (receiving destination) of the business partner is different from the business partner, information for specifying the payment destination is further linked and registered. Further, as another master, for example, a master in which unit works and their contents are registered may be prepared. Furthermore, a project master registered in step S202, which will be described later, may also be registered in step S201. Furthermore, if the master to be prepared has already been constructed, editing such as modification or new registration based on user input may be performed in step S201. Furthermore, a new master may be constructed or an existing master may be updated by reading and copying or overwriting the data of another master. The payment management data generation device 100 may be configured to be accessible to other masters, and the master may be considered to have been newly constructed when it becomes accessible.

Then, in step S202, registration of the project master is accepted. This process is normally performed at the stage when the contents of a new project have been determined. Therefore, if an existing project master exists, the contents of the new project are newly added to the master. As used herein, a project generally refers to a series of projects that result in one or more unit obligations (unit projects) that can span multiple accounting months. Furthermore, due to the cancellation of a project or unit project or a significant shortening of the construction period, the accounting month for each or all unit obligations may become a single unit.

FIG. 3 is a diagram schematically showing a configuration example of the project master registered in step S202 of FIG. 2.

In the project master shown in FIG. 3, for example, at least the project name of the project and project identification information (e.g., project number) for identifying the project are registered, and further, as necessary, business partner information is registered. The name of the previous business partner or identification information for identifying the business partner is registered. The business partner of the project here is the main body (representative) of the project, and may be the construction owner or the ordering party (another company), or if the main body is multiple companies, it is the representative. It may be one company, or it may be your own company or its affiliated company.

In the following step S203, a bond is registered. Credits here refer to, for example, the contents of an order when one or more unit projects constituting a project are ordered to one or more subcontractors (creditors), and are the contents of the order for the subcontractor until the completion of the project. Receivables (the total amount that the subcontractor can receive from the ordering party in response to the execution of the ordered work, i.e., the order amount), and obligations for the ordering party (company) until the completion of the project (the This is the total amount of payment due to the subcontractor's performance of the work, i.e. the order amount). Therefore, if there is order data indicating the contents of the order, the receivables may be registered by reading the order data, or the user may register the receivables based on the order data or the order slip. Registration of claims is performed to include project identification information, and is performed for each creditor (subcontractor). As a result, receivables for each unit business will be registered. Here, for example, by adding additional information (for example, a branch number) to the project identification information, a plurality of creditors (subcontractors) may be set for each unit project. This makes it possible to register debts for each unit business. The debt registered in step S203 is readably saved as debt data.

FIG. 4 is a diagram schematically showing a configuration example of debt data corresponding to the debt registered in step S203 of FIG. 2.

In the example of receivables data shown in FIG. 4, receivable identification information for identifying receivables (for example, order number), creditor identification information for identifying creditors (for example, business partner name), project identification number, It is configured to include order amount information regarding the total amount of the order amount, payment retention information indicating whether or not payment retention is set, and payment retention amount deduction rate information regarding the payment retention amount deduction rate.

As the order amount information, the total amount of the order amount is registered in order to manage the project until completion. Information on whether or not payments are withheld is the period during which payment (debt) is allowed to be withheld under the Construction Business Act, or longer, according to the contract (arrangement) between the ordering party (debtor in this case) and the contractor (in this case, creditor). This refers to information indicating whether or not it is permitted for a short period of time. The payment retention amount deduction rate is the ratio (percentage) of the amount to be retained (deducted) from the scheduled payment amount scheduled to be paid to the creditor. Note that the debt data may include, instead of the payment retention amount deduction rate information, retention amount information regarding the retention amount to be suspended for payment, or may include one of both. Preferably, the debt identification information includes information regarding the date on which the debt was issued (order date), thereby making it possible to manage the starting date of the period during which payment was withheld.

Then, in step S204, it is determined whether a debt is to be set. Specifically, it is determined whether a debt setting screen as shown in FIG. 5 is activated and input by the user is started. Debt setting is usually performed every accounting month before the scheduled payment date, and may be performed at any timing as needed. Examples of debts referred to here include the amount to be paid to creditors determined as a result of performance inspections regarding the progress of unit businesses that make up the project, and the amount to be withheld (deducted) from the amount to be paid. or its percentage, and if there is a retained amount, the amount to be released for part or all of the retained amount, or its percentage. The amount to be paid may be an amount corresponding to a percentage of all receivables determined as a result of the performance inspection. Here, by managing the amount to be paid and the amount related to release of the hold as a positive amount, and managing the amount related to the hold (deduction) as a negative amount, even if it is a positive amount, it will not be a negative amount. can also be managed as debt.

As a result of the determination in step S204, if debt setting is to be performed (Yes in step S204), the process proceeds to step S205. On the other hand, as a result of the determination in step S204, if debt setting is not performed (No in step S204), steps S205 to S206 are skipped and the process proceeds to determination processing from step S207 onwards.

In step S205, a debt setting reception process is performed. In the debt setting acceptance process, for example, information inputted via an input screen as shown in FIG. 5 (information determined as a result of the output inspection) is accepted by the user.

FIG. 6 is a subroutine showing details of the debt setting acceptance process executed in step S205 of FIG.

First, in step S601 in FIG. 6, the designation of a project and a creditor is accepted via an input screen as shown in FIG. The project and creditor may be specified using identification numbers registered in various masters. As a result, the project identification information and creditor information for which debt is to be set are obtained.

Then, in step S602, default display is performed on the input screen based on the project identification information and creditor information acquired in step S601. For example, based on the debt data shown in FIG. 4, information regarding the order amount (contract amount) and payment retention deduction rate is displayed on the input screen. Further, it is preferable that information regarding the payment amount or acceptance amount for the previous accounting month and the cumulative total of the payment amount up to the previous accounting month are also displayed on the input screen. By displaying various information on the input screen in this way, the user can set the current month's debt while comparing with previous amount information.

Subsequently, in step S603, input of information on the amount to be paid is accepted. The amount to be paid (hereinafter also referred to as "amount to be paid (a)") is, for example, the amount to be paid (the current month's acceptance amount) determined as a result of the current month's performance inspection. Normally, the amount to be paid is a positive amount because progress is made in each accounting month in the execution of a unit project by a subcontractor. Additionally, if it is determined that there is no progress as a result of the performance inspection, the amount to be paid is usually zero. However, for example, depending on the agreement or negotiation at the time of completion inspection (for example, delay in unit construction due to circumstances of the ordering party), an amount less than zero, that is, a negative amount, may be entered as the deductible amount as the amount to be paid. is also possible. When the input of the payment amount information is accepted, the payment retention amount information is displayed by default on the input screen based on the payment retention amount deduction rate. The retention money indicated by the payment retention money information displayed here is calculated, for example, by multiplying the amount to be paid by the ratio indicated by the payment retention money deduction rate. If the payment retention deduction rate is not set, the retention amount defaults to zero.

Next, in step S604, it is determined whether there is a change in the retained money as a result of the input by the user. The retained money is the retained money displayed by default as a result of the process in step S603. As a result of the process in step S604, if there is a change in the retained money, or as a result of the default display, an amount exceeding zero is set in the retained money (Yes in step S604), the process proceeds to steps S605 and thereafter. An error check is performed regarding the changed retained money or the default displayed retained money (hereinafter these retained funds are also collectively referred to as "retained money (b)"). On the other hand, if there is no change in the retained money or if zero is set in the retained money (No in step S604), the process advances to step S607.

When checking the error regarding the retained money (b), first, in steps S605 and S606, it is checked whether the amount to be paid (a) accepted in step S603 is an amount exceeding zero, and whether the retained money (b) obtained in step S604 is ) is less than or equal to the payment amount (a). Through these determination processes, it is confirmed that a new retention money is not set even though the amount to be paid (a) is not a positive amount, and even if the amount to be paid (a) is a positive amount, the said positive amount is It is confirmed that the retention money (b) that has been set is not set, that is, the validity of the set retention money (b) is confirmed.

As a result of the determination in step S605, if the amount to be paid (a) is not an amount exceeding zero (No in step S605), first, in step S620, in order to restrict that only zero can be input as the retained amount (b). Determine whether or not the retained money (b) is zero, and as a result of such determination, if the retained money (b) is not zero (No in step S620), input a change to zero for the retained money (b). In order to prompt the user, a first error display (for example, a warning display stating "Only 0 is allowed") is performed (step S621), and the process returns to step S603 to enter the payment amount (a) and the retention amount ( Wait for one or both of b) to be changed. As a result of the determination in step S620, if the retained money (b) is zero (Yes in step S620), the process proceeds to step S606.

As a result of the determination in step S606, if the retained amount (b) is not less than the payable amount (a) (No in step S606), restrictions are imposed so that the retained amount (b) exceeding the paid amount (a) is not input. In order to avoid this problem, a second error display is displayed in step S630 (for example, a warning display stating that "an amount exceeding the inspection amount for the current month cannot be specified"), and the process returns to step S603 to display the amount to be paid (a) and the pending amount. Wait for one or both of the money (b) to be changed.

Then, in steps S605 and S606, if the validity of the retention money (b) set in step S604 is confirmed (Yes in step S605 and Yes in step S606), the process advances to step S607.

In steps S607 to S609, an error check regarding the hold release fee is performed. Specifically, first, in step S607, it is determined whether a non-zero amount has been input as the hold release fee. As a result of the determination in step S607, if the hold release money has not been input or if the hold release money is set to zero (No in step S607), the process advances to step S610. On the other hand, as a result of the determination in step S607, if the hold release money has been input (Yes in step S607), the entered hold release money (hereinafter also referred to as "hold release money (c)") is The process proceeds to step S608.

In step S608, it is determined whether the payment retention reversible amount (hereinafter also referred to as "payment retention reversible amount (d)") is an amount greater than zero (that is, whether there is a balance in the payment retention amount). do. The reversible amount of payment reservations refers to the upper limit of the amount that can be withdrawn from the payment reservation amount, and is usually the total amount of payment reservations for the current month. Since the reversible amount of pending payment changes each time a payment process is performed, it is updated through the process described below.

As a result of the determination in step S608, if the pending payment reversible amount is greater than zero (Yes in step S608), there is a pending amount to be reversed, so the process advances to step S609. In the following step S609, it is determined whether the hold release amount (c) acquired in step S607 is less than or equal to the payment hold reversible amount (d). As a result of the determination in step S609, if the hold release amount (c) is less than or equal to the payment hold reversible amount (d), the hold release fee (c) exceeds the upper limit of the hold amount subject to cancellation. Since it has been confirmed that it is not a real thing, the process advances to step S610.

On the other hand, as a result of the determination in step S608, if the payment hold reversible amount is not an amount exceeding zero (No in step S608), it means that there is no balance in the payment hold amount that can be reversed, so the hold release amount is In order to restrict that only zero can be entered as (c), first, in step S640, it is determined whether the hold release amount (c) is zero, and as a result of such determination, it is determined that the hold release amount (c) is not zero. In this case (No in step S640), a third error display (for example, a warning display stating "Only 0 is allowed") is displayed to prompt the user to change the suspension release fee (c) to zero ( Step S641), the process returns to step S607 and waits for the hold release fee (c) to be changed. As a result of the determination in step S640, if the hold release fee (c) is zero (Yes in step S640), the process proceeds to step S609.

As a result of the determination in step S609, if the hold release amount (c) is not less than the payment hold reversible amount (d) (No in step S609), the hold release amount is greater than the payment hold reversible amount (d). In order to prevent money (c) from being input, a fourth error display is displayed in step S650 (e.g., a warning display stating that "the amount of this month's retention amount is greater than the amount of the retention amount") is displayed in step S607. Returning to the process, the system waits for the suspension release fee (c) to be changed.

Then, in steps S608 and S609, if the validity of the hold release money (c) acquired in step S607 is confirmed (Yes in step S608 and Yes in step S609), the process advances to step S610.

Then, in step S610, information regarding the amount to be paid (a) acquired in step S603, the retention amount (b) acquired in step S604, and the retention release amount (c) acquired in step S607 is acquired as debt setting information. . Note that each piece of debt setting information may be information indicating that the amount is zero. The process of step S610 is executed, for example, by pressing a "confirm" button (not shown) on the input screen shown in FIG. 5. Then, each piece of debt setting information acquired in step S610 is stored in a readable manner, for example, as debt setting data. Then, the process shown in FIG. 6 is completed, the process returns to the process shown in FIG. 2, and the process proceeds to step S206.

FIG. 7 is a diagram schematically showing the structure of the debt setting data generated in step S610 of FIG. 6.

The example of debt setting data shown in FIG. 7 is output inspection data indicating the results of output inspection. As shown in Figure 7, the earned value acceptance data includes acceptance identification information (for example, acceptance inspection number) for identifying the earned value inspection, receivable identification information (for example, order number), and recording date (for example, the implementation date of the earned value acceptance). information, information about the scheduled payment date (for example, the accounting date of the next month or the month after next), information about the payee, project identification information, and information about the amount to be paid (inspected amount), and further includes the receivables shown in Figure 4. Contains some information included in the configuration data. Some of the information included in the debt setting data shown in Figure 4 includes payment retention information, payment retention deduction rate information, etc. These pieces of information are obtained from the debt setting data shown in Figure 4. Good too. Therefore, if the output inspection data exists, each debt setting information may be acquired from the information read from the output inspection data instead of the process in step S205. Alternatively, in order to reflect each debt setting information in the performance inspection data, for example, information regarding the suspension release fee (c) may be added to the performance inspection data.

Returning to FIG. 2, in step S206, payment management data generation processing is performed. In the payment management data generation process, payment management is performed using the debt setting information regarding the payment target amount (a), retention amount (b), and retention release amount (c) obtained as a result of the debt setting reception process in step S205 (FIG. 6). Data is generated. FIG. 8 is a subroutine showing details of the payment management data generation process in step S206 in FIG.

In FIG. 8, first, in step S801, it is determined whether the amount to be paid is greater than or equal to zero. As a result of this determination, if the amount to be paid is zero or more (Yes in step S801), a record with breakdown classification "0" (hereinafter also referred to as "normal record") is generated in step S802, and the process advances to step S804. Note that if the amount to be paid is zero, the generation of the normal record may be omitted, thereby reducing the data capacity. On the other hand, if the result of this determination is that the amount to be paid is less than zero, that is, negative (No in step S801), a record with breakdown category "1" (hereinafter also referred to as "deduction record") is generated in step S803. , the process advances to step S804. The breakdown categories will be explained later. The records generated in steps S802 and S803 are records that constitute part of the payment management data generated in this process.

FIG. 9 is a diagram schematically showing a configuration example of payment management data including records generated in steps S802 and S803 of FIG. 2.

The payment management data shown in FIG. 9 is composed of records including scheduled payment amount information regarding the scheduled payment amount for fulfilling obligations to creditors. The scheduled payment amount may be positive (withdrawal) or negative (deduction). As shown in FIG. 9, the payment management data includes, in addition to scheduled payment amount information, identification information for identifying each record (for example, a payment scheduled number assigned as a sequential number), and a scheduled payment date regarding the scheduled payment date. information, information about the business partner's payee (for example, payee name), debt identification information for identifying the debt included in the debt setting information (for example, original document number), and the classification (classification) of each record. It is configured to include classification information (for example, a breakdown category or its category name) and payment status information (for example, a payment status name) for the scheduled payment amount. The scheduled payment date information is usually set to a designated date in an accounting month (for example, the next accounting month or the accounting month after the next) that is preset with respect to the recording date in the performance inspection data. However, as will be described later, it is also possible to set non-accountable information (for example, a future date) indicating that the scheduled accounting date has not been determined as the scheduled payment date information. Further, the original slip number that can be used as debt identification information is the original slip number in the output acceptance data. By including the above-mentioned information in the payment management data, it becomes possible to grasp the scheduled payment date and payment status of the scheduled payment amount of each record. The payment status information is selected from paid and unpaid. At the time each record is generated, the payment status information is set to unpaid, and when the scheduled payment amount for each record is completed on the scheduled payment date, the payment status information is set to paid. ing.

Here, the breakdown classification is set in each record as classification information for specifying the classification (classification) of each record in the payment management data. The breakdown category "0" corresponds to classification information for specifying records in which the amount to be paid (a) is positive (records related to normal payments). Therefore, the normal record with the breakdown category "0" generated in step S802 is a record that is subject to obligation fulfillment (withdrawal subject) in a preset accounting month. The breakdown category "1" corresponds to classification information for specifying records in which the amount to be paid (a) is negative (records related to deductions). Therefore, the deduction record of breakdown category "1" generated in step S803 is a record to be deducted in a preset accounting month. The breakdown categories "2" and "3" function as pending state information indicating the pending state of the retained money, as will be described later. Therefore, by including the pending status information in the payment management data, it is possible to quickly grasp the pending status of the retained funds in each record, and it is also possible to easily generate aggregated data as described below. become able to.

Subsequently, in step S804, it is determined whether it is necessary to generate a retention money record. Specifically, it is determined whether the retained money (b) is greater than zero. As a result of the determination in step S804, if it is not necessary to generate a retained money record (No in step S804), the process skips the process in step S805 described below and proceeds to step S806.

As a result of the determination in step S804, if it is necessary to generate a record related to the retained amount (Yes in step S804), the process proceeds to step S805, and the record with the breakdown category "1" (that is, the record related to deduction) and the breakdown category A pair of records "2" (hereinafter also referred to as "payment pending records") is generated, and the process advances to step S806. As explained using FIG. 6, if the amount to be paid (a) is negative, the retained amount (b) is set to zero, so it is necessary to generate a retained amount record in step S804. As a result, in the payment management data, deduction records derived from the negative amount to be paid (a) and deduction records derived from the retained amount (b) are prevented from coexisting. It has become.

Here, the payment pending record of breakdown category "2" generated in step S805 will be explained. The payment pending record with breakdown classification "2" is a record indicating that the payment is in a pending state. In step S805, a deduction record is generated based on the retention amount (b), but the negative amount indicated by the scheduled payment amount information in the deduction record will be accumulated as a retention amount when the scheduled payment date arrives. Become. Therefore, in step S805, a payment retention record in which the amount to be accumulated as retention money (that is, a positive amount) is registered as scheduled payment amount information is generated to be paired with the deduction record. Therefore, the positive amount indicated by the scheduled payment amount information included in the payment hold record with breakdown category "2" corresponds to the additional amount scheduled to be accumulated to the payment hold reversible amount, not the scheduled amount to be withdrawn to the payee. do.

In step S806, it is determined whether there is a payment hold release fee (c). Specifically, it is determined whether the hold release fee (c) is greater than zero.

As a result of the determination in step S806, if there is a hold release fee (c) (Yes in step S806), the payment hold record is updated based on the hold release fee (c) in steps S807 to S814. As a result of updating this payment hold record, a record with breakdown classification "3" (hereinafter also referred to as a "payment hold release record") is generated. Details of the payment hold record update process will be described later. When the payment pending record update process is completed, this process is ended, the process returns to FIG. 2, and the process proceeds to step S207.

On the other hand, as a result of the determination in step S806, if there is no hold release money (c) (No in step S806), the process of updating the payment hold record in steps S807 to S814 is skipped, this process is ended, and the flow shown in FIG. 2 and proceeds to step S207.

When each record is added and payment management data is generated as explained using FIG. 8, returning to FIG. 2, in step S207, it is determined whether an inquiry answer or a payment notice is required. Specifically, it waits for the user to input instructions for necessary documents. Here, the inquiry response form is a form in which the creditor who has received the performance inspection makes an inquiry to the debtor regarding the scheduled payment amount for the current month or the next month (for the creditor, the expected amount of payment) before the scheduled payment date. By receiving this document, the creditor can confirm that the results of the performance inspection are reflected in the scheduled payment amount before the scheduled payment date. I can do it. A payment notice is a document that is used by a debtor to notify the creditor of the amount to be paid (withdrawn), thereby saving the creditor the trouble of making inquiries to the debtor. .

As a result of the determination in step S207, if an inquiry response form or a payment notice is necessary (Yes in step S207), the necessary documents are created in steps S221 to S223, and the process proceeds to step S208. The process for creating the necessary documents will be described later. On the other hand, as a result of the determination in step S207, if the inquiry response form or the payment notice is not required (No in step S207), the process of creating the necessary documents in steps S221 to S223 is skipped and the process proceeds to step S208.

Next, in step S208, it is determined whether the scheduled payment date has arrived and the payment has been completed for the scheduled payment amount of each record included in the payment management data. To complete the payment, for example, read the transfer completion data from farm banking (FB) and search for information included in the payment management data (information such as payment schedule number, payment schedule date, payee, payment schedule amount, etc.) It can be understood by As a result of the determination in step S208, if the payment has not been completed, for example, if the scheduled payment date has not yet arrived (No in step S208), the process returns to step S204 to accept another debt setting. stand by. On the other hand, if there is a record in which payment has been completed (Yes in step S208), the payment status information of the record is set to paid (that is, unpaid is updated to paid) in step S209, and the process is performed in step S210. Proceed to processing. FIG. 10 shows an example in which the payment status information of some records of the payment management data shown in FIG. 9 has been updated to paid as a result of the process in step S209 of FIG.

In step S210, it is determined whether there is an unpaid record in the payment management data. Unpaid records are typically pending payment records. This is because, as described above, the scheduled payment amount in the payment hold record is not the amount to be paid (transfer amount) to the payee. As a result of the determination in step S210, if there is an unpaid record (Yes in step S210), in step S211, unpaid records are aggregated for each business partner (payee), and in step S212, payment is suspended. Update the payment hold reversible amount based on the aggregation results of the records. Therefore, since the payment hold reversible amount is updated every time a payment is completed, it is possible to prevent the hold release (reversal) of an amount exceeding the payment hold reversible amount.

FIG. 11 is a diagram used to explain the processing in steps S211 and S212 in FIG. 2, and FIG. 11(a) shows an example of a group of records to be aggregated in step S211 in FIG. FIG. 11(b) is a diagram schematically showing an example of the structure of data for managing the payable reversible amount generated as a result of the process of step S212 in FIG. A group of records shown in FIG. 11(a) is composed of unpaid records in FIG. 10. As shown in FIG. 11(b), it is preferable to generate and update data for managing the pending reversible amount each time the process of step S212 in FIG. It can be saved as much as possible.

Then, when the pending payment reversible amount is updated in step S212, the process returns to step S204, and the process waits for determination of another debt setting, necessity of necessary documents, and payment completion. On the other hand, as a result of the determination in step S210, if there are no unpaid records (No in step S210), it means that payments have been completed for all records, and the process shown in FIG. 2 is completed.

In addition, in the explanation using FIG. 2, FIG. 6, and FIG. 8 mentioned above, for example, master registration (maintenance) (step S201), project registration (step S202), debt registration (step S203), debt setting (step S204 and In FIG. 6), the creation of the inquiry response form or the payment notice form (steps S221 to S223) may be executed at any timing, that is, it is a process that can be processed by interruption. Further, the payment pending record update processing in steps S807 to S814 in FIG. 8 may be executed in another information processing device that functions as a payment pending data management device.

In addition, in the above explanation, we explained an example in which payment management data that reflects the results of the performance inspection conducted in January is newly generated, and payments other than payment pending records are completed in February. Similar processing can be applied continuously.

FIG. 12 is a diagram schematically showing an example of the results of the next month's output inspection, which is output inspection data different from the output inspection data shown in FIG. 7. FIG. 13 is a diagram schematically showing payment management data generated based on the output inspection data shown in FIG. 12. However, for convenience, the hold release record is excluded from the payment management data shown in FIG. 13. In this way, payment management data is generated for the next month as well in the same manner as described above.

Here, as shown in the performance inspection data shown in FIG. 12, if the payment hold cancellation amount (c) is set, that is, if it is determined that the payment hold is canceled in step S806 of FIG. 8 (step S806 (Yes) will be explained using FIG.

In FIG. 8, if it is determined that there is a payment hold release (Yes in step S806), a payment hold release record is generated (the breakdown classification does not need to be added at this point, and the scheduled payment date is One or more corresponding payment pending records are read from the existing payment management data (which may be any date) (step S807). The corresponding payment hold record is a payment hold record (hereinafter also referred to as "target payment hold record") that has the same order number, payee, and project number included in the generated payment hold release record. FIG. 14 is a diagram schematically showing an example of a payment hold release record generated as a result of the process in step S807 in FIG. 8 based on the performance inspection data shown in FIG. 12. FIG. 15 is a diagram schematically showing a group of target payment pending records read as a result of the process in step S807 in FIG.

In subsequent step S808, each of the group of target payment pending records read in step S807 is assigned a plurality of preset priorities (for example, "1", "2", and "3" set in descending order of priority). ”). FIG. 16 is a diagram schematically showing a state in which priority is given to the group of target payment pending records shown in FIG. 15.

The priority includes the order in which the retention amount is closest to the recording date (recording date in the completed performance inspection data), the retention release amount is closer to the full amount of the retention amount, or the order determined by a combination thereof, and further, The order may be determined by combining the order in which the numbers indicated by the scheduled payment date numbers are closest. For example, if the recording date of the hold amount of the target payment hold record (recording date in the earned income inspection data) is close, the scheduled payment amount (i.e. hold amount) of the target payment hold record is the same as or less than the hold release amount of the payment hold release record. If the amount is less than 1, priority "1" is set in the target payment pending record. In addition, if the recording date of the pending amount of the target payment pending record (recording date in the earned income inspection data) is not close (for example, a payment pending record that was generated based on the previous month's earned income inspection data rather than the current month), the applicable payment pending record Priority level "2" is set for the record.

Subsequently, in step S809, one target payment pending record with a high priority is selected from a group of target payment pending records for which priorities have been set. If there are multiple subject payment pending records with the same priority set, one subject payment pending record that is arbitrary or has a close accounting date or pending amount is selected.

Then, when the target payment hold record is selected, the set hold release amount information is set in place of the hold amount information included in the target payment hold record (breakdown classification "2"), and the hold status information is set. A payment hold release record is generated in which information (detail category "3") indicating payment hold release is set (step S810). Further, in this payment hold release record, date information regarding the accounting date or scheduled accounting date of hold release corresponding to the hold release amount information is set as scheduled payment date information. Therefore, unlike the target payment hold record, which normally has non-accrualable information (future date) set as the scheduled payment date information, the payment hold record contains information about the actual scheduled payment date as the scheduled payment date information. Information is set.

FIG. 17 is a diagram for explaining the update of payment management data when the third target payment pending record is selected from the group of target payment pending records shown in FIG. 16 in step S809 of FIG. 8. 17(a) schematically shows the selected target payment pending record, and FIG. 17(b) corresponds to the target payment pending record in FIG. 17(a) in step S810 of FIG. FIG. 2 is a diagram schematically showing a payment hold release record generated by the payment hold release record.

Subsequently, in step S811, it is determined whether there is a difference greater than zero between the hold release amount in the payment hold release record and the hold amount in the target payment hold record. As a result of the process in step S811, if there is no difference in amount exceeding zero, that is, if the amounts are the same, step S812, which will be described below, is skipped and the process proceeds to step S813. In the example shown in FIG. 17, the scheduled payment amount in the target payment hold record and the scheduled payment amount in the payment hold release record are the same amount, so the process of step S812 is not performed.

On the other hand, as a result of the process in step S811, if there is a difference of more than zero, that is, if the hold amount is part of the hold release amount (Yes in step S811), in step S812, the difference between the hold release amount and the hold release amount is determined. A new payment reservation record (hereinafter also referred to as "difference payment reservation record") containing the amount information as the reservation amount information is generated. In this embodiment, the breakdown category "2" is set in this difference payment pending record. By generating the difference payment hold record in this way, the scheduled payment amount of the target payment hold record becomes the same as the sum of the scheduled payment amounts of the pair of payment hold release record and the difference payment hold record.

FIG. 18 is a diagram for explaining the update of payment management data when the first target payment pending record is selected from the group of target payment pending records shown in FIG. 16 in step S809 of FIG. 18(a) schematically shows the selected target payment pending record, and FIG. 18(b) corresponds to the target payment pending record in FIG. 18(a) in step S810 of FIG. 9 is a diagram schematically showing a payment suspension release record generated in step S812 of FIG. 8 and a payment suspension record generated according to the difference in amount. FIG. FIG. 19 is a diagram for explaining the update of payment management data when the second target payment pending record is selected from the group of target payment pending records shown in FIG. 16 in step S809 of FIG. 19(a) schematically shows the selected target payment pending record, and FIG. 19(b) corresponds to the target payment pending record in FIG. 19(a) in step S810 of FIG. 9 is a diagram schematically showing a payment suspension release record generated in step S812 of FIG. 8 and a payment suspension record generated according to the difference in amount. FIG. As shown in FIGS. 18 and 19, the scheduled payment amount of the target payment suspension record is the same as the sum of the scheduled payment amounts of the pair of payment suspension release records and the difference payment suspension record.

In step S813, the target payment pending record is deleted. In the examples shown in FIGS. 17 to 19, the target payment pending record shown in FIG. 17(a), the target payment pending record shown in FIG. 18(a), and the target payment pending record shown in FIG. 19(a) are deleted. . This completes the updating of the payment suspension record (deletion of the target payment suspension record and generation of the difference payment suspension record) in conjunction with the generation of the payment suspension release record. Then, the process proceeds to step S814, and if there is another target payment pending record (Yes in step S814), the process returns to step S809, selects another target payment pending record, and performs the steps S810 to S814 described above. Process. If there are no other target payment pending records (No in step S814), this process is completed, the process returns to FIG. 2, and the process from step S207 onwards is performed.

Here, exceptional processing in the case where the scheduled payment amounts of two target payment hold records are the same as the scheduled payment amount of one payment hold release record will be described with reference to FIGS. 20 to 22.

FIG. 20 is a diagram schematically showing exemplary output inspection data. FIG. 21 is a diagram schematically showing two target payment pending records read out based on the output inspection data of FIG. 20 and to which priorities are set. FIG. 22 is a diagram for explaining the update of the two subject payment pending records shown in FIG. 21, and FIG. 22(a) schematically shows the two subject payment pending records before update, and FIG. b) is a diagram schematically showing two payment hold release records generated after updating corresponding to the two target payment hold records in FIG. 22(a).

In the example shown in Figures 20 to 22, the payment hold cancellation amount "31,000" in the performance inspection data is the two target payments of the scheduled payment amounts "1,000" and "30,000" that existed before the update. After updating, two payment hold release records are generated depending on the hold record: a payment hold release amount of "1,000" and a payment hold release amount of "30,000". According to the explanation of FIG. 8 above, the two target payment hold records are updated sequentially based on the priority, so in the interim, the payment hold release record for the payment hold release amount "1,000" and the payment hold release record for the payment hold release amount "1,000" , a difference payment hold record for the scheduled payment amount "30,000" is generated, but the former difference payment hold record is also selected as the target payment hold record, and as a result, the payment hold release amount is "30,000". '' will be generated, and the difference payment suspension record will be deleted, and as a result, two payment suspension cancellation records shown in FIG. 22(b) will be generated. Therefore, instead of the process shown in FIG. 8 described above, in the target payment pending record with a low priority (the record with the second priority "2" shown in FIG. 21) that corresponds to the difference payment pending record that may be generated intermediately, By changing the scheduled payment date and breakdown category, processing may be performed to generate a payment hold release record (the second record shown in FIG. 22(b)) that can be finally generated. Thereby, the load related to update processing can be reduced.

Next, the necessary document creation process executed in steps S221 to S223 in FIG. 2 will be explained. This process is performed if, as a result of the determination in step S207, it is necessary to create a necessary document (inquiry answer form or payment notice) (Yes in step S207), specifically, if the user instructs to create the necessary document. is executed.

First, in step S221, aggregate data corresponding to the required documents is generated in a predetermined format based on the payment management data. Aggregated data is data that aggregates records of designated creditors from payment management data.

Subsequently, in step S222, it is determined whether the aggregated data generated in step S221 is to be output. Specifically, it waits for an output instruction from the user. As a result of the determination in step S222, if the aggregated data is not to be output (No in step S222), the aggregated data is stored in a readable manner as necessary, and the determination processing from step S208 onwards is performed. On the other hand, as a result of the determination in step S222, if the aggregated data is to be output (Yes in step S222), the aggregated data is outputted in step S223, and then the determination processing from step S208 onwards is performed.

Here, outputting the aggregated data includes printing, transmitting via wireless or wired, and displaying on a predetermined display screen. By outputting the aggregated data, the aggregated data is output as form data set in advance according to the aggregated data. Examples of the form data include form data corresponding to an inquiry response form or a payment notice. However, the name of the form is arbitrary. Therefore, the form data corresponding to the inquiry answer form may be referred to as, for example, unpaid amount aggregate data, and the form data corresponding to the payment notice may be referred to as, for example, payment retention aggregate data. That is, by generating aggregate data from payment management data, it is possible to output arbitrary management data or form data. In this embodiment, since the payment management data includes payment pending status information and payment status information, it is possible to generate aggregate data that includes one or both of them. By generating aggregate data including such information, the user can improve the visibility of the information by outputting it. For example, a report containing information regarding the release of a payment hold will allow the creditor who receives it (the unit project contractor) to visually understand that the unit project's output has been evaluated or that its progress is good. This is preferable to conventional forms in which the payment hold release amount is simply added to the scheduled payment amount. Further, a form including information regarding paid or unpaid information is advantageous for an administrator to manage the progress of payments (transfers), for example.

As described above in detail, according to the series of processes shown in FIGS. 2, 6, and 8, the payment management data generation device 100 generates debt setting data (for example, information received via a predetermined input screen), Alternatively, payment management data regarding payment details to one or more creditors for a project that generates one or more unit debts that can span multiple accounting months is automatically generated based on (step S205) (Step S206) (payment management data generation means). Here, the payment management data includes at least scheduled payment amount information regarding the scheduled payment amount or scheduled deduction amount scheduled to be paid to the creditor regarding the project, and the payment management data includes at least scheduled payment amount information regarding the scheduled payment amount or scheduled deduction amount scheduled to be paid to the creditor regarding the project. Payment management data including scheduled payment amount information regarding the amount, which is payment retention amount information regarding the payment retention amount for which payment to the creditor is withheld, and payment retention status information indicating payment retention or release of the payment retention amount for the payment retention amount. may include. The debt setting data includes at least payment amount information regarding the amount to be paid to the creditor or the ratio of the amount to be paid to the amount to be paid, which is determined at any time or at a specific timing for the project, and The debt setting data further includes payment suspension amount information regarding a payment suspension amount for suspending payment to the creditor determined at the timing or a payment suspension target ratio to the payment target amount, and payment suspension determined at the timing. If at least one of the hold release amount or the payment hold release amount information regarding the proportion of the total payment hold amount to be released is included, in addition to the record that includes at least the scheduled payment amount information, the hold amount information and the payment hold amount information are included. A payment hold record whose hold status information includes information indicating payment hold, or a payment hold release record whose payment hold release amount information and payment hold status information include information indicating payment hold release is added (step S805 or In step S810), payment management data including a record including the payment pending status information is generated as the payment management data. Therefore, since the payment management data includes payment pending status information, it is no longer necessary for the user to manage payment pending status information individually or separately, which improves the convenience of managing payment details to creditors. can be improved.

In order to further improve convenience, it is possible to further include information that identifies the unit debt (for example, additional information such as a branch number to the project number) in the payment management data. It is also possible to manage each (unit business). In addition, in order to further improve convenience, the payment schedule data, the payment management data, and the aggregate data include a scheduled payment amount corresponding to the scheduled payment amount information, a payment reservation amount corresponding to the payment reservation amount information, and the payment reservation amount corresponding to the payment reservation amount information. It is possible to include payment status information indicating whether the payment hold release amount corresponding to the payment hold release amount information has been paid or unpaid, and it is also possible to manage the payment status.

In addition, to further improve convenience, it is also possible to generate aggregated data (aggregated accounts payable data and aggregated payment retention data, which will be described later) that aggregates the records of the creditors in a predetermined format based on the payment management data. (Step S221), thereby making it possible to obtain various output results (Step S223) (output means).

Further, according to the series of payment pending record update processing of steps S806 to S814 shown in FIG. When managing payment retention data regarding payment retention amounts for payments to one or more creditors for a project that generates multiple unit debts, payment retention for part or all of the payment retention amounts for which payment to the creditor is withheld is determined. When payment hold release amount information regarding the ratio of the payment hold target to the total amount of the release amount or the payment hold amount is set, update the target payment hold record that includes the payment hold amount information regarding the payment hold amount in the payment hold data. (Means for updating payment pending data). When updating the payment hold data, the set payment hold release amount information is set in place of the payment hold amount information regarding the payment hold amount included in the target payment hold record, and the payment hold release amount information is set as the payment hold state information. A payment hold release record in which information indicating the release is set is at least automatically generated (step S810). Therefore, the user can improve the convenience of managing the hold release money when part or all of the hold money is released.

Here, as described above, the payment management data generation device 100 also functions as a payment reservation data management device, so the payment management data generation device 100 also functions as a payment reservation data management device (for example, the process of updating a series of payment reservation records in steps S806 to S814). The function of executing the function) may be realized by another information processing device. That is, the payment pending data management device may be provided as a single information processing device. In this case, the target payment hold record and the payment hold release record do not need to include payment hold state information. As well as a payment pending data management apparatus, a payment pending data management method and a payment pending data management program are also provided.

In order to further improve convenience, date information regarding the recording date or scheduled recording date of payment suspension release corresponding to the payment suspension release amount information is set in the payment suspension release record (step S810).

In order to further improve convenience, if the payment hold release amount is a part of the payment hold amount (Yes in step S811), the difference between the payment hold release amount and the payment hold release amount is calculated as the payment hold amount. A new difference payment pending record is generated to be included as information (step S812).

In order to further improve convenience, non-accountable information indicating that the recording date or scheduled recording date for release of payment suspension is not determined is set in the difference payment suspension record (step S812).

In addition, when updating payment retention data, if one or more of the target payment retention records exist in the payment retention data, a plurality of preset payment retention records may be added to each of the one or more target payment retention records. The priority selected from among the priorities is set. As a result, processing will proceed from the target payment pending record with the highest priority. Here, the plurality of priorities are the order in which the recording date of the payment hold amount is closest, the order in which the payment hold amount is closer to the full amount of the payment hold release amount, or the order determined by a combination thereof. include. This allows processing to proceed efficiently.

Moreover, when the update of the payment reservation data is completed, the target payment reservation record is deleted (step S813). Thereby, data capacity can be reduced.

Further, according to the process of FIG. 6, setting of payment hold release amount information regarding a payment hold release amount that exceeds the total payment hold amount is regulated (No in step S609 and step S650) (hold release regulation means). As a result, it is possible to execute a series of payment hold record update processes of steps S806 to S814 shown in FIG. 8 for a payment hold release record with an appropriate payment hold release amount.

In the above explanation, the project is a contract work that includes multiple unit projects, the debtor of the one or more unit debts is the contractor of the contract work, and the creditor is a contract business that includes multiple unit projects. The above example is a case where the debt setting data is output inspection data showing the results of the output inspection of the project, but is not limited to this example, and the payment is suspended or the payment is suspended due to payment management. It is applicable in situations where the cancellation (reversal) of a contract occurs.

Next, a specific example of the series of processes described above will be explained using the drawings.

In a project that has order data as shown in FIG. 23 (steps S202 to S203), if there is output inspection data as shown in FIG. 24 (step S204), payment management data as shown in FIG. 25 is generated. Here, in the output acceptance data shown in FIG. 24, unlike the output acceptance data shown in FIG. , contains payment release records. Note that the payment management data shown in FIG. 25 also includes a record whose payment status information indicates that the payment has been completed due to the completion of the payment for the previous accounting month.

Here, the records of breakdown categories "2" and "3" included in the payment management data shown in Figure 25 (that is, only the records that include payment pending status information) are aggregated, and the records included in the earned value acceptance data shown in Figure 24 are further aggregated. By combining the pieces of information, payment retention aggregate data as shown in FIG. 26 can be obtained (step S221). As shown in Figure 26, the payment retention aggregate data includes information regarding the recording date, breakdown category, and payment status, so for example, it is possible to check whether there is a long-term payment retention in unpaid records. become able to.

When payment completion is confirmed, the payment management data shown in FIG. 24 is updated as shown in FIG. 27.

Below, multiple examples of aggregated data and corresponding forms will be described.

FIG. 28 is a diagram schematically showing a first example of the aggregated data created in step S221 of FIG. 2. FIG. 29 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 28. The aggregate data shown in FIG. 28 is payment retention money aggregate data, and can be obtained by aggregating records in which payment retention and non-payment are set. The form shown in FIG. 29 arranges the information included in the aggregated data shown in FIG. 28 on a project-by-project basis and on a creditor-by-creditor (payee-by-payee basis) basis. By outputting such a form, the user can quickly check the status of payment suspension. Furthermore, by outputting a portion of such a form, it becomes possible to quickly prepare a written response to an inquiry from a creditor. Alternatively, it is also possible to quickly prepare an inquiry response form by aggregating records of creditors who have received inquiries.

FIG. 30 is a diagram schematically showing a second example of the aggregated data created in step S221 of FIG. 2. FIG. 31 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 30. The aggregate data shown in FIG. 30 is payment retention money aggregate data that can be obtained by aggregating records in which payment retention and non-payment are set in the same way as shown in FIG. 28, and in this example, further, Contains records with payment hold release set. Therefore, the form shown in FIG. 31 also includes information regarding release of payment hold. By outputting such a report, the user will be able to understand the unit projects for which payment suspension has been released. Unit businesses (unit businesses for which payment suspension has been released) can be quickly grasped.

FIG. 32 is a diagram schematically showing a third example of the aggregated data created in step S221 of FIG. 2. FIG. 33 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 32. The aggregate data shown in FIG. 32 is payment retention aggregate data that can be obtained by aggregating records in which payment retention, payment retention release, and non-payment are set in the same way as shown in Figure 30. Also includes a record set to Paid. Therefore, the form shown in FIG. 33 also includes information regarding payment. By outputting such a form, the user can easily understand the recipient of the payment and can appropriately manage the payment. Furthermore, by outputting such a form, the user can easily answer an inquiry from a creditor as to whether the payment has been made.

FIG. 34 is a diagram schematically showing a fourth example of the aggregated data created in step S221 of FIG. 2. FIG. 35 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 34. FIG. 35(a) shows an example of a payment notice for the first payee, ) shows an example of a payment notice for the second payee, and FIG. 35(c) shows an example of a payment notice for the third payee. The aggregated data shown in Figure 34 is payment retention aggregate data, which is based on data that combines payment management data and earned value acceptance data. It can be obtained by aggregating records that have a certain accounting date). Thereby, payment pending records in which non-accountable information is set in the scheduled payment date information can also be aggregated. Therefore, as shown in FIG. 35(a), FIG. 35(b), and FIG. 35(c), it becomes possible to include at least the deduction amount of the retention money in the payment notice to each payee.

FIG. 36 is a diagram schematically showing a fifth example of the aggregated data created in step S221 of FIG. 2. FIG. 37 is a diagram showing an example of the structure of a form created based on the aggregated data shown in FIG. 36. FIG. ) shows an example of a payment notice for the second payee, and FIG. 37(c) shows an example of a payment notice for the third payee. The aggregated data shown in FIG. 36 can be generated in the same way as the payment retention money aggregated data shown in FIG. 34, and in the example shown in FIG. 36, payment retention release records are also aggregated. Therefore, as shown in Figures 35(a), 35(b), and 35(c), it is possible to include both the deduction amount and the cancellation amount of the retention money in the payment notice to each payee. It becomes like this.

FIG. 38 is a diagram schematically showing a sixth example of the aggregated data created in step S221 of FIG. 2. FIG. 39 is a diagram schematically showing aggregated data created based on the aggregated data shown in FIG. 38. FIG. 39(a) shows an example of aggregated data regarding the first unit business, ) is a diagram showing an example of aggregated data regarding the second unit business. The aggregated data shown in FIG. 38 is generated by aggregating payments for each unit project that constitutes the project. The aggregated data shown in FIGS. 39(a) and 39(b) are generated by extracting a part of the aggregated data (aggregated data for each unit business) shown in FIG. 38. As shown in FIGS. 38 and 39, according to this embodiment, payments for each unit business can also be easily grasped.

[3. Other embodiments]
In addition to the embodiments described above, the present invention may be implemented in various different embodiments within the scope of the technical idea described in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all of the processes described as being performed manually can be performed manually. Alternatively, some of the steps can be performed automatically using known methods.

In addition, unless otherwise specified, information including processing procedures, control procedures, specific names, parameters such as registered data and search conditions for each process, screen examples, and database configurations shown in this specification and drawings are included. It can be changed arbitrarily.

Furthermore, regarding the payment management data generation device 100 and the payment management data generation system 1000, the illustrated components are functional and conceptual, and do not necessarily need to be physically configured as illustrated.

For example, the processing functions provided by the payment management data generation device 100, especially each processing function performed by the control unit, may be realized in whole or in part by a CPU and a program interpreted and executed by the CPU. Alternatively, it may be realized as hardware using wired logic. Note that the program is recorded on a non-temporary computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processing described in this embodiment, and the program is recorded on a non-temporary computer-readable recording medium that includes payment management data as necessary. It is mechanically read by the generator 100. That is, a storage unit such as a ROM or an HDD (Hard Disk Drive) stores a computer program that cooperates with an OS to give instructions to a CPU and perform various processes. This computer program is executed by being loaded into the RAM, and constitutes a control unit in cooperation with the CPU.

Further, this computer program may be stored in an application program server connected to the payment management data generation device 100 via an arbitrary network (for example, the network 300), and may be stored in whole or in part as necessary. It is also possible to download.

Further, a program for executing the processing described in this embodiment may be stored in a non-temporary computer-readable recording medium, or may be configured as a program product. Here, the "recording medium" includes a memory card, a USB (Universal Serial Bus) memory, an SD (Secure Digital) card, a flexible disk, a magneto-optical disk, a ROM, an EPROM (Erasable Programmable Read Only Memory), and an EE. PROM (registration Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROM (Compact Disk Read Only Memory), MO (Magneto-Optical disk) ), DVD (Digital Versatile Disk), Blu-ray (registered trademark) Disc, etc. shall include any “portable physical medium”. Therefore, a recording medium storing a program for executing the processing described in this specification also constitutes the present invention.

Further, a "program" is a data processing method written in any language or writing method, and does not matter in the form of source code or binary code. Note that a "program" is not necessarily limited to a unitary structure, but may be distributed as multiple modules or libraries, or may work together with separate programs such as an OS to achieve its functions. Including things. Note that well-known configurations and procedures can be used for the specific configuration and reading procedure for reading the recording medium in each device shown in the embodiments, and the installation procedure after reading.

Various databases and the like stored in the storage unit 106 are storage means such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and various databases used for various processing and website provision. Stores programs, tables, databases, web page files, etc.

Further, the payment management data generation device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. Further, the payment management data generation device 100 may be realized by installing software (including programs, data, etc.) that causes the device to realize the processing described in this specification.

Furthermore, the specific form of dispersion and integration of devices is not limited to what is shown in the diagram, and all or part of them can be functionally or physically divided into arbitrary units according to various additions or functional loads. It can be configured in a distributed/integrated manner. That is, the embodiments described above may be implemented in any combination, or the embodiments may be implemented selectively.

INDUSTRIAL APPLICATION This invention is useful when performing payment management, and is especially useful when performing payment management including payment suspension or payment suspension release.

100 Payment management data generation device 102 Control unit 102A Hold release regulation unit 102B Payment management data generation unit 102b Payment hold data update unit 102C Output unit 104 Communication interface unit 106 Storage unit 106a Project master 106b Creditor master 106c Debt setting data storage area 106d Payment management data storage area 106e Aggregate data storage area 108 Input/output interface section 112 Input device 114 Output device 200 Server 300 Network 1000 Payment management data generation system

Claims (11)

A payment reservation data management device comprising a control unit for managing payment reservation data regarding a payment reservation amount of payments to one or more creditors for a project that generates one or more unit debts that can span multiple accounting months. There it is,
The control unit includes:
When the payment suspension release amount information regarding the payment suspension release amount for part or all of the payment suspension amount for which payment to the creditor is suspended or the payment suspension target ratio to the total payment suspension amount is set, the payment suspension data comprising a payment hold data update means for updating a target payment hold record including payment hold amount information regarding the said payment hold amount,
The payment pending data updating means includes:
The set payment hold release amount information is set in place of the payment hold amount information regarding the payment hold amount included in the target payment hold record, and information indicating payment hold release is set as payment hold state information. A payment reservation data management device characterized in that the payment reservation data is updated by at least generating a payment reservation release record. The payment pending data updating means includes:
2. The payment hold data management device according to claim 1, wherein the payment hold release record is set with date information regarding an accounting date or scheduled accounting date of payment hold release corresponding to the payment hold release amount information. The payment pending data updating means includes:
If the payment hold release amount is a part of the payment hold amount, a new difference payment hold record is generated that includes the difference between the payment hold amount and the payment hold release amount as payment hold amount information. The payment pending data management device according to claim 1 or 2. The payment pending data updating means includes:
4. The payment retention data management device according to claim 3, wherein the payment retention data management device sets in the difference payment retention record information indicating that the recording date or scheduled recording date for release of payment retention is not determined. The payment pending data updating means includes:
When one or more target payment retention records exist in the payment retention data, each of the one or more target payment retention records has a priority selected from among a plurality of preset priorities. The payment pending data management device according to any one of claims 1 to 4, wherein a priority is set. The plurality of priorities include the order in which the recording date of the payment hold amount is closer, the order in which the payment hold amount is closer to the full amount of the payment hold release amount, or the order determined by a combination thereof. The payment pending data management device according to claim 5. The payment pending data updating means includes:
The payment reservation data management device according to any one of claims 1 to 6, wherein the target payment reservation record is deleted when the update of the payment reservation data is completed. The control unit includes:
According to any one of claims 1 to 7, further comprising a hold release regulation means for restricting setting of payment hold release amount information regarding a payment hold release amount that exceeds the total amount of the payment hold amounts. payment hold data management device. The project is a contract work that includes multiple unit projects,
The debtor of the one or more unit obligations is the contractor of the contracted work, and
The payment pending data management device according to any one of claims 1 to 8, wherein the creditor is a subcontractor of the unit business. Managing payment pending data regarding the pending payment amount of payments to one or more creditors for a project that generates one or more unit debts that may span multiple accounting months, which is executed in an information processing device equipped with a control unit. A payment hold data management method for:
executed in the control unit,
When the payment suspension release amount information regarding the payment suspension release amount for part or all of the payment suspension amount for which payment to the creditor is suspended or the payment suspension target ratio to the total payment suspension amount is set, the payment suspension data a payment hold data update step of updating a target payment hold record including payment hold amount information regarding the payment hold amount,
In the payment hold data update step,
The set payment hold release amount information is set in place of the payment hold amount information regarding the payment hold amount included in the target payment hold record, and information indicating payment hold release is set as payment hold state information. A payment hold data management method, comprising: updating the payment hold data by generating at least a payment hold release record. Managing payment pending data regarding the pending payment amount of payments to one or more creditors for a project that generates one or more unit debts that may span multiple accounting months, which is executed in an information processing device equipped with a control unit. A payment hold data management program for:
for execution in the control unit,
When the payment suspension release amount information regarding the payment suspension release amount for part or all of the payment suspension amount for which payment to the creditor is suspended or the payment suspension target ratio to the total payment suspension amount is set, the payment suspension data a payment hold data update step of updating a target payment hold record including payment hold amount information regarding the payment hold amount,
In the payment hold data update step,
The set payment hold release amount information is set in place of the payment hold amount information regarding the payment hold amount included in the target payment hold record, and information indicating payment hold release is set as payment hold state information. A payment hold data management program characterized in that the payment hold data is updated by at least generating a payment hold release record.

Images