JP2023140701A - Information processing apparatus, information processing terminal, information processing system, information processing method, and program - Google Patents

Abstract

To specify a statement to be settled.SOLUTION: An information processing apparatus which can communicate with an information processing terminal used by a user over a network, includes: a receiving unit which receives, from the information processing terminal, a payment request with a statement to be settled which is specified from invoice information issued to the user; and a storage control unit which stores, in a storage unit, payment information that associates the statement with identification information identifying the payment request.SELECTED DRAWING: Figure 4

Description

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

Traditionally, in the reconciliation process for commercial transactions, the seller collects information such as the deposit amount and date included in the deposit information sent by the buyer, as well as information such as the billed amount and payment due date written on the invoice. Accounts receivable related to the invoices are cleared while checking with the above. In this case, the seller checks whether the accounts receivable are being collected according to the invoice and whether there are any delays in collection (see Patent Document 1).

However, there is a problem in that it is difficult to specify the details to be paid from the deposit information. For example, when the purchaser remits the amount related to some of the details included in the invoice, the billed amount stated on the invoice and the amount received do not match. In this case, it becomes necessary for the seller and the purchaser to confirm the details of the payment, which is a burden for both parties.

In view of the above-mentioned technical problems, an embodiment of the present invention is to make it possible to specify details for which payment is to be made.

In order to solve the above problems, an information processing device that is an embodiment of the present invention is an information processing device that can communicate with an information processing terminal used by a user via a network, and is an information processing device that is issued to a user. a receiving unit that receives a payment request specifying details to be paid from the bill information from the information processing terminal; a storage control unit that stores payment information that associates identification information for identifying the payment request with the details in the storage unit; , is provided.

According to an embodiment of the present invention, it is possible to specify details for which payment is to be made.

FIG. 2 is a conceptual diagram showing relationships between companies in one embodiment. FIG. 1 is a diagram illustrating an example of the overall configuration of an information processing system in an embodiment. FIG. 1 is a diagram illustrating an example of a hardware configuration of an information processing device in an embodiment. FIG. 1 is a diagram illustrating an example of a functional configuration of an information processing system in an embodiment. It is a figure showing an example of bill creation and sending processing in a 1st embodiment. It is a figure showing an example of a tenant information management table in a 1st embodiment. It is a figure showing an example of an accounts receivable information management table in a 1st embodiment. It is a figure showing an example of a bill creation screen in a 1st embodiment. It is a figure showing an example of a bill image in a 1st embodiment. FIG. 3 is a diagram showing an example of an issued bill information management table in the first embodiment. It is a figure showing an example of an accounts receivable information management table in a 1st embodiment. It is a figure showing an example of a bill sending screen in a 1st embodiment. It is a figure showing an example of a receipt information management table in a 1st embodiment. It is a figure showing an example of bill receipt processing in a 1st embodiment. It is a figure showing an example of a bill receipt screen in a 1st embodiment. FIG. 3 is a diagram showing an example of a received bill information management table in the first embodiment. It is a figure showing an example of remittance data creation processing in a 1st embodiment. It is a figure showing an example of a receipt bill list screen in a 1st embodiment. It is a figure showing an example of an accounts payable information management table in a 1st embodiment. It is a figure showing an example of a payment processing screen in a 1st embodiment. 7 is a diagram illustrating an example of a payment processing screen in Modification 1. FIG. 7 is a diagram illustrating an example of an accounts payable information management table in Modification 1. FIG. 7 is a diagram illustrating an example of a payment processing screen in Modification 2. FIG. 7 is a diagram showing an example of a chat history management table in Modification 2. FIG. It is a figure showing an example of a payment information management table in a 1st embodiment. It is a figure showing an example of an accounts payable information management table in a 1st embodiment. It is a figure showing an example of payment information acquisition and automatic payment processing in a 1st embodiment. It is a figure showing an example of a deposit information management table in a 1st embodiment. It is a diagram showing an example of automatic redemption processing in the first embodiment. It is a figure showing an example of an accounts receivable information management table in a 1st embodiment. It is a figure showing an example of an accounts payable information management table in a 1st embodiment. It is a figure showing an example of deposit management screen creation processing in a 1st embodiment. It is a figure showing an example of a deposit management screen in a 1st embodiment. It is a figure showing an example of a deposit management screen in a 1st embodiment. 12 is a diagram showing an example of a deposit management screen in Modification 3. FIG. It is a figure which shows an example of the accounts receivable information management table in 2nd Embodiment. It is a figure showing an example of a bill creation screen in a 2nd embodiment. It is a figure which shows an example of a bill image in 2nd Embodiment. FIG. 7 is a diagram showing an example of an issued bill information management table in the second embodiment. It is a figure which shows an example of the received bill information management table in 2nd Embodiment. It is a figure showing an example of an accounts payable information management table in a 2nd embodiment. It is a figure showing an example of a payment processing screen in a 2nd embodiment. It is a figure which shows an example of the payment information management table in 2nd Embodiment. It is a figure showing an example of a deposit management screen in a 2nd embodiment.

Embodiments of the present invention will be described in detail below with reference to the drawings. Note that in the drawings, components having the same functions are designated by the same numbers, and redundant explanation will be omitted.

[First embodiment]
[Relationship between companies]
The relationship between companies in this embodiment will be explained with reference to FIG. 1. FIG. 1 is a conceptual diagram showing the relationship between companies in this embodiment.

As shown in FIG. 1, service using company A is a company that receives compensation from service using company B by providing products or services to service using company B, which is a business partner. In this case, the service user company A, which is the seller, becomes the creditor, and the service user company B, the purchaser, becomes the debtor.

Service providing company C is a company that provides a service in which service using company A creates a bill (generating bill information) to send to service using company B on behalf of service using company A upon receiving a request from service using company A. In this embodiment, an entity that uses a service provided by a service providing company may be referred to as a tenant. That is, in this embodiment, a tenant is a business, an organization, an individual, or the like.

Financial institution D1 is a financial institution that manages the bank account of service user company B. Financial institution D2 is a financial institution that manages the bank account of service user company A. Note that this is not limited to a financial institution, but may also be a collection agency that manages accounts through an account transfer service.

Here, an outline of the processing in this embodiment will be explained. Note that each ID described below is an example of identification information.

First, service using company A requests service providing company C to create and send an invoice (generating bill information) to be issued to service using company B (step S1). As a result, service using company B receives the bill from service using company A via service providing company C (step S2).

Service user company B sends a payment request specifying the details to be paid to service provider company C (step 3-1). As a result, service providing company C creates remittance data including a payment ID that identifies the payment request, and sends it to service using company B (step S3-2). This remittance data is used for remittance based on an invoice from the bank account of the purchaser (service user company B) to the bank account of the seller (service user company A). That is, service providing company C creates remittance data that service using company B uses when remittance, and further performs a process of including a payment ID in the remittance data when creating the remittance data.

Next, service using company B sends remittance data including the payment ID to financial institution D1 (step S4-1). As a result, the financial institution D1 remits the amount according to the remittance data to the financial institution D2 that manages the bank account of the service using company A (step S4-2). At this time, the payment ID is also sent from the financial institution D1 to the financial institution D2 together with the remittance data.

Next, after confirming the deposit into the bank account of service user company A, financial institution D2 provides service provider C with payment information including payment details and payment ID (deposit source, deposit amount, deposit date). etc.) will be sent. As a result, service providing company C obtains payment information (step S5).

Next, the service providing company C identifies the details of the bill to be paid based on the payment ID included in the payment information, and performs a reconciliation process regarding the details (step S6). Even if a remittance is made based on some of the details included in an invoice, the payment ID can be used to identify the details to be paid, and it can be checked whether the invoiced amount and the received amount for the particular details match. It can be confirmed. Therefore, even if payment is made in units of details included in an invoice, it can be automatically cleared.

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

As shown in FIG. 2, the information processing system 1 in this embodiment includes a transaction management server 10, a seller terminal 20, a purchaser terminal 30, and two account management servers 40. Transaction management server 10, seller terminal 20, purchaser terminal 30, and account management server 40 are each connected to communication network N1.

The communication network N1 is configured so that connected devices can communicate with each other. The communication network N1 is constructed, for example, by a wired communication network such as the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

The communication network N1 includes not only wired communication but also wireless communication such as wireless LAN or short-range wireless communication, WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), 5G (5th Generation), etc. This may include a mobile communication network.

The seller terminal 20 is installed at service user company A (seller). The purchaser terminal 30 is installed at service using company B (purchaser). The transaction management server 10 is installed in a service providing company C. The purchaser's account management server 40-1 is installed in the financial institution D1. The account management server 40-2 on the seller side is installed in the financial institution D2.

The seller terminal 20 and the purchaser terminal 30 include, for example, a PJ (Projector), an IWB (Interactive White Board: a whiteboard with an electronic blackboard function that allows mutual communication), an output device such as a digital signage, and a HUD ( head up display) devices, industrial machinery, imaging devices, sound collection devices, medical equipment, network appliances, connected cars, personal computers, mobile phones, smartphones, tablets, game consoles, personal digital assistants (PDAs), Assistant), digital camera, wearable PC, or desktop PC.

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

As shown in FIG. 3, the computer in this embodiment includes a CPU (Central Processing Unit) 501, a ROM (Read Only Memory) 502, a RAM (Random Access Memory) 503, an HD (Hard Disk) 504, an 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, media Equipped with I/F516.

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

The display 506 displays various information such as a cursor, menu, window, characters, or images. External device connection I/F 508 is an interface for connecting various external devices. The external device in this case is, for example, a USB (Universal Serial Bus) memory, a printer, or the like. The network I/F 509 is an interface for data communication using the communication network N1. The bus line 510 is an address bus, a data bus, etc. for electrically connecting each component such as the CPU 501 shown in FIG. 3.

Further, the keyboard 511 is a type of input means that includes a plurality of keys for inputting characters, numerical values, various instructions, and the like. The pointing device 512 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, and the like. The DVD-RW drive 514 controls reading and writing of various data on a DVD-RW 513, which is an example of a removable recording medium. Note that it is not limited to DVD-RW, but may be DVD-R or the like. The media I/F 516 controls reading or writing (storage) of data to a recording medium 515 such as a flash memory.

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

<Functional configuration of transaction management server>
As shown in FIG. 4, the transaction management server 10 in this embodiment includes a transmitting/receiving section 11, a generating section 14, a determining section 15, a creating section 16, a storage control section 19, and a storage section 100. Each of these units is a function or functioning means that is realized when any of the components shown in FIG. . Furthermore, the storage unit 100 is constructed by the RAM 503 and HD 504 shown in FIG.

The transmitting/receiving unit 11 is realized by commands from the CPU 501 and network I/F 509 shown in FIG. 3, and transmits and receives various data (or information) to and from other terminals, devices, or systems via the communication network N1. .

The generation unit 14 is realized by instructions from the CPU 501 shown in FIG. 3, and generates predetermined data (information). The generated content will be described later.

The judgment unit 15 is realized by instructions from the CPU 501 shown in FIG. 3, and makes a predetermined judgment. The details of the judgment will be described later.

The creation unit 16 is realized by instructions from the CPU 501 shown in FIG. 3, and creates each screen, the URL of each screen, etc., which will be described later.

The storage control unit 19 is realized by instructions from the CPU 501 and the HDD controller 505 shown in FIG. I do.

The storage unit 100 includes tenant information management DB, accounts receivable information management DB, accounts payable information management DB, issued invoice information management DB, receipt information management DB, received invoice information management DB, payment information management DB, and payment information. A management DB has been constructed.

The tenant information management DB is configured by a tenant information management table. The tenant information management table stores information regarding service using company A and service using company B, which are tenants of the transaction management server 10. Details of the tenant information management table will be described later.

The accounts receivable information management DB is composed of an accounts receivable information management table for each tenant. The accounts receivable information management table stores accounts receivable information based on sales information from a seller (service using company A) to a purchaser (service using company B). The account receivable information may be imported from an external system having an account receivable account, such as an accounting system. If the transaction management server 10 also has an accounting function, an account receivable book owned by the transaction management server 10 may be used. Details of the accounts receivable information management table will be described later.

The accounts payable information management DB is composed of an accounts payable information management table for each tenant. The accounts payable information management table stores accounts payable information based on delivery information from a seller (service user company A) to a purchaser (service user company B). Accounts payable information may be imported from an external system having accounts payable, such as an accounting system. If the transaction management server 10 also has an accounting function, an accounts payable book that the transaction management server 10 has may be used. Details of the accounts payable information management table will be described later.

The issued bill information management DB is composed of issued bill information management tables for each tenant. The issued invoice information management table stores invoice information regarding invoices issued by the seller (service using company A) to the purchaser (service using company B). Details of the issued bill information management table will be described later.

The receipt information management DB is composed of a receipt information management table for each tenant. The receipt information management table stores receipt information for the purchaser (service using company B) to receive the bill. Details of the receipt information management table will be described later.

The received invoice information management DB is composed of received invoice information management tables for each tenant. The issued invoice information management table stores invoice information regarding invoices received by the purchaser (service using company B) from the seller (service using company A). Details of the received bill information management table will be described later.

The payment information management DB is composed of a payment information management table for each tenant. The payment information management table stores payment information sent by the purchaser (service using company B) to the seller (service using company A). Details of the payment information management table will be described later.

The deposit information management DB is composed of a deposit information management table for each tenant. The deposit information management table stores deposit information remitted to the account of the seller (service user company A). Details of the deposit information management table will be described later.

<Functional configuration of seller terminal>
As shown in FIG. 4, the seller terminal 20 in this embodiment includes a transmitting/receiving section 21, a reception section 22, a display control section 24, a determination section 25, a storage control section 29, and a storage section 200. Each of these units is a function or a means of functioning that is realized when any of the components shown in FIG. be. Furthermore, the storage unit 200 is constructed by the RAM 503 and HD 504 shown in FIG.

The transmitting/receiving unit 21 is realized by instructions from the CPU 501 shown in FIG. 3, an external device connection I/F 508, and a network I/F 509, and transmits various data ( or information).

The receiving unit 22 is mainly realized by commands from the CPU 501 shown in FIG. 3, as well as the keyboard 511 and pointing device 512, and receives various inputs from the user.

The display control unit 24 is mainly realized by instructions from the CPU 501 shown in FIG. 3, and outputs image data to the display 506 or an external display connected to the external device connection I/F 508. to display the image. The display control unit 24 has a web browser function.

The determining unit 25 is mainly realized by instructions from the CPU 501 shown in FIG. 3, and performs various determinations.

The storage control unit 29 is mainly realized by instructions from the CPU 501 and the HDD controller 505 shown in FIG. Perform processing such as

<Functional configuration of purchaser terminal>
As shown in FIG. 4, the purchaser terminal 30 in this embodiment includes a transmitting/receiving section 31, a reception section 32, a display control section 34, a determination section 35, a storage control section 39, and a storage section 300.

The transmitting/receiving unit 31, receiving unit 32, display control unit 34, determining unit 35, storage control unit 39, and storage unit 300 included in the purchaser terminal 30 are the transmitting/receiving unit 21, receiving unit 22, and display included in the seller terminal 20, respectively. Since it has the same functions as the control section 24, determination section 25, storage control section 29, and storage section 200, the description thereof will be omitted.

<Functional configuration of account management server>
As shown in FIG. 4, the account management server 40 in this embodiment includes a transmitting/receiving section 41, a determining section 45, a creating section 46, a storage control section 49, and a storage section 400. Each of these units is a function or functioning means that is realized when any of the components shown in FIG. . Furthermore, the storage unit 400 is constructed by the RAM 503 and HD 504 shown in FIG.

The transmitting/receiving unit 41 is realized by commands from the CPU 501 and network I/F 509 shown in FIG. 3, and transmits and receives various data (or information) to and from other terminals, devices, or systems via the communication network N1. .

The judgment unit 45 is realized by instructions from the CPU 501 shown in FIG. 3, and makes a predetermined judgment. The details of the judgment will be described later.

The creation unit 46 is realized by instructions from the CPU 501 shown in FIG. 3, and creates screens and the like.

The storage control unit 49 is realized by instructions from the CPU 501 and the HDD controller 505 shown in FIG. I do.

Note that the account management server 40 may be a server device provided by a financial institution, or may be a server device provided by a predetermined service that cooperates with the financial institution system.

[Processing procedure of information processing system]
The processing procedure of the information processing method executed by the information processing system in this embodiment will be described with reference to FIGS. 5 to 35.

<Creating and sending invoices>
First, the bill creation and sending process (step S1 in FIG. 1) in this embodiment will be explained with reference to FIG. FIG. 5 is a sequence diagram showing an example of bill creation and sending processing in this embodiment.

In step S11, the reception unit 22 included in the seller terminal 20 receives an operation by the seller to display an invoice creation screen. The seller is, for example, a person in charge of the business of service user company A.

The reception unit 22 receives authentication information such as a tenant ID, which is tenant identification information, input by the seller before accepting the display operation of the bill creation screen. Then, the transmitting/receiving unit 21 transmits the authentication information to the transaction management server 10, and the transaction management server 10 performs a predetermined authentication process. The transaction management server 10 uses the tenant information management DB to authenticate the seller. Therefore, only when the seller is authenticated by the transaction management server 10, the reception unit 22 can accept the seller's operation to display the invoice creation screen.

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

As shown in FIG. 6, the tenant information management table 1000 in this embodiment includes information representing the tenant (company name, etc.), authentication information (user ID and password, etc.), and contact information (email address, address, etc.) and the account information of the transfer destination, etc. are managed in association with each other.

In this embodiment, it is assumed that the tenant can use the service both as a seller and as a purchaser. However, by registering a user role representing a seller, a purchaser, etc. as tenant information, a specific tenant may be restricted to use the service only as a seller or only as a purchaser.

The explanation will be returned to FIG. 5. In step S12, the transmitting/receiving unit 21 included in the seller terminal 20 transmits an invoice creation screen acquisition request to the transaction management server 10. In the transaction management server 10 , the transmitting/receiving unit 11 receives a request to obtain an invoice creation screen from the seller terminal 20 .

In step S13, the storage control unit 19 included in the transaction management server 10 reads the account receivable information from the account receivable information management DB. Next, the creation unit 16 creates screen data for an invoice creation screen based on the account receivable information read by the storage control unit 19.

(Accounts receivable information management table)
Here, details of the accounts receivable information management table will be explained with reference to FIG. 7. FIG. 7 is a conceptual diagram showing an example of the accounts receivable information management table in this embodiment.

As shown in FIG. 7, in the accounts receivable information management table 1100 according to the present embodiment, the date on which an account receivable occurred (hereinafter also referred to as "account receivable date"), identification information for identifying an invoice (common Invoice ID, invoice ID, etc.), information on details in the invoice (detail ID, product code, unit price, quantity, amount, etc.), information on deposits (deposit quantity and amount), etc. are managed in association. .

The example of account receivable information shown in FIG. 7 is in an initial state imported from the account receivable account. In the initial state, each piece of identification information (common bill ID, bill ID, and detail ID) and information regarding deposits (deposit quantity and deposit amount) are blank.

The explanation will be returned to FIG. 5. In step S14, the transmission/reception unit 11 included in 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. In the seller terminal 20, the transmitting/receiving unit 21 receives the screen data of the invoice creation screen from the transaction management server 10.

In step S15, the display control unit 24 included in the seller terminal 20 displays an invoice creation screen on the display 506 based on the screen data of the invoice creation screen.

(Bill creation screen)
Here, the bill creation screen in this embodiment will be explained with reference to FIG. 8. FIG. 8 is a conceptual diagram showing an example of the bill creation screen in this embodiment.

As shown in FIG. 8, the invoice creation screen 2000 in this embodiment includes a condition setting area 2010, an accounts receivable display area 2020, a create button 2008, and a cancel button 2009.

When conditions such as billing destination, billing deadline, billing period, etc. are entered in the condition setting area 2010, accounts receivable information that matches the conditions is displayed in the accounts receivable display area 2020. Each condition value displayed in the condition setting area 2010 may be set in advance. For example, the billing period may be set from the day after the previous month's billing deadline to the current month's billing deadline.

In the accounts receivable display area 2020, the contents of the accounts receivable information are displayed in a form in which each detail can be selected. For example, by displaying one checkbox for each item, the item can be displayed in a selectable manner. In the initial state, it is assumed that all details are selected.

When the seller presses the create button 2008, the reception unit 22 accepts an operation to create a bill (generate bill information). When the seller presses the cancel button 2009, the display control unit 24 closes the invoice creation screen 2000.

The explanation will be returned to FIG. 5. In step S16, the receiving unit 22 included in the seller terminal 20 receives an operation of creating an invoice (generating invoice information) by the seller. Specifically, the seller selects the details to be included in the invoice on the invoice creation screen 2000 and presses the create button 2008.

In step S17, the transmitting/receiving unit 21 included in the seller terminal 20 transmits a bill information registration request to the transaction management server 10. The registration request includes the account receivable information selected in the account receivable display area 2020. In the transaction management server 10 , the transmitting/receiving unit 11 receives a request for registering bill information from the seller terminal 20 .

In step S18, the creation unit 16 included in the transaction management server 10 creates an invoice image as shown in FIG. 9 based on the invoice information registration request, and stores it in a predetermined storage location. At this time, the creation unit 16 creates a receipt screen URL that is a URL (Uniform Resource Locator) for accessing the receipt screen for receiving the bill.

Next, the storage control unit 19 generates bill information representing the contents of the bill and registers it in the issued bill information management DB. Furthermore, the storage control unit 19 updates the accounts receivable information management DB based on the generated bill information. At this time, the storage control unit 19 issues a common bill ID and bill ID for identifying the bill, and a statement ID for identifying each statement.

The common bill ID is identification information that the transaction management server 10 sets in each piece of bill information for common management among each tenant. The bill ID is identification information that the tenant arbitrarily sets in the bill information. Therefore, in subsequent processing, the identification information used by the transaction management server 10 to identify bill information is the common bill ID. However, if it is possible to control the bill ID so that it does not overlap between tenants, the bill ID may be used instead of the common bill ID.

(Issued invoice information management table)
Here, details of the issued bill information management table will be explained with reference to FIG. 10. FIG. 10 is a conceptual diagram showing an example of the issued bill information management table 1300 in this embodiment.

As shown in FIG. 10, the issued invoice information management table in this embodiment includes identification information for identifying invoices (common invoice ID, invoice ID, etc.), information representing the billing party ( billing company name, etc.), billing amount, billing date, payment due date, bill status, bill image storage location, details information (detail ID, product code, product name, unit price, quantity, amount, etc.), and transfer Destination information etc. are managed in association with each other.

Among these, the total amount of the amount of the selected account receivable information is set as the billing amount. The payment due date is automatically set based on the payment site corresponding to the purchaser. For example, if the purchaser is payment site 30 (Sunday), the payment deadline is the end of the next month. Further, for example, if the purchaser is the payment site 60 (Sunday), the payment deadline is the end of the month after the next month. The invoice status is set to "Created." Transfer destination information is obtained from the tenant information management table.

FIG. 11 shows an example of the accounts receivable information management table after invoice creation. As shown in Figure 11, in the accounts receivable information management table after invoice creation, the common invoice ID, invoice ID, and detail ID are registered in the accounts receivable account information that issued the invoice. .

The explanation will be returned to FIG. 5. In step S19, the reception unit 22 included in the seller terminal 20 accepts an invoice sending operation by the seller. The bill sending operation is performed on the bill sending screen. The bill sending screen is displayed, for example, by selecting a bill to be sent on a screen displaying a list of created bills.

(Bill sending screen)
Here, the bill sending screen in this embodiment will be explained with reference to FIG. 12. FIG. 12 is a conceptual diagram showing an example of the bill sending screen in this embodiment.

As shown in FIG. 12, the bill sending screen 2100 in this embodiment includes a destination selection field 2101, a bill image display field 2102, a cover letter input field 2103, a send button 2108, and a cancel button 2109.

Among these, the destination selection field 2101 selectably displays e-mail addresses associated with the purchaser in the tenant information management table. The bill image display field 2102 displays the bill image indicated by the bill image storage location in the issued bill information management table.

In the cover letter input field 2103, the subject and text to be written when sending the bill are input. Preferably, a predetermined template is initially displayed for the subject and body. A link to the receipt screen URL is embedded in the cover letter input field 2103.

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 bill sending screen 2100.

The explanation will be returned to FIG. 5. In step S20, the transmitting/receiving unit 21 included in the seller terminal 20 transmits a bill sending request to the transaction management server 10. The common bill ID is included in the sending request. In the transaction management server 10, the transmitting/receiving unit 11 receives a bill sending request from the seller terminal 20.

In step S21, the storage control unit 19 included in the transaction management server 10 specifies bill information in the issued bill information management table based on the common bill ID included in the bill sending request. Next, the storage control unit 19 updates the bill status of the specified bill information to "sent".

In step S22, the storage control unit 19 included in the transaction management server 10 generates receipt information based on the bill sending request and registers it in the receipt information management DB.

(Receipt information management table)
Here, details of the receipt information management table will be explained with reference to FIG. 13. FIG. 13 is a conceptual diagram showing an example of the receipt information management table in this embodiment.

As shown in FIG. 13, the receipt information management table 1400 in this embodiment includes identification information for identifying a bill (common bill ID, bill ID, etc.), information representing the issuer of the bill (issue (original company name, etc.), issue date, receipt screen URL, etc. are managed in association with each other.

The explanation will be returned to FIG. 5. In step S23, the transmitting/receiving unit 11 included in the transaction management server 10 transmits an e-mail including the receipt screen URL to the purchaser terminal 30. Note that the transmitting/receiving unit 11 does not have to directly transmit the e-mail including the receipt screen URL to the purchaser terminal 30. For example, the transmitting/receiving unit 11 may transmit an e-mail to a predetermined e-mail address of the purchaser, and the purchaser terminal 30 may receive the e-mail from a mail server.

The method of transmitting the receipt screen URL is not limited to email. For example, a message including the receipt screen URL may be sent to the purchaser terminal 30 via a messenger application. Further, the creation unit 16 creates a two-dimensional code indicating the receipt screen URL, embeds the two-dimensional code in the invoice image, and the transmitting/receiving unit 11 transmits the invoice image in which the two-dimensional code is embedded to the printing device. However, it is also possible to print out the invoice image on recording paper and send the printed paper invoice to the purchaser by mail.

<Bill receipt processing>
Next, the bill receiving process (step S2 in FIG. 1) in this embodiment will be described with reference to FIG. 14. FIG. 14 is a sequence diagram illustrating an example of bill receipt processing in this embodiment.

In step S31, the transmitting/receiving unit 31 included in the purchaser terminal 30 receives an e-mail or the like including the receipt screen URL. Next, the reception unit 32 accepts the purchaser's operation to display the bill receipt screen. The purchaser is, for example, a person in charge of business of service user company B. The display operation of the bill receipt screen is, for example, an operation of opening the receipt screen URL included in the e-mail (that is, an operation of clicking the link of the receipt screen URL in the e-mail).

In step S32, the transmitting/receiving unit 31 included in the purchaser terminal 30 transmits a bill receipt screen acquisition request to the transaction management server 10. The acquisition request includes the receipt screen URL. In the transaction management server 10 , the transmitting/receiving unit 11 receives a request to obtain a bill receipt screen from the purchaser terminal 30 .

In step S33, the storage control unit 19 included in 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 bill receipt screen acquisition request. . Next, the storage control unit 19 reads bill information from the issued bill information management DB using the issued bill information management table 1300 based on the common bill ID included in the read receipt information. Subsequently, the creation unit 16 creates screen data for a bill receipt screen based on the receipt information and bill information read out by the storage control unit 19.

In step S<b>34 , the transmission/reception unit 11 included in the transaction management server 10 transmits the screen data of the bill receipt screen created by the creation unit 16 to the purchaser terminal 30 . In the purchaser terminal 30, the transmitting/receiving unit 31 receives the screen data of the bill receipt screen from the transaction management server 10.

In step S35, the display control unit 34 included in the purchaser terminal 30 displays the bill receipt screen on the display 506 based on the screen data of the bill receipt screen.

(Bill receipt screen)
Here, the bill receipt screen in this embodiment will be explained with reference to FIG. 15. FIG. 15 is a conceptual diagram showing an example of the bill receipt screen in this embodiment.

As shown in FIG. 15, the bill receipt screen 2200 in this embodiment includes a bill image display field 2201, a download button 2202, and a receipt button 2203.

Among these, the bill image display column 2201 displays the bill image indicated by the bill image storage location in the issued bill information management table.

When the purchaser presses the download button 2202, the transmitting/receiving 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 reception operation.

The explanation will be returned to FIG. 14. In step S36, the receiving unit 32 included in the purchaser terminal 30 receives an invoice receiving operation from the purchaser. Specifically, the purchaser presses the receive button 2203 on the bill receipt screen 2200.

In step S37, the transmitting/receiving unit 31 included in the purchaser terminal 30 transmits a bill receipt request to the transaction management server 10. The receipt request includes the common bill ID. In the transaction management server 10 , the transmitting/receiving unit 11 receives a bill receipt request from the purchaser terminal 30 .

In step S38, the storage control unit 19 included in the transaction management server 10 specifies the bill information in the issued bill information management table based on the common bill ID included in the bill receipt request. Next, the storage control unit 19 updates the bill status of the specified bill information to "received".

In step S39, the storage control unit 19 included in the transaction management server 10 registers the bill information specified in the issued bill information management table in the received bill information management DB.

(Received invoice information management table)
Here, details of the received invoice information management table will be explained with reference to FIG. 16. FIG. 16 is a conceptual diagram showing an example of the received bill information management table in this embodiment.

As shown in FIG. 16, the received bill information management table 1500 in this embodiment includes identification information for identifying a bill (common bill ID, bill ID, etc.), information representing the billing party of the bill, etc. (billing company name, etc.), billing amount, billing date, payment due date, invoice image storage location, details information (detail ID, product code, product name, unit price, quantity, amount, etc.), transfer destination information, etc. are managed in association with each other. That is, the received bill information management table differs from the issued bill information management table in that it does not have a bill status.

<Remittance data creation process>
Next, the remittance data creation process (step S3 in FIG. 1) in this embodiment will be described with reference to FIG. 17. FIG. 17 is a sequence diagram showing an example of remittance data creation processing in this embodiment.

In step S41, the reception unit 32 included in the purchaser terminal 30 accepts a purchaser's operation to display a payment processing screen. The display operation of the payment processing screen is performed on the received invoice list screen.

(Received invoice list screen)
Here, the received invoice list screen in this embodiment will be explained with reference to FIG. 18. FIG. 18 is a conceptual diagram showing an example of the received bill list screen in this embodiment.

As shown in FIG. 18, the received bill list screen 2300 in this embodiment includes a bill list display field 2301. The bill list display column 2301 displays a list of information regarding received bills (billing source, bill number, total amount, date of issue, etc.). For each bill displayed in the bill list display field 2301, a display button 2302, a download button 2303, and a payment processing button 2304 are displayed.

When the purchaser presses the display button 2302, a bill image corresponding to the bill is displayed on the display 506. When the purchaser presses the download button 2303, the transmitting/receiving 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 payment processing button 2304, the reception unit 32 accepts an operation to display a payment processing screen.

The explanation will be returned to FIG. 17. In step S42, the transmitting/receiving unit 31 included in the purchaser terminal 30 transmits a payment processing screen acquisition request to the transaction management server 10. The acquisition request includes the common bill ID. In the transaction management server 10 , the transmitting/receiving unit 11 receives a request to obtain a payment processing screen from the purchaser terminal 30 .

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

(Accounts payable information management table)
Here, details of the accounts payable information management table will be explained with reference to FIG. 19. FIG. 19 is a conceptual diagram showing an example of the accounts payable information management table in this embodiment.

As shown in FIG. 19, in the accounts payable information management table in this embodiment, the date on which accounts payable occurred (hereinafter also referred to as "accounts payable date"), identification information for identifying invoices (common invoice ID and Invoice ID, etc.), information on details in the invoice (detail ID, product code, unit price, quantity, amount, etc.), information on payment (payment quantity and payment amount), etc. are managed in association with each other.

The example of accounts payable information shown in FIG. 19 is in an initial state imported from the accounts payable account. In the initial state, each piece of identification information (common bill ID, bill ID, and detail ID) and payment information (payment quantity and payment amount) are blank.

The explanation will be returned to FIG. 17. In step S<b>44 , the transmission/reception unit 11 included in the transaction management server 10 transmits the screen data of the payment processing screen created by the creation unit 16 to the purchaser terminal 30 . In the purchaser terminal 30, the transmitting/receiving section 31 receives the screen data of the payment processing screen from the transaction management server 10.

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

(Payment processing screen)
Here, the payment processing screen in this embodiment will be explained with reference to FIG. 20. FIG. 20 is a conceptual diagram showing an example of a payment processing screen in this embodiment.

As shown in FIG. 20, the payment processing screen 2400 in this embodiment includes a condition setting area 2410, an accounts payable information display field 2420, an invoice information display field 2430, a detailed information display field 2440, a quantity input button 2441, It has a payment information display field 2450, a create button 2408, and a cancel button 2409.

When conditions such as payment deadline and payment period are entered in the condition setting area 2410, accounts payable information that matches the conditions is displayed in the accounts payable information display field 2420. Each condition value displayed in the condition setting area 2410 may be set in advance. For example, the payment period may be set from the day after the previous month's payment deadline to the current month's payment deadline.

The bill information display field 2430 displays the contents of bill information (bill ID, billed amount, billing date, payment deadline, etc.). In the detailed information display field 2440, information regarding the detailed items included in the bill information (product name, quantity, unit price, amount, etc.) is displayed in a form in which each detailed item can be selected.

In the detail information display column 2440, each detail included in the accounts payable information and the invoice information is checked. Details included in both accounts payable information and invoice information are automatically selected. At this time, if the quantity in the accounts payable information and the quantity in the invoice information do not match, both quantities are displayed so that they can be grasped. For example, it may be displayed in a format such as "quantity of accounts payable information/quantity of invoice information".

One quantity input button 2441 is displayed for each detail displayed in the detail information display field 2440. When the quantity input button 2441 is pressed, a dialog screen for inputting the quantity is displayed, and the quantity to be paid for the details can be input.

Note that the quantity input button 2441 corresponding to a detail that is not selected in the detail information display field 2440 may be controlled so that it cannot be pressed.

Payment information display field 2450 displays payee information included in the bill information. The payment date in the payment information display field 2450 is automatically entered based on a preset rule (for example, the 25th of the next month, etc.). However, it is also possible for the purchaser to manually modify it.

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

[Modification 1: Payment processing screen that reflects returned goods information]
The payment processing screen 2400 may further display return information when a return is made from the purchaser to the seller.

FIG. 21 is a conceptual diagram showing an example of a payment processing screen 2400 that displays return information. The payment processing screen 2400 shown in FIG. 21 further includes a return information display field 2460. The returned goods information displayed in the returned goods information display field 2460 is stored in the accounts payable information management table.

FIG. 22 is a conceptual diagram showing an example of an accounts payable information management table in which return information is stored. The accounts payable information management table shown in FIG. 22 includes accounts payable information representing returns. In the accounts payable information representing returned goods, the quantity and amount are set to minus (△), and the notes are set to "returned goods."

Here, an example in which returned goods information is displayed on the payment processing screen has been described, but other information may be displayed as long as the details result in a negative billed amount. For example, accounts payable information may be displayed with the quantity and amount set to negative values due to discounts or defective products.

[Modification 2: Payment processing screen with chat function]
On the payment processing screen 2400, the purchaser may wish to make an inquiry to the seller regarding the details of the payment. Specifically, this may be the case, for example, when it is discovered that there are products or quantities that have not been delivered among the details listed on the invoice, or when it is desired to confirm who will bear the transfer fee.

For the above case, the payment processing screen 2400 may include a chat function for the purchaser to inquire about billing details from the seller. FIG. 23 is a conceptual diagram showing an example of a payment processing screen 2400 with a chat function.

As shown in FIG. 23, the payment processing screen 2400 with chat function further includes an inquiry button 2442 and a chat area 2470.

One inquiry button 2442 is displayed for each statement displayed in the statement information display field 2440. When the inquiry button 2442 is pressed, words for making an inquiry regarding the details are input into the chat area 2470. Information shared between the seller and the purchaser, such as the bill ID, is automatically embedded in the wording.

(Chat history management table)
When the payment processing screen 2400 includes a chat function, a chat history management DB is constructed in the storage unit 100 included in the transaction management server 10.

The chat history management DB is composed of a chat history management table. The chat history management table stores history information of inquiries made between a seller (service user company A) and a purchaser (service user company B).

FIG. 24 is a conceptual diagram showing an example of a chat history management table in this embodiment. As shown in FIG. 24, the chat history management table 1800 in this embodiment includes chat date and time, identification information for identifying the subject of inquiry (payment ID, common bill ID, bill ID, and statement ID), sender The information representing the billing party (billing source or billing destination), the content of the transmission, etc. are managed in association with each other.

Although an example in which inquiries are made between a seller and a purchaser via chat has been described here, the means for making inquiries between the seller and the purchaser is not limited to chat. Any means may be used as long as it allows a conversation between the seller and the purchaser, and for example, it may be a function that can initiate a voice call or a video call over the Internet.

The explanation will be returned to FIG. 17. In step S46, the reception unit 32 included in the purchaser terminal 30 receives an operation by the purchaser 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.

In step S47, the transmitting/receiving unit 31 included in the purchaser terminal 30 transmits a remittance data creation request (hereinafter also referred to as a "payment request") to the transaction management server 10. The creation request includes an invoice ID, a detail ID, and a quantity input for each detail. The detail ID included in the creation request is the detail ID of the detail selected in the detail information display column 2440. In the transaction management server 10, the transmitting/receiving unit 11 receives a remittance data creation request from the purchaser terminal 30.

In step S48, the creation unit 16 issues a payment ID that identifies the payment based on the remittance data creation request. Next, the creation unit 16 creates remittance data in which the payment ID is embedded. The payment ID can be embedded in the remittance data as EDI (Electronic Data Interchange) information. Further, it may be embedded in a specific item (for example, notes, etc.) of the transaction details in the Zengin EDI system.

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

In step S49, the storage control unit 19 included in the transaction management server 10 generates payment information representing the content of the remittance data and registers it in the payment information management DB. Furthermore, the storage control unit 19 updates the accounts payable information management DB based on the remittance data creation request.

(Payment information management table)
Here, details of the payment information management table will be explained with reference to FIG. 25. FIG. 25 is a conceptual diagram showing an example of the payment information management table in this embodiment.

As shown in FIG. 25, the payment information management table 1600 in this embodiment includes information representing the contents of remittance data (payment ID, payment amount, scheduled payment date, etc.), identification information for identifying the bill (common Invoice ID, invoice ID, etc.) and information regarding details (detail ID, quantity, amount, etc.) are managed in association with each other.

FIG. 26 shows an example of the accounts payable information management table after remittance data is created. As shown in FIG. 26, in the accounts payable information management table after the remittance data is created, the common invoice ID, invoice ID, and detail ID are registered in the account payable information for which the remittance data was created.

The explanation will be returned to FIG. 17. In step S50, the transmitting/receiving unit 11 included in the transaction management server 10 transmits remittance data in which the payment ID is embedded to the purchaser terminal 30.

Thereafter, the purchaser instructs execution of remittance using the downloaded remittance data according to a predetermined procedure. For example, the purchaser instructs execution of remittance by uploading remittance data via a predetermined screen provided by financial institution D1 such as firm banking or internet banking that manages the account of service user company B. Then, the financial institution D1 that manages the account of service user company B remits the amount according to the remittance data to the financial institution D2 that manages the account of service user A, and also uses the payment ID included in the remittance data. The information is also transmitted to the financial institution D2. Thereby, the seller can obtain payment information including information such as payment ID from the financial institution D2.

Note that remittance based on remittance data is not limited to being performed via a financial institution. For example, remittances may be made via a service such as an online payment service. In this case, for example, service providing company C sends a two-dimensional code indicating the remittance data to the purchaser, and the purchaser uses the application of the service such as the online payment service installed on the purchaser terminal 30 to send the remittance data. Remittances can be made by scanning the two-dimensional code.

<Acquisition of payment information and automatic payment processing>
Next, the deposit information acquisition process (step S5 in FIG. 1) and the automatic payment process (step S6 in FIG. 1) in this embodiment will be described with reference to FIG. FIG. 27 is a sequence diagram illustrating an example of the deposit information acquisition process and the automatic payment process in this embodiment.

In step S61, the transmitting/receiving unit 11 included in the transaction management server 10 transmits a deposit information acquisition request to the account management server 40-2. The account management server 40-2 is an account management server 40 that manages the account of service user company A.

The transaction management server 10 may transmit a request to obtain deposit information by a request from the seller terminal 20 in response to an operation by the seller, or every predetermined time interval (for example, 30 minutes). It may be.

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

The account management server 40-2 performs a predetermined authentication process when transmitting deposit information regarding the account of the service using company A to the transaction management server 10. For example, the authentication information for the account of the service user company A is registered in the tenant information management DB, and the transmission/reception unit 11 of the transaction management server 10 sends the authentication information specified based on the tenant ID along with a request to obtain deposit information. It is sent to the account management server 40-2.

In the account management server 40-2, the storage control unit 49 executes authentication processing based on the transmitted authentication information. If the authentication is successful, the storage control unit 49 reads out the deposit information corresponding to the authentication information from among the deposit information stored in the storage unit 400 . Finally, the transmitting/receiving unit 41 transmits the read deposit information to the transaction management server 10.

In step S62, the storage control unit 19 included in the transaction management server 10 registers the deposit information received from the account management server 40-2 in the deposit information management DB.

(Deposit information management table)
Here, details of the deposit information management table will be explained with reference to FIG. 28. FIG. 28 is a conceptual diagram showing an example of the deposit information management table in this embodiment.

As shown in FIG. 28, the deposit information management table 1700 in this embodiment includes information representing the transaction date, withdrawal amount (payment amount), payment destination, deposit amount (deposit amount), and remittance source. Information, balance, payment ID, payment status, etc. are managed in association with each other. In the initial state, the clearing status is blank.

The explanation will be returned to FIG. 27. In step S64, the transaction management server 10 executes automatic clearing processing based on the deposit information and payment information.

≪Automatic clearing process≫
Here, details of the automatic redemption process (step S64 in FIG. 27) in this embodiment will be explained with reference to FIG. 29. FIG. 29 is a flowchart illustrating an example of automatic redemption processing in this embodiment.

In step S64-1, the storage control unit 19 acquires unprocessed deposit information from the deposit information management DB. Unprocessed deposit information is deposit information whose payment status in the deposit information management table is blank.

Steps S64-2 to S64-8 are executed for each piece of unprocessed deposit information acquired in step S64-1.

In step S64-2, the determining unit 15 determines whether a payment ID is set in the acquired payment information. If the payment ID has been set (YES), the determination unit 15 acquires the payment ID and advances the process to step S64-3. If the payment ID has not been set (NO), the determination unit 15 advances the process to step S64-8.

In step S64-3, the storage control unit 19 obtains payment information from the payment information management DB based on the payment ID obtained in step S64-2.

In step S64-4, the determining unit 15 determines whether the payment amount in the payment information and the deposit amount in the deposit information match. If the payment amount and deposit amount match (YES), the determination unit 15 advances the process to step S64-5. If the payment amount and deposit amount do not match (NO), the determination unit 15 advances the process to step S64-7.

In step S64-5, the storage control unit 19 generates accounts receivable information based on the deposit information and payment information, and registers it in the accounts receivable information management table. In the accounts receivable information to be generated, the accounts receivable date is set to the transaction date of the payment information, and the common invoice ID, invoice ID, detail ID, payment quantity, and payment amount are set to the common invoice ID and invoice ID of the payment information. , item ID, quantity, and amount.

In step S64-6, the storage control unit 19 updates the payment status in the deposit information management table to cleared. Thereafter, the storage control unit 19 ends the processing for the deposit information and returns the processing to step S64-2.

In step S64-7, the storage control unit 19 updates the payment status in the deposit information management table to amount mismatch. Thereafter, the storage control unit 19 ends the processing for the deposit information and returns the processing to step S64-2.

In step S64-8, the storage control unit 19 updates the application status of the deposit information management table to manual application. Thereafter, the storage control unit 19 ends the processing for the deposit information and returns the processing to step S64-2.

FIG. 30 shows an example of the accounts receivable information management table after automatic clearing. As shown in Figure 30, in the accounts receivable information management table after automatic clearing, a record is added in which the common invoice ID, invoice ID, and item ID match, and the deposit quantity and deposit amount are set. has been done.

FIG. 31 shows an example of the accounts payable information management table after automatic clearing. As shown in Figure 31, in the accounts payable information management table after automatic clearing, a record is added in which the common invoice ID, invoice ID, and item ID match, and the payment quantity and payment amount are set. ing.

Note that the registration of the deposit quantity and deposit amount in the accounts payable information management table is not performed in the automatic clearing process. The purchaser manually registers account payable information in which the deposit quantity and deposit amount are set by operating the purchaser terminal 30 or the like.

However, the transaction management server 10 may be configured to refer to the payment information management table on the scheduled payment date and automatically register it in the accounts payable information management table when payment is confirmed. Specifically, in the payment information management table, obtain the payment information with the scheduled payment date of the current day, and register the accounts payable information with the common invoice ID, item ID, quantity, and amount set in the accounts payable information management table. good.

The explanation will be returned to FIG. 27. In step S65, the reception unit 22 included in the seller terminal 20 accepts the seller's operation to display the deposit management screen. The display operation of the deposit management screen is performed, for example, on the main menu screen provided by the transaction management server 10.

In step S66, the transmitting/receiving unit 21 included in the seller terminal 20 transmits a deposit management screen acquisition request to the transaction management server 10. The acquisition request includes a billing period. The billing period may be from the day after the previous month's billing deadline to the current month's billing deadline, or may be specified in the display operation of the deposit management screen. In the transaction management server 10, the transmitting/receiving unit 11 receives a request to obtain a deposit management screen from the seller terminal 20.

In step S67, the storage control unit 19 included in the transaction management server 10 reads the account receivable information from the account receivable information management DB based on the billing period included in the request to obtain the payment management screen. Next, the storage control unit 19 reads bill information from the issued bill information management DB based on the common bill ID included in the read accounts receivable information.

Subsequently, the storage control unit 19 reads payment information from the payment information management DB based on the common bill ID included in the read account receivable information. Next, the creation unit 16 creates screen data for the deposit management screen based on the account receivable information, bill information, and payment information read out by the storage control unit 19.

≪Deposit management screen creation process≫
Here, details of the deposit management screen creation process (step S67 in FIG. 27) in this embodiment will be described with reference to FIG. 32. FIG. 32 is a flowchart illustrating an example of the deposit management screen creation process in this embodiment.

In step S67-1, the storage control unit 19 obtains first account receivable information from the account receivable information management DB. The first account receivable book information is account receivable book information in which the account receivable date is within the billing period and the deposit quantity and deposit amount are blank.

Steps S67-2 to S67-15 are executed for each of the first accounts receivable information acquired in step S67-1.

In step S67-2, the determination unit 15 determines whether or not the common invoice ID and detail ID are set in the acquired first account receivable information. If the common bill ID and detail ID have been set (YES), the determination unit 15 acquires the common bill ID and detail ID, and advances the process to step S67-3. If the common bill ID and detailed ID are not set (NO), the determination unit 15 advances the process to step S67-8.

In step S67-3, the storage control unit 19 acquires second accounts receivable information from the accounts receivable information management DB based on the common invoice ID and detail ID acquired in step S67-2. The second account receivable information is account receivable information in which the common invoice ID and detail ID are the same as the first account receivable information, and the payment quantity and payment amount are set.

In step S67-4, the determining unit 15 determines whether or not the second accounts receivable information was acquired in step S67-3. If the second accounts receivable information can be acquired (YES), the determination unit 15 advances the process to step S67-5. If the second accounts receivable information cannot be obtained (NO), the determination unit 15 advances the process to step S67-10.

In step S67-5, the creation unit 16 acquires the receivable date, deposit quantity, and deposit amount from the second account receivable information acquired in step S67-3. Note that the acquired receivable date is displayed on the payment management screen as the payment date.

In step S67-6, the determining unit 15 determines whether the quantity and amount of money in the first account receivable book information match the amount and amount of money received in the second account receivable book information. If the quantity and amount match the deposited quantity and deposited amount (YES), the determination unit 15 ends the process for the first account receivable information and returns the process to step S67-2. If the quantity and amount do not match the deposited quantity and deposited amount (NO), the determination unit 15 advances the process to step S67-7.

In step S67-7, the creation unit 16 decides to cooperatively display the first account receivable information as requiring attention. Any method may be used for highlighting, for example, changing the background color, changing the font color, displaying in bold, etc. Thereafter, the creation unit 16 ends the process for the first account receivable information and returns the process to step S67-2.

In step S67-8, the creation unit 16 sets the invoice status displayed on the deposit management screen to unissued.

In step S67-9, the creation unit 16 sets the scheduled deposit quantity and scheduled deposit amount to be displayed on the deposit management screen to blank fields. Thereafter, the creation unit 16 ends the process for the first account receivable information and returns the process to step S67-2.

In step S67-10, the storage control unit 19 obtains bill information from the issued bill information management DB based on the common bill ID obtained in step S67-2. Next, the storage control unit 19 acquires payment information from the payment information management DB based on the common bill ID.

In step S67-11, the creation unit 16 obtains the bill status of the bill information obtained in step S67-10. Note that the acquired bill status is used as the bill status displayed on the deposit management screen.

In step S67-12, the determining unit 15 determines whether the payment information was successfully acquired in step S67-10. If the payment information can be obtained (YES), the determination unit 15 advances the process to step S67-13. If the payment information cannot be acquired (NO), the determination unit 15 advances the process to step S67-9.

In step S67-13, the creation unit 16 obtains the scheduled payment date of the payment information obtained in step S67-10. The acquired scheduled payment date is displayed on the deposit management screen as the scheduled deposit date.

In step S67-14, the creation unit 16 obtains the quantity and amount of payment information obtained in step S67-10 based on the detail ID of the first account receivable information obtained in step S67-1. Note that the acquired quantity and amount are used as the scheduled deposit quantity and scheduled deposit amount displayed on the deposit management screen.

In step S67-15, the determining unit 15 determines whether the quantity and amount of the first account receivable information match the quantity and amount of the payment information. If the quantity and the amount match (YES), the determining unit 15 ends the process for the first account receivable information and returns the process to step S67-2. If the quantity and the amount do not match (NO), the determining unit 15 advances the process to step S67-7.

In step S67-16, the creation unit 16 creates screen data for the deposit management screen based on the information acquired in steps S67-1 to S67-15.

The explanation will be returned to FIG. 27. In step S68, the transmission/reception unit 11 included in the transaction management server 10 transmits the screen data of the deposit management screen created by the creation unit 16 to the seller terminal 20. In the seller terminal 20, the transmitting/receiving unit 21 receives the screen data of the deposit management screen from the transaction management server 10.

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

(Deposit management screen)
Here, the deposit management screen in this embodiment will be explained with reference to FIG. 33. FIG. 33 is a conceptual diagram showing an example of the deposit management screen in this embodiment.

As shown in FIG. 33, the deposit management screen 2500 in this embodiment includes a condition setting area 2510, a deposit information display field 2520, and a details confirmation button 2521.

When a condition such as a billing period is entered in the condition setting area 2510, deposit information that matches the condition is displayed in the deposit information display field 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 previous month's billing deadline to the current month's billing deadline.

One detailed confirmation button 2521 is displayed for each deposit information displayed in the deposit information display field 2520. When the details confirmation button 2521 is pressed, a screen displaying details of deposit information is displayed. The details confirmation button 2521 can be used to confirm details when the amount in the statement does not match the scheduled deposit amount or the deposited amount.

Note that the details confirmation button 2521 corresponding to the deposit information for which information regarding the deposit schedule (scheduled deposit date, scheduled deposit quantity, and scheduled deposit amount) or information regarding the deposit (deposit date and deposit amount) is not displayed is controlled to be hidden. You may.

FIG. 34 shows an example of the deposit management screen 2500 when the deposit has already been made. As shown in FIG. 34, on the deposit management screen 2500 when the deposit has already been made, the deposit date and deposit amount are displayed in the deposit information display field 2520.

[Modification 3: Deposit management screen with chat function]
On the deposit management screen 2500, the seller may wish to make an inquiry to the purchaser regarding the details of the deposit. Specifically, for example, if the invoiced amount stated on the invoice differs from the scheduled or deposited amount, or if the transfer fee was supposed to be borne by the buyer, the amount minus the transfer fee is paid as borne by the seller. For example, if the

For the above-mentioned case, the deposit management screen 2500 may include a chat function, similar to the payment processing screen 2400, for the seller to inquire about the details of the deposit from the purchaser. FIG. 35 is a conceptual diagram showing an example of a deposit management screen 2500 with a chat function.

As shown in FIG. 35, the deposit management screen 2500 with a chat function further includes an inquiry button 2522 and a chat area 2530.

One inquiry button 2522 is displayed for each deposit information displayed in the deposit information display field 2520. When the inquiry button 2522 is pressed, words for inquiring about the deposit are input into the chat area 2530. Information shared between the seller and the purchaser, such as the payment ID, is automatically embedded in the wording.

[Main effects of the first embodiment]
When the transaction management server 10 in this embodiment receives a payment request with specified details from the purchaser terminal 30, it stores payment information that associates the payment ID that identifies the payment request with the details targeted for payment. Therefore, according to the transaction management server 10 in this embodiment, it is possible to specify the details to be paid.

In particular, the transaction management server 10 in this embodiment transmits remittance data in which the payment ID is embedded to the purchaser terminal 30. When the purchaser makes a remittance using the remittance data, the transaction management server 10 can acquire deposit information in which the payment ID is embedded from the account management server 40. Therefore, the transaction management server 10 in this embodiment can specify the details to be paid based on the deposit information. As a result, according to the transaction management server 10 in this embodiment, by comparing the deposit information and the payment information, it is possible to realize automatic clearing on a detailed basis.

Furthermore, the transaction management server 10 in this embodiment can make inquiries between the seller and the purchaser on the payment processing screen for creating remittance data and the deposit management screen for checking the payment status. Provide chat functionality. The chat function allows you to embed information necessary for inquiries into messages. Therefore, according to the transaction management server 10 of the present embodiment, when a seller or a purchaser has any questions about the details of a request or payment, etc., it is possible to efficiently make an inquiry to the other party.

[Second embodiment]
In the first embodiment, an example has been described in which the current month's invoice is automatically cleared in units of details. In the second embodiment, an example will be described in which unbilled details remain in the previous month's invoice, and automatic clearing is performed in units of details for the invoice including the carried over amount from the previous month.

The information processing system in the second embodiment will be described below with reference to FIGS. 36 to 44, focusing on the differences from the first embodiment.

(Accounts receivable information management table)
FIG. 36 is a conceptual diagram showing an example of the accounts receivable information management table in this embodiment. As shown in FIG. 36, the accounts receivable information management table in this embodiment stores accounts receivable information carried forward from the previous month and accounts receivable information for the current month. In the accounts receivable information for the previous month carryover, the accounts receivable date is the previous month (in this case, September 1 to September 30, 2020), and there is no account receivable information in which the deposit quantity and deposit amount are set. It is something.

For example, the account receivable information for which the common invoice ID for September 29, 2020 is abcd1235 is carried over from the previous month because there is no account receivable information in which the deposit quantity and payment amount are set. On the other hand, the account receivable information with the common invoice ID abcd1235 on September 10, 2020 is carried forward from the previous month because there is account receivable information on October 25, 2020, in which the payment quantity and amount were set. It's not a minute.

Additionally, the accounts receivable information for October 15, 2020 and October 30, 2020 whose common invoice ID is abcd1321 is for the current month. Therefore, the billed amount for the current month is 1,210,000 yen, which is the sum of the previous month's carryover amount of 880,000 yen and the current month's total amount of 330,000 yen.

(Bill creation screen)
FIG. 37 is a conceptual diagram showing an example of the bill creation screen in this embodiment. As shown in FIG. 37, the invoice creation screen 2000 in this embodiment has a previous month carryover display area 2021 and a current month display area 2022 instead of the accounts receivable display area 2020.

The previous month carryover display area 2021 is similar to the accounts receivable display area 2020 in the first embodiment, except that the displayed account receivable information is limited to the previous month carryover information. Further, the current month display area 2022 is similar to the accounts receivable display area 2020 in the first embodiment, except that the displayed account receivable information is limited to the current month.

(Bill image)
FIG. 38 is a conceptual diagram showing an example of a bill image in this embodiment. As shown in FIG. 38, in the bill image according to this embodiment, the amount carried over from the previous month, the amount for the current month, and the amount billed this time are written respectively. Note that the details listed in the bill image are only for the current month.

(Issued invoice information management table)
FIG. 39 is a conceptual diagram showing an example of the issued bill information management table in this embodiment. As shown in FIG. 39, the carryover common bill ID is added to the issued bill information management table in this embodiment.

The carryover common bill ID is a common bill ID for identifying the bill issued in the previous month for the details of the carryover of the previous month. In the issued invoice information management table, it can be seen that the details for which the carryover common invoice ID is set are those carried over from the previous month.

(Received invoice information management table)
FIG. 40 is a conceptual diagram showing an example of the received bill information management table in this embodiment. As shown in FIG. 40, a carryover common bill ID is added to the received bill information management table in this embodiment.

Similar to the issued bill information management table, it can be seen that in the received bill information management table, the details for which the carryover common bill ID is set are those carried over from the previous month.

(Accounts payable information management table)
FIG. 41 is a conceptual diagram showing an example of the accounts payable information management table in this embodiment. As shown in FIG. 41, the accounts payable information management table with the previous month's carryover information stores the accounts payable account information for the previous month's carryover and the current month's account payable account information. The contents set in the accounts payable information for the previous month carried forward and the accounts payable information for the current month are the same as in the accounts receivable information management table.

(Payment processing screen)
FIG. 42 is a conceptual diagram showing an example of the bill creation screen in this embodiment. As shown in FIG. 42, in the payment processing screen 2400 in this embodiment, the detailed information display field 2440 is displayed divided into the previous month's carryover amount and the current month's amount.

(Payment information management table)
FIG. 43 is a conceptual diagram showing an example of the payment information management table in this embodiment. As shown in FIG. 43, the payment information management table in this embodiment includes payment information carried forward from the previous month.

In the payment information carried over from the previous month, detail IDs related to a plurality of common bill IDs are associated with one payment ID. For example, payment information whose payment ID is ADB852841F8B32772 includes detail IDs "0001" and "0003" whose common bill ID is abcd1235, and detail ID "0001" whose common bill ID is abcd1321.

(Deposit management screen)
FIG. 44 is a conceptual diagram showing an example of the deposit management screen in this embodiment. As shown in FIG. 44, it can be seen that the deposit management screen 2500 in this embodiment displays the current month's scheduled payment date, deposit quantity, and scheduled deposit amount for the details of the previous month carryover.

For example, accounts receivable information (carryover from the previous month) with an accounts receivable date of September 29, 2020 is displayed as November 25, 2020 as the expected payment date. Further, for example, in the accounts receivable information (for the current month) whose accounts receivable date is October 15, 2020, the scheduled payment date is displayed as November 25, 2020. In other words, it can be seen that payment schedules for the same day are registered for the details of the carryover from the previous month and the details of the current month.

[Main effects of the second embodiment]
The transaction management server 10 in this embodiment stores payment information that associates a payment ID that identifies a payment request with a detailed item to be paid. At this time, details included in different bills can be associated with one payment ID. Therefore, according to the transaction management server 10 of this embodiment, even if a particular item to be paid is selected from a plurality of bills, the particular item to be paid can be specified.

As a result, according to the transaction management server 10 of this embodiment, even if a detail to be paid is selected from a plurality of invoices, automatic clearing can be achieved on a detail-by-detail basis.

[supplement]
In the above embodiment, the bill information on the seller side is stored in the issued bill information management table, and the bill information on the purchaser side is stored in the received bill information management table. Here, the transaction management server 10 may be configured to include a bill information management table common to each tenant and share bill information. With this configuration, the bill information can be referenced without the purchaser performing operations such as receiving the bill.

In the embodiment described above, the transaction management server 10 is an example of an information processing device. The account management server 40-2 is an example of a second information processing device. Purchaser terminal 30 is an example of an information processing terminal. The seller terminal 20 is an example of a second information processing terminal. The transmitter/receiver 11 is an example of a transmitter or a receiver. Chat area 2470 and chat area 2530 are examples of interaction areas.

Each function of the embodiments described above can be realized by one or more processing circuits. Here, the term "processing circuit" as used herein refers to a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, or a processor designed to execute each function explained above. This includes devices such as ASICs (Application Specific Integrated Circuits), DSPs (digital signal processors), FPGAs (field programmable gate arrays), and conventional circuit modules.

The devices described in the examples are merely indicative of one of several computing environments for implementing the embodiments disclosed herein. In some embodiments, transaction management server 10 and account management server 40 include multiple computing devices, such as a server cluster. The plurality of computing devices are configured to communicate with each other via any type of communication link, including a network, shared memory, etc., to perform the processes disclosed herein.

Although the embodiments of the present invention have been described in detail above, the present invention is not limited to these embodiments, and various modifications or variations can be made within the scope of the gist of the present invention as described in the claims. Changes are possible.

1 Information processing system 10 Transaction management server 20 Seller terminal 30 Purchaser terminal 40 Account management server 11, 21, 31, 41 Transmission/reception section 22, 32 Reception section 24, 34 Display control section 15, 25, 35, 45 Judgment section 16 , 46 Creation unit 19, 29, 39, 49 Storage control unit 100, 200, 300, 400 Storage unit

Japanese Patent Application Publication No. 2008-9873

Claims (14)

An information processing device that can communicate with an information processing terminal used by a user via a network,
a receiving unit that receives from the information processing terminal a payment request specifying details to be paid from bill information issued to the user;
a storage control unit that stores payment information that associates identification information that identifies the payment request with the details in a storage unit;
An information processing device comprising: The information processing device according to claim 1,
further comprising a transmitting unit that transmits remittance data including the identification information and for remitting an amount based on the details included in the payment information to a business partner's account, to the information processing terminal;
Information processing device. The information processing device according to claim 2,
The receiving unit receives deposit information including the identification information from a second information processing device that manages an account of the business partner.
Information processing device. The information processing device according to claim 3,
erasing the deposit information by comparing the deposit information and the payment information using the identification information;
Information processing device. The information processing device according to claim 4,
The transmitting unit transmits screen data for comparing account payable information based on the invoice information and the invoice information to the information processing terminal.
Information processing device. The information processing device according to claim 4,
The transmitting unit transmits screen data for comparing the bill information and the payment status of the statement to a second information processing terminal used by the business partner.
Information processing device. The information processing device according to claim 5 or 6,
The screen data includes an interaction area for dialogue between the user and the business partner,
Information processing device. An information processing terminal capable of communicating with an information processing device via a network,
a display control unit that displays a screen for generating remittance data based on bill information issued to the user;
a transmitting unit that transmits a payment request specifying details to be paid from the bill information to the information processing device;
An information processing terminal equipped with. An information processing terminal capable of communicating with an information processing device via a network,
a transmitting unit that transmits bill information issued by a user to the information processing device;
a display control unit that displays a screen for displaying the payment status of the statement based on identification information that identifies a payment request that specifies the statement to be paid from the bill information;
An information processing terminal equipped with. An information processing system in which an information processing terminal and an information processing device used by a user can communicate via a network,
The information processing terminal is
comprising a transmitting unit that transmits a payment request specifying details to be paid from bill information issued to the user to the information processing device;
The information processing device includes:
a receiving unit that receives the payment request from the information processing terminal;
a storage control unit that stores payment information that associates identification information that identifies the payment request with the details in a storage unit;
An information processing system equipped with. A computer that can communicate with the information processing terminal used by the user via the network,
a receiving procedure for receiving a payment request specifying details to be paid from bill information issued to the user from the information processing terminal;
a storage control procedure for storing payment information that associates identification information for identifying the payment request with the details in a storage unit;
An information processing method that performs. A computer that can communicate with the information processing terminal used by the user via the network,
a receiving procedure for receiving a payment request specifying details to be paid from bill information issued to the user from the information processing terminal;
a storage control procedure for storing payment information that associates identification information for identifying the payment request with the details in a storage unit;
A program to run. A computer that can communicate with an information processing device via a network,
a display control procedure for displaying a screen for generating remittance data based on invoice information issued to the user;
a sending procedure for sending a payment request specifying details to be paid from the bill information to the information processing device;
A program to run. A computer that can communicate with an information processing device via a network,
a transmission procedure for transmitting bill information issued by a user to the information processing device;
a display control procedure for displaying a screen for displaying the payment status of the statement based on identification information that identifies a payment request that specifies the statement to be paid from the bill information;
A program to run.

Images