JP7113122B2 - Lump-sum payment processing device, lump-sum payment processing method, and lump-sum payment processing program - Google Patents

Description

The present invention relates to a lump sum deposit processing apparatus, a lump sum deposit processing method, and a lump sum deposit processing program.

Patent Literature 1 describes a claim reconciliation device (FIG. 13, etc.) capable of collectively reconciling a plurality of claims corresponding to deposits collectively made for a plurality of claims. there is
Specifically, in FIG. 4, which explains the outline of the collective claim reconciliation process of Patent Document 1, as shown in FIG. Compare the total billing amount with the amount received. As a result of the comparison, if the total amount of all billing details of the payer who matches the transfer requester who made the deposit matches the amount of the payment, all billing details of the payer will be subject to reconciliation, Erase. As a result of the comparison, if the total amount of all billing details of the payer that matches the transfer requester who made the payment does not match the amount of the payment, all the total invoices that were the basis of the total invoice (hereinafter referred to as "total invoice amount"), and compare the total invoice amount of the total invoice amount with the received amount. As a result of the comparison, if the total invoice amount and the receipt amount of any of the total invoices match, all the invoice items that were the basis of the matching total invoice are subject to reconciliation, and the reconciliation is performed. conduct. As a result of the comparison, if the deposit amount does not match the total invoice amount of any total invoice, the total amount of all billing items that were the basis of the monthly invoice (hereinafter referred to as (referred to as the monthly billing amount) is obtained, and the monthly billing amount of the monthly billing and the payment amount are compared. As a result of the comparison, if the monthly invoice amount and the deposit amount of any monthly invoice match, all invoice details that were the basis of the matching monthly invoice are subject to reconciliation, Erase. ] (Patent Document 1, paragraphs 0027 to 0029).

JP-A-2006-323532

However, with the conventional technology, it is not possible to manage the balance of billing and receivables for each business partner with multiple billing bases and a lump sum payment to the head office. There was a problem that it was not possible to perform payment processing, and it was not possible to grasp the balance of receivables not only by base but also by all business partners.

The present invention has been made in view of the above-mentioned problems, and in the case of a business partner with a plurality of billing points and lump-sum payment at the head office, management of balance of claims and balance of receivables is managed by each point, and payment processing is performed. , the head office code is used for single payment processing, and the balance of receivables can be grasped not only by base but also by the entire business partner. It aims at providing a processing program.

In order to solve the above-described problems and achieve the object, a lump sum payment processing apparatus according to the present invention is a lump sum payment processing apparatus comprising a storage unit and a control unit, wherein the storage unit is a billing data storage means for storing billing data including billing data and billing amount; and billing balance management means for managing the billing balance for each of the billing destinations by performing reconciliation processing on the billing data based on the billing data.

Further, in the lump sum deposit processing apparatus according to the present invention, in the lump sum deposit processing apparatus, the billing data further includes a closing date, and the remaining billing management means, based on the deposit data, The billing balance is managed for each of the billing destinations by performing reconciliation processing on the billing data in the order of closest to the billing destination.

Further, in the lump sum deposit processing apparatus according to the present invention, in the lump sum deposit processing apparatus, the billing balance management means further converts the deposit data, which has not undergone the reconciliation process, out of the deposit data into provisional receipt data. , is registered in the billing data storage means.

Further, in the lump sum payment processing apparatus according to the present invention, in the lump sum payment processing apparatus, the billing balance management means uses the payment data of the billing destination designated as the payment source to perform the payment request. The billing balance is managed for each billing destination by executing reconciliation processing for the billing data of the reconciliation billing destination, which is the billing destination different from the billing destination.

Further, a lump sum payment processing method according to the present invention is a lump sum payment processing method to be executed by a lump sum payment processing apparatus having a storage unit and a control unit, wherein the storage unit stores billing destination data and a billing data storage means for storing billing data including a billing amount, a billing data obtaining step of obtaining billing data from a plurality of representatives of the billing destinations, executed by the control unit, based on the billing data; and a billing balance management step of managing the billing balance for each of the billing destinations by performing reconciliation processing on the billing data.

Further, a lump sum deposit processing program according to the present invention is a lump sum deposit processing program to be executed by a lump sum deposit processing apparatus having a storage unit and a control unit, wherein the storage unit stores billing destination data and a billing data storage means for storing billing data including a billing amount, a billing data obtaining step of obtaining billing data from a plurality of representatives of the billing destinations in the control unit; and a billing balance management step of managing the billing balance for each of the billing destinations by performing reconciliation processing on the billing data.

According to the present invention, in a business partner where there are a plurality of billing bases and payment is made in a lump sum at the head office, management of the billing balance and the balance of receivables is managed by each base, and the payment processing is performed by a single payment using the head office code. The effect is that it is possible to grasp the balance of receivables not only for each base but also for the entire business partner.

FIG. 1 is a diagram showing an example of a deposit slip issuance. FIG. 2 is a diagram showing an example of a deposit slip issuance. FIG. 3 is a block diagram showing an example of the configuration of the lump sum deposit processing apparatus. FIG. 4 is a flow chart showing an example of the processing of the lump sum deposit processing apparatus in this embodiment. FIG. 5 is a diagram showing an outline of reconciliation to multiple billing destinations. FIG. 6 is a diagram showing an overview of reconciliation to multiple billing destinations. FIG. 7 is a diagram showing an overview of reconciliation to multiple billing destinations. FIG. 8 is a diagram showing an overview of reconciliation to multiple billing destinations. FIG. 9 is a diagram showing an overview of reconciliation to multiple billing destinations. FIG. 10 is a diagram showing an overview of reconciliation to multiple billing destinations. FIG. 11 is a diagram showing the details of acquisition of the payment amount at the time of billing. FIG. 12 is a diagram showing the details of the acquisition of the payment amount at the time of billing. FIG. 13 is a diagram showing front reception in this embodiment. FIG. 14 is a diagram showing an example of a deposit input screen.

An embodiment of the present invention will be described in detail based on the drawings. In addition, this invention is not limited by this embodiment.

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

First, in the past, since it was assumed that the billing processing code equals the payment processing code, it was necessary to check the amount billed at each base of the business partner before performing the payment processing. In the past, deposit slips themselves had to be separated by billing unit, so the number of deposit details and the number of bills actually received and the number of deposit details on the system differed (matching in terms of total). There was a problem.

For example, as shown in Figure 1, in the past, even if there was a lump sum payment (transfer, bill) from the head office, the payment slip was issued separately based on the company's receivables (billing destination). I had to. As a result, conventionally, deposit processing is performed after confirmation of receivables to be written off, resulting in delays in issuing deposit slips and, as a result, delays in confirming balances of deposits. Also, conventionally, even in the case of deposit operation by taking in transfer deposit data of FB, etc., manual operation was necessary because the billing destination was assumed to be the deposit destination. In addition, in the past, there were cases where a bill system was generally introduced to manage bills, etc., but since payment processing had to be done in a manner different from the bills, a bill system was not used. We had no choice but to take separate management.

Therefore, in the present embodiment, it is possible to handle lump sum payment (support for head office lump sum payment for individual invoices for each base), that is, for a business partner with multiple billing bases and a head office lump sum payment, and the balance of receivables can be managed by base, and payment processing can be performed with a single head office code. In addition, in this embodiment, it is possible to grasp the balance of receivables not only for each base but also for all business partners. As a result, in the past, payment processing was performed after confirming the billing amount for each base, but in this embodiment, payment processing and reconciliation processing are completely separated, and payment processing is performed according to the fact of payment. We are able to process payments quickly. In addition, in this embodiment, as a result of the reconciliation processing, it is possible to automatically manage, as a temporary receipt, the head office code for the balance of payment for which the reconciliation target is unknown.

For example, as shown in FIG. 2, in the present embodiment, pattern (1): when the billing destination and payment destination are one and the same base, pattern (2): the billing destination is the main branch of each sales base, and , when the payment destination is the same head office and branch, and pattern (3): when the billing destination is the head office and branch of each sales base and the payment destination is the head office.

[2. Constitution]
An example of the configuration of the lump sum deposit processing apparatus 100 according to this embodiment will be described with reference to FIG. FIG. 3 is a block diagram showing an example of the configuration of the lump sum deposit processing apparatus 100. As shown in FIG.

The lump sum deposit processing device 100 is a commercially available desktop personal computer. Note that the lump sum payment processing apparatus 100 is not limited to a stationary information processing apparatus such as a desktop personal computer. type information processing device.

The lump sum payment processing apparatus 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 lump sum deposit processing apparatus 100 is communicably connected via an arbitrary communication path.

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

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 stores a computer program for performing various processes by giving commands to a CPU (Central Processing Unit) in cooperation with an OS (Operating System). As the storage unit 106, for example, memory devices such as RAM (Random Access Memory) and ROM (Read Only Memory), fixed disk devices such as hard disks, flexible disks, and optical disks can be used. The storage unit 106 has a billing data file 106a.

The billing data file 106a stores billing data including billing destination data and billing amounts. The billing data may also include a closing date.

An input device 112 and an output device 114 are connected to the input/output interface unit 108 . The output device 114 can be a monitor (including a home television), a speaker, or a printer. The input device 112 can be a keyboard, a mouse, a microphone, or a monitor that realizes a pointing device function in cooperation with a mouse. Note that, hereinafter, the output device 114 may be referred to as the monitor 114 and the input device 112 may be referred to as the keyboard 112 or the mouse 112 .

The control unit 102 is a CPU or the like that controls the lump sum deposit processing apparatus 100 in an integrated manner. The control unit 102 has an internal memory for storing a control program such as an OS, a program defining various processing procedures, required data, and the like, and performs various information processing based on these stored programs. Run. The control unit 102 functionally and conceptually includes a payment data acquisition unit 102a and an outstanding billing management unit 102b.

The payment data acquisition unit 102a acquires payment 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 reconciliation processing for the billing data based on the deposit data. Here, the outstanding billing management unit 102b may manage the billing balance for each billing destination by reconciling the billing data in order of closing date based on the billing data. In addition, the outstanding billing management unit 102b may further register (store) the billing data that has not undergone the reconciliation process in the billing data file 106a as provisional receipt data. In addition, the outstanding billing management unit 102b performs reconciliation processing for the billing data of the reconciliation billing destination, which is a billing destination different from the payment billing destination, using the payment data of the payment billing destination designated as the payment source. By doing so, the billing balance for each billing destination may be managed.

[3. Concrete example]
A specific example of this embodiment will be described with reference to FIGS. 4 to 14. FIG.

[Sales transfer processing]
Here, with reference to FIG. 4, an example of lump sum deposit processing in this embodiment will be described. FIG. 4 is a flow chart showing an example of processing of the lump sum payment processing apparatus 100 in this embodiment.

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

Then, based on the payment data acquired by the payment data acquisition unit 102a, the outstanding billing management unit 102b performs reconciliation processing for the claim data stored in the claim data file 106a in order of closing date. The billing balance for each destination is managed, and among the relevant billing data, the billing data that has not undergone the reconciliation process is registered in the billing data file 106a as provisional receipt data (step SA-2), and the process is terminated. Here, the outstanding billing management unit 102b uses the payment data of the payment requesting party, which is the payment requesting party specified as the payment source, to perform the reconciliation process for the payment data of the reconciliation requesting party, which is a different payment party from the payment requesting party. , the billing balance for each billing destination may be managed.

Here, the processing contents of the lump sum payment processing apparatus will be described with reference to FIGS. 5 to 14. FIG.

5, 6, and 7 are diagrams showing an overview of multi-billing reconciliation. When transferring money from customers and transferring cash collected by sales offices to the head office account, multiple billing destinations may be paid together. In this case, implement a function to break it down into amounts for each billing destination. Also consider the splitting of billing destinations for the sorting linkage of the accounting system.

As a result of payment input and EB (electronic banking) payment capture, payment input is made to correspond to data in which a plurality of billing destinations have been paid, so that reconciliation can be performed for each billing destination. Whether or not to make a lump sum payment is set for each billing destination. In other words, for billing destinations with "consolidated payment flag = 1" in the billing destination master maintenance, the billing data displayed for reconciliation will be all billing destinations with "consolidated payment flag = 1" as well. minutes. By default, only the billing recipients specified in the master settings are displayed, but by changing the conditions, all billing recipients with "consolidated payment flag = 1" can be reconciled. do. In addition, in the billing destination master maintenance, the billing destination with the "consolidated payment flag = 0" should be the same as the payment requesting destination and the reconciliation payment destination (receipt requesting destination = reconciliation payment destination) as before. do. That is, reconciliation of payment from a billing destination other than oneself is prohibited, and reconciliation to other billing destinations is also prohibited. When making a lump sum payment, the denomination cannot be printed on the billing statement. Automatic redemption is also not allowed. In addition, if the lump sum payment is not made, printing of the denomination on the billing statement and automatic redemption will be allowed as before.

Concrete processing of clearing will be described with reference to FIGS. In the following explanation, the billing destinations AAA, BBB, and CCC are all on the same closing date (last closing date).

First, invoices S001 to S004 shown in FIG. 5 are issued on the closing date of 201×/12/31.
Next, in EB (Electronic Banking) deposit capture, deposit information including the information shown in FIG. 5 is captured. It should be noted that the collected payment corresponds to the payment collectively received from the billing destination AAA. 5 is created as a payment journal for the received payment information.
Next, in deposit input, reconciliation information is created for the received deposit information. The created reconciliation information is obtained by reconciling to a plurality of billing destinations (billing destinations AAA and BBB). In the reconciliation information, the payment date and the reconciliation date shall be the same day (acquisition date = reconciliation date). From the payment information, it can be seen that the total amount of the payment has been transferred by AAA. Also, the reconciliation journal entries shown in FIG. 5 are created for the reconciliation information. The reconciliation item in the deposit information is displayed as not yet completed, indicating that the reconciliation has not been completed.

Next, invoices S005 and S006 shown in FIG. 6 are issued on the closing date of 201×+1/01/31. The new invoices S005 and S006 are stored in the billing item in the reconciliation information in a state linked to S001 and S002 stored in the reconciliation target billing item.
Next, in deposit input, reconciliation information is created for the received deposit information. Note that the created reconciliation information is reconciled to a billing destination that includes a new billing destination CCC in addition to the billing destinations AAA and BBB. Also, when correcting the reconciliation information, the payment date and the reconciliation date should be different dates (receipt date ≠ reconciliation date). From the payment information, it can be seen that the total amount of the payment has been transferred by AAA. Also, the reconciliation journal entries shown in FIG. 6 are created for the reconciliation information. In FIG. 6, for the bills S001 and S002, the previous reconciliation information is corrected and reconciliation is performed again for the bills S001, S002 and S003. Since the total amount collected from the billing destination AAA has been cleared, the clearing item in the payment information is displayed as completed, indicating that the payment has been completed.

Next, bills S007 to S009 shown in FIG. 7 are issued on the closing date 201×+1/02/28. The new bills S007 to S009 are stored in the items to be billed in the reconciliation information in a state linked to the items S001 to S003 stored in the items of bills to be reconciled.

The deposit operation in the case where a lump sum deposit is made to multiple reconciliation target billing destinations before the current response (the above-described response (FIGS. 5 to 7) according to the present embodiment) is as follows. In the past, it was necessary to have the same billing destination and clearing billing destination (receipt billing destination = clearing billing destination), so if a lump sum payment was made to multiple billing destinations, registration of payment information was required. Previously, it was necessary to divide the payment information itself after investigating how much payment was made to which billing destination. As a result, it is necessary to create and divide deposit slips more than the actual number of occurrences of deposit slips, which complicates operation and occurrence journal entries.

Concrete processing of clearing will be described with reference to FIGS. In the following explanation, the billing destinations AAA, BBB, and CCC are all on the same closing date (last closing date).

First, invoices S001 to S004 shown in FIG. 8 are issued on the closing date of 201×/12/31.
Next, in EB (Electronic Banking) deposit capture, deposit information including the information shown in FIG. 8 is captured. It should be noted that the collected payment corresponds to the payment collectively received from the billing destination AAA. 8 is created as a payment journal for the received payment information.
Next, in deposit input, reconciliation information is created for the received deposit information. The created reconciliation information is obtained by reconciling to a plurality of billing destinations (billing destinations AAA and BBB). In the reconciliation information, the payment date and the reconciliation date shall be the same day (acquisition date = reconciliation date). In addition, it is necessary to divide the payment information and perform reconciliation so that reconciliation can be performed for multiple billing destinations. That is, in the payment information, the billing destination AAA and the billing destination BBB are divided, and the reconciliation of one of them is completed. A split Kuroden is issued for the completed reconciliation, and the other is for correction of the deposit. As shown in FIG. 8, a payment journal entry for the payment information is created. The reconciliation item in the deposit information is indicated as not yet completed in S001. S002 indicates that the process has been completed.

Next, invoices S005 and S006 shown in FIG. 9 are issued on the closing date of 201×+1/01/31. The new invoices S005 and S006 are stored in the billing item in the reconciliation information in a state linked to S001 and S002 stored in the reconciliation target billing item.
Next, in deposit input, reconciliation information is created for the received deposit information. Note that the created reconciliation information is reconciled to a billing destination that includes a new billing destination CCC in addition to the billing destinations AAA and BBB. In addition, when correcting the deposit information and the reconciliation information, the remittance date and reconciliation date shall be different dates (receipt date ≠ reconciliation date). AAA and CCC are newly added to the billing destination of the deposit information. AAA is the divided portion of Akaden, and CCC is the divided portion of Black Den. In addition, the payment journal entry shown in FIG. 9 is created for the payment information. In FIG. 9, reconciliation information is performed for bills S001 and S003. Since the total amount collected from the billing destination AAA has been cleared, the clearing item in the payment information is displayed as completed, indicating that the payment has been completed.

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

11 and 12 are diagrams showing the details of the acquisition of the payment amount at the time of billing. Along with support for specifying a billing destination different from the billing destination of the payment source when performing payment reconciliation, the acquisition source of the acquisition of payment results at the time of billing closing processing can be changed to Change to get from history.
Next, the terms are defined below. The payment billing destination is a billing destination designated as a payment source (receipt header. billing destination (billing destination stored in the payment header)). The reconciliation billing party is a billing party designated as a reconciliation target (collection schedule for reconciliation.billing party (billing party stored in collection schedule data)). The invoice receipt month is specified in the receipt header. This is the month in which the payment date (the payment date stored in the payment header) is used as the base date. Billing application month is entered in the payment application header. This is the month that becomes the invoice closing date 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 a billing party closes on the 20th, the payment date is 201x+1/06/25, and the payment application date is 201x+1/07/31, the invoice payment month is 201x+1/06, the payment application month is is 201×+1/07.
The method of acquiring the payment record at the time of provisional closing of billing will be changed as follows. When creating billing data (accounting results) for a billing party (a billing party is different from a billing party (billing party ≠ billing party)), the amount received by the billing party for the current month is the deposit reconciliation details history. It is a sum of the amount of money applied to the payment (the amount of money applied to the money stored in the history data of the details of payment application) (from the history of details of payment (billing NO)).
Next, when creating billing data (payment results) related to the billing destination (the billing destination is the same as the billing destination (the billing destination = the billing destination)), the amount of money received by the billing destination for the current month and the payment amount (unapplied amount) of the current month's payment request destination, minus the applied amount (subtraction) corresponding to the applied resource. The payment amount of the payment request destination for the current month is shown in the payment reconciliation details history. It is a total of the amount of money applied to the payment (the amount of money applied to the money stored in the history data of the details of payment application) (from the history of details of payment (update billing No.)). The payment amount (unapplied amount) of the payment request destination for the current month is displayed in the payment header. It is the amount of original funds for payment application (the amount of original funds for payment application stored in the payment header) (from payment H (header) (update claim NO)). The applied amount (subtracted amount) corresponding to the applied funds is shown in the deposit payment history. It is a total of the amount of funds to be applied this time (the amount of funds to be applied this time stored in the deposit reconciliation history data) (from the history of reconciliation (renewal of billing NO)).

FIG. 13 is a diagram showing front reception in this embodiment. If lump sum payment is not made, the payment amount including the payment amount corresponding to the advance receipt is obtained as the payment amount on the payment date (managed with the carryover balance minus). Also, at the time of offsetting sales and advance payments, only the details of sales are acquired and consistency is maintained as a whole. In the case of lump sum payment, the unapplied balance at the time of billing is acquired as the record of the billing destination at the time of payment (amount of resources to be applied - amount of resources to be applied in the breakdown (amount of resources to be applied this time)). It does not capture clearing against prepaid bills. Even if the denomination is set-off of advance receipts, the applied amount is acquired as the received 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 reconciliation. Data is extracted and displayed based on information entered as reconciliation information.

Here, the background and outline of this embodiment will be briefly described again.
Receivables are basically managed on a billing-to basis, but in the case of large companies, there are cases where multiple billing-to management is required for a single corporation (eg, cases where billing is required for each division). Furthermore, when there are multiple billing destinations for one corporation, there are cases where payment is received from the billing destination, and there are cases where payment is received from the corporate representative (head office).
Therefore, in this embodiment, a mechanism is realized that can correctly manage the management of the deposit source and the unit of claim reconciliation in accordance with these practices. Specifically, in this embodiment, the payee and billing destination are managed separately. In addition, in this embodiment, when narrowing down the reconciliation targets, the remittance billing destination is used to narrow down the reconciliation targets. In addition, in this embodiment, when the payment reconciliation unit is "automatic", reconciliation is performed from the oldest receivable balance scheduled for collection.
According to this embodiment, even if there is a lump sum payment, it can be accounted for at the time of payment, and can be reconciled to the balance of receivables for each billing party. Moreover, according to this embodiment, it can be used not only in the relationship of head offices and branches, but also in the relationship of group companies. In addition, according to this embodiment, there are two patterns of deposit data, manual input and EB capture, but EB capture can be managed in the same way. In addition, according to this embodiment, both the deposit source and the billing destination can manage claims within the system. Further, according to this embodiment, it is possible to automatically generate accounting journal entries. Moreover, according to the present embodiment, when a reconciliation error occurs, it becomes possible to correct it correctly including the accounting from the next month onwards. Further, according to the present embodiment, it is possible to present payment information at the time of billing by speeding up the payment processing. In addition, according to this embodiment, corporate management, temporary receipt management in payment reconciliation, reconciliation pattern management, credit management unit (billing destination/receipt destination) management, lump sum payment, and journal linkage are possible.
Note that the differences between this embodiment and Patent Document 1 (Japanese Patent Application Laid-Open No. 2006-323532) are as follows.
- In this embodiment, the total numbering process is unnecessary.
- In this embodiment, the "total summary unit" (closing date, payer, currency, total invoice numbering unit item) is not required.
- In the present embodiment, it is not necessary that the invoices are sent to the same company.
- In this embodiment, it is not necessary for the amount of money received and the amount of money billed to match.
- In this embodiment, deposit journal entries and deposit reconciliation journal entries for multiple remittance destinations can be linked to the accounting system.

[4. Other embodiments]
The present invention may be implemented in various different embodiments other than the embodiments described above 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 automatically performed can be manually performed, or all of the processes described as being manually performed Alternatively, some can be done automatically by known methods.

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

Also, with respect to the lump sum payment processing apparatus 100, each illustrated component is functionally conceptual, and does not necessarily need to be physically configured as illustrated.

For example, the processing functions of the lump sum payment processing apparatus 100, particularly the processing functions performed by the control unit 102, are realized in whole or in part by a CPU and a program interpreted and executed by the CPU. Alternatively, it may be implemented as hardware using wired logic. In addition, the program is recorded on a non-temporary computer-readable recording medium containing programmed instructions for causing the information processing apparatus to execute the processing described in the present embodiment. It is read mechanically by the device 100 . That is, a storage unit such as a ROM or HDD (Hard Disk Drive) stores a computer program for giving commands to the CPU in cooperation with the OS to perform various processes. This computer program is executed by being loaded into the RAM and constitutes a control section in cooperation with the CPU.

In addition, this computer program may be stored in an application program server connected to the lump sum deposit processing apparatus 100 via any network, and it is possible to download all or part of it as necessary. is.

Also, the 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 term "recording medium" means memory card, USB (Universal Serial Bus) memory, SD (Secure Digital) card, flexible disk, magneto-optical disk, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (registered Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROM (Compact Disk Read Only Memory), MO (Magneto-Optical disk), DVD (Digital Versatile Disk), and Disc (Registered trademark) such as Blu- shall include any "portable physical medium".

A "program" is a data processing method written in any language or writing method, regardless of the format such as source code or binary code. In addition, the "program" is not necessarily limited to a single configuration, but is distributed as multiple modules or libraries, or cooperates with a separate program represented by the OS to achieve its function. including things. It should be noted 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, the installation procedure after reading, and the like.

The 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. programs, tables, databases, and files for web pages.

The lump sum payment processing apparatus 100 may be configured as an information processing apparatus such as a known personal computer or workstation, or may be configured as the information processing apparatus to which any peripheral device is connected. Also, the lump sum deposit processing device 100 may be realized by installing software (including programs, data, etc.) for realizing the processing described in the present embodiment.

Furthermore, the specific forms of distribution and integration of devices are not limited to those shown in the figures, and all or part of them can be functionally or physically arranged in arbitrary units according to various additions or functional loads. It can be distributed and integrated. In other words, the embodiments described above may be arbitrarily combined and implemented, or the embodiments may be selectively implemented.

The present invention is particularly useful for companies that do business with customers all over the country.

REFERENCE SIGNS LIST 100 lump sum deposit processing device 102 control unit 102a deposit data acquisition unit 102b balance billing 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)

A lump sum deposit processing device comprising a storage unit and a control unit,
The storage unit
billing data storage means for storing billing data including billing destination data, billing amount, and scheduled collection date;
billing destination storage means for storing a billing destination master set with a consolidated payment flag indicating the billing destinations to be reconciled using payment data from representatives of the plurality of billing destinations;
with
The control unit
payment data acquisition means for acquiring the payment data from representatives of the plurality of billing destinations;
Using the payment data of the payment requesting destination that is the payment destination specified as the payment source, the collective payment flag is set in the billing destination master in order from the oldest scheduled collection date. outstanding billing management means for managing the billing balance for each billing destination by performing reconciliation processing on the billing data of the reconciliation billing destination, which is the billing destination;
A lump sum deposit processing device comprising: The billing balance management means
2. The lump-sum payment processing apparatus according to claim 1, further comprising registering, among the payment data, the payment data for which the reconciliation processing has not been performed as provisional receipt data in the billing data storage means. A lump sum deposit processing method to be executed by a lump sum deposit processing apparatus having a storage unit and a control unit,
The storage unit
billing data storage means for storing billing data including billing destination data, billing amount, and scheduled collection date;
billing destination storage means for storing a billing destination master set with a consolidated payment flag indicating the billing destinations to be reconciled using payment data from representatives of the plurality of billing destinations;
with
to be executed by the control unit;
a payment data obtaining step of obtaining the payment data from the representatives of the plurality of billing destinations;
Using the payment data of the payment requesting destination that is the payment destination specified as the payment source, the collective payment flag is set in the billing destination master in order from the oldest scheduled collection date. a billing balance management step of managing the billing balance for each billing destination by performing reconciliation processing for the billing data of the reconciliation billing destination that is the billing destination;
A lump sum payment processing method, comprising: A lump sum deposit processing program to be executed by a lump sum deposit processing apparatus comprising a storage unit and a control unit,
The storage unit
billing data storage means for storing billing data including billing destination data, billing amount, and scheduled collection date;
billing destination storage means for storing a billing destination master set with a consolidated payment flag indicating the billing destinations to be reconciled using payment data from representatives of the plurality of billing destinations;
with
In the control unit,
a payment data obtaining step of obtaining the payment data from the representatives of the plurality of billing destinations;
Using the payment data of the payment requesting destination that is the payment destination specified as the payment source, the collective payment flag is set in the billing destination master in order from the oldest scheduled collection date. a billing balance management step of managing the billing balance for each billing destination by performing reconciliation processing for the billing data of the reconciliation billing destination that is the billing destination;
Lump-sum payment processing program for executing

Images