JP6815015B1 - Billing application method and billing application program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a payment management method and a payment management program capable of facilitating extraction of billing data and payment data corresponding to the same billing destination and smoothly performing application. A payment management method is a shared update step of updating a shared learning history 14 based on application information related to application performed on a shared user who shares the shared learning history 14 among users 2. including. The application information includes the corporate number corresponding to the billing destination of the billing data and the name of the transfer requester. At least one of the batch application process for the shared user and the individual application process for the shared user performs the application based on the billing data, the deposit data, and the user learning history 15 that can be updated based on the shared learning history 14. including. [Selection diagram] Fig. 3

Description

The present invention relates to a claim clearing method and a claim clearing program.

Generally, payment by wire transfer is widely used as a payment method for commercial transactions. In the settlement by transfer, when the seller sells the product or the like to the buyer, the seller issues an invoice stating the invoice amount to the buyer based on the information of the product or the like. For example, the buyer charges the invoice amount to the seller's bank through EB (Electronic Banking), through the window of a financial institution such as a bank, or using an ATM (Automated Teller Machine), or by other means. Ask the bank to transfer money to your account. The requested financial institution transfers funds from the buyer's bank account to the seller's bank account through a payment network such as the Japanese Bankers Association. As a result, payment is made by wire transfer.

The seller prepares billing data related to the invoice issued and further prepares deposit data related to the transfer received by the seller in order to manage the settlement. By collating the billing data with the deposit data, the seller confirms whether the buyer who is the billing destination made the transfer. Since it is complicated to manage the settlement manually, there is a method of managing the settlement with less labor by automatically clearing the billing data and the deposit data as in Patent Document 1.

JP-A-2018-73249

By the way, billing data may be manually input or created by an accounting system. Deposit data may be entered manually or obtained as data from a bank. The deposit data includes the name of the transfer requester who is the billing address. For example, the billing address of the billing data may be written in Chinese characters, and the name of the transfer requester of the deposit data provided by the bank may be written in katakana. In addition, the same billing address may use different transfer requester names. Therefore, for clearing, simply extracting the name that matches the name stated as the billing address on the invoice and the name of the transfer requester and executing the clearing will result in billing data and payment related to the same billing address. The data will remain without being subject to clearing.

The present invention has been made in view of such circumstances, and an object, wherein clearing methods and can be performed clearing smoothly and easily extracted and the payment data billing data corresponding to the same billing To provide a billing application program.

The first aspect is a billing clearing method executed by a computer for managing the payment of a plurality of users, wherein clearing method comprising the billing data acquisition step of acquiring one or more billing data, A deposit data acquisition process that acquires one or more deposit data including the name of the transfer requester, a batch application process that automatically applies the billing data, and an individual deletion process that applies the billing data based on manual operation. A shared update process that updates the shared learning history based on the application related to the application performed to the shared user who shares the shared learning history among the users, and a shared update process prepared for each user. Including that the user learning history that is not shared can be updated by the user based on the shared learning history, the application information includes the corporate number corresponding to the billing destination of the billing data and the transfer requester name, and the corporate number is , Unique identification information assigned to each of multiple corporations, and at least one of the batch application process for shared users and the individual application process for shared users is based on billing data, deposit data, and shared learning history. It is a billing application method that includes performing application based on an updatable user learning history.

According to the first aspect, since a plurality of shared users can perform the application using the user learning history that can be updated based on the shared learning history learned by the application of other shared users, the application can be performed individually. Compared to the case where only the user learning history learned by the user is used, the application can be performed efficiently by using the corporate number and the transfer requester's name, and the learning speed can be increased. .. Since the shared learning history is updated based on the unique corporate number, it is easier to clearly identify the transfer requester name than when using the identification information unique to each user. In addition, when the number of new shared users increases, it is possible to efficiently clear the data from the beginning by using the shared learning history even if there is no user learning history independently learned. As a result, the billing data and the deposit data corresponding to the same billing destination can be easily extracted and the application can be smoothly performed.

The second aspect is that the shared learning history is updated by storing the shared correspondence relationship representing the correspondence between the corporate number involved in the application and the transfer requester's name in the shared learning history. Including, at least one of the batch application process for shared users and the individual application process for shared users is a corporation that corresponds to the billing destination of user learning history and billing data that can be updated based on the shared correspondence relationship in the shared learning history. based on the transfer request names the number and deposit data, including shared extraction step of extracting the billing data and payment data to be candidates for use in clearing, the billing clearing method according to the first aspect is there.

According to the second aspect, since the correspondence between the corporate number stored in the shared learning history and the transfer requester's name is used, the billing is performed as compared with the case where each user uses only the user learning history independently learned. Data and deposit data can be extracted efficiently. Even if the payment data has different transfer requester names, it can be known that they are the same person if the corporate number is common, so that the billing data and the payment data that are candidates for application can be extracted with high accuracy.

The third aspect, wherein clearing method, based on the customer name that represents the billing that corresponds to the billing data includes a first user update step of storing a first correspondence between the user learning history, the The correspondence relationship of 1 represents the correspondence between the customer name involved in the application and the transfer requester name, and the second correspondence relationship representing the correspondence between the customer name and the corporate number is included in the user learning history. The shared update process updates the shared learning history by storing the shared correspondence in the shared learning history based on the first correspondence and the second correspondence in the user learning history of the shared user. The claim application method according to the second aspect, which includes.

According to the third aspect, each user can manage the individual user learning history without sharing the first correspondence relationship representing the correspondence between the customer name and the transfer requester name, and also the customer name. It is possible to manage without sharing the second correspondence relationship indicating the correspondence between the and the corporate number. Further, since the shared learning history is updated based on the first correspondence and the second correspondence of the user learning history of a plurality of shared users, the shared user who can use the shared learning history has his / her own. It is possible to perform the application more efficiently than when using only the user learning history.

In the fourth aspect, the billing application method includes a corporate number setting step of creating a second correspondence by associating the customer name with the corporate number based on the input by the user, and the corporate number setting process is performed. The request cancellation according to the third aspect, which includes obtaining the corporate number corresponding to the corporate name represented by the customer name by referring to the corporate number data storing the corporate number corresponding to the corporate name. It is a inclusion method.

According to the fourth aspect, the corporate number can be obtained based on the customer name and the second correspondence can be easily created. Therefore, for example, it is possible to easily associate the corporate number with the billing destination of the billing data for which the customer name is known, and to correct the corporate number of the billing data for which the customer name is known.

Fifth aspect, wherein clearing method, based on the corporate number corresponding to the billing data includes a second user updating step of storing the third correspondence to the user learning history, third correspondence relationship , Represents the correspondence between the corporate number involved in the application and the name of the transfer requester, and the shared update process stores the third correspondence in the user learning history of the shared user in the shared learning history. The claim application method according to the second aspect, which comprises updating the history.

According to the fifth aspect, each user can manage the individual user learning history without sharing the third correspondence relationship representing the correspondence between the corporate number and the transfer requester's name. Furthermore, since the shared learning history is updated based on the third correspondence of the user learning history of a plurality of shared users, the shared user who can use the shared learning history uses only his / her own user learning history. It is possible to perform the application more efficiently than in the case.

In the sixth aspect, the individual application process for the shared user displays the billing data and the deposit data extracted based on the user learning history in the shared extraction process, and the displayed billing data and the deposit data. Is a claim application method according to any one of the second to fifth aspects, including manually associating the data for application.

According to the sixth aspect, only the user learning history is used because the user can manually associate the billing data and the deposit data extracted based on the user learning history that can be updated based on the shared learning history. It is possible to accurately associate billing data with payment data because excess or deficiency of extraction is less likely to occur.

The seventh aspect includes a user setting step of selecting whether the billing application method is at least a shared user or a non-shared user who does not share the shared learning history for a plurality of users, and the non-shared user. The batch clearing process for and the individual clearing process for non-shared users include the user-specific extraction process, and the user-specific extraction process is used for clearing based on the user learning history that cannot be updated based on the shared learning history. are the extracts the candidate becomes billing data and payment data, wherein clearing method does not update the shared learning history on the basis of the clearing information associated with clearing made to non-shared user, first The claim application method according to any one of the sixth aspects from the above aspect.

According to the seventh aspect, the user can select whether to be a shared user or a non-shared user, and since the shared learning history is not updated when the user is a non-shared user, the user's security management options are expanded.

An eighth aspect is a billing application program that causes a computer to execute the billing application method according to any one of the first to seventh aspects.

According to the present invention, billing data and deposit data corresponding to the same billing destination can be easily extracted and can be smoothly applied.

It is a schematic block diagram which shows the structure which concerns on the settlement management method which concerns on this Embodiment. It is a user learning history stored in the storage device of FIG. It is a shared learning history stored in the storage device of FIG. It is a flow chart of the shared type extraction process executed by the settlement management unit of FIG. It is a flow chart of the extraction process for each user executed by the settlement management unit of FIG. It is a flow chart of the payment management method executed by the payment management unit of FIG. It is a billing data setting table displayed in the billing data setting process of FIG. It is a deposit data setting table displayed in the deposit data setting process of FIG. It is a flow chart of the batch clearing process executed by the settlement management unit of FIG. It is a collation order setting table displayed in the collation order setting process of FIG. It is a clearing result table displayed in the result display process of FIG. It is a candidate screen displayed in the individual application process of FIG. It is a selection table displayed in the individual application process of FIG. It is a simulation table displayed in the individual application process of FIG. It is a figure which shows the storage content of the storage device in the modification. It is a flow chart of the settlement management method in a modification.

(Outline configuration)
FIG. 1 is a schematic configuration diagram showing components related to a payment management method, including a payment management system 1 that implements a payment management (billing application) method according to the present embodiment. The payment management system 1 is a cloud-type system that provides a service for managing payments of a plurality of users 2 to users 2 via a network 3. The payment management system 1 may be constructed using the same equipment as other services, or may be constructed using independent equipment that is not shared with other services.

The payment management system 1 is connected to the network 3. A plurality of user devices 4, a bank system 5, an external system 6, a corporate number providing device 7, and various devices (not shown) used by each of the plurality of users 2 can be connected to the network 3.

As the network 3, various communication paths such as the Internet, an intranet, a local area network 3 (LAN), a wide area network 3 (WAN), a wired communication network, a wireless communication network, a television communication network, a satellite communication network, and acoustic communication are available. However, it is not limited to these. Payment management system 1, user device 4, bank system 5, external system 6, and corporate number providing device 7 include, for example, a distributed computer, a server computer, a desktop computer, a smartphone, a personal digital assistant, a laptop computer, and a tablet computer. , Television, and combinations thereof, but is not limited to these.

The user device 4 is a device having an input / output function for the user 2, and is a device that can use the payment service provided as a website by the payment management system 1. The user device 4 is, for example, a general-purpose computer including a communication device, a storage device, a processor, a display unit, and an input unit. The display according to the instruction of the payment management system 1 is performed by the display unit of the user device 4, for example, the display. Input to the payment management system 1 is performed by an input unit of the user device 4, for example, a keyboard or a mouse.

Although three companies are shown as user 2, the number of users 2 may be more or less than three. User 2 may or may not be a legal entity. For convenience, user 2 may be referred to as US1, US2, and US3 to distinguish them. The user device 4 may be prepared for each user 2, one user device 4 may be used by a plurality of users 2, and one user 2 may use a plurality of user devices 4.

The plurality of users 2 include a shared user who shares the shared learning history 14 described later and a non-shared user who does not share the shared learning history 14. In the example of FIG. 1, US1 company and US2 company are shared users, and US3 company is a non-shared user, but the present invention is not limited to this.

The corporate number providing device 7 is connected to the corporate number storage device 8 that stores the corporate number corresponding to the name of the corporation. The corporate number is unique identification information assigned to each of a plurality of corporations. The corporate number providing device 7 is provided by, for example, the National Tax Agency. The corporate number providing device 7 is accessible from the outside via the network 3, and has a function of returning a corporate number corresponding to the name of the corporation when the name of the corporation is input from the outside. In order to acquire a corporate number from the outside, for example, an API (Application Programming Interface) prepared for controlling the corporate number providing device 7 is used. In the present embodiment, the relationship between the corporate name and the corporate number is stored in advance in the storage device 11 described later as the corporate number data 19. For example, the payment management system 1 communicates with the corporate number providing device 7 once a day to update the corporate number data 19.

The payment management system 1 is a computer including a communication device 10, a storage device 11, and a processor 12 capable of communicating with other devices via a network 3.

The storage device 11 is a payment management (billing application ) program 13 for causing the payment management system 1 to execute a payment management method, a shared learning history 14 shared by shared users, and non-shared user learning prepared for each user 2. It is possible to store the history 15, the comprehensive learning history 16, and the corporate number data 19 representing the relationship between the corporate name and the corporate number, and other information can be stored as needed. In the example of FIG. 1, UH1 which is a user learning history 15 for US1 company, UH2 which is a user learning history 15 for US2 company, and UH3 which is a user learning history 15 for US3 company are included. The stored user learning history 15 is not limited to that shown.

By controlling the communication device 10, the processor 12 transmits and receives information via various devices and the network 3. The processor 12 functions as the payment management unit 17 by reading and executing the payment management program 13 stored in the storage device 11. The payment management unit 17 executes the payment management method described later.

Types of storage device 11 include, but are not limited to, read-only memory, readable and writable memory, volatile memory, non-volatile memory, tangible non-primary recording media, and combinations thereof. Some or all of the various configurations, including those implemented by the processor 12 and the payment management program, may be implemented by hardware such as application specific integrated circuits (ASICs).

(User learning history)
FIG. 2 shows an exemplary user learning history 15 stored in the storage device 11 of FIG. Each user learning history 15 includes a first correspondence 91 and a second correspondence 92. The first correspondence 91 represents the correspondence between the name of the customer who was involved in the application performed in the past and the name of the transfer requester. The application will be described later. The second correspondence 92 represents the correspondence between the customer name and the corporate number. FIG. 2 shows only an example of UH1 which is a user learning history 15 for US1 company and UH2 which is a user learning history 15 for US2 company, but user learning for another user 2, for example, US3 company in FIG. The history 15 is created in the same manner. The specific content of FIG. 2 is an example.

An example of the first correspondence 91 of the UH1 shown in FIG. 2 will be described. The transfer requester names "A" and "Ka) A" correspond to the customer name "A Co., Ltd." The transfer requester names "B" and "Kabushiki Gaishaby" correspond to the customer name "B Co., Ltd." The transfer requester name "C" corresponds to the customer name "C Co., Ltd." The transfer requester name "D" corresponds to the customer name "D Co., Ltd." The transfer requester name "E" corresponds to the customer name "E Co., Ltd." The transfer requester name "F" corresponds to the customer name "F Co., Ltd."

An example of the second correspondence 92 of the UH1 shown in FIG. 2 will be described. "Customer name A Co., Ltd." corresponds to the corporate number "0000000000001". The customer name "B Co., Ltd." corresponds to the corporate number "0000000000002". The customer name "C Co., Ltd." corresponds to the corporate number "0000000000003". The customer name "D Co., Ltd." corresponds to the corporate number "00000000000004". The customer name "E Co., Ltd." corresponds to the corporate number "000000000000500". The customer name "F Co., Ltd." corresponds to the corporate number "0000000000000006".

An example of the first correspondence 91 of the UH2 shown in FIG. 2 will be described. The transfer requester names "A" and "Kabushiki Gaisha" correspond to the customer name "A Co., Ltd." The transfer requester name "Cub) B corresponds to the customer name "B Co., Ltd." The transfer requester names "K" and "C" correspond to the customer name "C Co., Ltd.". The transfer requester name "G" corresponds to the customer name "G Co., Ltd." The transfer requester name "H" corresponds to the customer name "H Co., Ltd." The transfer requester name "Ai" corresponds to the customer name "I Co., Ltd."

An example of the second correspondence 92 of the UH1 shown in FIG. 2 will be described. The customer name "A Co., Ltd." corresponds to the corporate number "0000000000001". The customer name "B Co., Ltd." corresponds to the corporate number "0000000000002". The customer name "C Co., Ltd." corresponds to the corporate number "0000000000003". The customer name "G Co., Ltd." corresponds to the corporate number "00000000000007". The customer name "H Co., Ltd." corresponds to the corporate number "0000000000000". The customer name "I Co., Ltd." corresponds to the corporate number "00000000000009".

The payment management unit 17 causes the user device 4 to display a customer master screen for managing the customer. The payment management unit 17 makes it possible to select the customer whose information is to be changed on the customer master screen. In response to receiving the selection of the customer whose information is to be changed from the user device 4, the payment management unit 17 displays an information change screen on the user device 4 which allows the user device 4 to select whether or not to edit the user learning history 15. Display it. In response to the user device 4 selecting to edit the user learning history 15, the payment management unit 17 refers to the shared learning history 14 using the corporate number corresponding to the customer as a key, thereby referring to the corporate number. Search for the transfer requester name corresponding to. The payment management unit 17 displays the search results as a selectable list on the user device 4. The user learning history 15 is updated based on the corporate number and the transfer requester name selected by the user device 4. Information other than the transfer requester's name may be associated with the corporate number in the shared learning history 14.

(Shared learning history)
FIG. 3 shows an exemplary shared learning history 14 stored in the storage device 11 of FIG. The shared learning history 14 includes a shared correspondence relationship 93. The sharing correspondence relationship 93 represents the correspondence between the corporate number involved in the application performed by the sharing user in the past and the name of the transfer requester. The correspondence between the corporate number and the transfer requester's name in the sharing correspondence 93 is derived from the first correspondence 91 and the second correspondence 92 in the user learning history 15 (FIG. 2) of a plurality of shared users, and is fused. It was done. The specific content of FIG. 3 is an example.

The sharing correspondence relationship 93 shown in FIG. 3 will be described. The corporate number "0000000000001" corresponds to the transfer requester names "A", "Ka) A", and "Kabushiki Gaishae". The corporate number "0000000000002" corresponds to the transfer requester names "B", "Kabushikigai Shabby", and "Cub) Bee". The corporate number "0000000000003" corresponds to the transfer requester names "C" and "F". The transfer requester name "D" corresponds to the corporate number "00000000000004". The transfer requester name "e" corresponds to the corporate number "000000000000500". The transfer requester name "F" corresponds to the corporate number "0000000000000006". The transfer requester name "G" corresponds to the corporate number "00000000000007". The transfer requester name "H" corresponds to the corporate number "0000000000000". The transfer requester name "Ai" corresponds to the corporate number "00000000000009".

(Shared extraction process)
FIG. 4 is a flow chart of a shared extraction process executed by the payment management unit 17 of FIG. The payment management unit 17 extracts one or more billing data and one or more deposit data that are candidates to be used for clearing the shared user by the shared extraction process. In other words, the billing data and deposit data related to the same billing destination are extracted. As will be described later, at least one of the batch application process for the shared user and the individual application process for the shared user includes the shared extraction process. The shared extraction process will be described with reference to FIG.

In step 21, the settlement management unit 17 refers to the billing data and acquires the corporate number corresponding to the billing destination of the billing data. If the billing data includes a corporate number, the corporate number is obtained directly from the billing data. If the billing data does not include the corporate number and includes the customer name corresponding to the billing destination, the corporate number is acquired with reference to the second correspondence 92 (FIG. 2). For example, when the US1 company is the user 2 and the billing address is "A Co., Ltd.", the corporate number "0000000000001" is acquired.

Next, in step 22, the settlement management unit 17 extracts the billing data corresponding to the corporate number acquired in step 21 from the plurality of billing data. The second correspondence 92 (FIG. 2) may be referred to as appropriate for the extraction.

Next, in step 23, the payment management unit 17 refers to the user learning history 15 (FIG. 2) that can be updated based on the shared learning history 14 (FIG. 3), and corresponds to the corporate number acquired in step 21. For example, in the case of US1 company, the transfer requester names "A" and "Ka) A" are acquired corresponding to the corporate number "0000000000001".

Next, in step 24, the settlement management unit 17 extracts the payment data including the transfer requester name corresponding to the corporate number acquired in step 21. As a result, by using the Corporate Number, one or more billing data and one or more deposit data that are candidates for use in the application are extracted.

(Extraction process by user)
FIG. 5 is a flow chart of a user-specific extraction process executed by the payment management unit 17 of FIG. The payment management unit 17 extracts one or more billing data and one or more payment data that are candidates to be used for clearing non-shared users by the user-specific extraction process. In other words, the billing data and deposit data related to the same billing destination are extracted. As will be described later, the batch application process for non-shared users and the individual application process for non-shared users include a user-specific extraction process. The user-specific extraction process will be described with reference to FIG.

In step 25, the settlement management unit 17 refers to the billing data and acquires the corporate number corresponding to the billing destination of the billing data. If the billing data includes a corporate number, the corporate number is obtained directly from the billing data. If the billing data does not include the corporate number and includes the customer name corresponding to the billing destination, the corporate number is acquired with reference to the second correspondence 92 (FIG. 2).

Next, in step 26, the settlement management unit 17 extracts the billing data corresponding to the corporate number acquired in step 25 from the plurality of billing data. The second correspondence 92 (FIG. 2) may be referred to as appropriate for the extraction.

Next, in step 27, the payment management unit 17 refers to the first correspondence 91 in the user learning history 15 (FIG. 2) that cannot be updated based on the shared learning history 14 (FIG. 3), and in step 25. When the transfer requester name corresponding to the acquired corporate number is acquired, for example, when the US1 company is user 2 and the corporate number is "0000000000001", the transfer requester names "A" and "f" A Is acquired.

Next, in step 28, the settlement management unit 17 extracts the payment data including the transfer requester's name corresponding to the corporate number acquired in step 25. As a result, by using the Corporate Number, one or more billing data and one or more deposit data that are candidates for use in the application are extracted.

(First user update process)
The payment management unit 17 executes the first user update step after the application described later or at an appropriate timing, and the user learning shown in FIG. 2 is based on the application information related to the application performed. The first correspondence 91 is stored in the history 15. The application information includes the corporate number corresponding to the billing destination of the billing data involved in the actual application and the name of the transfer requester of the payment data involved in the same application. In other words, since the corporate number and the customer name correspond uniquely, the settlement management unit 17 is involved in the same clearing as the customer name representing the billing destination of the billing data that was actually involved in the clearing. The first correspondence 91 is updated based on the name of the transfer requester of the payment data. The first user update process is executed regardless of whether the user 2 is a shared user or a non-shared user.

For example, referring to FIG. 2, the user 2 is US1 company, the billing destination of the billing data is "A Co., Ltd." corresponding to the corporate number "0000000000001", and the name of the transfer requester of the deposit data is ". In the case of "f) A", the customer "A Co., Ltd." and the transfer requester name "f) A" are stored in UH1 as the first correspondence 91.

(Shared update process)
The payment management unit 17 executes the shared update process after the above-mentioned first user update process or at an appropriate timing. The payment management unit 17 updates the shared learning history 14 based on the application information related to the application performed on the shared user by the shared update process. When the non-shared user is cleared, the payment management unit 17 does not update the shared learning history 14 based on the clearing information related to the clearing. As shown in FIG. 3, the settlement management unit 17 stores the shared learning history 14 in the shared learning history 14, which represents the correspondence between the corporate number involved in the application and the transfer requester's name. Including updating. More specifically, the shared update process shares the shared correspondence 93 shown in FIG. 3 based on the first correspondence 91 and the second correspondence 92 in the user learning history 15 of the shared user shown in FIG. It includes updating the shared learning history 14 by storing it in the learning history 14. In one example, the payment management unit 17 allows the user to select the correspondence between the corporate number and the transfer requester's name, and updates the shared learning history 14 based only on the correspondence between the selected corporate number and the transfer requester's name.

An example will be described with reference to FIG. When the US1 company is the user 2, the settlement management unit 17 refers to the UH1 shown in FIG. 2 and acquires the customer name "B Co., Ltd." corresponding to the corporate number "0000000000002" based on the second correspondence 92. Then, based on the first correspondence 91, the transfer requester names "B" and "Kabushikigai Shabby" corresponding to the customer name "B Co., Ltd." are acquired. As a result, the settlement management unit 17 acquires a correspondence relationship in which the transfer requester names "B" and "Kabushiki Gaishaby" correspond to the corporate number "0000000000002". The payment management unit 17 stores the acquired correspondence as the shared correspondence 93 shown in FIG. 3 in the shared learning history 14.

When the US2 company is the user 2, the settlement management unit 17 refers to UH2 shown in FIG. 2 and acquires the customer name "B Co., Ltd." corresponding to the corporate number "0000000000002" based on the second correspondence 92. Then, based on the first correspondence 91, the transfer requester name "Cub) B corresponding to the customer name "B Co., Ltd." is acquired. As a result, the settlement management unit 17 acquires a correspondence relationship in which the transfer requester name "Cub) Bee corresponds to the corporate number "0000000000002". The payment management unit 17 stores the acquired correspondence as the shared correspondence 93 shown in FIG. 3 in the shared learning history 14.

By the shared renewal process when US1 company is user 2 and the shared renewal process when US2 company is user 2, the transfer requester names "B", "Kabushikigai Shabby", and "Cub" are transferred to the corporate number "0000000000002". The correspondence of "B" is stored in the shared learning history 14 as the shared correspondence relationship 93.

(Corporate number setting process)
In one example, the settlement management unit 17 executes the corporate number setting process.

In the corporate number setting process, the settlement management unit 17 creates a second correspondence 92 (FIG. 2) by associating the customer name with the corporate number based on the input by the user. The payment management unit 17 causes the user device 4 to display a customer master screen for managing the customer. The payment management unit 17 makes it possible to select a customer whose information is to be changed on the customer master screen. In response to receiving the selection of the customer whose information is to be changed from the user device 4, the payment management unit 17 causes the user device 4 to display an information change screen on which it is possible to select whether or not to search for the corporate number. .. In response to the selection of the corporate number search by the user device 4, the payment management unit 17 searches for the corporate number corresponding to the customer by referring to the corporate number data 19.

For example, the settlement management unit 17 searches for a corporate number by partial match, and displays the name and corporate number of the corresponding corporation in a list on the user device 4. The payment management unit 17 shows the pair of the candidate customer name and the corporate number to the user 2 so as to be selectable, and creates the second correspondence 92 according to the selection by the user 2. The candidate customer name is, for example, a similar character string, and may be, for example, a character string in which some characters are replaced with other characters.

(Payment management method)
Next, the overall outline of the payment management method will be described. FIG. 6 is a flow chart illustrating a payment management method executed by the payment management unit 17 of FIG. The order of the steps is not limited to the order of the present embodiment, and other steps may be added, some steps may be omitted, and a plurality of steps are arranged in parallel as long as there is no contradiction. One or more steps may be repeated, and some steps may start and end independently of the start and end of other steps.

For example, the payment management unit 17 displays to the user 2 via the user device 4 that executes the browser program by providing a website for payment management, and the user device 4 that executes the browser program. Receives input from user 2 via.

First, the user setting step is executed in step 30. The payment management unit 17 causes the user 2 to select at least a shared user or a non-shared user in the user setting process. The shared user is the user 2 who shares the shared learning history 14. The non-shared user is the user 2 who does not share the shared learning history 14. The payment management unit 17 displays, for example, a selection screen on the user device 4 so that it can be set, and receives the selection by the user 2. In the example of FIG. 1, US1 company and US2 company have been selected to be shared users, and US3 company has been selected to be a non-shared user.

Next, the billing data acquisition step is executed in step 31. In the billing data acquisition process, the payment management unit 17 acquires one or more billing data from the user device 4 or from the external system 6 (for example, a cloud-type accounting processing device) used by the user 2. Billing data may be acquired by other methods. Items of billing data include, for example, corporate number, customer name, billing classification, positive / negative of billing balance, absolute value of billing balance (planned payment amount), scheduled payment date, billing date, billing destination code (customer code). ), And the due date cash schedule flag, which may be more or less. The invoice issuance destination code is a code given by the user 2 for each invoice issuance destination.

Next, the billing data setting step is executed in step 32. In the billing data setting process, the payment management unit 17 displays the billing data setting table 41 shown in FIG. 7 on the user device 4 so that it can be set, and receives the setting based on the operation of the user 2 from the user device 4. The billing data setting table 41 includes columns for "order", "use", and "items of billing data". The "order" numerically indicates the priority when each item of the "billing data item" is used for associating the billing data with the deposit data in the batch application process and the individual application process described later. "Use" indicates whether each of the "billing data items" is used for association ("○") or not ("x"). The setting contents of FIG. 7 are examples. Different settings may be made between the batch application process and the individual application process.

Next, the deposit data acquisition step is executed in step 33. In the payment data acquisition process, the payment management unit 17 acquires one or more payment data from the user device 4 or from the banking system 5 operated by the bank used by the user 2. The deposit data may be acquired by other methods. Items of deposit data include, for example, offset data, positive / negative of deposit balance, deposit date, transfer requester name (invoice issuance destination katakana name), destination bank, destination branch, absolute value of deposit balance, and deposit classification. , More or less than this.

The name of the transfer requester is the katakana notation of the person who made the transfer. The deposit data may include a fee burden. The fee burden indicates whether the transfer fee is borne by the "company" or the "counterparty". The "company" is the user 2 who is the claimant. The "counterparty" is the billing address of user 2, that is, the depositor.

Next, in step 34, the deposit data setting step is executed. In the payment data setting process, the payment management unit 17 causes the user device 4 to display the payment data setting table 42 shown in FIG. 8 so that it can be set, and receives the setting by the user 2 from the user device 4. The deposit data setting table 42 includes columns for "order", "use", and "items for deposit data". The "order" numerically indicates the priority when each item of the "payment data item" is used for associating the billing data with the payment data in the batch application process and the individual application process described later. "Use" indicates whether each of the "payment data items" is used for association ("○") or not ("x"). The setting contents of FIG. 8 are examples. Different settings may be made between the batch application process and the individual application process.

Next, in step 35, the batch application step described later is executed. In the batch clearing process, the billing data is automatically cleared. Next, in step 36, the individual application step described later is executed. In the individual clearing process, the billing data is cleared based on a manual operation. At least one of the batch application process for the shared user and the individual application process for the shared user performs the application based on the billing data, the deposit data, and the user learning history 15 that can be updated based on the shared learning history 14. including.

Next, in step 37, the above-mentioned first user-specific update step is executed. In the first user-specific update step, the first correspondence 91 is stored in the user learning history 15 shown in FIG. 2 based on the application information related to the applied application.

Next, in step 38, the above-mentioned shared update step is executed. In the shared update process, the shared learning history 14 is updated based on the application information related to the application performed on the shared user.

Next, in step 39, the comprehensive learning history update step described later is executed.

(Batch application process)
FIG. 9 is a flow chart of a batch application process executed by the payment management unit 17 of FIG. The batch application process will be described with reference to FIG.

First, in step 51, the settlement management unit 17 executes a collation order setting step. The payment management unit 17 displays the collation setting table 43 shown in FIG. 10 on the user device 4 so that it can be set, and receives the setting based on the operation of the user 2 from the user device 4. The collation setting table 43 includes columns for "order", "use", and "collation logic". The "order" numerically indicates the priority when used for associating the billing data with the deposit data for each of the "collation logics". "Use" indicates whether it is used for mapping ("○") or not ("x") for each of the "collation logics". The setting contents of FIG. 10 are examples.

The collation logic represents how the batch collation process is performed. In the exemplary collation order setting table 43 of FIG. 10, as the collation logic, "number collation", "dedicated deposit account collation" for collating the dedicated deposit account, "customer code collation" for collating the invoice issuance destination code, Includes "learning history collation" to collate the total learning history and "master kana name collation" to collate the billing destination kana name. The dedicated deposit account is an account assigned to each invoice issuer. The user 2 can improve the efficiency and accuracy of the collation process in the batch collation process by changing the order of the collation logic and appropriately selecting whether or not to use the collation logic.

Next, the settlement management unit 17 executes the collation logic (FIG. 10) in step 52. In one example, when the user 2 is a shared user, the payment management unit 17 may execute the above-mentioned shared extraction step. In the shared extraction process, one or more billing candidates used to clear shared users with reference to the user learning history 15 (FIG. 2) that can be updated based on the shared learning history 14 (FIG. 3). The data and one or more deposit data are extracted to create one or more candidate correspondence sets.

In one example, when the user 2 is a non-shared user, the payment management unit 17 may execute the above-mentioned user-specific extraction step. In the user-specific extraction process, one or more candidates used for clearing non-shared users by referring to the user learning history 15 (FIG. 2) that cannot be updated based on the shared learning history 14 (FIG. 3). Billing data and one or more deposit data are extracted to create one or more candidate correspondence sets.

The collation logic (FIG. 10) may be executed by appropriately using the candidate correspondence set. At the end of step 52, one or more correspondence sets with one or more billing data and one or more deposit data associated with or without the candidate correspondence set are created. There is.

For example, from the candidate correspondence sets, a combination in which the total amount of billing data and the total amount of deposit data match or are close to each other is selected to create a correspondence set.

Next, in step 53, the batch application execution step is executed. The settlement management unit 17 clears the corresponding set in the batch clearing execution process. When application is performed, the application balance is calculated by subtracting the total deposit amount from the total billing amount in each corresponding set. The total billing amount is the total amount of the billing amount (calculated from the absolute value of the billing balance and the positive / negative of the billing balance) of the billing data of each set. The total deposit amount is the total amount of the deposit amount of the deposit data of each set (calculated from the absolute value of the deposit balance and the positive / negative of the deposit balance). Billing data, deposit data, or other data is updated as appropriate based on the clearing balance.

In the batch clearing execution process, error adjustment is performed. In the error adjustment, if the fee burden is in-house and the clearing balance is within the preset fee error amount, the settlement management unit 17 processes the clearing balance as a "fee" and the total billing amount. Is considered to be the same as the total deposit amount, and the unpaid amount is set to "0". In the error adjustment, if the application balance is within the preset consumption tax error amount, the settlement management unit 17 processes the application balance as "consumption tax error", and the total billing amount is the same as the total deposit amount. And set the unpaid amount to "0".

Next, in step 54, the result display step is executed. The settlement management unit 17 causes the user device 4 (FIG. 1) to display the application result in the result display process. The application result is displayed as, for example, the application result table 44 shown in FIG. The "item number" is a number that identifies the corresponding set that has been cleared. The "customer name" and "total billing amount" are displayed in relation to the billing data. "Transfer requester name", "total deposit amount", and "commission burden" are displayed in relation to the deposit data. "Remaining consumption" is displayed for each item number.

The application result will be described with reference to the exemplary application result table 44 of FIG. In item number "1", the billing data of the customer name "A Co., Ltd." and the total billing amount "279,000", the transfer requester name "A", the total deposit amount "200,000", and the fee burden " It is shown that the deposit data of "the other party" is associated with it, and it is shown that the remaining amount of application is "79,000". The settlement management unit 17 specifies the application balance "79,000" as the unpaid amount, and sets the item number "1" as the application incomplete.

In item number "2", the billing data of the customer name "B Co., Ltd." and the total billing amount "2,685,000", the transfer requester name "B", the total deposit amount "2,530,000", It is shown that the payment data of the fee burden "destination" is associated with the payment data, and the remaining amount of application is "155,000". The settlement management unit 17 specifies the remaining amount of application "155,000" as the unpaid amount, and sets the item number "2" as the incomplete application.

In item number "3", the billing data of the customer name "C Co., Ltd." and the total billing amount "10,500", the transfer requester name "C", the total deposit amount "9,975", and the fee burden " It is shown that it is associated with the deposit data of "own company", and it is shown that the application balance is "525". The settlement management unit 17 specifies the remaining amount of application "525" as the "unpaid amount", and sets the item number "3" as the incomplete application. In one example, if the remaining amount of application "525" is less than or equal to the preset fee error amount, the settlement management unit 17 specifies that the unpaid amount is "0" for item number "3", and item number "3". Is completed.

In item number "4", the billing data of the customer name "D Co., Ltd." and the total billing amount "31,500", the transfer requester name "D", the total deposit amount "31,500", and the fee burden " It is shown that the deposit data of "the other party" is associated with it, and it is shown that the application balance is "0". Since the remaining amount of application is "0", the settlement management unit 17 sets the unpaid amount as "0" and specifies that the item number "4" is completed.

In item number "5", the billing data of the customer name "E Co., Ltd." and the total billing amount "23,372", the transfer requester name "E", the total deposit amount "23,371", and the fee burden " It is shown that the deposit data of "the other party" is associated with it, and it is shown that the application balance is "1". The settlement management unit 17 identifies the remaining amount of application "1" as the unpaid amount, and sets the item number "5" as the incomplete application. In one example, if the remaining amount of application "1" is less than or equal to the preset consumption tax error amount, the settlement management unit 17 specifies that the unpaid amount is "0" for item number "3", and item number "3". Is completed.

In item number "6", the billing data of the customer name "F Co., Ltd." and the total billing amount "232,000", the transfer requester name "F", the total deposit amount "234,280", and the fee burden " It is shown that the deposit data of "the other party" is associated with it, and it is shown that the remaining amount of application is "-2,280". Since the total payment amount is "2,280" larger than the total billing amount, the settlement management unit 17 specifies the item number "6" as being overpaid. The payment management unit 17 specifies "2,280" as an overpayment, and indicates to the user 2 that there is an overpayment, for example, by prefixing it with a code "-". The settlement management unit 17 sets item number "6" to be incomplete.

In one example, for item number "6", the settlement management unit 17 processes the overpayment "2,280" as an advance payment. When the deposit amount of the deposit data of item number "6" is regarded as the advance payment and the next payment management method is executed, the deposit data of item number "6" will be changed to another billing data by referring to the advance payment information. Be associated.

(Individual application process)
The individual application process executed by the payment management unit 17 will be described. In the individual clearing process, the user 2 is cleared and cleared by manually accepting various operations for one or a plurality of corresponding sets whose clearing is not completed in the batch clearing execution process. Let them choose whether or not to complete. The individual consumption step includes an individual error adjustment step and a simulation step.

First, the individual error adjustment process will be described. In the individual error adjustment step, the settlement management unit 17 causes the user device 4 to display the selection table 64 illustrated in FIG. 12 for the corresponding set in which the application is not completed in FIG. The selection table 64 displays the details of the corresponding set for which the application has not been completed, and lists one or more billing data and one or more deposit data. In the example of FIG. 12, "item number", "customer name", "billing date", "scheduled payment date", and "billing amount" that identify the billing data in relation to the billing data are displayed. The "transfer requester name", "payment date", and "payment amount" are displayed in relation to the payment data.

FIG. 12 illustrates a selection table 64 related to item number “3” of FIG. 11 in which the application is not completed. As shown in FIG. 12, the billing data of item number “3” in FIG. 11 is composed of three billing data of billing amounts “5,500”, “3,000”, and “2,000”. The deposit data of item number “3” in FIG. 11 is composed of one deposit data of the deposit amount “9,975”. There is a difference "525" between the total billing amount "10,500" and the total deposit amount "9,975".

When it is determined in the batch application process that the difference "525" of the item number "3" in FIG. 11 exceeds the fee error amount, or when the error adjustment is not performed in the batch application process, FIG. 11 shows. Item number "3" is incomplete. When the item number "3" in FIG. 11 is incomplete, the settlement management unit 17 automatically presents the difference as a "commission" to the user 2 in the individual error adjustment process as shown in FIG. Let them select whether or not to complete the application by performing the application. In one example, the payment management unit 17 causes the user 2 to select whether or not the difference is a "commission", and then select whether or not the application can be completed by performing the application, and processing is performed based on the selection. ..

In the corresponding set of item number “5” in FIG. 11, the application is not completed and there is an unpaid amount “1” equal to the application balance “1”. In the individual error adjustment process, the settlement management unit 17 automatically presents the difference as a "consumption tax error" to the user 2 and causes the user to select whether or not to complete the application by performing the application. In one example, the payment management unit 17 causes the user 2 to select whether or not the difference is a "consumption tax error", and then select whether or not the application can be completed by performing the application, and processing based on the selection. do.

In one example, the settlement management unit 17 extracts billing data candidates and deposit data candidates in the individual error adjustment process. Candidate extraction for shared users is performed by the shared extraction step described above. Extraction of candidates for non-shared users is executed by the user-specific extraction process described above. The payment management unit 17 causes the user device 4 to display the extracted candidates in a selectable manner. The extracted candidates are displayed, for example, on the candidate screen 61 illustrated in FIG. The candidate screen 61 includes a billing data candidate table 62 and a deposit data candidate table 63. The presentation form of the candidate and the items to be presented are not limited to those shown in FIG.

In the example of FIG. 13, the billing data related to the customer name “A Co., Ltd.” of the corporate number “0000000000001” and the billing data identification information is “X1”, “X2”, and “X3”. Displayed with the billed amount. In the example of FIG. 13, the deposit data identification information “Y1”, the transfer requester name “A”, the deposit amount “1,000”, the deposit data identification information “Y2”, the transfer requester name “Ka) A”, The deposit data of the deposit amount "1,800,000", the deposit data identification information "Y3", the transfer requester name "Kabushiki Gaishae", and the deposit data of the deposit amount "400,000" are displayed.

The payment management unit 17 enables the user 2 to manually associate and select the billing data and the deposit data for application. The payment management unit 17 modifies (for example, adds, deletes, or replaces) the billing data and the deposit data displayed in FIG. 12 based on the operation of the user 2. The settlement management unit 17 causes the user 2 to select whether or not the corrected billing data and the payment data can be applied and the application is completed, and the processing is performed based on the selection.

By the error adjustment of the batch application process or the individual error adjustment process of the individual application process, it is possible to prevent the amount corresponding to the fee error and the consumption tax error from remaining as an unpaid amount. Further, even if the calculation method of the consumption tax differs between the company and the invoicing destination, it is possible to prevent the amount corresponding to the consumption tax error from remaining as an unpaid amount.

Next, the simulation process will be described. In the simulation process, the payment management unit 17 causes the user device 4 to display the simulation table 65 illustrated in FIG. 14 for the corresponding set in which the application is not completed in FIG. The simulation table 65 displays the details of the corresponding set for which the application has not been completed, and lists one or more billing data and one or more deposit data. In the example of FIG. 14, “item number”, “customer name”, “billing date”, “scheduled payment date”, and “billing amount” that identify the billing data in relation to the billing data are displayed. The "transfer requester name", "payment date", and "payment amount" are displayed in relation to the payment data.

FIG. 14 shows a simulation table 65 related to item number “2” of FIG. 11 in which the application is not completed. As shown in FIG. 14, the billing data of item number “2” in FIG. 11 includes billing amounts “1,000,000”, “637,000”, “500,000”, “393,000”, and “ It is composed of five billing data of "155,000". The deposit data of item number “2” in FIG. 11 is composed of one deposit data of the deposit amount “2,530,000”. There is a difference "155,000" between the total billing amount "2,685,000" and the total deposit amount "2,530,000".

In one example, the settlement management unit 17 extracts candidates for billing data and deposit data in the simulation process as in the individual error adjustment process. The payment management unit 17 displays the extracted candidates on the user device 4 so as to be selectable, and corrects the billing data and the deposit data displayed in FIG. 14 (for example, addition, deletion, or) based on the operation of the user 2. Replace. For example, user 2 modifies the difference so that it becomes "0". In one example, if the difference does not become "0", it may be processed as if the user 2 made a deposit to compensate for the difference. The settlement management unit 17 causes the user 2 to select whether or not the corrected billing data and the payment data can be applied and the application is completed, and the processing is performed based on the selection.

(Comprehensive learning history update process)
Next, the comprehensive learning history update process will be described. The payment management unit 17 learns the pattern in which the application is performed in the individual application process and stores it as the comprehensive learning history 16 (FIG. 1). The settlement management unit 17 makes a comprehensive learning history 16 (FIG. 1) the correspondence relationship between at least a part of the billing data and at least a part of the deposit data constituting the correspondence set that was cleared in the individual clearing process. Remember. For example, the combination of billing data and deposit data shown in the selection table 64 of FIG. 12 is stored.

An example of using the comprehensive learning history 16 (FIG. 1) will be described. When it is selected in step 51 of FIG. 9 that the “learning history collation” of FIG. 10 is used, the overall learning history 16 (FIG. 1) is referenced in steps 55 and 56 of FIG. A collation set similar to that illustrated in 11 is created. For example, the settlement management unit 17 automatically discovers the same or similar correspondence set as the correspondence set stored in the comprehensive learning history 16 (FIG. 1) from the input billing data and payment data. The settlement management unit 17 may automatically perform the same process as the individual clearing process performed in the past.

(Modification example)
Next, a modified example will be described. Hereinafter, the differences between the above-described embodiment and the modified examples will be mainly described. In the modified example, a part of the storage contents of the storage device 11 of FIG. 1 is different. Specifically, as shown in FIG. 15, the storage device 11 in the modified example stores a user learning history 18 different from the user learning history 15 in FIG. As shown in FIG. 15, the storage device 11 of the modified example has a third correspondence relationship shown in FIG. 15 in place of or additionally of the first correspondence relationship 91 and the second correspondence relationship 92 shown in FIG. 94 is stored. The third correspondence relationship 94 directly represents the correspondence between the corporate number involved in the application and the name of the transfer requester. The exemplary third correspondence 94 of FIG. 15 is the same as the correspondence derived from the first correspondence 91 and the second correspondence 92 of FIG.

FIG. 16 is a flow chart of a payment management method in the same modified example. Steps 70 to 79 are substantially the same steps as steps 30 to 39 of FIG. 5 except for the following points. In the payment management method of the modified example, the second user-specific update step in step 77 of FIG. 16 is executed instead of the first user-specific update step in step 37 of FIG. In the second user-specific update process, the third correspondence relationship 94 is stored in the non-shared user learning history 15 prepared for each user 2 based on the corporate number corresponding to the billing data.

The shared update step in step 78 of the modified example includes updating the shared learning history 14 by storing the third correspondence 94 in the user learning history 15 of the shared user in the shared learning history 14. In the payment management method for non-shared users, billing data and deposit data are extracted by referring to the third correspondence relationship 94 in FIG. 15 instead of the first correspondence relation 91 and the second correspondence relation 92 in FIG. Will be done.

(Summary)
According to the present embodiment, since a plurality of shared users can perform the application using the user learning history 15 that can be updated based on the shared learning history 14 learned by the application of other shared users. Compared to the case where each user 2 uses only the user learning history 15 independently learned, the application can be performed efficiently by using the corporate number and the transfer requester's name, and the learning speed is further increased. be able to. Since the shared learning history 14 is updated based on the unique corporate number, it is easier to clearly identify the transfer requester name as compared with the case where the identification information unique to each user 2 is used. Further, when the number of newly shared users increases, it is possible to efficiently delete from the initial stage by using the shared learning history 14 even if the user learning history 15 independently learned does not exist. As a result, the billing data and the deposit data corresponding to the same billing destination can be easily extracted and the application can be smoothly performed.

According to the present embodiment, since the correspondence between the corporate number stored in the shared learning history 14 and the transfer requester's name is used, as compared with the case where each user 2 uses only the user learning history 15 independently learned. , Billing data and deposit data can be efficiently extracted. Even if the payment data has different transfer requester names, it can be known that they are the same person if the corporate number is common, so that the billing data and the payment data that are candidates for application can be extracted with high accuracy.

According to the present embodiment, each user 2 can manage the individual user learning history 15 without sharing the first correspondence relationship 91 representing the correspondence between the customer name and the transfer requester name, and is also good at it. It is possible to manage the second correspondence relationship 92, which represents the correspondence between the destination name and the corporate number, without sharing. Further, since the shared learning history 14 is updated based on the first correspondence 91 and the second correspondence 92 of the user learning history 15 of the plurality of shared users, the shared learning history 14 can be used. The user can perform the application more efficiently than the case where only his / her own user learning history 15 is used.

According to the present embodiment, the corporate number can be obtained based on the customer name and the second correspondence 92 can be easily created. Therefore, for example, it is possible to easily associate the corporate number with the billing destination of the billing data for which the customer name is known, and to correct the corporate number of the billing data for which the customer name is known.

According to the present embodiment, since the user 2 can manually associate the billing data and the deposit data extracted based on the user learning history 15 that can be updated based on the shared learning history 14, only the user learning history 15 Compared to the case where is used, excess or deficiency of extraction is less likely to occur, and billing data and deposit data can be associated with each other with high accuracy.

According to the present embodiment, it is possible to select whether the user 2 becomes a shared user or a non-shared user, and since the shared learning history 14 is not updated when the user 2 becomes a non-shared user, the security management option of the user 2 is selected. spread.

According to the modification of the present embodiment, each user 2 can manage the individual user learning history 15 without sharing the third correspondence relationship 94 representing the correspondence between the corporate number and the transfer requester's name. Further, since the shared learning history 14 is updated based on the third correspondence 94 of the user learning history 15 of the plurality of shared users, the shared user who can use the shared learning history 14 has his / her own user learning history. It is possible to perform the application more efficiently than when only 15 is used.

The present invention is not limited to the embodiments described above. That is, one of ordinary skill in the art may make various changes, combinations, sub-combinations, and alternatives with respect to the components of the above-described embodiments within the technical scope of the present invention or the equivalent thereof.

The present invention is applicable to various payment management methods and payment management programs for managing payments.

1 ... payment management system, 2 ... user, 3 ... network, 4 ... user device,
5 ... Banking system, 6 ... External system, 7 ... Corporate number providing device, 8 ... Corporate number storage device,
10 ... communication device, 11 ... storage device, 12 ... processor, 13 ... payment management program,
14 ... shared learning history, 15 ... user learning history, 16 ... comprehensive learning history,
17 ... Payment management department, 18 ... User learning history, 19 ... Corporate number data,
41 ... Billing data setting table, 42 ... Deposit data setting table, 43 ... Collation setting table,
44 ... Application result table, 61 ... Candidate screen, 62 ... Billing data candidate table,
63 ... Deposit data candidate table, 64 ... Selection table, 65 ... Simulation table,
91 ... 1st correspondence, 92 ... 2nd correspondence, 93 ... shared correspondence,
94 ... Third correspondence

Claims (8)

A billing application method performed by a computer to manage payments for multiple users.
The bill application method is
A billing data acquisition process for acquiring one or more billing data,
A deposit data acquisition process that acquires one or more deposit data including the name of the transfer requester, and
A batch application process that automatically applies the billing data, and
An individual clearing process that clears the billing data based on manual operation,
A shared update process for updating the shared learning history based on the application information related to the application performed on the shared user who shares the shared learning history among the users.
To enable the user to update the non-shared user learning history prepared for each user based on the shared learning history.
Including
The application information includes the corporate number corresponding to the billing destination of the billing data and the transfer requester's name.
The corporate number is unique identification information assigned to each of the plurality of corporations.
At least one of the batch application process for the shared user and the individual application process for the shared user is based on the billing data, the payment data, and the user learning history that can be updated based on the shared learning history. Including performing the above application,
Billing application method. The shared learning history is updated by storing the shared correspondence relationship representing the correspondence between the corporate number involved in the application and the transfer requester's name in the shared learning history. Including
The user learning history and the billing data that can be updated based on the shared correspondence relationship in the shared learning history by at least one of the batch application process for the shared user and the individual application process for the shared user. A shared extraction step of extracting the billing data and the deposit data as candidates to be used for the application based on the corporation number corresponding to the billing destination and the transfer requester name of the deposit data is included.
The claim application method according to claim 1. The billing clearing method, based on the customer name that represents the billing that corresponds to said billing data includes a first user update step of storing a first corresponding relationship to the user learning history,
The first correspondence represents the correspondence between the customer name and the transfer requester name involved in the application performed.
A second correspondence relationship representing the correspondence between the customer name and the corporation number is included in the user learning history.
The shared learning step stores the shared correspondence in the shared learning history based on the first correspondence and the second correspondence in the user learning history of the shared user. Including updating history,
The claim application method according to claim 2. The billing application method includes a corporate number setting step of creating a second correspondence by associating the customer name with the corporate number based on the input by the user.
The corporation number setting process includes obtaining the corporation number corresponding to the name of the corporation represented by the customer name by referring to the corporation number data storing the corporation number corresponding to the name of the corporation. ,
The claim application method according to claim 3. The billing clearing method, based on the corporation number corresponding to said billing data includes a second user updating step of storing the third correspondence to the user learning history,
The third correspondence represents the correspondence between the corporate number involved in the application and the transfer requester's name.
The shared update step includes updating the shared learning history by storing the third correspondence in the user learning history of the shared user in the shared learning history.
The claim application method according to claim 2. The individual application process for the shared user
Displaying the billing data and the deposit data extracted based on the user learning history in the shared extraction step.
Making it possible to manually associate the displayed billing data with the deposit data for the application, and
including,
The claim application method according to any one of claims 2 to 5. The billing application method includes a user setting step of selecting at least the shared user or a non-shared user who does not share the shared learning history for a plurality of the users.
The batch application process for the non-shared user and the individual application process for the non-shared user include a user-specific extraction process.
The user-specific extraction step extracts the billing data and the deposit data as candidates to be used for the application based on the user learning history that cannot be updated based on the shared learning history.
The billing application method does not update the shared learning history based on the application information related to the application performed on the non-shared user.
The claim application method according to any one of claims 1 to 6. Billing clearing program for executing billing clearing method according to the computer in any one of claims 1 to 7.

Images