JP2005352911A - System, method, and program for credit management - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To narrow down credit management data while taking a payment day and a payment period into consideration. <P>SOLUTION: A payment day specifying part 10a specifies a payment day included in payment data stored in a payment data management part 4 as to the payment data. Then a date comparison part 6b compares the specified payment day with a payment period included in credit data. Based upon the comparison result, a credit data candidate narrowing-down part (date) 10c regards credit data whose payment period has specific relation with the payment day as a candidate for credit data corresponding to the payment date. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a claim management system, a claim management method, and a claim management program for supporting identification of a claim corresponding to deposit.

In general, the accounting system manages the receivable, and when the receivable is received, a process for erasing the receivable is performed. At this time, it is necessary to specify which claim the deposit is for.
In various transactions in Japan, settlement by bank transfer is widely performed. Banks also offer services that provide account holders with data such as deposits. Note that this service is a form of service in farm banking (FB).

However, in this service, the data provided by the bank basically includes only information such as the date of payment, the name of the transfer requester (katakana), and the amount of money. Therefore, it is difficult to completely identify which bond the deposit corresponds to (for example, slip number, invoice number, debtor (customer) code, etc.) based on data provided by the bank by computer processing. It is.
For this reason, it is based on data provided by the bank, and it is based on human judgment to specify which credits correspond to the deposit, and there is a problem that business efficiency is poor.
Therefore, a system for managing various receivables for the purpose of improving business efficiency has been provided or proposed. One of them is as follows.

  The remittance user makes a selection regarding the invoice to which remittance is made, and remittance breakdown data is generated accordingly, and the unique number associated therewith is an invoice number (INVOICE No.), a reference number (Reference No.), The payment number is generated as a matching key either alone or in combination. Then, the remittance request data including the matching key is output to the remittance user side, and similarly, the remittance breakdown data including the matching key is output to the remittance receiving side.

Thereafter, the remittance request data including the matching key is transferred to the remittance user side financial institution by the remittance user side, and the remittance is requested. A payment order including a matching key is passed from a financial institution on the remittance user side to a financial institution on the remittance receiving side. The remittance receiving side obtains remittance arrival data including a matching key from a financial institution on the remittance receiving side, matches the remittance breakdown data received previously with the matching key, and performs the revocation processing of the bond (for example, , See Patent Document 1).
JP 2003-271888 A

  The inventor of the present application has obtained the knowledge that during the devising of a system that can efficiently identify which bond the deposit is for, the deposit is very often made on or close to the due date. And while considering this, it has been thought that it is possible to more efficiently identify which bond the deposit corresponds to, but considering the knowledge obtained by the present inventors including the system described above. I haven't found the technology to manage the receivables.

  In addition, a company generally has many customers, and some of them have similar names. Furthermore, the customer does not always enter the name of the transfer requester (katakana) with the same name. This also contributes to the time required to identify which bond the deposit corresponds to.

  Accordingly, the present invention provides a claim management system, a claim management method, and a claim management program for supporting efficient identification of a claim corresponding to a receipt by taking into account the receipt date and the due date. Objective. In addition, the present invention is capable of efficiently identifying the receivable corresponding to the deposit even when the customer has many customers and the customer uses a plurality of transfer requester names (katakana). The object is to provide a receivable management system, a receivable management method, and a receivable management program.

  The claim management system according to claim 1 is a claim management system that supports the identification of a claim corresponding to a deposit, and is included in the deposit data management means (1) for managing a plurality of claim data including a due date, and the receipt data. Date comparison means (10b) for comparing the payment date with the due date included in each of the bond data managed by the bond data management means, and the payment included in the payment data based on the comparison result by the date comparison means A credit data due date narrowing means (10c) which uses the claim data having a predetermined relationship with respect to the date as candidates for the claim data for the deposit data.

  The claim management method according to claim 3 is a claim management method performed in a claim management system having a claim management means (1) for managing a plurality of claims data including payment dates, which supports identification of a claim corresponding to a deposit. The date comparison procedure (S116 to S117) for comparing the payment date included in the deposit data with the payment date included in each bond data managed by the bond data management means, and based on the comparison result in the date comparison procedure Receivable data date narrowing procedure (S118 to S119) in which receivable data having a predetermined relationship with the payment date included in the payment data is used as a candidate for receivable data for the payment data. Features.

  The claim management program according to claim 5 is a computer for supporting identification of a claim corresponding to a deposit, a claim data management means (1) for managing a plurality of claim data including a due date, and a receipt date included in the receipt data. The date comparison means (10b) for comparing with the due date included in each of the bond data managed by the bond data management means, and the payment date included in the payment data based on the comparison result by the date comparison means The credit data due date having a predetermined relationship is functioned as a credit data date narrowing means (10c) that uses the credit data as a candidate for the credit data for the deposit data.

  According to claim 1, claim 3, and claim 5, the payment having a predetermined relationship with the payment date using the payment date included in the payment data and the payment date included in the managed bond data. The due date data of the due date is set as a candidate for the claim data corresponding to the deposit data. Therefore, since the credit data to be selected is reduced when the person in charge specifies the claim data corresponding to the deposit, the specification can be performed efficiently. Further, narrowing down the receivable data to be selected using the payment date and the payment date is based on the knowledge obtained by the inventors of the present invention that much of the payment is made on or close to the payment date. It is a match.

  The claim management system according to claim 2, wherein the claim data includes an income receiver code, and for each client code corresponding to the income receiver code, the requester code includes a requester code transfer requester. A transfer use name management means (3) for managing one or a plurality of transfer request person names associated with each other, and a transfer request person name managed by the transfer use name management means for the transfer request person name included in the deposit data A client name comparison unit (6b) to be compared and a transfer requester who uses a transfer requester name having a predetermined relationship with a transfer requester name included in the deposit data based on a comparison result by the client name comparison unit. Transfer requester narrowing means (6c) as candidates for the transfer requester, and requester candidate display means for displaying the transfer requester candidates based on the narrowing result by the transfer requestor narrowing means 7), requester designating means (8) for designating a transfer requester from the candidates for transfer request displayed on the candidate client display means, and among the claims data managed by the claim management means Further, a receivable data requester narrowing means (9) that uses the receivable data of the income receiver code that matches the requester code of the transfer requester specified by the requester specifying means as a candidate for the deposit data. It is characterized by that.

  The claim management method according to claim 4, wherein the claim data includes an income receiver code, and the claim management system includes, for each client code corresponding to the income receiver code, a request to the client code. Further included is a transfer use name management means (3) for managing one or a plurality of transfer requester names used by the person code transfer requester, and using the transfer requester name included in the deposit data as the transfer use. The client name comparison procedure (S104 to S106) to be compared with the transfer client name managed by the name management means, and the transfer client name included in the deposit data based on the comparison result in the client name comparison procedure A transfer requester narrowing procedure (S107 to S108) in which a transfer requester who uses a certain transfer requester name is a candidate for a transfer requester of the deposit data, and the transfer requester narrowing procedure Requester candidate display procedure (S109) for displaying the transfer requester candidate based on the narrowing-down result, and a request for designating the transfer requester from the transfer requester candidates displayed in the requester candidate display procedure From the person designation procedure (S109) and the claim data managed by the claim management means, the claim data of the income destination code that matches the requester code of the transfer requester designated in the requester designation procedure is obtained. A bond data requester narrowing-down procedure (S113 to S115) as candidates for the deposit data.

  7. The claim management program according to claim 6, wherein the claim data includes a destination code, and the computer transfers the requester code to the requester code for each requester code corresponding to the destination code. Transfer use name management means (3) for managing one or more transfer requester names used by the client in association with each other, and a transfer request in which the transfer request name included in the deposit data is managed by the transfer use name management means A client name comparison means (6b) for comparing with a person name, and a payment requester who uses a transfer client name having a predetermined relationship with a transfer client name included in the payment data based on a comparison result by the client name comparison means. Transfer requester narrowing means (6c) as a data transfer requester candidate, and a client who displays a transfer requester candidate based on the narrowing result by the transfer requester narrowing means Supplementary display means (7), client designation means (8) for designating a transfer requester from the candidates for transfer request displayed on the candidate candidate display means, and claims managed by the claim management means Receiving data requester narrowing means (9), which uses, as candidates for the deposit data, the receivable data of the income receiver code that matches the requester code of the transfer requester specified by the requester specifying means from among the data Further, the computer is made to function.

According to claim 2, claim 4, and claim 6, the transfer requester name included in the receipt data using the transfer requester name included in the receipt data and the transfer requester name used by the managing client. A transfer requester who uses a transfer requester name having a predetermined relationship is set as a transfer requester candidate for the received data. Therefore, it is possible to efficiently identify the transfer requester who has made the deposit.
Further, narrowing down is performed such that the claim data of the income receiver code that matches the requester code of the transfer requester as a candidate is a candidate for the claim data for the deposit data. For this reason, when the person in charge specifies the bond data corresponding to the deposit, the bond data to be selected further decreases, so that the specification can be performed more efficiently.

  It should be noted that “(sign)” referred to in this column only exemplifies a corresponding configuration in a column (the best mode for carrying out the invention) to be described later, and does not indicate any claim in the claims. The interpretation is not limited.

  According to the present invention, it is the knowledge obtained by the present inventor that realizes narrowing down the candidates for receivables in accordance with the fact that many of the deposits are made close to the due date, and Since the number is small, for example, a person in charge can efficiently specify a bond for deposit.

  Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings.

  First, the configuration of the bond management system in the embodiment of the present invention will be described with reference to FIG. FIG. 1 is a functional block diagram for explaining the function of the bond management system in the present embodiment. However, in this embodiment, a description will be given focusing on functions necessary for narrowing down bond data corresponding to deposit data from a plurality of bond data. In the present embodiment, a case will be described in which the deposit data provided from the bank is collected at a time and used as the deposit data to be processed. However, only the deposit data specified by the user is set as the deposit data to be processed. In some cases.

  As shown in FIG. 1, the bond management system includes a bond data management unit 1, a customer management unit 2, a transfer use name management unit 3, a deposit data management unit 4, a deposit data take-in unit 5, and a client narrowing processing unit 6. , Candidate client display unit 7, client specification unit 8, bond data candidate screening unit (client) 9, due date screening processing unit 10, candidate loan data display unit 11, bond data specification unit 12, and loan application It functions as the processing unit 13.

  The bond data management unit 1 registers and manages bond information for each bond, an example of which is shown in FIG. FIG. 2 is a diagram showing an example of the contents stored in the bond data management unit 1. As shown in FIG. 2, the receivable data registered and managed in the receivable data management unit 1 includes an income receiver code, a payment date, an amount, and the like. The income destination code is a code uniquely assigned to a customer who deposits a claim.

  The customer management unit 2 registers and manages customer information (hereinafter referred to as customer information) for each customer, an example of which is shown in FIG. FIG. 3 is a diagram showing an example of the contents stored in the customer management unit 2. Each customer is uniquely assigned a code (hereinafter referred to as a customer code). As shown in FIG. 3, customer information registered and managed in the customer management unit 2 is the customer's customer name ( (Official name) and the customer code of the customer. However, the revenue destination code and customer code related to the same customer are the same code. The customer code is a code corresponding to the client code.

  The transfer use name management unit 3 registers and manages a transfer requester name (katakana) used when a customer makes a transfer, an example of which is shown in FIG. FIG. 4 is a diagram showing an example of the contents stored in the transfer use name management unit 3. As shown in FIG. 4, the customer use name management unit 3 stores the customer code and the transfer requester name (transfer requester name (katakana) used by the customer of this customer code when making a transfer) in association with each other. Yes. However, since the same customer may use a plurality of transfer requester names (Katakana), there may be a plurality of transfer requester names (Katakana) in one customer code.

  The deposit data management unit 4 registers and manages deposit data provided from a bank, an example of which is shown in FIG. FIG. 5 is a diagram showing an example of the contents stored in the deposit data management unit 4. As mentioned above, in the payment data provided by the bank, the name of the transfer client (katakana) used when the customer made the transfer, the payment date the customer actually made the payment, and the customer actually made the transfer Only basic information such as the amount (transfer amount) is included. As shown in FIG. 5, the deposit data management unit 4 stores deposit data provided from a bank including them.

  The receipt data capture unit 5 collects the receipt data stored in the receipt data management unit 4 at once.

  The requester narrowing processing unit 6 functions as each part of the transfer use name specifying unit 6a, the transfer requester name comparison unit 6b, and the transfer requester candidate narrowing down unit 6c, and the transfer request included in the deposit data provided by the bank. This payment data from the customers managed by the customer management unit 2 using the name (Katakana) and the transfer request name (Katakana) used by the customer managed by the transfer use name management unit 3 for the transfer. The process of narrowing down the candidate of the customer who performed.

  The transfer use name specifying unit 6 a specifies the transfer requester name (katakana) included in the payment data with respect to the payment data acquired by the payment data acquisition unit 5.

  The transfer requester name comparison unit 6b compares the transfer requester name (katakana) specified by the transfer use name specifying unit 6a with the transfer requester name (katakana) stored in the transfer use name management unit 3.

  The transfer requester candidate narrowing-down unit 6c is based on the comparison result by the transfer requester name comparison unit 6b, and the transfer is in a predetermined relationship (matched in this embodiment) with the transfer requester name (katakana) of the deposit data. The transfer requester name (katakana) stored in the use name management unit 13 is used as a candidate for the deposit data, thereby narrowing down the transfer requester (customer who made the transfer). Then, the transfer requester candidate narrowing down part 6c specifies the customer code related to the transfer requester name (katakana) as the candidate from the stored contents of the transfer use name management part 3, and further this customer based on the specified customer code. The official name of the customer of the code is specified from the stored contents of the customer management unit 2.

  The candidate client display unit 7 is configured by a liquid crystal display, for example, and is captured by the deposit data capturing unit 5 based on the processing result of the transfer requester candidate narrowing unit 6c of the client narrowing processing unit 6. For each deposit, the customer code of the customer who is a candidate for the transfer client who made the deposit and its official name are displayed (see FIG. 7).

  The client designation unit 8 is configured by, for example, a keyboard or a pointing device, and is used by the user to designate one customer from the candidates for the transfer client displayed on the candidate client display unit 7. .

  Receivable data candidate narrowing down section (client) 9, among the receivable data managed by the receivable data management section 1 based on the customer code of the customer specified by the client specifying section 8 for the deposit, Receivable data having the same income code as the customer code is set as a candidate for receivable data for the received data.

  The due date narrowing processing unit 10 functions as each of the deposit date specifying unit 10a, the date comparison unit 10b, and the claim data candidate narrowing unit (date) 10c, and the deposit date and the receivable included in the deposit data provided by the bank. Of the receivable data stored in the receivable data management unit 1 using the due date included in the data, the receivable data candidate screening unit (client) 9 selects the receivable data as candidates The process of narrowing down the candidates for bond data for this deposit data is performed.

  The payment date specifying unit 10 a specifies the payment date included in the payment data with respect to the payment data acquired by the payment data acquisition unit 5.

  The date comparison unit 10b uses the deposit date specified by the deposit date specifying unit 10a and the deposit data candidate narrowing-down unit (requester) 9 out of the receivable data stored in the receivable data management unit 1 to identify candidates for the received data. The due date included in the receivable data is compared.

  Based on the comparison result by the date comparison unit 10b, the bond data candidate narrowing down part (date) 10c selects the bond data for which the payment date of the payment data has a predetermined relationship with the payment date, In this way, the bond data is narrowed down. However, as a predetermined relationship, for example, the payment date is from 3 days before the payment due date (example) to the payment due date, or the payment date is the same as the payment due date, or the payment date is 3 days from the payment due date (example) To 2 days after the due date (one example). For example, the system may be constructed with a predetermined relationship as a fixed value, or the system may be constructed so that the user designates the predetermined relationship each time. In the latter case, if the user does not specify, the default value is used.

  The narrowing down of the bond data with respect to the deposit data by the function of each unit of the due date narrowing processing unit 10 is performed by the above-described knowledge obtained by the inventors of the present application (most of the deposits are made on the date of payment or close to the date of payment. ).

  The candidate bond data display unit 11 is configured by a liquid crystal display, for example, and is captured by the deposit data capture unit 5 based on the processing result of the bond data candidate narrowing unit (date) 10c of the due date narrowing processing unit 10 For each deposit, the bond data that is a candidate for the transfer client who made the deposit is displayed (see FIG. 8).

  The bond data specifying unit 12 is configured by, for example, a keyboard or a pointing device, and is used by the user to specify one customer from the bond data candidates displayed on the candidate bond data display unit 11.

  The receivable application processing unit 13 performs receivable data application processing based on the user input using the receivable data specifying unit 12 (designation of receivable data for deposit).

  Next, the credit management method performed in the credit management system described above with reference to FIGS. 1 to 5 will be described with reference to FIG. FIG. 6 is a flowchart showing the processing procedure of the credit management method performed by the credit management system.

  Deposit data including the above information is sent from the bank. Then, the deposit data is registered and managed in the deposit data management unit 4 by processing of a processing unit (not shown) (step S101). The processing in this step S101 is performed whenever the deposit data is sent from the bank.

  When the user performs a predetermined operation for taking in the FB data using the input unit, the receipt data managed by the receipt data management unit 4 is collectively fetched by the deposit data fetch unit 5 ( Step S102). In addition, when making the payment data of a process target into a user specification, what is necessary is just to construct | assemble so that a user can specify the payment data of a process target by step S102.

  In the transfer use name identifying unit 6a of the client narrowing-down processing unit 6, it is determined whether there is any deposit data that has not been subjected to the processing in step S104, which will be described later, among the deposit data fetched in a lump in step S102 ( Step S103), if there is any (S103: YES), the transfer request name (katakana) included in one of the unprocessed payment data among the payment data captured in step S102 in the transfer use name specifying unit 6a. Is identified (step S104), and the process proceeds to step S105. If not (S103: NO), the process proceeds to step S109.

  In the transfer request person name comparison unit 6b, it is determined whether there is a transfer request person name (katakana) that has not been subjected to the processing in step S106 among the transfer request person names (katakana) managed by the transfer use name management unit 3 ( If there is any (step S105) (S105: YES), the process proceeds to step S106. If not (S105: NO), the process returns to step S103.

  In the transfer requester name comparison unit 6b, the transfer requester name (katakana) specified in step S104 is compared with one transfer requester name (katakana) managed by the transfer use name management unit 3 that is not a comparison target. (Step S106).

  In the transfer requester candidate narrowing down part 6c, based on the comparison result in step S106, it is determined whether or not both are in a predetermined relationship (step S107). If they are in a predetermined relationship (S107: YES), payment data As a candidate transfer requester for (step S108), the process returns to step S105. If not in the predetermined relationship (S107: NO), the process returns to step S105.

  By performing the processing from step S103 to step S108, the transfer requester name (Katakana) used at the time of depositing has a predetermined relationship with the transfer requester name (katakana) used at the time of depositing for all the payment data captured in step S102. A transfer requester (customer) who uses katakana) is listed as a candidate for a transfer request for payment data.

  As shown in the example of FIG. 7, the customer code and the official name of the customer listed as candidates for each deposit are displayed on the candidate client display unit 7 (step S109). FIG. 7 is a diagram showing an example of a screen displayed on the candidate client display unit 7. In FIG. 7, customer codes and their official names (parts in some cases) listed as candidates for each deposit are displayed (the part indicated by A in the figure). There is an input field (portion indicated by B in the figure) used when designating.

  The user designates the customer code by inputting the customer NO using the client designation unit 8 among the candidate customers for each deposit displayed on the client display unit 7 (step S110).

  The bond data candidate narrowing down section (client) 9 determines whether there is any deposit data that has not been subjected to processing such as step S112, which will be described later, among the deposit data that has been collected at step S102 (step S111). If there is (S111: YES), the process proceeds to step S112. If not (S111: NO), the process proceeds to step S120.

  In the bond data candidate narrowing down section (client) 9, it is determined whether there is any bond data that has not been subjected to processing such as step S <b> 113 described later among the bond data stored in the bond data management section 1 (step S <b> 112). ) If there is (S112: YES), for one of the unprocessed bond data, the income destination code included therein is specified (step S113), and the process proceeds to step S114. If not (S112: NO), the process returns to step S111.

  In the bond data candidate narrowing down section (client) 9, the customer code specified in step S110 and the income destination code specified in step S113 are compared with respect to the target deposit data (step S114), and the two match. Is determined (step S115). If the two match (S115: YES), the bond data becomes a candidate for the deposit data, and the process proceeds to step S116. If they do not match (S115: NO), the process returns to step S112.

  The payment date specifying unit 10a of the due date narrowing processing unit 10 specifies the payment date included in the received payment data (step S116), and proceeds to the process of step S117.

  In the date comparison unit 10b, the payment date of the payment data specified in step S116 is compared with the payment date included in the subject bond data (step S117), and the process proceeds to step S118.

  Based on the comparison result in step S117, the bond data candidate screening unit 10c determines whether the payment date has a predetermined relationship with the due date (step S118). If the payment date has a predetermined relationship (S118) : YES), it is set as candidate bond data for the target deposit data (step S119), and the process returns to step S112. If not in the predetermined relationship (S118: NO), the process returns to step S112.

  By performing the processing from step S111 to step S119, for each deposit data collected in step S102, the bond data related to the customer specified by the user, which has a predetermined relationship with the deposit date of the deposit data. Receivable data on a certain due date is listed as a candidate receivable data for the received data.

  The candidate bond data display unit 11 displays the bond data listed as candidates for the deposit for each deposit, as shown in FIG. 8 (step S120). FIG. 8 is a diagram showing an example of a screen displayed on the candidate bond data display unit 11. FIG. 8 is for one deposit data. In FIG. 8, information on bond data listed as candidates for the deposit data is displayed (part indicated by C in the figure). There is a selection button (portion indicated by D in the figure) used when designating.

  The user specifies one of the candidate bond data for the deposit displayed on the candidate bond data display unit 11 using the bond data specifying unit 12 (step S121). Then, the receivable application processing unit 13 performs receivable data application processing on the receivable data designated for the deposit data, and the management content of the receivable data management unit 1 is updated (step S122).

  According to the embodiment described above, the payment date included in the payment data and the payment date included in the bond data are used, and the payment date and the payment date are in a predetermined relationship (for example, several days before the payment date). The credit data is narrowed down using the credit data on the payment due date as candidates for the deposit data. This is narrowing down in accordance with the knowledge obtained by the inventors of the present application that payment is often made close to the due date. For this reason, as a result of performing narrowing down according to the knowledge obtained by the present inventors and reducing the number of receivable data to be selected with respect to the deposit data, the user can easily determine the receivable data with respect to the deposit data.

  In addition, since the receivable data is narrowed down to the deposit data using the name of the transfer requester (katakana) included in the deposit data, the number of receivable data to be selected for the deposit data is reduced. As a result, the user can easily determine bond data for the deposit data.

  Although the preferred embodiments of the present invention have been described above, the present invention is not limited to the above-described embodiments, and various design changes can be made within the scope described in the claims. is there. For example, in the above-described embodiment, both refining the bond data using the payment date included in the deposit data and filtering the bond data using the transfer requester name (katakana) included in the deposit data However, the present invention is not limited to this, and it is also possible to narrow down the bond data using the payment date included in the payment data. Further, it is also possible to narrow down the bond data using the name of the transfer requester (katakana) included in the deposit data.

  It should be noted that a program for realizing the functions of each processing unit described above is recorded on a computer-readable recording medium, the program recorded on the recording medium is read into a computer system, and executed to execute the above-described various processes. You may go. The “computer system” here includes an OS and hardware such as peripheral devices. The “computer system” includes a WWW system provided with a homepage providing environment (or display environment). The “computer-readable recording medium” refers to a storage device such as a flexible medium, a magneto-optical disk, a portable medium such as a ROM and a CD-ROM, and a hard disk incorporated in a computer system. Further, the “computer-readable recording medium” refers to a volatile memory (RAM) in a computer system that becomes a server or a client when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. In addition, those holding programs for a certain period of time are also included.

  The program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in the transmission medium. Here, the “transmission medium” for transmitting the program refers to a medium having a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. The program may be for realizing a part of the functions described above. Furthermore, what can implement | achieve the function mentioned above in combination with the program already recorded on the computer system, and what is called a difference file (difference program) may be sufficient.

The functional block diagram for demonstrating the function of the credit management system in embodiment of this invention. The figure which shows an example of the memory content of the bond data management part of FIG. The figure which shows an example of the memory content of the customer management part of FIG. The figure which shows an example of the memory content of the transfer use name management part of FIG. It is a figure which shows an example of the memory content of the payment data management part of FIG. The flowchart which shows the process sequence of the credit management method which the credit management system of FIG. 1 performs. The figure which shows the example of a screen displayed on the candidate requester display part of FIG. The figure which shows the example of a screen displayed on the candidate loan data display part of FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Claim data management part 2 Customer management part 3 Transfer use name management part 4 Deposit data management part 5 Deposit data capture part 6 Requester narrowing processing part 6a Transfer use name specification part 6b Transfer request person name comparison part 6c Transfer requester candidate Narrowing part 7 Candidate client display part 8 Client specifying part 9 Receivable data candidate narrowing part (client)
10 Date processing unit 10a Payment date identification unit 10b Date comparison unit 10c Receivable data candidate screening unit (date)
10d Candidate bond data display part 10e Claim data specification part 11 Claim application processing part

Claims (6)

In a claims management system that supports the identification of claims corresponding to deposits,
A receivable data management means for managing a plurality of receivable data including due dates;
A date comparison means for comparing a payment date included in the payment data with a payment due date included in each bond data managed by the bond data management means;
Receivable data due date narrowing means that makes the receivable data of the due date having a predetermined relationship with the payment date included in the receipt data based on the comparison result by the date comparison means as a candidate for the claim data for the receipt data;
A debt management system characterized by comprising: The bond data includes the income code,
For each client code corresponding to the income code, a transfer use name management means for managing the client code in association with one or a plurality of transfer client names used by the client requesting the client code;
A client name comparing means for comparing the name of the transfer requester included in the deposit data with a transfer requester name managed by the transfer use name management means;
A transfer requester who makes a transfer requester who uses a transfer requester name having a predetermined relationship with a transfer requester name included in the payment data based on a comparison result by the requester name comparison means as a transfer requester candidate of the payment data Narrowing means,
Requester candidate display means for displaying the transfer requester candidates based on the narrowing result by the transfer requestor narrowing means;
Requester designation means for designating a transfer requester from among transfer requester candidates displayed on the requester candidate display means;
Receivable data in which the receivable data of the income receiver code that matches the requester code of the transfer requester specified by the requester specifying means is selected as the candidate for the deposit data from the receivable data managed by the receivable management means Client narrowing means,
The claim management system according to claim 1, further comprising: In a claim management method performed in a claim management system having a claim management means for managing a plurality of claims data including payment dates, which supports identification of claims corresponding to deposits,
A date comparison procedure for comparing the payment date included in the payment data with the due date included in each bond data managed by the bond data management means;
Receiving data due date due to the payment data having a predetermined relationship with the payment date included in the payment data based on the comparison result in the date comparison procedure,
A claim management method characterized by comprising: The bond data includes the income code,
In the claim management system, for each client code corresponding to the income receiver code, a transfer use name that is managed by associating one or a plurality of transfer requester names used by the requester code with the requester code. Further includes management means,
A requester name comparison procedure for comparing the transfer requester name included in the deposit data with the transfer requester name managed by the transfer use name management means;
Based on the comparison result in the requester name comparison procedure, the transfer requester who uses the transfer requester name having a predetermined relationship with the transfer requester name included in the payment data as a candidate for the transfer requester of the payment data Refinement procedure,
Requester candidate display procedure for displaying transfer requester candidates based on a narrowing result in the transfer requester narrowing procedure;
A client designation procedure for designating a transfer client from among candidates for a transfer client displayed in the client candidate display procedure;
Receivable data in which the receivable data of the income receiver code that matches the requester code of the transfer requester specified in the requester specifying procedure is selected as the candidate for the deposit data from the receivable data managed by the receivable management means Requester narrowing procedure,
The claim management method according to claim 3, further comprising: A computer that supports the identification of receivables
Receivable data management means for managing multiple receivable data including due dates,
A date comparison means for comparing a payment date included in the payment data with a payment due date included in each of the bond data managed by the bond data management means, and included in the payment data based on a comparison result by the date comparison means Receivable data due date narrowing means using receivable date data having a predetermined relationship with the payment date as a candidate for receivable data for the payment data;
A debt management program characterized by functioning as The bond data includes the income code,
Computer
For each client code corresponding to the income destination code, a transfer use name management means for managing the client code in association with one or a plurality of transfer client names used by the client requesting the client code;
A client name comparison unit that compares the name of the transfer requester included in the deposit data with a transfer requester name managed by the transfer use name management unit;
A transfer requester who makes a transfer requester who uses a transfer requester name having a predetermined relationship with a transfer requester name included in the payment data based on a comparison result by the requester name comparison means as a transfer requester candidate of the payment data Narrowing means,
Requester candidate display means for displaying the transfer requester candidates based on the narrowing down result by the transfer requestor narrowing means;
Requester designating means for designating a transfer requester from candidates of transfer requesters displayed on the client candidate display means, and the client designating means from among the claim data managed by the claim management means Receivable data requester narrowing means that makes the receivable data of the destination code that matches the requester code of the transfer requester specified by
The claim management program according to claim 5, further comprising causing a computer to function.

Images