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

Abstract

PROBLEM TO BE SOLVED: 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 apparatus, a batch deposit processing method, and a batch deposit processing program.

Patent Document 1 describes a receivable application device (such as FIG. 13) that can perform the application of a plurality of receivables corresponding to deposits made in a lump for a plurality of receivables. Yes.
Specifically, in FIG. 4 for explaining the outline of the collective bond cancellation process of Patent Document 1, as shown in FIG. 4 (a), “all the payers matching the transfer requester who made the deposit”. Compare the total amount of the billing details with the receipt amount. If, as a result of the comparison, the total amount of all the billing details of the payer that matches the transfer requester who made the payment matches the deposit amount, all the billing details of the payer are subject to application, Do the erase. If, as a result of the comparison, the total amount of all invoice details of the payer that matches the transfer requester who made the payment does not match the receipt amount, all the invoices from which the total invoice originated The total invoice amount (hereinafter referred to as the total invoice amount) is obtained, and the total invoice amount of the total invoice is compared with the receipt amount. As a result of comparison, if the total invoice amount and the receipt amount of any of the total invoices match, all the billing details that are the source of the matching total invoices will be subject to the cancellation, and Do. 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 the invoice items that are the basis of the monthly invoice (hereinafter, The monthly invoice amount is calculated, and the monthly invoice amount of the monthly invoice is compared with the receipt amount. As a result of comparison, if the monthly invoice amount and the deposit amount of any monthly invoice match, all the billing statements that are the source of the matching monthly invoice will be subject to retirement, Do the erase. (Patent Document 1, paragraphs 0027 to 0029).

JP 2006-323532 A

  However, in the conventional technology, there are multiple billing bases, and it is not possible to manage the balance of bills and balances at each business partner, such as collective payment at the head office. There was a problem that payment processing could not be performed, and the balance of receivables could not be grasped not only by base but also by the whole business partner.

  The present invention has been made in view of the above-mentioned problems, and there are a plurality of billing sending bases, and the balance of bills and the balance of receivables are managed for each base in a business partner such as a collective payment at the headquarters, and payment processing is performed. For a single deposit process at the head office code, and for the balance of receivables, the collective deposit processing device, collective deposit processing method, and collective deposit that can be grasped not only by location but also by the entire business partner An object is to provide a processing program.

  In order to solve the above-described problems and achieve the object, a batch deposit processing apparatus according to the present invention is a batch deposit processing apparatus including a storage unit and a control unit, and the storage unit is a billing request. Billing data storage means for storing billing data including billing data and billing data, and the control unit receives depositing data from a plurality of billing representatives, and depositing data acquisition means On the basis of this, it is provided with a remaining charge management means for managing a billing balance for each billing destination by performing a clearing process on the billing data.

  In the batch deposit processing apparatus according to the present invention, in the batch deposit processing apparatus, the billing data further includes a closing date, and the remaining bill management means is configured to determine the closing date based on the deposit data. The billing balance for each billing destination is managed by performing a clearing process on the billing data in the order of close.

  In the collective deposit processing apparatus according to the present invention, in the collective deposit processing apparatus, the remaining bill management means further includes, among the deposit data, the receipt data that has not been subjected to the application process is provisional receipt data. As registered in the billing data storage means.

  Further, the collective deposit processing apparatus according to the present invention is the collective deposit processing apparatus, wherein the remaining bill management means uses the deposit data of the deposit billing destination which is the billing destination designated as the deposit source. The billing balance for each billing destination is managed by performing a billing process on the billing data of the billing billing destination which is the billing destination different from the billing destination.

  In addition, a collective deposit processing method according to the present invention is a collective deposit processing method for causing a collective deposit processing apparatus provided with a storage unit and a control unit to execute the collective deposit processing method, wherein the storage unit includes billing destination billing data. A billing data storage unit for storing billing data including a billing amount, and a depositing data acquisition step for acquiring depositing data from a plurality of representatives of the billing destinations, which is executed by the control unit, and based on the depositing data And a remaining charge management step of managing a bill balance for each billing destination by performing a clearing process on the billing data.

  A batch payment processing program according to the present invention is a batch payment processing program for causing a batch payment processing apparatus including a storage unit and a control unit to execute the batch payment processing program, wherein the storage unit includes billing destination data of a billing destination. A billing data storage means for storing billing data including a billing amount, and in the control unit, based on the depositing data acquisition step of acquiring depositing data from a plurality of representatives of the billing destination, The present invention is characterized in that a charge remaining management step for managing a bill balance for each billing destination is performed by performing a consumption process on the bill data.

  According to the present invention, there are a plurality of billing bases, and the balance of bills and receivables are managed by each base at a business partner such as the head office collective deposit, and the deposit process is a single deposit with the head office code. This process has the effect that the balance of receivables can be grasped not only by base but also by the entire business partner.

FIG. 1 is a diagram showing an example of a deposit slip draft. FIG. 2 is a diagram showing an example of a deposit slip draft. FIG. 3 is a block diagram showing an example of the configuration of the batch deposit processing apparatus. FIG. 4 is a flowchart showing an example of processing of the batch deposit processing apparatus in the present embodiment. FIG. 5 is a diagram showing an outline of the multiple billing destination application. FIG. 6 is a diagram showing an outline of the multiple billing destination application. FIG. 7 is a diagram showing an outline of the multiple billing destination application. FIG. 8 is a diagram showing an outline of the multiple billing destination application. FIG. 9 is a diagram showing an outline of the multiple billing destination application. FIG. 10 is a diagram showing an outline of the multiple billing destination application. 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 the reception in the present embodiment. FIG. 14 is a diagram illustrating an example of a deposit input screen.

  Embodiments of the present invention will be described in detail with reference to the drawings. In addition, this invention is not limited by this embodiment.

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

  First, conventionally, since it was assumed that the billing process code = payment process code, it was necessary to perform the deposit process after confirming the billing amount at each base of the business partner. Conventionally, since the deposit slip itself has to be divided by billing unit, the deposit deposit details and the actual bills received and the number of deposit details on the system are different (matched in total). There was a problem.

  For example, as shown in Fig. 1, in the past, even if there were payments (transfer, bills) from the head office in a lump sum, the receipt slips were divided and created on the basis of the receivables (billers) owned by the company. There was a need to do. As a result, conventionally, since the deposit processing is performed after confirming the application receivable, the drafting of the deposit slip is delayed and the balance confirmation of the result deposit is delayed. Conventionally, even when deposit operation is performed by taking in transfer deposit data such as FB, manual operation is necessary because the billing destination is a premise of deposit. Conventionally, bill systems have been generally introduced for bills and bills are managed, but the bill system must be processed differently from the bills. We had to take separate management.

  Therefore, in the present embodiment, collective payment support (support for collective billing at the head office for individual bills at each site), that is, a billing balance at a business partner such as a plurality of bill sending sites and a collective deposit at the head office. In addition, it is possible to manage the balance of receivables at each site, and with regard to deposit processing, it is possible to perform single deposit processing with the head office code. Further, in the present embodiment, the balance of receivables can be grasped not only for each base but also for the entire business partner. As a result, in the present embodiment, the deposit processing and the application processing are completely separated in the present embodiment, so that the deposit processing is performed after confirming the billing amount for each base in the past. Payment processing is realized early. Further, in the present embodiment, as a result of the application process, the remaining deposit whose application object is unknown can be automatically managed as a provisional payment by the head office code.

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

[2. Constitution]
An example of the configuration of the batch deposit processing apparatus 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 collective deposit processing apparatus 100.

  The batch deposit processing apparatus 100 is a commercially available desktop personal computer. The collective deposit processing apparatus 100 is not limited to a stationary information processing apparatus such as a desktop personal computer, but is a portable personal computer such as a commercially available notebook personal computer, PDA (Personal Digital Assistant), smartphone, or tablet personal computer. It may be a type information processing apparatus.

  The collective deposit processing apparatus 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each unit provided in the collective deposit processing apparatus 100 is communicably connected via an arbitrary communication path.

  The communication interface unit 104 communicatively connects the collective 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 other devices via a communication line. Here, the network 300 has a function of connecting the batch deposit processing apparatus 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).

  The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 stores a computer program for giving various instructions to a CPU (Central Processing Unit) in cooperation with an OS (Operating System). As the storage unit 106, for example, a memory device such as a RAM (Random Access Memory) and a ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, and an optical disk 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 (including a home television), a speaker, and a printer can be used. As the input device 112, in addition to a keyboard, a mouse, and a microphone, a monitor that realizes a pointing device function in cooperation with the mouse can be used. In the following description, the output device 114 may be described as the monitor 114, and the input device 112 may be described as the keyboard 112 or the mouse 112.

  The control unit 102 is a CPU or the like that controls the batch 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 that defines various processing procedures, and necessary data, and performs various information processing based on these stored programs. Run. The control unit 102 includes a deposit data acquisition unit 102a and a remaining charge management unit 102b in terms of functional concept.

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

  The remaining bill management unit 102b manages the bill balance for each billing destination by performing an application process on the billing data based on the deposit data. Here, the remaining bill management unit 102b may manage the billing balance for each billing destination by performing a clearing process on the billing data in order of close closing date based on the deposit data. Further, the remaining charge management unit 102b may register (store) the receipt data that has not been applied in the receipt data as provisional receipt data in the claim data file 106a. In addition, the remaining charge management unit 102b uses the payment data of the payment requester, which is the chargeee specified as the payment source, to perform an application process for the charge data of the application requester that is different from the payment requester. 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.

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

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

  Then, the remaining charge management unit 102b performs the application process on the billing data stored in the billing data file 106a in order from the close date based on the deposit data acquired by the deposit data acquisition unit 102a, thereby The billing balance for each destination is managed, and among the deposit data, the deposit data that has not been subjected to the application process is registered in the billing data file 106a as provisional deposit data (step SA-2), and the processing is terminated. Here, the remaining charge management unit 102b uses the payment data of the payment requester, which is the chargeee specified as the payment source, to apply for the billing data of the application requester that is different from the payment requester. The billing balance for each billing destination may be managed by performing.

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

  5, 6 and 7 are diagrams showing an outline of the multiple billing destination application. When depositing money from a customer and transferring money to the head office account for the cash collected by the sales office, payments may be made for multiple billing parties. In this case, a function for disassembling the amount for each billing destination is implemented. Considering the splitting of billing destinations as well for the accounting system sorting linkage.

  As a result of deposit input and EB (Electronic Banking) deposit taking, the deposit input is made to correspond to the data in which a plurality of billing destinations are deposited so that it can be cleared for each billing destination. Whether or not to make a batch payment is set for each billing party. In other words, for the billing billing party for which “collective deposit flag = 1” is set in the billing destination master maintenance, the billing data to be displayed in the application target is all billing destinations having “collective deposit flag = 1” in the same manner. Minutes. By default, only the billing destination specified in the master billing is displayed, but by changing the conditions, it is possible to apply to all billing destinations that have “collective receipt flag = 1” To do. In addition, in the billing destination master maintenance, the billing destination whose “collection receipt flag = 0” is the same as the conventional method in which the receipt request destination and the application payee are the same (payment invoice destination = application payee). To do. In other words, it is impossible to cancel the payment from a billing party other than yourself, and it is also impossible to apply to another billing party. When making a batch payment, the denomination cannot be printed on the billing statement. In addition, automatic consumption is not allowed. In addition, when the deposit is not performed, the denomination can be printed on the billing statement and automatically cleared as before.

  A specific process of application will be described with reference to FIGS. In the following description, all of the billing destinations AAA, BBB, and CCC have the same closing date (the closing date).

First, invoices S001 to S004 shown in FIG. 5 are issued on the closing date 201 × / 12/31.
Next, in EB (Electronic Banking) depositing capture, the deposit information including the information shown in FIG. 5 is captured. In addition, the taken-in deposit corresponds to the deposit received collectively from the billing destination AAA. Further, as shown in FIG. 5, a deposit journal for the received deposit information is created.
Next, in the payment input, application information is created for the received payment information. Note that the created consumption information is information obtained by applying to a plurality of billing parties (billing parties AAA, BBB). In the application information, the payment date and the application date are the same day (payment date = application date). It can be seen from the deposit information that the entire deposit amount has been transferred by AAA. Moreover, what is shown in FIG. 5 is created as a consumption journal for the consumption information. The item of application in the deposit information is displayed as not yet, indicating that it has not been completed.

Next, bills S005 and S006 shown in FIG. 6 are issued on the closing date 201 × + 1/01/31. The new bills S005 and S006 are stored in the billing item in the consumption information in a state linked to S001 and S002 stored in the billing item.
Next, in the payment input, application information is created for the received payment information. The created application information is information that is applied to the billing destination that newly includes the billing destination CCC in addition to the billing destinations AAA and BBB. In addition, when correcting the application information, the payment date and the application date are different (payment date ≠ application date). It can be seen from the deposit information that the entire deposit amount has been transferred by AAA. Moreover, what is shown in FIG. 6 is created as a consumption journal for the consumption information. In FIG. 6, for the bills S001 and S002, the previous erase information is corrected and the bills S001, S002 and S003 are erased again. Since the entire amount collectively received from the billing destination AAA has been deleted, the item of application in the payment information is displayed as complete, indicating that it 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 billing target item in a state linked to S001 to S003 stored in the billing target billing item in the billing information.

  The deposit operation in the case where collective deposits are made for a plurality of application target billing parties in the state before performing the present correspondence (the above-described correspondence according to the present embodiment (FIGS. 5 to 7)) is as follows. Conventionally, the payment request destination and the application request for payment must be the same (payment request destination = application request destination). Therefore, if multiple payments are made for multiple billing parties, the payment information is registered. Before, it was necessary to divide the payment information itself after investigating to which billing party the payment was made to make the payment. As a result, it is necessary to create and divide payment slips that are more than the actual number of payment slips generated, making operation and journal entries complicated.

  A specific process of application will be described with reference to FIGS. In the following description, all of the billing destinations AAA, BBB, and CCC have the same closing date (the closing date).

First, invoices S001 to S004 shown in FIG. 8 are issued on the closing date 201 × / 12/31.
Next, in EB (Electronic Banking) depositing capture, the deposit information including the information shown in FIG. 8 is captured. In addition, the taken-in deposit corresponds to the deposit received collectively from the billing destination AAA. In addition, as shown in FIG. 8, a deposit journal for the received deposit information is created.
Next, in the payment input, application information is created for the received payment information. Note that the created consumption information is information obtained by applying to a plurality of billing parties (billing parties AAA, BBB). In the application information, the payment date and the application date are the same day (payment date = application date). Furthermore, it is necessary to divide the payment information and perform the application so that it can be applied to the bills of a plurality of billing parties. That is, in the payment information, the billing destination AAA and the billing destination BBB are divided, and one application is completed. The completed blackout will be issued with a black portion of the division, and the other will be the payment correction. As shown in FIG. 8, a deposit journal for the deposit information is created. The item of application in the deposit information is not displayed in S001 and is not completed. In S002, it is shown that it is complete and completed.

Next, bills S005 and S006 shown in FIG. 9 are issued on the closing date 201 × + 1/01/31. The new bills S005 and S006 are stored in the billing item in the consumption information in a state linked to S001 and S002 stored in the billing item.
Next, in the payment input, application information is created for the received payment information. The created application information is information that is applied to the billing destination that newly includes the billing destination CCC in addition to the billing destinations AAA and BBB. In addition, when the payment information and the application information are corrected, the payment date and the application date are different (payment date ≠ application date). AAA and CCC are newly added to billing information billing destinations. AAA is the red transmission for the division, and CCC is the black transmission for the division. Further, the deposit journal shown in FIG. 9 is created as the deposit journal for the deposit information. In FIG. 9, consumption information is performed for the bills S001 and S003. Since the entire amount collectively received from the billing destination AAA has been deleted, the item of application in the payment information is displayed as complete, indicating that it has been completed.

  Next, invoices 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 billing target item in a state linked to the “adjustment amount” stored in the billing target billing item and S003 in the billing information.

FIG. 11 and FIG. 12 are diagrams showing the details of obtaining the deposit amount when charging. Accompanying the correspondence that the billing party different from the billing party's billing destination can be specified as the application destination when performing the payment application, the acquisition source of the acquisition result of the payment at the time of the billing closing process is designated as the payment application details. Change to get from history.
Next, the following words are defined. The payment request destination is a request destination (payment header. Billing destination (the billing destination stored in the payment header)) designated as the payment source. The consumption request destination is a request destination (recovery schedule to be cleared. Billing destination (billing address stored in collection schedule data)) designated as a consumption target. The invoice receipt month is the receipt header. This is the month that falls within the billing deadline with the payment date (the payment date stored in the payment header) as the reference date. The billing application month is the receipt application header. This is the month that falls within the billing scope based on the receipt application date (the receipt application date (obtained from the receipt application history) stored in the receipt header). For example, if the billing date is 20 × + 1/06/25 and the payment application date is 201 × + 1/07/31, the billing payment month is 201 × + 1/06, the billing application month. Is 201 × + 1/07.
The method for obtaining the payment record at the time of temporary claim tightening is changed as follows. When creating billing data (payment actual) for the billing party of the clearing billing party (the clearing billing party is different from the billing billing party (clearing billing party ≠ depositing billing party)) Is the receipt application history. This is an aggregation of the payment application amount (the payment application amount stored in the payment application detail history data) (from the application details history (billing NO)).
Next, at the time of creating billing data (payment actual) for the billing party of the same billing party (clearing billing party is the same as the billing party (clearing billing party = depositing billing party)), the deposit amount of the current billing party And the deposit amount (unapplied amount) of the receipt requester for the current month, minus the applied amount (subtracted amount) corresponding to the source of consumption. The deposit amount for the current month's deposit request is the receipt application history. This is the total of the payment application amount (the payment application amount stored in the payment application details history data) (from the application details history (billing NO update)). The deposit amount (unapplied amount) of the receipt requester for the current month is the receipt header. This is the amount of funds used for deposit application (the amount of funds used for deposit application stored in the deposit header) (from deposit H (header) (invoicing NO update)). The applied amount (subtracted amount) corresponding to the applied resource is the payment application breakdown history. This is the total of the amount of capital consumed this time (the amount of capital applied this time stored in the payment application breakdown history data) (from the consumption breakdown history (billing NO update)).

  FIG. 13 is a diagram showing the reception in the present embodiment. If the deposit is not made in a lump sum, it is acquired as the deposit amount on the deposit date (including the carry-over balance minus), including the deposit corresponding to the receipt. In addition, only the sales details are acquired and the consistency is maintained as a whole at the time of sales offsetting. When making a batch payment, the unapplied balance at the time of billing is acquired as the result of the billing party at the time of billing (the amount of capital consumed for consumption-the amount of capital consumed for breakdown (current amount of funds for consumption this time)). You do not get a reconciliation for down payment. Even if the denomination is an advance offset, the application amount is acquired as the deposit amount.

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

Here, the background and outline of this embodiment will be briefly described again.
Accounts receivable management is basically a billing destination unit, but there are cases where a large corporation needs to manage multiple billing destinations (eg, a case where billing is required for each business division). Furthermore, when there are a plurality of billing destinations for one corporation, there are cases where there is payment from the billing destination and cases where there is payment from the corporate representative (head office).
Therefore, in the present embodiment, a mechanism that can correctly manage the management of the deposit source and the unit of receivable application is realized in accordance with these practices. Specifically, in this embodiment, the deposit destination and the billing destination are managed separately. Moreover, in this embodiment, when narrowing down the object of application, it narrows down by a payment request destination. Further, in this embodiment, when the deposit application unit is “automatic”, the application is performed from the balance of the old collection schedule.
And according to this embodiment, even if there is a collective deposit, it can be recorded at the timing of deposit, and it is possible to apply to the balance of claims in the billing unit. Further, according to the present embodiment, it can be used not only in the relationship of the main branch but also in the relationship of a group company. Further, according to the present embodiment, there are two patterns of deposit data, manual input and EB capture, but the same management is possible even with EB capture. In addition, according to the present embodiment, the receivable management in the system can be performed at either the deposit source or the billing destination. Further, according to the present embodiment, accounting journals can be automatically generated. Further, according to the present embodiment, when an application error occurs, it is possible to correct correctly including accounting in the following month. In addition, according to the present embodiment, it becomes possible to present the deposit information at the time of billing because the deposit process is accelerated. In addition, according to the present embodiment, it is possible to perform corporate management, provisional payment management in payment application, application pattern management, receivable management unit (billing destination / payment destination) management, collective payment, and journal entry cooperation.
The difference between the present embodiment and Patent Document 1 (Japanese Patent Laid-Open No. 2006-323532) is as follows.
-In this embodiment, a total numbering process is unnecessary.
In the present embodiment, the “total summary unit” (closing date, payer, currency, total billing number unit item) is not required.
In the present embodiment, it is not necessary that the bill is sent to the same company.
In the present embodiment, the deposit amount and the billing amount do not need to match.
In this embodiment, it is possible to link payment journals and payment application journals for a plurality of application destinations 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 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 performed manually, or all of the processes described as being performed manually are all performed. Alternatively, a part can be automatically performed by a known method.

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

  Moreover, regarding the collective deposit 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 provided in the batch deposit processing apparatus 100, in particular, each processing function performed by the control unit 102, is realized entirely or arbitrarily by a CPU and a program interpreted and executed by the CPU. It may also be realized as hardware by wired logic. The program is recorded on a non-transitory computer-readable recording medium including programmed instructions for causing the information processing apparatus to execute the processing described in this embodiment, and collective deposit processing is performed as necessary. It is mechanically read by the device 100. In other words, in a storage unit such as a ROM or a HDD (Hard Disk Drive), a computer program for giving instructions to the CPU in cooperation with the OS and performing various processes is recorded. This computer program is executed by being loaded into the RAM, and constitutes a control unit in cooperation with the CPU.

  The computer program may be stored in an application program server connected to the collective deposit processing apparatus 100 via an arbitrary network, and may be downloaded in whole or in part as necessary. It is.

  In addition, 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” refers to a memory card, USB (Universal Serial Bus) memory, SD (Secure Digital) card, flexible disk, magneto-optical disk, ROM, EPROM (Erasable Programmable Read Only Memory), EEPROM (registration). Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROM (Compact Disk Read Only Memory), MO (Magneto-Optical disk), DVD (Digital Digital, Trademark) Any “portable physical media It is intended to include.

  The “program” is a data processing method described in an arbitrary language or description method, and may be in any form such as source code or binary code. Note that the “program” is not necessarily limited to a single configuration, and functions are achieved in cooperation with a separate configuration such as a plurality of modules and libraries or a separate program represented by the OS. Including things. In addition, a well-known structure and procedure can be used about the specific structure and reading procedure for reading a recording medium in each apparatus shown to embodiment, the installation procedure after reading, etc.

  Various databases and the like stored in the storage unit 106 are storage means such as a memory device such as a RAM and a ROM, a fixed disk device such as a hard disk, a flexible disk, and an optical disk. Programs, tables, databases, web page files, and the like.

  The collective deposit 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 connected to an arbitrary peripheral device. The collective deposit processing apparatus 100 may be realized by installing software (including a program or data) for realizing the processing described in the present embodiment in the apparatus.

  Furthermore, the specific form of distribution / integration of the devices is not limited to that shown in the figure, and all or a part of them may be functionally or physically in arbitrary units according to various additions or according to functional loads. It can be configured to be distributed and integrated. That is, the above-described embodiments may be arbitrarily combined and may be selectively implemented.

  The present invention is particularly useful in companies that deal with customers nationwide.

DESCRIPTION OF SYMBOLS 100 Collective deposit processing apparatus 102 Control part 102a Deposit data acquisition part 102b Remaining bill management part 104 Communication interface part 106 Storage part 106a Claim data file 108 Input / output interface part 112 Input device 114 Output device 200 Server 300 Network

Claims (6)

A batch deposit processing apparatus including a storage unit and a control unit,
The storage unit
Billing data storage means for storing billing data including billing destination data and billing amount;
With
The controller is
Deposit data acquisition means for acquiring deposit data from a plurality of representatives of the billing destinations;
Remaining bill management means for managing a bill balance for each billing destination by performing an application process on the billing data based on the deposit data;
A batch deposit processing apparatus characterized by comprising: The billing data is
In addition, it includes a closing date,
The remaining bill management means is:
The collective deposit according to claim 1, wherein the bill balance for each billing destination is managed by performing a clearing process on the billing data in order of closeness of the closing date based on the deposit data. Processing equipment. The remaining bill management means is:
The batch payment processing apparatus according to claim 1, further comprising: registering, in the billing data storage unit, the deposit data that has not been subjected to the application process among the deposit data as provisional deposit data. . The remaining bill management means is:
By using the payment data of the payment request destination, which is the charge destination designated as the payment source, by performing an application process on the charge data of the application request destination, which is different from the payment request destination, The collective deposit processing apparatus according to any one of claims 1 to 3, wherein a bill balance for each billing destination is managed. A collective deposit processing method for causing a collective deposit processing apparatus including a storage unit and a control unit to execute,
The storage unit
Billing data storage means for storing billing data including billing destination data and billing amount;
With
To be executed by the control unit;
A deposit data acquisition step of acquiring deposit data from a plurality of representatives of the billing destinations;
A remaining charge management step for managing a bill balance for each billing destination by performing an application process on the billing data based on the deposit data;
The collective deposit processing method characterized by including. A batch deposit processing program for causing a batch deposit processing apparatus including a storage unit and a control unit to execute,
The storage unit
Billing data storage means for storing billing data including billing destination data and billing amount;
With
In the control unit,
A deposit data acquisition step of acquiring deposit data from a plurality of representatives of the billing destinations;
A remaining charge management step for managing a bill balance for each billing destination by performing an application process on the billing data based on the deposit data;
Collective deposit processing program to execute.