JP7525530B2 - Credit claim transfer system, credit claim transfer method, and credit claim transfer program - Google Patents

Description

The present invention relates to a credit claim transfer system, a credit claim transfer method, and a credit claim transfer program.

For example, in a company with multiple stores, the denominations of in-store sales are diverse, including credit cards and electronic money in addition to cash. If the headquarters cannot link denomination information with the store's POS sales data, staff will have to manually transfer sales by denomination at the time of closing. For example, Patent Document 1 is a conventional system for managing credit receivables.

JP 2015-121997 A

However, Patent Document 1 does not mention anything about reducing the workload of staff who transfer sales by denomination when denomination information cannot be linked to the store's POS sales data.

The present invention has been made in consideration of the above, and aims to provide a credit receivable transfer system, a credit receivable transfer method, and a credit receivable transfer program that can reduce the workload of a person in charge of transferring sales by denomination when denomination information cannot be linked to the sales data of a store's POS.

In order to solve the above-mentioned problems and achieve the object, the present invention provides a credit receivable transfer system equipped with a control unit, the control unit being configured to be able to access a terminal identification number conversion master in which the terminal identification number of a payment terminal is associated with store identification information (store code and/or store name) and registered, and a credit company conversion master in which the sales company code is associated with billing identification information (billing code and/or billing name) and registered, and a sales import means for importing sales data including the sales month, store identification information, sales amount, consumption tax, and total amount from the POS of each store, and a sales import means for tallying up the actual payments made at the payment terminal of each store. The system is characterized by comprising a credit credit inquiry means for acquiring credit credit inquiry data including the transaction date, the terminal identification number of the settlement terminal, the card identification information, the sales company code, and the amount used from the credit credit inquiry system, and a transfer means for converting the terminal identification number to store identification information by referring to the terminal identification number conversion master based on the credit credit inquiry data, converting the sales company code to billing identification information by referring to the credit company conversion master, and generating transfer data including the sales month, store identification information, billing identification information, card identification information, sales amount, and an accrual category that specifies the transfer or fee.

Furthermore, according to one aspect of the present invention, the transfer data may be recorded with a negative fee amount if the accrual category is a fee.

In accordance with one aspect of the present invention, the control unit is further configured to be able to access a fee master in which a fee rate is associated with each billing identification information and card identification information, and the transfer means may obtain the fee rate from the fee master using the billing identification information and card identification information as keys, and calculate the fee amount by multiplying the sales amount by the obtained fee rate.

According to one aspect of the present invention, the control unit is further configured to be able to access a commission upper and lower limit master in which the commission upper limit sales amount, the commission upper limit amount, the commission lower limit sales amount, and the commission lower limit amount are registered in association with each billing destination identification information and card identification information, and the transfer means uses the billing destination identification information and the card identification information as keys to obtain the commission upper limit sales amount, the commission upper limit amount, the commission lower limit sales amount, and the commission lower limit amount from the commission upper and lower limit master, and if the sales amount is equal to or greater than the commission upper limit sales amount, the commission amount = the commission upper limit amount, if the sales amount is equal to or less than the commission lower limit sales amount, the commission amount = the commission lower limit amount, if the commission amount is equal to or greater than the commission upper limit amount, the commission amount = the commission upper limit amount, and if the commission amount is equal to or less than the commission lower limit amount, the commission amount = the commission lower limit amount.

According to one aspect of the present invention, the control unit may further include a non-cash claims management means for consolidating the transfer data by billing recipient and generating non-cash claims data including billing recipient identification information and claim amount.

According to one aspect of the present invention, the control unit may further include a deposit reconciliation processing means for reconciling the non-cash receivable data when a deposit is received from the billing destination.

According to one aspect of the present invention, the payment media of the payment terminal may include credit cards, transportation IC cards, and electronic money.

According to one aspect of the present invention, the store may include a store of a company that operates multiple stores.

In order to solve the above-mentioned problems and achieve the object, the present invention provides a credit receivable transfer method executed by an information processing device having a control unit, the control unit being configured to be able to access a terminal identification number conversion master in which a terminal identification number is associated with store identification information and registered, and a credit company conversion master in which a sales company code is associated with billing identification information and registered, and a sales import process executed by the control unit imports sales data including the sales month, store identification information, sales amount, consumption tax, and total amount from the POS of each store, and a credit transaction process tallying up the actual settlement results at the settlement terminal of each store. The method includes a credit claim inquiry process for acquiring credit claim inquiry data including the transaction date, the terminal identification number of the payment terminal, the card identification information, the sales company code, and the amount used from the credit claim inquiry system, and a transfer process for converting the terminal identification number to store identification information by referring to the terminal identification number conversion master based on the credit claim inquiry data, and converting the sales company code to billing identification information by referring to the credit company conversion master, and generating transfer data including the sales month, store identification information, billing identification information, card identification information, amount, and an accrual category that specifies the transfer or fee.

In order to solve the above-mentioned problems and achieve the object, the present invention provides a credit receivable transfer program to be executed by an information processing device having a control unit, the control unit being configured to be able to access a terminal identification number conversion master in which a terminal identification number is associated with store identification information and registered, and a credit company conversion master in which a sales company code is associated with billing identification information and registered, and the control unit includes a sales import process for importing sales data including the sales month, store identification information, sales amount, consumption tax, and total amount from the POS of each store, and a credit receivable inquiry system for aggregating the actual settlement results at the settlement terminal of each store. The credit claim transfer program is characterized by executing a credit claim inquiry process for acquiring credit claim inquiry data including a transaction date, a terminal identification number of a payment terminal, card identification information, a sales company code, and a usage amount, and a transfer process for converting the terminal identification number to store identification information by referring to the terminal identification number conversion master based on the credit claim inquiry data, and converting the sales company code to billing identification information by referring to the credit company conversion master, and generating transfer data including a sales month, store identification information, billing identification information, card identification information, amount, and an accrual category that specifies a transfer or fee.

The present invention has the effect of reducing the workload of a person in charge of transferring sales by denomination when denomination information cannot be linked to the sales data of a store's POS.

FIG. 1 is a diagram for explaining a processing image of a credit claim transfer system according to the present invention. FIG. 2 is a block diagram showing an example of the configuration of a credit claim transfer system according to this embodiment. FIG. 3 is a diagram showing an example of the configuration of the terminal identification number conversion master. FIG. 4 is a diagram showing an example of the configuration of the credit company conversion master. FIG. 5 is a diagram showing an example of the configuration of the credit fee master. FIG. 6 is a diagram showing an example of the configuration of the credit fee upper and lower limit master. FIG. 7 is a diagram showing a flow for explaining an outline of the overall processing of the control unit of the credit claim transfer system according to this embodiment. FIG. 8 is a diagram for explaining a specific example of the process of the control unit of the credit claim transfer system according to the present embodiment. FIG. 9 is a diagram for explaining a specific example of the process of the control unit of the credit claim transfer system according to the present embodiment. FIG. 10 is a diagram for explaining a specific example of the process of the control unit of the credit claim transfer system according to the present embodiment.

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

[1. Overview]
For example, in a company with multiple stores, the denominations of in-store sales are diverse, including credit cards and electronic money in addition to cash. If the headquarters cannot link denomination information from the store's POS sales data, staff will have to manually transfer sales by denomination at the time of closing. The only way to link non-cash information from the POS is to revise the in-store system, which is costly when there are many stores. On the other hand, with the recent trend toward cashless transactions, the number of denominations that need to be managed is increasing.

Therefore, even if the breakdown of non-cash denominations cannot be obtained from the store's POS sales data, the present invention reduces the workload and operational errors of staff by obtaining detailed data of non-cash denominations after closing and using the master data to perform automatic transfer processing.

Figure 1 is a diagram for explaining the processing image of the credit receivable transfer system of the present invention. The credit receivable transfer system of the present invention uses non-cash data usage record data (credit receivable inquiry data) from the closing summary, passes it through each conversion master, and totals amounts by store, denomination, and collection schedule. When money is deposited, a fee is deducted from the credit company, so the receivable is managed after recording an estimated fee. A transfer slip is created based on the result of calculating the amount that was once recorded in the same account from store sales. The transferred receivable is cleared against the deposit. In the following explanation, all amounts are expressed in units of "yen" and the notation is omitted.

In Figure 1, a sales file is obtained from the store's POS. Here, the breakdown of denominations other than cash cannot be obtained. In this case, the accounting entry would be, for example, accounts receivable: 1,000,000 / sales: 1,000,000 (not broken down by denomination).

Credit claim inquiry data (e.g., J-manager data) is obtained from a credit claim inquiry system (e.g., J-manager) that tallys up the actual payment results at the store's payment terminal. Credit companies deposit the funds via the online banking system after deducting fees, so the credit is managed after recording an estimated fee.

In this case, the accounting entries would be, for example, accounts receivable: 400,000 / sales: 400,000 (reducing the original accounts receivable by the amount of card sales), card accounts receivable: 400,000 / card sales: 400,000 (recording card accounts receivable), credit fees: 8,800 / card accounts receivable: 8,800 (reducing card accounts receivable by the estimated fee amount).

The credit company will deduct the fee and deposit the amount via the online banking system. In this case, the accounting entry will be: Deposit: 312,000 / Card accounts receivable: 312,000.

The credit receivable transfer system of the present invention can be widely applied to a wide range of industries, such as businesses with multiple store locations.

2. Configuration
An example of the configuration of the credit claim transfer system according to this embodiment will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the configuration of the credit claim transfer system according to this embodiment.

The credit receivable transfer system 100 is a commercially available desktop personal computer. Note that the credit receivable transfer system 100 is not limited to a stationary information processing device such as a desktop personal computer, but may be a portable information processing device such as a commercially available notebook personal computer, PDA (Personal Digital Assistant), smartphone, or tablet personal computer.

The credit receivable transfer system 100 comprises a control unit 102, a communication interface unit 104, a memory unit 106, and an input/output interface unit 108. Each unit of the credit receivable transfer system 100 is connected to each other so as to be able to communicate with each other via any communication path.

The communication interface unit 104 communicatively connects the credit claim transfer system 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via the communication line. Here, the network 300 has a function of communicatively connecting the credit claim transfer system 100 to each store's POS 400..., payment terminal, credit claim inquiry system (e.g., J-manager) 500, online banking system 600, and server 200, for example the Internet or a LAN (Local Area Network).

Each store is provided with a POS 400 and a payment terminal 401 connected to the POS 400. The payment terminal 401 is, for example, a reader for making payments with payment media such as credit cards, electronic money, and transportation IC cards. The credit claim inquiry system 500 tallys up the actual payments made at the payment terminals 401... at each store, and accumulates credit claim inquiry data (for example, J-manager data) including the transaction date, the terminal identification number of the payment terminal 401..., card identification information (card identification code and/or card identification name), parent company code, and amount used.

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

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 records computer programs that work in cooperation with the OS (Operating System) to give commands to the CPU (Central Processing Unit) to perform various processes. The storage unit 106 can be, for example, a memory device such as a RAM (Random Access Memory) or a ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, or the like.

The memory unit 106 also includes a terminal identification number conversion master 106a, a credit company conversion master 106b, a credit fee master 106c, a credit fee upper/lower limit master 106d, and a data file 106e. Figure 3 is a diagram showing an example of the configuration of the terminal identification number conversion master 106a. Figure 4 is a diagram showing an example of the configuration of the credit company conversion master 106b. Figure 5 is a diagram showing an example of the configuration of the credit fee master 106c. Figure 6 is a diagram showing an example of the configuration of the credit fee upper/lower limit master 106d.

As shown in FIG. 3, the terminal identification number conversion master 106a can be configured as a table in which terminal identification numbers, store codes, and store names are associated and registered. The terminal identification number is the device number of the payment terminal 402 at the store. The store code and store name are obtained from the terminal identification number. In the example shown in FIG. 3, the first line has the terminal identification number "4816151001XXX", the store code "T100", and the store name "Asakusa store", and the second line has the terminal identification number "4816151002XXX", the store code "T200", and the store name "Kyobashi store".

As shown in FIG. 4, the credit company conversion master 106b can be configured as a table in which the sales company code (five characters from the third digit), billing name, and billing code are associated and registered. The billing destination is obtained from the sales company code (five characters from the third digit). In the example shown in FIG. 3, the first line has the sales company code "99661", the billing name "Card Company A", and the billing code "101", and the second line has the sales company code "99662", the billing name "Card Company B", and the billing code "102".

As shown in FIG. 5, the credit fee master 106c can be configured as a table in which billing codes, card identification codes, card identification names, and fee rates are associated and registered. In the example shown in FIG. 5, the first line has billing code "101", card identification code "001", card identification name "credit card", and fee rate "2.2", and the second line has billing code "102", card identifier code "001", card identification name "credit card", and fee rate "2.3".

As shown in FIG. 6, the credit fee upper and lower limit master 106d can be configured as a table in which the billing destination code, card identification code, card identification name, upper fee sales amount, upper fee amount, lower fee sales amount, and lower fee amount are associated and registered. The example shown in FIG. 6 shows an example in which the same upper fee sales amount, upper fee amount, lower fee sales amount, and lower fee amount are set regardless of the billing destination code, card identification code, and card identification name. The first line shows the billing destination code "101", card identification code "001", card identification name "credit card", upper fee sales amount "10,000", upper fee amount "250", lower fee sales amount "3,000", and lower fee amount "50".

Data file 106e is a file for storing various data such as sales data, credit claim inquiry data, transfer data, non-cash claim data, and deposit data.

Sales data may include sales month, store code, store name, sales amount, consumption tax, and total.

Credit claim inquiry data (e.g., J-manager data) may include the transaction date, terminal identification number, card identification code, sales company code, and usage amount. Non-cash usage records include only amounts including tax.

The transfer data may include the sales month, store code, store name, billing code, billing name, card identification code, card identification name, amount, and an accrual category that specifies the transfer or estimated fee. The estimated fee is deducted from the receivable, so it is recorded as a negative amount.

Non-cash receivable data may include billing code, billing name, and receivable amount. Receivables are managed by billing recipient.

Deposit data may include billing code, billing name, and deposit amount.

Returning to FIG. 2, the control unit 102 is a CPU or the like that provides overall control of the credit receivable transfer system 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, and required data, and executes various information processing operations based on these stored programs.

The control unit 102 is configured to be able to access the terminal identification number conversion master 106a, the credit company conversion master 106b, the credit fee master 106c, the upper and lower limit credit fee master 106d, and the data file 106e, which are stored in the memory unit 106. Note that these master files may be provided in other locations (e.g., the server 200) as long as they are accessible by the control unit 102.

The control unit 102, in terms of its functional concept, comprises a sales capture unit 102a, a credit claim inquiry unit 102b, a transfer processing unit 102c, a non-cash claim management unit 102d, a deposit processing unit 102e, a master maintenance unit 102f, and a screen display control unit 102g.

The sales import unit 102a imports sales data, including the sales month, store identification information, sales amount, consumption tax, and total amount, from each store's POS 400... and stores it in the data file 106e.

The credit claim inquiry unit 102b obtains credit claim inquiry data (e.g., J-manager data) including the transaction date, the terminal identification number of the payment terminal 401, the card identification information (card identification code and/or card identification name), the sales company code, and the amount used from a credit claim inquiry system (e.g., J-manager) 500 that tallys up the actual payment results at the payment terminals of each store, and stores the data in the data file 106e.

The transfer processing unit 102c converts the terminal identification number into store identification information (store code and/or store name) with reference to the terminal identification number conversion master 106a based on the credit claim inquiry data, and converts the sales company code into billing identification information (billing code and/or billing name) with reference to the credit company conversion master 106b, and generates transfer data including the sales month, store identification information, billing identification information, card identification information (card identification code and/or card identification name), amount, and an accrual category that specifies the transfer or estimated fee, and stores this in the data file 106e. If the accrual category is a fee, the transfer data may be set so that the fee amount is recorded as a negative amount (a negative amount).

The transfer processing unit 102c may use the billing identification information and card identification information as keys to obtain the commission rate from the credit commission master 106c, and calculate the commission amount by multiplying the sales amount by the obtained commission rate.

The transfer processing unit 102c also uses the billing destination identification information and card identification information as keys to obtain the upper fee sales amount, the upper fee amount, the lower fee sales amount, and the lower fee amount from the credit fee upper and lower limit master 106d, and if the sales amount is equal to or greater than the upper fee sales amount, the fee amount = the upper fee amount, if the sales amount is equal to or less than the lower fee sales amount, the fee amount = the lower fee amount, if the fee amount is equal to or greater than the upper fee amount, the fee amount = the upper fee amount, and if the fee amount is equal to or less than the lower fee amount, the fee amount = the lower fee amount.

The non-cash claims management unit 102d compiles the transfer data by billing recipient, generates non-cash claims data including billing recipient identification information and claim amount, and stores the data in data file 106e.

When the billing destination makes a deposit via the online banking system 600, the deposit processing unit 102e creates deposit data and stores it in the data file 106e. The deposit processing unit 102e also settles the deposit data against the non-cash receivables data.

The master maintenance unit 102f, for example, inputs, adds, deletes, edits, etc. data into the terminal identification number conversion master 106a, the credit company conversion master 106b, the credit fee master 106c, and the credit fee upper and lower limit master 106d in response to the operator's operations on the master maintenance screen displayed on the monitor 114.

The screen display control unit 102g controls the display and input of various screens displayed on the monitor 114.

3. Specific Examples
A specific example of the processing of the credit claim transfer system 100 in this embodiment will be described with reference to Figures 2 to 10. First, an outline of the overall processing of the credit claim transfer system 100 in this embodiment will be described with reference to Figure 7. Figure 7 is a diagram showing a flow for explaining an outline of the overall processing of the credit claim transfer system 100 in this embodiment.

(3-1. Overall processing)
7, the sales acquisition unit 102a executes a sales acquisition process (step S1). Specifically, in the sales acquisition process, the sales acquisition unit 102a acquires sales data, including sales month, store identification information, sales amount, consumption tax, and total amount, from the POS 400 of each store, and stores the data in the data file 106e.

The credit claim inquiry unit 102b executes the credit claim inquiry process (step S2). Specifically, in the credit claim inquiry process, the credit claim inquiry unit 102b acquires credit claim inquiry data, including the transaction date, the terminal identification number of the payment terminal, the card identification information, the sales company code, and the amount used, from the credit claim inquiry system 500, which compiles the actual payment results at the payment terminals 401... of each store, and stores the data in the data file 106e.

The transfer processing unit 102c executes the transfer process (step S3). Specifically, in the transfer process, the transfer processing unit 102c converts the terminal identification number into store identification information with reference to the terminal identification number conversion master 106a based on the credit claim inquiry data, converts the sales company code into billing identification information with reference to the credit company conversion master 106b, generates transfer data including the sales month, store identification information, billing identification information, card identification information, sales amount, and transfer or estimated fee generation category, and stores the data in the data file 106e.

The non-cash claims management unit 102d compiles the transfer data by billing recipient, generates non-cash claims data including billing recipient identification information and claim amount, and stores the data in data file 106e.

The deposit processing unit 102e executes the deposit reconciliation process (step S4). Specifically, in the deposit reconciliation process, when the deposit is received from the billing destination via the online banking system 600, the deposit processing unit 102e creates deposit data and reconciles the deposit data against the non-cash receivable data.

(3-2. Sample data)
8 to 10 are diagrams showing sample data for explaining a specific example of the processing of the control unit 102 of the credit claim transfer system 100 according to this embodiment. A specific example of the processing of the control unit 102 of the credit claim transfer system 100 according to this embodiment will be explained with reference to Figs. 8 to 10. In the following explanation, explanation will be given using data examples of the terminal identification number conversion master 106a in Fig. 3, the credit company conversion master 106b in Fig. 4, the credit fee master 106c in Fig. 5, and the credit fee upper and lower limit master 106d in Fig. 6.

(S1: Sales import process)
The sales import unit 102a imports sales data, including sales month, store identification information, sales amount, consumption tax, and total amount, from the POS 400 of each store, and stores the data in a data file 106e.

Figure 8 (A) shows an example of sales data. The sales data includes fields for sales month, store code, store name, sales amount, consumption tax, and total amount. In the example shown in Figure 8 (A), the first line has sales month "2021/6", store code "T100", store name "Asakusa store", sales amount "5,000,000", consumption tax "500,000", and total amount "5,500,000", while the second line has sales month "2021/6", store code "T200", store name "Kyobashi store", sales amount "6,000,000", consumption tax "600,000", and total amount "6,600,000". As such, the sales data does not include denomination information.

(S2: Credit claim inquiry process)
In the credit claim inquiry process, the credit claim inquiry unit 102b obtains credit claim inquiry data (e.g., J-manager data) including the transaction date, the terminal identification number of the payment terminal, card identification information, billing identification information, and the amount used from a credit claim inquiry system (e.g., J-manager) 500 that compiles the actual payment results at the payment terminals of each store, and stores the data in a data file 106e.

Figure 8 (B) is a diagram showing an example of credit claim inquiry data. Credit claim inquiry data includes fields for transaction date, terminal identification number, card identification code, sales company code, and usage amount. The usage amount (non-cash usage record) is the amount including tax.

In the example shown in FIG. 8(B), the first line shows the transaction date "2021/6/1", the terminal identification number "4816151001XXX", the card identification code "001", the sales company code "2'996610000", and "11,000". The second line shows the transaction date "2021/6/1", the terminal identification number "4816151002XXX", the card identification code "001", the sales company code "2'996620000", and "11,000".

(S3: Transfer process)
Based on the credit claim inquiry data, the transfer processing unit 102c refers to the terminal identification number conversion master 106a to convert the terminal identification number into store identification information, and refers to the credit company conversion master 106b to convert the sales company code into billing identification information, generates transfer data including the sales month, store identification information, billing identification information, card identification information, amount, and accrual category, and stores it in a data file 106e.

Figure 8 (C) is a diagram showing an example of transfer data. The transfer data includes items such as sales month, store code, store name, billing code, billing name, card identification code, card identification name, amount, and an accrual category that specifies the transfer or estimated fee. The estimated fee is deducted from the receivable, so it is recorded as a negative amount.

In the example shown in FIG. 8(C), the first line contains sales month "2021/6", store code "T100", store name "Asakusa store", billing code "101", billing name "Card company A", card identification code "001", card identification name "Credit card", amount "11,000", and occurrence category "Transfer". This is the result of converting the terminal identification number "4816151001XXX" to the store code "T100" and store name "Asakusa store" by referring to the terminal identification number conversion master 106a in FIG. 3 for the first line of the credit claim inquiry data, and converting the sales company code "99661" to the billing code "101" and billing name "Card company A" by referring to the credit company conversion master 106b in FIG. 4.

The seventh line has the sales month "2021/6", store code "T100", store name "Asakusa store", billing code "101", billing name "Card company A", card identification code "001", card identification name "Credit card", amount "-242", and classification "Estimated fee". The fee amount is calculated by using the billing code "101" and card identification code "001" as keys to obtain the fee rate "2.2" from the credit fee master 106c in FIG. 5, calculating the amount "11,000" x fee rate "2.2" = "242", and recording it as a negative amount, resulting in "-242".

The non-cash claims management unit 102d compiles the transfer data by billing recipient, generates non-cash claims data including billing recipient identification information and claim amount, and stores the data in data file 106e.

Figure 8 (D) is a diagram showing an example of non-cash receivable data. Non-cash receivable data includes fields for billing code, billing name, and receivable amount. Receivables are managed by billing recipient. In the example shown in Figure 8 (D), the first line contains billing code "101," billing name "Card Company A," and receivable amount "10,758."

(S4: Deposit reconciliation process)
When the deposit processing unit 102e receives a deposit from the billing destination via the Internet banking system 600, it creates deposit data and settles the deposit data against the non-cash bond data.

Figure 8 (E) is a diagram showing an example of deposit data. Deposit data may include fields for billing code, billing name, and deposit amount. In the example shown in Figure 8 (E), the first line contains the billing code "101," the billing name "Card Company A," and the deposit amount "10,758."

(Fee calculation)
In the example shown in Fig. 8(C), the transfer processing unit 102c calculates the approximate fee for the transfer data using only the credit fee master 106c, but the fee may also be calculated by referring to the credit fee upper and lower limit master 106d. In the example of the credit fee upper and lower limit master 106d shown in Fig. 6, the same upper fee sales amount, upper fee amount, lower fee sales amount, and lower fee amount are set for the billing code and the card identification code.

Figure 9 is a diagram showing an example of fee calculation. Figure 10 is a diagram showing the fee calculation flow. In Figure 10, in step S11, if corresponding data cannot be obtained from the credit fee upper/lower limit master 106d (if the data does not match the upper fee sales amount, upper fee amount, lower fee sales amount, or lower fee amount), the fee amount is calculated as follows: fee amount = sales amount (total amount) x fee rate.

In step S12, if the sales amount is equal to or greater than the upper commission sales amount, the commission amount is set to the upper commission amount. If the sales amount is less than the upper commission sales amount and greater than the lower commission sales amount, the process proceeds to S13. If the sales amount is equal to or less than the lower commission sales amount, the commission amount is set to the lower commission amount.

In step S13, if the commission amount is equal to or greater than the upper limit commission amount, the commission amount is set to the upper limit commission amount. If the commission amount is less than the upper limit commission amount and greater than the lower limit commission amount, the commission amount is set to the sales amount x commission rate. If the commission amount is equal to or less than the lower limit commission amount, the commission amount is set to the lower limit commission amount.

In the example shown in Figure 10, the total amount in the first line is "2,000", so the minimum commission amount below the minimum commission sales amount of "3,000" is fixed at "50". The calculated commission in the fourth line is "320", which exceeds the maximum commission amount of "250", so the maximum commission amount is set at "250". The commission amounts in the sixth to ninth lines are greater than the maximum commission sales amount of "10,000", so the maximum commission amount is fixed at "250". For the second, third, and fifth lines, the commission is calculated by multiplying the total amount by the commission rate.

As described above, according to this embodiment, the terminal identification number conversion master 106a in which the terminal identification number and the store identification information are associated and registered, the credit company conversion master 106b in which the sales company code and the billing destination identification information are associated and registered, the sales import unit 102a imports sales data including the sales month, store identification information, sales amount, consumption tax, and total amount from the POS 400 of each store, and the credit credit inquiry system 500 tallying up the actual settlement results at the settlement terminals 401 of each store, imports credit credit inquiry data including the transaction date, the terminal identification number of the settlement terminal, the card identification information, the sales company code, and the amount used. The system is equipped with a credit claim inquiry unit 102b that acquires the credit claim, and a transfer processing unit 102c that, based on the credit claim inquiry data, converts the terminal identification number to store identification information by referring to the terminal identification number conversion master 106a, converts the sales company code to billing identification information by referring to the credit company conversion master 106b, and generates transfer data including the sales month, store identification information, billing identification information, card identification information, sales amount, and an accrual category that specifies the transfer or fee. This makes it possible to reduce the workload of the person in charge when transferring sales by denomination when denomination information cannot be linked from the store's POS sales data.

[4. Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby making it possible to contribute to goals 8 and 9 of the SDGs.

In addition, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, which can contribute to the achievement of SDGs goals 12, 13, and 15.

In addition, this embodiment can contribute to strengthening control and governance, making it possible to contribute to Goal 16 of the SDGs.

5. Other embodiments
The present invention may be embodied in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.

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

Furthermore, with regard to the credit receivable transfer system 100, each component shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure.

For example, the processing functions of the credit receivable transfer system 100, particularly the processing functions performed by the control unit, may be realized in whole or in part by a CPU and a program interpreted and executed by the CPU, or may be realized as hardware using wired logic. The program is recorded on a non-transient computer-readable recording medium that contains programmed instructions for causing the information processing device to execute the processing described in this embodiment, and is mechanically read by the credit receivable transfer system 100 as necessary. That is, a computer program for giving instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). This computer program is executed by being loaded into RAM, and cooperates with the CPU to form the control unit.

This computer program may also be stored in an application program server connected to the credit receivable transfer system 100 via any network, and may be downloaded in whole or in part as needed.

In addition, the program for executing the processing described in this embodiment may be stored on a non-transitory computer-readable recording medium, and may also be configured as a program product. Here, the term "recording medium" refers to a memory card, a USB (Universal Serial Bus) memory, a SD (Secure Digital) card, a flexible disk, a magneto-optical disk, a ROM, an EPROM (Erasable Programmable Read Only Memory), an EEPROM (registered trademark) (Electrically Erasable and Programmable Read Only Memory), a CD-ROM (Compact Disk Read Only Memory), an MO (Magneto-Optical disk), a DVD (Digital Versatile This includes any "portable physical medium" such as a portable DVD (registered trademark) or Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. Note that a "program" is not necessarily limited to a single configuration, but also includes a distributed configuration consisting of multiple modules or libraries, and a program that works in conjunction with a separate program, such as an OS, to achieve its function. Note that the specific configuration and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known configurations and procedures.

The various databases stored in the memory unit are storage devices such as RAM, ROM, etc., fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and providing websites.

The credit receivable transfer system 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. The credit receivable transfer system 100 may also be realized by implementing software (including programs or data, etc.) that causes the device to realize the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments can be implemented in any combination, or the embodiments can be implemented selectively.

100 Credit claim transfer system 102 Control unit 102a Sales acquisition unit 102b Credit claim inquiry unit 102c Transfer processing unit 102d Non-cash claim management unit 102e Deposit processing unit 102f Master maintenance unit 102g Screen display control unit 104 Communication interface unit 106 Memory unit 106a Terminal identification number conversion master 106b Credit company conversion master 106c Credit fee master 106d Credit fee upper limit/lower limit master 106e Data file 108 Input/output interface unit 112 Input device 114 Output device 200 Server 300 Network 400 POS
401 Terminal 500 Credit claim inquiry system 600 Internet banking system

Claims (10)

A credit claim transfer system having a control unit,
The control unit is
a terminal identification number conversion master in which the terminal identification number and the store identification information are associated and registered;
A credit company conversion master in which a sales company code and billing identification information are associated and registered;
is configured to be accessible to
a sales input means for inputting sales data including sales month, store identification information, sales amount, consumption tax, and total amount from the POS of each store;
a credit claim inquiry means for acquiring credit claim inquiry data including a transaction date, a terminal identification number of a payment terminal, card identification information, a sales company code, and a credit claim amount from a credit claim inquiry system that compiles the results of payments made at the payment terminals of each store;
a transfer means for converting the terminal identification number into store identification information by referring to the terminal identification number conversion master based on the credit claim inquiry data, and converting the sales company code into billing identification information by referring to the credit company conversion master, thereby generating transfer data including a sales month, store identification information, billing identification information, card identification information, sales amount, and an accrual category that specifies a transfer or fee;
A credit claim transfer system comprising: The credit receivable transfer system of claim 1, characterized in that in the transfer data, when the accrual category is a fee, the fee amount is recorded as a negative value. The control unit further
The system is configured to be able to access a commission master in which a commission rate is associated and registered for each billing destination identification information and card identification information,
The credit receivable transfer system described in claim 1 or 2, characterized in that the transfer means obtains a commission rate from the commission master using billing identification information and card identification information as keys, and calculates the commission amount by multiplying the sales amount by the obtained commission rate. The control unit further
A commission upper and lower limit master in which a commission upper limit sales amount, a commission upper limit amount, a commission lower limit sales amount, and a commission lower limit amount are associated and registered for each billing destination identification information and card identification information is accessible;
The credit receivable transfer system described in claim 3, characterized in that the transfer means uses billing identification information and card identification information as keys to obtain the upper limit sales amount, upper limit commission amount, lower limit sales amount, and lower limit commission amount from the upper and lower limit commission master, and if the sales amount is equal to or greater than the upper limit sales amount, the commission amount = the upper limit commission amount, if the sales amount is equal to or less than the lower limit sales amount, the commission amount = the lower limit commission amount, if the commission amount is equal to or greater than the upper limit commission amount, the commission amount = the upper limit commission amount, and if the commission amount is equal to or less than the lower limit commission amount, the commission amount = the lower limit commission amount. The credit claim transfer system according to any one of claims 1 to 4, characterized in that it is provided with a non-cash claim management means for consolidating the transfer data by billing recipient and generating non-cash claim data including billing recipient identification information and claim amount. The credit receivable transfer system according to claim 5, characterized in that it is provided with a deposit reconciliation processing means for clearing the non-cash receivable data when a deposit is received from the billing destination. The credit receivable transfer system according to any one of claims 1 to 6, characterized in that the payment media of the payment terminal include credit cards, transportation IC cards, and electronic money. The credit receivable transfer system according to any one of claims 1 to 7, characterized in that the store includes a store of a company that operates multiple stores. A credit claim transfer method executed by an information processing device having a control unit,
The control unit is
a terminal identification number conversion master in which the terminal identification number and the store identification information are associated and registered;
A credit company conversion master in which a sales company code and billing identification information are associated and registered;
is configured to be accessible to
Executed in the control unit,
a sales import step of importing sales data including sales month, store identification information, sales amount, consumption tax, and total amount from the POS of each store;
a credit claim inquiry step of acquiring credit claim inquiry data including a transaction date, a terminal identification number of the payment terminal, card identification information, a sales company code, and a usage amount from a credit claim inquiry system that compiles the results of payments made at the payment terminals of each store;
a transfer process for converting the terminal identification number to store identification information by referring to the terminal identification number conversion master based on the credit claim inquiry data, and converting the sales company code to billing identification information by referring to the credit company conversion master, thereby generating transfer data including sales month, store identification information, billing identification information, card identification information, sales amount, and an accrual category specifying transfer or fee. A credit claim transfer program to be executed by an information processing device having a control unit,
The control unit is
a terminal identification number conversion master in which the terminal identification number and the store identification information are associated and registered;
A credit company conversion master in which a sales company code and billing identification information are associated and registered;
is configured to be accessible to
In the control unit,
a sales import step of importing sales data including sales month, store identification information, sales amount, consumption tax, and total amount from the POS of each store;
a credit claim inquiry step of acquiring credit claim inquiry data including a transaction date, a terminal identification number of the payment terminal, card identification information, a sales company code, and a usage amount from a credit claim inquiry system that compiles the results of payments made at the payment terminals of each store;
a transfer process for converting the terminal identification number into store identification information by referring to the terminal identification number conversion master based on the credit claim inquiry data, and converting the sales company code into billing identification information by referring to the credit company conversion master, thereby generating transfer data including a sales month, store identification information, billing identification information, card identification information, sales amount, and an accrual category that specifies a transfer or fee;
A credit receivable transfer program to carry out the above.

Images