JP2021168214A - Bulk payment processor, bulk payment processing method, and bulk payment processing program - Google Patents

Abstract

To provide a bulk payment processor, a bulk payment processing method and a bulk payment processing program capable of carrying out payment in a lump sum (bulk payment by headquarters to individual billings for business offices).SOLUTION: In the bulk payment processing method in an embodiment, a billing delivery source carries out a series of processing including: plural payments such as headquarters bulk payment based on the transaction destination; claim remaining and/or receivables remaining for respective business offices; and payment processing to a single headquarter code. Management of the claim remaining is carried out based on not only business offices but also entire of transaction destinations. With this, although the payment processing was conventionally carried out after checking billing amount for respective business offices, the payment processing and the clearing processing are completely separated from each other, the payment processing can be swiftly carried out based on actual payment.SELECTED DRAWING: Figure 3

Description

The present invention relates to a batch deposit processing device, a batch deposit processing method, and a batch deposit processing program.

Patent Document 1 describes a claim clearing device (FIG. 13 or the like) capable of collectively clearing a plurality of claims corresponding to payments made to a plurality of claims in a batch. There is.
Specifically, in FIG. 4, which explains the outline of the lump-sum receivable clearing process of Patent Document 1, as shown in FIG. Compare the total amount on the billing statement with the deposit amount. As a result of the comparison, if the total amount of all billing details of the payer matching the transfer requester who made the deposit matches the deposit amount, all the billing details of the payer are subject to clearing. Perform erasing. As a result of the comparison, if the total amount of all invoices of the payer who matches the transfer requester who made the deposit does not match the deposit amount, all of the total invoices are the basis of the total invoice. The total amount of the invoice details (hereinafter referred to as the total invoice amount) is obtained, and the total invoice amount of the total invoice is compared with the deposit amount. As a result of the comparison, if the total invoice amount and the deposit amount of any of the total invoices match, all the invoice details that are the source of the matching total invoice are subject to clearing, and the clearing is performed. conduct. As a result of the comparison, if the deposit amount does not match the total invoice amount of any of the total invoices, the total amount of all the invoice details that are the basis of the monthly invoice (hereinafter referred to as "monthly invoice unit"). The monthly invoice amount is compared with the deposit amount for the monthly invoice amount). As a result of the comparison, if the monthly invoice amount and the deposit amount of any of the monthly invoices match, all the invoice details that are the basis of the matching monthly invoice are subject to clearing. Perform the invoice. (Patent Document 1 paragraphs 0027 to 0029).

Japanese Unexamined Patent Publication No. 2006-323532

However, with the conventional technology, it is not possible to manage the balance of bills and receivables for each base at a business partner such as multiple billing bases and lump-sum payment at the head office for deposits, and the head office code can be used for payment processing. There was a problem that it was not possible to process the deposit, and it was not possible to grasp the balance of receivables not only by base but also by the entire business partner.

The present invention has been made in view of the above problems, and the management of the balance of claims and the balance of receivables is managed for each base at a business partner such as a plurality of billing bases and a lump sum payment at the head office for payment, and payment processing is performed. For, the head office code is used for single deposit processing, and for the balance of receivables, not only for each base, but also for the entire business partner, a batch deposit processing device, a batch deposit processing method, and a batch deposit The purpose is to provide a processing program.

In order to solve the above-mentioned problems and achieve the object, the batch deposit processing device according to the present invention is a batch deposit processing device including a storage unit and a control unit, and the storage unit is a billing destination. The control unit includes a billing data storage means for storing billing data including a destination data and a billing amount, and the control unit uses the deposit data acquisition means for acquiring deposit data from a plurality of representatives of the billing destination and the deposit data. Based on this, it is characterized in that it is provided with a billing balance management means for managing the billing balance for each billing destination by performing a clearing process on the billing data.

Further, in the batch deposit processing device according to the present invention, in the batch deposit processing device, the billing data further includes a closing date, and the billing balance management means is based on the deposit data. It is characterized in that the billing balance for each billing destination is managed by performing the clearing processing on the billing data in the order of closeness.

Further, in the batch deposit processing device according to the present invention, in the batch deposit processing device, the billing balance management means further, among the deposit data, the deposit data that has not been applied is temporarily received data. It is characterized in that it is registered in the billing data storage means.

Further, in the batch deposit processing device according to the present invention, in the batch deposit processing device, the billing balance management means uses the deposit data of the deposit request destination designated as the deposit source to request the deposit. It is characterized in that the billing balance for each billing destination is managed by performing a clearing process on the billing data of the clearing billing destination, which is a billing destination different from the destination.

Further, the batch deposit processing method according to the present invention is a batch deposit processing method for causing a batch deposit processing device including a storage unit and a control unit to execute the batch deposit processing method, and the storage unit is used with the billing destination data of the billing destination. Based on a payment data acquisition step of acquiring payment data from a plurality of representatives of the billing destination, which is provided by a billing data storage means for storing billing data including a billing amount and executed by the control unit, and the payment data. It is characterized by including a billing balance management step of managing the billing balance for each billing destination by performing the clearing process on the billing data.

Further, the batch deposit processing program according to the present invention is a batch deposit processing program for being executed by a batch deposit processing device including a storage unit and a control unit, and the storage unit is a billing destination data of a billing destination. A billing data storage means for storing billing data including a billing amount is provided, and the control unit has a deposit data acquisition step of acquiring deposit data from a plurality of representatives of the billing destination, and based on the deposit data. By performing the clearing process on the billing data, the billing balance management step of managing the billing balance for each billing destination is executed.

According to the present invention, there are a plurality of billing sending bases, and the management of the balance of claims and the balance of receivables is managed for each base at a business partner such as a lump sum payment at the head office for payment, and the payment processing is made with a single head office code. It has the effect of being able to process and grasp the balance of receivables not only by base but also by all business partners.

FIG. 1 is a diagram showing an example of issuing a deposit slip. FIG. 2 is a diagram showing an example of issuing a deposit slip. FIG. 3 is a block diagram showing an example of the configuration of the batch deposit processing device. FIG. 4 is a flowchart showing an example of processing of the batch deposit processing device according to the present embodiment. FIG. 5 is a diagram showing an outline of application for multiple billing destinations. FIG. 6 is a diagram showing an outline of application for multiple billing destinations. FIG. 7 is a diagram showing an outline of application for multiple billing destinations. FIG. 8 is a diagram showing an outline of application for multiple billing destinations. FIG. 9 is a diagram showing an outline of application for multiple billing destinations. FIG. 10 is a diagram showing an outline of application for multiple billing destinations. FIG. 11 is a diagram showing details of acquisition of the deposit amount at the time of billing. FIG. 12 is a diagram showing details of acquisition of the deposit amount at the time of billing. FIG. 13 is a diagram showing an advance reception in the present embodiment. FIG. 14 is a diagram showing an example of a deposit input screen.

Embodiments of the present invention will be described in detail with reference to the drawings. The present invention is not limited to the present embodiment.

[1. Overview]
The outline of the present invention will be described with reference to FIGS. 1 and 2. 1 and 2 are diagrams showing an example of issuing a deposit slip.

First, in the past, since the billing processing code = deposit processing code was premised, it was necessary to perform the deposit processing after confirming the billing amount of each base of the business partner. In addition, in the past, the deposit slip itself had to be divided by billing unit, so the number of deposit details and bills actually received and the number of deposit details on the system differed (matched in total). There was a problem that it would end up.

For example, as shown in Fig. 1, in the past, even if payments (transfers, bills) were made collectively from the head office, payment slips were issued separately based on the credit base (billing destination) owned by the company. I had to do it. As a result, in the past, the deposit processing was performed after confirming the applied receivables, so that the issuance of the deposit slip was delayed, and as a result, the confirmation of the balance of the deposit was delayed. Further, in the past, even when the payment operation was performed by importing the transfer payment data such as FB, the billing destination was premised on the payment, so the manual operation was necessary. In addition, in the past, there was a case where a bill system or the like was generally introduced for bills to manage the face of the bill, but since the deposit process must be performed in a form different from the face of the bill, what is the bill system? I had to take separate management.

Therefore, in the present embodiment, it is possible to make a lump sum payment (a lump sum payment at the head office for each individual bill), that is, a business partner who has a plurality of billing bases and a lump sum payment at the head office for payment. In addition, it is possible to manage the balance of receivables by base, and for deposit processing, it is possible to process deposits with a single head office code. Further, in the present embodiment, it is possible to grasp the balance of receivables not only by base but also by all business partners. As a result, in the past, the payment process was performed after confirming the billing amount for each base, but in this embodiment, the payment process and the application process are completely separated and matched with the payment fact. The deposit process is realized at an early stage. Further, in the present embodiment, as a result of the application processing, the deposit balance whose application target is unknown can be automatically managed as a temporary receipt by the head office code.

For example, as shown in FIG. 2, in the present embodiment, pattern (1): when the billing destination and the deposit destination are one and the same base, pattern (2): the billing destination is the head office and branch office of each sales base. , When the payment destination is the same head office and branch office, and pattern (3): It is possible to handle all cases where the billing destination is the head office and branch office of each sales base and the payment destination is the head office.

[2. composition]
An example of the configuration of the batch deposit processing device 100 according to the present embodiment will be described with reference to FIG. FIG. 3 is a block diagram showing an example of the configuration of the batch deposit processing device 100.

The batch deposit processing device 100 is a commercially available desktop personal computer. The batch deposit processing device 100 is not limited to a stationary information processing device such as a desktop personal computer, but is a portable personal computer, a PDA (Personal Digital Assistants), a smartphone, a tablet personal computer, or the like on the market. It may be a type information processing device.

The batch deposit processing device 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each part of the batch deposit processing device 100 is communicably connected via an arbitrary communication path.

The communication interface unit 104 connects the batch deposit processing device 100 to the network 300 so as to be communicable 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 another device via a communication line. Here, the network 300 has a function of connecting the batch deposit processing device 100 and the server 200 so as to be able to communicate with each other, and is, for example, the Internet, a LAN (Local Area Network), or the like.

Various databases, tables, files, and the like are stored in the storage unit 106. In the storage unit 106, a computer program for giving an instruction to a CPU (Central Processing Unit) in cooperation with an OS (Operating System) to perform various processes is recorded. 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, or the like can be used. The storage unit 106 includes a billing data file 106a.

The billing data file 106a stores billing data including billing destination data and billing amount. The billing data may further include a closing date.

An input device 112 and an output device 114 are connected to the input / output interface unit 108. As the output device 114, a speaker or a printer can be used in addition to a monitor (including a home television). 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. In the following, the output device 114 may be referred to as a monitor 114, and the input device 112 may be referred to as a keyboard 112 or a mouse 112.

The control unit 102 is a CPU or the like that collectively controls the batch deposit processing device 100. The control unit 102 has an internal memory for storing a control program such as an OS, a program that defines various processing procedures, required data, and the like, and performs various information processing based on these stored programs. Run. The control unit 102 functionally includes a payment data acquisition unit 102a and a billing balance management unit 102b.

The deposit data acquisition unit 102a acquires deposit data from representatives of a plurality of billing destinations.

The billing balance management unit 102b manages the billing balance for each billing destination by performing application processing on the billing data based on the deposit data. Here, the billing balance management unit 102b may manage the billing balance for each billing destination by performing the application processing on the billing data in the order of the closing date based on the payment data. In addition, the billing balance management unit 102b may further register (store) the deposit data that has not been applied out of the deposit data in the billing data file 106a as temporary receipt data. In addition, the billing balance management unit 102b uses the payment data of the payment billing destination, which is the billing destination designated as the payment source, to perform the application processing for the billing data of the application billing destination, which is a billing destination different from the payment billing destination. By doing so, the billing balance may be managed for each billing destination.

[3. Concrete example]
Specific examples of this embodiment will be described with reference to FIGS. 4 to 14.

[Sales transfer processing]
Here, an example of the batch deposit processing in the present embodiment will be described with reference to FIG. FIG. 4 is a flowchart showing an example of processing of the batch deposit processing device 100 in the present embodiment.

As shown in FIG. 4, the deposit data acquisition unit 102a acquires deposit data from representatives of a plurality of billing destinations (step SA-1).

Then, the billing balance management unit 102b performs a billing process on the billing data stored in the billing data file 106a in the order of the closing date based on the deposit data acquired by the deposit data acquisition unit 102a. The billing balance is managed for each destination, and among the deposit data, the deposit data that has not been applied is registered as provisional receipt data in the billing data file 106a (step SA-2), and the processing is completed. Here, the billing balance management unit 102b uses the payment data of the payment billing destination designated as the payment source to apply the application processing to the billing data of the application billing destination that is different from the payment billing destination. By performing the above, the billing balance for each billing destination may be managed.

Here, the processing contents of the batch deposit processing apparatus will be described with reference to FIGS. 5 to 14.

FIGS. 5, 6 and 7 are diagrams showing an outline of application for multiple billing destinations. When making a transfer from a customer or making a transfer to the head office account for cash collection by a business office, multiple billing destinations may be collectively paid. In this case, implement a function to decompose into the amount of money for each billing destination. Regarding the sorting coordination of the accounting system, consider the division of billing destinations.

As a result of deposit input and EB (electronic banking) deposit import, data that has been deposited for multiple billing destinations is made to correspond to the deposit input so that it can be applied to each billing destination. The setting of whether or not to make a bulk deposit is made for each billing address. That is, for the payment billing destination in which the billing destination master maintenance sets "collective payment flag = 1", the billing data to be displayed in the application target is similarly set to "collective payment flag = 1" for all billing destinations. Minutes. By default, only the billing destinations specified in the master setting are displayed, but by changing the conditions, all billing destinations with "Bulk deposit flag = 1" can be applied. do. In addition, in the billing destination master maintenance, the billing destination in which "collective payment flag = 0" is the same as the payment billing destination and the application payment destination (payment billing destination = application payment destination) as before. do. In other words, it is not possible to apply payments from billing destinations other than yourself, and it is also not possible to apply to other billing destinations. When making a bulk deposit, the denomination cannot be printed on the billing statement. Also, automatic application is not possible. If the payment is not made in bulk, the denomination can be printed on the invoice and automatically applied as before.

The specific processing of the application will be described with reference to FIGS. 5, 6 and 7. In the following explanation, the billing destinations AAA, BBB, and CCC all have the same closing date (last day closing).

First, the invoices S001 to S004 shown in FIG. 5 are issued on the closing date 201 × / 12/31.
Next, in the EB (electronic banking) deposit capture, the deposit information including the information shown in FIG. 5 is fetched. In addition, the received deposit corresponds to the one deposited collectively from the billing address AAA. Further, as a payment journal for the imported payment information, the one shown in FIG. 5 is created.
Next, in the deposit input, application information is created for the imported deposit information. The created application information is applied to a plurality of billing destinations (billing destination AAA, BBB). In addition, in the application information, the payment date and the application date shall be the same day (payment date = application date). From the deposit information, it can be seen that the entire deposit amount has been transferred by AAA. Further, as an application journal for the application information, the one shown in FIG. 5 is created. The application item in the deposit information is marked as not completed, indicating that it has not been completed.

Next, the invoices S005 and S006 shown in FIG. 6 are issued on the closing date 201 × + 1/01/31. The new invoices S005 and S006 are stored in the billing target item in the state of being linked to S001 and S002 stored in the clearing target billing item in the application information.
Next, in the deposit input, application information is created for the imported deposit information. The created application information is applied to the billing destinations including the billing destination AAA and BBB and the billing destination CCC. In addition, when correcting the application information, the payment date and the application date shall be different days (payment date ≠ application date). From the deposit information, it can be seen that the entire deposit amount has been transferred by AAA. Further, as the application journal for the application information, the one shown in FIG. 6 is created. In FIG. 6, the previous application information is corrected for the invoices S001 and S002, and the invoices S001, S002 and S003 are applied again. Since the entire amount deposited in bulk from the billing address AAA has been applied, the application item in the deposit information is indicated as complete, indicating that it has been completed.

Next, the invoices S007 to S009 shown in FIG. 7 are issued on the closing date 201 × + 1/02/28. The new invoices S007 to S009 are stored in the billing target item in the state of being linked to S001 to S003 stored in the clearing target billing item in the application information.

The payment operation when a batch payment is made to a plurality of billing destinations subject to application in the state before the current response (the above-mentioned response according to the present embodiment (FIGS. 5 to 7)) is as follows. In the past, the payment billing destination and the application billing destination had to be the same (payment billing destination = application billing destination), so if a batch payment is made to multiple billing destinations, the payment information is registered. Before, it was necessary to divide the deposit information itself after investigating which billing destination and how much the deposit was for. As a result, it is necessary to create and divide the payment slips more than the actual number of times the payment slips are generated, and the operation and the generated journals are complicated.

Specific processing of the application will be described with reference to FIGS. 8, 9 and 10. In the following explanation, the billing destinations AAA, BBB, and CCC all have the same closing date (last day closing).

First, the invoices S001 to S004 shown in FIG. 8 are issued on the closing date 201 × / 12/31.
Next, in the EB (electronic banking) deposit capture, the deposit information including the information shown in FIG. 8 is fetched. In addition, the received deposit corresponds to the one deposited collectively from the billing address AAA. Further, as a payment journal for the imported payment information, the one shown in FIG. 8 is created.
Next, in the deposit input, application information is created for the imported deposit information. The created application information is applied to a plurality of billing destinations (billing destination AAA, BBB). In addition, in the application information, the payment date and the application date shall be the same day (payment date = application date). Furthermore, it is necessary to divide the payment information and apply it so that it can be applied to the invoices of multiple billing destinations. That is, in the payment information, the billing destination AAA and the billing destination BBB are divided, and the application of one of them is completed. A split black biography will be issued for the completed application, and the other will be a correction of the deposit. The deposit journal for the deposit information is created as shown in FIG. The item of application in the payment information is displayed as not yet completed in S001, and has not been completed. In S002, it is shown that it is completed.

Next, the invoices S005 and S006 shown in FIG. 9 are issued on the closing date 201 × + 1/01/31. The new invoices S005 and S006 are stored in the billing target item in the state of being linked to S001 and S002 stored in the clearing target billing item in the application information.
Next, in the deposit input, application information is created for the imported deposit information. The created application information is applied to the billing destinations including the billing destination AAA and BBB and the billing destination CCC. In addition, when correcting the deposit information and application information, the deposit date and the application date shall be different days (payment date ≠ application date). AAA and CCC will be newly added to the billing address for payment information. AAA is the red biography of the division, and CCC is the black biography of the division. Further, as a deposit journal for the deposit information, the one shown in FIG. 9 is created. In FIG. 9, application information is provided for invoices S001 and S003. Since the entire amount deposited in bulk from the billing address AAA has been applied, the application item in the deposit information is indicated as complete, indicating that it has been completed.

Next, the invoices S007 to S009 shown in FIG. 10 are issued on the closing date 201 × + 1/02/28. The new invoices S007 and S009 are stored in the item to be billed in the state of being linked to the "adjustment amount" and S003 stored in the item of the bill to be cleared in the application information.

11 and 12 are diagrams showing details of acquisition of the deposit amount at the time of billing. Along with the response that it is possible to specify a billing address different from the billing address of the deposit source as the application destination when performing the payment application, the acquisition source of the payment record acquisition at the time of billing closing processing is the payment application details. Change to get from the history.
Next, the words are defined below. The deposit billing destination is the billing destination (payment header. Billing destination (billing destination stored in the deposit header)) designated as the deposit source. The application billing destination is the billing destination designated as the application target (collection schedule of the application target. Billing destination (billing destination stored in the collection schedule data)). The billing payment month is the payment header. It is the month in which the billing is closed with the payment date (the payment date stored in the payment header) as the base date. The billing application month is the payment application header. It is the month that is within the billing closing range based on the payment application date (the payment application date stored in the payment header (obtained from the payment application details history)). For example, if the billing destination is closed on the 20th and the payment date is 201 × + 1/06/25 and the payment application date is 201 × + 1/07/31, the billing payment month is 201 × + 1/06, and the billing application month. Is 201 × + 1/07.
The method of obtaining the payment record at the time of provisional billing will be changed as follows. When creating billing data (payment record) for a billing destination (the clearing billing destination is different from the payment billing destination (clearing billing destination ≠ payment billing destination)), the payment amount of the clearing billing destination for the current month Is the history of payment application details. It is a total of the payment application amount (the payment application amount stored in the payment application detail history data) (from the application detail history (billing NO)).
Next, when creating billing data (payment record) related to the billing destination (the application billing destination is the same as the payment billing destination (application billing destination = payment billing destination)), the deposit amount of the payment billing destination for the current month And the payment amount (unapplied amount) of the payment request destination for the current month, minus the applied amount (subtracted amount) corresponding to the application source. The payment amount of the payment request destination for the current month is the history of payment application details. It is a total of the payment application amount (the payment application amount stored in the payment application detail history data) (from the application detail history (billing NO update)). The deposit amount (unapplied amount) of the deposit request destination for the current month is the deposit header. The amount of the deposit application source fund (the amount of the deposit application source fund stored in the deposit header) (from the deposit H (header) (billing NO update)). The applied amount (subtracted amount) corresponding to the application source is the payment application breakdown history. This is a total of the amount of resources for application this time (the amount of resources for application this time stored in the payment application breakdown history data) (from the application breakdown history (billing NO update)).

FIG. 13 is a diagram showing an advance reception in the present embodiment. If you do not make a lump sum deposit, you will get the deposit amount on the deposit date, including the deposit amount corresponding to the advance receipt (managed with a negative carry-forward balance). In addition, when sales and advance receipts are offset, only sales details are acquired to maintain consistency as a whole. When making a bulk deposit, the unapplied balance at the time of billing is acquired as the actual result of the billing destination at the time of billing (amount of funds for application-amount of funds for application of breakdown (amount of funds for application this time)). No application is obtained for the advance request. Even if the denomination is offset in advance, the amount to be applied will be acquired as the deposit amount.

FIG. 14 is a diagram showing an example of a deposit input screen. The deposit input screen includes an area for inputting / outputting deposit information and an area for applying. Data is extracted and displayed based on the information entered as application information.

Here, the background and the outline of the present embodiment will be briefly described again.
Credit management is basically on a billing basis, but in the case of a large company, there are cases where multiple billing destinations are required for one corporation (example: cases where billing is required for each business division). Furthermore, when there are multiple billing destinations for one corporation, there are cases where payment is made from the billing destination and cases where payment is made from the corporate representative (head office).
Therefore, in the present embodiment, a mechanism has been realized in which the unit of payment source management and receivables clearing can be correctly managed according to these practices. Specifically, in the present embodiment, the deposit destination and the billing destination are managed separately. Further, in the present embodiment, when narrowing down the application target, the payment request destination is narrowed down. Further, in the present embodiment, when the payment application unit is "automatic", the old receivables to be collected are applied first.
Then, according to the present embodiment, even if there is a bulk deposit, it can be recorded at the timing of the deposit, and the receivable balance of the billing destination unit can be applied. Further, according to the present embodiment, it can be used not only in the relationship of the head office but also in the relationship of a group company. Further, according to the present embodiment, there are two patterns of payment data, manual input and EB import, but the same management is possible even with EB import. In addition, according to the present embodiment, credit management within the system is possible at both the deposit source and the billing destination. Further, according to the present embodiment, it has become possible to automatically generate accounting journals. Further, according to the present embodiment, when an application error occurs, it is possible to correct it correctly including accounting from the next month onward. Further, according to the present embodiment, it is possible to present the payment information at the time of billing by speeding up the payment processing. Further, according to the present embodiment, corporate management, provisional receipt management in payment application, application pattern management, receivable management unit (billing destination / payment destination) management, bulk payment, and journal entry cooperation are possible.
The differences between this embodiment and Patent Document 1 (Japanese Unexamined Patent Publication No. 2006-323532) are as follows.
-In this embodiment, the total numbering process is not required.
-In this embodiment, the "total summary unit" (closing date, payer, currency, total billing numbering unit item) is not required.
-In this embodiment, the invoices need not be sent to the same company.
-In this embodiment, the deposit amount and the billing amount do not have to match.
-In the present embodiment, payment journals and payment application journals for a plurality of application destinations can be linked to the accounting system.

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

For example, of each of the processes described in the embodiments, all or part of the processes described as being automatically performed may be manually performed, or all of the processes described as being performed manually. Alternatively, a part thereof can be automatically performed by a known method.

In addition, the processing procedure, control procedure, specific name, information including parameters such as registration data and search conditions of each processing, screen examples, and database configuration shown in the present specification and drawings are not specified unless otherwise specified. Can be changed arbitrarily.

Further, with respect to the batch deposit processing device 100, each component shown in the figure is a functional concept and does not necessarily have to be physically configured as shown in the figure.

For example, with respect to the processing functions included in the batch deposit processing device 100, particularly each processing function performed by the control unit 102, all or any part thereof is realized by the CPU and a program interpreted and executed by the CPU. It may be realized as hardware by wired logic. The program is recorded on a non-temporary computer-readable recording medium including a programmed instruction for causing the information processing apparatus to execute the process described in the present embodiment, and a batch deposit process is performed as necessary. It is read mechanically by the device 100. That is, a computer program for giving instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or an HDD (Hard Disk Drive). This computer program is executed by being loaded into the RAM, and cooperates with the CPU to form a control unit.

Further, this computer program may be stored in the application program server connected to the batch deposit processing device 100 via an arbitrary network, and all or a part thereof can be downloaded as needed. Is.

Further, the program for executing the process described in the present 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 EEPROM (registration). Trademarks) (Electrically Erasable and Programmable Read Only Memory), CD-ROM (Compact Disk Read Only Memory), MO (Magnet-Optical Disk), MO (Magnet-Optical Disk), MO (Magnet-Optical Disc), DVD (Digital), DVD (Digital) It shall include any "portable physical medium".

The "program" is a data processing method described in any language or description method, regardless of the format such as source code or binary code. The "program" is not necessarily limited to a single program, but is distributed as a plurality of modules or libraries, or cooperates with a separate program represented by the OS to achieve its function. Including things. A well-known configuration or procedure can be used for a specific configuration and reading procedure for reading the recording medium in each device shown in the embodiment, an installation procedure after reading, and the like.

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

Further, the batch deposit processing 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 an arbitrary peripheral device is connected. Further, the batch deposit processing device 100 may be realized by mounting software (including a program or data) that realizes the processing described in the present embodiment on the device.

Further, the specific form of distribution / integration of the device is not limited to the one shown in the drawing, and all or a part thereof may be functionally or physically in an arbitrary unit according to various additions or functional loads. It can be distributed and integrated. That is, the above-described embodiments may be arbitrarily combined and implemented, or the embodiments may be selectively implemented.

The present invention is particularly useful in companies that do business with business partners nationwide.

100 Bulk deposit processing device 102 Control unit 102a Deposit data acquisition unit 102b Billing balance management unit 104 Communication interface unit 106 Storage unit 106a Billing data file 108 Input / output interface unit 112 Input device 114 Output device 200 Server 300 Network

Claims (4)

It is a batch deposit processing device equipped with a storage unit and a control unit.
The storage unit
A billing data storage means for storing billing data including billing destination data, billing amount, and expected collection date, and
A billing destination storage means for storing a billing destination master in which a collective deposit flag indicating the billing destination that is the target of application using payment data from a plurality of representatives of the billing destination is set, and a billing destination storage means.
With
The control unit
A deposit data acquisition means for acquiring the deposit data from the representatives of the plurality of billing destinations, and
Using the payment data of the payment billing destination designated as the payment source, the collective payment flag is set in the billing destination master in the order of the oldest scheduled collection date, which is different from the payment billing destination. A billing balance management means for managing the billing balance for each billing destination by performing a clearing process on the billing data of the cleared billing destination, which is the billing destination.
A bulk deposit processing device characterized by being equipped with. The billing balance management means
Further, the batch deposit processing apparatus according to claim 1, wherein among the deposit data, the deposit data that has not been applied is registered as provisional receipt data in the billing data storage means. It is a batch deposit processing method for executing a batch deposit processing device having a storage unit and a control unit.
The storage unit
A billing data storage means for storing billing data including billing destination data, billing amount, and expected collection date, and
A billing destination storage means for storing a billing destination master in which a collective deposit flag indicating the billing destination that is the target of application using payment data from a plurality of representatives of the billing destination is set, and a billing destination storage means.
With
It is executed by the control unit.
A deposit data acquisition step for acquiring the deposit data from the representatives of the plurality of billing destinations, and
Using the payment data of the payment billing destination designated as the payment source, the collective payment flag is set in the billing destination master in the order of the oldest scheduled collection date, which is different from the payment billing destination. A billing balance management step for managing the billing balance for each billing destination by performing a clearing process for the billing data of the cleared billing destination, which is the billing destination.
A bulk deposit processing method characterized by including. It is a batch deposit processing program to be executed by a batch deposit processing device having a storage unit and a control unit.
The storage unit
A billing data storage means for storing billing data including billing destination data, billing amount, and expected collection date, and
A billing destination storage means for storing a billing destination master in which a collective deposit flag indicating the billing destination that is the target of application using payment data from a plurality of representatives of the billing destination is set, and a billing destination storage means.
With
In the control unit
A deposit data acquisition step for acquiring the deposit data from the representatives of the plurality of billing destinations, and
Using the payment data of the payment billing destination designated as the payment source, the collective payment flag is set in the billing destination master in the order of the oldest scheduled collection date, which is different from the payment billing destination. A billing balance management step for managing the billing balance for each billing destination by performing a clearing process for the billing data of the cleared billing destination, which is the billing destination.
Bulk deposit processing program to execute.

Images