JP7764438B2 - Debt processing device, debt processing method, and debt processing program - Google Patents

Description

The present invention relates to a debt processing device, a debt processing method, and a debt processing program.

For example, in the logistics industry, there are cases where each business office records payables for each order received, and then determines the payables based on the consolidated invoices sent to the central business office. For example, Patent Document 1 discloses a conventional payables processing system.

Japanese Patent Application Laid-Open No. 2021-46887

However, Patent Document 1 does not state anything about achieving both a speedy understanding of income and expenditures for each order by recording liabilities for each business location, and consolidated payments (debt determination) for each invoiced item.

The present invention was made in consideration of the above, and aims to provide a debt processing device, debt processing method, and debt processing program that can simultaneously quickly grasp income and expenditures for each order by recording debts for each business location, and aggregate payments for each invoiced item.

To solve the above-mentioned problems and achieve the objectives, the present invention provides a debtor processing device equipped with a control unit, configured to be able to access a memory area that stores cost information including the invoice number of the payee, which is the invoice number of the payee, voucher number, accounting date, payee, cost item, and amount; and includes an order recording means that, for each business location, registers the cost information's voucher number, accounting date, payee, cost item, and amount in the memory area when recording an order; and a debtor determination means that, on the debtor determination screen, extracts cost information from the memory area using the specified payee as a key, inputs the invoice number of the extracted cost information to update the cost information, and creates payment schedule data that aggregates amounts for each invoice number and registers it in the memory area.

Furthermore, according to one aspect of the present invention, the debt determination means may extract cost information from the storage area using the specified voucher number in addition to the payee as a key.

Furthermore, according to one aspect of the present invention, the debt determination means may create a payment request form for each payee based on the payment schedule data registered in the storage area.

Furthermore, according to one aspect of the present invention, the debt determination means may create supporting document data compliant with the Electronic Bookkeeping Act for each invoiced number and register it in the storage area.

Furthermore, to solve the above-mentioned problems and achieve the objectives, the present invention provides a debt processing method executed by an information processing device equipped with a control unit, wherein the control unit is configured to be able to access a memory area that stores cost information including the invoice number of the payee, which is the invoice number of the payee, voucher number, accounting date, payee, cost item, and amount; and the method includes an order entry process executed by the control unit for each business location when entering an order, which registers the cost information's voucher number, accounting date, payee, cost item, and amount in the memory area; and a debt determination process that extracts cost information from the memory area using the specified payee as a key on a debt determination screen, inputs the invoice number of the extracted cost information to update the cost information, and creates payment schedule data that aggregates amounts for each invoice number and registers this in the memory area.

Furthermore, to solve the above-mentioned problems and achieve the objectives, the present invention provides an account payable processing program to be executed by an information processing device equipped with a control unit, wherein the control unit is configured to be able to access a memory area that stores cost information including the invoice number of the payee, which is the invoice number of the payee, voucher number, accounting date, payee, cost item, and amount; and the control unit executes an order entry process in which, for each business location, when entering an order, the cost information's voucher number, accounting date, payee, cost item, and amount are registered in the memory area; and an account payable determination process in which, on an account payable determination screen, the specified payee is used as a key to extract cost information from the memory area, input the invoice number of the extracted cost information to update the cost information, and create payment schedule data that aggregates amounts for each invoice number and register the data in the memory area.

This invention has the advantage of enabling quick accounting of income and expenditures for each order by recording liabilities for each business location, while also enabling consolidated payments for each invoiced item.

FIG. 1 is a block diagram showing an example of the configuration of a debt processing device according to this embodiment. FIG. 2 is a diagram showing a processing flow for explaining the overall processing flow of the control unit of the debt processing device according to this embodiment. FIG. 3 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 4 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 5 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 6 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 7 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 8 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 9 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment. FIG. 10 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to this embodiment.

Embodiments of a debt processing device, debt processing method, and debt processing program according to the present invention are described in detail below with reference to the accompanying drawings. Note that the present invention is not limited to these embodiments.

[1. Overview]
For example, in the logistics industry, orders are generally accepted based on the contract at the time of transaction conclusion, and orders are recorded based on the receivables and payables information at the time of conclusion. Therefore, since it is possible to roughly estimate receivables and payables for each project at the time of order recording, receivables and payables are often recorded including plans when orders are recorded. In addition, in order to quickly grasp the income and expenditures for each project, it is necessary to record receivables and payables when orders are recorded.

On the other hand, invoices, which contain final information on recorded liabilities, are often sent in bulk to the main office at various times, such as at the end of the month or each time. Also, in order to reduce overseas remittance fees, invoices are generally sent in bulk for a certain period of time, rather than for each order. Additionally, in order to efficiently determine and pay liabilities, it is preferred to send invoices in bulk for each payee. Therefore, there are requirements for quickly understanding the income and expenditures of order orders and efficiently determining and paying liabilities using invoices in bulk.

However, in a workflow where each business office records payables for each order and then determines the payables based on the invoices sent in a consolidated form to the central business office, the granularity of the recorded payables and the invoiced amounts differs, making it difficult to correctly link each piece of data. One factor contributing to this is that the aggregation unit for the invoiced amounts sent differs depending on the payee.

This invention therefore aligns the granularity of information by aggregating the liabilities (multiple cost information) recorded for each order at each business location by invoice unit. This solves the above problem while also enabling quick understanding of income and expenditures for each order by recording liabilities for each business location, and making lump-sum payments for each invoice unit. Furthermore, by separating the details for payment processing from the details managed on an invoice basis, it is possible to make checking work easier for the person in charge.

In addition, with this invention, when attaching supporting documents in accordance with the Electronic Bookkeeping Act, the aggregation unit and the supporting document attachment unit match, making it easier to confirm and control when attaching documents.

The debt processing device of the present invention can be widely used in industries where cost accounting is performed on a task-by-task basis and the granularity does not match that of invoices, and can be suitably used in the logistics industry, for example.

2. Configuration
An example of the configuration of a debt processing device 100 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a block diagram showing an example of the configuration of the debt processing device 100.

The debt processing device 100 is a commercially available desktop personal computer, workstation, etc.

The debt processing device 100 comprises a control unit 102, a communication interface unit 104, a memory unit 106, and an input/output interface unit 108. Each unit of the debt processing device 100 is connected to each other so that they can communicate with each other via any communication path.

The communication interface unit 104 communicatively connects the debt processing device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has the function of exchanging data with other devices via a communication line. Here, the network 300 has the function of communicatively connecting the debt processing device 100 with the server 200 and terminals 400, etc., and is, for example, the Internet or a LAN (Local Area Network). Note that various master data, etc., described below, may be stored in the server 200, for example. The terminals 400, etc., are terminals of each business office (e.g., the Yokohama Branch Sales Department or the Osaka Branch Sales Department) or a main business office (e.g., the Tokyo Head Office Accounting Department), and are configured to be able to communicate data with the debt processing device 100 via the network 300.

An input device 112 and an output device 114 are connected to the input/output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that functions as a pointing device in conjunction with a mouse. Note that, below, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112.

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 stores computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes. The storage unit 106 can be, for example, a memory device such as RAM (Random Access Memory) or ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, or an optical disk.

The memory unit (memory area) 106 stores, for example, a cost information data table 106a, a payment schedule data table 106b, a voucher image data table 106c, and a voucher information data table 106d.

The cost information data table (debt accounting data table) 106a is a table for storing cost information (see Figure 3). Cost information may include the following items: voucher number (number), line number, accounting date, payee, cost item, amount, invoiced number (number), debt confirmation number (number), debt confirmation line number, and invoiced management number (number). Of the cost information, the voucher number, line number, accounting date, payee, cost item, and amount are registered during the order accounting process. Furthermore, of the cost information, the invoiced number, debt confirmation number, debt confirmation line number, and invoiced management number are registered during the debt confirmation process.

The payment schedule data table (debt confirmation data table) 106b is a table for storing payment schedule data (see Figure 7). Payment schedule data may include the debt confirmation number, line number, scheduled payment date, amount, and invoice number.

The evidence image data table 106c is a table for storing evidence image data of evidence data (attached files), and the evidence image data may include electronic evidence Guid data (see Figure 9 (A)).

The supporting document information data table 106d is a table for storing supporting document information for supporting document data (attached files). The supporting document information may include the electronic supporting document GUID, file name, document name, transaction date, amount, business partner, receipt date, size, invoiced number, and invoiced management number (see Figure 9 (B)).

The control unit 102 is a CPU or the like that provides overall control of the debt processing device 100. The control unit 102 has internal memory for storing control programs such as an OS, programs that define various processing procedures, and required data, and performs various information processing operations based on these stored programs.

The control unit 102 is configured to be able to access the cost information data table 106a, payment schedule data table 106b, voucher image data table 106c, voucher information data table 106d, etc., stored in the memory unit 106. Note that the cost information data table 106a, payment schedule data table 106b, voucher image data table 106c, voucher information data table 106d, etc. may also be provided in another location (e.g., server 200), as long as the control unit 102 is able to access them.

Functionally, the control unit 102 comprises an order entry unit 102a, a debt determination unit 102b, an inquiry unit 102c, and a screen display control unit 102d.

The order entry unit 102a, for example, provides an order entry screen (not shown) in response to access from each business location's terminal 400, and inputs the cost information voucher number, line number, entry date, payee, cost item, and amount in response to operations on the order entry screen by the operator of each business location's terminal 400, and registers the cost information in the cost information data table 106a in the memory unit 106.

The debt determination unit 102b, for example, provides a debt determination screen (see Figure 4) in response to access from the representative business establishment terminal 400, and extracts cost information from the cost information data table 106a using the specified payee as a key in response to operations performed by the operator of the representative business establishment terminal 400 on the debt determination screen, inputs the invoiced number of the extracted cost information to update the cost information, creates payment schedule data that aggregates the amount for each invoiced number, and registers this in the payment schedule data table 106b. In this case, the debt determination unit 102b may extract cost information from the cost information data table 106a using the specified voucher number as a key in addition to the payee.

The debt determination unit 102b may create and output (display and/or print) a payment request form for each payee based on the payment schedule data registered in the cost information data table 106a.

The debt determination unit 102b may create supporting document data (attached files) that comply with the Electronic Bookkeeping Act for each invoice number and store them in the supporting document image data table 106c and supporting document information data table 106d.

The query unit 102c provides a supporting document attachment query screen (see Figure 10) in response to access from, for example, the terminal 400 of the main business office or each business office, and, in response to operations performed by the operator of the terminal 400 of the main business office or each business office on the supporting document attachment query screen, references the payment schedule data table 106b, cost information data table 106a, supporting document image data table 106c, and supporting document information data table 106d based on the specified search criteria (e.g., invoiced number, etc.), and displays the search results (e.g., debt confirmation number, line number, invoiced management number, invoiced number, accounting date, payee, invoiced total amount, number of electronic transaction attachments, number of scanner-saved attachments, etc.).

The screen display control unit 102d controls the display and input reception of various screens (e.g., order entry screen, debt confirmation screen, attachment list screen, attachment details screen, voucher attachment inquiry screen, etc.) displayed on the monitor 114.

3. Specific Examples
A specific example of the processing by the control unit 102 of the debt processing device 100 in this embodiment will be described with reference to Figures 1 to 10. Figures 2 to 10 are diagrams for explaining a specific example of the processing by the control unit 102 of the debt processing device 100 in this embodiment.

[3-1. Processing flow (operation flow)]
2 is a diagram for explaining the overall processing flow (operation flow) of the control unit 102 of the debt processing device 100 in this embodiment. The overall processing flow (operation flow) of the control unit 102 of the debt processing device 100 in this embodiment will be described with reference to FIG.

Here, we will explain as an example a case where each business office (Yokohama Branch Sales Department, Osaka Branch Sales Department) receives and records orders from customers during the month (6/1, 6/10, 6/15, 6/20), and on the closing date (6/30), the main business office (Tokyo Head Office Accounting Department) consolidates invoices and consolidates payables.

The order entry unit 102a executes the order entry process (job) (step S1). Specifically, in the order entry process, the order entry unit 102a provides an order entry screen (not shown) in response to access from the terminal 400 of each business location, and enters the cost information (voucher number, line number, entry date, payee, cost item, and amount) in response to operations performed by the operator of the terminal 400 of each business location on the order entry screen, and registers the cost information data table 106a in the memory unit 106.

In this example, (1)-1: The Yokohama Branch Sales Department and the Osaka Branch Sales Department receive orders and register cost information.

(1)-2: The Yokohama Branch Sales Department and the Osaka Branch Sales Department send (email, fax, mail, etc.) the purchase order to the payee (A Shipping, B Warehouse). (1)-3: After the work is completed, the payee (A Shipping, B Warehouse) sends (email, fax, mail, etc.) a work report to the Yokohama Branch Sales Department and the Osaka Branch Sales Department (the order recipient), who then receive the work report. (2)-1: The payee (A Shipping, B Warehouse) sends (email, fax, mail, etc.) an invoice to the main business office (Tokyo Head Office Accounting Department).

An operational issue here is that the units used to consolidate invoices can vary by payee. For example, Shipping Company A consolidates all invoices for the current month onto a single invoice and sends them. Warehouse B also consolidates and sends separate invoices for the current month's invoices, including customs fees and other charges.

The debt determination unit 102b executes the debt determination process (job) (step S2). In the debt determination process, multiple cost information items are aggregated by invoice number to determine the debt. Specifically, the debt determination unit 102b provides a debt determination screen (see Figure 4) in response to access from the representative business establishment terminal 400, and extracts cost information from the cost information data table 106a using the specified payee as a key in response to operations performed by the operator of the representative business establishment terminal 400 on the debt determination screen. The cost information is updated by inputting the invoice number of the extracted cost information, and payment schedule data aggregating amounts for each invoice number is created and registered in the payment schedule data table 106b. In this case, the debt determination unit 102b may extract cost information from the cost information data table 106a using the specified voucher number in addition to the payee as a key. The debt determination unit 102b may create supporting document data (attached files) that comply with the Electronic Bookkeeping Act for each invoice number, and store them in the supporting document image data table 106c and supporting document information data table 106d. The debt determination unit 102b may also create and output a payment request form for each payee based on the payment schedule data registered in the cost information data table 106a. Payments to payees are made based on this payment requester.

The inquiry unit 102c executes inquiry processing, and provides a voucher attachment inquiry screen (see Figure 10) in response to access from the terminal 400 of the representative business office or each business office, and based on the search criteria (e.g., invoiced number, etc.) specified in response to operations by the operator of the terminal 400 of the representative business office or each business office on the voucher attachment inquiry screen, references the payment schedule data table 106b, cost information data table 106a, voucher image data table 106c, and voucher information data table 106d, and displays the search results (e.g., debt confirmation number, line number, invoiced management number, invoiced number, accounting date, payee, invoiced total amount, number of electronic transaction attachments, number of scanner-saved attachments, etc.).

[3-2. Sample data]
3 to 10 are diagrams showing sample data for explaining a specific example of the processing by the control unit 102 of the debt processing device 100 in this embodiment. A specific example of the processing by the control unit 102 of the debt processing device 100 in this embodiment will be described with reference to FIGS.

(S1: Order entry process)
A specific example of order entry processing will be described with reference to Figure 3. The order entry unit 102a provides an order entry screen (not shown) in response to access from the terminal 400 of each business location, and inputs the voucher number, line number, entry date, payee, cost item, and amount of cost information in response to operations on the order entry screen by the operator of the terminal 400 of each business location, and registers the input in the cost information data table 106a of the storage unit 106.

Figure 3 shows example data from the cost information data table (payables posting data table) 106a, which stores cost information. As shown in Figure 3, the cost information has the following fields: voucher number, line number, posting date, payee, cost item, amount, invoiced number, payables confirmation number, payables confirmation line number, and invoiced management number. The invoiced number, payables confirmation number, payables confirmation line number, and invoiced management number are "NULL" at the order posting processing stage, and the data is registered during the payables confirmation processing. In this example, the Yokohama Branch Sales Department registers voucher number: TYGN2306001 on 2023/06/01. The Osaka Branch Sales Department registers voucher number: TYGN2306002 on 2023/06/10. The Yokohama Branch Sales Department registers voucher number: TYGN2306003 on 2023/06/15. The Osaka Branch Sales Department will register slip number TYGN2306004 on 2023/06/20.

In the example shown in the figure, the fifth line has the invoice number "TYGN2306003", line number "1", accounting date "2023/06/15", payee "2: Warehouse B", cost item "100: Customs clearance application fee", and amount "10,000". The sixth line has the invoice number "TYGN2306003", line number "2", accounting date "2023/06/15", payee "2: Warehouse B", cost item "101: Animal quarantine application fee", and amount "20,000". The seventh line has the invoice number "TYGN2306003", line number "3", accounting date "2023/06/15", payee "2: Warehouse B", cost item "102: Plant quarantine application fee", and amount "40,000".

(S2: Debt determination process)
A specific example of the debt determination process will be described with reference to Figures 4 to 9. The debt determination unit 102b, for example, provides a debt determination screen (see Figure 4) in response to access from the terminal 400 of the representative establishment, extracts cost information from the cost information data table 106a using the specified payee and voucher number as keys in response to operations on the debt determination screen by the operator of the terminal 400 of the representative establishment, inputs the invoiced number of the extracted cost information to update the cost information, creates payment schedule data that aggregates amounts for each invoiced number, and registers this in the payment schedule data table 106b.

Figure 4 shows an example of the debt settlement screen 500. On the debt settlement screen, you select the target from the cost details based on the invoice you have on hand sent by the payee, and then register the debt settlement. The debt settlement screen 500 includes an extraction condition setting area (not shown) for specifying extraction conditions such as the payee (required) and voucher number From-To (optional), an execution button (not shown) for executing the extraction, an invoice unit summary details area (invoice number, amount, attachments), a cost details area that extracts and displays cost information that matches the extraction conditions from the cost information data table 106a, and a "Register F10" button.

In this example, the target data was extracted using the extraction conditions "Payment destination: 2: Warehouse B," "Voucher No. From: TYGN2306003," and "Voucher No. To: TYGN2306004."

The selection of the target for determining the payable amount will be explained with reference to Figure 5. Payee: With the invoice (invoice from the payee) received from Warehouse B at hand, enter the invoice number of the cost details and summarize the target amount for each invoice number. It is possible to determine the payable amount collectively for each payee, regardless of the unit in which the invoice is sent.

The operator operates the debt settlement target selection screen 500 by entering the invoiced number at hand into the invoiced number field of the cost detail line that matches the details of the invoiced item at hand in the cost details area. The debt settlement unit 102b aggregates the amounts by invoiced number of the cost details and displays them for each invoiced number in the invoice unit aggregated details area.

In the example shown in the figure, in the cost details area, the invoiced item numbers "BBSQ2306001" and "BBSQ2306002" from Warehouse B are entered into the corresponding details. As a result, the amounts are aggregated for the invoiced item numbers "BBSQ2306001" and "BBSQ2306002" in the cost details, and displayed for each invoiced item number in the invoiced item summary area. Specifically, invoiced item number "BBSQ2306001" and amount "126,000 (= 20,000 + 40,000 + 22,000 + 44,000)" are displayed, and invoiced item number "BBSQ2306002" and amount "21,000 (= 10,000 + 11,000)" are displayed.

The process of attaching supporting documents for each invoice will be explained with reference to Figure 6. The debt determination unit 102b creates supporting document data (attached files) for each invoice number in response to the operator's operations on the debt determination screen 500, and stores the data in the supporting document image data table 106c and the supporting document information data table 106d.

When the attachment "..." button for the target invoice No. is pressed and selected in the invoice-based aggregated details area on the debt confirmation screen 500 shown in Figure 6 (A), a file name is created for the attachment file of the supporting document for the selected invoice No., and the attachment list screen 600 shown in Figure 6 (B) is displayed. Since supporting documents are attached to details aggregated by invoice, one supporting document is attached per invoice.

The attachment list screen 600 includes the created file name, a details button, and a file type field. In the example shown in the figure, the attachment "..." button for invoice number "BBSQ2306001" is pressed in the invoice unit summary details area of the debt determination screen 500, creating a file name for the attachment voucher for invoice number "BBSQ2306001." The attachment list screen 600 displays the file name "Invoice_B Warehouse_BBSQ2306001.xlsx" and type "Electronic Transaction."

When the "..." button for the details of the target file name is pressed on the attachment list screen 600, the attachment details screen 700 is displayed, which is a screen for entering detailed information about the attachment of the supporting document. The attachment details screen 700 displays the image of the attachment, file type, and attribute information (document name, transaction year and month, date of receipt or sending, amount, client name, invoice number, reason for delay), allowing the operator to set the file type and attribute information. In the example shown in the figure, the "..." button for the details of the file name "Invoice_B Warehouse_BBSQ2306001.xlsx" is pressed on the attachment list screen 600, and the attachment details screen 700 for the file name "Invoice_B Warehouse_BBSQ2306001.xlsx" is displayed.

When "F10 Register" is pressed on the debt confirmation screen 500, the payment schedule data table 106b, cost information data table 106a, supporting document image data table 106c, and supporting document information data table 106d are updated according to the input on the screens (debt confirmation screen 500, attachment list screen 600, attachment details screen 700).

Figure 7 shows an example of data in the payment schedule data table (debt confirmation data table) to be updated. The payment schedule data has the following fields: debt confirmation number, line number, scheduled payment date, amount, and invoice number. The "debt confirmation number" is automatically assigned for each payee. The scheduled payment date is the closing date.

In the example shown in the figure, the first line has the debt confirmation number "TYSS2306002", row number "1", scheduled payment date "2023/06/30", amount "126,000", and invoice number "BBSQ2306001". The second line has the debt confirmation number "TYSS2306002", row number "2", scheduled payment date "2023/06/30", amount "21,000", and invoice number "BBSQ2306002".

The debt determination unit 102b creates a payment request for each debt determination number (payee). In the example shown in the figure, the payment request has invoice number: BBSQ2306002, payee: Warehouse B, and total amount: 147,000 yen.

Figure 8 is a diagram showing an example of data to be updated in the cost information data table (debt recording data table) 106a. The "Invoiced No.", "Debt Confirmed No.", "Debt Confirmed Line No.", and "Invoiced Management No." of the target record in the cost information data table (debt recording data table) 106a are updated. The "Debt Confirmed No." and "Debt Confirmed Line No." are join keys with the payment schedule data table 106b. The "Invoiced Management No." is the join key with the supporting document information data table 106d.

The "Invoice Management No." is automatically assigned for each invoice number. Since the invoice number is entered manually, it cannot be used as a combined key. Therefore, the automatically assigned "Invoice Management No." is used as the combined key.

In the example shown in the figure, the "Invoice No.," "Debt Confirmation No.," "Debt Confirmation Line No.," and "Invoice Management No." have been updated for document Nos. "TYGN2306003" and "TYGN2306004." For Invoice No. "BBSQ2306001," the Invoice Management No. "TKHI23060001" has been automatically assigned, and for Invoice No. "BBSQ2306002," the Invoice Management No. "TKHI23060002" has been automatically assigned.

Figure 9 shows example data for the updated evidence image data table 106c and evidence information data table 106d, with Figure 9(A) showing an example of the updated evidence image data table 106c and Figure 9(B) showing an example of the updated evidence information data table 106d.

As shown in Figure 9 (A), the evidence image data table 106c has fields for electronic evidence Guid and data. In the example shown in the figure, the first row has electronic evidence Guid "GuidA" and data "Invoice_B Warehouse_BBSQ2306001.xlsx binary data", and the second row has electronic evidence Guid "GuidB" and data "Invoice_B Warehouse_BBSQ2306002.xlsx binary data".

As shown in Figure 9 (B), the evidence information data table 106d has the following fields: electronic evidence Guid, file name, document name, transaction date, amount, client, receipt date, size, invoiced number, and invoiced management number. In the example shown in the figure, the first row contains the electronic evidence Guid "GuidA", file name "Invoice_B Warehouse_BBSQ2306001.xlsx", document name "Invoice", transaction date "2023/06/15", amount "126,000", client "2:B Warehouse", receipt date "2023/06/30", size "A4", invoiced number "BBSQ2306001", and invoiced management number "TKHI23060001". The second line has the electronic document Guid "GuidB", file name "Invoice_B Warehouse_BBSQ2306002.xlsx", document name "Invoice", transaction date "2023/06/15", amount "21,000", customer "2: B Warehouse", receipt date "2023/06/30", size "A4", invoice recipient number "BBSQ2306002", and invoice recipient management number "TKHI23060002".

(Inquiry processing)
A specific example of the inquiry process will be described with reference to Figure 10. The inquiry unit 102c provides a voucher attachment inquiry screen in response to access from the terminal 400 of the representative business office or each business office, and based on the search criteria (e.g., invoiced number, etc.) specified in response to operations on the voucher attachment inquiry screen by the operator of the terminal 400 of the representative business office or each business office, references the payment schedule data table 106b, cost information data table 106a, voucher image data table 106c, and voucher information data table 106d, and displays the search results (e.g., debt confirmation number, line number, invoiced management number, invoiced number, accounting date, payee, invoiced total amount, number of electronic transaction attachments, number of scanner-saved attachments, etc.).

On the evidence attachment inquiry screen, you can check whether the attached invoice and the scheduled payment data (debt confirmation data) are correctly linked. Figure 10 (A) is a diagram showing an example of the evidence attachment inquiry screen 800. On the evidence attachment inquiry screen 800, you can switch between the search conditions screen (not shown) and the search results screen using a button.

The search conditions screen includes the following search conditions (From To can be specified, all extraction items are optional): "Debt Confirmation No., Invoice Management No., Invoice No., Accounting Date, Payee, Total Invoice Amount"

When search conditions are specified and the execute button (not shown) is pressed, the query unit 102c references the payment schedule data table 106b, cost information data table 106a, supporting document image data table 106c, and supporting document information data table 106d based on the extraction conditions, and displays the search results on the search result screen by invoiced management number. The search results include the following fields: debt confirmation number, line number, invoiced management number, invoiced number, accounting date, payee, invoiced total amount, number of electronic transaction attachments, and number of scanner-saved attachments.

For example, if you perform a search using the search criteria "Invoice No. From: BBSQ2306001 Invoice No. To: BBSQ2306002," the search results, as shown in Figure 10 (A), will include, on the first line, the debt settlement number "TYSS2306002," row number "1," invoice management number "TKHI23060001," invoice No. "BBSQ2306001," accounting date "2023/06/15," payee "2: Warehouse B," total invoice amount "126,000," and electronic transaction information. The number of attachments drawn is "1", the number of attachments saved by scanner is "0", and on the second line, the debt confirmation number is "TYSS2306002", the row number is "2", the invoice management number is "TKHI23060002", the invoice number is "BBSQ2306002", the accounting date is "2023/06/15", the payee is "2: Warehouse B", the total amount of the invoice is "21,000", the number of electronic transaction attachments is "1", and the number of attachments saved by scanner is "0".

When you select the desired statement from the search results and press the "F2 Confirm Attachments" button, an attachment list screen 600 will be displayed showing the supporting document attachments attached to the statement, as shown in Figure 10 (B). When you press the "..." button on the attachment list screen 600, an attachment details screen 700 will be displayed, as shown in Figure 10 (C).

In the example shown in the figure, in the search results of Figure 10 (A), the detail "Debt Confirmation No: TYSS2306002 Line No: 1" is selected, the "F2 Confirm Attachments" button is pressed, the attachment list screen 600 for "Invoiced No: BBSQ2306001" is displayed, and the "Details..." button is pressed, and the attachment details screen 700 for "Invoiced No: BBSQ2306001" is displayed.

The operator can confirm whether the linking is correct by comparing the detailed information on the search results screen with the attachment information on the attachment details screen 700. In the example shown in the same figure, it can be confirmed that the linking is correct.

As explained above, this embodiment is equipped with an order recording unit 102a that, for each business location, registers the cost information (voucher number, recording date, payee, cost item, and amount) in the cost information data table 106a when recording an order, and an obligation determination unit 102b that, on the obligation determination screen, uses the specified payee as a key to extract cost information from the storage area, inputs the invoice number of the extracted cost information to update the cost information, and creates payment schedule data that aggregates amounts for each invoice number and registers this in the payment schedule data table 106b. This makes it possible to quickly grasp the income and expenditure for each order by recording obligations for each business location, while also making payments aggregated for each invoice.

[4. Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to SDGs goals 12, 13, and 15.

Furthermore, this embodiment can contribute to strengthening control and governance, thereby contributing to Goal 16 of the SDGs.

5. Other Embodiments
The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

In addition, the processing procedures, control procedures, specific names, registered data for each process, information including parameters such as search conditions, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

Furthermore, with regard to the debt processing device 100, the components shown in the figure are functional concepts and do not necessarily have to be physically configured as shown.

For example, all or any part of the processing functions of the debt processing device 100, particularly the processing functions performed by the control unit, may be implemented by a CPU and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory, computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the debt processing device 100 as needed. In other words, a computer program that works in conjunction with the OS to issue commands to the CPU and perform various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). This computer program is executed by being loaded into RAM, and works in conjunction with the CPU to form the control unit.

In addition, this computer program may be stored on an application program server connected to the debt processing device 100 via any network, and all or part of it may be downloaded as needed.

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

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. It should be noted that a "program" is not necessarily limited to a single structure, but also includes a distributed structure consisting of multiple modules or libraries, or a structure that achieves its function by working in conjunction with a separate program, such as an OS. The specific structure and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known structures and procedures.

The various databases stored in the memory unit are storage devices such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and website provision.

The debt processing device 100 may also be configured as an information processing device such as a known personal computer or workstation, or as such an information processing device to which any peripheral device is connected. The debt processing device 100 may also be implemented by installing software (including programs or data, etc.) that causes such a device to perform the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments may be implemented in any combination, or embodiments may be implemented selectively.

100 Debt processing device 102 Control unit 102a Order entry unit 102b Debt determination unit 102c Inquiry unit 102d Screen display control unit 104 Communication interface unit 106 Storage unit 106a Cost information data table 106b Payment schedule data table 106c Voucher image data table 106d Voucher information data table 108 Input/output interface unit 112 Input device 114 Output device 300 Network 400 Terminal

Claims (6)

A debt processing device equipped with a control unit,
The control unit
The system is configured to be able to access a storage area that stores cost information including an invoice number, which is the invoice number of the payee, a slip number, a recording date, a payee, a cost item, and an amount;
an order entry means for registering, for each business establishment, the slip number, entry date, payee, cost item, and amount of cost information in the storage area when entering an order;
a debt determination means for extracting cost information from the storage area using a designated payee as a key on the debt determination screen, inputting the invoiced number of the extracted cost information to update the cost information, and creating payment schedule data that aggregates the amounts for each invoiced number and registering it in the storage area;
A debt processing device comprising: The debt processing device described in claim 1, characterized in that the debt determination means extracts cost information from the memory area using the specified voucher number in addition to the payee as a key. The debt processing device described in claim 1, characterized in that the debt determination means creates a payment request form for each payee based on the payment schedule data registered in the memory area. A debt processing device as described in any one of claims 1 to 3, characterized in that the debt determination means creates supporting document data compliant with the Electronic Bookkeeping Act for each invoice number and registers it in the storage area. A debt processing method executed by an information processing device having a control unit,
The control unit
The system is configured to be able to access a storage area that stores cost information including an invoice number, which is the invoice number of the payee, a slip number, a recording date, a payee, a cost item, and an amount;
Executed in the control unit:
an order entry step for registering, for each business establishment, the slip number, entry date, payee, cost item, and amount of cost information in the storage area when entering an order;
a debt determination step of extracting cost information from the storage area using the designated payee as a key on the debt determination screen, inputting the invoiced number of the extracted cost information to update the cost information, and creating payment schedule data that aggregates the amounts for each invoiced number, and registering this data in the storage area;
A debt settlement method comprising: A debt processing program to be executed by an information processing device having a control unit,
The control unit
The system is configured to be able to access a storage area that stores cost information including an invoice number, which is the invoice number of the payee, a slip number, a recording date, a payee, a cost item, and an amount;
In the control unit,
an order entry step for registering, for each business establishment, the slip number, entry date, payee, cost item, and amount of cost information in the storage area when entering an order;
a debt determination step of extracting cost information from the storage area using the designated payee as a key on the debt determination screen, inputting the invoiced number of the extracted cost information to update the cost information, and creating payment schedule data that aggregates the amounts for each invoiced number, and registering this data in the storage area;
Debt settlement program to carry out.