Information processing device, information processing system, information processing method and program

Abstract

To propose actions to collect uncollected receivables according to the collection status of the receivables.SOLUTION: An information processing device can communicate with a user terminal used by a user. The information processing device includes: an acquisition unit that acquires receivable management information that indicates the collection status of receivables billed by the user to a business partner; and a communication unit that transmits, to the user terminal, screen data for displaying a proposal screen that proposes a selection for collecting receivables whose collection status indicates uncollected.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an information processing device, an information processing system, an information processing method, and a program. [Background technology]

[0002] In commercial transactions, there is a risk that creditors will be unable to collect their receivables. To reduce the risk of uncollectible receivables, there are credit guarantee companies that can be requested to guarantee the receivables. There is also a debt collection method in which the business partner submits an account transfer request to an affiliated financial institution in advance, and the payment is transferred from the business partner's account to the creditor's account, and there are account transfer agency companies that handle the procedures necessary for account transfers on behalf of the creditor.

[0003] For example, Patent Document 1 discloses an invention in which, in order to reduce risks in commercial transactions, provisional payment information from the payer indicates the ability to pay to the payee, and the actual payment is executed with the payee's approval and a request for final payment including the provisional payment information from the payee. Summary of the Invention [Problem to be solved by the invention]

[0004] However, conventional debt collection methods have the problem that it is difficult to determine the collection method for uncollected debts. For example, when there are multiple uncollected debts, it is necessary to determine which debts should be claimed for the performance of the debt guarantee. Also, even if the payment deadline has passed, it may not be appropriate to immediately perform the debt guarantee.

[0005] In view of the above technical problems, one embodiment of the present invention proposes a selection for collecting uncollected debts depending on the debt collection status. [Means for solving the problem]

[0006] In order to solve the above problems, an information processing device that is one embodiment of the present invention is an information processing device that can communicate with a user terminal used by a user, and is equipped with an acquisition unit that acquires receivables management information that indicates the collection status of receivables that the user has invoiced to a business partner, and a communication unit that transmits screen data to the user terminal to display a proposal screen that suggests options for collecting receivables that have a collection status of uncollected. [Effects of the Invention]

[0007] According to one embodiment of the present invention, options for collecting uncollected debts can be suggested depending on the debt collection status. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 2 is a conceptual diagram illustrating the relationships between companies in one embodiment. [Figure 2] 1 is a block diagram illustrating an example of an overall configuration of an information processing system according to an embodiment. [Figure 3] FIG. 1 is a block diagram illustrating an example of a hardware configuration of an information processing device according to an embodiment. [Figure 4] FIG. 1 is a block diagram illustrating an example of a functional configuration of an information processing system according to an embodiment. [Figure 5] FIG. 10 is a diagram illustrating an example of a business partner information table according to an embodiment. [Figure 6] FIG. 10 is a diagram illustrating an example of an invoice information table according to an embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of an account transfer application table according to an embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of an account transfer information table according to an embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of a bond guarantee information table according to an embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a performance information table according to an embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of a bond management information table according to an embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of a credit information table according to an embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of a transaction history information table according to an embodiment. [Figure 14] FIG. 10 is a sequence diagram illustrating an example of an account transfer process according to an embodiment. [Figure 15] FIG. 10 is a sequence diagram illustrating an example of information collection processing according to an embodiment. [Figure 16] FIG. 10 is a sequence diagram illustrating an example of a proposal execution process according to an embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of a bond list screen according to an embodiment. [Figure 18] 10 is a flowchart illustrating an example of a behavior determination process according to an embodiment. [Figure 19] FIG. 10 is a diagram illustrating an example of a proposal screen according to an embodiment. [Figure 20] FIG. 10 is a diagram illustrating an example of a setting screen according to an embodiment. [Figure 21] FIG. 10 is a sequence diagram illustrating an example of a proposal execution process according to a modified example. [Figure 22] FIG. 10 is a diagram illustrating an example of a behavior determination process according to a modified example. [Figure 23] 10A and 10B are diagrams showing examples of a proposal screen and a guidance screen according to a modified example. [Figure 24] 10A and 10B are diagrams showing examples of a proposal screen and a guidance screen according to a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the drawings, components having the same functions are designated by the same reference numerals, and duplicated explanations will be omitted.

[0010] [Embodiment] [Inter-company relationships] The relationships between the companies in this embodiment will be described with reference to Fig. 1. Fig. 1 is a conceptual diagram showing the relationships between the companies in this embodiment.

[0011] As shown in Figure 1, service user company A is a company that provides goods or services to business partner company B and receives compensation from business partner company B. Business partner company B is a business partner of service user company A. In this case, a relationship is created in which service user company A is the creditor and business partner company B is the debtor.

[0012] Service provider company C is a company that, upon request from service user company A, provides a service that manages a series of procedures carried out in transactions with business partner company B. In addition, a service user company that uses a service provided by information processing system 1 in this embodiment may be referred to as a tenant. In other words, in this embodiment, a tenant is a business, organization, individual, etc. Hereinafter, the service provided by service provider company C will be referred to as a "transaction management service." The series of procedures includes, for example, issuing and sending invoices to business partners, collecting receivables through account transfers, and fulfilling a receivable guarantee for uncollectible receivables.

[0013] Account transfer service company D is a company that cooperates with service provider company C to provide a service that handles the procedures required for collecting receivables through account transfer. Hereinafter, the service provided by account transfer service company D will be referred to as the "account transfer service." Generally, an account transfer service executes all account transfer requests submitted by a specified closing date in one go on a specified transfer date. In this embodiment, the account transfer service executes account transfers once a month.

[0014] Financial institution E is a company or organization that manages the accounts held by service user company A and business partner company B. In response to a request from account transfer service company D, financial institution E transfers the payment from business partner company B's account to service user company A's account.

[0015] Debt guarantee service company F is a company that provides a service to pay insurance claims for uncollectible debts in cooperation with service provider company C. Hereinafter, the service provided by debt guarantee service company F will be referred to as the "debt guarantee service."

[0016] Credit information service company G is a company that holds credit information indicating the trustworthiness of the management, etc. of various companies, including client company B, and provides the credit information to service provider company C. Credit information service company G may be one company or multiple companies. If credit guarantee service company F holds credit information, it may provide the credit information to service provider company C. Service provider company C may also independently calculate the trustworthiness based on information it has collected about the management, etc. of client company B. The trustworthiness can be calculated, for example, using a machine learning model that has learned information about the management, etc. of various companies.

[0017] Here, an outline of the processing in this embodiment will be described.

[0018] First, service user company A requests service provider company C to create an invoice based on a business transaction with business partner company B and send the created invoice to business partner company B (S1). In response, service provider company C creates an invoice and sends it to business partner company B (S2).

[0019] Next, service user company A requests service provider company C to register account transfer information based on the invoice it issued (S3). In response, service provider company C registers the account transfer information and requests account transfer service company D to carry out the account transfer (S4).

[0020] Next, the account transfer service company D sends a payment slip to request the account transfer to the financial institution E. The account transfer service company D may also send payment data to request the account transfer electronically to the financial institution E. The financial institution E carries out the account transfer on the specified transfer date in accordance with the payment slip or payment data (S5). It is assumed that the account transfer service company D has submitted an account transfer request form for the client company B to the financial institution E in advance.

[0021] Next, service provider company C obtains the account transfer result from account transfer service company D (S6). After that, service provider company C, in response to a request from service user company A, proposes an action to collect the outstanding receivables (hereinafter also referred to as a "collection action") (S7).

[0022] Then, service using company A decides on collection action and carries it out. For example, service using company A sends a demand letter to business partner company B urging payment (S8-1). Service providing company C may send a demand letter to business partner company B in response to a request from service using company A. Also, for example, service using company A requests service providing company C to fulfill the claim guarantee (S8-2). In response to the request for fulfillment of the claim guarantee, service providing company C applies to claim guarantee service company F to fulfill the claim guarantee (S9).

[0023] The collection action is a choice that can be taken by service user company A based on the proposal by service provider company C. Therefore, for example, the decision to wait and see without taking any specific action at this time is also included as a choice of service user company A.

[0024] [Overall configuration of information processing system] The overall configuration of the information processing system according to this embodiment will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the overall configuration of the information processing system according to this embodiment.

[0025] As shown in Figure 2, the information processing system 1 in this embodiment includes a transaction management system 2, an account transfer system 3, a claim guarantee system 4, and a user terminal 50. The transaction management system 2 in this embodiment includes a document management server 10, an account transfer server 20, a claim guarantee server 30, and a claim management server 40. Each system, server, and terminal included in the information processing system 1 is connected to a communication network N1.

[0026] The communication network N1 is configured so that each connected device can communicate with each other. The communication network N1 is constructed by a wired communication network such as the Internet, a local area network (LAN), or a wide area network (WAN). The communication network N1 may include not only wired communication but also wireless communication networks such as wireless LAN or short-range wireless communication, or mobile communication networks such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), or 5G (5th Generation).

[0027] The user terminal 50 is installed at service using company A. The transaction management system 2 is installed at service providing company C. The account transfer system 3 is installed at account transfer service company D. The claim guarantee system 4 is installed at claim guarantee service company F.

[0028] The form management server 10 provides a form management service to the user terminal 50 via the communication network N1. The form management service in this embodiment is a service that creates an invoice in response to a request from the user terminal 50 and sends the created invoice to a business partner.

[0029] The account transfer server 20 provides an account transfer intermediation service to the user terminal 50 via the communication network N1. The account transfer intermediation service in this embodiment is a service that executes procedures for collecting receivables by account transfer to the account transfer system 3 in response to a request from the user terminal 50.

[0030] The claim guarantee server 30 provides a claim guarantee intermediation service to the user terminal 50 via the communication network N1. The claim guarantee intermediation service in this embodiment is a service that, in response to a request from the user terminal 50, executes procedures for the claim guarantee system 4 to fulfill a claim guarantee for an uncollected claim.

[0031] The claim management server 40 provides a claim management service to the user terminal 50 via the communication network N1. The claim management service in this embodiment is a service that manages the collection status of claims and performs collection actions to collect claims in response to requests from the user terminal 50.

[0032] The user terminal 50 is an information processing device used by a user. The user is an employee of the service using company A, etc. The user terminal 50 uses various services provided by each server included in the transaction management system 2 via the communication network N1 in response to the user's operation.

[0033] An example of the document management server 10, the account transfer server 20, the claim guarantee server 30, the claim management server 40, and the user terminal 50 is an information processing device. Note that the document management server 10, the account transfer server 20, the claim guarantee server 30, the claim management server 40, and the user terminal 50 are not limited to information processing devices as long as they are devices equipped with communication functions.

[0034] The document management server 10, the account transfer server 20, the claim guarantee server 30, the claim management server 40, and the user terminal 50 may be, for example, an output device such as a PJ (Projector), an IWB (Interactive White Board: an electronic white board with a blackboard function that allows intercommunication), digital signage, a HUD (Head Up Display) device, industrial machinery, an imaging device, a sound collection device, medical equipment, a network home appliance, an automobile (Connected Car), a notebook PC (Personal Computer), a mobile phone, a smartphone, a tablet terminal, a game console, a PDA (Personal Digital Assistant), a digital camera, a wearable PC or a desktop PC, etc.

[0035] [Hardware configuration of information processing system] The hardware configuration of the information processing system in this embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the hardware configuration when the document management server 10, the account transfer server 20, the claim guarantee server 30, the claim management server 40, and the user terminal 50 are realized by a computer.

[0036] As shown in Figure 3, the computer includes a CPU (Central Processing Unit) 501, a ROM (Read Only Memory) 502, a RAM (Random Access Memory) 503, a HD (Hard Disk) 504, a HDD (Hard Disk Drive) controller 505, a display 506, an external device connection I / F (Interface) 508, a network I / F 509, a bus line 510, a keyboard 511, a pointing device 512, a DVD-RW (Digital Versatile Disk Rewritable) drive 514, and a media I / F 516.

[0037] Of these, the CPU 501 controls the operation of the entire computer. The ROM 502 stores programs used to drive the CPU 501, such as the IPL. The RAM 503 is used as a work area for the CPU 501. The HD 504 stores various data such as programs. The HDD controller 505 controls the reading and writing of various data from and to the HD 504 under the control of the CPU 501.

[0038] The display 506 displays various types of information such as a cursor, menus, windows, characters, or images. The external device connection I / F 508 is an interface for connecting various types of external devices. In this case, the external devices are, for example, USB (Universal Serial Bus) memories, printers, etc. The network I / F 509 is an interface for data communication using the communication network N1. The bus line 510 is an address bus, data bus, etc. for electrically connecting the components such as the CPU 501 shown in FIG. 3.

[0039] The keyboard 511 is a type of input means having multiple keys for inputting characters, numbers, various instructions, etc. The pointing device 512 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. The DVD-RW drive 514 controls reading and writing of various data from a DVD-RW 513, which is an example of a removable recording medium. Note that this is not limited to a DVD-RW, and may be a DVD-R, etc. The media I / F 516 controls reading and writing (storing) of data from a recording medium 515, such as a flash memory.

[0040] [Functional configuration of information processing system] The functional configuration of the information processing system in this embodiment will be described with reference to Fig. 4 to Fig. 14. Fig. 4 is a block diagram showing an example of the functional configuration of the information processing system in this embodiment.

[0041] <Functional configuration of the report management server> As shown in FIG. 4, the form management server 10 in this embodiment includes a form management information storage unit 100, a storage control unit 11, and a communication unit 12.

[0042] The form management information storage unit 100 stores customer information and invoice information used in the form management service. The form management information storage unit 100 is realized using, for example, the HD 504 shown in FIG.

[0043] The storage control unit 11 writes and reads data to and from the form management information storage unit 100. The storage control unit 11 is realized, for example, by a program loaded from the HD 504 onto the RAM 503 shown in FIG. 3 and executed by the CPU 501 and the HDD controller 505.

[0044] The communication unit 12 transmits and receives various data to and from other servers, devices, or systems via the communication network N1. The communication unit 12 is realized, for example, by a program loaded from the HD 504 onto the RAM 503 shown in FIG. 3 and executed by the CPU 501 and the network I / F 509.

[0045] (Customer information table) Fig. 5 is a conceptual diagram showing an example of a business partner information table for storing business partner information. A business partner information management DB 1001 configured with a business partner information table such as that shown in Fig. 5 is constructed in the form management information storage unit 100. The business partner information table stores information about business partner company B, which is a business partner of service using company A.

[0046] As shown in Figure 5, the customer information table manages, for each tenant, the billing recipient ID, billing recipient name (company name, etc.), billing recipient address (location), billing recipient contact information (telephone number, email address, etc.), billing recipient's contact name, and billing recipient's account information (bank name, branch name, account type, account number, account holder name, etc.) in association with each other.

[0047] (Invoice information table) Fig. 6 is a conceptual diagram showing an example of an invoice information table that stores invoice information. The form management information storage unit 100 has constructed an invoice information management DB 1002 that is configured with an invoice information table such as that shown in Fig. 6. The invoice information table stores information about invoices issued by service using company A.

[0048] As shown in Figure 6, the invoice information table manages, for each tenant, the invoice ID, invoice recipient ID, invoice recipient name (company name, etc.), invoice amount, invoice date, payment due date, payment status (unpaid or paid), and payment date in association with each other. The payment status is set to "unpaid" when an invoice is issued in the form management service, and is set to "paid" when payment is confirmed.

[0049] <Functional configuration of account transfer server> As shown in FIG. 4, the account transfer server 20 in this embodiment comprises an account transfer information storage unit 200, a storage control unit 21, and a communication unit 22.

[0050] The account transfer information storage unit 200 stores account transfer application information and account transfer information used in the account transfer intermediation service. The account transfer information storage unit 200 is realized, for example, using the HD 504 shown in FIG.

[0051] The storage control unit 21 writes and reads data to and from the account transfer information storage unit 200. The storage control unit 21 is realized, for example, by a program loaded from HD 504 onto RAM 503 shown in Fig. 3 and executed by the CPU 501 and HDD controller 505.

[0052] The communication unit 22 transmits and receives various data to and from other servers, devices, or systems via the communication network N1. The communication unit 22 is realized, for example, by a program loaded from the HD 504 onto the RAM 503 shown in FIG. 3 and executed by the CPU 501 and the network I / F 509.

[0053] (Account transfer application table) Figure 7 is a conceptual diagram showing an example of an account transfer application table that stores account transfer application information. The account transfer information storage unit 200 has created an account transfer application management DB 2001 that is configured using an account transfer application table such as the one shown in Figure 7. The account transfer application table stores information related to account transfer applications requested by service using company A.

[0054] As shown in Figure 7, the account transfer application table manages, for each tenant, the application name representing the account transfer application, the total billed amount, the transfer date, the collection result (collection completed, partial uncollectible, or uncollectible), the total collected amount, etc. "Collection completed" means that all account transfers included in the application have been completed, "partially uncollectible" means that the application includes uncompleted account transfers, and "uncollectible" means that all account transfers included in the application have not been completed.

[0055] (Account transfer information table) Figure 8 is a conceptual diagram showing an example of an account transfer information table that stores account transfer information. The account transfer information storage unit 200 has created an account transfer information management DB 2002 that is configured using an account transfer information table such as the one shown in Figure 8. The account transfer information table stores information about account transfers for each account transfer application requested by service using company A.

[0056] As shown in Figure 8, the account transfer information table associates and manages the transfer ID, invoice ID, name of the billing recipient (company name, etc.), billing amount, transfer date, and transfer result (transfer completed or incomplete, and if incomplete, the reason), for each tenant and account transfer application.

[0057] <Functional configuration of the credit guarantee server> As shown in FIG. 4, the claim guarantee server 30 in this embodiment comprises a claim guarantee information storage unit 300, a storage control unit 31, and a communication unit 32.

[0058] The claim guarantee information storage unit 300 stores the claim guarantee information and performance information used in the claim guarantee intermediation service. The claim guarantee information storage unit 300 is realized, for example, by using the HD 504 shown in FIG.

[0059] The memory control unit 31 writes and reads data to and from the claim guarantee information memory unit 300. The memory control unit 31 is realized, for example, by a process executed by the CPU 501 and the HDD controller 505 of a program loaded from the HD 504 onto the RAM 503 shown in FIG.

[0060] The communication unit 32 transmits and receives various data to and from other servers, devices, or systems via the communication network N1. The communication unit 32 is realized, for example, by a process executed by the CPU 501 and the network I / F 509 in accordance with a program loaded from the HD 504 onto the RAM 503 shown in FIG.

[0061] (Bond Guarantee Information Table) Figure 9 is a conceptual diagram showing an example of a claim guarantee information table that stores claim guarantee information. The claim guarantee information storage unit 300 has constructed a claim guarantee information management DB3001 that is made up of a claim guarantee information table such as that shown in Figure 9. The claim guarantee information table stores information that indicates the contract status and performance history of the claim guarantee for business partner company B, which is the subject of claim guarantee by service using company A.

[0062] As shown in Figure 9, the debt guarantee information table manages, for each tenant, the name of the business partner (company name, etc.), the maximum amount of the guarantee, the history of debt guarantee performance, the guarantee start date, the guarantee end date, and the guarantee status, etc., in association with each other.

[0063] (Performance information table) Fig. 10 is a conceptual diagram showing an example of a performance information table that stores performance information. The claim guarantee information storage unit 300 has constructed a performance information management DB 3002 that is configured with a performance information table such as that shown in Fig. 10. The performance information table stores the history (performance history) of service using company A's applications for performance of claim guarantees.

[0064] As shown in Figure 10, the performance information table manages, for each tenant, the name of the business partner (company name, etc.), billing amount, billing date, payment due date, performance status, and performance date, etc., in association with each other.

[0065] <Functional configuration of the credit management server> As shown in Figure 4, the claim management server 40 in this embodiment includes a claim management information storage unit 400, a screen data storage unit 410, a storage control unit 41, a communication unit 42, an information acquisition unit 43, a screen creation unit 44, a judgment unit 45, and an execution unit 46.

[0066] The claim management information storage unit 400 stores claim management information, credit information, and transaction history information used in the claim management service.

[0067] The screen data storage unit 410 stores screen data for displaying a screen to be provided (transmitted) to the user terminal 50. The screen data is, for example, screen data written in HTML (HyperText Markup Language) or the like, and may include an application written in JavaScript (registered trademark) or the like.

[0068] The bond management information storage unit 400 and the screen data storage unit 410 are realized, for example, using the HD 504 shown in FIG.

[0069] The memory control unit 41 writes and reads data to the claim management information memory unit 400 and the screen data memory unit 410. The memory control unit 41 is realized, for example, by a process in which a program loaded from the HD 504 to the RAM 503 shown in FIG. 3 is executed by the CPU 501 and the HDD controller 505.

[0070] The communication unit 42 transmits and receives various data to and from other servers, devices, or systems via the communication network N1. The communication unit 42 is realized, for example, by a process executed by the CPU 501 and the network I / F 509 in accordance with a program loaded from the HD 504 onto the RAM 503 shown in FIG.

[0071] The information acquisition unit 43 uses the communication unit 42 to acquire information from each server included in the transaction management system 2, and uses the memory control unit 41 to store the bond management information in the bond management information memory unit 400.

[0072] The screen creation unit 44 uses the storage control unit 41 to read out the screen data from the screen data storage unit 410, and uses the communication unit 42 to transmit the screen data to the user terminal 50.

[0073] The judgment unit 45 uses the memory control unit 41 to read out the claim management information from the claim management information memory unit 400 and makes a predetermined judgment based on the claim management information.

[0074] The execution unit 46 receives a request to execute a collection action from the user terminal 50 using the communication unit 42, and executes the collection action requested by the user terminal 50.

[0075] The information acquisition unit 43, the screen creation unit 44, the determination unit 45, and the execution unit 46 are realized by, for example, processing that is executed by the CPU 501 according to a program loaded onto the RAM 503 from the HD 504 shown in FIG.

[0076] (Accounts Management Information Table) Fig. 11 is a conceptual diagram showing an example of a claim management information table that stores claim management information. A claim management information management DB 4001 that is configured with a claim management information table such as that shown in Fig. 11 is constructed in the claim management information storage unit 400. The claim management information table stores information about claims based on invoices issued by service using company A.

[0077] As shown in Figure 11, the receivables management information table manages, for each tenant, the invoice ID, name of the billing recipient (company name, etc.), billing amount, invoice date, payment due date, payment status, deposit date, transfer ID, and reminder date (history of reminder letter sending), etc., in association with each other.

[0078] (Credit Information Table) Fig. 12 is a conceptual diagram showing an example of a credit information table for storing credit information. The credit management information storage unit 400 has constructed a credit information management DB 4002 that is made up of a credit information table such as that shown in Fig. 12. The credit information table stores credit information related to trading partner company B.

[0079] As shown in Figure 12, the credit information table associates and manages the name of the business partner (such as the company name), industry, number of employees, sales, rating, previous year's rating, rank, etc. The credit information stored in the credit information table is information about the business partners of service user company A extracted from credit information previously obtained from credit information service company G. The credit information may use a reliability calculated independently by the transaction management system 2 based on information collected by itself.

[0080] (Transaction history information table) Figure 13 is a conceptual diagram showing an example of a transaction history information table that stores transaction history information. The receivables management information storage unit 400 has constructed a transaction history information management DB 4003 that is made up of a transaction history information table such as the one shown in Figure 13. The transaction history information table stores information regarding the issuance status and collection status of invoices issued by trading company B.

[0081] As shown in Figure 13, the transaction history information table associates and manages, for each business partner, the name of the invoice recipient (such as the company name), the invoice recipient's industry, the payment due date, the date of receipt, the performance status of the receivable (completed or delayed performance), and a flag indicating the payment tendency. "Completed" means that the collection of the receivable has been completed, while "delayed performance" means that the collection of the receivable is delayed. Note that transaction history information is the status of issued invoices, so the presence or absence of transaction history information indicates the issuance status.

[0082] <Functional configuration of user terminal> As shown in FIG. 4, the user terminal 50 in this embodiment includes a display control unit 51, a communication unit 52, and a reception unit 53.

[0083] The display control unit 51 displays a screen based on screen data received using the communication unit 52. The display control unit 51 is, for example, a web browser function provided in the user terminal 50. The display control unit 51 is realized, for example, by a process executed by the CPU 501 and the display 506 in accordance with a program loaded from the HD 504 onto the RAM 503 shown in FIG.

[0084] The communication unit 52 transmits and receives various data to and from other servers, devices, or systems via the communication network N1. The communication unit 52 is realized, for example, by a process executed by the CPU 501 and the network I / F 509 in accordance with a program loaded from the HD 504 onto the RAM 503 shown in FIG.

[0085] The reception unit 53 receives various operations from the user and is realized by, for example, commands from the CPU 501 and the keyboard 511 or pointing device 512 shown in FIG.

[0086] [Information processing system processing procedure] The processing steps of the information processing method executed by the information processing system in this embodiment will be described with reference to Fig. 14 to Fig. 20. Fig. 14 to Fig. 16 are sequence diagrams showing an example of the processing steps of the information processing method in this embodiment. The information processing method in this embodiment consists of an account transfer process (see Fig. 14), an information collection process (see Fig. 15), and a proposal execution process (see Fig. 16).

[0087] <Account transfer processing> FIG. 14 is a sequence diagram showing an example of an account transfer process in this embodiment.

[0088] In step S11, the reception unit 53 included in the user terminal 50 receives an operation by the user to instruct the issuance of an invoice. Before receiving the operation to instruct the issuance of an invoice, the reception unit 53 receives authentication information, such as a tenant ID, which is identification information of the tenant, entered by the user. Then, the communication unit 52 transmits the authentication information to the form management server 10, and the form management server 10 performs a predetermined authentication process. Therefore, the reception unit 53 can receive an operation by the user to instruct the issuance of an invoice only when the user has been authenticated by the form management server 10.

[0089] In step S12, the communication unit 52 of the user terminal 50 sends an invoice issuance request to the document management server 10 in response to an operation to issue an invoice. The issuance request includes the invoice information entered by the user. The invoice information includes information to be written on the invoice, such as the name of the billing recipient, the invoice amount, and the payment due date.

[0090] In step S13, the communication unit 12 included in the document management server 10 receives the invoice issuance request sent by the user terminal 50. Next, the storage control unit 11 stores the received invoice information in the invoice information management DB 1002. At this time, the storage control unit 11 issues an invoice ID that identifies the invoice information.

[0091] Furthermore, if the billing party included in the invoice information is not registered in the customer information management DB 1001, information about the customer is stored in the customer information management DB 1001. At this time, the storage control unit 11 issues a billing party ID that identifies the customer information.

[0092] In step S14, the communication unit 12 included in the document management server 10 creates an invoice based on the registered invoice information and sends it to trading partner company B. The invoice can be sent in a variety of ways, such as by mailing a printed invoice, sending an email with the invoice attached, or notifying the client of a URL (Uniform Resource Locator) link to open the invoice.

[0093] In step S15, the communication unit 12 included in the document management server 10 transmits a registration request for the claim management information to the claim management server 40. The registration request includes the invoice information stored in the invoice information management DB 1002.

[0094] In step S16, the communication unit 42 included in the claim management server 40 receives the request to register the claim management information sent by the document management server 10. Next, the memory control unit 41 stores the claim management information in the claim management information management DB 4001 based on the received invoice information.

[0095] In step S17, the reception unit 53 of the user terminal 50 receives an operation by the user to request an account transfer. The operation is performed by specifying the invoice for which the account transfer is being requested. Note that the user may specify multiple invoices.

[0096] In step S18, in response to an operation instructing an account transfer application, the communication unit 52 included in the user terminal 50 sends an account transfer application request to the account transfer server 20. The application request includes an invoice ID that identifies the specified invoice.

[0097] In step S19, the communication unit 22 included in the account transfer server 20 receives the account transfer application request sent by the user terminal 50. Next, the storage control unit 21 requests the document management server 10 to acquire the invoice information and business partner information identified by the received invoice ID. The acquisition request includes the invoice ID.

[0098] In step S20, the communication unit 12 included in the document management server 10 receives the request to acquire invoice information and customer information sent by the account transfer server 20. Next, the memory control unit 11 reads out the invoice information identified by the received invoice ID from the invoice information management DB 1002. The memory control unit 11 also reads out the customer information identified by the invoice ID included in the read invoice information from the customer information management DB 1001.

[0099] In step S21, the communication unit 12 included in the document management server 10 transmits the invoice information and business partner information read by the memory control unit 11 to the account transfer server 20.

[0100] In step S22, the communication unit 22 included in the account transfer server 20 receives the invoice information and business partner information sent by the document management server 10. Next, the memory control unit 21 stores the account transfer information in the account transfer information management DB 2002 based on the received invoice information and business partner information. At this time, the memory control unit 21 issues a transfer ID that identifies the account transfer information.

[0101] In step S23, the communication unit 22 included in the account transfer server 20 sends an account transfer application based on the registered account transfer information to the account transfer system 3. The application includes a transfer ID, tenant account information, business partner account information, billing amount, transfer date, etc.

[0102] Tenant account information is set in advance by each tenant. Customer account information is included in the customer information. The billing amount is included in the invoice information. The transfer date is automatically set to the transfer date when the next account transfer will be performed.

[0103] In step S24, the account transfer system 3 registers the account transfer application received from the account transfer server 20. Thereafter, the account transfer system 3 requests the financial institution E to execute the registered account transfer on a specified transfer date. In response to the request to execute the account transfer, the financial institution E executes the account transfer.

[0104] <Information collection processing> FIG. 15 is a sequence diagram showing an example of information collection processing in this embodiment.

[0105] In step S31, the information acquisition unit 43 provided in the claim management server 40 uses the communication unit 42 to request the account transfer server 20 to acquire the account transfer result. The communication unit 42 sends a request to acquire the account transfer result to the account transfer server 20. The acquisition request includes the invoice ID of the invoice for which the account transfer result is to be acquired. The invoice to be acquired is, for example, the invoice for which an account transfer was performed on the immediately preceding transfer date.

[0106] In step S32, the communication unit 22 provided in the account transfer server 20 receives the request to obtain the account transfer result sent by the claim management server 40. Next, the memory control unit 21 reads out the account transfer information identified by the received invoice ID from the account transfer information management DB 2002. Next, the communication unit 22 sends a request to obtain the account transfer result to the account transfer system 3. The request includes the transfer ID included in the read account transfer information.

[0107] The account transfer system 3 returns the account transfer result identified by the transfer ID to the account transfer server 20. As a result, the communication unit 22 receives the account transfer result. Then, the memory control unit 21 registers the received account transfer result in the account transfer information management DB2002.

[0108] The memory control unit 21 also updates the account transfer application management DB2001 based on the received account transfer results. Specifically, the memory control unit 21 totals the billed amounts for completed account transfers and registers this total collected amount in the account transfer application table. Furthermore, when all account transfers for the application are completed, the collection result is updated to "collection completed." On the other hand, when there are incomplete account transfers for the application, the collection result is updated to "partially uncollectible."

[0109] In step S33, the communication unit 22 included in the account transfer server 20 transmits to the claim management server 40 the account transfer information in which the account transfer result has been registered.

[0110] In step S34, the communication unit 42 provided in the claim management server 40 receives the account transfer information sent by the account transfer server 20. Next, the memory control unit 41 stores the received account transfer information in the claim management information memory unit 400. The memory control unit 41 also registers the transfer ID included in the received account transfer information in the claim management information management DB 4001.

[0111] The following steps S35 to S42 are executed when there is an incomplete account transfer (that is, an uncollected debt).

[0112] An uncollected debt refers to a situation in which the full amount stated on the invoice has not been paid. Specifically, an uncollected debt is a debt based on an invoice for which the account transfer information transfer result has not yet been marked as "transfer completed."

[0113] In step S35, the information acquisition unit 43 provided in the claim management server 40 requests the claim guarantee server 30 to acquire performance information using the communication unit 42. The communication unit 42 sends a request to acquire performance information to the claim guarantee server 30. The request includes information indicating the billing destination included in the incomplete account transfer information.

[0114] In step S36, the communication unit 32 provided in the claim guarantee server 30 receives the request to acquire performance information sent by the claim management server 40. Next, the memory control unit 31 reads out the received performance information related to the billing destination from the performance information management DB3002.

[0115] In step S37, the communication unit 32 included in the claim guarantee server 30 transmits the read performance information to the claim management server 40.

[0116] In step S38, the communication unit 42 included in the claim management server 40 receives the performance information sent by the claim guarantee server 30. Next, the memory control unit 41 stores the received performance information in the claim management information memory unit 400.

[0117] In step S39, the information acquisition unit 43 included in the claim management server 40 requests the document management server 10 to acquire transaction history information using the communication unit 42. The communication unit 42 sends a request to acquire transaction history information to the document management server 10. The request includes the invoice ID included in the incomplete account transfer information.

[0118] In step S40, the communication unit 12 provided in the document management server 10 receives the request to acquire transaction history information sent by the claim management server 40. Next, the memory control unit 11 reads out the invoice information identified by the received invoice ID from the invoice information management DB 1002.

[0119] Next, the storage control unit 11 reads out invoice information related to the billing destination included in the read invoice information from the invoice information management DB 1002. Specifically, the storage control unit 11 obtains invoice information related to the billing destination stored in an invoice information table related to another tenant. The storage control unit 11 then generates transaction history information based on the read invoice information.

[0120] In step S41, the communication unit 12 included in the document management server 10 transmits the generated transaction history information to the claim management server 40.

[0121] In step S42, the communication unit 42 included in the claim management server 40 receives the transaction history information sent by the document management server 10. Next, the storage control unit 41 stores the received transaction history information in the transaction history information management DB4003.

[0122] The business type of the client included in the transaction history information is read from the credit information management DB 4002. The performance status included in the transaction history information is set to "completed" if a payment date is set, and set to "performance delayed" if the payment due date has passed and no payment date is set. The flag included in the transaction history information is set to "1" if the payment due date and payment date are in the same month, and set to "0" otherwise.

[0123] Figure 13(A) is an example of transaction history information for a certain business partner, Company A. Figure 13(B) is an example of transaction history information for another business partner, Company B. For example, in the transaction history information for Company A, Company C has not paid an invoice to Company A, which is due on June 30, 2021. Therefore, in the transaction history information for that transaction, the performance status is set to "Delayed performance" and the flag is set to "1." Also, for example, in the transaction history information for Company B, Company E paid an invoice to Company B in a month other than the due date. Therefore, in the transaction history information for that business partner, the flag is set to "1."

[0124] Here, we have explained an example in which steps S35 to S42 are executed only for the billing destination of an incomplete account transfer, but steps S35 to S42 may also be executed for all business partners after step S22 shown in Figure 14. In this configuration, if there is a high-risk business partner in the account transfer application, it is possible to issue a warning in advance.

[0125] <Proposal execution process> FIG. 16 is a sequence diagram showing an example of the proposal execution process in this embodiment.

[0126] In step S51, the reception unit 53 included in the user terminal 50 receives an operation by the user to instruct the display of a proposal screen. The operation to instruct the display of the proposal screen is, for example, an operation to press a button on a credit list screen that displays a list of credit management information.

[0127] <<Receivables list screen>> The bond list screen will now be described with reference to Fig. 17. Fig. 17 is a diagram showing an example of the bond list screen in this embodiment.

[0128] As shown in Figure 17, the claim list screen 4100 in this embodiment has a claim list display field 4110 for displaying a list of claim management information managed by the claim management server 40, and a display button 4109 for displaying a proposal screen.

[0129] Of the various debt management information displayed in the debt list display field 4110, debt management information for which the payment due date has passed and the payment status is "unpaid" displays a performance application button 4111 for applying for performance of the debt guarantee for that debt management information.

[0130] When the user presses the display button 4109 on the bond list screen 4100, the reception unit 53 receives an operation to instruct the display of a proposal screen.

[0131] When the user presses the performance application button 4111 on the claim list screen 4100, the reception unit 53 receives the operation to apply for performance of the claim guarantee. When the reception unit 53 receives the operation to apply for performance of the claim guarantee, a process to apply for performance of the claim guarantee is executed for the claim management information corresponding to the button. The process to apply for performance of the claim guarantee will be described later.

[0132] Returning to Figure 16, in step S52, the communication unit 52 of the user terminal 50 requests the claim management server 40 to send screen data for displaying the proposal screen in response to an operation instructing the display of the proposal screen.

[0133] In step S53, the communication unit 42 included in the claim management server 40 receives the request to send the screen data sent by the user terminal 50. Next, the memory control unit 41 reads out the uncollected claim management information from the claim management information management DB 4001. Next, the judgment unit 45 judges the collection action to be taken to collect the claim for each of the read claim management information.

[0134] Action Determination Processing The process of step S53 executed by the determination unit 45 will now be described in more detail with reference to Fig. 18. Fig. 18 is a flowchart showing an example of the behavior determination process corresponding to step S53.

[0135] The action determination process shown in Fig. 18 is executed for each piece of debt management information whose payment status is "unpaid." That is, a proposal that can be selected as one of the collection actions to be taken for collection of each piece of uncollected debt management information is determined.

[0136] In step S53-1, the judgment unit 45 judges the account transfer result. Specifically, the judgment unit 45 identifies the account transfer information by the transfer ID included in the receivable management information to be judged, and obtains the transfer result of the identified account transfer information.

[0137] If the transfer result is "transfer completed", the judgment unit 45 terminates the process. If the transfer result is "insufficient deposit balance", the judgment unit 45 proceeds to step S53-2. If the transfer result is "transfer suspended due to various notifications", the judgment unit 45 proceeds to step S53-8. Furthermore, if the transfer result is "no deposit transaction" or "no account transfer request", the judgment unit 45 proceeds to step S53-9.

[0138] In step S53-2, the judgment unit 45 judges whether a request for performance of a claim guarantee has been made to the business partner within a predetermined period. Specifically, the judgment unit 45 acquires performance information related to the billing party included in the claim management information to be judged. The judgment unit 45 then calculates the number of days from the most recent performance request date among the acquired performance information to the current day, and judges whether the number of days is greater than the predetermined period. The predetermined period may be set arbitrarily, but may be, for example, within one year.

[0139] If there is no request for performance of the claim guarantee within the predetermined period (NO), the judgment unit 45 proceeds to step S53-3. If there is a request for performance of the claim guarantee within the predetermined period (YES), the judgment unit 45 proceeds to step S53-8.

[0140] In step S53-3, the judgment unit 45 judges whether the credit information of the customer is equal to or lower than a predetermined standard. Specifically, the judgment unit 45 reads the credit information corresponding to the billing destination included in the receivable management information to be judged from the credit information management DB 4002, and judges whether the credit information satisfies the predetermined standard.

[0141] The predetermined standard may be set arbitrarily, for example, that the credit information rank is C or higher, or that the rating has not dropped by 10 points or more from the previous year's rating.

[0142] If the credit information is not equal to or less than the predetermined standard (NO), the decision unit 45 proceeds to step S53-4. If the credit information is equal to or less than the predetermined standard (YES), the decision unit 45 proceeds to step S53-8.

[0143] In step S53-4, the judgment unit 45 judges whether or not the transaction between the relevant business partner and another company satisfies predetermined conditions. Specifically, the judgment unit 45 reads out the transaction history information corresponding to the billing party included in the receivable management information to be judged from the transaction history information management DB 4003, and judges whether or not the transaction history information satisfies predetermined conditions.

[0144] The specified conditions may be arbitrarily determined based on business practices or experience. For example, a specified condition may be a case where, in transactions between the relevant business partner and the relevant tenant over a specified period of time (e.g., six months), the payment date for all transactions has been later than the payment due date, but payment has been made within a specified period of time (e.g., within one month) from the payment due date. In such a case, it can be determined that the relevant business partner has a habit of missing payment due dates, but that payment will likely be made in the near future if the business partner waits, so it is safer to wait and see.

[0145] In addition, for example, in transactions between the business partner and other tenants over a predetermined period in the past, the payment date for all transactions was later than the payment due date, but the payment was made within the predetermined period from the payment due date. In such a case, too, it can be judged that it is safer to wait and see, as it is likely that the payment will be made soon if the business partner waits.

[0146] In addition, there may be cases where you want to exclude delays from a specific supplier, for example, if you have received prior notice from that supplier that payment will be delayed. In such cases, you can make it possible to register suppliers to be excluded in advance, and the predetermined condition may be that the supplier in question is included in the suppliers registered as excluded.

[0147] If the transaction with another company does not meet the predetermined conditions (NO), the determination unit 45 proceeds to step S53-5. If the transaction with another company meets the predetermined conditions (YES), the determination unit 45 ends the process.

[0148] In step S53-5, the judgment unit 45 judges whether a demand letter has been sent to the business partner. Specifically, the judgment unit 45 acquires the demand date included in the receivables management information to be judged. If a demand date is set, it is judged that a demand letter has been sent. If no demand date is set, it is judged that a demand letter has not been sent.

[0149] If the determination unit 45 determines that a demand letter has not been sent (NO), the process proceeds to step S53-6. If the determination unit 45 determines that a demand letter has been sent (YES), the process proceeds to step S53-7.

[0150] In step S53-6, the judgment unit 45 determines the proposed collection action for the debt management information to be "send a reminder letter," and terminates the process. The reminder letter may be sent by any method, such as by mailing a printed reminder letter or by sending an email with the reminder letter attached. The document management server 10 may also be configured to send the reminder letter in response to a request from the debt management server 40.

[0151] In step S53-7, the judgment unit 45 judges whether the deadline for dunning has passed. Specifically, the judgment unit 45 acquires the dunning date included in the debt management information to be judged, and judges whether a predetermined period (for example, one month) has passed since the acquired dunning date. Also, for example, the user may arbitrarily set the dunning deadline when sending a dunning notice, and register the dunning deadline in the debt management information.

[0152] If the reminder deadline has passed (YES), the determination unit 45 advances the process to step S53-8. If the reminder deadline has not passed (NO), the determination unit 45 ends the process.

[0153] In step S53-8, the judgment unit 45 determines the collection action to be proposed for the claim management information to be "claim guarantee performance" and ends the process. "Claims guarantee performance" means applying to the claims guarantee system 4 for performance of the claims guarantee for the claim.

[0154] In step S53-9, the judgment unit 45 determines the proposed collection action for the relevant debt management information to be "send notice of transfer impossibility," and ends the process. Sending a notice of transfer impossibility means notifying the user terminal 50 that account transfer cannot be performed using the registered account information.

[0155] If the transfer result shows "No deposit transaction" or "No account transfer request," it is highly likely that there was a problem with the prior procedures, such as incorrect registered account information. In such cases, if the user checks the registered details and performs the procedures again correctly, account transfers will become available. Therefore, if the user is notified of this and the account transfer is performed again, it is expected that the receivable will be collectible.

[0156] Returning to Figure 16, in step S54, the memory control unit 41 included in the claim management server 40 reads screen data for displaying a proposal screen from the screen data memory unit 410. Next, the screen creation unit 44 generates screen data to be displayed on the user terminal 50 based on the screen data read by the memory control unit 41. At this time, the screen creation unit 44 associates the uncollected claim management information with the collection action determined by the determination unit 45, and embeds it in the screen data for displaying the proposal screen.

[0157] In step S55, the communication unit 42 included in the claim management server 40 transmits the screen data generated in step S54 to the user terminal 50.

[0158] In step S56, the communication unit 52 of the user terminal 50 receives screen data for displaying the proposal screen from the claim management server 40. Next, the display control unit 51 displays the proposal screen on the display 506 based on the received screen data.

[0159] ≪Proposal screen≫ The proposal screen will now be described with reference to Fig. 19. Fig. 19 is a diagram showing an example of the proposal screen in this embodiment.

[0160] As shown in Figure 19, the proposal screen 4200 in this embodiment has a dunning proposal display field 4210 for displaying information about invoices for which it is proposed to send a dunning letter, a claim guarantee proposal display field 4220 for displaying information about invoices for which it is proposed to fulfill the claim guarantee, a dunning execution button 4219 for sending a dunning letter, a fulfillment request button 4229 for requesting fulfillment of the claim guarantee, an exit button 4298, and a settings button 4299 for displaying the settings screen.

[0161] The dunning proposal display field 4210 displays information based on the receivables management information for which the judgment unit 45 has determined that the proposed collection action is to "send a dunning letter." Each piece of receivables management information displayed in the dunning proposal display field 4210 displays a radio button 4211 for selecting the receivables management information.

[0162] The claim guarantee proposal display field 4220 displays information based on the claim management information in which the judgment unit 45 has determined that the proposed collection action is "claim guarantee performance." Each piece of claim management information displayed in the claim guarantee proposal display field 4220 displays a radio button 4221 for selecting the claim management information.

[0163] When the user presses the execute reminder button 4219 on the proposal screen 4200, the reception unit 53 receives an operation to send a reminder. When the reception unit 53 receives an operation to send a reminder, a process to send a reminder is executed for the debt management information for which the radio button 4211 is selected.

[0164] When the user presses the performance application button 4229 on the proposal screen 4200, the reception unit 53 receives the operation to apply for performance of the claim guarantee. When the reception unit 53 receives the operation to apply for performance of the claim guarantee, a process to apply for performance of the claim guarantee is executed for the claim management information for which the radio button 4221 is selected.

[0165] When the user presses the end button 4298 on the proposal screen 4200, the display control unit 51 closes the proposal screen 4200. In this case, the collection action displayed on the proposal screen 4200 is not executed. In this way, by providing the end button 4298 on the proposal screen 4200, it is possible to accept, as a user's choice, a decision to wait and see without taking any specific action on uncollected receivables.

[0166] When the user presses the setting button 4299 on the proposal screen 4200, the accepting unit 53 accepts an operation to display a setting screen. In response to the operation to display the setting screen, the display control unit 51 displays on the display 506 a setting screen for setting information used by the determination unit 45 in the behavior determination process.

[0167] In addition, if there is a business partner whose guarantee amount will exceed the maximum guarantee amount if the guarantee is fulfilled for the debt displayed in the debt guarantee proposal display field 4220, the proposal screen 4200 may display information to that effect.

[0168] Specifically, in step S54, the memory control unit 41 reads out the claim guarantee information relating to the claim recipient for the claim for which the collection action has been determined to be "claim guarantee performance" from the claim guarantee information management DB 3001. Next, the screen creation unit 44 determines whether the total amount of the performance history plus the total amount of the claim amount in the claim management information exceeds the maximum guarantee amount in the claim guarantee information. If the screen creation unit 44 determines that the maximum guarantee amount is exceeded, it includes information indicating this in the screen data for displaying the proposal screen 4200.

[0169] <Settings screen> The setting screen will now be described with reference to Fig. 20. Fig. 20 is a diagram showing an example of the setting screen in this embodiment.

[0170] 20, the setting screen 4300 in this embodiment has check boxes 4301 to 4303 for setting whether or not to use the transaction history, account transfer result, and credit information in the behavior determination process, and a confirm button 4309. When the user changes the check status of the check boxes 4301 to 4303 and presses the confirm button 4309, the information to be used in the behavior determination process is set in the determination unit 45.

[0171] If it is set that the transaction history is not used in the behavior determination process, the determination unit 45 skips step S53-4 of the behavior determination process. Also, if it is set that the account transfer result is not used in the behavior determination process, the determination unit 45 skips step S53-1 of the behavior determination process. And, if it is set that the credit information is not used in the behavior determination process, the determination unit 45 skips step S53-3 of the behavior determination process.

[0172] Returning to FIG. 16, in step S57, the reception unit 53 of the user terminal 50 receives an operation by the user instructing the execution of collection actions. This operation is performed by specifying the invoice for which collection actions are to be performed. Note that the user may specify multiple invoices. In the following, the explanation will continue assuming that the user has performed an operation to instruct the performance of the debt guarantee.

[0173] In step S58, in response to an operation instructing the execution of a collection action, the communication unit 52 provided in the user terminal 50 sends a request to execute the collection action to the debt management server 40. The execution request includes information indicating the collection action instructed by the user and an invoice ID that identifies the invoice specified by the user.

[0174] In step S59, the communication unit 42 provided in the claim management server 40 receives the request to execute the collection action sent by the user terminal 50. Next, the execution unit 46 executes the collection action based on the received information indicating the collection action. Here, the execution unit 46 uses the communication unit 42 to request the claim guarantee server 30 to execute the claim guarantee. The communication unit 42 sends a request to execute the claim guarantee to the claim guarantee server 30. The execution request includes an invoice ID that identifies the specified invoice and information indicating the billing destination.

[0175] If the user instructs that a reminder be sent, the execution unit 46 creates the reminder and sends it to business partner company B. If the document management server 10 executes the sending of the reminder, the execution unit 46 sends a request to send the reminder to the document management server 10. In response to the request, the document management server 10 creates the reminder and sends it to business partner company B. The execution unit 46 also uses the memory control unit 11 to register the reminder date in the debt management information management DB 4001. The reminder date is set to the date on which the reminder will be sent.

[0176] In step S60, the communication unit 32 provided in the claim guarantee server 30 receives the claim guarantee performance request sent by the claim management server 40. Next, the memory control unit 31 stores the performance information in the performance information management DB 3002 based on the received claim guarantee performance request. At this time, the performance request date is set to the current date. In addition, the performance status is set to "in performance."

[0177] Next, based on the received claim guarantee performance request, the communication unit 32 transmits a claim guarantee performance application to the claim guarantee system 4. The performance application includes the name of the business partner, the amount claimed, and the like.

[0178] In step S61, the claim guarantee system 4 registers the claim guarantee performance application received from the claim guarantee server 30. Thereafter, an examiner who is an employee of claim guarantee service company F reviews the registered claim guarantee performance application and registers the review results in the claim guarantee system 4. Note that the above-mentioned review may be carried out by the claim guarantee system 4 automatically reviewing the claim guarantee performance application based on specified conditions and automatically settling part or all of the amount related to the performance application, and the method is not important. The claim guarantee system 4 then returns the registered review results to the claim guarantee server 30.

[0179] In step S62, the communication unit 32 provided in the claim guarantee server 30 receives the examination results sent by the claim guarantee system 4. Next, the memory control unit 31 registers the received examination results in the performance information management DB 3002. Specifically, the memory control unit 31 updates the performance status to "performed" and registers the current date as the performance date.

[0180] In step S63, the communication unit 32 provided in the claim guarantee server 30 transmits the received examination results to the user terminal 50. In the user terminal 50, the communication unit 52 receives the examination results transmitted by the claim guarantee server 30. Next, the display control unit 51 displays the received examination results on a proposal screen or the like.

[0181] [Modification] <Warning display based on trading trends> In the information processing system 1 of this embodiment, when a user presses the performance request button 4229 on the proposal screen 4200, a request for performance of a claim guarantee is made to the claim guarantee system 4. At this time, before the request for performance of a claim guarantee is made to the claim guarantee system 4, a warning may be displayed based on the transaction trends of the business partner that is the subject of the request.

[0182] For example, if a certain business partner has intermittently delayed payments in transactions over the past few months, but has since made all payments, it is likely that the business partner has a tendency to be lax on payment deadlines, but that there are no problems with its financial condition. On the other hand, if a certain business partner has always made payments before the due date in past transactions, but a delay occurred in the most recent month's transaction, it is difficult to determine whether the delay is a temporary one or whether its financial condition has deteriorated.

[0183] Such decisions based on transaction trends should be made by users based on more comprehensive information. By warning users before applying for the execution of a credit guarantee, they can be given time to reconsider and avoid inappropriate execution of a credit guarantee.

[0184] Specifically, after the judgment unit 45 determines that the proposed collection action for the outstanding debt management information is "fulfillment of debt guarantee" (step S53-8), it determines whether the transaction history matches the predetermined warning rules. If the warning rules are met, the judgment unit 45 outputs information indicating the transaction tendency along with the proposed collection action. The output information indicating the transaction tendency is embedded in screen data for displaying the proposal screen by the screen creation unit 44 (step S54).

[0185] When the performance request button 4229 is pressed, the proposal screen 4200 displays a confirmation screen having an OK button and a Cancel button (step S57). If the user presses the OK button on the confirmation screen, a request for performance of the claim guarantee is sent to the claim guarantee server 30 (step S58). On the other hand, if the user presses the Cancel button, the claim guarantee performance request is canceled.

[0186] <Information about the debt guarantee service> The information processing system 1 in this embodiment is based on the premise that the service user company A has concluded a contract to use the claim guarantee service with the claim guarantee service company F. Generally, in a claim guarantee service, after concluding a contract to use the claim guarantee service, it is necessary to select in advance the business partners to be covered by the claim guarantee and set the scope of use of the claim guarantee (maximum amount, guarantee period, etc.) for each business partner.

[0187] Therefore, if the tenant service user company A has not signed up for the debt guarantee service, or if the service user company A has signed up for the debt guarantee service but its debt to business partner company B, which is not covered by the debt guarantee, becomes uncollectible, it is advisable to display a message encouraging the use of the debt guarantee service.

[0188] <Proposal execution process> The proposal execution process in this modified example will be described with reference to Fig. 21. Fig. 21 is a sequence diagram showing an example of the proposal execution process in this modified example. The following description will focus on differences from the proposal execution process in the embodiment.

[0189] In step S53B, the determination unit 45 included in the claim management server 40 determines the collection action to be taken to collect the claim for each of the uncollected claim management information.

[0190] Action Determination Processing The behavior determination process in this modified example will be described with reference to Fig. 22. Fig. 22 is a flowchart showing an example of the behavior determination process corresponding to step S53B.

[0191] As shown in FIG. 22, in the behavior determination process of this modification, steps S53-10 and S53-11 are executed before step S53-8 is executed, and depending on the results of these steps, step S53-8 or step S53-12 is executed.

[0192] In step S53-10, the judgment unit 45 determines whether the tenant has contracted for the claim guarantee service. Whether the tenant has contracted for the claim guarantee service can be determined, for example, by having the claim management server 40 store the service usage status of each tenant and reading out the service usage status related to the claim guarantee service when the user logs in to the transaction management system 2 from the user terminal 50.

[0193] If the tenant has signed a contract for the credit guarantee service (YES), the determination unit 45 proceeds to step S53-11. If the tenant has not signed a contract for the credit guarantee service (NO), the determination unit 45 proceeds to step S53-12.

[0194] In step S53-11, the judgment unit 45 judges whether the business partner of the credit management information to be judged is eligible for the credit guarantee service. The judgment as to whether the business partner is eligible for the credit guarantee service can be made by reading the credit guarantee information for the business partner from the credit guarantee information management DB 3001 and referring to the guarantee status included in the credit guarantee information.

[0195] If the customer is a target of the credit guarantee service (YES), the judgment unit 45 proceeds to step S53-8. If the customer is not a target of the credit guarantee service (NO), the judgment unit 45 proceeds to step S53-12.

[0196] In step S53-12, the decision unit 45 determines the collection action to be proposed for the debt management information to be "Debt Guarantee Service Information."

[0197] Returning to Figure 21, in step S56, the communication unit 52 of the user terminal 50 receives screen data for displaying a proposal screen from the claim management server 40. Next, the display control unit 51 displays the proposal screen on the display 506 based on the received screen data.

[0198] In step S71, the reception unit 53 included in the user terminal 50 receives an operation by the user to instruct the display of a guidance screen. The operation to instruct the display of the guidance screen is, for example, an operation to press a button on the proposal screen. Next, the display control unit 51 displays the guidance screen on the display 506 in response to the operation to instruct the display of the guidance screen.

[0199] <Proposal screen and information screen> The proposal screen and the guide screen in this modified example will now be described with reference to Fig. 23 and Fig. 24. Fig. 23 and Fig. 24 are diagrams showing examples of the proposal screen and the guide screen in this modified example.

[0200] 23(A) is a diagram showing an example of a proposal screen 4400 that is displayed when a tenant has not yet signed up for a claim guarantee service. As shown in Fig. 23(A), the proposal screen 4400 has a message display field 4401 for displaying a message encouraging the tenant to sign up for the claim guarantee service, a claim display field 4402 for displaying information about uncollected claims, and a details confirmation button 4409 for displaying a guidance screen.

[0201] When the accepting unit 53 accepts an operation in which the user presses the confirm details button 4409 on the proposal screen 4400, the display control unit 51 displays a guide screen 4410 as shown in FIG.

[0202] 23(B) is a diagram showing an example of a guidance screen 4410 that is displayed when a tenant has not yet signed up for a claim guarantee service. As shown in Fig. 23(B), the guidance screen 4410 has a plan display field 4411 for displaying multiple claim guarantee service plans available to the tenant, and a contract button 4419 for starting the contract process for the selected claim guarantee service.

[0203] The plans of the debt guarantee service displayed in the plan display field 4411 are plans available to the service using company A from among the plans offered by the debt guarantee service of debt guarantee service company F, which is affiliated with service providing company C. If there are many plans available to the service using company A, it is sufficient to select a predetermined number of optimal plans in consideration of the current number of business partners of business partner company B or the total amount of debt, etc.

[0204] 24(A) is a diagram showing an example of a proposal screen 4420 that is displayed when the business partner of the uncollected receivable is not eligible for the receivable guarantee service. As shown in FIG. 24(A), the proposal screen 4420 has a message display field 4421 for displaying a message encouraging the customer to expand the receivable guarantee service plan, a receivable display field 4422 for displaying information about the uncollected receivable, and a details confirmation button 4429 for displaying a guidance screen.

[0205] When the accepting unit 53 accepts an operation in which the user presses the confirm details button 4429 on the proposal screen 4420, the display control unit 51 displays a guide screen 4430 as shown in FIG.

[0206] 24(B) is a diagram showing an example of a guidance screen 4430 that is displayed when the business partner of the uncollected debt is not eligible for the debt guarantee service. As shown in FIG. 24(B), the guidance screen 4430 has a plan display field 4431 for displaying the currently contracted plan and multiple plans that expand the scope of the debt guarantee, and a contract button 4439 for starting the contract process for the selected debt guarantee service.

[0207] The plan for expanding the scope of the receivables guarantee displayed in the plan display field 4431 is the most suitable plan selected from among the plans available to the service using company A, taking into consideration the current number of business partners of the business partner company B or the total amount of the receivables, as in the plan display field 4411 shown in Figure 23(B).

[0208] Returning to Fig. 21, in step S72, the reception unit 53 of the user terminal 50 receives an operation by the user to instruct the user to sign a contract for the credit guarantee service. This operation is performed by specifying a plan for the credit guarantee service.

[0209] In step S73, in response to an operation instructing a contract for a claim guarantee service, the communication unit 52 included in the user terminal 50 transmits an application request for a claim guarantee contract to the claim guarantee server 30. The application request includes information indicating the specified plan.

[0210] In step S74, the communication unit 32 included in the claim guarantee server 30 receives the request for application for a claim guarantee contract sent by the user terminal 50. Next, based on the received application request, the communication unit 32 sends an application for a claim guarantee contract to the claim guarantee system 4. The application includes information about the tenant, information about the business partner, information indicating the plan, etc.

[0211] [Major Effects of the Embodiments] In this embodiment, the debt management server 40 creates a proposal screen for proposing actions to collect each outstanding debt based on debt management information acquired from other servers included in the transaction management system 2, and displays the proposal screen on the user terminal 50. This makes it easier for service-using companies to decide on actions to collect outstanding debts.

[0212] For example, if multiple receivables remain uncollected, it will be easier to determine which receivables should be given priority for performance of the receivable guarantee. Also, even if a receivable remains uncollected, if there is a high probability that payment will be made in the near future based on the business practices of the client, it will be possible to decide not to take action to collect the receivables, but to wait for the payment to arrive.

[0213] Furthermore, in the modified example, when there are uncollected claims from tenants who are not using the claim guarantee service or from business partners who are not covered by the claim guarantee service, the claim management server 40 creates a guidance screen to guide users to use the claim guarantee service and displays it on the user terminal 50. This allows companies using the service to consider more reliable means of collecting claims, and claim guarantee service companies can increase the use of their claim guarantee service.

[0214] [supplement] In the embodiment described above, an example was described in which payment was made by an account transfer service, but the payment method is not limited to this. For example, the present invention can also be applied to payment at a convenience store using a transfer slip, or payment by credit card, etc.

[0215] In the embodiment described above, an example was described in which a collection action was proposed when there was an incomplete account transfer, but the situation in which the proposal is made is not limited to this. For example, when a user sends a document such as an estimate or invoice created by the document management service to a business partner, by performing the determination process described in step S53 on the business partner to which the document is sent, it is possible to issue a warning if the business partner to which the document is sent is a business partner that may be subject to the performance of a claim guarantee.

[0216] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" in this specification includes a processor programmed to perform each function by software, such as a processor implemented by an electronic circuit, as well as devices such as an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), or a conventional circuit module designed to perform each function described above.

[0217] Although the embodiments of the present invention have been described in detail above, the present invention is not limited to these embodiments, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims. [Explanation of symbols]

[0218] 1. Information Processing Systems 2. Transaction Management System 3. Direct debit system 4. Debt Guarantee System 10. Report Management Server 20 Account Transfer Server 30. Debt Guarantee Server 40 Credit management server 50 User terminals 11, 21, 31, 41 Memory control unit 12, 22, 32, 42, 52 Communications Department 43 Information Acquisition Department 44 Screen Creation Department 45 Judgment Department 46 Executive Department 51 Display control unit 53 Reception 100 Form management information storage unit 200 Account transfer information storage unit 300 Debt guarantee information storage unit 400 Debt management information storage unit 410 Screen data storage unit [Prior art documents] [Patent documents]

[0219] [Patent Document 1] Japanese Patent Application Laid-Open No. 2004-70975

Claims

1. An information processing device capable of communicating with a user terminal used by a user, an acquisition unit that acquires credit management information indicating the collection status of credits claimed by the user from business partners; a communication unit that transmits screen data to the user terminal for displaying a proposal screen that proposes options for collecting the debt whose collection status indicates that it is uncollected; Equipped with the proposal screen displays information about the claim for which performance of the claim guarantee is proposed; The claim management information includes account transfer information including the result of account transfer based on the claim, and claim guarantee information indicating the performance status of claim guarantees to the business partner, a determination unit that determines the selection of the claim based on the account transfer information and the claim guarantee information, Information processing device.

2. 2. The information processing device according to claim 1, the determination unit determines the selection for the claim for which the account transfer is incomplete based on the reason why the account transfer is incomplete and the performance history of the claim guarantee for the business partner. Information processing device.

3. 3. The information processing device according to claim 2, The claim management information further includes transaction history information including the issuance status or collection status of claims that other users have claimed from the business partner, the proposal screen displays information indicating the trading tendency of the trading partner based on the trading history information; Information processing device.

4. 2. The information processing device according to claim 1, the communication unit transmits to the user terminal screen data for displaying a guide screen that displays information regarding the bond guarantee according to the user's usage status of the bond guarantee; Information processing device.

5. An information processing system in which a user terminal used by a user and an information processing device can communicate with each other, The information processing device includes: an acquisition unit that acquires credit management information indicating the collection status of credits claimed by the user from business partners; a communication unit that transmits screen data to the user terminal for displaying a proposal screen that proposes options for collecting the debt whose collection status indicates that it is uncollected; Equipped with The user terminal a communication unit that transmits a request for acquiring screen data for displaying the proposal screen to the information processing device in response to an operation by the user; a display control unit that displays the proposal screen based on the screen data transmitted by the information processing device; Equipped with the proposal screen displays information about the claim for which performance of the claim guarantee is proposed; The claim management information includes account transfer information including the result of account transfer based on the claim, and claim guarantee information indicating the performance status of claim guarantees to the business partner, the information processing device further includes a determination unit that determines the selection of the claim based on the account transfer information and the claim guarantee information; Information processing system.

6. A computer that can communicate with a user terminal used by a user, an acquisition step of acquiring credit management information representing the collection status of credits claimed by the user from business partners; a communication procedure for transmitting screen data to the user terminal for displaying a proposal screen for proposing options for collecting the debt whose collection status indicates that it is uncollected; Run the proposal screen displays information about the claim for which performance of the claim guarantee is proposed; The claim management information includes account transfer information including the result of account transfer based on the claim, and claim guarantee information indicating the performance status of claim guarantees to the business partner, and further performing a determination step of determining the selection of the bond based on the account transfer information and the bond guarantee information. Information processing methods.

7. 7. The information processing method according to claim 6, The determination step determines the selection for the claim for which the account transfer is incomplete based on the reason why the account transfer is incomplete and the performance history of the claim guarantee for the business partner. Information processing methods.

8. 8. The information processing method according to claim 7, The claim management information further includes transaction history information including the issuance status or collection status of claims that other users have claimed from the business partner, the proposal screen displays information indicating the trading tendency of the trading partner based on the trading history information; Information processing methods.

9. 7. The information processing method according to claim 6, the communication procedure includes transmitting screen data to the user terminal for displaying a guide screen that displays information about the bond guarantee according to the user's usage status of the bond guarantee; Information processing methods.

10. A computer that can communicate with the user terminal used by the user, an acquisition step of acquiring credit management information representing the collection status of credits claimed by the user from business partners; a communication procedure for transmitting screen data to the user terminal for displaying a proposal screen for proposing options for collecting the debt whose collection status indicates that it is uncollected; Execute the proposal screen displays information about the claim for which performance of the claim guarantee is proposed; The claim management information includes account transfer information including the result of account transfer based on the claim, and claim guarantee information indicating the performance status of claim guarantees to the business partner, a determination step of determining the selection of the bond based on the account transfer information and the bond guarantee information; program.

Images