Business support device, business support method, and business support program

Abstract

This system allows for simultaneous reconciliation processing across multiple transfer destinations for a single deposit, preventing the inconvenience of waiting in line for reconciliation. [Solution] This business support device assists in transfer operations, where an amount deposited into a transfer source is transferred to multiple transfer destinations. The acquisition unit acquires the deposited amount by dividing it into transfer amounts for each transfer destination. The accounts receivable data generation unit generates accounts receivable data for each transfer destination, with the acquired transfer amount set as a negative amount for the transfer source and the acquired transfer amount set as a positive amount for the transfer destination. This makes it possible to perform reconciliation processing at multiple transfer destinations simultaneously for a single deposit, preventing the inconvenience of waiting in line for reconciliation work.

Description

Technical Field

[0001] The present invention relates to a business support device, a business support method, and a business support program.

Background Art

[0002] Patent Document 1 (Japanese Patent No. 7569417) discloses a settlement processing device that provides a payment means for card payment combined with a guarantee function.

[0003] In paragraph 0056 of this Patent Document 1, there is a description of setting the status of claim data and claim detail data to "paid", which enables the clerical work of offsetting payments for each claim to be performed easily.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] Here, when transfers are made to a plurality of payees based on the payment from a single remitter, the offsetting process of the creditor balance is an exclusive process. Therefore, it is difficult to perform the offsetting process simultaneously at a plurality of payees for a single payment, and it was necessary to wait for the offsetting process until the offsetting process at other payees was completed.

[0006] The present invention has been made in view of the above problems, and an object thereof is to provide a business support device, a business support method, and a business support program that enable offsetting processes at a plurality of payees simultaneously for a single payment and prevent the inconvenience of waiting for the order of the offsetting work.

Means for Solving the Problems

[0007] To solve the above-mentioned problems and achieve the objective, the business support device according to the present invention is a business support device that supports transfer operations in which an amount deposited into a transfer source is transferred to multiple transfer destinations, and comprises: an acquisition unit that acquires the deposited amount by dividing it into transfer amounts for each transfer destination; and a receivable data generation unit that generates receivable data for each transfer destination, with the acquired transfer amount being a negative amount for the transfer source and the acquired transfer amount being a positive amount for the transfer destination.

[0008] Furthermore, in order to solve the above-mentioned problems and achieve the objective, the business support method according to the present invention is a business support method for a business support device that supports transfer operations in which an amount deposited into a transfer source is transferred to multiple transfer destinations, comprising: an acquisition step in which the acquisition unit acquires the deposited amount by dividing it into transfer amounts for each transfer destination; and a debt data generation step in which the debt data generation unit generates debt data for each transfer destination, in which the acquired transfer amount is set as a negative amount for the transfer source and the acquired transfer amount is set as a positive amount for the transfer destination.

[0009] Furthermore, in order to solve the above-mentioned problems and achieve the objective, the business support program according to the present invention is a business support device that supports transfer operations in which an amount deposited into a transfer source is transferred to multiple transfer destinations, and the computer functions as an acquisition unit that acquires the deposited amount by dividing it into transfer amounts for each transfer destination, and a receivable data generation unit that generates receivable data for each transfer destination, with the acquired transfer amount being a negative amount for the transfer source and the acquired transfer amount being a positive amount for the transfer destination. [Effects of the Invention]

[0010] This invention enables simultaneous reconciliation processing at multiple transfer destinations for a single deposit, preventing the inconvenience of waiting in line for reconciliation work. Therefore, it can improve the efficiency of accounting operations. [Brief explanation of the drawing]

[0011] [Figure 1] Figure 1 is a block diagram showing the hardware configuration of the business support device according to the embodiment. [Figure 2]FIG. 2 is a diagram showing an example of credit data. [Figure 3] FIG. 3 is a diagram showing an example of an input classification general ledger master table. [Figure 4] FIG. 4 is a diagram showing an example of a creditor classification general ledger master table. [Figure 5] FIG. 5 is a diagram for explaining the outline of the business support device according to the embodiment. [Figure 6] FIG. 6 is a diagram showing a series of processing flows from bill deposit to deposit transfer to credit reflection after the bill due date in the business support device according to the embodiment. [Figure 7] FIG. 7 is a diagram showing an example of received bill data generated by the deposit of a promissory note. [Figure 8] FIG. 8 is a diagram showing an example of deposit data for the deposit department. [Figure 9] FIG. 9 is a diagram showing an example of credit data. [Figure 10] FIG. 10 is a diagram showing an example of a deposit transfer input screen. [Figure 11] FIG. 11 is a diagram showing an example of deposit data for each creditor management department. [Figure 12] FIG. 12 is a diagram showing an example of deposit transfer detail data. [Figure 13] FIG. 13 is a diagram showing how the credit data in the correct accounting form is updated in the business support device according to the embodiment. [Figure 14] FIG. 14 is a diagram showing the credit data updated after the bill due date. [Figure 15] FIG. 15 is a diagram showing the generated journal entry data before the bill due date. [Figure 16] FIG. 16 is a diagram showing the generated journal entry data of the deposit department after the bill due date. [Figure 17] FIG. 17 is a diagram showing the detailed journal entry data of the bill generated after the bill due date.

MODE FOR CARRYING OUT THE INVENTION

[0012] Hereinafter, a business support device according to an embodiment to which the present invention is applied will be described in detail based on the drawings. Note that the present invention is not limited to the following embodiments.

[0013] (Hardware Configuration) As shown in FIG. 1, the business support device 1 of the embodiment includes a storage unit 2, a control unit 3, a communication interface unit 4, and an input / output interface unit 5. An input device 6 and an output device 7 are connected to the input / output interface unit 5.

[0014] As the output device 7, a display unit such as a monitor device (including a home TV), a printing device, or a speaker device corresponds. As the input device 6, in addition to a keyboard device, a mouse device, and a microphone device, a monitor device that realizes a pointing device function in cooperation with the mouse device can be used.

[0015] The communication interface unit 4 is connected to a network such as a wide area network such as the Internet or a private network such as a LAN (Local Area Network).

[0016] [[ID=|17]] As the storage unit 2, for example, a storage device such as a ROM (Read Only Memory), a RAM (Random Access Memory), an HDD (Hard Disk Drive), or an SSD (Solid State Drive) can be used.

[0017] The storage unit 2 stores a business support program that enables offset processing at a plurality of transfer destinations simultaneously for one deposit and prevents the inconvenience of waiting in line for the offset work.

[0018] In addition, the storage unit 2 is provided with a credit data storage unit 11, a received bill data storage unit 12, a deposit data storage unit 13, an input classification ledger item master table 14, a creditor classification ledger item master table 15, and a journal data storage unit 16, which are storage areas respectively.

[0019] As shown in Figure 2, the credit data storage unit 11 stores credit data including department codes, counterparty codes, credit limits, accounts receivable balances, outstanding bill balances, and credit balances. Of the credit data shown in Figure 2, the credit data for the department code "B000" is the credit data for the department where the payment corresponding to the receivable is made (the payment department = the transfer source).

[0020] In this example, the counterparty making the payment corresponding to the receivable is the counterparty with the counterparty code "S001". Also, the credit limit, accounts receivable balance, outstanding bill balance, and credit balance for the payment department with the department code "B000" are all "0 yen", etc.

[0021] In contrast, the credit data for department codes "B001" and "B002" is the credit data of the department responsible for debt management (debt management department). This debt management department reconciles debts based on payments received by the payment department.

[0022] In this example, the credit limit for the accounts receivable management department with department code "B001" is "50,000 yen," and the accounts receivable balance (the amount to be reconciled as a receivable) is "40,000 yen." Also, since the accounts receivable balance is "40,000 yen," the credit balance is "10,000 yen."

[0023] Furthermore, the credit limit for the accounts receivable management department under department code "B002" is "75,000 yen," and the accounts receivable balance is "60,000 yen." Since the accounts receivable balance is "60,000 yen," the credit balance is "15,000 yen."

[0024] As shown in Figure 3, the input category account master table has accounts set for each input category. In this example in Figure 3, the account set for the receipt category "Notes Receivable" is "Notes Receivable".

[0025] As shown in Figure 4, the Accounts Receivable Classification Account Master Table 15 has accounts set for each account classification. In this example in Figure 4, the account for the "Temporary Receivable" account classification is set to "Temporary Receivable," and the account for the "Accounts Receivable" account classification is set to "Accounts Receivable."

[0026] (overview) Here, we will describe the outline of the business support device 1 of the embodiment. When there are transactions with multiple departments from a single customer, the reconciliation process is an exclusive process, making it difficult for multiple departments to perform reconciliation processing simultaneously for a single payment. Therefore, it is necessary to wait until the other departments have finished their reconciliation processing.

[0027] Furthermore, while debtors use bank transfers, checks, and promissory notes as payment methods, in the case of promissory note payments, receivables from multiple departments are often consolidated onto a single note. In such cases, proper credit management has become difficult.

[0028] Specifically, as shown in Figure 5(a), suppose two departments invoiced "1,000 yen" and "1,500 yen" respectively, and as shown in Figure 5(b), a single payment of "2,500 yen" was made to the receiving department. In this case, when the invoices from departments A and B were reconciled, the outstanding balance of receivables and the outstanding balance of bills of exchange were set to "0 yen," resulting in the inconvenience of recording the credit balance of departments A and B as the credit limit of "1,500 yen." In addition, the "2,500 yen" received by the receiving department was treated as the outstanding balance of bills of exchange for the receiving department, resulting in the inconvenience of recording the credit balance of the receiving department as "-2,500 yen."

[0029] Thus, when a single promissory note was issued for payments on accounts receivable from multiple departments, proper credit management became difficult.

[0030] When a single bill of exchange is used to pay receivables from multiple departments, as shown in Figure 5(c), the correct credit management involves setting the credit balance of the paying department to "0 yen," setting the outstanding bill balances for departments A and B to "1,000 yen" and "1,500 yen" respectively, corresponding to the receivables, and setting the outstanding credit bill balances for departments A and B to "500 yen" and "0 yen," which represent the difference between the credit limits.

[0031] For these reasons, the business support device 1 of this embodiment enables the reconciliation process for each department, preventing the inconvenience of waiting in line for reconciliation work and thereby improving the efficiency of operations.

[0032] Furthermore, by splitting payment slips before reconciliation, it becomes possible to manage outstanding amounts by department, enabling accurate credit management.

[0033] Furthermore, the system automatically generates journal entries detailing the outcome when a promissory note is paid in installments, thereby supporting accounting operations.

[0034] (Functional configuration of business support equipment) Next, the control unit 3 executes the business support program stored in the storage unit 2, and functions as an acquisition unit 21, a data generation unit 22, and a display control unit 23, as shown in Figure 1. The data generation unit 22 includes the functions of a receivables data generation unit 24, a journal entry data generation unit 25, and a credit data generation unit 26.

[0035] In this example, the acquisition unit 21 to the credit data generation unit 26 are described as being implemented in software based on the business support program, but all or part of the acquisition unit 21 to the credit data generation unit 26 may be implemented in hardware. In either case, the same effects as described later can be obtained.

[0036] The acquisition unit 21 acquires the received amount (for example, a bill payment to the payment department shown in Figure 7) by dividing it into the transfer amounts for each transfer destination (each accounts receivable management department).

[0037] In addition to the promissory note payment method shown in Figure 7, the payment method may also be a bank transfer or a check.

[0038] The receivables data generation unit 24 generates receivables data for each transfer destination (credit data in Figure 9, deposit data in Figures 11(a) and 11(b), and deposit transfer details data in Figure 12) by setting the acquired transfer amount as a negative amount for the transfer source and the acquired transfer amount as a positive amount for the transfer destination.

[0039] For example, when payment is made using a promissory note with a set payment due date, the acquisition unit 21 acquires the received note amount by dividing it into the transfer amounts for each transfer destination.

[0040] Furthermore, the receivables data generation unit 24 generates a receipt slip as receivables data, based on the operator's input (see the receipt transfer input screen in Figure 10), with the received bill amount as a provisional receipt and the total amount of transfers to each transfer destination as the settled amount. (See the receipt slips for the 100,000 yen receipt amount in the first row of Figure 11(a) and the first row of Figure 11(b)).

[0041] Furthermore, the accounts receivable data generation unit 24 generates a red slip for each of the aforementioned transfer destinations, with the accounts receivable account classification set to "Temporary Receivable" and the transfer amount to the transfer destination set to the negative amount to the transfer source (see the red slips with negative deposit amounts in the second and fourth lines of Figure 11(a) and the second and fourth lines of Figure 11(b)).

[0042] Furthermore, the accounts receivable data generation unit 24 generates black slips for each of the transfer destinations, with the accounts receivable category set to accounts receivable and the transfer amount set to the transfer destination's positive amount (refer to the black slips with positive deposit amounts in lines 3 and 5 of Figure 11(a) and lines 3 and 5 of Figure 11(b)).

[0043] The journal entry data generation unit 25 generates journal entry data for red slips and black slips (see Figures 15(a) and 15(b)), and also generates conclusion journal entry data corresponding to red slips and black slips after the payment due date of the promissory note (see Figures 16 and 17).

[0044] The credit data generation unit 26 generates credit data that includes the credit limit for the transferor and each transferee, the outstanding balance of receivables for each transferee (accounts receivable balance in Figure 13), the outstanding balance of promissory notes indicating the balance after the transfer amount has been settled by promissory notes, and the credit balance which is the amount obtained by subtracting the outstanding balance of promissory notes from the credit limit (see Figure 13).

[0045] The credit data generation unit 26 updates the credit balance in the credit data to an amount obtained by subtracting the balance settled with the transfer amount obtained from the promissory note after the payment due date of the promissory note from the credit limit (in the example in Figure 14, this is "0 yen") (see Figure 14).

[0046] Such receivable data (credit data in Figure 9, payment data in Figures 11(a) and 11(b), payment transfer details data in Figure 12, journal entry data, incident journal entry data, etc.) is output to the output target device by the control unit 3 functioning as an output control unit. The output target device corresponds to, for example, the output device 7, and can be a display device, a printing device, or a speaker device. The output control unit converts the receivable data into display information, print information, or audio information and supplies it to the corresponding device. This makes it possible to obtain display output, print output, or audio output of the receivable data. In addition, the output target device can be the storage unit 2, an external storage device, or a server device on a network, and the receivable data may be output to or transmitted to these devices for storage.

[0047] (A series of processes from bill payment to transfer of funds, from the bill's due date to the reflection of credit approval) Next, we will explain the series of processes from bill receipt to payment transfer to credit reflection upon the bill's maturity date. For the purposes of this explanation, we will assume that payments for receivables from multiple departments are made using a single promissory note. In this case, the above series of processes proceed in the following order, as shown in Figure 6: input of bills receivable to the input department → input of payments to the input department → input of payment transfers to the respective receivables management departments (Department A and Department B) for each receivable → bill management → creation of journal entry data.

[0048] (Entering bills of exchange receivable) First, the operator inputs the information of the received promissory note via the input device 6. This input promissory note information is acquired by the acquisition unit 21. Based on the acquired promissory note information, the data generation unit 22 generates the received bill data exemplified in Figure 7 and stores it in the received bill data storage unit 12.

[0049] The bills receivable data includes a unique bill number, management department code, customer code, issue date (receipt date), bill due date, and amount. The management department code is "B000," which is the management department code of the receiving department, clearly indicating that the payment for that promissory note is for the receiving department. For example, the amount received by the promissory note is "100,000 yen."

[0050] (Deposit entry) Next, the receivable data generation unit 24 generates the deposit data shown in Figures 8(a) and 8(b) based on the bills receivable data and the operator's input. This deposit data consists of the deposit header data shown in Figure 8(a) and the deposit detail data shown in Figure 8(b).

[0051] The deposit header data shown in Figure 8(a) consists of a unique deposit number, deposit date, account receivable category, deposit amount, customer code, department code, confirmed deposit category, reconciliation source, and reconciled amount. Of these, the unique deposit number is automatically assigned by the account receivable data generation unit 24. The deposit date is added to the deposit header data by the account receivable data generation unit 24 by referring to the issue date (deposit date) of the aforementioned bill of exchange data. The account receivable category is manually entered by the operator. In this case, the account receivable category will be "Temporary Receivable".

[0052] The amount of payment is added to the payment header data by the accounts receivable data generation unit 24 by referring to the amount in the aforementioned bills receivable data. The billing party (= trading partner) is added to the payment header data by the accounts receivable data generation unit 24 by referring to the trading partner in the aforementioned bills receivable data, and in this example, the billing party code "S001" is added to the payment header data. The department code is also added to the payment header data by the accounts receivable data generation unit 24 by referring to the trading partner in the aforementioned bills receivable data, and in this example, the department code "B000" indicating the payment department is added to the payment header data.

[0053] The payment confirmation category indicates whether or not the payment has been confirmed. In the case of payment by promissory note, the payment is confirmed after the due date of the note. For this reason, the claims data generation unit 24 generates payment header data with "Not Confirmed" entered in the payment confirmation category before the due date of the note (in this example, the due date of the note is November 30, 2024).

[0054] The reconciliation source indicates the amount available for reconciliation in the accounts receivable management departments with management department codes "B001" and "B002". In this example, the entered amount is the reconciliation source, which is "100,000 yen".

[0055] The settled amount is the amount used to settle receivables in the receivables management departments of the management department codes "B001" and "B002". At the stage when the payment is received in the "B000" payment department, the receivables have not yet been settled in each receivables department, so the settled amount is "0 yen (meaning that 0 yen was used to settle receivables from the 100,000 yen received)".

[0056] The deposit details data shown in Figure 8(b) consists of a deposit number, line number, deposit category, deposit amount, bill number, and bill due date. The deposit number is the same as the deposit number assigned to the deposit header data. The deposit category is assigned as "bill receivable" by the operator.

[0057] The deposit amount, bill number, and bill due date are obtained by the claims data generation unit 24 from the bills receivable data shown in Figure 7 and attached to the deposit details data.

[0058] Furthermore, based on the aforementioned "100,000 yen" bill payment, the credit data generation unit 26 generates credit data for each department with the department codes "B000", "B001", and "B002", as shown in Figure 9, including the department code, counterparty, credit limit, accounts receivable balance, outstanding bill balance, and credit balance.

[0059] The counterparty (debtor) is the counterparty with counterparty code "S001". The credit limit is the amount for which credit transactions are possible with that department. In this example, the credit limit for the deposit department with department code "B000" is set to "0 yen". Also, the credit limit for the accounts receivable management department with department code "B001" is set to "50,000 yen", and the credit limit for the accounts receivable management department with department code "B002" is set to "75,000 yen".

[0060] The accounts receivable balance indicates the amount of receivables for each department (the amount to be settled by payment). In this example, the accounts receivable balance for the payment department with department code "B000" is "0 yen". Also, the accounts receivable balance for the accounts receivable management department with department code "B001" is "40,000 yen", and the accounts receivable balance for the accounts receivable management department with department code "B002" is "60,000 yen".

[0061] The credit data generation unit 26 sets the "100,000 yen" received by promissory note as the outstanding balance of promissory notes for the receiving department with department code "B000". The credit data generation unit 26 also sets the credit balance of "-100,000 yen", obtained by calculating "credit limit of 0 yen - outstanding balance of promissory notes of 100,000 yen", as the credit balance for the receiving department.

[0062] In contrast, the credit limit for the accounts receivable management department with department code "B001" is "50,000 yen," and the outstanding balance of accounts receivable in the accounts receivable management department is "40,000 yen." Therefore, the credit data generation unit 26 calculates a credit balance of "10,000 yen" by performing the calculation "credit limit of 50,000 yen - outstanding balance of accounts receivable of 40,000 yen," and uses this balance as the credit balance for the accounts receivable management department with department code "B001."

[0063] Similarly, the credit limit for the accounts receivable management department with department code "B002" is "75,000 yen," and the outstanding balance of accounts receivable in the accounts receivable management department is "60,000 yen." Therefore, the credit data generation unit 26 calculates the outstanding balance of "15,000 yen" by performing the calculation "credit limit of 75,000 yen - outstanding balance of accounts receivable of 60,000 yen," and uses this balance as the outstanding balance for the accounts receivable management department with department code "B002."

[0064] In addition, the operator may manually input various information about the deposit data based on the bills receivable data, and the receivable data generation unit 24 may generate the deposit data shown in Figures 8(a) and 8(b) based on the various information entered by the operator.

[0065] (Input for payment transfer) Next, the operator specifies the display of the deposit transfer input screen via the input device 6. The display control unit 23 then displays the deposit transfer input screen, as illustrated in Figure 10, via the output device 7. In this deposit transfer input screen, the upper half of the area is the input field for the source red slip, and the lower half of the area is the input field for the destination black slip.

[0066] In this example, the source of the transfer is the receiving department with department code "B000". Therefore, the display control unit 23 refers to the payment header data shown in Figure 8(a) and the payment details data shown in Figure 8(b), and automatically enters and displays the source payment number (NY001), payment date (September 25, 2024), department code (B000: receiving department), billing address (S001), account type (temporary receipt), payment amount, and reconciliation amount, etc., into the respective input fields for the source information on the payment transfer input screen.

[0067] Furthermore, the display control unit 23 displays the deposit type (bill of exchange), deposit amount (100,000 yen), transferred amount (0 yen), and details summary as details of the transfer source information.

[0068] In this example, the recipient of the transfer is the accounts receivable management department with department codes "B001" and "B002". Therefore, the operator refers to the deposit header data shown in Figure 8(a) and the deposit details data shown in Figure 8(b), and enters the deposit transfer number (NF001), deposit transfer category, business location (A001), deposit transfer date (September 25, 2024), transferable amount (100,000 yen), transfer amount (40,000 yen), and description into the respective input fields for the recipient information on the deposit transfer input screen.

[0069] In addition, the operator enters the transfer destination deposit number (NY003), transfer source deposit line number (1), department code (B001), payment recipient (S001), credit memo transfer destination deposit number (NY002), and account receivable category (accounts receivable), etc., into the respective input fields for transfer destination information on the deposit transfer input screen.

[0070] Note that the transfer destination information in Figure 10 is for the accounts receivable management department with department code "B001". Therefore, it should be understood that the transfer destination information for the accounts receivable management department with department code "B002" will be entered in the same way as the transfer destination information for the accounts receivable management department with department code "B001". In this case, "B001" will be entered as the department code and "60,000 yen" as the transfer amount.

[0071] The acquisition unit 21 acquires the deposited amount (100,000 yen) by splitting it into the transfer amount for the accounts receivable management department with department code "B001" (40,000 yen) and the transfer amount for the accounts receivable management department with department code "B002" (60,000 yen), based on the input on the deposit transfer input screen.

[0072] As a result, the receivables data generation unit 24 updates the settled amount in the deposit header data shown in Figure 8(a) to the settled amount of "100,000 yen," as shown in the first row of the deposit header data in Figure 11(a). This generates a deposit slip in which the amount of the received bill is treated as a temporary receipt, and the total amount of the transfers to each transfer destination is treated as the settled amount.

[0073] Furthermore, the accounts receivable data generation unit 24 generates a red slip by setting the transfer amount of the accounts receivable management department for the acquired department code "B001" (40,000 yen) and the transfer amount of the accounts receivable management department for the department code "B002" (60,000 yen) to a negative amount of the transfer source (department code B000), as shown in the deposit header data in the second and fourth lines of Figure 11(a) and the deposit detail data in the second and fourth lines of Figure 11(b).

[0074] The deposit header data corresponding to this red memo will have the account type as "Temporary Receipt," the deposit confirmation type as "Confirmed," and the reconciliation source and reconciliation amount as "-40,000 yen" and "-60,000 yen," respectively. In addition, the deposit detail data corresponding to the red memo will have the deposit type as "Bills Receivable," and the deposit amounts as "-40,000 yen" and "-60,000 yen," respectively.

[0075] Furthermore, the accounts receivable data generation unit 24 generates black slips, as shown in the deposit header data on the 3rd and 5th lines of Figure 11(a) and the deposit detail data on the 3rd and 5th lines of Figure 11(b), by adding the acquired transfer amounts (40,000 yen) for the accounts receivable management department with department code "B001" and (60,000 yen) for the accounts receivable management department with department code "B002" to the transfer destination (the deposit management department of B001 or B002), respectively.

[0076] The deposit header data, which corresponds to this black slip, will have "Accounts Receivable" as the account type, "Confirmed" as the payment confirmation type, "-40,000 yen" and "-60,000 yen" as the reconciliation source, and "0 yen" and "0 yen" as the reconciliation amount, respectively. In addition, the deposit detail data, which corresponds to the black slip, will have "Bills Receivable" as the payment type, and "+40,000 yen" and "+60,000 yen" as the payment amount, respectively.

[0077] Furthermore, the claims data generation unit 24 generates the deposit transfer details data exemplified in Figure 12 in order to correlate the various data mentioned above. This deposit transfer details data correlates the deposit transfer number, source deposit number, source deposit line number, credit memo destination deposit number, and destination deposit number, respectively, as shown in Figure 10.

[0078] Figure 12 shows an example where the deposit transfer number for "NF001", the source deposit number for "NY001", the source deposit line number for "1", the credit memo transfer destination deposit number for "NY002", and the transfer destination deposit number for "NY003" are interconnected. Also, Figure 12 shows an example where the deposit transfer number for "NF002", the source deposit number for "NY001", the source deposit line number for "1", the credit memo transfer destination deposit number for "NY004", and the transfer destination deposit number for "NY005" are interconnected.

[0079] This type of deposit transfer details data makes it possible to easily and quickly identify the source deposit number and other information corresponding to the deposit transfer number.

[0080] Once the receivables in each accounts receivable management department have been settled, the credit data generation unit 26 updates the outstanding balance of bills of exchange for the receiving department with department code "B000" from "+100,000 yen (see Figure 9)" to "0 yen" as shown in Figure 13. It also updates the credit balance for the receiving department with department code "B000" from "-100,000 yen (see Figure 9)" to "0 yen" as shown in Figure 13.

[0081] Furthermore, the credit data generation unit 26 updates the accounts receivable balance for the accounts receivable management department with department code "B001" from "+40,000 yen (see Figure 9)" to "0 yen" as shown in Figure 13, and also updates the outstanding balance of bills of exchange from "0 yen (see Figure 9)" to "+40,000 yen" as shown in Figure 13.

[0082] Furthermore, the credit data generation unit 26 updates the accounts receivable balance for the accounts receivable management department with department code "B002" from "+60,000 yen (see Figure 9)" to "0 yen" as shown in Figure 13, and also updates the outstanding balance of bills of exchange from "0 yen (see Figure 9)" to "+60,000 yen" as shown in Figure 13.

[0083] This enables proper credit management.

[0084] (Bill management) Next, when the due date for the promissory note arrives, the credit data generation unit 26 updates the outstanding balance of the promissory note for the accounts receivable management department with department code "B001" to "0 yen," as shown in Figure 14, and also resets the credit balance to the credit limit of "50,000 yen."

[0085] Furthermore, when the due date for the promissory note arrives, the credit data generation unit 26 updates the outstanding balance of the promissory note for the accounts receivable management department with department code "B002" to "0 yen," as shown in Figure 14, and also resets the credit balance to the credit limit of "75,000 yen."

[0086] This allows for the generation of accurate credit data for each accounts receivable management department, reflecting the receipt of promissory notes after their due date.

[0087] (Journal entry data creation process) Next, when the promissory note is received (in this example, September 25, 2024), the journal entry data generation unit 25 refers to the input category account master table 14 shown in Figure 3 and generates journal entry data for the receipt of the promissory note for the input department with the department code "B000," as shown in Figure 15(a). In this example, the journal entry data generation unit 25 generates journal entry data for the receipt of the promissory note, with the debit account set to "Notes Receivable" and the debit amount to "100,000 yen," and the credit account set to "Temporary Accounts Received" and the credit amount to "100,000 yen," and stores this journal entry in the journal entry data storage unit 16.

[0088] Furthermore, as shown in Figure 15(b), the journal entry data generation unit 25 generates journal entry data for the input department with the department code "B000" and for the accounts receivable management of the department codes "B001" and "B002".

[0089] In this example, the journal entry data generation unit 25 generates journal entry data corresponding to the aforementioned red slip, with the debit account title set to "Notes Receivable" and the debit amount set to "-40,000 yen," and the credit account title set to "Temporary Receipts" and the credit amount set to "-40,000 yen," and stores this data in the journal entry data storage unit 16. The journal entry data generation unit 25 also generates journal entry data corresponding to the aforementioned black slip, with the debit account title set to "Notes Receivable" and the debit amount set to "+40,000 yen," and the credit account title set to "Accounts Receivable" and the credit amount set to "+40,000 yen," and stores this data in the journal entry data storage unit 16.

[0090] Furthermore, the journal entry data generation unit 25 generates journal entry data corresponding to the aforementioned red slip, with the debit account title set to "Notes Receivable" and the debit amount set to "-60,000 yen," and the credit account title set to "Temporary Receipts" and the credit amount set to "-60,000 yen," and stores this data in the journal entry data storage unit 16. In addition, the journal entry data generation unit 25 generates journal entry data corresponding to the aforementioned black slip, with the debit account title set to "Notes Receivable" and the debit amount set to "+60,000 yen," and the credit account title set to "Accounts Receivable" and the credit amount set to "+40,000 yen," and stores this data in the journal entry data storage unit 16.

[0091] Next, when the due date for the promissory note arrives, the journal entry data generation unit 25 generates a journal entry as shown in Figure 16, with the debit account set to "CASH" and the debit amount to "+100,000 yen", and the credit account set to "Notes Receivable" and the credit amount to "+100,000 yen", and stores it in the journal entry data storage unit 16.

[0092] Furthermore, when the due date for the promissory note arrives, the journal entry data generation unit 25 generates the following journal entry data, as shown in Figure 17: a debit account title of "notes receivable" with a debit amount of "+40,000 yen", a credit account title of "notes receivable" with a credit amount of "+40,000 yen", a debit account title of "notes receivable" with a debit amount of "+60,000 yen", and a credit account title of "notes receivable" with a credit amount of "+60,000 yen", and stores them in the journal entry data storage unit 16.

[0093] The business support device 1 of this embodiment can support accounting operations because it can automatically generate journal entry data detailing the outcome when a bill of exchange is split.

[0094] (Effects of the embodiment) As is clear from the above description, the business support device 1 of the embodiment can prevent the inconvenience of waiting in line for reconciliation work by enabling reconciliation processing for each department, thereby improving the efficiency of operations.

[0095] Furthermore, by splitting payment slips before reconciliation, it becomes possible to manage outstanding amounts for each department, enabling accurate credit management.

[0096] Furthermore, it can automatically generate journal entries detailing the outcome when a promissory note is paid in installments, thereby supporting accounting operations.

[0097] [Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This invention can contribute to improving operational efficiency and promoting appropriate management decisions by companies, and therefore can contribute to SDGs Goals 8 and 9.

[0098] Furthermore, this invention can contribute to reducing waste and promoting paperless and digital processes, thereby contributing to SDGs Goals 12, 13, and 15.

[0099] Furthermore, this invention can contribute to strengthening control and governance, and therefore can contribute to achieving the 16 goals of the SDGs.

[0100] [Other embodiments] The present invention can be implemented in various different forms within the scope of the technical idea described in the claims, even in embodiments other than those described above.

[0101] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically may be performed manually. Alternatively, all or part of the processes described as being performed manually may be performed automatically by known methods or the like.

[0102] Furthermore, unless otherwise specified, the processing procedures, control procedures, specific names, registration data for each process, information including search conditions and other parameters, screen examples, and database configuration shown in the specification or drawings can be changed at will.

[0103] Furthermore, with respect to the business support device 1, each component shown in the diagram is a functional concept and does not necessarily have to have the physical configuration shown. For example, the processing functions of the business support device 1, particularly the processing functions performed by the control unit 3, may be implemented in whole or in any part by a program interpreted and executed by the control unit 3 (CPU: Central Processing Unit), or by hardware using wired logic.

[0104] The program is recorded on a non-temporary, computer-readable recording medium containing programmed instructions for the information processing device to execute the processes described in the embodiment, and is mechanically read by the business support device 1 as needed. In other words, the storage unit 2, such as ROM or HDD, records a computer program that works in cooperation with the OS (Operating System) to give instructions to the control unit 3 (CPU) and perform various processes. This computer program is loaded into RAM, unpacked, and executed by the control unit 3 as appropriate.

[0105] Furthermore, the business support program for this business support device 1 may be stored on another server device connected to the business support device 1 via any network, and all or part of it may be downloaded and executed as needed.

[0106] Furthermore, the business support program for executing the processes described in the embodiment may be stored on a non-temporary computer-readable recording medium, or it may be configured as a program product.

[0107] Here, any "portable physical medium" can be used as the "recording medium," such as memory cards, USB (Universal Serial Bus) memory, 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 Blu-ray (Registered Trademark) Discs.

[0108] Furthermore, "program" refers to a data processing method written in any language or writing method, regardless of whether it is source code or binary code.

[0109] Furthermore, the term "program" is not necessarily limited to a single, monolithic entity, but also includes those that are distributed as multiple modules or libraries, and those that work in cooperation with other programs, such as an operating system, to achieve their functions.

[0110] Furthermore, for the specific configuration, reading procedure, and post-reading installation procedure for the business support device 1 of the embodiment, well-known configurations or procedures can be used.

[0111] The storage unit 2 is a storage means such as memory devices like RAM and ROM, fixed disk devices like hard disks, flexible disks, and optical disks, and stores various programs, tables, databases, and web page files used for various processing or website provision.

[0112] Furthermore, the business support device 1 may be composed of a known personal computer device or an information processing device such as a workstation, or it may be composed of an information processing device to which any peripheral device is connected. In addition, the information processing device may be implemented by implementing software (including programs or data, etc.) that realizes the processing described in the embodiment.

[0113] Furthermore, the specific forms of distribution and integration of the devices are not limited to those shown in the figures, and all or part of them can be configured by functionally or physically distributing or integrating them in any unit according to various additions or functional loads. In other words, the embodiments described above can be selectively implemented by arbitrarily combining the embodiments described above. [Industrial applicability]

[0114] This invention is particularly suitable for use in transfer operations where a single deposit is transferred to multiple recipients. [Explanation of symbols]

[0115] 1 Business support equipment 2 Storage section 3. Control Unit 4. Communication Interface Section 5 Input / Output Interface Section 6 Input devices 7 Output device 11 Credit Data Storage Unit 12. Bills Receivable Data Storage Unit 13. Deposit Data Storage Unit 14 Input Category Account Master Table 15 Account Classification Account Master Table 16. Journal entry data storage unit 21 Acquisition Department 22 Data Generation Unit 23 Display Control Unit 24. Debt Data Generation Department 25. Journal entry data generation unit 26 Credit Data Generation Unit

Claims

1. A business support device that assists in the transfer operation of transferring an amount deposited into a transfer source to multiple transfer destinations, An acquisition unit that divides the deposited amount into the transfer amounts for each of the aforementioned transfer destinations and acquires them, A receivable data generation unit generates receivable data for each transfer destination, where the acquired transfer amount is set as the negative amount of the transfer source and the acquired transfer amount is set as the positive amount of the transfer destination. A business support device having the following features.

2. When payment is made by promissory note with a set payment due date, The acquisition unit acquires the deposited bill amount by dividing it into the transfer amounts of each transfer destination. The aforementioned receivable data generation unit generates a receipt voucher as receivable data, based on the operator's input, with the received bill amount as temporary receipt and the total amount of transfers to each transfer destination as the settled amount. It also generates a red voucher for each transfer destination, with the receivable account category set to temporary receipt and the transfer amount to the transfer destination set to a negative amount for the transfer source, and a black voucher for each transfer destination, with the receivable account category set to accounts receivable and the transfer amount to the transfer destination set to a positive amount for the transfer destination. The business support device according to claim 1, characterized by the following:

3. The system further includes a journal entry data generation unit that generates journal entry data for the aforementioned red memo and journal entry data for the aforementioned black memo, and also generates conclusion journal entry data corresponding to the aforementioned red memo and the aforementioned black memo after the payment due date of the promissory note. The business support device according to claim 2, characterized by the following:

4. The system further includes a credit data generation unit that generates credit data including the credit limit for the transferor and each of the transfer destinations, the outstanding balance of the receivables for each of the transfer destinations, the outstanding balance of promissory notes indicating the balance after settling the outstanding balance of the receivables with the transfer amount using the promissory notes, and the credit balance which is the amount obtained by subtracting the outstanding balance of promissory notes from the credit limit. A business support device according to claim 2 or claim 3, characterized by the above.

5. The credit data generation unit updates the credit balance in the credit data to an amount obtained by subtracting from the credit limit the balance the balance of the claim settled with the transfer amount obtained from the promissory note after the payment due date of the promissory note. The business support device according to claim 4, characterized by the following:

6. A business support method for a business support device that includes an acquisition unit and a debt data generation unit, and supports transfer operations that transfer amounts deposited into a transfer source to multiple transfer destinations, The acquisition unit performs an acquisition step of dividing the deposited amount into the transfer amounts of each transfer destination and acquiring them, The debt data generation unit generates debt data for each transfer destination by setting the acquired transfer amount as a negative amount for the transfer source and the acquired transfer amount as a positive amount for the transfer destination, A business support method that has the following characteristics.

7. Computers, A business support device that assists in the transfer operation of transferring an amount deposited into a transfer source to multiple transfer destinations, An acquisition unit that divides the deposited amount into the transfer amounts for each of the aforementioned transfer destinations and acquires them, A receivable data generation unit generates receivable data for each transfer destination, where the acquired transfer amount is treated as a negative amount for the transfer source and the acquired transfer amount is treated as a positive amount for the transfer destination. A business support program designed to function as such.

Images