JP7601078B2 - Information processing device, information processing method, information processing program, and information processing system - Google Patents

Description

The present invention relates to an information processing device, an information processing method, an information processing program, and an information processing system.

Conventionally, a warranty service device is known that, when a business entity incurs a claim, acquires a warranty claim including claim information, and, in the event of default, claims insurance money for the claim related to the debt and executes the process of paying the guarantee money to the business entity that is the creditor.

The conventional technology described above does not take into consideration the need to understand the status of transactions between businesses and their business partners before and after a default occurs.

The present invention was made in consideration of the above circumstances, and aims to allow companies to understand the status of transactions with business partners.

The disclosed technology is an information processing device having a registration unit that stores in a memory unit guarantee registration information that corresponds together business partner information indicating a business partner, invoice information for the business partner, and information input from a terminal device indicating the contents of a guarantee for a claim against the business partner, and a screen output unit that references the memory unit and displays on a display unit, for each of a plurality of business partners, transaction status information indicating the status of a transaction with the business partner and information indicating the contents of the guarantee.

This allows you to understand the status of transactions with business partners.

FIG. 1 is a diagram illustrating an example of a system configuration of an information processing system according to an embodiment of the present invention. FIG. 2 illustrates an example of a hardware configuration of an information processing device. FIG. 2 illustrates an example of a hardware configuration of a terminal device. FIG. 13 is a diagram illustrating an example of an invoice database. FIG. 2 is a diagram illustrating an example of a business partner database. FIG. 11 is a diagram illustrating an example of a warranty registration database. FIG. 13 is a diagram illustrating an example of a performance history database. FIG. 2 is a diagram illustrating the functional configuration of each device in the information processing system. FIG. 11 is a first sequence diagram illustrating an operation of the information processing system. FIG. 2 is a second sequence diagram illustrating the operation of the information processing system. FIG. 1 is a first diagram showing a home screen. FIG. 13 is a diagram showing another display example of the display field. FIG. 13 is a diagram showing an example of a supplier selection screen. FIG. 13 is a diagram showing an example of a registration screen. FIG. 11 is a third sequence diagram illustrating the operation of the information processing system. FIG. 13 is a diagram showing an example of a list screen of application information. FIG. 13 is a diagram showing an example of an input screen for warranty details. FIG. 4 is a fourth sequence diagram illustrating the operation of the information processing system. 13 is a first flowchart illustrating the processing of a risk assessment unit. FIG. 11 is a diagram illustrating an example of a determination result table. FIG. 2 is a second diagram showing the home screen. FIG. 13 is a diagram showing an example of a list screen of performance history information. FIG. 5 is a fifth sequence diagram illustrating the operation of the information processing system. FIG. 2 is a diagram illustrating an example of a quotation database. 13 is a second flowchart illustrating the processing of the risk assessment unit.

The embodiment will be described below with reference to the drawings. Figure 1 is a diagram showing an example of the system configuration of an information processing system according to this embodiment.

The information processing system 1 of this embodiment includes a transaction management system 100 and a terminal device 400.

The transaction management system 100 has a document management device 200 and a transaction management device 300. The document management device 200 and the transaction management device 300 of this embodiment may be realized, for example, by a general information processing device. For example, the transaction management device 300 of this embodiment is a first information processing device, and the document management device 200 is a second information processing device.

In addition, the transaction management system 100 of this embodiment communicates with the terminal device 400 and the claim guarantee management system 500.

In the transaction management system 100 of this embodiment, the terminal device 400 is, for example, a terminal device used by a business operator who conducts transactions with various business partners. Note that the business operator in this embodiment may be an individual or an organization such as a company or corporation. In the following description of the embodiment, the business operator who is the user of the terminal device 400 may be referred to as a tenant. Also, the user who actually operates the terminal device 400 may be referred to as a tenant.

The credit guarantee management system 500 is managed by a credit guarantee institution or the like that provides a service to guarantee the credit related to the debt in the event of a default by a business partner of the business using the terminal device 400.

In the following description, the services provided to tenants by the claim guarantee management system 500 may be referred to as claim guarantee services.

The claim guarantee service of this embodiment is a service in which, when a tenant is unable to pay the claim amount due to a lack of funds on the part of the business partner or other reasons, the claim amount is paid to the tenant by the claim guarantee institution that manages the claim guarantee management system 500 within a predetermined upper guarantee limit.

In this embodiment, a claim is a right that allows a tenant to demand payment of the invoice amount from a business partner who has issued an invoice, and is a right that a tenant has against a business partner.

Note that the receivable in this embodiment is not limited to an invoice issued by the tenant to a business partner, but may also be a right of the tenant to request payment for goods, services, etc. from a business partner based on documents such as purchase orders and receipts received by the tenant from the business partner, and documents such as quotations and delivery notes issued by the tenant to the business partner.

The claim guarantee management system 500 of this embodiment includes a claim guarantee management device 600 and a terminal device 700. The claim guarantee management device 600 stores, for example, information input from the terminal device 700 and information acquired through communication with the transaction management system 100. The terminal device 700 is used by the administrator of the claim guarantee management system 500, etc.

In the transaction management system 100 of this embodiment, the document management device 200 has an invoice database 210, a customer database 220, and a document management section 230. Also, in the transaction management system 100, the transaction management device 300 has a warranty registration database 310 and a performance history database 320.

In this embodiment, the transaction management system 100 receives a request from a tenant via the terminal device 400 and registers a business partner that uses the claim guarantee service in the claim guarantee management system 500.

Specifically, the transaction management system 100 stores information on forms issued from tenants to business partners in the invoice database 210 by the form management unit 230 of the form management device 200. Note that in the following description of the embodiment, an invoice is described as an example of a form, but the form is not limited to an invoice. The form may be an estimate, a delivery note, etc.

The form management device 200 also stores information indicating the business partner identified from the invoice information in the business partner database 220 by the form management unit 230. In the following explanation, the information stored in the business partner database 220 is referred to as business partner information. A business partner is, in other words, the party to whom the invoice amount is billed.

In addition, in the document management device 200, the document management unit 230 receives a request from the terminal device 400 to register customer information in the credit guarantee management system 500, and transmits the invoice information of the tenant using the terminal device 400 and the customer information to the transaction management device 300.

The transaction management device 300 transmits invoice information and customer information to the credit guarantee management system 500 via the transaction management section 330, and accepts input of information indicating the guarantee content. The transaction management section 330 then associates the customer information with the information indicating the guarantee content and stores it in the guarantee registration database 310. In the following description, the information stored in the guarantee registration database 310 is referred to as guarantee registration information.

In addition, upon receiving a request from the terminal device 400, the transaction management device 300 causes the terminal device 400 to display a list of warranty registration information for each of the tenant's business partners.

Furthermore, when a default on a debt occurs, the transaction management device 300, upon receiving a request from the terminal device 400, requests the debt guarantee management system 500 to guarantee the debt related to the debt via the transaction management section 330. In other words, the transaction management device 300 requests the debt guarantee management system 500 to fulfill the debt for this transaction.

Then, the transaction management unit 330 stores in the performance history database 320 performance history information indicating the history of the performance of the obligation, which indicates that the performance of the obligation was requested, that the obligation was performed, etc.

In this way, the transaction management system 100 of this embodiment can present the status of transactions between the tenant and each business partner to the tenant.

In addition, in this embodiment, the tenant's business partners are identified from the information on the forms managed by the form management device 200 and are registered as business partners that use the claim guarantee service provided by the claim guarantee management system 500, so there is no need for the tenant to enter information about the business partners. Therefore, in this embodiment, the effort required to use the claim guarantee service can be easily reduced.

In the example of FIG. 1, the transaction management system 100 includes the document management device 200 and the transaction management device 300, but is not limited to this. The document management device 200 and the transaction management device 300 may be realized, for example, by a single information processing device, or each of the document management device 200 and the transaction management device 300 may be realized by multiple information processing devices.

In the example of FIG. 1, the document management device 200 has an invoice database 210 and a customer database 220, and the transaction management device 300 has a warranty registration database 310 and a performance history database 320, but this is not limited to the above.

The above-mentioned databases may be provided in part or in whole in an external device other than the document management device 200 or the transaction management device 300. Also, for example, the above-mentioned four databases may be provided in either the document management device 200 or the transaction management device 300.

Below, the hardware configuration of the information processing device that realizes the document management device 200 and the transaction management device 300, and the hardware configuration of the terminal device 400 will be described with reference to Figures 2 and 3.

Figure 2 is a diagram showing an example of the hardware configuration of an information processing device. Figure 2 shows an example of the hardware configuration of a form management device 200, which is a second information processing device.

The document management device 200 is constructed by a computer, and as shown in FIG. 2, includes a CPU 201, a ROM 202, a RAM 203, a HD 204, a HDD (Hard Disk Drive) controller 205, a display 206, an external device connection I/F (Interface) 208, a network I/F 209, a bus line B1, a keyboard 211, a pointing device 212, a DVD-RW (Digital Versatile Disk Rewritable) drive 214, and a media I/F 216.

Of these, the CPU 201 controls the overall operation of the document management device 200. The ROM 202 stores programs used to drive the CPU 201, such as IPL. The RAM 203 is used as a work area for the CPU 201. The HD 204 stores various data such as programs. The HDD controller 205 controls the reading or writing of various data from the HD 204 according to the control of the CPU 201. The display 206 displays various information such as a cursor, menu, window, character, or image. The external device connection I/F 208 is an interface for connecting various external devices. In this case, the external device is, for example, a USB (Universal Serial Bus) memory or a printer. The network I/F 209 is an interface for data communication using a communication network. The bus line B1 is an address bus or a data bus for electrically connecting each component such as the CPU 201 shown in FIG. 2.

The keyboard 211 is a type of input means equipped with multiple keys for inputting characters, numbers, various instructions, etc. The pointing device 212 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. The DVD-RW drive 214 controls the reading and writing of various data from a DVD-RW 213, 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 216 controls the reading and writing (storing) of data from a recording medium 215, such as a flash memory.

Figure 3 is a diagram showing an example of the hardware configuration of a terminal device. The terminal device 400 of this embodiment includes a CPU 401, a ROM 402, a RAM 403, an EEPROM 404, a CMOS sensor 405, an image sensor I/F 406, an acceleration/orientation sensor 407, a media I/F 409, and a GPS receiver 411.

Of these, CPU 401 is an arithmetic processing device that controls the operation of the entire terminal device 400. ROM 402 stores CPU 401 and programs used to drive CPU 401, such as IPL. RAM 403 is used as a work area for CPU 401. EEPROM 404 reads or writes various data, such as smartphone programs, under the control of CPU 401. ROM 402, RAM 403, and EEPROM 404 are examples of storage devices of terminal device 400.

The CMOS (Complementary Metal Oxide Semiconductor) sensor 405 is a type of built-in imaging means that captures an image of a subject (mainly a self-portrait) under the control of the CPU 401 to obtain image data. Note that instead of a CMOS sensor, the imaging means may be a CCD (Charge Coupled Device) sensor or other such device.

The imaging element I/F 406 is a circuit that controls the driving of the CMOS sensor 405. The acceleration/direction sensor 407 is a variety of sensors, such as an electronic magnetic compass that detects geomagnetism, a gyrocompass, and an acceleration sensor. The media I/F 409 controls the reading and writing (storage) of data from and to a recording medium 408, such as a flash memory. The GPS receiver 411 receives GPS signals from GPS satellites.

The terminal device 400 also includes a long-distance communication circuit 412, an antenna 412a of the long-distance communication circuit 412, a CMOS sensor 413, an image sensor I/F 414, a microphone 415, a speaker 416, an audio input/output I/F 417, a display 418, an external device connection I/F (Interface) 419, a short-distance communication circuit 420, an antenna 420a of the short-distance communication circuit 420, and a touch panel 421.

Of these, the long-distance communication circuit 412 is a circuit that communicates with other devices via a communication network. The CMOS sensor 413 is a type of built-in imaging means that captures an image of a subject and obtains image data under the control of the CPU 401. The image sensor I/F 414 is a circuit that controls the operation of the CMOS sensor 413. The microphone 415 is a built-in circuit that converts sound into an electrical signal. The speaker 316 is a built-in circuit that converts electrical signals into physical vibrations to produce sounds such as music and voice. The audio input/output I/F 417 is a circuit that processes the input and output of audio signals between the microphone 415 and the speaker 416 under the control of the CPU 401.

The display 418 is a type of display means such as a liquid crystal or organic EL (Electro Luminescence) that displays an image of a subject, various icons, etc. The external device connection I/F 419 is an interface for connecting various external devices. The short-range communication circuit 430 is a communication circuit such as NFC (Near Field Communication) or Bluetooth (registered trademark). The touch panel 421 is a type of input means that allows a user to operate the terminal device 400 by pressing the display 418. The display 418 is an example of a display unit that the terminal device 400 has.

Next, with reference to Figures 4 to 7, we will explain each database of the transaction management system 100 of this embodiment.

Figure 4 shows an example of an invoice database. In this embodiment, the invoice database 210 is provided for each tenant. Invoice information is accumulated in the invoice database 210 as tenants issue invoices to business partners.

In this embodiment, the invoice database 210 includes information items such as tenant ID, invoice destination, invoice amount, invoice date, payment due date, payment status, and payment date.

The value of the item "Tenant ID" indicates identification information for identifying a tenant. The identification information for identifying a tenant may be, for example, the name of the tenant.

The value of the "Billing party" item indicates the party to which the invoice amount will be billed. In other words, the value of the "Billing party" item is the business partner of the tenant identified by the tenant ID.

The value of the "Amount invoiced" field indicates the amount invoiced, and the value of the "Invoice date" field indicates the date the invoice was issued. The value of the "Payment due date" field indicates the date by which the invoice amount is due.

The value of the item "Payment Status" indicates whether the invoiced amount has been paid, and is changed in response to operations from the terminal device 400. In addition, in the invoice information, an invoice amount for which the value of the item "Payment Status" is "Unpaid" is the amount currently being traded between the tenant and the business partner. The value of the item "Deposit Date" indicates the date on which the invoiced amount was deposited into the bank account, etc., of the tenant ID.

In addition, invoice image data or storage destination information such as a file path indicating the storage destination of the image data may be stored in the invoice database 210 as invoice information.

In this way, the invoice information in this embodiment can be said to be information regarding a bill to a business partner.

Figure 5 is a diagram showing an example of a customer database. In this embodiment, the customer database 220 may be provided for each tenant. In addition, the customer information in this embodiment is registered by the tenant.

In this embodiment, the customer database 220 includes information items such as tenant ID, customer name, address, telephone number, email address, and person in charge.

In the business partner database 220, the values of the items "business partner name," "address," "telephone number," "email address," and "person in charge" indicate the business partner's name, address, telephone number, email address, and name of the person in charge.

Figure 6 is a diagram showing an example of a warranty registration database. The warranty registration database 310 includes information items such as tenant name, business partner name, address, transaction start date, whether or not there is a payment delay, application status, maximum warranty amount, and warranty period. In the warranty registration database 310, the item "tenant name" is associated with other items. In the following explanation, information in the warranty registration database 310 that includes the value of the item "tenant name" and the values of the other items is referred to as warranty registration information.

The value of the item "Tenant Name" indicates the name of the tenant. The value of the item "Customer Name" is the name of the customer indicated by the value of the item "Customer Name" in the customer database 220. The value of the item "Address" indicates the address of the customer. The value of the item "Transaction Start Date" indicates the date on which the tenant and customer started trading. Specifically, the registration unit 333 may set the oldest billing date included in the invoice information stored in the invoice database 210 as the transaction start date.

The value of the item "Whether or not there is a delay in payment" indicates whether or not there is a delay in payment of the invoice amount from the business partner to the tenant. Specifically, when there is invoice information stored in the invoice database 210 for which the payment due date has passed and the value of the item "Payment status" is "Unpaid," the registration unit 333 sets the value of the item "Whether or not there is a delay in payment" to "Yes."

The value of the "Application Status" item indicates whether or not the claim guarantee service is available. Specifically, if the value of the "Application Status" item is "Reviewed", it indicates that the claim guarantee service is available for this business partner. Also, if the value of the "Application Status" item is "Under Review", or if there is no value for the "Application Status" item, it indicates that the claim guarantee service is not available for this business partner.

The value of the "Maximum guaranteed amount" field indicates the maximum amount guaranteed to the business partner. The value of the "Guarantee period" field indicates the period during which the debt guarantee service can be used by the business partner.

In other words, the warranty registration information in this embodiment includes at least a portion of the business partner information, a portion of the invoice information, and information indicating the warranty details for the business partner.

Figure 7 is a diagram showing an example of a performance history database. The performance history database 320 of this embodiment includes information items such as tenant name, business partner name, billing amount, billing date, payment due date, performance status, performance execution date, maximum guarantee amount, guarantee period, etc.

In the performance history database 320, the item "tenant name" is associated with other items, and information including the value of the item "tenant name" and the values of other items in the performance history database 320 is referred to as performance history information.

The value of the "Performance Status" field indicates the status of the obligation's performance. The value of the "Performance Execution Date" field indicates the date on which the obligation's performance was executed.

In addition, image data of the invoice to be fulfilled or storage destination information such as a file path indicating the storage destination of the image data may be stored in the fulfillment history database 320 as fulfillment history information.

Next, the functions of each device of the transaction management system 100 of this embodiment will be described with reference to FIG. 8. FIG. 8 is a diagram illustrating the functional configuration of each device of the information processing system.

First, the form management device 200 will be described. The form management device 200 of this embodiment has an invoice database 210, a supplier database 220, and a form management unit 230. The invoice database 210 and the supplier database 220 are realized by storage devices such as the ROM 202, RAM 203, and HD 204 of the form management unit 230. The form management unit 230 is realized by the CPU 201 reading and executing a form recognition program.

The document management unit 230 includes a document recognition unit 231, a request reception unit 232, an erasure unit 233, a communication unit 234, and a document generation unit 235.

The form recognition unit 231 extracts the names of items (item names) and the values of these items (item values) contained in the form image shown by the form image data acquired by the form management device 20, and performs form recognition by converting the items and item values into text data and associating them. The form recognition unit 231 then stores the form recognition result, which is the result of the form recognition, in the invoice database 210. In this embodiment, since an invoice is an example of a form, information indicating the form recognition result becomes invoice information.

The request reception unit 232 receives various requests to the document management device 200. Specifically, the request reception unit 232 receives requests to obtain invoice information and customer information from the transaction management device 300.

The erasing unit 233 accepts an operation from the terminal device 400 to change the value of the item "payment status" included in the invoice information stored in the invoice database 210. Specifically, the erasing unit 233 changes the value of the item "payment status" from "unpaid" to "paid" in response to an operation from the terminal device 400.

The communication unit 234 transmits and receives information between the form management device 200 and each of the other devices. The form generation unit 235 issues invoices in response to operations from the terminal device 400, and stores the invoice information of the issued invoices in the invoice database 210.

Next, we will explain the transaction management device 300. The transaction management device 300 has a warranty registration database 310, a performance history database 320, and a transaction management section 330.

The guarantee registration database 310 and the performance history database 320 are realized by storage devices such as ROM, RAM, and HD of the transaction management device 300. The transaction management section 330 is realized by the CPU of the transaction management device 300 reading and executing a transaction management program.

The transaction management unit 330 of this embodiment has an input reception unit 331, an information acquisition unit 332, a registration unit 333, a performance management unit 334, a risk assessment unit 335, a screen output unit 336, and a communication unit 337.

The input reception unit 331 receives various inputs to the transaction management device 300. Specifically, the input reception unit 331 receives, for example, a request for registration to enable the use of the credit guarantee service. The input reception unit 331 also receives inputs such as information indicating the details of the guarantee for the business partner from the terminal device 700 of the credit guarantee management system 500.

The information acquisition unit 332 acquires various types of information. Specifically, for example, the information acquisition unit 332 acquires invoice information and business partner information from the document management device 200.

The registration unit 333 associates the acquired business partner information with the information indicating the warranty content accepted by the input acceptance unit 331, and registers (stores) it in the warranty registration database 310.

The performance management unit 334 stores performance history information in the performance history database 320 when operations related to the performance of a debt are performed, when a debt is performed through a credit guarantee service, etc. In other words, the performance management unit 334 updates the performance history database 320.

The risk assessment unit 335 assesses the degree of risk of transactions between the tenant and the business partner based on the information indicating the guarantee contents for each business partner stored in the guarantee registration database 310 and the invoice information for each business partner, and stores the result as a assessment result table 339.

More specifically, the risk assessment unit 335 calculates the amount of the transaction with each business partner from the invoice information, and assesses the degree of risk of the transaction with the business partner based on the amount of the transaction, information indicating the guarantee details for each business partner, and whether or not there is a payment delay.

The risk assessment unit 335 then stores in the assessment result table 339 transaction status information that associates the amount of the transaction, information indicating the guarantee details for each trading partner, whether or not there is a payment delay, and the degree of risk of the transaction with the trading partner.

Details of the processing of the risk assessment unit 335 and the assessment result table 339 will be described later.

The screen output unit 336 generates screen data for displaying various screens and outputs it to the terminal device 400, the terminal device 700, etc. via the communication unit 337.

The communication unit 337 transmits and receives information between the transaction management device 300 and each of the other devices.

The terminal device 400 of this embodiment has a display control unit 440 and a communication unit 454500. The display control unit 440 controls the display on the terminal device 400. The display control unit 440 may be realized, for example, by a browser or the like, or may be realized by an application for using a credit guarantee service or the like.

The communication unit 450 transmits and receives information between the terminal device 400 and each of the other devices. Note that the terminal device 700 of this embodiment may also have a display control unit and a communication unit, similar to the terminal device 400.

Next, the operation of the transaction management system 100 of this embodiment will be described. Figure 9 is a first sequence diagram that explains the operation of the information processing system. Figure 9 shows the operation of the transaction management system 100 when storing invoice information and business partner information in the document management device 200.

In the transaction management system 100 of this embodiment, the document management device 200 causes the document generation unit 235 of the document management unit 230 to display an invoice issuance screen on the terminal device 400 (step S901).

In addition, the document management device 200 may display the issuance screen on the terminal device 400, for example, by accessing a specific URL (Uniform Resource Locator) on the terminal device 400 or by clicking a link or button displayed on the screen.

Next, the terminal device 400 accepts settings of invoice information from the tenant (user belonging to the tenant) (step S902). Specifically, the terminal device 400 accepts settings of, for example, the invoice destination, invoice amount, invoice date, payment due date, etc.

Next, the terminal device 400 accepts an invoice issuance operation from the tenant (step S903) and transmits the invoice information to the document management device 200 via the communication unit 450 (step S904).

Next, when the form management device 200 receives the invoice information, the form generation unit 235 performs a process to issue an invoice (step S905). Specifically, the form management device 200 may generate PDF data of the invoice based on the invoice information received by the communication unit 234, for example, and send the PDF data to a pre-set email address of the billing destination, etc.

Next, the document management device 200 stores the invoice information in the invoice database 210 (step S906).

In addition, the document management device 200 of this embodiment may receive image data generated by scanning an invoice from the terminal device 400, and perform document recognition on the image (image of the invoice) indicated by this image data by the document recognition unit 231, and use the result as invoice information.

Figure 10 is a second sequence diagram explaining the operation of the information processing system. Figure 10 shows the operation of the transaction management system 100 when registering warranty registration information in the warranty registration database 310 in the transaction management device 300.

In the transaction management system 100 of this embodiment, the transaction management device 300 causes the screen output unit 336 to display the home screen of the claim guarantee service on the terminal device 400 (step S1001). Details of the home screen will be described later.

When the terminal device 400 receives an operation to register business partner information via the communication unit 450 (step S1002), the terminal device 400 transmits a business partner registration request to the transaction management device 300 (step S1003).

Upon receiving the request to register customer information, the transaction management device 300 transmits, via the information acquisition unit 332, a request to the document management device 200 to acquire a list of billing destinations (customers) included in the tenant's invoice information (step S1004).

The document management device 200 receives the request through the request receiving unit 232 and obtains a list of business partners (step S1005). Specifically, the document management device 200 obtains the value of the item "billing destination" from the invoice database 210 of the tenant corresponding to the terminal device 400 as a list of business partners.

Next, the document management device 200 transmits the list of business partners to the transaction management device 300 via the communication unit 234 (step S1006).

When the transaction management device 300 acquires the list of business partners, the screen output unit 336 generates screen data for displaying a business partner selection screen (step S1007). Then, in response to the business partner information registration operation, the transaction management device 300 transmits the generated screen data to the terminal device 400 via the communication unit 337, causing the terminal device 400 to display the selection screen (step S1008). Details of the selection screen will be described later.

When the terminal device 400 accepts the selection of a trading partner on the selection screen (step S1009), it transmits the selected trading partner name to the transaction management device 300 (step S1010).

When the transaction management device 300 receives the customer name, the information acquisition unit 332 sends a request to the document management device 200 to acquire the customer information corresponding to the customer name (step S1011).

When the request receiving unit 232 receives the request, the document management device 200 retrieves supplier information from the supplier database 220 whose value in the "Name" field matches the selected supplier name, and transmits the information to the transaction management device 300 (step S1012).

When the transaction management device 300 acquires the trading partner information through the information acquisition unit 332, the registration unit 333 sets the acquired trading partner information as part of the warranty registration information stored in the warranty registration database 310 (step S1013).

Next, the transaction management device 300 sends a request to the document management device 200 to obtain invoice information for the selected business partner (step S1014).

When the request receiving unit 232 receives a request to obtain invoice information, the document management device 200 retrieves invoice information from the invoice database 210 corresponding to the tenant, in which the value of the "invoice destination" item matches the selected business partner, and transmits the invoice information to the transaction management device 300 (step S1015).

Next, the transaction management device 300 uses the registration unit 333 to identify information to be registered as warranty registration information from the acquired invoice information, and sets it as part of the warranty registration information (step S1016).

Specifically, the registration unit 333 sets the oldest billing date among the billing dates included in the acquired invoice information as the value of the "transaction start date." Furthermore, if there is invoice information that is unpaid even though the payment due date has passed, the registration unit 333 sets the value of the warranty registration information item "Whether or not payment is delayed" to "Yes."

In other words, the registration unit 333 in this embodiment includes information on specific predetermined items from the invoice information as part of the warranty registration information.

Then, the transaction management device 300, through the registration unit 333, associates the business partner information set in step S1013 with part of the invoice information set in step S1015 to prepare warranty registration information, and stores (registers) it in the warranty registration database 310 (step S1017).

Note that the warranty registration information stored in the warranty registration database 310 at this time does not include information indicating the contents of the warranty, such as items such as "application status," "maximum warranty amount," and "warranty period."

Next, the transaction management device 300 generates screen data for displaying a registration screen including the warranty registration information via the screen output unit 336, and transmits the screen data via the communication unit 337 to the terminal device 400 for display (step S1018).

When the registration screen including the warranty registration information is displayed on the terminal device 400, the tenant modifies the warranty registration information (step S1019). The modified content is reflected in the warranty registration database 310.

The processing from step S1014 to step S1017 in FIG. 10 may be executed each time a transaction is made between a tenant and a business partner. In other words, the warranty registration database 310 may be updated each time a transaction is made between a tenant and a business partner. A transaction includes, for example, the issuance of an invoice from the tenant to the business partner, and the payment of the invoice amount from the business partner to the tenant.

Below, examples of displays on the terminal device 400 will be described with reference to Figures 11 to 13. Figure 11A is a first diagram showing the home screen.

The screen 111 shown in FIG. 11A is, for example, an example of a home screen when using a claim guarantee service, and is displayed on the terminal device 400 in step S1002 of FIG. 10.

Screen 111 displays the tenant name and has display field 112 and display field 113. Display field 112 displays a list of business partner names registered as business partners that use the credit guarantee service. In other words, display field 112 displays a list of business partner names whose guarantee registration information is stored in the guarantee registration database 310.

In addition, in display field 112, along with each business partner's name, information indicating the guarantee details for each business partner and transaction status information indicating the status of the transaction between the tenant and the business partner are displayed.

In FIG. 11A, display column 112 includes display columns 112-1, 112-2, 112-3, etc., and in each display column, along with the business partner name, information indicating the guarantee details for each business partner, the amount of the transaction between the tenant and the business partner, and whether or not there is a payment delay are displayed. In other words, display columns 112-1, 112-2, and 112-3 display transaction status information for each business partner. Also, display column 112-4 displays display component 115 instead of the business partner name.

Display field 113 displays a list of transaction status information for each business partner. In addition, for business partners with late payments in the list displayed in display field 113, display component 114 is displayed to request the execution of debt performance.

In the example of FIG. 11A, the display field 113 displays a list of warranty registration information for business partners, but this is not limited to this. For example, the display field 113 may display a list of invoice information for each business partner.

Specifically, for example, the display field 113 may display a list of invoice information for each business partner.

Figure 11B shows another example of the display field 113. Figure 11B shows another example of the display field.

Display field 113A shown in FIG. 11B displays a list of invoice information for invoices issued to each business partner whose transaction status information is displayed in display field 112.

Specifically, display field 113A displays invoice information for each business partner, such as the invoice recipient, invoice amount, and payment due date (see Figure 4).

When the current date is past the payment due date and the payment status of the invoice information is "unpaid," display column 113A determines that the invoice information is past due and displays "overdue" as the value of the "overdue" item. Display column 113A also displays display component 114A in association with invoice information whose "overdue" item value is "overdue." Display component 114A is a display component for instructing the execution of debt performance.

In addition, the display field 113 may be blank, for example, if no business partners that use the credit guarantee service are registered. In that case, only the display component 112-5 may be displayed in the display field 112.

When the display component 115 is selected on the screen 111, the transaction management device 300 of this embodiment accepts this as an operation to register a new business partner, and transitions the display of the terminal device 400 from the home screen to a business partner selection screen.

Figure 12 is a diagram showing an example of a business partner selection screen. Screen 121 shown in Figure 12 is an example of a business partner selection screen displayed on terminal device 400 in step S1008 of Figure 10.

In addition, screen 121 may be displayed in a pop-up format on screen 111 shown in FIG. 11.

Screen 121 displays a list of names of business partners that are not registered as business partners using the credit guarantee service, from the list of business partners obtained in step S1006 of FIG. 10.

When a trading partner name is selected on screen 121, the transaction management device 300 performs processing from step S1010 onward in FIG. 10, and transitions the display on the terminal device 400 from screen 121 to a registration screen, which will be described later.

Figure 13 is a diagram showing an example of a registration screen. Screen 131 shown in Figure 13 is an example of a registration screen displayed on terminal device 400 in step S1019 of Figure 10.

Screen 131 has a display field 132 and display components 133 and 134. Display field 132 displays warranty registration information that corresponds the business partner information set in step S1013 of FIG. 10 with the information identified from the invoice information in step S1016.

In the example of FIG. 13, in display field 132, supplier information including the supplier's company name, address, etc., the transaction start date identified from the claim information, whether there is a payment delay, etc. are displayed as warranty registration information.

In other words, the warranty registration information in this embodiment includes business partner information acquired from the document management device 200 and information extracted from the invoice information acquired from the document management device 200 based on predetermined conditions, etc.

Display component 113 is a display component for canceling the storage of the guarantee registration information in the guarantee registration database 310. Display component 114 is a display component for storing the guarantee registration information in the guarantee registration database 310 and requesting (applying for) an examination of the guarantee contents to the credit guarantee management system 500.

In this embodiment, when the display component 114 is selected on the screen 131 of the transaction management device 300, a process is performed to request the credit guarantee management system 500 to review the guarantee details.

Figure 14 is a third sequence diagram explaining the operation of the information processing system. Figure 14 shows the operation of the transaction management system 100 when the transaction management device 300 requests the credit guarantee management system 500 to review the guarantee contents.

In the transaction management system 100, when the terminal device 400 receives an operation by a tenant to select a request (application) for review of the guarantee contents (operation to select the display component 134) (step S1401), the terminal device 400 transmits an application request to the transaction management device 300 (step S1402).

Upon receiving this request, the transaction management device 300 stores the application status in the warranty registration information stored in the warranty registration database 310 via the registration unit 333 (step S1403).

Specifically, the registration unit 333 sets the value of the item "application status" to "under review" for the guarantee registration information in the guarantee registration database 310 where the value of the item "tenant name" matches the business partner name. At this time, the transaction management device 300 may send a notification indicating a request for review to the terminal device 700 of the credit guarantee management system 500.

In the claim guarantee management system 500, when the terminal device 700 receives an operation to instruct the display of application information (step S1404), the terminal device 700 transmits this request to the transaction management device 300 (step S1405). The terminal device 700 is operated, for example, by an administrator of the claim guarantee management system 500.

Next, the transaction management device 300 generates screen data for displaying a list of application information through the screen output unit 336, and displays the application information list screen on the terminal device 700 (step S1406). Details of the application information list screen will be described later.

Next, the terminal device 700 accepts input of the warranty details for the applied business partner (step S1407). Next, the terminal device 700 accepts an operation to register information indicating the entered warranty details (step S1408).

When the terminal device 700 accepts this operation, it transmits information indicating the guarantee contents and a registration request for this message driver's room 10 to the transaction management device 300 (step S1409).

The transaction management device 300 receives this request through the input reception unit 331, and stores information indicating the warranty content in the warranty registration database 310 through the registration unit 333 (step S1410). At this time, the registration unit 333 associates the business partner for which a request for review of the warranty content has been made with the information indicating the warranty content, and stores them in the warranty registration database 310.

Figure 15 is a diagram showing an example of a list screen of application information. Screen 151 shown in Figure 15 is an example of a screen displayed on the terminal device 700 in step S1406 of Figure 14.

Display field 152 and display components 153, 154, and 155 are displayed on screen 151. Display field 152 displays warranty registration information stored in warranty registration database 310. Display field 152 also displays display component 156, which is associated with warranty registration information whose "application status" field has a value of "under review." Display component 156 is a display component for transitioning screen 151 to an input screen for warranty details.

Warranty registration information in which the value of the item "Application Status" is "Under Review" is warranty registration information in which the input of information indicating the warranty content has not been completed. Specifically, for example, it is warranty registration information that does not include values for at least one of the items "Maximum Warranty Amount" and "Warranty Period".

Display component 153 is a display component for displaying all warranty registration information stored in warranty registration database 310 in display field 152. When display component 153 is operated, warranty registration information whose "application status" item has the value "under review" and warranty registration information whose "application status" item has the value "reviewed" are displayed in the display field.

Display component 154 is a display component for displaying only warranty registration information stored in warranty registration database 310 for which the value of the item "Application status" is "Under review."

Display component 155 is a display component for switching between a list screen of application information and a screen related to debt performance, which will be described later.

When display component 156 is operated on screen 151, the display on the terminal device 700 transitions from screen 151 to an input screen for the warranty details, which will be described later.

Figure 16 is a diagram showing an example of an input screen for the warranty details. Screen 161 shown in Figure 16 is an example of a screen displayed on the terminal device 700 in step S1407 of Figure 14.

Display fields 162, 163, and display components 164, 165 are displayed on screen 161. Display field 162 displays business partner information, and display field 16 displays an input field for warranty details.

Display component 164 is a display component for canceling the storage of information indicating the warranty contents stored in warranty registration database 310. Display component 165 is a display component for storing information indicating the entered warranty contents in warranty registration database 310.

In this embodiment, when information indicating the guarantee content is entered into the display field 163 on the terminal device 700 and the display component 165 is operated, the terminal device 700 transmits a registration request for the information indicating the guarantee content to the transaction management device 300.

In the example of FIG. 16, a request to register warranty registration information for a business partner named "Company A" is sent to the transaction management device 300. Company A's warranty registration information includes Company A's business partner information, the transaction start date identified from the invoice information, whether there is a payment delay, the maximum warranty amount, and the warranty period.

When the transaction management device 300 receives this registration request, the registration unit 333 associates the received information indicating the warranty content with the trading partner information displayed in the display field 162 of the screen 161, and registers (stores) it in the warranty registration database 310.

At this stage, the warranty registration information stored in the warranty registration database 310 contains business partner information and information indicating the warranty details.

In this embodiment, the information (examination results) indicating the guarantee contents of the trading partner is received from the credit guarantee management system 500 via a network, but this is not limited to this. The information indicating the guarantee contents may be directly input to the transaction management device 300 by, for example, an administrator of the credit guarantee management system 500. In this case, the screen 151 shown in FIG. 15 and the screen 161 shown in the image setting memory unit 16 may be displayed on a display device such as a display connected to the transaction management device 300.

Next, referring to FIG. 17, the operation of the transaction management system 100 when requesting a guarantee from a credit guarantee service for a default on a debt will be described. FIG. 17 is a fourth sequence diagram illustrating the operation of the information processing system.

In the transaction management system 100, when the terminal device 400 receives a display operation of the home screen from a tenant (step S1701), it sends a display request of the home screen to the transaction management device 300 (step S1702).

Next, the transaction management device 300, via the information acquisition unit 332, identifies one of the tenant's business partners that is registered as a business partner that will use the credit guarantee service, and sends a request to the document management device 200 to acquire invoice information for this business partner (step S1703).

Upon receiving this request, the document management device 200 retrieves the corresponding invoice information from the invoice database 210 and transmits it to the transaction management device 300 (step S1704). At this time, the document management device 200 transmits all of the invoice information, including that of the identified supplier, to the transaction management device 300.

When the transaction management device 300 receives the invoice information of the identified supplier, the risk assessment unit 335 determines an index indicating the risk in the transaction between this supplier and the tenant (step S1705). In other words, the transaction management device 300 derives information indicating the status of the transaction between the tenant and the supplier using the risk assessment unit 335. The processing of step S1705 will be described in detail later.

The transaction management device 300 performs the processes from step S1703 to step S1705 for all business partners registered as business partners using the credit guarantee service, and the screen output unit 336 generates screen data for displaying a home screen including the results (step S1706).

Next, the transaction management device 300 causes the terminal device 400 to display the home screen based on this screen data (step S1707). The information for each trading partner obtained in the processes from step S1703 to step S1705 is displayed in the display field 112 of the home screen 111 (see FIG. 11).

Next, the terminal device 400 accepts the selection of a business partner on the home screen (step S1708). Upon accepting the selection of a business partner, the terminal device 400 displays a list of invoice information for the selected business partner information on the home screen (step S1709).

Next, when the terminal device 400 receives an operation from the tenant instructing the performance of the debt (step S1710), it sends a debt performance request to the transaction management device 300 (step S1711).

When the transaction management device 300 receives a performance request, the performance management unit 334 generates performance history information, and the registration unit 333 stores the performance history information in the performance history database 320 (step S1712).

Specifically, the performance management unit 334 obtains the tenant name, the selected business partner name, the billing amount to the business partner, the billing date, the payment deadline, the maximum guarantee amount, and the guarantee period from the guarantee registration database 310, and stores the performance history information with the performance status set to "in progress" in the performance history database 320 (see FIG. 7).

When a performance request is received, the performance management unit 334 may obtain necessary information, such as image data of the invoice to be fulfilled, from the document management device 200, generate performance history information, and store it in the performance history database 320.

Next, the terminal device 700 receives an operation from the administrator of the credit guarantee management system 500, etc., instructing the display of a list screen of performance history information (step S1713). The terminal device 700 receives this operation and transmits a display request for the list of performance history information to the transaction management device 300 (step S1714).

The screen output unit 336 of the transaction management device 300 generates screen data for displaying a list of performance history information, and causes the terminal device 700 to display the performance history list screen (step S1715). Details of the performance history list screen will be described later.

When the terminal device 700 receives an operation indicating that the debt has been fulfilled (step S1716), it sends a notification to the transaction management device 300 indicating that the debt has been fulfilled (step S1717).

Upon receiving this notification, the transaction management device 300 causes the performance management unit 334 to update the value of the "Performance Status" item in the performance history information stored in the performance history database 320 in step S1712 to "Performed" (step 1718).

Next, referring to FIG. 18, the processing of the risk assessment unit 335 in step S1705 of FIG. 7 will be described. FIG. 18 is a first flowchart illustrating the processing of the risk assessment unit.

In this embodiment, the risk assessment unit 335 calculates the total invoice amount of invoice information with a payment status of unpaid among the invoice information of a certain business partner obtained from the document management device 200 (step S1801). In the following explanation, the total calculated in step S1801 is referred to as total value A. Total value A is the amount currently being traded between the tenant and the business partner.

The risk assessment unit 335 then identifies invoice information whose payment status is unpaid and whose payment deadline has passed, and calculates the total value of the invoice amounts whose payment deadline has passed (step S1802). In the following explanation, the total value calculated in step S1802 is referred to as total value B.

Then, the risk assessment unit 335 determines whether the value of the sum B is greater than 0 (step S1803). In other words, the risk assessment unit 335 determines whether there is any unpaid amount whose payment deadline has passed.

In step S1803, if the total value B is 0, that is, if there is no outstanding amount that is past due, the risk assessment unit 335 proceeds to step S1806, which will be described later.

In step S1803, if the total value B is greater than 0, that is, if there is an unpaid amount that is past the payment deadline, the risk assessment unit 335 determines whether the total value B exceeds the guaranteed upper limit amount (step S1804).

In other words, the risk assessment unit 335 determines whether the unpaid amount that is past the due date can be fully recovered by the credit guarantee service.

If the total value B exceeds the guaranteed upper limit amount in step S1804, the risk assessment unit 335 determines that the risk in the transaction with this trading partner is "high" (step S1805) and ends the process.

In step S1804, if the total value B does not exceed the guaranteed upper limit amount, the risk assessment unit 335 proceeds to step S1809, which will be described later.

If the sum B is 0 in step S1803, the risk assessment unit 335 determines whether the sum A is less than or equal to the guaranteed upper limit amount (step S1806).

In step S1806, if the sum A is not less than the guaranteed upper limit amount, that is, if the sum A exceeds the guaranteed upper limit amount, the risk assessment unit 335 determines that the risk in the transaction with this trading partner is "medium" (step S1807), and ends the process.

In step S1806, if the total value A is equal to or less than the guaranteed upper limit amount, the risk assessment unit 335 determines that the risk in the transaction with this trading partner is "low" (step S1808) and ends the process.

Also, in step S1804, if the sum B does not exceed the guaranteed upper limit amount, the risk assessment unit 335 determines whether the sum A is equal to or less than the guaranteed upper limit amount (step S1809).

In step S1809, if the total value A is not less than the guaranteed upper limit amount, the process proceeds to step S1805. In other words, if there is an unpaid amount that is past due and the amount billed to the business partner exceeds the guaranteed upper limit amount, the risk assessment unit 335 assesses the risk of the transaction with this business partner as "high."

In step S1809, if the total value A is equal to or less than the guaranteed upper limit amount, the risk assessment unit 335 proceeds to step S1809. In other words, if there is an unpaid amount that is past due and the amount billed to the business partner is less than the guaranteed upper limit amount, the risk assessment unit 335 determines that the risk of the transaction with this business partner is "medium."

The risk assessment unit 335 of this embodiment performs the process of FIG. 18 for each trading partner registered as a trading partner that uses the credit guarantee service, and stores the risk assessment results in the assessment result table 339.

In addition, the risk assessment unit 335 of this embodiment may, for example, after performing a risk assessment, calculate the ratio of the total value A (the total of unpaid invoice amounts) to the guaranteed upper limit amount and store it in the assessment result table 339.

The process shown in FIG. 18 may be executed, for example, each time the warranty registration database 310 is updated; in other words, the process shown in FIG. 18 may be executed each time a transaction is conducted between a tenant and a business partner.

Figure 19 is a diagram showing an example of a judgment result table. The judgment result table 339 of this embodiment is generated for each tenant. The judgment result table 339 has the following information items: tenant ID, business partner name, guaranteed upper limit amount, total value A, ratio, total value B, and risk judgment result. In the judgment result table 339, the item "business partner name" is associated with other items, and information including the value of the item "business partner name" and the values of the other items may be expressed as transaction status information. The transaction status information is information that indicates the status of transactions between tenants and business partners. In other words, the risk judgment unit 335 of this embodiment calculates the transaction status information. The business partner information may be updated each time the guarantee registration database 310 is updated.

The value of the "Total Value A" item indicates the total amount of invoices whose payment status is unpaid in transactions between the corresponding business partner and tenant. The value of the "Ratio" item indicates the ratio of Total Value A to the guaranteed upper limit amount.

The value of the item "Total Value B" indicates the total amount of invoices that are unpaid and past due in transactions between the corresponding business partner and tenant. The value of the item "Risk Assessment Result" indicates an index of risk when conducting a transaction between the tenant ID and business partner.

In the example of Figure 19, the tenant name "Company X" has companies B, C, D, E, and F as its business partners. Of these, Company B's total value A is less than the upper guarantee amount, and the total value B is 0. The ratio is also low at 5%. For this reason, the risk for Company X when doing business with Company B is considered to be "low."

Furthermore, for Company C, total value A is less than the guaranteed upper limit amount, but total value B exists. Therefore, the risk for Company X when trading with Company C is considered to be "medium." For Company D, both total values A and B are greater than the guaranteed upper limit amount. Therefore, the risk for Company X when trading with Company D is considered to be "high."

In this embodiment, when the transaction management device 300 displays the home screen on the terminal device 400, it references this determination result table 339 to generate screen data for displaying the home screen.

Figure 20 is a second diagram showing the home screen. Screen 111A shown in Figure 20 shows that, among the business partners of tenant "Company X," "Company A" has been newly registered as a business partner that uses the credit guarantee service, and that Company D's debt has been fulfilled through the credit guarantee service.

Screen 111A includes display fields 112A and 113A. Display field 112A displays display fields 112-1, 112-2, 112-3, 112-4, etc.

Display field 112-1 displays the name of Company B (client name) in the judgment result table 339, a marker 171 indicating the risk of trading with Company B, and trading status information 172.

Specifically, according to Company B's transaction status information, the guaranteed upper limit is 10 million yen, the total unpaid invoice amount is 500,000 yen, and there is no unpaid amount that is past the payment deadline (see Figure 19).

Therefore, marker 171 is a marker indicating a risk assessment result of "low," and transaction status information 172 shows a guaranteed upper limit of 10 million yen, a total of unpaid invoice amounts of 500,000 yen, and an amount of unpaid amounts past the payment deadline of 0.

In addition, the display field 112-1 displays the maximum guaranteed amount, so information showing the details of Company B's guarantee is displayed.

Display field 112-2 displays the name of Company B (client name) in the judgment result table 339, a marker 173 indicating the risk of trading with Company C, and trading status information 174.

Specifically, Company C's transaction status information shows that the guaranteed upper limit is 5 million yen, the total unpaid invoice amount is 3 million yen, and the amount of unpaid money that is past the payment deadline is 500,000 yen (see Figure 19).

Therefore, marker 173 indicates that the risk assessment result is "medium," and transaction status information 174 shows that the guaranteed upper limit is 5 million yen, the total unpaid invoice amount is 3 million yen, and the unpaid amount that is past the payment deadline is 500,000 yen.

In addition, the display field 112-2 displays the maximum guaranteed amount, so information showing the details of Company C's guarantee is displayed.

Display field 112-3 displays the name of Company D (client name) in the judgment result table 339, a marker 175 indicating the risk of transactions with Company D, and transaction status information 176.

Specifically, in Company D's transaction status information, the guaranteed upper limit is 2 million yen, the total unpaid invoice amount is 1.5 million yen, and the amount of unpaid money that is past the payment deadline is 1.5 million yen (see Figure 19).

Therefore, marker 175 indicates that the risk assessment result is "high," and transaction status information 176 shows that the guaranteed upper limit is 3 million yen, the total unpaid invoice amount is 2 million yen, and the unpaid amount that is past the payment deadline is 1.5 million yen.

In addition, the display field 112-3 displays the maximum guaranteed amount, so information showing the details of Company D's guarantee is displayed.

Note that the display modes of the markers 171, 173, and 175 may be different from each other, and are not limited to the display mode shown in FIG. 20. The markers 171, 173, and 175 may be, for example, other than markers, and may be the direct display of the risk assessment results of the assessment result table 339.

In addition, in this embodiment, the display in display fields 112 and 113 is updated every time the customer information is updated.

In this manner, in this embodiment, a list of transaction status information showing the status of transactions between the tenant and each business partner is presented to the tenant. In other words, in this embodiment, for each tenant, a list of the tenant's business partners, the amount in transaction (amount outstanding), and the maximum guaranteed amount is presented to the tenant.

Therefore, this embodiment allows tenants to easily understand the status of transactions with each business partner.

In addition, in this embodiment, the home screen also displays a list of information indicating the guarantee details for each of the tenant's business partners. Therefore, according to this embodiment, it is possible to present the tenant with a list of the details guaranteed by the credit guarantee service for each business partner.

In addition, in this embodiment, when registering a business partner who will use the claim guarantee service in the transaction management device 300, a specific display component in the display field 112 is selected to display a list of business partners, and the business partner can be registered for the claim guarantee service simply by selecting the business partner from this list. Therefore, in this embodiment, the time and effort required for a tenant to manually input business partner information in order to use the claim guarantee service can be reduced, and the use of the claim guarantee service can be easily registered for each business partner.

Next, we will explain the display field 113. The display field 113 displays a list of transaction status information for each trading partner.

Here, when an operation is performed in display field 112A to select a display field corresponding to a particular business partner, a list of invoice information for the selected business partner may be displayed in display field 113.

In this case, for example, invoice information whose payment status is unpaid or invoice information whose payment is delayed may be highlighted. Also, display component 114 may be displayed in display field 113 in association with the highlighted invoice information.

In this way, by displaying the display component 114 for instructing the fulfillment of a debt in association with unpaid invoice information, it is possible to instruct the fulfillment of a debt for each invoice information.

In addition, in the display field 113 shown in FIG. 20, a display component 114 is displayed in association with Company D, whose risk assessment result is "high."

When the terminal device 400 receives an operation to select the display component 114 on the screen 111A, it sends a request for performance of the debt of Company D to the transaction management device 300.

The transaction management device 300 may send a notification to the credit guarantee management system 500 indicating that it has accepted Company D's request for performance of the debt.

The terminal device 700 transmits a display request to the transaction management device 300 for a performance history information list screen, including the performance history information of Company D. FIG. 21 shows an example of the performance history information list screen.

Screen 151A shown in FIG. 21 is displayed on the terminal device 700 in step S1715 of FIG. 17. Screen 151A has a display field 152A, and display components 153, 154A, 155, and 156A.

Display field 152A displays a list of performance history information stored in performance history database 320.

Display component 154A is a display component for displaying only performance history information whose performance status is "in progress" in display field 152A.

Display component 156A is a display component that is displayed in association with performance history information whose performance status is "in performance." In display field 152A, the performance history information of Company D is displayed in association with display component 156A. When terminal device 700 receives an operation to select display component 156A, it may transition screen 151A to a screen for confirming whether or not the debt has been performed.

In addition, in the list of performance history information displayed in display field 152A, a button for viewing image data of the invoice corresponding to the performance history information may be displayed for each performance history information.

When the transaction management device 300 of this embodiment receives a notification from the credit guarantee management system 500 indicating that the performance of the debt has been completed, it changes the performance status in the performance history database 320 from "in performance" to "performed." The transaction management device 300 then reflects the results of the debt performance or execution in the total value A, total value B, etc. in the guarantee registration database 310.

Next, the cancellation operation in the transaction management system 100 of this embodiment will be described with reference to FIG. 22. Cancellation refers to receiving payment for the invoice amount and changing the payment status in the invoice information stored in the invoice database 210 to "paid."

Figure 22 is a fifth sequence diagram explaining the operation of the information processing system. In the transaction management system 100 of this embodiment, the document management device 200 causes the terminal device 400 to display a reconciliation screen (step S2201). Note that the reconciliation screen may be displayed from the document management device 200 to the terminal device 400 periodically, for example.

Then, the terminal device 400 accepts an operation to set the invoice information to be cleared (step S2202). The terminal device 400 then accepts input of clearing information (step S2203). The terminal device 400 then accepts a clearing operation to instruct clearing (step S2204).

When the terminal device 400 accepts the cancellation operation, it sends a cancellation request for the corresponding invoice information to the document management device 200 (step S2205).

Upon receiving the reconciliation request, the transaction management device 300 executes the reconciliation of the corresponding invoice information (step S2206). Specifically, the document management device 200 uses the reconciliation unit 233 to identify the corresponding invoice information in the invoice database 210, and changes the "payment status" item of the identified invoice information from "unpaid" to "paid." The above process completes the reconciliation of the unpaid amount.

In this embodiment, an invoice has been described as an example of a form, but, for example, a quotation may also be an example of a form. In other words, in this embodiment, the warranty registration information includes transaction status information, information identified from invoice information, and information indicating the warranty content, but this is not limited to this. The information included in the warranty registration information may include transaction status information, information identified from invoice information, information identified from quotation information, and information indicating the warranty content.

Figure 23 is a diagram showing an example of a quotation database. The quotation database 210A shown in Figure 23 stores quotation information. The quotation information includes information items such as quote recipient, estimated amount, quotation date, planned billing date, planned deadline, status, order date, billing date, payment date, invoice ID, etc.

The value of the "Quoted To" field is the business partner to whom the quote is issued. The value of the "Estimated Amount" field is the estimated amount listed on the quote. The value of the "Estimated Date" field indicates the date on which the quote was issued. The value of the "Scheduled Invoice Date" field indicates the planned date on which the invoice is to be issued. The value of the "Scheduled Payment Due Date" field indicates the planned date on which payment of the invoice amount is due.

The value of the "Status" item indicates the status of the transaction. The value of the "Order Date" item indicates the date the order for the quotation was received. The value of the "Invoice Date" item indicates the date the invoice corresponding to the quotation was issued. The value of the "Payment Date" item indicates the date the invoice amount was received. The value of the "Invoice ID" item indicates identification information for identifying the invoice corresponding to the quotation.

In this embodiment, for example, the quotation database 210A may be referenced when the risk assessment unit 335 assesses risk.

Below, with reference to FIG. 24, a case where the risk assessment unit 335 assesses risk using invoice information and quotation information is described. FIG. 24 is a second flowchart explaining the processing of the risk assessment unit.

In the example of FIG. 24, the risk assessment unit 335 calculates the sum of the unpaid invoice amount and the amount obtained by multiplying the estimated amount by the acceptance rate for each of the tenant's business partners, and sets this sum as A' (step S2401).

The order rate indicates the ratio of the number of quotation information records in which a value is entered in the "Order Date" field to the number of quotation information records for a business partner in the quotation database 210A.

For example, if the business partner is Company A, the number of records of quotation information stored in quotation database 210A is four (see FIG. 23). Of these four pieces of quotation information, the number of records of quotation information in which a value has been entered in the "Order Date" field, indicating that an order for the quoted content has actually been received, is zero.

Therefore, in the case of Company A, the estimated amount multiplied by the acceptance rate is 0 yen, and the total value A' is the same as the total value A of the unpaid invoice amount.

The processing from step S2402 to step S2409 in FIG. 24 is the same as the processing from step S18002 to step S1809 in FIG. 18, except that total value A is set to total value A', so a description thereof will be omitted.

In this way, according to this embodiment, a list of information showing the guarantee contents of the trading partner can be presented to the tenant, who is the user of the transaction management system 100 including the transaction management device 300.

In this embodiment, part of the warranty registration information includes part of the invoice information obtained by document recognition, but the warranty registration information does not have to include information obtained by document recognition.

Specifically, for example, part of the invoice information included in the warranty registration information may be obtained separately from a device other than the document management device 200.

Each function of the above-described embodiments can be realized by one or more processing circuits. In this specification, the term "processing circuit" includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, and devices such as an ASIC (Application Specific Integrated Circuit), DSP (digital signal processor), FPGA (field programmable gate array), and conventional circuit modules designed to execute each function described above.

Furthermore, the devices described in the embodiments represent only one of multiple computing environments for implementing the embodiments disclosed herein.

In one embodiment, the document management device 200 includes multiple computing devices, such as a server cluster. The multiple computing devices are configured to communicate with each other over any type of communication link, including a network, shared memory, etc., to perform the processing disclosed herein. Similarly, the document management device 200 can include multiple computing devices configured to communicate with each other.

Furthermore, the form management device 200 can be configured to share the disclosed processing steps in various combinations. For example, the processes executed by the form management device 200 can be executed by other server devices. Similarly, the functions of the form management device 200 can be executed by other server devices. Also, the server device and each element of the other server devices may be integrated into one server device or may be separated into multiple devices.

The correspondence table in the statement may be generated by the learning effect of machine learning. Also, by classifying keywords and account items that may be included in the description of transaction details using machine learning, it is not necessary to use a correspondence table.

Here, machine learning refers to a technology that allows a computer to acquire human-like learning capabilities, in which the computer autonomously generates algorithms necessary for judgments such as data identification from training data that is previously loaded, and applies these to new data to make predictions. The learning method for machine learning may be any of supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, and deep learning, or may be a combination of these learning methods; any learning method for machine learning is acceptable.

The present invention has been described above based on each embodiment, but the present invention is not limited to the requirements shown in the above embodiments. These points can be changed without departing from the spirit of the present invention, and can be appropriately determined according to the application form.

REFERENCE SIGNS LIST 100 Information processing system 200 Document management device 210 Invoice database 220 Supplier database 230 Document management section 300 Transaction management device 310 Guarantee registration database 320 Performance history database 330 Transaction management section 331 Input reception section 332 Information acquisition section 333 Registration section 334 Performance management section 335 Risk judgment section 336 Screen output section 337 Communication section 339 Judgment result table 400, 700 Terminal device 500 Credit guarantee management system 600 Credit guarantee management device

JP 2020-003960 A

Claims (13)

a registration unit that stores in a storage unit guarantee registration information that associates customer information indicating a customer, invoice information for the customer, and information input from a terminal device indicating the details of a guarantee for a claim against the customer;
an information processing device having a screen output unit that refers to the memory unit and displays, for each of the multiple trading partners, transaction status information indicating the status of transactions with the trading partners and information indicating the guarantee content on a display unit. The information processing device according to claim 1, wherein the transaction status information includes at least information indicating the amount of the transaction being made with the trading partner. 3. The information processing apparatus according to claim 2, wherein the amount of the transaction with said business partner is an amount of the transaction calculated based on said invoice information. an information acquisition unit that acquires the business partner information and the invoice information;
The information processing apparatus according to claim 2 , further comprising an input receiving unit for receiving an input of information indicating the guarantee content. a risk determination unit that identifies an amount of the transaction from the invoice information, and determines a risk of a transaction with the trading partner for each trading partner based on the amount of the transaction and information indicating the guarantee content;
The information processing apparatus according to claim 4 , wherein the screen output unit causes the display unit to display a list of the judgment results for each of the business partners. The risk assessment unit
determining the risk based on a maximum guarantee amount included in the information indicating the guarantee content and an amount of the transaction with the trading partner;
6. The information processing apparatus according to claim 5 , further comprising: generating and storing the transaction status information including the guaranteed upper limit amount, the amount of the transaction with the trading partner, and the result of the risk assessment. The amount of the transaction with the said business partner is
The total amount of unpaid invoice amounts invoiced to the business partner,
The risk assessment unit
The information processing apparatus according to claim 6 , wherein the risk is determined using a total amount of the unpaid amount and a total amount of the unpaid amount that is past due for payment. The screen output unit is
The information processing apparatus according to claim 7 , further comprising: a display unit configured to display a list of the transaction status information for each of the business partners. The transaction status information is
9. The information processing device according to claim 7 , wherein the warranty registration information is updated every time the warranty registration information is updated. The information processing apparatus according to claim 3 , wherein the invoice information is acquired by performing form recognition on an invoice issued to the business partner. An information processing method by an information processing device, comprising:
storing in a storage unit guarantee registration information that associates customer information indicating a customer, invoice information for the customer, and information input from a terminal device indicating the details of a guarantee for a claim against the customer;
An information processing method comprising: referring to the storage unit; and displaying, for each of a plurality of said business partners, transaction status information indicating the status of transactions with said business partners and information indicating the guarantee content on a display unit. storing in a storage unit guarantee registration information that associates customer information indicating a customer, invoice information for the customer, and information input from a terminal device indicating the details of a guarantee for a claim against the customer;
An information processing program that causes a computer to execute a process of referring to the memory unit and displaying, for each of the multiple trading partners, transaction status information indicating the status of transactions with the trading partner and information indicating the guarantee content on a display unit. An information processing system including a terminal device and an information processing device,
The information processing device includes:
a registration unit that stores in a storage unit guarantee registration information that associates customer information indicating a customer, invoice information for the customer, and information input from a terminal device indicating the details of a guarantee for a claim against the customer;
a screen output unit that refers to the storage unit and outputs, for each of the plurality of trading partners, transaction status information indicating a transaction status with the trading partner and information indicating the guarantee content to the terminal device,
The terminal device
an information processing system having a display unit that displays, for each of the business partners, transaction status information indicating the status of a transaction with the business partner and information indicating the guarantee content;

Images