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

Abstract

To propose an invoice that considers conditions for both a user and a client.SOLUTION: An information processing apparatus which can communicate with an information processing terminal used by a user over a network includes: a storage control unit which stores, in a storage unit, transaction conditions of a user and payment conditions of a client; and a transmission unit which transmits, to the information processing terminal, screen data for displaying a screen that proposes generation of invoice information according to transaction conditions or invoice information according to the payment conditions.SELECTED DRAWING: Figure 4

Description

Technical Field

[0006] , ,

[0001] This invention relates to an information processing apparatus, an information processing terminal, an information processing system, an information processing method, and a program.

Background Art

[0002] Conventionally, in the write-off process in commercial transactions, the seller collates information such as the amount of payment and the payment date included in the payment information sent from the purchaser with information such as the amount billed and the payment due date described in the invoice, and writes off the accounts receivable related to the invoice. In this case, the seller checks whether the accounts receivable are collected as per the invoice and whether there is any delay in collection (see Patent Document 1).

Summary of the Invention

Problems to be Solved by the Invention

[0003] However, there is a problem that it may take time to confirm the transaction conditions. For example, if there is a discrepancy in the understanding of the transaction conditions and payment conditions between the seller and the purchaser, it is necessary to confirm the billing details or payment details each time, which is a burden for both parties.

[0004] One embodiment of this invention is to propose the generation of invoice information considering the conditions of both the user and the business partner in view of the above technical problems.

Means for Solving the Problems

[0005] In order to solve the above problems, an information processing apparatus according to one embodiment of this invention is an information processing apparatus capable of communicating with an information processing terminal used by a user via a network, and includes a storage control unit that stores the user's transaction conditions and the business partner's payment conditions in a storage unit, A determination unit determines which of the transaction terms and payment terms to prioritize when generating invoice information; an identification unit identifies which items to include in the invoice information from among multiple items included in the accounts receivable ledger information based on the determination result by the determination unit; and based on the items identified by the identification unit... and a transmission unit that transmits screen data for displaying a screen for proposing the generation of invoice information to the information processing terminal.

Effects of the Invention

[0006] According to one embodiment of this invention, it is possible to propose the generation of invoice information that takes into account the conditions of both the user and the business partner. [Brief explanation of the drawing]

[0007] [Figure 1] This is a conceptual diagram illustrating the relationships between the companies in one embodiment of the system. [Figure 2] This figure shows an example of the overall configuration of an information processing system in one embodiment. [Figure 3] This figure shows an example of the hardware configuration of an information processing device in one embodiment. [Figure 4] This figure shows an example of the functional configuration of an information processing system in one embodiment. [Figure 5] This figure shows an example of the condition information registration process in the first embodiment. [Figure 6] This figure shows an example of a transaction conditions setting screen in the first embodiment. [Figure 7] This figure shows an example of a transaction conditions management table in the first embodiment. [Figure 8] This figure shows an example of a payment terms setting screen in the first embodiment. [Figure 9] This figure shows an example of a payment terms management table in the first embodiment. [Figure 10] This figure shows an example of the invoice creation and sending process in the first embodiment. [Figure 11] This figure shows an example of a tenant information management table in the first embodiment. [Figure 12] This figure shows an example of an accounts receivable ledger information management table in the first embodiment. [Figure 13] This figure shows an example of the data creation process for the invoice creation screen in the first embodiment. [Figure 14] This figure shows an example of the invoice creation screen in the first embodiment. [Figure 15] This figure shows an example of the invoice creation screen in the first embodiment. [Figure 16] It is a diagram showing an example of a claim form image in the first embodiment. [Figure 17] It is a diagram showing an example of an issued claim form information management table in the first embodiment. [Figure 18] It is a diagram showing an example of an issued claim form information management table in the first embodiment. [Figure 19] It is a diagram showing an example of an accounts receivable information management table in the first embodiment. [Figure 20] It is a diagram showing an example of an accounts receivable information management table in the first embodiment. [Figure 21] It is a diagram showing an example of a claim form sending screen in the first embodiment. [Figure 22] It is a diagram showing an example of a received information management table in the first embodiment. [Figure 23] It is a diagram showing an example of a claim form receiving process in the first embodiment. [Figure 24] It is a diagram showing an example of a claim form receiving screen in the first embodiment. [Figure 25] It is a diagram showing an example of a received claim form information management table in the first embodiment. [Figure 26] It is a diagram showing an example of a remittance data creation process in the first embodiment. [Figure 27] It is a diagram showing an example of a received claim form list screen in the first embodiment. [Figure 28] It is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 29] It is a diagram showing an example of a payment process screen data creation process in the first embodiment. [Figure 30] It is a diagram showing an example of a payment process screen in the first embodiment. [Figure 31] It is a diagram showing an example of a payment process screen in the first embodiment. [Figure 32] It is a diagram showing an example of a payment information management table in the first embodiment. [Figure 33]This figure shows an example of an accounts payable ledger information management table in the first embodiment. [Figure 34] This figure shows an example of deposit information acquisition and automatic reconciliation processing in the first embodiment. [Figure 35] This figure shows an example of a deposit information management table in the first embodiment. [Figure 36] This figure shows an example of the automatic reconciliation process in the first embodiment. [Figure 37] This figure shows an example of an accounts receivable ledger information management table in the first embodiment. [Figure 38] This figure shows an example of an accounts payable ledger information management table in the first embodiment. [Figure 39] This figure shows an example of the process for creating a deposit management screen in the first embodiment. [Figure 40] This figure shows an example of a deposit management screen in the first embodiment. [Figure 41] This figure shows an example of a deposit management screen in the first embodiment. [Figure 42] This figure shows an example of a transaction conditions setting screen in the second embodiment. [Figure 43] This figure shows an example of a transaction conditions management table in the second embodiment. [Figure 44] This figure shows an example of a payment terms management table in the second embodiment. [Figure 45] This figure shows an example of an accounts payable ledger information management table in the second embodiment. [Figure 46] This figure shows an example of a payment processing screen in the second embodiment. [Modes for carrying out the invention]

[0008] The embodiments of this invention will be described in detail below with reference to the drawings. Note that components having the same function are numbered the same in the drawings, and redundant explanations are omitted.

[0009] [First Embodiment] [Relationships between companies] The relationships between the companies in this embodiment will be explained with reference to Figure 1. Figure 1 is a conceptual diagram showing the relationships between the companies in this embodiment.

[0010] As shown in Figure 1, service user company A is a company that provides goods or services to its trading partner, service user company B, and receives consideration from service user company B. In this case, service user company A, as the seller, is the creditor, and service user company B, as the buyer, is the debtor.

[0011] Service provider C is a company that, at the request of service user A, provides a service to create invoices (generate invoice information) that service user A sends to service user B. In this embodiment, the entity that uses the services provided by the service provider may be referred to as the tenant. In other words, in this embodiment, the tenant is a business, organization, or individual.

[0012] Financial institution D1 is the financial institution that manages the bank account of service user company B. Financial institution D2 is the financial institution that manages the bank account of service user company A. Note that this does not have to be a financial institution; it could also be a payment collection agency that manages accounts through a direct debit service.

[0013] Here, we will briefly describe the processing in this embodiment. Note that the IDs described later are examples of identification information.

[0014] First, service user A requests service provider C to register the terms of trade (Step S0-1). The terms of trade are, for example, the billing date and payment terms. Service provider C then registers the terms of trade for service user A. Next, service user B requests service provider C to register the payment terms (Step S0-2). The payment terms are, for example, the payment due date and the scheduled payment date. Service provider C then registers the payment terms for service user B.

[0015] Next, service user A requests service provider C to create (generate) and send an invoice to service user B (Step S1). At this time, service provider C proposes an invoice to service user A that takes into account service user A's terms of trade and service user B's payment terms. As a result, service user B receives the invoice from service user A through service provider C (Step S2).

[0016] Service user B sends a payment request to service provider C specifying the items to be paid (Step 3-1). Service provider C then creates remittance data including a payment ID that identifies the payment request and sends it to service user B (Step S3-2). This remittance data is used for remittances based on invoices from the buyer's (service user B's) bank account to the seller's (service user A's) bank account. In other words, service provider C creates the remittance data that service user B will use when making a remittance, and furthermore, it includes a payment ID in the remittance data during its creation.

[0017] Next, service user company B sends remittance data, which includes the payment ID, to financial institution D1 (step S4-1). As a result, financial institution D1 sends the amount specified in the remittance data to financial institution D2, where service user company A's bank account is managed (step S4-2). At this time, the payment ID is also sent from financial institution D1 to financial institution D2 along with the remittance data.

[0018] Next, after financial institution D2 confirms the deposit into service user company A's bank account, it sends deposit information (information such as deposit source, deposit amount, deposit date, etc.), including the deposit details and payment ID, to service provider company C. As a result, service provider company C obtains the deposit information (step S5).

[0019] Next, service provider C identifies the details of the invoice that were paid based on the payment ID included in the payment information and performs reconciliation processing for those details (step S6). Even if a remittance is made based on only a portion of the details included in the invoice, the details that were paid can be identified by the payment ID, and it is possible to verify whether the invoiced amount and the received amount for those details match. Therefore, even if payments are made on an item-by-item basis within the invoice, reconciliation can be performed automatically.

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

[0021] As shown in Figure 2, the information processing system 1 in this embodiment includes a transaction management server 10, a seller terminal 20, a buyer terminal 30, and two account management servers 40. The transaction management server 10, seller terminal 20, buyer terminal 30, and account management servers 40 are each connected to a communication network N1.

[0022] The communication network N1 is configured so that each connected device can communicate with one another. The communication network N1 is constructed using wired communication networks such as the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0023] The communication network N1 may include not only wired communication but also wireless communication such as Wi-Fi 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).

[0024] The seller terminal 20 is installed at service user company A (seller). The buyer terminal 30 is installed at service user company B (buyer). The transaction management server 10 is installed at service provider company C. The buyer's account management server 40-1 is installed at financial institution D1. The seller's account management server 40-2 is installed at financial institution D2.

[0025] The seller terminal 20 and the buyer terminal 30 may be, for example, output devices such as PJ (Projector), IWB (Interactive White Board), digital signage, HUD (Head Up Display) devices, industrial machinery, imaging devices, sound collection devices, medical equipment, networked home appliances, automobiles (Connected Car), notebook PCs (Personal Computers), mobile phones, smartphones, tablet devices, game consoles, PDAs (Personal Digital Assistants), digital cameras, wearable PCs, or desktop PCs.

[0026] [Hardware configuration of the information processing system] The hardware configuration of the information processing system in this embodiment will be described with reference to Figure 3. Figure 3 is a diagram showing an example of a hardware configuration when the transaction management server 10, seller terminal 20, buyer terminal 30, and account management server 40 are implemented using computers.

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

[0028] Of these components, 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 the work area for the CPU 501. The HD 504 stores various data, such as programs. The HDD controller 505 controls the reading or writing of various data to the HD 504 according to the control of the CPU 501.

[0029] Display 506 displays various information such as cursors, menus, windows, characters, or images. External device connection I / F 508 is an interface for connecting various external devices. In this case, external devices include, for example, USB (Universal Serial Bus) memory and printers. Network I / F 509 is an interface for data communication using the communication network N1. Bus line 510 is an address bus, data bus, etc., for electrically connecting various components such as the CPU 501 shown in Figure 3.

[0030] The keyboard 511 is a type of input means equipped with multiple keys for inputting characters, numbers, and various instructions. The pointing device 512 is a type of input means for selecting and executing various instructions, selecting processing targets, and moving the cursor. The DVD-RW drive 514 controls the reading or writing of various data to the DVD-RW 513, which is an example of a removable recording medium. Note that it is not limited to DVD-RW, but may also be DVD-R, etc. The media interface 516 controls the reading or writing (storage) of data to the recording medium 515, such as flash memory.

[0031] [Functional Configuration of Information Processing Systems] The functional configuration of the information processing system in this embodiment will be described with reference to Figure 4. Figure 4 is a block diagram showing an example of the functional configuration of the information processing system in this embodiment.

[0032] <Functional Configuration of the Transaction Management Server> As shown in Figure 4, the transaction management server 10 in this embodiment comprises a transmission / reception unit 11, a generation unit 14, a determination unit 15, a creation unit 16, a memory control unit 19, and a memory unit 100. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 501 following a program deployed from the HD 504 onto the RAM 503. The memory unit 100 is constructed from the RAM 503 and HD 504 shown in Figure 3.

[0033] The transmitting / receiving unit 11 is implemented by instructions from the CPU 501 and the network I / F 509 shown in Figure 3, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network N1.

[0034] The generation unit 14 is implemented by instructions from the CPU 501 shown in Figure 3, and generates predetermined data (information). The details of the generated data will be described later.

[0035] The decision unit 15 is implemented by instructions from the CPU 501 shown in Figure 3 and performs a predetermined decision. The details of the decision will be described later.

[0036] The creation unit 16 is implemented by instructions from the CPU 501 shown in Figure 3, and performs tasks such as creating the various screens and URLs for each screen, as described later.

[0037] The memory control unit 19 is implemented by instructions from the CPU 501 shown in Figure 3 and the HDD controller 505, and performs processing such as storing various data in the memory unit 100 and reading various data stored in the memory unit 100.

[0038] The memory unit 100 contains a tenant information management database, an accounts receivable ledger information management database, an accounts payable ledger information management database, an issued invoice information management database, a received information management database, a received invoice information management database, a payment information management database, a transaction terms management database, and a payment terms management database.

[0039] The tenant information management database consists of tenant information management tables. These tables store information about service user companies A and B, which are tenants of the transaction management server 10. Details of the tenant information management tables will be described later.

[0040] The accounts receivable information management database consists of accounts receivable information management tables for each tenant. These tables store accounts receivable information based on sales information from the seller (service user company A) to the buyer (service user company B). Accounts receivable information can be imported from an external system that has an accounts receivable ledger, such as an accounting system. If the transaction management server 10 also has accounting functions, the accounts receivable ledger on the transaction management server 10 may be used. Details of the accounts receivable information management tables will be described later.

[0041] The accounts payable information management database consists of accounts payable information management tables for each tenant. These tables store accounts payable information based on delivery information from the seller (service user company A) to the buyer (service user company B). Accounts payable information can be imported from an external system that has an accounts payable ledger, such as an accounting system. If the transaction management server 10 also has accounting functions, the accounts payable ledger on the transaction management server 10 may be used. Details of the accounts payable information management tables will be described later.

[0042] The invoice information management database consists of invoice information management tables for each tenant. These tables store invoice information related to invoices issued by the seller (service user company A) to the buyer (service user company B). Details of the invoice information management tables will be described later.

[0043] The receipt information management database consists of receipt information management tables for each tenant. These tables store receipt information for the purchaser (service user company B) to receive invoices. Details of the receipt information management tables will be described later.

[0044] The received invoice information management database consists of a separate invoice information management table for each tenant. The issued invoice information management table stores invoice information related to invoices received by the buyer (service user company B) from the seller (service user company A). Details of the received invoice information management table will be described later.

[0045] The payment information management database consists of payment information management tables for each tenant. These tables store payment information sent by the buyer (service user company B) to the seller (service user company A). Details of the payment information management tables will be described later.

[0046] The payment information management database consists of payment information management tables for each tenant. These tables store payment information transferred to the seller's (service user company A) account. Details of the payment information management tables will be described later.

[0047] The transaction terms management database consists of transaction terms management tables for each tenant. These tables store the transaction terms set by the seller (service user company A). Details of the transaction terms management tables will be described later.

[0048] The payment terms management database consists of payment terms management tables for each tenant. These tables store the payment terms set by the purchaser (service user company B). Details of the payment terms management tables will be described later.

[0049] <Functional Configuration of the Seller's Terminal> As shown in Figure 4, the seller terminal 20 in this embodiment comprises a transmitting / receiving unit 21, a receiving unit 22, a display control unit 24, a determination unit 25, a memory control unit 29, and a memory unit 200. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 501 in accordance with a program deployed from the HD 504 onto the RAM 503. The memory unit 200 is constructed from the RAM 503 and HD 504 shown in Figure 3.

[0050] The transmitting / receiving unit 21 is implemented by commands from the CPU 501 shown in Figure 3, as well as the external device connection I / F 508 and network I / F 509, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network N1.

[0051] The reception unit 22 is mainly implemented by commands from the CPU 501 shown in Figure 3, as well as the keyboard 511 and pointing device 512, and accepts various inputs from the user.

[0052] The display control unit 24 is primarily implemented by instructions from the CPU 501 shown in Figure 3, and displays images by outputting image data to the display 506 or an external display connected to the external device connection I / F 508. The display control unit 24 also has a web browser function.

[0053] The decision unit 25 is mainly implemented by instructions from the CPU 501 shown in Figure 3, and performs various decisions.

[0054] The memory control unit 29 is mainly implemented by instructions from the CPU 501 shown in Figure 3 and the HDD controller 505, and performs processing such as storing various data in the memory unit 200 and reading various data stored in the memory unit 200.

[0055] <Functional configuration of the purchaser's device> As shown in Figure 4, the purchaser terminal 30 in this embodiment includes a transmitting / receiving unit 31, a receiving unit 32, a display control unit 34, a determination unit 35, a storage control unit 39, and a storage unit 300.

[0056] The transceiver unit 31, reception unit 32, display control unit 34, determination unit 35, memory control unit 39, and memory unit 300 of the purchaser terminal 30 have the same functions as the transceiver unit 21, reception unit 22, display control unit 24, determination unit 25, memory control unit 29, and memory unit 200 of the seller terminal 20, so their explanation is omitted.

[0057] <Functional Configuration of Account Management Server> As shown in Figure 4, the account management server 40 in this embodiment includes a transmitting / receiving unit 41, a determination unit 45, a creation unit 46, a memory control unit 49, and a memory unit 400. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 501 following a program deployed from the HD 504 onto the RAM 503. The memory unit 400 is constructed from the RAM 503 and HD 504 shown in Figure 3.

[0058] The transmitting / receiving unit 41 is implemented by instructions from the CPU 501 and the network I / F 509 shown in Figure 3, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network N1.

[0059] The decision unit 45 is implemented by instructions from the CPU 501 shown in Figure 3 and performs a predetermined decision. The details of the decision will be described later.

[0060] The creation unit 46 is implemented by instructions from the CPU 501 shown in Figure 3, and performs tasks such as creating the screen.

[0061] The memory control unit 49 is implemented by instructions from the CPU 501 shown in Figure 3 and the HDD controller 505, and performs processing such as storing various data in the memory unit 400 and reading various data stored in the memory unit 400.

[0062] The account management server 40 may be a server device provided by a financial institution, or a server device provided by a predetermined service that cooperates with a financial institution's system.

[0063] [Processing procedures for information processing systems] The processing procedure of the information processing method executed by the information processing system in this embodiment will be described with reference to Figures 5 to 41.

[0064] In this embodiment, it is assumed that the seller and the buyer have agreed in advance on the billing date and payment terms through a contract or other agreement. In this embodiment, the payment terms are the maximum period from the billing date to the payment date.

[0065] <Registering Conditional Information> First, the condition information registration process in this embodiment (step S0 in Figure 1) will be explained with reference to Figure 5. Figure 5 is a sequence diagram showing an example of the condition information registration process in this embodiment.

[0066] In step S1, the reception unit 22 of the seller terminal 20 accepts the seller's operation to register the transaction conditions. The seller is, for example, a person in charge of performing the duties of service user company A.

[0067] The operation to register trading conditions is performed on the trading conditions setting screen. The trading conditions setting screen is displayed, for example, by selecting the trading conditions setting menu on the main menu screen provided by the trading management server 10.

[0068] (Transaction conditions setting screen) Here, the transaction conditions setting screen in this embodiment will be described with reference to Figure 6. Figure 6 is a conceptual diagram showing an example of the transaction conditions setting screen in this embodiment.

[0069] As shown in Figure 6, the transaction conditions setting screen 3000 in this embodiment has a customer input field 3001, a payment terms input field 3002, a billing closing date input field 3003, a register button 3008, and a cancel button 3009.

[0070] When the seller presses the registration button 3008, the reception unit 22 accepts the registration operation for the transaction conditions. When the seller presses the cancel button 3009, the display control unit 24 closes the transaction conditions setting screen 3000.

[0071] The terms and conditions setting screen allows you to set the terms and conditions agreed upon in advance between the seller and the buyer. This prior agreement is made, for example, in a contract. In the example in Figure 6, it shows that the buyer will be billed in a lump sum for goods delivered during the one-month period up to the end of the month. After receiving the invoice, the buyer must pay the billed amount by the end of the month following the billing date. For example, goods delivered and billed between September 1st and September 30th must be paid for by October 31st.

[0072] Let's return to Figure 5 for explanation. In step S2, the transmitting / receiving unit 21 of the seller terminal 20 sends a request for registration of transaction conditions to the transaction management server 10. This registration request includes the transaction conditions entered on the transaction conditions setting screen 3000. The transmitting / receiving unit 11 of the transaction management server 10 receives the request for registration of transaction conditions from the seller terminal 20.

[0073] In step S3, the memory control unit 19 of the transaction management server 10 registers the transaction conditions included in the transaction conditions registration request in the transaction conditions management DB.

[0074] (Transaction Terms Management Table) Here, the details of the transaction conditions management table will be explained with reference to Figure 7. Figure 7 is a conceptual diagram showing an example of the transaction conditions management table in this embodiment.

[0075] As shown in Figure 7, in the transaction terms management table 1800 of this embodiment, information representing the trading partner (such as the trading partner's company name), payment terms, and billing closing date are managed in association with each other.

[0076] Let's return to Figure 5 for explanation. In step S4, the reception unit 32 of the purchaser terminal 30 accepts the purchaser's operation to register payment terms. The purchaser is, for example, a person in charge of performing the duties of service user company B.

[0077] The registration of payment terms is performed on the payment terms settings screen. The payment terms settings screen can be displayed, for example, by selecting the payment terms settings menu on the main menu screen provided by the transaction management server 10.

[0078] (Payment terms setting screen) Here, the payment terms setting screen in this embodiment will be described with reference to Figure 8. Figure 8 is a conceptual diagram showing an example of the payment terms setting screen in this embodiment.

[0079] As shown in Figure 8, the payment conditions setting screen 3100 in this embodiment has a payment closing date input field 3101, a payment due date input field 3102, a register button 3108, and a cancel button 3109.

[0080] When the buyer presses the registration button 3108, the reception unit 32 accepts the payment terms registration operation. When the buyer presses the cancel button 3109, the display control unit 34 closes the payment terms setting screen 3100.

[0081] The payment terms setting screen allows you to set the payment terms for the buyer. Payment terms do not need to be agreed upon in advance. However, the actual payment made by the buyer must comply with the previously agreed-upon transaction terms. The example in Figure 8 shows that payment for goods delivered between the 26th of the previous month and the 25th of the current month will be made in a lump sum by the 20th of the following month.

[0082] Let's return to Figure 5 for explanation. In step S5, the transmitting / receiving unit 31 of the buyer terminal 30 sends a request for registration of payment terms to the transaction management server 10. This registration request includes the payment terms entered on the payment terms setting screen 3100. The transmitting / receiving unit 11 of the transaction management server 10 receives the request for registration of payment terms from the buyer terminal 30.

[0083] In step S6, the memory control unit 19 of the transaction management server 10 registers the payment terms included in the payment terms registration request in the payment terms management DB.

[0084] (Payment Terms Management Table) Here, the details of the payment terms management table will be explained with reference to Figure 9. Figure 9 is a conceptual diagram showing an example of a payment terms management table in this embodiment.

[0085] As shown in Figure 9, in the payment terms management table 1900 of this embodiment, the payment closing date and the scheduled payment date are managed in association with each other.

[0086] <Invoice creation and sending> Next, the invoice creation and sending process in this embodiment (step S1 in Figure 1) will be explained with reference to Figure 10. Figure 10 is a sequence diagram showing an example of the invoice creation and sending process in this embodiment.

[0087] In step S11, the reception unit 22 of the seller terminal 20 receives an operation from the seller to display the invoice creation screen. The seller is, for example, a person in charge of performing the duties of service user company A.

[0088] Before accepting the request to display the invoice creation screen, the reception unit 22 receives authentication information such as the tenant ID, which is the tenant identification information entered by the seller. The transmission / reception unit 21 then sends the authentication information to the transaction management server 10, where the transaction management server 10 performs a predetermined authentication process. The transaction management server 10 authenticates the seller using the tenant information management DB. Therefore, the reception unit 22 can only accept the request to display the invoice creation screen by the seller if the seller has been authenticated by the transaction management server 10.

[0089] (Tenant information management table) Here, the details of the tenant information management table will be explained with reference to Figure 11. Figure 11 is a conceptual diagram showing an example of the tenant information management table in this embodiment.

[0090] As shown in Figure 11, in this embodiment, the tenant information management table 1000 manages tenant information (company name, etc.), authentication information (user ID and password, etc.), contact information (email address and address, etc.), and bank account information for transfers in an associated manner.

[0091] In this embodiment, tenants can use the service as both sellers and buyers. However, by registering user roles representing sellers or buyers as tenant information, it is possible to restrict specific tenants to using the service as either sellers or buyers only.

[0092] Let's return to Figure 10 for explanation. In step S12, the transmitting / receiving unit 21 of the seller terminal 20 sends a request to the transaction management server 10 to retrieve the invoice creation screen. The transaction management server 10 receives the request to retrieve the invoice creation screen from the seller terminal 20 via its transmitting / receiving unit 11.

[0093] In step S13, the memory control unit 19 of the transaction management server 10 reads the accounts receivable ledger information from the accounts receivable ledger information management DB. Next, the creation unit 16 creates the screen data for the invoice creation screen based on the accounts receivable ledger information read by the memory control unit 19.

[0094] The common invoice ID is identification information that the transaction management server 10 sets for each invoice information for common management across all tenants. The invoice ID is identification information that tenants arbitrarily set for their invoice information. Therefore, in subsequent processing, the identification information that the transaction management server 10 uses to identify invoice information is the common invoice ID. However, if it is possible to control the invoice ID so that it does not overlap between tenants, the invoice ID may be used instead of the common invoice ID.

[0095] (Accounts Receivable Ledger Information Management Table) Here, the details of the accounts receivable ledger information management table will be explained with reference to Figure 12. Figure 12 is a conceptual diagram showing an example of the accounts receivable ledger information management table in this embodiment.

[0096] As shown in Figure 12, in the accounts receivable ledger information management table 1100 of this embodiment, the date on which accounts receivable were incurred (hereinafter also referred to as "accounts receivable date"), identification information for identifying invoices (common invoice ID and invoice ID, etc.), information regarding the details in the invoice (detail ID, product code, unit price, quantity, amount, etc.), and information regarding payments (payment quantity and payment amount) are managed in association with each other.

[0097] The example of accounts receivable ledger information shown in Figure 12 represents the initial state after importing from the accounts receivable ledger. In the initial state, each identification information (common invoice ID, invoice ID, and item ID) and payment information (payment quantity and payment amount) are blank.

[0098] ≪Creating data for the invoice creation screen≫ Here, the process of creating invoice creation screen data in this embodiment (step S13 in Figure 10) will be explained with reference to Figure 13. Figure 13 is a conceptual diagram showing an example of the process of creating invoice creation screen data in this embodiment.

[0099] In step S13-1, the memory control unit 19 retrieves accounts receivable ledger information from the accounts receivable ledger information management DB in which the accounts receivable date is within the billing period and the payment quantity and payment amount are blank.

[0100] In step S13-2, the decision unit 15 determines whether or not to prioritize the supplier's payment terms. Whether or not to prioritize the supplier's payment terms is assumed to be pre-registered. If the supplier's payment terms are to be prioritized (YES), the decision unit 15 proceeds to step S13-3. If the supplier's payment terms are not to be prioritized (NO), the decision unit 15 proceeds to step S13-5.

[0101] In step S13-3, the memory control unit 19 retrieves the seller's billing closing date from the transaction terms management DB. Next, the memory control unit 19 retrieves the buyer's payment closing date from the payment terms management DB.

[0102] In step S13-4, the determination unit 15 determines the chronological relationship between the billing closing date and the payment closing date obtained in step S13-3. If the payment closing date is earlier than the billing closing date, the determination unit 15 proceeds to step S13-6. If the billing closing date is earlier than the payment closing date, the determination unit 15 proceeds to step S13-7.

[0103] In step S13-5, the creation unit 16 decides to display the accounts receivable ledger information obtained in step S13-1 as the item to be billed.

[0104] In step S13-6, the creation unit 16 decides to display the accounts receivable information obtained in step S13-1, specifically the accounts receivable information with an accounts receivable date prior to the payment closing date, as the billing target.

[0105] In step S13-7, the memory control unit 19 acquires accounts receivable ledger information in which the accounts receivable date falls within the period from the day following the billing closing date to the payment closing date of the next billing period. Next, the memory control unit 19 decides to display the accounts receivable ledger information acquired in step S13-1 and the accounts receivable ledger information acquired in step S13-7 as billing targets.

[0106] In step S13-8, the creation unit 16 calculates the total amount of the accounts receivable information that has been decided to be displayed as the billing item. The calculated amount is then displayed on the invoice creation screen as the billing amount.

[0107] In step S13-9, the creation unit 16 calculates the date by adding the number of days in the payment term to the billing closing date. The calculated date is displayed on the invoice creation screen as the payment due date for the invoice.

[0108] In step S13-10, the creation unit 16 creates screen data for the invoice creation screen based on the information obtained in steps S13-1 to S13-9.

[0109] Let's return to Figure 10 for explanation. In step S14, the transmit / receive unit 11 of the transaction management server 10 transmits the screen data of the invoice creation screen created by the creation unit 16 to the seller terminal 20. The transmit / receive unit 21 of the seller terminal 20 receives the screen data of the invoice creation screen from the transaction management server 10.

[0110] In step S15, the display control unit 24 of the seller terminal 20 displays the invoice creation screen on the display 506 based on the screen data of the invoice creation screen.

[0111] (Invoice creation screen) Here, the invoice creation screen in this embodiment will be described with reference to Figure 14. Figure 14 is a conceptual diagram showing an example of the invoice creation screen in this embodiment.

[0112] As shown in Figure 14, the invoice creation screen 2000 in this embodiment has a condition setting area 2010, an accounts receivable ledger display area 2020, a payment deadline display field 2030, a create button 2008, and a cancel button 2009. The condition setting area 2010 displays a customer priority selection field 2011 for selecting whether or not to prioritize the payment terms of the customer.

[0113] In the Condition Setting Area 2010, entering conditions such as the billing recipient and billing period will display accounts receivable information that matches those conditions in the Accounts Receivable Display Area 2020. The condition values ​​displayed in the Condition Setting Area 2010 can be set in advance. For example, the billing period can be set from the day after the billing closing date of the previous month to the billing closing date of the current month.

[0114] The Accounts Receivable Ledger Display Area 2020 displays the contents of the accounts receivable ledger in a format where each item can be selected. For example, by displaying a checkbox for each item, that item can be made selectable. In the initial state, all items are selected.

[0115] When the seller selects "Customer Priority Selection 2011," the accounts receivable information displayed in the accounts receivable display area 2020 that matches the customer's payment terms will be selected. Other accounts receivable information will be deselected. Initially, "Customer Priority Selection 2011" is not selected (i.e., the seller's own terms take priority).

[0116] When the seller presses the Create button 2008, the Reception Unit 22 accepts the operation to create an invoice (generate invoice information). When the seller presses the Cancel button 2009, the Display Control Unit 24 closes the Invoice Creation Screen 2000.

[0117] Figure 15 is a conceptual diagram showing an example of an invoice creation screen where "Customer Priority" is selected. As shown in Figure 15, when "Customer Priority" is selected, accounts receivable information that does not match the customer's payment terms is deselected. Here, since the customer's payment due date is set to the 25th, it can be seen that the accounts receivable information with a receivable date of September 29, 2020 has been deselected. It can also be seen that the invoice amount is the amount obtained by subtracting the invoice amount of the deselected accounts receivable information.

[0118] If the system has selected "Prioritize Customers" and attempts to select accounts receivable information that has been deselected, a warning may be displayed indicating that it does not meet the customer's payment terms. For example, accounts receivable information with a receivable date of September 29, 2020, is past the customer's payment due date of September 25, so a message such as "The customer's payment due date has been exceeded" may be displayed on display 506.

[0119] Let's return to Figure 10 for explanation. In step S16, the reception unit 22 of the seller terminal 20 accepts the seller's operation to create an invoice (generate invoice information). Specifically, the seller selects the items to be included in the invoice on the invoice creation screen 2000 and presses the create button 2008.

[0120] In step S17, the transmitting / receiving unit 21 of the seller terminal 20 sends a request to register invoice information to the transaction management server 10. This registration request includes the accounts receivable information selected in the accounts receivable display area 2020. The transmitting / receiving unit 11 of the transaction management server 10 receives the request to register invoice information from the seller terminal 20.

[0121] In step S18, the creation unit 16 of the transaction management server 10 generates an invoice image as shown in Figure 16 based on the request to register invoice information and stores it in a predetermined storage location. At this time, the creation unit 16 creates a receipt screen URL, which is a URL (Uniform Resource Locator) for accessing the receipt screen for receiving the invoice.

[0122] Next, the memory control unit 19 generates invoice information representing the contents of the invoice and registers it in the issued invoice information management DB. The memory control unit 19 also updates the accounts receivable ledger information management DB based on the generated invoice information. At this time, the memory control unit 19 issues a common invoice ID and an invoice ID to identify the invoice, as well as a detail ID to identify each detail.

[0123] (Invoice Information Management Table) Here, the details of the invoice information management table will be explained with reference to Figure 17. Figure 17 is a conceptual diagram showing an example of the invoice information management table in this embodiment.

[0124] As shown in Figure 17, in the invoice information management table 1300 of this embodiment, the following information is managed in association with each other: identification information that identifies the invoice (common invoice ID and invoice ID, etc.), information representing the recipient of the invoice (name of the recipient company, etc.), invoice amount, invoice date, payment due date, invoice status, invoice image storage location, customer priority, details information (details ID, product code, product name, unit price, quantity and amount, etc.), and bank transfer information.

[0125] Of these, the invoice amount is set to the total amount of the selected accounts receivable information. The payment due date is automatically set based on the payment terms corresponding to the buyer. For example, if the buyer has a payment term of 30 days, the payment due date will be the end of the following month. Also, for example, if the buyer has a payment term of 60 days, the payment due date will be the end of the month after next. The invoice status is set to "Created". Bank transfer information is obtained from the tenant information management table.

[0126] Figure 18 is a conceptual diagram showing an example of an invoice creation screen where customer priority is selected. As shown in Figure 18, when customer priority is selected, details based on accounts receivable information that do not match the customer's payment terms will not be included in the invoice information. Here, it can be seen that details for 5 whiteboards and 35 chairs based on accounts receivable information with a receivable date of September 29, 2020 have been deleted from the invoice information with common invoice ID abcd1235. It can also be seen that the invoice amount is the amount after subtracting the invoice amount for the deleted details.

[0127] Figure 19 shows an example of an accounts receivable ledger information management table after invoice creation. As shown in Figure 19, in the accounts receivable ledger information management table after invoice creation, the common invoice ID, invoice ID, and item ID are registered for the accounts receivable ledger information for which the invoice was issued.

[0128] Figure 20 is a conceptual diagram showing an example of an accounts receivable ledger information management table after invoice creation when customer priority is selected. As shown in Figure 20, in the accounts receivable ledger information management table when customer priority is selected, the common invoice ID, invoice ID, and item ID are not registered for accounts receivable ledger information that is not included in the invoice. Here, it can be seen that the accounts receivable ledger information with a receivable date of September 29, 2020 has blank fields for common invoice ID, invoice ID, and item ID.

[0129] Let's return to Figure 10 for explanation. In step S19, the reception unit 22 of the seller terminal 20 receives the seller's operation to send an invoice. The operation to send an invoice is performed on the invoice sending screen. The invoice sending screen is displayed, for example, by selecting the invoice to be sent on the screen that displays a list of created invoices.

[0130] (Invoice submission screen) Here, the invoice sending screen in this embodiment will be described with reference to Figure 21. Figure 21 is a conceptual diagram showing an example of the invoice sending screen in this embodiment.

[0131] As shown in Figure 21, the invoice sending screen 2100 in this embodiment includes a recipient selection field 2101, an invoice image display field 2102, a cover letter input field 2103, a send button 2108, and a cancel button 2109.

[0132] Of these, the recipient selection field 2101 displays the email address associated with the purchaser in the tenant information management table, making it selectable. The invoice image display field 2102 displays the invoice image indicated by the invoice image storage location in the issued invoice information management table.

[0133] The cover letter input field 2103 is where you enter the subject and body of the invoice to be sent. Ideally, a predefined template should be displayed initially for the subject and body. The cover letter input field 2103 should also contain an embedded link to the receipt screen URL.

[0134] When the seller presses the send button 2108, the reception unit 22 accepts the invoice sending operation. When the seller presses the cancel button 2109, the display control unit 24 closes the invoice sending screen 2100.

[0135] Let's return to Figure 10 for explanation. In step S20, the transmitting / receiving unit 21 of the seller terminal 20 sends an invoice delivery request to the transaction management server 10. This delivery request includes a common invoice ID. The transmitting / receiving unit 11 of the transaction management server 10 receives the invoice delivery request from the seller terminal 20.

[0136] In step S21, the memory control unit 19 of the transaction management server 10 identifies the invoice information in the issued invoice information management table based on the common invoice ID included in the invoice sending request. Next, the memory control unit 19 updates the invoice status of the identified invoice information to "Sent".

[0137] In step S22, the memory control unit 19 of the transaction management server 10 generates receipt information based on the invoice sending request and registers it in the receipt information management DB.

[0138] (Receipt Information Management Table) Here, the details of the receipt information management table will be explained with reference to Figure 22. Figure 22 is a conceptual diagram showing an example of the receipt information management table in this embodiment.

[0139] As shown in Figure 22, in the receipt information management table 1400 of this embodiment, identification information that identifies the invoice (common invoice ID and invoice ID, etc.), information representing the issuer of the invoice (issuer company name, etc.), issue date, and receipt screen URL are managed in association with each other.

[0140] Let's return to Figure 10 for explanation. In step S23, the sending / receiving unit 11 of the transaction management server 10 sends an email containing the receipt screen URL to the buyer's terminal 30. Note that the sending / receiving unit 11 does not have to send the email containing the receipt screen URL directly to the buyer's terminal 30. For example, the sending / receiving unit 11 may send an email to a designated email address on the buyer's side, and the buyer's terminal 30 may receive the email from the mail server.

[0141] The method of sending the receipt screen URL is not limited to email. For example, a message containing the receipt screen URL may be sent to the buyer's terminal 30 via a messenger app. Furthermore, the creation unit 16 may create a two-dimensional code indicating the receipt screen URL, embed the two-dimensional code in the invoice image, the sending / receiving unit 11 may send the invoice image with the embedded two-dimensional code to a printing device, print the invoice image on recording paper, and mail the printed paper invoice to the buyer.

[0142] <Invoice receipt processing> Next, the invoice receipt process in this embodiment (step S2 in Figure 1) will be explained with reference to Figure 23. Figure 23 is a sequence diagram showing an example of the invoice receipt process in this embodiment.

[0143] In step S31, the send / receive unit 31 of the purchaser terminal 30 receives an email containing a receipt screen URL. Next, the reception unit 32 receives the purchaser's operation to display the invoice receipt screen. The purchaser is, for example, a person in charge of performing the duties of service user company B. The operation to display the invoice receipt screen is, for example, the operation to open the receipt screen URL included in the email (i.e., the operation to click the receipt screen URL link in the email).

[0144] In step S32, the transmitting / receiving unit 31 of the purchaser terminal 30 sends a request to the transaction management server 10 to retrieve the invoice receipt screen. This request includes the URL of the receipt screen. The transaction management server 10 receives the request to retrieve the invoice receipt screen from the purchaser terminal 30 via the transmitting / receiving unit 11.

[0145] In step S33, the memory control unit 19 of the transaction management server 10 reads receipt information from the receipt information management DB using the receipt information management table 1400 based on the receipt screen URL included in the request to acquire the invoice receipt screen. Next, the memory control unit 19 reads invoice information from the issued invoice information management DB using the issued invoice information management table 1300 based on the common invoice ID included in the read receipt information. Subsequently, the creation unit 16 creates screen data for the invoice receipt screen based on the receipt information and invoice information read by the memory control unit 19.

[0146] In step S34, the transmit / receive unit 11 of the transaction management server 10 sends the screen data of the invoice receipt screen created by the creation unit 16 to the buyer terminal 30. The transmit / receive unit 31 of the buyer terminal 30 receives the screen data of the invoice receipt screen from the transaction management server 10.

[0147] In step S35, the display control unit 34 of the purchaser terminal 30 displays the invoice receipt screen on the display 506 based on the screen data of the invoice receipt screen.

[0148] (Invoice receipt screen) Here, the invoice receipt screen in this embodiment will be described with reference to Figure 24. Figure 24 is a conceptual diagram showing an example of the invoice receipt screen in this embodiment.

[0149] As shown in Figure 24, the invoice receipt screen 2200 in this embodiment has an invoice image display field 2201, a download button 2202, and a receive button 2203.

[0150] Of these, the invoice image display field 2201 displays the invoice image indicated by the invoice image storage location in the issued invoice information management table.

[0151] When the purchaser presses the download button 2202, the transmission / reception unit 31 downloads the invoice image, and the storage control unit 39 stores the downloaded invoice image in a predetermined storage location in the storage unit 300. When the purchaser presses the receive button 2203, the reception unit 32 accepts the invoice receipt operation.

[0152] Let's return to Figure 23 for explanation. In step S36, the reception unit 32 of the purchaser terminal 30 receives the purchaser's operation to receive the invoice. Specifically, the purchaser presses the receive button 2203 on the invoice receipt screen 2200.

[0153] In step S37, the transmitting / receiving unit 31 of the purchaser terminal 30 sends a request for receipt of the invoice to the transaction management server 10. This request for receipt includes a common invoice ID. The transmitting / receiving unit 11 of the transaction management server 10 receives the request for receipt of the invoice from the purchaser terminal 30.

[0154] In step S38, the memory control unit 19 of the transaction management server 10 identifies the invoice information in the issued invoice information management table based on the common invoice ID included in the invoice receipt request. Next, the memory control unit 19 updates the invoice status of the identified invoice information to "received".

[0155] In step S39, the memory control unit 19 of the transaction management server 10 registers the invoice information identified in the issued invoice information management table into the received invoice information management DB.

[0156] (Invoice Receipt Information Management Table) Here, the details of the invoice information management table will be explained with reference to Figure 25. Figure 25 is a conceptual diagram showing an example of the invoice information management table in this embodiment.

[0157] As shown in Figure 25, the received invoice information management table 1500 in this embodiment manages the following information in association: identification information to identify the invoice (common invoice ID and invoice ID, etc.), information representing the recipient of the invoice (name of the recipient company, etc.), invoice amount, invoice date, payment due date, invoice image storage location, details information (details ID, product code, product name, unit price, quantity, amount, etc.), and bank transfer information. In other words, the received invoice information management table differs from the issued invoice information management table only in that it does not have an invoice status.

[0158] <Remittance data creation process> Next, the remittance data creation process in this embodiment (step S3 in Figure 1) will be explained with reference to Figure 26. Figure 26 is a sequence diagram showing an example of the remittance data creation process in this embodiment.

[0159] In step S41, the reception unit 32 of the purchaser terminal 30 receives an operation from the purchaser to display the payment processing screen. The operation to display the payment processing screen is performed on the receipt invoice list screen.

[0160] (List of received invoices screen) Here, the invoice list screen in this embodiment will be described with reference to Figure 27. Figure 27 is a conceptual diagram showing an example of the invoice list screen in this embodiment.

[0161] As shown in Figure 27, the received invoice list screen 2300 in this embodiment has an invoice list display field 2301. The invoice list display field 2301 displays a list of information about received invoices (billing source, invoice number, total amount, issue date, etc.). Each invoice displayed in the invoice list display field 2301 has a display button 2302, a download button 2303, and a payment processing button 2304.

[0162] When the buyer presses the display button 2302, the invoice image corresponding to the invoice is displayed on the display 506. When the buyer presses the download button 2303, the transmission / reception unit 31 downloads the invoice image, and the storage control unit 39 stores the downloaded invoice image in a predetermined storage location in the storage unit 300. When the buyer presses the payment processing button 2304, the reception unit 32 accepts the operation to display the payment processing screen.

[0163] Let's return to Figure 26 for explanation. In step S42, the transmitting / receiving unit 31 of the purchaser terminal 30 sends a request to the transaction management server 10 to retrieve the payment processing screen. This request includes a common invoice ID. The transaction management server 10 receives the request to retrieve the payment processing screen from the purchaser terminal 30 via its transmitting / receiving unit 11.

[0164] In step S43, the memory control unit 19 of the transaction management server 10 reads invoice information from the received invoice information management DB based on the common invoice ID included in the payment processing screen acquisition request. Next, the memory control unit 19 reads accounts payable ledger information from the accounts payable ledger information management DB based on the common invoice ID included in the read invoice information. Subsequently, the creation unit 16 creates screen data for the payment processing screen based on the invoice information and accounts payable ledger information read by the memory control unit 19.

[0165] (Accounts Payable Ledger Information Management Table) Here, the details of the accounts payable ledger information management table will be explained with reference to Figure 28. Figure 28 is a conceptual diagram showing an example of the accounts payable ledger information management table in this embodiment.

[0166] As shown in Figure 28, in the accounts payable information management table of this embodiment, the date on which accounts payable were incurred (hereinafter also referred to as "accounts payable date"), identification information to identify the invoice (common invoice ID and invoice ID, etc.), information regarding the details in the invoice (detail ID, product code, unit price, quantity, amount, etc.), and information regarding payment (payment quantity and payment amount) are managed in association with each other.

[0167] The example of accounts payable ledger information shown in Figure 28 represents the initial state after importing from the accounts payable ledger. In the initial state, each identification information (common invoice ID, invoice ID, and item ID) and payment information (payment quantity and payment amount) are blank.

[0168] ≪Creating payment processing screen data≫ Here, the process of creating payment processing screen data in this embodiment (step S43 in Figure 26) will be explained with reference to Figure 29. Figure 29 is a conceptual diagram showing an example of the process of creating payment processing screen data in this embodiment.

[0169] In step S43-1, the memory control unit 19 retrieves invoice information identified by the common invoice ID from the received invoice information management DB.

[0170] In step S43-2, the memory control unit 19 retrieves accounts payable ledger information from the accounts payable ledger information management DB in which the accounts payable date is within the payment period and the payment quantity and payment amount fields are blank.

[0171] In step S43-3, the decision unit 15 determines whether to prioritize the payment terms of the business partner based on the priority of the business partner in the invoice information. If the payment terms of the business partner are to be prioritized (YES), the decision unit 15 proceeds to step S43-8. If the payment terms of the business partner are not to be prioritized (NO), the decision unit 15 proceeds to step S43-4.

[0172] In step S43-4, the memory control unit 19 obtains the purchaser's payment closing date from the payment terms management DB.

[0173] In step S43-5, the creation unit 16 retrieves details from the accounts payable ledger information obtained in step S43-2 that are not included in the invoice information obtained in step S43-1.

[0174] In step S43-6, the determination unit 15 determines whether or not details were obtained in step S43-5. If details were obtained (YES), the determination unit 15 proceeds to step S43-7. If no details were obtained (NO), the determination unit 15 proceeds to step S43-8.

[0175] In step S43-7, the determination unit 15 determines whether each item obtained in step S43-5 satisfies the payment terms. Specifically, first, the determination unit 15 calculates the scheduled payment date from the accounts payable date. Next, the determination unit 15 calculates the due date based on the billing closing date and the payment terms. Then, it determines whether the scheduled payment date is earlier than the due date. The determination unit 15 decides to display each item that satisfies the payment terms as an item to be paid.

[0176] In step S43-8, the creation unit 16 decides to display each item that matches the invoice information obtained in step S43-1 and the accounts payable ledger information obtained in step S43-2 as an item to be paid.

[0177] In step S43-9, the creation unit 16 calculates the next payment date based on the current date and time and the scheduled payment date of the payment terms. The calculated payment date is displayed as the payment date on the payment processing screen.

[0178] In step S43-10, the creation unit 16 creates screen data for the payment processing screen based on the information obtained in steps S43-1 to S43-9.

[0179] Let's return to Figure 26 for explanation. In step S44, the transmit / receive unit 11 of the transaction management server 10 transmits the screen data of the payment processing screen created by the creation unit 16 to the buyer terminal 30. The transmit / receive unit 31 of the buyer terminal 30 receives the screen data of the payment processing screen from the transaction management server 10.

[0180] In step S45, the display control unit 34 of the purchaser terminal 30 displays the payment processing screen on the display 506 based on the screen data of the payment processing screen.

[0181] (Payment processing screen) Here, the payment processing screen in this embodiment will be described with reference to Figure 30. Figure 30 is a conceptual diagram showing an example of the payment processing screen in this embodiment.

[0182] As shown in Figure 30, the payment processing screen 2400 in this embodiment includes a condition setting area 2410, an accounts payable information display area 2420, an invoice information display area 2430, a detail information display area 2440, a quantity input button 2441, a payment information display area 2450, an accounts payable information display area 2460, a create button 2408, and a cancel button 2409.

[0183] In the condition setting area 2410, when conditions such as the payment closing date and payment period are entered, accounts payable ledger information that matches those conditions is displayed in the accounts payable ledger information display area 2420. The condition values ​​displayed in the condition setting area 2410 may be set in advance. For example, the payment period can be set from the day after the payment closing date of the previous month to the payment closing date of the current month.

[0184] The invoice information display area 2430 displays the contents of the invoice (invoice ID, invoice amount, invoice date, payment due date, and priority of customer, etc.). The item information display area 2440 displays information about the item included in the invoice (product name, quantity, unit price, and amount, etc.) in a format that allows selection of each item.

[0185] The accounts payable information display field 2460 shows accounts payable information where the accounts payable date falls within the next payment period. According to the buyer's payment terms (payment due date is the 25th), the accounts receivable information for September 29, 2020, would not be subject to payment. However, if payment is made in the next payment period, the payment date will be November 20, which would not satisfy the conditions of payment term 30 (payment due date is October 31). Therefore, the accounts receivable information for September 29, 2020, must also be included in this payment.

[0186] If, by agreement with the seller, the payment closing date is the end of the month and the payment term is 60 days, then the accounts receivable information as of September 29, 2020, satisfies the conditions of a 60-day payment term (payment due date is November 30). Therefore, the accounts receivable information as of September 29, 2020, does not need to be included in this payment.

[0187] In the details display section 2440, each item included in the accounts payable ledger information and invoice information is compared. Items included in both the accounts payable ledger information and invoice information are automatically selected. In this case, if the quantity in the accounts payable ledger information and the quantity in the invoice information do not match, both quantities are displayed so that they can be understood. For example, it can be displayed in the format "Quantity in accounts payable ledger information / Quantity in invoice information".

[0188] One quantity input button 2441 is displayed for each item shown in the item information display field 2440. When a quantity input button 2441 is pressed, a dialog box for entering the quantity appears, allowing the user to enter the quantity to be paid for that item.

[0189] Furthermore, the quantity input buttons 2441 corresponding to items not selected in the item details display field 2440 may be disabled.

[0190] The payment information display field 2450 displays the bank transfer details included in the invoice information. The payment date in the payment information display field 2450 is automatically entered as the scheduled payment date set in the buyer's payment terms (in this case, the 20th of the following month). However, the buyer can also manually correct this date.

[0191] When the buyer presses the create button 2408, the reception unit 32 accepts the operation to create the remittance data. When the buyer presses the cancel button 2409, the display control unit 34 closes the payment processing screen 2400.

[0192] Figure 31 is a conceptual diagram showing an example of the payment processing screen when "supplier priority" is selected. As shown in Figure 31, when "supplier priority" is selected, the accounts payable information display field 2460 is not displayed. This is because when "supplier priority" is selected, the invoice is created to match the buyer's payment terms, so payment should be made as stated on the invoice.

[0193] Let's return to Figure 26 for explanation. In step S46, the reception unit 32 of the purchaser terminal 30 accepts the purchaser's operation to create remittance data. Specifically, the purchaser selects the details to be included in the remittance data on the payment processing screen 2400 and presses the create button 2408.

[0194] In step S47, the transmitting / receiving unit 31 of the buyer terminal 30 sends a request to create remittance data (hereinafter also referred to as a "payment request") to the transaction management server 10. This request includes the invoice ID, item ID, and the quantity entered for each item. The item ID included in this request is the item ID of the item selected in the item information display field 2440. The transmitting / receiving unit 11 of the transaction management server 10 receives the request to create remittance data from the buyer terminal 30.

[0195] In step S48, the creation unit 16 issues a payment ID that identifies the payment based on the request to create remittance data. Next, the creation unit 16 creates remittance data with the payment ID embedded. The payment ID can be embedded in the remittance data as EDI (Electronic Data Interchange) information. Alternatively, it may be embedded in a specific item (e.g., remarks) in the transaction details of the Zengin EDI system.

[0196] The payment ID does not necessarily have to be issued by the transaction management server 10. For example, the payment information ID issued by financial institution D1 when the remittance data is created may be used as the payment ID.

[0197] In step S49, the memory control unit 19 of the transaction management server 10 generates payment information representing the contents of the remittance data and registers it in the payment information management DB. The memory control unit 19 also updates the accounts payable information management DB based on the request to create the remittance data.

[0198] (Payment Information Management Table) Here, the details of the payment information management table will be explained with reference to Figure 32. Figure 32 is a conceptual diagram showing an example of the payment information management table in this embodiment.

[0199] As shown in Figure 32, in the payment information management table 1600 of this embodiment, information representing the content of the remittance data (payment ID, payment amount, and scheduled payment date, etc.), identification information identifying the invoice (common invoice ID and invoice ID, etc.), and information related to the details (details ID, quantity, and amount, etc.) are managed in association with each other.

[0200] Figure 33 shows an example of an accounts payable ledger information management table after the creation of remittance data. As shown in Figure 33, in the accounts payable ledger information management table after the creation of remittance data, the common invoice ID, invoice ID, and item ID are registered in the accounts payable information for which the remittance data was created.

[0201] Let's return to Figure 26 for explanation. In step S50, the transceiver unit 11 of the transaction management server 10 transmits the remittance data, in which the payment ID is embedded, to the buyer terminal 30.

[0202] Subsequently, the buyer instructs the financial institution D1 to execute the transfer using the downloaded transfer data, following the prescribed procedure. For example, the buyer instructs the transfer by uploading the transfer data through a designated screen provided by financial institution D1, such as a corporate banking or internet banking service that manages the account of service user company B. Then, financial institution D1, which manages the account of service user company B, transfers the amount according to the transfer data to financial institution D2, which manages the account of service user company A, and also transmits information such as the payment ID included in the transfer data to financial institution D2. As a result, the seller can obtain the deposit information, including the payment ID, from financial institution D2.

[0203] Furthermore, remittances based on remittance data are not limited to being conducted through financial institutions. For example, remittances may be made through services such as online payment services. In this case, for example, service provider C may send a two-dimensional code indicating the remittance data to the purchaser, and the purchaser can make the remittance by having the purchaser's terminal 30 read the two-dimensional code through the application of the online payment service or similar service installed on the purchaser's terminal 30.

[0204] <Acquisition of payment information and automatic reconciliation processing> Next, the payment information acquisition process (step S5 in Figure 1) and the automatic reconciliation process (step S6 in Figure 1) in this embodiment will be explained with reference to Figure 34. Figure 34 is a sequence diagram showing an example of the payment information acquisition process and the automatic reconciliation process in this embodiment.

[0205] In step S61, the transceiver unit 11 of the transaction management server 10 sends a request to the account management server 40-2 to obtain deposit information. The account management server 40-2 is the account management server 40 that manages the accounts of service user company A.

[0206] The trigger for the transaction management server 10 to send a request to acquire deposit information may be a request from the seller's terminal 20 in response to an operation by the seller, or it may be every predetermined time interval (for example, every 30 minutes).

[0207] In step S62, the transmitting / receiving unit 41 of the account management server 40-2 transmits deposit information regarding the account of service user company A to the transaction management server 10. This deposit information includes a payment ID. The transmitting / receiving unit 11 of the transaction management server 10 receives the deposit information from the account management server 40-2.

[0208] The account management server 40-2 performs a predetermined authentication process when sending deposit information related to the account of service user company A to the transaction management server 10. For example, the authentication information for service user company A's account is registered in the tenant information management DB, and the sending / receiving unit 11 of the transaction management server 10 sends the authentication information identified based on the tenant ID to the account management server 40-2 along with a request to obtain deposit information.

[0209] In the account management server 40-2, the memory control unit 49 performs authentication processing based on the transmitted authentication information. If authentication is successful, the memory control unit 49 reads the deposit information corresponding to the authentication information from the deposit information stored in the memory unit 400. Finally, the transmission / reception unit 41 sends the read deposit information to the transaction management server 10.

[0210] In step S62, the memory control unit 19 of the transaction management server 10 registers the deposit information received from the account management server 40-2 in the deposit information management DB.

[0211] (Deposit Information Management Table) Here, the details of the deposit information management table will be explained with reference to Figure 35. Figure 35 is a conceptual diagram showing an example of a deposit information management table in this embodiment.

[0212] As shown in Figure 35, in the deposit information management table 1700 of this embodiment, the transaction date, withdrawal amount (payment amount), information representing the payee, deposit amount (amount received), information representing the sender, balance, payment ID, and reconciliation status are managed in association with each other. In the initial state, the reconciliation status field is blank.

[0213] Let's return to Figure 34 for explanation. In step S64, the transaction management server 10 performs an automatic reconciliation process based on the deposit information and payment information.

[0214] Automatic reconciliation process Here, the details of the automatic reconciliation process in this embodiment (step S64 in Figure 34) will be explained with reference to Figure 36. Figure 36 is a flowchart showing an example of the automatic reconciliation process in this embodiment.

[0215] In step S64-1, the memory control unit 19 retrieves unprocessed payment information from the payment information management DB. Unprocessed payment information refers to payment information for which the reconciliation status in the payment information management table is blank.

[0216] Steps S64-2 through S64-8 are performed for each of the unprocessed deposit information obtained in step S64-1.

[0217] In step S64-2, the determination unit 15 determines whether a payment ID is set in the acquired deposit information. If a payment ID is set (YES), the determination unit 15 acquires the payment ID and proceeds to step S64-3. If a payment ID is not set (NO), the determination unit 15 proceeds to step S64-8.

[0218] In step S64-3, the memory control unit 19 retrieves payment information from the payment information management DB based on the payment ID obtained in step S64-2.

[0219] In step S64-4, the determination unit 15 determines whether the payment amount in the payment information matches the amount received in the deposit information. If the payment amount and the amount received match (YES), the determination unit 15 proceeds to step S64-5. If the payment amount and the amount received do not match (NO), the determination unit 15 proceeds to step S64-7.

[0220] In step S64-5, the memory control unit 19 generates accounts receivable ledger information based on the deposit information and payment information, and registers it in the accounts receivable ledger information management table. The generated accounts receivable ledger information has the accounts receivable date set to the transaction date of the deposit information, and the common invoice ID, invoice ID, item ID, deposit quantity, and deposit amount are set to the common invoice ID, invoice ID, item ID, quantity, and amount of the payment information.

[0221] In step S64-6, the memory control unit 19 updates the settlement status of the deposit information management table to settled. After that, the memory control unit 19 finishes processing the deposit information and returns to step S64-2.

[0222] In step S64-7, the memory control unit 19 updates the reconciliation status of the deposit information management table to an amount mismatch. After that, the memory control unit 19 terminates processing for the deposit information and returns to step S64-2.

[0223] In step S64-8, the memory control unit 19 updates the settlement status of the deposit information management table to manual settlement. After that, the memory control unit 19 finishes processing the deposit information and returns to step S64-2.

[0224] Figure 37 shows an example of an accounts receivable ledger information management table after automatic reconciliation. As shown in Figure 37, in the accounts receivable ledger information management table after automatic reconciliation, records have been added where the common invoice ID, invoice ID, and item ID match, and where the payment quantity and payment amount have been set.

[0225] Figure 38 shows an example of an accounts payable ledger information management table after automatic reconciliation. As shown in Figure 38, in the accounts payable ledger information management table after automatic reconciliation, records have been added where the common invoice ID, invoice ID, and item ID match, and where the payment quantity and payment amount have been set.

[0226] Note that the registration of payment quantities and amounts in the accounts payable ledger information management table is not performed by the automatic reconciliation process. The purchaser manually registers the accounts payable ledger information with the payment quantities and amounts set by operating the purchaser terminal 30.

[0227] However, the transaction management server 10 may be configured to refer to the payment information management table on the due date and automatically register the information in the accounts payable ledger information management table once payment is confirmed. Specifically, the payment information management table can be used to retrieve payment information for the current due date, and accounts payable ledger information with the common invoice ID, item ID, quantity, and amount set can be registered in the accounts payable ledger information management table.

[0228] Let's return to Figure 34 for explanation. In step S65, the reception unit 22 of the seller terminal 20 receives an operation from the seller to display the deposit management screen. The operation to display the deposit management screen is performed, for example, on the main menu screen provided by the transaction management server 10.

[0229] In step S66, the transmitting / receiving unit 21 of the seller terminal 20 sends a request to the transaction management server 10 to retrieve the payment management screen. This request includes the billing period. The billing period may be from the day after the billing closing date of the previous month to the billing closing date of the current month, or it may be specified in the display operation of the payment management screen. The transaction management server 10 receives the request to retrieve the payment management screen from the seller terminal 20 via the transmitting / receiving unit 11.

[0230] In step S67, the memory control unit 19 of the transaction management server 10 reads accounts receivable information from the accounts receivable information management DB based on the billing period included in the acquisition request for the payment management screen. Next, the memory control unit 19 reads invoice information from the issued invoice information management DB based on the common invoice ID included in the read accounts receivable information.

[0231] Next, the memory control unit 19 reads payment information from the payment information management DB based on the common invoice ID included in the read accounts receivable ledger information. Then, the creation unit 16 creates screen data for the payment management screen based on the accounts receivable ledger information, invoice information, and payment information read by the memory control unit 19.

[0232] ≪Process for creating the deposit management screen≫ Here, the details of the process for creating the deposit management screen in this embodiment (step S67 in Figure 34) will be explained with reference to Figure 39. Figure 39 is a flowchart showing an example of the process for creating the deposit management screen in this embodiment.

[0233] In step S67-1, the memory control unit 19 obtains first accounts receivable ledger information from the accounts receivable ledger information management DB. The first accounts receivable ledger information is accounts receivable ledger information in which the accounts receivable date is within the billing period and the payment quantity and payment amount are blank.

[0234] Steps S67-2 to S67-15 are performed for each of the first accounts receivable ledger information obtained in step S67-1.

[0235] In step S67-2, the determination unit 15 determines whether a common invoice ID and an item ID are set in the acquired first accounts receivable ledger information. If a common invoice ID and an item ID are set (YES), the determination unit 15 acquires the common invoice ID and the item ID and proceeds to step S67-3. If a common invoice ID and an item ID are not set (NO), the determination unit 15 proceeds to step S67-8.

[0236] In step S67-3, the memory control unit 19 retrieves second accounts receivable ledger information from the accounts receivable ledger information management DB based on the common invoice ID and item ID obtained in step S67-2. The second accounts receivable ledger information is accounts receivable ledger information in which the common invoice ID and item ID are the same as the first accounts receivable ledger information, and in which the payment quantity and payment amount are set.

[0237] In step S67-4, the determination unit 15 determines whether or not it was able to obtain the second accounts receivable ledger information in step S67-3. If the second accounts receivable ledger information was obtained (YES), the determination unit 15 proceeds to step S67-5. If the second accounts receivable ledger information was not obtained (NO), the determination unit 15 proceeds to step S67-10.

[0238] In step S67-5, the creation unit 16 retrieves the accounts receivable date, payment quantity, and payment amount from the second accounts receivable ledger information obtained in step S67-3. The retrieved accounts receivable date is displayed as the payment date on the payment management screen.

[0239] In step S67-6, the determination unit 15 determines whether the quantity and amount in the first accounts receivable ledger information match the quantity and amount received in the second accounts receivable ledger information. If the quantity and amount match the quantity and amount received (YES), the determination unit 15 terminates processing for the first accounts receivable ledger information and returns to step S67-2. If the quantity and amount do not match the quantity and amount received (NO), the determination unit 15 proceeds to step S67-7.

[0240] In step S67-7, the creation unit 16 decides to highlight the first accounts receivable ledger information as requiring attention. The highlighting can be done in any way, for example, by changing the background color, changing the text color, or displaying it in bold. After that, the creation unit 16 finishes processing the first accounts receivable ledger information and returns to step S67-2.

[0241] In step S67-8, the creation unit 16 sets the invoice status displayed on the payment management screen to "Not Issued".

[0242] In step S67-9, the creation unit 16 sets the expected payment quantity and expected payment amount to be displayed on the payment management screen to blank. After that, the creation unit 16 finishes processing the first accounts receivable ledger information and returns to step S67-2.

[0243] In step S67-10, the memory control unit 19 retrieves invoice information from the issued invoice information management DB based on the common invoice ID obtained in step S67-2. Next, the memory control unit 19 retrieves payment information from the payment information management DB based on the common invoice ID.

[0244] In step S67-11, the creation unit 16 retrieves the invoice status of the invoice information obtained in step S67-10. The retrieved invoice status is used as the invoice status displayed on the payment management screen.

[0245] In step S67-12, the determination unit 15 determines whether or not payment information was obtained in step S67-10. If payment information was obtained (YES), the determination unit 15 proceeds to step S67-13. If payment information was not obtained (NO), the determination unit 15 proceeds to step S67-9.

[0246] In step S67-13, the creation unit 16 retrieves the scheduled payment date from the payment information obtained in step S67-10. The retrieved scheduled payment date is then displayed on the payment management screen as the scheduled deposit date.

[0247] In step S67-14, the creation unit 16 obtains the quantity and amount of the payment information obtained in step S67-10 based on the detail ID of the first accounts receivable information obtained in step S67-1. The obtained quantity and amount are used as the expected payment quantity and expected payment amount displayed on the payment management screen.

[0248] In step S67-15, the determination unit 15 determines whether the quantity and amount in the first accounts receivable ledger information match the quantity and amount in the payment information. If the quantity and amount match (YES), the determination unit 15 terminates processing for the first accounts receivable ledger information and returns to step S67-2. If the quantity and amount do not match (NO), the determination unit 15 proceeds to step S67-7.

[0249] In step S67-16, the creation unit 16 creates the screen data of the payment management screen based on the information obtained in steps S67-1 to S67-15.

[0250] Returning to FIG. 34 for explanation. In step S68, the transmission / reception unit 11 included in the transaction management server 10 transmits the screen data of the payment management screen created by the creation unit 16 to the seller terminal 20. In the seller terminal 20, the transmission / reception unit 21 receives the screen data of the payment management screen from the transaction management server 10.

[0251] In step S69, the display control unit 24 included in the seller terminal 20 displays the payment management screen on the display 506 based on the screen data of the payment management screen.

[0252] (Payment Management Screen) Here, the payment management screen in this embodiment will be described with reference to FIG. 40. FIG. 40 is a conceptual diagram showing an example of the payment management screen in this embodiment.

[0253] As shown in FIG. 40, the payment management screen 2500 in this embodiment has a condition setting area 2510, a payment information display column 2520, and a detailed confirmation button 2521.

[0254] In the condition setting area 2510, when conditions such as the billing period are input, the payment information that matches the conditions is displayed in the payment information display column 2520. Each condition value displayed in the condition setting area 2510 may be set in advance. For example, the billing period may be set from the day after the billing closing date of the previous month to the billing closing date of the current month.

[0255] For each payment information displayed in the payment information display column 2520, one detailed confirmation button 2521 is displayed. When the detailed confirmation button 2521 is pressed, a screen for displaying the details of the payment information is displayed. The detailed confirmation button 2521 can be used to confirm the details when the amount in the details does not match the scheduled payment amount or the paid amount.

[0256] Furthermore, the detailed confirmation button 2521 corresponding to payment information for which information regarding the expected payment (expected payment date, expected payment quantity, and expected payment amount) or payment information (payment date and payment amount) is not displayed may be controlled to be hidden.

[0257] Figure 41 shows an example of the deposit management screen 2500 when a payment has been made. As shown in Figure 41, in the deposit management screen 2500 when a payment has been made, the deposit date and deposit amount are displayed in the deposit information display field 2520.

[0258] [Main effects of the first embodiment] In this embodiment, the transaction management server 10 has the seller's transaction terms and the buyer's payment terms pre-registered. On the invoice creation screen, the user can select which terms to prioritize, and the server will then propose an invoice that conforms to the selected terms. Therefore, the transaction management server 10 in this embodiment can propose an invoice that takes into account the terms of both the seller and the buyer.

[0259] [Second Embodiment] In the first embodiment, an example was described in which the billing date and payment terms were agreed upon in advance between the seller and the buyer. In the second embodiment, an example was described in which the payment terms were agreed upon in advance, but the billing date was not.

[0260] In the first embodiment, since there is an agreement on the billing closing date and payment terms, the payment due date is determined to be the date after the number of days in the payment terms has elapsed from the billing closing date. In the second embodiment, there is no agreement on the billing closing date, and the seller can set it independently without the buyer's consent. Therefore, the payment due date is determined to be the date after the number of days in the payment terms has elapsed from the date the accounts receivable were generated. However, the items to be billed are determined by the seller based on the billing closing date.

[0261] In the first embodiment, the billing closing date is the starting date, so all items included in the invoice have the same payment due date. On the other hand, in the second embodiment, the starting date is the date on which the accounts receivable for each item arises, so the payment due date differs for each item. Therefore, depending on the relationship between the billing closing date and the payment closing date, it may be necessary to pay in the previous payment period in order to meet the payment terms. Accordingly, in the example of the second embodiment, the buyer needs to decide which items to pay from the items listed on the invoice in order to meet the payment terms.

[0262] The information processing system in the second embodiment will be described below, focusing on the differences from the first embodiment, with reference to Figures 42 to 46.

[0263] (Transaction conditions setting screen) Figure 42 is a conceptual diagram showing an example of a transaction conditions setting screen in this embodiment. As shown in Figure 42, the transaction conditions setting screen 3000 in this embodiment has multiple customer input fields 3001, multiple payment term input fields 3002, and one billing closing date input field 3003.

[0264] Multiple customer input fields 3001 and multiple payment terms input fields 3002 are associated on a one-to-one basis. In the transaction terms setting screen 3000 of this embodiment, payment terms are set for each of the multiple customers, and the same billing closing date is set for all customers.

[0265] As shown in Figure 42, in this embodiment, payment terms 45 are set for the purchaser, Company B.

[0266] (Transaction Terms Management Table) Figure 43 is a conceptual diagram showing an example of a transaction conditions management table in this embodiment. As shown in Figure 43, the transaction conditions management table in this embodiment stores the transaction conditions set on the transaction conditions setting screen 3000 shown in Figure 42.

[0267] (Payment Terms Management Table) Figure 44 is a conceptual diagram showing an example of a payment terms management table in this embodiment. As shown in Figure 44, in this embodiment, the purchaser, Company B, has set the payment due date to the 12th of the following month.

[0268] (Accounts Payable Ledger Information Management Table) Figure 45 is a conceptual diagram showing an example of an accounts payable information management table in this embodiment. As shown in Figure 45, in this embodiment, accounts payable information for 5 whiteboards with an accounts payable date of September 26, 2020, and accounts payable information for 35 chairs with an accounts payable date of September 29, 2020 are stored.

[0269] (Payment processing screen) Figure 46 is a conceptual diagram showing an example of a payment processing screen in this embodiment. As shown in Figure 46, in the payment processing screen 2400 in this embodiment, there is accounts payable information displayed in the accounts payable information display field 2460 that is not subject to payment. Specifically, among the accounts payable information displayed in the accounts payable information display field 2460, accounts payable information with a payment date of September 26th is included in the payment targets, but accounts payable information with a payment date of September 29th is not included in the payment targets.

[0270] In this embodiment, the payment due date is calculated based on the payment terms, with the accounts payable date as the starting date. Therefore, if the accounts payable ledger information with an accounts payable date of September 26th is paid on the next payment date of November 12th, the conditions of payment terms 45 cannot be met. Consequently, the accounts payable ledger information with an accounts payable date of September 26th must be included in the payment targets. On the other hand, if the accounts payable ledger information with an accounts payable date of September 29th is paid on the next payment date of November 12th, the conditions of payment terms 45 will be met. Consequently, it does not need to be included in the payment targets.

[0271] [Main effects of the second embodiment] In the present embodiment, when the conditions of the payment site are applied with the date on which the account payable occurred as the starting date, even for the account payable information included in the next payment period, if the account payable information cannot meet the conditions of the payment site when paying on the next payment date, the transaction management server 10 in the present embodiment performs control to make it a payment target. Therefore, according to the transaction management server 10 in the present embodiment, it is possible to avoid a situation where the conditions of the payment site cannot be met due to the relationship between the billing closing date and the payment closing date.

[0272] [Supplementary Explanation] In the above embodiment, the invoice information on the seller side is stored in the issued invoice information management table, and the invoice information on the purchaser side is stored in the received invoice information management table. Here, the transaction management server 10 may be configured to include an invoice information management table common to each tenant and share the invoice information. By configuring it in this way, it is possible to refer to the invoice information without the purchaser side performing operations such as receiving the invoice.

[0273] In the above embodiment, the transaction management server 10 is an example of an information processing device. The seller terminal 20 is an example of an information processing terminal. The transmission / reception unit 11 is an example of a transmission unit or a reception unit.

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

[0275] The apparatus described in the examples represents only one of several computing environments for carrying out the embodiments disclosed herein. In one embodiment, the transaction management server 10 and the account management server 40 include multiple computing devices, such as a server cluster. The multiple computing devices are configured to communicate with each other via any type of communication link, including a network or shared memory, and perform the processing disclosed herein.

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

[0277] 1. Information Processing System 10 Transaction Management Server 20 Seller terminals 30 Purchaser's device 40 Account Management Server 11,21,31,41 Transmitter / Receiver 22,32 Reception Department 24,34 Display Control Unit 15,25,35,45 Judgment section 16,46 Creation Department 19,29,39,49 Memory Control Unit 100,200,300,400 storage section [Prior art documents] [Patent Documents]

[0278] [Patent Document 1] Japanese Patent Publication No. 2008-9873

Claims

1. An information processing device that can communicate with an information processing terminal used by a user via a network, A storage control unit that stores the user's transaction terms and the payment terms of the trading partner in a storage unit, A determination unit that determines which of the aforementioned transaction terms and payment terms to prioritize when generating invoice information, Based on the determination result by the determination unit, an identification unit identifies the items to be included in the invoice information from among multiple items included in the accounts receivable ledger information, A transmission unit transmits screen data to the information processing terminal for displaying a screen that proposes the generation of invoice information based on the details identified by the identification unit, An information processing device equipped with the following features.

2. An information processing apparatus according to claim 1, The aforementioned terms and conditions include the terms relating to the billing date and payment terms, The aforementioned payment terms include terms relating to the payment closing date and the scheduled payment date. Information processing device.

3. An information processing apparatus according to claim 2, The aforementioned screen selects the items to be included in the invoice information based on the relationship between the billing closing date and the payment closing date. Information processing device.

4. An information processing apparatus according to claim 3, The aforementioned billing closing date and payment terms are conditions agreed upon in advance by the user and the business partner. The aforementioned screen calculates the payment due date to be included in the invoice information based on the billing closing date and the payment terms. Information processing device.

5. An information processing apparatus according to claim 3, The aforementioned payment terms are conditions agreed upon in advance by the user and the business partner. The aforementioned screen selects the items to be included in the invoice information based on the relationship between the due date calculated based on the accounts receivable date and payment terms of the items, and the scheduled payment date. Information processing device.

6. An information processing terminal capable of communicating with an information processing device via a network, A display control unit that displays a screen for proposing the generation of invoice information based on specific details, A transmission unit that transmits a payment request to the information processing device, which identifies the details to be paid from the invoice information, Equipped with, The aforementioned specific details are identified from among multiple details included in the accounts receivable ledger information, based on the result of determining which of the user's transaction terms and the trading partner's payment terms should take precedence when generating invoice information. An information processing terminal.

7. An information processing system in which an information processing terminal used by a user and an information processing device can communicate via a network, The aforementioned information processing device is A storage control unit that stores the user's transaction terms and the payment terms of the trading partner in a storage unit, A determination unit that determines which of the aforementioned transaction terms and payment terms to prioritize when generating invoice information, Based on the determination result by the determination unit, an identification unit identifies the items to be included in the invoice information from among multiple items included in the accounts receivable ledger information, A transmission unit transmits screen data to the information processing terminal for displaying a screen that proposes the generation of invoice information based on the details identified by the identification unit, Equipped with, The aforementioned information processing terminal is A display control unit that displays the screen based on the screen data, A transmission unit that transmits a payment request to the information processing device, which identifies the details to be paid from the invoice information, An information processing system equipped with the following features.

8. A computer that can communicate with the information processing terminal used by the user via a network, A storage control procedure for storing the user's transaction terms and the trading partner's payment terms in a storage unit, A determination procedure for determining which of the aforementioned transaction terms and payment terms should take precedence when generating invoice information, Based on the determination result of the above determination procedure, a selection procedure is performed to identify which items to include in the invoice information from among multiple items included in the accounts receivable ledger information. A transmission procedure for sending screen data to the information processing terminal to display a screen that proposes the generation of invoice information based on the details identified by the aforementioned specific procedure, An information processing method that performs the following.

9. A computer that can communicate with the information processing terminal used by the user via a network, A storage control procedure for storing the user's transaction terms and the trading partner's payment terms in a storage unit, A determination procedure for determining which of the aforementioned transaction terms and payment terms should take precedence when generating invoice information, Based on the determination result of the above determination procedure, a selection procedure is performed to identify which items to include in the invoice information from among multiple items included in the accounts receivable ledger information. A transmission procedure for sending screen data to the information processing terminal to display a screen that proposes the generation of invoice information based on the details identified by the aforementioned specific procedure, A program to execute.

10. A computer that can communicate with an information processing device via a network, A display control procedure for displaying a screen that proposes the generation of invoice information based on specific details, A transmission procedure for sending a payment request to the information processing device, which identifies the details to be paid from the aforementioned invoice information, Make it run, The aforementioned specific details are identified from among multiple details included in the accounts receivable ledger information, based on the result of determining which of the user's transaction terms and the trading partner's payment terms should take precedence when generating invoice information. program.

Images