Debt processing device, debt processing method, and debt processing program

Abstract

To provide a debt disposal device, debt disposal method and debt disposal program capable of compatibly achieving speedy acquisition of balance for each order received by debt recording for each business office and payment aggregated for each billed invoice.SOLUTION: A debt disposal device includes: order entry recording means for registering a slip number of cost information, a recording date, a payee, a cost item, and an amount of money in a storage area for each business office when an order entry is recorded; and debt determination means for extracting the cost information from the storage area using a designated payee as a key on a debt determination screen, inputting the billed invoice number of the extracted cost information to update the cost information, creating payment schedule data obtained by aggregating the amount for every billed invoice number, and registering the data in the storage area.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] For example, in the logistics industry, there are cases where each business office records payables for each order received and settles the payables based on the invoices sent to the central business office in a consolidated form. For example, Patent Document 1 shows a conventional payable processing system. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-46887 Summary of the Invention [Problem to be solved by the invention]

[0004] However, Patent Document 1 does not state anything about achieving both speedy understanding of income and expenditure for each order by recording liabilities for each business establishment and consolidated payments (debt determination) for each invoiced party.

[0005] The present invention has been made in consideration of the above, and aims to provide a debt processing device, debt processing method, and debt processing program that can simultaneously achieve speedy understanding of income and expenditures for each order by recording debts for each business location, and consolidated payments for each invoiced party. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems and achieve the object, the present invention is a debt processing device equipped with a control unit, which 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 is characterized by comprising: an order recording means that, for each business location, when recording an order, registers the voucher number, accounting date, payee, cost item, and amount of the cost information in the memory area; and a debt determination means that, on a debt 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 this in the memory area.

[0007] According to another aspect of the present invention, the debt determination means may extract cost information from the storage area using a specified slip number in addition to the payee as a key.

[0008] According to another aspect of the present invention, the debt determination means may prepare a payment request for each payee based on the payment schedule data registered in the storage area.

[0009] According to another aspect of the present invention, the debt determination means may create supporting document data that complies with the Electronic Bookkeeping Act for each invoiced number and register the data in the storage area.

[0010] In addition, in order to solve the above-mentioned problems and achieve the object, 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, in which the cost information's voucher number, accounting date, payee, cost item, and amount are registered in the memory area, and a debt determination process for extracting cost information from the memory area using the specified payee as a key on a debt determination screen, inputting the invoice number of the extracted cost information to update the cost information, and creating payment schedule data that aggregates amounts for each invoice number and registering it in the memory area.

[0011] Furthermore, in order to solve the above-mentioned problems and achieve the object, the present invention is an debt 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 recording step in which, for each business establishment, when recording an order, the cost information's voucher number, accounting date, payee, cost item, and amount are registered in the memory area, and an debt determination step in which, on a debt 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 registers this in the memory area. [Effects of the Invention]

[0012] According to the present invention, it is possible to achieve both a speedy grasp of income and expenditure for each order by recording liabilities for each business establishment and consolidated payments for each invoiced item. [Brief explanation of the drawings]

[0013] [Figure 1]FIG. 1 is a block diagram showing an example of the configuration of a debt processing device according to this embodiment. [Figure 2] 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. [Figure 3] FIG. 3 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 4] FIG. 4 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 5] FIG. 5 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 6] FIG. 6 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 7] FIG. 7 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 8] FIG. 8 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 9] FIG. 9 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. [Figure 10] FIG. 10 is a diagram for explaining a specific example of the processing of the control unit of the debt processing device according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of a debt processing device, a debt processing method, and a debt processing program according to the present invention will be described in detail below with reference to the accompanying drawings. However, the present invention is not limited to these preferred embodiments.

[0015] [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.

[0016] On the other hand, invoices, which are the final information on recorded liabilities, are often sent to the main office in bulk at various times, such as at the end of the month or each time. Also, in order to reduce overseas remittance fees, it is common for invoices to be sent in a consolidated form for a certain period of time, rather than for each order. Additionally, in order to efficiently settle and pay liabilities, it is preferred to send invoices in bulk for each payee. For this reason, there are requirements for quickly grasping the income and expenditures of order orders and efficiently settling and paying liabilities using consolidated invoices.

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

[0018] Therefore, in this invention, the granularity of information is adjusted by a function that aggregates the payables (multiple cost information) recorded for each order at each business location by invoice unit. This solves the above problem while enabling both a speedy grasp of income and expenditure for each order by recording payables for each business location and lump-sum payments for each invoice unit. In addition, by separating the details for payment processing from the details managed by invoice unit, it becomes possible to make the checking work of the person in charge easier.

[0019] Furthermore, in the present invention, when attaching supporting documents in accordance with the Electronic Bookkeeping Act, the aggregation unit and the supporting document attachment unit match, making it possible to easily confirm and control the attachment.

[0020] The debtor processing device of the present invention can be widely used in all 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.

[0021] [2. Configuration] An example of the configuration of the 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.

[0022] The debt processing device 100 is a commercially available desktop personal computer, workstation, or the like.

[0023] 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. The units comprised in the debt processing device 100 are connected to each other so as to be able to communicate with each other via any communication path.

[0024] 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 a function of communicating data with other devices via a communication line. Here, the network 300 has a function of connecting the debt processing device 100 to the server 200 and terminals 400... so that they can communicate with each other, and is, for example, the Internet or a LAN (Local Area Network). Note that data such as various masters described below may be stored in the server 200, for example. The terminals 400... are terminals of, for example, each business office (for example, the Yokohama Branch Sales Department or the Osaka Branch Sales Department) or a main business office (for example, 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.

[0025] 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 cooperates with a mouse to achieve a pointing device function. In the following, 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.

[0026] Various databases, tables, files, etc. are stored in the storage unit 106. Computer programs that work in conjunction with the OS (Operating System) to issue commands to the CPU (Central Processing Unit) to perform various processes are recorded in the storage unit 106. 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, an optical disk, etc.

[0027] The storage unit (storage area) 106 stores, for example, a cost information data table 106a, a payment schedule data table 106b, a voucher image data table 106c, a voucher information data table 106d, and the like.

[0028] The cost information data table (payables posting data table) 106a is a table for storing cost information (see FIG. 3). The cost information may include the following items: slip number (number), line number, posting date, payee, cost item, amount, invoiced number (number), payables confirmation number (number), payables confirmation line number, and invoiced management number (number). Of the cost information, the slip number, line number, posting date, payee, cost item, and amount are registered during the order posting process. Also, of the cost information, the invoiced number, payables confirmation number, payables confirmation line number, and invoiced management number are registered during the payables confirmation process.

[0029] The payment schedule data table (debt confirmation data table) 106b is a table for storing payment schedule data (see FIG. 7). The payment schedule data may include a debt confirmation number, a line number, a scheduled payment date, an amount, and an invoice number.

[0030] The evidence image data table 106c is a table for storing evidence image data of evidence data (attached file), and the evidence image data may include electronic evidence Guid and data (see FIG. 9(A)).

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

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

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

[0034] The control unit 102 conceptually includes an order entry unit 102a, a debt determination unit 102b, an inquiry unit 102c, and a screen display control unit 102d.

[0035] The order entry unit 102a, for example, provides an order entry screen (not shown) in response to access from the terminal 400 of each business location, 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 the terminal 400 of each business location, and registers the input in the cost information data table 106a of the memory unit 106.

[0036] The debt determination unit 102b, for example, provides a debt determination screen (see FIG. 4) in response to access from the terminal 400 of the representative business establishment, and extracts cost information from the cost information data table 106a using the designated payee as a key in response to operations on the debt determination screen by the operator of the terminal 400 of the representative business establishment, inputs the invoice number of the extracted cost information to update the cost information, creates payment schedule data that aggregates the amounts for each invoice 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 designated voucher number as a key in addition to the payee.

[0037] 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.

[0038] The debt determination unit 102b may create evidence data (attached file) that complies with the Electronic Bookkeeping Act for each invoiced number, and store the evidence image data table 106c and the evidence information data table 106d.

[0039] The inquiry unit 102c provides a supporting document attachment inquiry screen (see Figure 10) in response to access from, for example, the terminal 400 of the main business office or each business office, and based on the search conditions (e.g., invoiced number, etc.) specified in response to operations by the operator of the terminal 400 of the main business office or each business office on the supporting document attachment inquiry 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, 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.).

[0040] The screen display control unit 102d controls the display and input reception of various screens displayed on the monitor 114 (for example, an order entry screen, a debt determination screen, an attachment list screen, an attachment details screen, a voucher attachment inquiry screen, etc.).

[0041] [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.

[0042] [3-1. Processing flow (operational flow)] Fig. 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. 2.

[0043] Here, we will explain as an example a case where each business office (Yokohama Branch Sales Department, Osaka Branch Sales Department) receives orders from customers and records them 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.

[0044] The order entry unit 102a executes an 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 establishment, and inputs the slip 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 establishment, and registers the input data in the cost information data table 106a of the storage unit 106.

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

[0046] (1)-2: The Yokohama Branch Sales Department and the Osaka Branch Sales Department send (by 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 (by 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 (by email, fax, mail, etc.) an invoice to the main business office (Tokyo Head Office Accounting Department).

[0047] An operational issue here is that the units used to compile invoices can vary for each payee. For example, Shipping Company A sends invoices by consolidating all invoices for the current month onto one page. Warehouse B also sends invoices by consolidating all invoices for the current month, including customs fees, separately.

[0048] The debt determination unit 102b executes the debt determination process (job) (step S2). In the debt determination process, multiple pieces of cost information are aggregated by invoice number to determine the debt. Specifically, the debt determination unit 102b provides a debt determination screen (see FIG. 4) in response to access from the terminal 400 of the representative business establishment, and extracts cost information from the cost information data table 106a using the designated payee as a key in response to operations performed by the operator of the terminal 400 of the representative business establishment on the debt determination screen. The invoice number of the extracted cost information is input to update the cost information. Payment schedule data that aggregates the 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 designated voucher number as a key in addition to the payee. 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 the supporting document information data table 106d. The debt determination unit 102b may 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.

[0049] The inquiry unit 102c executes an inquiry process and provides a supporting document attachment inquiry screen (see Figure 10) in response to access from the terminal 400 of the main business office or each business office, and based on the search conditions (e.g., invoiced number, etc.) specified in response to operations by the operator of the terminal 400 of the main business office or each business office on the supporting document attachment inquiry 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, 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.).

[0050] [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 explained with reference to FIGS. 3 to 10.

[0051] (S1: Order entry processing) A specific example of order entry processing will be described with reference to Fig. 3. The order entry unit 102a provides an order entry screen (not shown) in response to access from the terminal 400 of each business establishment, for example, and inputs the slip 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 establishment, and registers them in the cost information data table 106a of the storage unit 106.

[0052] Figure 3 shows an example of data in 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 confirmed number, payables confirmed line number, and invoiced management number. The invoiced number, payables confirmed number, payables confirmed line number, and invoiced management number are "NULL" at the order posting process stage, and the data is registered during the payables confirmation process. 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 invoice number TYGN2306004 on 2023 / 06 / 20.

[0053] 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."

[0054] (S2: Debt determination processing) A specific example of debt determination processing 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 business 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 business establishment, inputs the invoice number of the extracted cost information to update the cost information, creates payment schedule data that aggregates amounts for each invoice number, and registers this invoice data in the payment schedule data table 106b.

[0055] 4 is a diagram showing an example of the debt settlement screen 500. On the debt settlement screen, the user selects an object from the cost details based on the invoice received from the payee, and registers 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 extraction, an invoice unit summary details area (invoice number, amount, attachment), a cost details area for extracting and displaying cost information that matches the extraction conditions from the cost information data table 106a, and a "Register F10" button, etc.

[0056] In this example, target data is extracted using the extraction conditions "Payment destination: 2: Warehouse B", "Slip No. From: TYGN2306003", and "Slip No. To: TYGN2306004".

[0057] The selection of the payables settlement target 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 amounts by invoice number. It is possible to settle the payables by payee, regardless of the unit in which the invoices are sent.

[0058] The operator inputs 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 of ​​the debt settlement target selection screen 500. 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.

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

[0060] The process of attaching a supporting document for each invoice will be described with reference to Figure 6. The debt determination unit 102b creates supporting document data (attached file) for each invoice No. in response to an operator's operation 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.

[0061] 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.

[0062] 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," and the attachment list screen 600 displays the file name "Invoice_B Warehouse_BBSQ2306001.xlsx" and type "Electronic Transaction."

[0063] When the "..." button for 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 following items: the image of the attachment, the file type, and attribute information (document name, transaction year and month, date of receipt or sending, amount, client name, invoice number, reason for delay), and the operator can set the file type and attribute information. In the example shown in the figure, the "..." button for 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.

[0064] 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).

[0065] 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 No., Line No., Scheduled Payment Date, Amount, and Invoiced No. The "Debt Confirmation No." is automatically assigned for each payee. The scheduled payment date is the closing date.

[0066] In the example shown in the same 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", and 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".

[0067] 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.

[0068] Figure 8 is a diagram showing an example of data to be updated in the cost information data table (debt apportioning 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 apportioning 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 a join key with the supporting document information data table 106d.

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

[0070] 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," and the invoice management No. "TKHI23060001" has been automatically assigned for invoice No. "BBSQ2306001," and the invoice management No. "TKHI23060002" has been automatically assigned for invoice No. "BBSQ2306002."

[0071] Figure 9 shows example data of the updated evidence image data table 106c and evidence information data table 106d, where Figure 9(A) shows an example of the updated evidence image data table 106c, and Figure 9(B) shows an example of the updated evidence information data table 106d.

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

[0073] 9(B), the evidence information data table 106d has the following fields: electronic evidence Guid, file name, document name, transaction date, amount, customer, 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," the file name "Invoice_B Warehouse_BBSQ2306001.xlsx," the document name "Invoice," the transaction date "2023 / 06 / 15," the amount "126,000," the customer "2:B Warehouse," the receipt date "2023 / 06 / 30," the size "A4," the invoiced number "BBSQ2306001," and the invoiced management number "TKHI23060001." The second line contains the electronic document Guid "GuidB", file name "Invoice_B Warehouse_BBSQ2306002.xlsx", document name "Invoice", transaction date "2023 / 06 / 15", amount "21,000", business partner "2:B Warehouse", receipt date "2023 / 06 / 30", size "A4", invoice recipient number "BBSQ2306002", and invoice recipient management number "TKHI23060002".

[0074] (Inquiry processing) A specific example of the inquiry process will be described with reference to Fig. 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 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.).

[0075] On the evidence attachment inquiry screen, it is possible to 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, it is possible to switch between the search condition screen (not shown) and the search result screen with a button.

[0076] The search conditions screen has 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"

[0077] When the 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 No. The search results include the following items: debt confirmation No., line No., invoiced management No., invoiced No., accounting date, payee, invoiced total amount, number of electronic transaction attachments, and number of scanner-saved attachments.

[0078] For example, if you specify the search criteria as "Invoice No. From:BBSQ2306001 Invoice No. To:BBSQ2306002", the search results will be as shown in Figure 10(A), in the first line, the Debt Confirmation No. "TYSS2306002", row number "1", Invoice Management No. "TKHI23060001", Invoice No. "BBSQ2306001", accounting date "2023 / 06 / 15", payee "2:B Warehouse", invoice total amount "126,000", electronic transaction The number of attachments drawn is "1", the number of attachments saved on the scanner is "0", and on the second line, the debt settlement number is "TYSS2306002", the line 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:B Warehouse", the total amount of invoices is "21,000", the number of electronic transaction attachments is "1", and the number of attachments saved on the scanner is "0".

[0079] When you select the target statement from the search results and press the "F2 Confirm Attachments" button, an attachment list screen 600 of the supporting documents attached to the statement will be displayed, 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).

[0080] In the example shown in the same figure, in the search results of Figure 10 (A), the detail "Debt Confirmation No: TYSS2306002 Line No: 1" is selected, the "F2 Confirm Attachment" 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.

[0081] The operator can check whether the linking is correct by comparing the detailed information on the search result screen with the attachment file information on the attachment file details screen 700. In the example shown in the figure, it can be confirmed that the linking is correct.

[0082] As explained above, according to this embodiment, there is provided an order recording unit 102a for each business establishment which, when recording an order, registers the cost information such as the slip number, recording date, payee, cost item, and amount in the cost information data table 106a, and a debt determination unit 102b which, on the debt determination screen, uses the payee specified 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 debts for each business establishment, and to make payments aggregated for each invoice.

[0083] [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.

[0084] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of SDGs Goals 12, 13, and 15.

[0085] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0086] 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.

[0087] 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.

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

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

[0090] 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. That is, a computer program is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive) for working with the OS to issue instructions to the CPU and perform various processes. This computer program is executed by being loaded into RAM and works with the CPU to form the control unit.

[0091] Furthermore, this computer program may be stored in an application program server connected to the debt processing device 100 via any network, and it is also possible to download all or part of it as needed.

[0092] Furthermore, the program for executing the processes described in this embodiment may be stored in a non-transitory computer-readable recording medium or configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) disc.

[0093] Furthermore, a "program" is a data processing method written in any language or description method, regardless of the format, such as source code or binary code. Note that a "program" is not necessarily limited to a single structure, but also includes a structure that is distributed as multiple modules or libraries, or a structure that achieves its function by cooperating with a separate program, such as an OS. Note that the specific configuration 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 configurations and procedures.

[0094] The various databases stored in the memory unit are storage means 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 providing websites.

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

[0096] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be configured by functionally or physically distributing and integrating them in any unit depending on various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Explanation of symbols]

[0097] 100 Debt Processing Device 102 Control section 102a Order Accounting Department 102b Debt Settlement Department 102c Enquiry Section 102d Screen display control unit 104 Communication interface unit 106 Storage section 106a Cost Information Data Table 106b Payment schedule data table 106c Voucher Image Data Table 106d Evidence information data table 108 Input / Output Interface Section 112 Input Device 114 Output Device 300 Network 400 terminals

Claims

1. A debt processing device equipped with a control unit, The control unit Invoice No. of the payee, slip No., accounting date, payee, cost item, amount The method is configured to be able to access a storage area that stores cost information including 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:

2. 2. The debt processing apparatus according to claim 1, wherein said debt determination means extracts cost information from said storage area using a designated slip number in addition to said payee as a key.

3. 2. The debt processing apparatus according to claim 1, wherein said debt determination means prepares a payment request for each payee based on the payment schedule data registered in said storage area.

4. The debt processing device according to any one of claims 1 to 3, characterized in that the debt determination means creates supporting document data that complies with the Electronic Bookkeeping Act for each invoice number and registers it in the memory area.

5. A debt processing method executed by an information processing device having a control unit, The control unit Invoice No. of the payee, slip No., accounting date, payee, cost item, amount The method is configured to be able to access a storage area that stores cost information including 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 it in the storage area; A debt settlement method comprising:

6. A debt processing program to be executed by an information processing device having a control unit, The control unit Invoice No. of the payee, slip No., accounting date, payee, cost item, amount The method is configured to be able to access a storage area that stores cost information including 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 it in the storage area; Debt settlement program to carry out.

Images