Deposit management device, deposit management method, and deposit management program

Abstract

The challenges include improving the convenience of managing security deposits. [Solution] In this embodiment, the security deposit management device comprises an acquisition unit and a calculation unit. The acquisition unit acquires a security deposit rate according to the rate pattern for each member store. The calculation unit calculates the amount of security deposit that the member store is required to deposit with the credit company based on the security deposit rate acquired by the acquisition unit, and calculates the settlement amount for each member store based on the principal amount advanced by the credit company and the amount of the security deposit.

Description

Technical Field

[0001] The present invention relates to a margin management device, a margin management method, and a margin management program.

Background Art

[0002] Patent Document 1 discloses a system for a group such as a company or a corporation providing a guarantee service to perform a creditor's right guarantee service after concluding a comprehensive contract of transaction credit insurance with an insurance company.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In an installment contract, when a user purchases a product, a credit sales company transmits an advance payment to a franchise store. In contrast, the credit sales company may receive a margin from the franchise store. As a method for the credit sales company to receive a margin from the franchise store, there is a case where the credit sales company receives the margin in a lump sum at the time of contracting with the franchise store, and there is also a case where the franchise store deposits a margin at a predetermined rate according to the rate of the advance payment when the credit sales company makes an advance payment to the franchise store.

[0005] However, in the latter case, for example, in the form of monthly settlement, the calculation of the margin is performed outside the system collectively according to the total amount of the advance payment, and while the credit sales company pays the advance payment to the franchise store each time, there is a case where the credit sales company separately collects the margin from the franchise store. In this case, in the settlement operation, a separate operation of collecting the margin occurs, which is troublesome.

[0006] The present invention has been made in view of the above problems, and an object of the present invention is to improve the convenience of margin management. [Means for solving the problem]

[0007] To solve the above-mentioned problems and achieve the objective, the deposit management device according to the present invention is characterized by comprising: an acquisition unit that acquires a deposit rate according to the rate pattern of each member store; a calculation unit that calculates the amount of deposit that the member store is required to deposit with the credit company based on the deposit rate acquired by the acquisition unit, and calculates the settlement amount for each member store based on the principal amount advanced by the credit company and the amount of the deposit.

[0008] Furthermore, in the data management device according to the present invention, the calculation unit may calculate the settlement amount by subtracting the amount of the security deposit from the principal amount advanced.

[0009] Furthermore, in the data management device according to the present invention, the calculation unit may aggregate the amount of the principal amount advanced and the amount of the guarantee deposit within a certain period, and calculate the settlement amount for each member store within the certain period.

[0010] Furthermore, in the data management device according to the present invention, the calculation unit may calculate the cumulative amount of security deposits for each member store, calculate the amount of security deposits for each contract, and update the cumulative amount of security deposits for each member store.

[0011] Furthermore, in the data management device according to the present invention, the calculation unit may further calculate the add-on fee.

[0012] Furthermore, the deposit management method according to the present invention is characterized by including an acquisition step of obtaining a deposit rate according to the rate pattern of each member store, and a step of calculating the amount of deposit that the member store is required to deposit with the credit company based on the deposit rate, and calculating the settlement amount for each member store based on the principal amount advanced by the credit company and the amount of the deposit.

[0013] Furthermore, the deposit management program according to the present invention functions as an information processing device that acquires a deposit rate according to the rate pattern for each member store, calculates the amount of deposit that the member store is required to deposit with the credit company based on the deposit rate, and calculates the settlement amount for each member store based on the principal amount advanced by the credit company and the amount of the deposit. [Effects of the Invention]

[0014] This invention has the effect of improving the convenience of managing security deposits in the settlement process of security deposits. [Brief explanation of the drawing]

[0015] [Figure 1] Figure 1 is a block diagram showing an example of the configuration of the deposit management device according to this embodiment. [Figure 2] Figure 2 is a diagram illustrating the background according to this embodiment. [Figure 3] Figure 3 shows an example of a system in which a credit company receives a deposit from a member store. [Figure 4] Figure 4 shows an example of a settlement method for advance payments and security deposits between a credit company and a member store. [Figure 5] Figure 5 is a diagram illustrating an example of a settlement method for advance payments and security deposits between a credit company and a member store in an embodiment of the system. [Figure 6] Figure 6 is a flowchart illustrating the processing flow performed by the deposit management device according to this embodiment. [Figure 7] Figure 7 shows an example of a merchant management screen in a deposit management device according to an embodiment. [Figure 8] Figure 8 shows an example of a merchant data table in a deposit management device according to an embodiment. [Figure 9] Figure 9 shows an example of a merchant contract management screen in a deposit management device according to an embodiment. [Figure 10]FIG. 10 is a diagram showing an example of a franchise-specific rate data table in the deposit management device according to the embodiment. [Figure 11] FIG. 11 is a diagram showing an example of a customer contract data table in the deposit management device according to the embodiment. [Figure 12] FIG. 12 is a diagram for explaining the update of the franchise data table in step S400. [Figure 13] FIG. 13 is a diagram showing an example of a settlement details data table by franchise in the deposit management device according to the embodiment. [Figure 14] FIG. 14 is a diagram showing an example of a settlement table by franchise in the deposit management device according to the embodiment. Embodiments for Carrying Out the Invention

[0016] Hereinafter, embodiments of the deposit management device, deposit management method, and deposit management program according to the present invention will be described in detail based on the drawings. Note that the present invention is not limited by this embodiment.

[0017] [1. Configuration] An example of the configuration of the deposit management device 100 according to the present embodiment will be described with reference to FIG. 1 and the like. FIG. 1 is a block diagram showing an example of the configuration of the deposit management device 100.

[0018] The deposit management device 100 is constructed based on, for example, a commercially available desktop personal computer. Note that the deposit management device 100 is not limited to being constructed based on a stationary information processing device such as a desktop personal computer, and may be constructed based on a portable information processing device such as a commercially available notebook personal computer, PDA (Personal Digital Assistants), smartphone, or tablet personal computer.

[0019] The deposit management device 100 comprises a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. Each part of the deposit management device 100 is connected to communicate via any communication path.

[0020] The communication interface unit 104 connects the deposit management device 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 the function of communicating data with other devices via a communication line. Here, the network 300 has the function of connecting the deposit management device 100 and the server 200 so that they can communicate with each other, and is, for example, the internet or a LAN (Local Area Network). The data stored in the storage unit 106 may be stored in, for example, the server 200.

[0021] The input / output interface unit 108 is connected to an input device 112 and an output device 114. The output device 114 can be a monitor (including a home television), as well as a speaker or a printer. The input device 112 can be a keyboard, mouse, microphone, or a monitor that works in conjunction with the mouse to provide pointing device functionality.

[0022] The memory unit 106 stores various databases, tables, and files. The memory unit 106 also stores computer programs that work in cooperation with the OS (Operating System) to give instructions to the CPU (Central Processing Unit) to perform various processes. As the memory unit 106, for example, memory devices such as RAM (Random Access Memory) and ROM (Read Only Memory), fixed disk devices such as hard disks, flexible disks, and optical disks can be used.

[0023] The storage unit 106 stores data tables such as the merchant data table 1, the merchant-specific fee rate data table 2, the customer contract data table 3, the merchant-specific settlement details data table 4, and the merchant-specific settlement table 5.

[0024] Figure 8 shows an example of the information stored in Merchant Data Table 1. Merchant Data Table 1 is a data table for managing the basic information of each merchant. Each row in Merchant Data Table 1 holds information such as the "Merchant Code," which is a serial number assigned to each merchant; the "Merchant Name," which is the name of the merchant corresponding to the Merchant Code; the "Representative Name," which is the name of the representative of the merchant; the "Address," which is the address of the merchant; "Deposit (Manual)," which represents the deposit that the merchant deposits to the credit company and is entered manually by the user; "Cumulative Deposit Amount (Calculated)," which represents the cumulative amount of deposits that the merchant is required to deposit with the credit company and is calculated automatically; and "Deposit Refund Amount," which indicates the amount of deposit refunded when the credit company refunds the deposit to the merchant due to termination of the merchant agreement, etc. The "Cumulative Guarantee Deposit Amount (Calculation)" is, as will be explained later, the calculated cumulative amount of the guarantee period, which changes daily, in cases such as when a customer purchases goods and a credit company pays the merchant for the goods on their behalf, and the contract requires the merchant to accumulate a guarantee deposit with the credit company in proportion to the amount paid on their behalf.

[0025] Figure 10 shows an example of the information stored in the Merchant-Specific Rate Data Table 2. The Merchant-Specific Rate Data Table 2 is a data table for managing add-on fee rates, security deposit rates, etc., for each merchant. Each row in the Merchant-Specific Rate Data Table 2 holds information such as the "Merchant Code," which is a serial number assigned to each merchant; the "Rate Pattern," which shows the rate pattern for the add-on fee rate and security interest rate; the "Rate Pattern Name," which shows the name of the rate pattern; the "Add-on Fee Rate," which shows the ratio of the add-on fee, which is a fee that the credit company charges the customer (user) in addition to the amount paid by the customer in an installment contract, to the price of the goods paid by the customer; and the "Security Deposit Rate," which shows the ratio of the amount of security deposit that the merchant needs to deposit with the credit company to the principal amount advanced by the credit company on behalf of the merchant.

[0026] Figure 11 shows an example of the information stored in Customer Contract Data Table 3. Customer Contract Data Table 3 is a data table for managing contract information and related information such as security deposits for each customer (user) contract. Each row in Customer Contract Data Table 3 holds information such as "Customer" which indicates the customer's ID, "Contract Number" which is the number assigned to the contract, "Contract Date" which indicates the date the contract was concluded, "Merchant Code" which is a serial number assigned to the merchant, "Merchant Rate Pattern" which indicates the rate pattern of the add-on fee rate and the guaranteed interest rate, "Principal Amount Advanced" which is the price of goods etc. that the credit company advances to the merchant for the contract, "Add-on Fee" which is an additional fee that the credit company collects from the customer in addition to the price of the goods as a fee, and "Security Deposit" which indicates the amount of security deposit that the merchant needs to deposit with the credit company for the contract.

[0027] Figure 13 shows an example of the information stored in the Merchant-Specific Settlement Details Data Table 4. The Merchant-Specific Settlement Details Data Table 4 is a data table for managing the information that forms the basis for the credit company to settle the principal amount advanced and the security deposit with the merchant for each customer (user) contract. Each row in the Merchant-Specific Settlement Details Data Table 4 holds information such as the "Merchant Code," which is a serial number assigned to the merchant; the "Contract Number," which is a number assigned to the contract; the "Settlement Amount," which shows the total settlement amount considering the principal amount advanced by the credit company to the merchant and the security deposit that the merchant needs to deposit with the credit company for that contract; the "Principal Amount Advanced," which shows the principal amount advanced by the credit company to the merchant; and the "Security Deposit," which shows the amount of the security deposit that the merchant needs to deposit with the credit company.

[0028] Figure 14 shows an example of the information stored in the Merchant-Specific Settlement Table 5. The Merchant-Specific Settlement Table 5 is a data table for managing information on the total settlement amount for each merchant, taking into account the principal amount advanced by the credit company to the merchant and the security deposit that the merchant is required to deposit with the credit company, over a certain period. Each row in the Merchant-Specific Settlement Table 5 holds information on the "Merchant Code," which is a serial number assigned to the merchant, and the "Total Settlement Amount," which shows the total settlement amount for each merchant, taking into account the principal amount advanced by the credit company to the merchant and the security deposit that the merchant is required to deposit with the credit company, over a certain period.

[0029] Returning to Figure 1, the control unit 102 is a CPU or similar component that comprehensively controls the deposit management device 100. The control unit 102 has internal memory for storing control programs such as the OS, programs that define various processing procedures, and required data, and executes various information processing based on these stored programs.

[0030] Functionally, the control unit 102 comprises an acquisition unit 102a, a calculation unit 102b, a display control unit 102c, a generation unit 102d, and the like. The acquisition unit 102a acquires various data, such as the deposit rate according to the rate pattern for each merchant, from the storage unit 106 or from the user via the input / output interface unit 108. The calculation unit 102b calculates the amount of the deposit that the merchant is required to deposit with the credit company based on the deposit rate, and calculates the settlement amount for each merchant based on the principal amount advanced by the credit company and the amount of the deposit.

[0031] The display control unit 102c controls the input / output interface unit 108, displaying various screens to the user or receiving various inputs from the user. The generation unit 102d creates various data tables, such as the merchant data table 1, the merchant-specific fee rate data table 2, the customer contract data table 3, the merchant-specific settlement details data table 4, and the merchant-specific settlement table 5. Details of these functions will be described later.

[0032] [2. Overview] The overview of the deposit management device 100 according to the embodiment will be explained using Figures 2 to 5. First, the background of the embodiment will be explained using Figure 2. A company that handles installment payments (credit company 400) has a settlement process. When a user 600 enters into a sales contract or service provision contract with a merchant 500, the user may enter into an installment contract with the credit company 400. An example of such a sales contract would be when a user 600 purchases a television for 500,000 yen from a merchant 500, which is a television retailer. In this case, the user 600 pays the merchant 500 for the television, and the merchant 500 transfers the television to the user 600.

[0033] Here, instead of paying the merchant 500 the full price of the goods in a lump sum, user 600 can enter into an installment agreement with credit company 400 and pay the price in installments. For example, user 600 can pay credit company 400 the price of the goods (50,000 yen) plus an add-on fee (an additional fee paid to the credit company) in one payment, and then pay the purchase price of the 500,000 yen television in 10 installments. On the other hand, credit company 400 will advance payment to merchant 500 for the goods purchased by user 600. In order to receive advance payment from credit company 400, merchant 500 needs to enter into a merchant agreement with credit company 400.

[0034] Here, a contract also exists between the credit company 400 and the merchant 500, and the credit company 400 may receive a security deposit from the merchant 500. The advantage of the credit company 400 receiving a security deposit from the merchant 500 is that if the credit company 400 needs to collect money from the merchant 500, such as for the cancellation of an advance payment, the security deposit can be used to cover the amount. The security deposit is usually returned when the contract between the credit company 400 and the merchant 501 ends.

[0035] Figure 3 shows an example of a system in which a credit company 400 receives a security deposit from a member store. One possible pattern is that, as shown in Case 1 of Figure 3, the credit company 400 receives the security deposit in a lump sum when it enters into a contract with the member store 501. Another possible pattern is that, as shown in Case 2 of Figure 3, when the credit company 400 makes an advance payment to the member store 502, the member store 502 deposits a security deposit with the credit company 400 in a predetermined percentage corresponding to the advance payment.

[0036] In the latter case (Case 2), the amount of the security deposit is determined at the time of advance payment, making management complicated. Therefore, in the settlement of advance payments and security deposits between the credit company and the affiliated store, as shown in Case 2-1 in Figure 4, for example, the security deposit is calculated outside the system based on the total amount of advance payments, for example, on a monthly basis. In such cases, the credit company 400 pays the advance payments to the affiliated store 503 each time, while separately collecting the security deposit from the affiliated store 503.

[0037] However, in this case, the settlement process involves the troublesome task of separately collecting a security deposit.

[0038] The security deposit management device 100 according to this embodiment is designed in view of the above background and is characterized by comprising: an acquisition unit 102a that acquires a security deposit rate according to the rate pattern for each member store 500; and a calculation unit 102b that calculates the amount of security deposit that the member store 500 is required to deposit with the credit company 400 based on the security deposit rate acquired by the acquisition unit 102a, and calculates the settlement amount for each member store 500 based on the principal amount advanced by the credit company 400 and the amount of the security deposit.

[0039] As a result, according to the security deposit management device 100 of this embodiment, for example, as shown in Case 2-2 in Figure 5, the advance payment made by the credit company 400 to the merchant 502 is offset against the security deposit that the merchant 502 pays to the credit company 400, and the credit company 400 only needs to send the difference between the advance payment and the security deposit to the merchant 502. This eliminates the need to separately collect the security deposit in the settlement process, improving convenience. In other words, by including the security deposit in the settlement process with the merchant 502, it becomes possible to automatically collect the security deposit by performing a settlement by subtracting the advance payment from the security deposit.

[0040] Furthermore, according to the security deposit management device 100 of this embodiment, security deposits can be managed collectively for each affiliated store at the time of contract, and by calculating the security deposit for each user's contract at the time of advance payment for each affiliated store, it becomes possible to manage the deposits accumulated at the time of customer contract, thereby improving convenience.

[0041] [3. Specific examples of processing] A specific example of the processing performed by the deposit management device 100 configured as described above will be explained with reference to Figure 6. Figure 6 is a flowchart showing the flow of interest calculation processing performed by the deposit management device 100 according to the embodiment. The processing in steps S100 and S200 corresponds to pre-setting processing, the processing in steps S300 and S400 corresponds to daily contract data registration processing, and the processing in steps S600 to S800 corresponds to data aggregation processing.

[0042] First, in step S100, the control unit 102 registers merchant information and generates the merchant data table 1. As an example, the display control unit 102c displays the merchant contract screen 60 shown in Figure 7 to the user and accepts input of merchant information from the user. The acquisition unit 102a acquires the value of the merchant code from the user through the input field 61. The generation unit 102d generates the value of the "Merchant Code" item in the merchant data table 1 shown in Figure 8 based on the acquired merchant code value.

[0043] Furthermore, when the user presses button 63, the display control unit 102c displays the merchant information corresponding to the merchant code entered by the user in the display area 62.

[0044] Furthermore, the acquisition unit 102a accepts input of "merchant name," "representative name," and "address" from the user through input fields 64a, 64b, and 64c. When the user enters values ​​into input fields 64a, 64b, and 64c and presses the registration button 68, the generation unit 102d generates values ​​for the "merchant name," "representative name," and "address" items in the merchant data table 1 shown in Figure 8, based on the values ​​of merchant name, representative name, and address acquired through input fields 64a, 64b, and 64c.

[0045] Furthermore, if a security deposit is collected at the time of the merchant agreement, the acquisition unit 102a accepts input from the user for the security deposit to be collected at the time of the merchant agreement through the input field 65. When the user enters a value in the input field 65 and presses the registration button 68, the generation unit 102d generates a value for the "Security Deposit (Manual)" item in the merchant data table 1 based on the value of the security deposit to be collected at the time of the merchant agreement obtained through the input field 65.

[0046] If a security deposit is to be accumulated in accordance with the advance payment, the user does not need to enter a value in input field 65.

[0047] When a security deposit is accumulated in accordance with advance payments, the display control unit 102c displays the value of the "Cumulative Security Deposit Amount (Calculated)" item in the merchant data table 1 in the display area 66. In this way, the display control unit 102c displays to the user the cumulative amount of the security deposit when a security deposit is accumulated in accordance with advance payments. When a security deposit is accumulated in accordance with advance payments, the "Cumulative Security Deposit Amount (Calculated)" in the merchant data table 1 is recalculated and updated each time an advance payment is made. In this way, the display control unit 102c displays to the user the cumulative security deposit amount at that time.

[0048] Furthermore, when the security deposit is to be returned upon termination of the merchant agreement, the acquisition unit 102a receives input from the user regarding the security deposit to be returned to the merchant through the input field 67. When the user enters a value in the input field 65 and presses the registration button 68, the generation unit 102d generates a value for the "Security Deposit Return Amount" item in the merchant data table 1 based on the value of the security deposit to be returned to the merchant obtained through the input field 67.

[0049] In this way, the merchant data table 1 shown in Figure 8 is generated. In the merchant data table 1 shown in Figure 8, row 10 shows an example of Case 2, that is, when the merchant deposits the security deposit in installments. Row 11 shows an example of Case 1, that is, when the merchant deposits the security deposit in a lump sum. Row 12 shows an example of Case 1, that is, when the merchant deposits the security deposit in a lump sum and the security deposit is returned to the merchant.

[0050] Next, in step S200, the acquisition unit 102a acquires the deposit rate according to the rate pattern for each merchant, and the generation unit 102d creates a merchant-specific rate data table 2 based on the acquired deposit rates.

[0051] As an example, the display control unit 102c displays the merchant contract management screen 70 shown in Figure 9 to the user and accepts input from the user regarding merchant-specific rate tables and other information. The acquisition unit 102a acquires the "merchant code" and the "rate pattern" value, which indicates the rate pattern of the add-on fee rate and guaranteed interest rate, from the user through input fields 71 ​​and 73. Here, "rate pattern" is information indicating the rate pattern of the add-on fee rate and guaranteed interest rate. An add-on fee is a fee that the credit company charges the customer (user) in addition to the amount paid in an installment contract. A guarantee deposit refers to the amount of a guarantee deposit that the merchant must provide to the credit company. The add-on fee rate and guarantee deposit rate are the ratios of the add-on fee and guarantee deposit, respectively, to the principal amount advanced by the credit company on behalf of the merchant. The generation unit 102d generates values ​​for the "Merchant Code" and "Rate Pattern" items in the Merchant Data Table 1 shown in Figure 10, based on the acquired Merchant Code and Rate Pattern values.

[0052] Furthermore, when the user presses button 75, the display control unit 102c displays the merchant name corresponding to the merchant code entered by the user in the display area 72, and the rate pattern name corresponding to the rate pattern entered by the user in the display area 74.

[0053] Furthermore, the acquisition unit 102a accepts input from the user for "rate pattern name," "add-on fee rate," and "deposit rate" through input fields 76, 77, and 78. In other words, the acquisition unit 102a acquires the deposit rate corresponding to the rate pattern for each merchant. When the user enters values ​​into input fields 76, 77, and 78 and presses the registration button 79, the generation unit 102d generates values ​​for the "rate pattern name," "add-on fee rate," and "deposit rate" items in the merchant-specific rate data table 2 shown in Figure 10, based on the "rate pattern name," "add-on fee rate," and "deposit rate" values ​​acquired through input fields 76, 77, and 78.

[0054] In this case, if a security deposit is collected at the time of the merchant agreement, no additional security deposit is required when the credit company makes the advance payment. Therefore, in this case, the "security deposit rate" that the user enters in input field 78 will be 0%. On the other hand, if a security deposit is accumulated in accordance with the advance payment, the user enters the agreed-upon value as the security deposit rate in input field 78.

[0055] In this way, the merchant-specific fee rate data table 2 shown in Figure 10 is generated. In the merchant-specific fee rate data table 2 shown in Figure 10, row 20 represents the fee rate data corresponding to "Merchant A contract pattern (1)" where the add-on fee rate is 10.0% and the security deposit rate is 1.0%. Row 21 represents the fee rate data corresponding to "Merchant A contract pattern (2)" where the merchant is the same as row 20, but the add-on fee rate is 5.0% and the security deposit rate is 0.5%. Rows 20 and 21 are both fee rate data when a security deposit is accumulated in accordance with the advance payment. On the other hand, rows 22 and 23 show the fee rate data when a security deposit is collected at the time of the merchant contract. When a security deposit is collected at the time of the merchant contract, no additional security deposit is incurred when the credit company makes an advance payment, so in this case, the security deposit rate is 0%.

[0056] Next, the process proceeds to step S300, which describes the process when a customer purchases a product and enters into a credit agreement. In steps S300 and S400, the daily contract data registration process takes place.

[0057] Specifically, in step S300, for each contract, the process calculates the principal amount to be advanced, the add-on fee, and the security deposit based on the merchant-specific fee rate pattern, and creates customer contract data table 3.

[0058] As an example, the display control unit 102c displays a customer contract data registration screen (not shown) to the user and accepts input from the user regarding the customer contract data table 3. The acquisition unit 102a acquires from the user the following values: "Customer" indicating the customer's ID, "Contract Number" which is the number assigned to the contract, "Contract Date" which indicates the date the contract was concluded, "Merchant Code" which is the serial number assigned to the merchant, "Merchant Rate Pattern" which indicates the rate patterns for the add-on fee rate and guaranteed interest rate, and "Principal Amount Advanced" which is the price of goods, etc., that the credit company advances to the merchant for the contract. The generation unit 102d generates the values ​​for the "Customer," "Contract Number," "Contract Date," "Merchant Code," "Draft Merchant Rate Pattern," and "Principal Amount Advanced" items in the customer contract data table 3 shown in Figure 11, based on the values ​​of "Customer," "Contract Number," "Contract Date," "Merchant Code," "Draft Merchant Rate Pattern," and "Principal Amount Advanced" acquired from the user.

[0059] Next, the calculation unit 102b calculates the amount of the deposit that the merchant is required to deposit with the credit company based on the deposit rate acquired by the acquisition unit 102a in step S200. As an example, the calculation unit 102b calculates the amount of the deposit that the merchant is required to deposit with the credit company by multiplying the "principal amount advanced" in the customer contract data table 3 by the "deposit rate" in the merchant-specific rate data table 2 that corresponds to the "merchant code" and "rate pattern" in the customer contract data table 3. The generation unit 102d generates the value of the "deposit" item in the customer contract data table 3 based on the deposit value calculated by the calculation unit 102b.

[0060] For example, in row 30 of Figure 11, the merchant code in Customer Contract Data Table 3 is "10001" and the merchant-specific rate pattern is "001". Therefore, the corresponding deposit rate in Merchant-Specific Rate Data Table 2 is "1.0%". The calculation unit 102b calculates the amount of the deposit that the merchant must deposit with the credit company as 200,000 × 1.0% = 2,000 yen by multiplying the principal amount advanced, "200,000", in Customer Contract Data Table 3 by the deposit rate of "1.0%". The generation unit 102d generates the value of the "Deposit" item in Customer Contract Data Table 3 based on the deposit value calculated by the calculation unit 102b.

[0061] Furthermore, in the case of row 31 in Figure 11, the merchant code in Customer Contract Data Table 3 is "10001" and the merchant-specific rate pattern is "002", so the corresponding deposit rate in Merchant-Specific Rate Data Table 2 is "0.5%". The calculation unit 102b calculates the amount of the deposit that the merchant must deposit with the credit company as 300,000 × 0.5% = 1,500 yen by multiplying the principal amount advanced, "300,000", in Customer Contract Data Table 3 by the deposit rate of "0.5%". The generation unit 102d generates the value of the "Deposit" item in Customer Contract Data Table 3 based on the deposit value calculated by the calculation unit 102b.

[0062] Furthermore, in the case of row 32 in Figure 11, the merchant code in customer contract data table 3 is "10002" and the merchant-specific rate pattern is "001", so the corresponding deposit rate in merchant-specific rate data table 2 is "0.0%". Therefore, the calculation unit 102b calculates the deposit amount as 0 yen. The generation unit 102d generates the value of the "Deposit" item in customer contract data table 3 based on the deposit value calculated by the calculation unit 102b.

[0063] Furthermore, the calculation unit 102b further calculates the amount of the add-on fee based on the deposit rate acquired by the acquisition unit 102a in step S200. As an example, the calculation unit 102b calculates the amount of the add-on fee by multiplying the "principal amount advanced" in the customer contract data table 3 by the "add-on fee rate" in the merchant-specific rate data table 2, which corresponds to the "merchant code" and "rate pattern" in the customer contract data table 3. The generation unit 102d generates a value for the "add-on fee" item in the customer contract data table 3 based on the amount of the add-on fee calculated by the calculation unit 102b.

[0064] For example, in row 30 of Figure 11, the merchant code in Customer Contract Data Table 3 is "10001" and the merchant-specific fee rate pattern is "001". Therefore, the corresponding add-on fee rate in Merchant-Specific Fee Rate Data Table 2 is "10.0%". The calculation unit 102b calculates the add-on fee amount as 200,000 × 10.0% = 20,000 yen by multiplying the principal amount advanced in Customer Contract Data Table 3, "200,000", by the add-on fee rate of "10.0%". The generation unit 102d generates the value of the "Add-on Fee" item in Customer Contract Data Table 3 based on the deposit value calculated by the calculation unit 102b.

[0065] Similarly, in the case of rows 31 and 32 in Figure 11, the merchant code in Customer Contract Data Table 3 and the add-on fee rate in Merchant-Specific Fee Rate Data Table 2 corresponding to the merchant-specific fee rate pattern are "5.0%" and "8.0%", respectively. The calculation unit 102b calculates the amount of the add-on fee by multiplying the principal amounts of "300,000" and "400,000" in Customer Contract Data Table 3 by the add-on fee rates of "5.0%" and "8.0%", resulting in 300,000 × 5.0% = 15,000 yen and 400,000 × 8.0% = 32,000 yen, respectively. The generation unit 102d generates the value of the "Add-on Fee" item in Customer Contract Data Table 3 based on the deposit value calculated by the calculation unit 102b.

[0066] In this way, in step S300, the customer contract data table 3 shown in Figure 11 is generated.

[0067] Next, in step S400, the calculation unit 102b updates the cumulative guarantee amount in the merchant-specific data table 2 in accordance with the contract. That is, the calculation unit 102b calculates the cumulative guarantee amount for each merchant and updates the cumulative guarantee amount for each merchant based on the guarantee value calculated for each contract. Figure 12 shows an example of such a case. As an example, let's explain the case where the last update date of the merchant-specific data table 2 is October 30, 2024, and the calculation unit 102b updates the "Cumulative Reward Amount (Calculation)" item in the merchant-specific data table 2 on November 10, 2024. The calculation unit 102b aggregates the guarantee amounts related to contracts from the last update date of the merchant-specific data table 2 to the present for each merchant. In the example in Figure 11, for the merchant with merchant code 00001, a security deposit of 2,000 yen is incurred on November 1st, and a security deposit of 1,500 yen is incurred on November 10th, so the total security deposit is 2,000 yen + 1,500 yen = 3,500 yen. Therefore, the calculation unit 102b calculates the cumulative security deposit amount as 3,000,000 yen + 3,500 yen = 3,003,500 yen. Based on the cumulative security deposit amount calculated by the calculation unit 102b, the "Cumulative Security Deposit Amount (Calculation)" item in the merchant data table 2 is updated.

[0068] Next, the calculation process for the settlement amount of the security deposit, from steps S600 to S800, will be explained. In step S500, the calculation unit 102b determines whether the end date of the aggregation period has been reached. If the end date of the aggregation period has not been reached (step S500 No), the processes in steps S300 and S400 are repeated. On the other hand, if the end date of the aggregation period has been reached (step S500 Yes), the process proceeds to step S600, and the calculation unit 102b performs the security deposit aggregation process.

[0069] Next, in step S600, the calculation unit 102b calculates the settlement amount for each contract based on the principal amount advanced and the security deposit, and the generation unit 102d generates the merchant-specific settlement details data table 4 based on the settlement amount calculated by the calculation unit 102b. Here, the merchant-specific settlement details data table 4 is a data table for managing the information that forms the basis for the credit company to settle the principal amount advanced and the security deposit with the merchant for each customer (user) contract. While the merchant-specific settlement table 5 is a table that aggregates all contracts within a certain period, the merchant-specific settlement details data table 4 is a table that serves as the source data necessary to generate the merchant-specific settlement table 5 for each contract.

[0070] Figure 13 shows an example of the Merchant-Specific Settlement Details Data Table 4. In the Merchant-Specific Settlement Details Data Table 4, the items "Merchant Code," "Contract Number," "Principal Amount Advanced," and "Deposit" are the same as those in the Customer Contract Data Table 3. Therefore, the generation unit 102d creates the "Merchant Code," "Contract Number," "Principal Amount Advanced," and "Deposit" items in the Merchant-Specific Settlement Details Data Table 4 by transferring the "Merchant Code," "Contract Number," "Principal Amount Advanced," and "Deposit" items from the Customer Contract Data Table 3 to the Merchant-Specific Settlement Details Data Table 4.

[0071] Next, the calculation unit 102b calculates the settlement amount for each merchant based on the principal amount advanced by the credit company and the amount of the security deposit, for each contract. Specifically, the calculation unit 102b calculates the settlement amount by subtracting the amount of the security deposit from the principal amount advanced. For example, as shown in line 40, the "principal amount advanced" is 200,000 yen and the "security deposit" is 2,000 yen, so the settlement amount is 200,000 yen - 2,000 yen = 198,000 yen. Also, as shown in line 41, the "principal amount advanced" is 300,000 yen and the "security deposit" is 1,500 yen, so the settlement amount is 300,000 yen - 1,500 yen = 298,500 yen. Furthermore, as shown in row 42, the "principal amount advanced" is 400,000 yen and the "deposit" is 0 yen, so the settlement amount is 400,000 yen - 0 yen = 400,000 yen.

[0072] The generation unit 102d creates data for the "Settlement Amount" item in the merchant-specific settlement details data table 4 based on the settlement machine for each contract calculated by the calculation unit 102b. In this way, the merchant-specific settlement details data table 4 shown in Figure 13 is generated.

[0073] Next, in step S700, the calculation unit 102b aggregates settlement data for each merchant within a certain period, and the generation unit 102d creates a merchant-specific settlement table 5 based on the settlement data aggregated for each merchant by the calculation unit 102b. The merchant-specific settlement table 5 is a data table for managing information on the total settlement amount for each merchant, taking into account the principal amount advanced by the credit company to the merchant and the security deposit that the merchant is required to deposit with the credit company, for a certain period. An example of the merchant-specific settlement table 5 is shown in Figure 14.

[0074] As an example, if we explain the calculation unit 102b assuming that the period for data aggregation is from November 1, 2024 to November 20, 2024, the calculation unit 102b calculates the total settlement amount for each merchant during a certain period (November 1, 2024 to November 20, 2024) by adding up the corresponding settlement amounts in the merchant-specific settlement details data table 4. For example, in the case of a merchant with merchant code "10001" shown in row 50, the contract with contract number 100, which has a settlement amount of "198,000 yen," and the contract with contract number 101, which has a settlement amount of "298,500 yen," are the contracts that correspond to merchant code "10001" from November 1, 2024 to November 20, 2024. Therefore, the calculation unit 102b adds these settlement amounts together to calculate the settlement amount for merchant code "10001" from November 1, 2024 to November 20, 2024 as "496,500 yen." Furthermore, in the case of the merchant with merchant code "10002" shown in row 50, the contract with contract number 200, which has a settlement amount of "400,000 yen", corresponds to the contract with merchant code "10002" for the period from November 1, 2024 to November 20, 2024. Therefore, the calculation unit 102b calculates the settlement amount for merchant code "10002" for the period from November 1, 2024 to November 20, 2024 as "400,000 yen".

[0075] Thus, in steps S600 and S700, the calculation unit 102b aggregates the principal amount advanced and the amount of the security deposit within a certain period, calculates the settlement amount for each merchant within that period, and thereby generates the merchant-specific settlement table 5. Subsequently, in step S800, the display control unit 102c displays the created merchant-specific settlement table 5 on the display unit.

[0076] As described above, the security deposit management device 100 according to the embodiment includes an acquisition unit 102a that acquires a security deposit rate according to the rate pattern for each member store 500, and a calculation unit 102b that calculates the amount of security deposit that the member store 500 is required to deposit with the credit company 400 based on the security deposit rate acquired by the acquisition unit 102a, and calculates the settlement amount for each member store 500 based on the principal amount advanced by the credit company 400 and the amount of the security deposit.

[0077] This allows credit company 400 to offset the advance payment made to merchant 500 against the security deposit paid by merchant 500 to credit company 400, and only the difference between the advance payment and the security deposit needs to be transferred. This eliminates the need to separately collect the security deposit in the settlement process, improving convenience.

[0078] Furthermore, the security deposit can be managed collectively for each franchisee at the time of contract, and by calculating the security deposit on a per-contract basis for each user at the time of advance payment for each franchisee, it becomes possible to accumulate and manage the security deposit at the time of customer contract, improving convenience.

[0079] [4. Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving operational efficiency and promoting appropriate management decisions within companies, thereby enabling contributions to SDGs Goals 8 and 9.

[0080] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and digital processes, thereby contributing to SDGs Goals 12, 13, and 15.

[0081] Furthermore, this embodiment can contribute to strengthening control and governance, thereby enabling contributions to SDG Goal 16.

[0082] [5. Other Embodiments] In addition to the embodiments described above, the present invention may be implemented in various different embodiments within the scope of the technical idea described in the claims.

[0083] 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 by known methods.

[0084] Furthermore, the processing procedures, control procedures, specific names, information including parameters such as registration data and search conditions for each process, screen examples, and database configuration shown in this specification and in the drawings may be changed at will unless otherwise specified.

[0085] Furthermore, with respect to the deposit management device 100, each component shown in the illustration is a functional concept and does not necessarily need to be physically configured as shown.

[0086] For example, the processing functions of the deposit management device 100, particularly those performed in the control unit, may be implemented in whole or in part by a CPU and a program interpreted and executed by the CPU, or they may be implemented as wired logic hardware. The program is recorded on a non-temporary computer-readable recording medium containing programmed instructions for the information processing device to execute the processing described in this embodiment, and is mechanically read by the deposit management device 100 as needed. That is, a storage unit such as ROM or HDD (Hard Disk Drive) records a computer program that works in cooperation with the OS to give instructions to the CPU and perform various processing tasks. This computer program is executed by being loaded into RAM and works in cooperation with the CPU to constitute the control unit.

[0087] Furthermore, this computer program may be stored on an application program server connected to the deposit management device 100 via any network, and it is possible to download all or part of it as needed.

[0088] Furthermore, the program for executing the processing described in this embodiment may be stored on a non-temporary computer-readable recording medium, or it may be configured as a program product. Here, "recording medium" includes any "portable physical medium" such as memory cards, USB (Universal Serial Bus) memory, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (Registered Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROMs (Compact Disk Read Only Memory), MOs (Magneto-Optical disks), DVDs (Digital Versatile Disks), and Blu-ray (Registered Trademark) Discs.

[0089] Furthermore, "program" refers to a data processing method described in any language or writing method, regardless of its format, such as source code or binary code. Note that "program" is not necessarily limited to a single, monolithic structure; it also includes distributed structures consisting of multiple modules or libraries, and those that work in cooperation with other programs, such as an operating system, to achieve their functions. Regarding the specific configuration and reading procedures for reading the recording medium in each device shown in the embodiments, as well as the installation procedures after reading, well-known configurations and procedures can be used.

[0090] The various databases stored in the memory unit are memory devices such as RAM and ROM, 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 website provision.

[0091] Furthermore, the deposit management device 100 may be configured as an information processing device such as a known personal computer or workstation, or as an information processing device to which any peripheral devices are connected. Alternatively, the deposit management device 100 may be implemented by implementing software (including programs or data, etc.) that realizes the processing described in this embodiment on the device.

[0092] Furthermore, the specific forms of distribution and integration of the devices are not limited to those shown in the figures, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit according to various additions or functional loads. In other words, the embodiments described above may be implemented in any combination, or the embodiments may be implemented selectively. [Industrial applicability]

[0093] This invention is useful in various situations, such as business management in credit companies. [Explanation of symbols]

[0094] 100 Deposit Management Device 102 Control Unit 102a Acquisition Department 102b Calculation Unit 102c Display Control Unit 102d Generator 104 Communication Interface Section 106 Storage section 1. Merchant Data Table 2. Data table by affiliated store 3. Customer Contract Data Table 4. Transactional Store Settlement Details Data Table 5. Payment Table by Merchant 108 Input / Output Interface Section 112 Input device 114 Output device 200 servers 300 Networks

Claims

1. An acquisition unit that acquires the deposit rate according to the rate pattern of each member store, A security deposit management device characterized by comprising a calculation unit that calculates the amount of security deposit that the affiliated store must deposit with the credit company based on the security deposit rate acquired by the acquisition unit, and calculates the settlement amount for each affiliated store based on the principal amount advanced by the credit company and the amount of security deposit.

2. The security deposit management device according to claim 1, characterized in that the calculation unit calculates the settlement amount by subtracting the amount of the security deposit from the principal amount advanced.

3. The security deposit management device according to claim 1, wherein the calculation unit aggregates the principal amount advanced and the amount of the security deposit within a certain period and calculates the settlement amount for each member store within the certain period.

4. The calculation unit calculates the cumulative amount of the security deposit for each member store, The security deposit management device according to claim 1, which calculates the amount of the security deposit for each contract and updates the cumulative amount of the security deposit for each member store.

5. The deposit management device according to claim 1, wherein the calculation unit further calculates an add-on fee.

6. The acquisition steps involve obtaining a deposit rate according to the rate pattern for each member store, The steps include: calculating the amount of the security deposit that the merchant is required to deposit with the credit company based on the security deposit rate; and calculating the settlement amount for each merchant based on the principal amount advanced by the credit company and the amount of the security deposit. A deposit management method characterized by including the following.

7. Information processing equipment, A means of obtaining a deposit rate according to the rate pattern of each member store, A calculation means that calculates the amount of the security deposit that the affiliated store must deposit with the credit company based on the security deposit rate, and calculates the settlement amount for each affiliated store based on the principal amount advanced by the credit company and the amount of the security deposit. A deposit management program designed to function as such.

Images