JP7482458B2 - Data structure for travel business and accounting processing system using same - Google Patents

Description

The present invention relates to a data structure for travel business and an accounting processing system using the same.

Various accounting systems for travel business have been proposed in the past. The system described in Patent Document 1 is one example. In Patent Document 1, a reservation card (travel product file) showing the reservation details for a trip is created (Figure 7 of Patent Document 1). The reservation card contains sales and purchase information for multiple sales products. Based on this reservation card, accounting for sales, purchases, deposits, and payments is performed at a timing after the sales and purchase reference date (for example, the departure date of the trip). Here, in the example described in Patent Document 1, deposits from customers are treated as advance payments, and payments to suppliers are treated as advance payments (Figure 8 of the same document). If the total amount of sales (total sales amount) in the reservation card exceeds the total amount of advance payments (total advance amount), the difference is automatically recorded as unpaid (Figure 5 of the same document). If the total amount of purchases (total purchase amount) in the reservation card exceeds the total amount of advance payments (total advance amount), the difference is automatically recorded as unpaid (Figure 5 of the same document).

JP 2003-016155 A

According to the system in Patent Document 1, deposits and payments are associated with reservation cards, and unpaid and unpaid amounts are recorded on a reservation card basis only when the reference date for sales and purchases, such as the departure date of a trip, arrives. For this reason, matching of deposits and payments with sales and purchases and evaluation based on this (understanding of unpaid and unpaid amounts, etc.) cannot be performed until the reference date for sales and purchases, and can only be understood on a reservation card basis.

The object of the present invention is to provide a data structure for travel business that makes it easy to perform detailed matching and evaluation of deposits and payments for sales and purchases even before the reference date for those sales and purchases, and an accounting processing system using the same.

The data structure for travel business according to the present invention is a data structure for travel business related to accounting information including information on sales, purchases, deposits, and payments, and includes sales data indicating unit sales, which are sales for each unit reservation, which is one reservation for one supplier, or for each unit that is more detailed than that, purchase data indicating unit purchases, which correspond one-to-one with the unit sales, which are purchases for each unit reservation or for each unit that is more detailed than that, deposit data indicating deposits, payment data indicating payments, deposit allocation data indicating deposit allocations that allocate the deposits indicated by the deposit data to the sales indicated by the sales data for each unit sales, payment allocation data indicating payment allocations that allocate the payments indicated by the payment data to the purchases indicated by the purchase data for each unit purchase, and reference date data indicating the reference dates for the unit sales, the unit purchases, deposits, payments, the deposit allocations, and the payment allocations, and in the reference date data, at least one of the reference dates for the deposit allocations and the payment allocations can be set in the past with respect to the reference date of the unit sales or the unit purchases to which they are allocated.

According to the data structure of the present invention, there is a deposit allocation/payment allocation that links deposits/payments to unit sales/unit purchases for each unit reservation or more detailed units. At least one of the base dates for deposit allocation and payment allocation can be set to a date earlier than the base date of the unit sales or unit purchase to which it is allocated. In other words, regardless of the timing of deposits or payments relative to the base dates of sales or purchases, deposits/payments can be allocated to unit sales/unit purchases while setting a base date earlier than the base date of sales or purchases. This makes it possible to match and evaluate deposits/payments with sales/purchases (for example, grasp unpaid amounts and unpaid amounts) at a timing preceding the base date of sales or purchases. In addition, since the allocation of deposits/purchases is performed for each unit sales/unit purchases, detailed matching and evaluation are possible. In the present invention, "allocation" or "allocation" refers to matching part or all of a deposit to unit sales, or matching part or all of a payment to unit purchases.

The accounting processing system according to the present invention is equipped with a storage means for storing receipt and disbursement data having the above data structure, data indicating credit account items and debit account items for each of the unit sales, the unit purchases, the deposits, the payments, the deposit allocation, and the payment allocation, and a journal processing means for executing journal processing to generate journal entry vouchers for each of the unit sales, the unit purchases, the deposits, the payments, the deposit allocation, and the payment allocation based on the contents stored in the storage means, and the journal processing means is configured to be able to execute the journal processing for each of the deposit allocation and the payment allocation at a timing in the past with respect to the base date of the unit sales or the unit purchase to which the allocation is made.

According to the accounting processing system of the present invention, if a deposit or purchase occurs prior to unit sales or unit purchase, accounting processing can be performed for the deposit allocation or payment allocation related to that deposit or purchase, even if it is before the base date of the unit sales or unit purchase. Therefore, closing processing for deposits and payments and their allocation can be performed early.

In addition, in the present invention, the journal processing means is capable of executing the journal processing for the unit sales, unit purchases, deposits, payments, deposit allocations, and payment allocations indicated by the receipt and disbursement data for each of one or more consecutive journalization dates, for which the reference date indicated by the reference date data corresponds to the journalization date, and executes the first journal processing in which the debit is the credit account item in the journal entry slip for the deposit and the credit is the first account item, and executes the journal processing for the unit sales to which the deposit allocation is assigned. It is preferable to further execute the second journal entry processing in which the debit is the first account item and the credit is the debit account item in the journal entry voucher of the unit sales when the journal entry processing has been performed, and execute the third journal entry processing in which the debit is the credit account item in the journal entry voucher of the payment when the journal entry processing has been performed for the unit purchase to which the payment is to be assigned, and further execute the fourth journal entry processing in which the debit is the first account item and the credit is the debit account item in the journal entry voucher of the unit purchase when the journal entry processing has been performed for the unit purchase to which the payment is to be assigned. According to this, in the journal entry processing for the deposit allocation, the first journal entry processing is performed once regardless of whether the unit sales to which the deposit allocation is assigned have been assigned have been assigned. Then, when it is determined that the journal entry processing for the unit sales has been performed, the second journal entry processing is performed, thereby generating a journal entry voucher that links the deposit and the sales. Also, in the journal entry processing for the payment allocation, the third journal entry processing is performed once regardless of whether the unit purchase to which the payment allocation is assigned has been assigned have been assigned. Then, if it is determined that the unit purchase journalization process has been completed, the fourth journalization process is performed, and a journalization voucher linking the payment and the purchase is output. Therefore, because journalization can be performed regardless of whether the allocation destination has already been journalized, closing processes for deposits and payments and their allocation can be completed quickly.

In addition, in the present invention, it is preferable to evaluate the result of the journal processing by comparing the result of adding up the credit amount and the debit amount included in the journal entry voucher generated from the elements constituting at least one of the first group consisting of the unit sales and the deposit allocation, the second group consisting of the unit purchase and the payment allocation, the third group consisting of the deposit and the deposit allocation, and the fourth group consisting of the payment and the payment allocation, for each account item, with the corresponding unpaid amount, unpaid amount, and unallocated amount indicated by the receipt and disbursement data. According to this, in each of the first to fourth groups consisting of a combination of two accounting information related to each other, when the credit amount and the debit amount generated from the elements constituting each group are added up for each account item, the journal processing can be evaluated based on the journal relationship that the sum corresponds to the unpaid amount, unpaid amount, or unallocated amount obtained from the original accounting information.

In addition, in the present invention, it is preferable to evaluate the result of the journal entry processing based on whether the debit and credit amounts included in the journal entry voucher generated from the deposit allocation for which both the first and second journal entry processing have been executed match for the first account item when the amounts match, and to evaluate the result of the journal entry processing based on whether the debit and credit amounts included in the journal entry voucher generated from the payment allocation for which both the third and fourth journal entry processing have been executed match for the second account item when the amounts match. According to this, for a deposit allocation for which both the first and second journal entry processing have been executed, it is possible to evaluate the journal entry processing based on the journal entry relationship that the debit and credit amounts included in the journal entry voucher generated from this match for the first account item when the amounts match. Furthermore, for payment allocations for which both the third and fourth journal entry processes have already been executed, it is possible to evaluate the journal entry processes based on the journal entry relationship in which the debit and credit amounts included in the journal entry voucher generated from this match when added together for the second account item.

1 is a block diagram showing a configuration of an accounting processing system according to an embodiment of the present invention. 2 is a schematic diagram showing a configuration of a server included in the system of FIG. 1 . Fig. 3(a) is a diagram showing an example of receipt and disbursement data used in the system of Fig. 1. Fig. 3(b) is a diagram showing another example of receipt and disbursement data used in the system of Fig. 1. 2 is a screen for inputting and displaying reservation details, etc. in the accounting processing system of FIG. 1 . This is the screen that is displayed when "Billing" is selected in FIG. This is the screen that is displayed when "Deposit" in FIG. 4 is selected. 2 is a payment reconciliation screen in the system of FIG. 1 . This is the screen that is displayed when "Sell" is selected in FIG. This is the screen that is displayed when "refund/transfer request" is selected in FIG. This is an image that is displayed as part of the screen in FIG. 9 when the processing related to FIG. 9 has progressed. 3 is a table showing the contents of journal entries such as sales in the journal entry process executed by the server of FIG. 2 . 3 is a table showing the contents of accounting for deposits, etc., in the accounting process executed by the server of FIG. 2 . 3 is a table showing the contents of accounting such as deposit allocation in the accounting process executed by the server of FIG. 2 . 3 is a flow diagram showing a main routine of accounting processing related to sales and purchases in the accounting processing executed by the server of FIG. 2. 15 is a flow diagram of a sales and purchase journalizing subroutine called from the main routine of FIG. 14. 15 is a flow diagram of a purchase adjustment journal entry subroutine called from the main routine of FIG. 14. 3 is a flow diagram showing a main routine of the accounting process related to deposits/withdrawals and allocation in the accounting process executed by the server of FIG. 2. FIG. 18 is a flow chart relating to a deposit/withdrawal journalizing subroutine called from the main routine of FIG. 17. 18 is a flow diagram of an allocation journalizing subroutine called from the main routine of FIG. 17. 18 is a flow diagram of an allocation reversal subroutine called from the main routine of FIG. 17. 20 is a flow diagram relating to an additional journalizing subroutine called from the sales/purchase journalizing subroutine of FIG. 15 or the allocation journalizing subroutine of FIG. 19. 3 is a diagram showing a journalization result generated by the journalization process executed by the server of FIG. 2. Fig. 23 is a diagram for explaining an example of evaluation processing of the journalization results executed by the server in Fig. 2. Fig. 23(a) is a schematic diagram showing an example of sales and deposit allocation. Fig. 23(b) is a table showing the results of the journalization processing executed by the server for the sales and deposit allocation in Fig. 23(a). Fig. 23(c) is a table showing the summation results in the evaluation processing executed by the server for the journalization results in Fig. 23(a). FIG. 24 is a diagram for explaining another example of the evaluation process of the journalization results executed by the server in FIG. 2. FIG. 24(a) is a schematic diagram showing an example of deposits and deposit allocations. FIG. 24(b) is a table showing the results of the journalization process executed by the server for the deposits and deposit allocations in FIG. 24(a). FIG. 24(c) is a table showing the summation results in the evaluation process executed by the server for the journalization results in FIG. 24(a).

<System Overview>
An accounting processing system 1 according to an embodiment of the present invention will be described with reference to Figures 1 to 24. The accounting processing system 1 is a system for processing accounting tasks included in travel services. The details will be described below.

As shown in FIG. 1, the accounting system 1 includes a plurality of terminals 100 and a server 200. Data communication is performed between the terminals 100 and the server 200 via the Internet N. Communication between the terminals 100 and the server 200 uses an Internet communication protocol such as HTTP (Hyper Text Transfer Protocol). Both the terminals 100 and the server 200 are constructed with hardware such as a computer and software such as program data stored in a memory device. This software can be distributed by downloading via the Internet or by various recording media. The computer includes hardware such as a CPU (Central Processing Unit), memories such as ROM (Read-Only Memory) and RAM (Random Access Memory), a hard disk drive, and various interfaces such as an input/output interface. In each of the terminals 100 and the server 200, the hardware executes the following communication processing and other processes according to the software. The browser 130 described below is one such piece of software.

As shown in FIG. 2, the server 200 has a memory unit 210 (a memory means in the present invention), a data management unit 220, an accounting processing unit 230, and an accounting evaluation unit 240. The memory unit 210 stores information indicating the reservation contents for the trip transmitted from the terminal 100, accounting information related to the reservation contents, etc. The reservation contents include the types of trips such as arranged trips, packaged trips, and commissioned trips. Arranged trips are trips that require reservations of air tickets, accommodation, trains, etc. to be made with a supplier according to the travel contents such as the travel destination and schedule desired by the traveler. Packaged trips are trips in which the travel destination and schedule are set in advance, and reservations of air tickets, accommodation, trains, etc. are also set in advance. Commissioned trips are trips related to products of other companies. The reservation contents are stored in the memory unit 210 as reservation data 420 while being organized into units of reservation cards consisting of a collection of information for each trip. The reservation card is a unit of information for managing a series of operations from receiving a travel application to completing the trip, and is also called a chart. Each reservation card contains multiple unit reservations, which are one reservation with one supplier. A unit reservation corresponds to a single reservation action made by a reservation clerk with a supplier. A single reservation number is assigned to this unit reservation by the supplier.

The accounting information is stored in the memory unit 210 as receipt and disbursement data 400. The receipt and disbursement data 400 includes sales and purchase data 410 indicating the travel fare, receipt and disbursement data 430 indicating receipts and disbursements, allocation data 440 relating the travel fare to receipts and disbursements, and invoice data 450 indicating the contents of the invoice.

The sales data 410 includes sales data 411 indicating sales billed to customers (travelers, etc.), purchase data 412 indicating purchases billed from suppliers, and purchase adjustment data 413 indicating purchase adjustment amounts. The sales data 411 indicates sales details consisting of multiple sales items (corresponding to unit sales in the present invention). The sales data 411 includes data indicating the tax category and tax rate of each sales item. The tax category indicates whether it corresponds to "taxable", "non-taxable", "non-taxable", or "tax-free". The sales data 411 also includes data indicating the sales date as the base date for each sales item (base date data in the present invention). The "sales date" in this embodiment corresponds to the accounting date for sales. Accounting determines what date must be the accounting date for each type of travel (arranged travel or packaged travel, etc.) and service. In this accounting processing system 1, the sales date is also set based on such accounting standards. Furthermore, the sales data 411 includes data indicating the sales destination.

The purchase data 412 shows a purchase detail consisting of a plurality of purchase items (corresponding to unit purchases in the present invention) corresponding to a plurality of sales items. The purchase data 412 includes data indicating the tax category and tax rate for each purchase item. The tax category indicates whether it corresponds to "taxable", "non-taxable", "non-taxable", or "tax exempt". The purchase data 412 also includes data indicating the base date for each purchase item. The sales items and purchase items are items related to travel fares per unit reservation or per more detailed unit, and have a one-to-one correspondence with each other. The base date for the purchase item coincides with the sales date. Furthermore, the purchase data 412 includes data indicating the supplier.

Purchase adjustment data 413 corresponds to one of the purchase items, and is generated when a purchase amount adjustment is performed for that purchase item. As described below, the purchase amount adjustment is performed to match the adjusted purchase amount with the payment amount when the payment amount is changed from the original purchase amount due to exchange rate fluctuations, etc.

The deposit/withdrawal data 430 indicates deposits and withdrawals made in accordance with invoices issued for travel fares. In this embodiment, deposits and withdrawals are made in various ways, such as cash and bank transfers. In addition, there may be multiple transfer accounts used for deposits and withdrawals, such as a different account being used for each department in the travel agency. In this embodiment, a "deposit/withdrawal type" is used to distinguish the type of deposit/withdrawal and the transfer account. The deposit/withdrawal type indicates, for example, whether the deposit/withdrawal is made in cash or by bank transfer, and also indicates which account was used for deposits by transfer.

Deposits and withdrawals include deposits from customers and payments to suppliers. Deposit and withdrawal data 430 includes deposit data 431 indicating the contents of the deposit and payment data 432 indicating the contents of the payment. In this embodiment, "deposit" generally refers to the receipt of travel fees corresponding to sales from a customer or the fees received. When the deposit amount indicated by deposit data 431 is a positive value, it indicates a deposit from such a customer. When the deposit amount indicated by deposit data 431 is a negative value, it indicates that a refund has been made to the customer. A refund is a process that returns the excess amount when a deposit is made that exceeds the amount of the invoice. In addition, as described below, when an excess deposit occurs, a transfer can be performed instead of a refund. The transfer of a deposit in this embodiment is a process that allocates the excess amount of the deposit to an invoice for a reservation card different from the reservation card corresponding to the original invoice, according to the intention of the depositor. Deposit data 431 includes data indicating the deposit date as the base date for each deposit, the deposit/withdrawal type, and the deposit source (corresponding to the base date data in this invention). In principle, the deposit date corresponds to the day on which the deposit was made. The source of the deposit indicates the name of the individual or company that made the deposit.

In this embodiment, "payment" refers to paying travel fees related to procurement to a supplier, or the amount paid. Payment data 432 indicates the amount paid to such a supplier and the payment date as the base date (corresponding to the base date data in this invention). Payment data 432 also includes data indicating the type of deposit/withdrawal and the payee. The payee indicates the name of the corporation to which the payment is made. The payee corresponds to the supplier of the supplier to which the payment corresponds.

The allocation data 440 is data that associates the sales and purchase data 410 and the cash inflow and outflow data 430. As described above, the deposit corresponds to sales, and the payment corresponds to purchase. The allocation data 440 shows these correspondences on a sales item basis or a purchase item basis. In this embodiment, "allocation" refers to allocating (associating) a part or all of the deposit to a sales statement, or allocating (associating) a part or all of the payment to a purchase statement. In addition, the deposit or payment and the sales or purchase that are associated with each other by the allocation data 440 are referred to as the "source of allocation" and the latter as the "destination of allocation". In the following explanation, allocation may be expressed as "allocation". For example, allocation corresponds to the clearing work of matching the deposit with an invoice and crossing it out in the conventional accounting. The allocation data 440 includes data indicating the base date for each allocation (base date data in this invention). This base date usually coincides with the deposit date or payment date of the corresponding deposit or payment. Both the receipt date and the payment date can be in the past compared to the sales date. Therefore, the allocation base date can also be in the past compared to the base date of the sales or purchase of the allocation destination.

Invoice data 450 is data showing the contents of an invoice issued to a customer. Each invoice consists of multiple billing items as billing details. Each billing item corresponds to a sales item. Invoice data 450 includes data showing the billing destination and the billing amount for each billing item, as well as data showing the correspondence between each sales item shown in sales data 411 and each billing item. The billing amount shown in invoice data 450 can be a positive value or a negative value. The former corresponds to the case where a payment is made from the customer in response to the invoice, and the latter corresponds to the case where a refund is made to the customer in response to the invoice.

Figure 3 shows an example of receipt and disbursement data 400. Figure 3(a) shows the amounts and reference dates indicated by each piece of data: invoice data 450, sales data 411, allocation data 440, and deposit data 431. Each item in sales data 411 corresponds to each sales item. In the figure, these items are arranged according to the reference date of each data. The straight lines connecting the sales items, allocation, and deposit items show the association between the sales items and deposits by allocation.

In this embodiment, as described below, accounting processing is performed on items to be closed on each closing date (for example, the end of each month). The thick lines in Figure 3(a), consisting of solid lines, dashed lines, dashed lines, etc., represent the boundaries of items to be closed when the closing date is set to the end of July, August, September, October, November, and December, respectively. In other words, each line indicates that the items placed above it that have not yet been closed are to be closed on the closing date of that line.

Figure 3(b) shows the amounts and base dates shown by each data such as invoice data 450 when the allocation is changed for the deposit after the journalization process. The straight lines connecting the sales items, allocation, and deposit items show the association between the sales items and the deposit by allocation. In the example of Figure 3(b), the contents of two items dated 9/30 in the allocation data 440, for which the journalization process was completed at the end of September, are updated. Specifically, in the allocation data 440, the item that allocates the 2,000 yen deposit dated 9/30 to the sales item of 1,000 yen dated 9/1 and the sales item of 2,000 yen dated 9/5, each of 1,000 yen on 9/30, has been changed to 0 yen on 10/1. This is the result of a process that changes the contents of the allocation after the journalization process when it becomes necessary to change the allocation due to a change in the invoice amount, etc., after the journalization process, as described later. Hereinafter, such a process will be referred to as "VOID processing". In addition, a new allocation has been generated on 10/1 to allocate the 2,000 yen received on 9/30 to the 2,000 yen on 9/15, which is a new sales item that was generated due to changes in the billing amount, etc.

The storage unit 210 also stores journal entry method data 460 and journal entry result data 470. The journal entry method data 460 is data that indicates the method of journal entry processing. Journal entry information generated in accordance with the journal entry method data 460 is stored in the storage unit 210 as journal entry result data 470. Details of the journal entry method data 460 and the journal entry result data 470 will be described later.

The data management unit 220 generates receipt and disbursement data 400, reservation data 420, etc. based on various information received from the terminal 100, and stores them in the storage unit 210. For example, the data management unit 220 receives reservation information indicating the reservation contents for each unit reservation from the terminal 100. Such information is input for each unit reservation through the reservation image area 320 of the screen IMI 300 of FIG. 4, as described later. The data management unit 220 generates reservation data 420 indicating information such as the reservation status, PAX, flight information, etc., sent from the terminal 100, and stores it in the storage unit 210. The data management unit 220 also receives information regarding sales and purchases for each unit reservation from the terminal 100. Such information is input for each unit reservation through the sales and purchase information area 330 of the screen IMI 300 of FIG. 4, as described later. The data management unit 220 generates sales and purchase data 410 based on this, and stores it in the storage unit 210. The data management unit 220 also receives information indicating the contents of deposits and withdrawals (see Figures 6, 7, and 10) from the terminal 100, as described below, and generates deposit and withdrawal data 430 based on this, which is stored in the memory unit 210. The data management unit 220 also receives information indicating the contents of an invoice from the terminal 100. Such information is entered through the screen IMI20 in Figure 5, as described below. The data management unit 220 generates invoice data 450 indicating the information sent from the terminal 100, and stores it in the memory unit 210.

The data management unit 220 generates allocation data 440 based on the allocation content input through the screen IMI30 of FIG. 6 and the screen IMI50 of FIG. 7, etc., as described below, and stores the data in the storage unit 210. The method of generating allocation data 440 is as follows. For example, when allocating a deposit, the data management unit 220 allocates the deposit among the unallocated sales items in order of the oldest sales date. In other words, the data management unit 220 executes the following in order from the sales item with the oldest sales date to the sales item with the newest sales date. (1) If the unpaid amount in a sales item is equal to or greater than the unallocated deposit, the entire amount is allocated to that sales item. Also, (2) If the amount of a sales item is less than the unallocated deposit, the amount of the unallocated deposit is allocated to that sales item, and the remaining amount excluding the allocated amount is allocated to the next sales item and onwards. For the allocation of the next sales item and onwards, the above (1) and (2) are repeated.

As a result, in the example of Figure 3(a), the 2,000 yen deposit dated 7/1 is allocated to the sales item dated 9/1 and the sales item dated 9/5 in the amount of 1,000 yen each. In this way, since the sales item dated 9/1 is less than the deposit dated 7/1 and the sum of the sales item dated 9/1 and the sales item dated 9/5 is greater than or equal to the deposit dated 7/1, the above process (2) is executed, and the entire amount of the deposit dated 7/1 is allocated to the two sales items dated 9/1 and 9/5. However, since the sales item dated 9/5 is 2,000 yen, if 1,000 yen is allocated to it, then 1,000 yen corresponding to the unpaid amount for this sales item will be generated at this point.

After that, as shown in FIG. 3(a), a deposit of 3,000 yen is made on 8/15 for this invoice, and the deposit and allocation are entered through the screen IMI 30 as described above. The data management unit 220 allocates the deposit of 3,000 yen as described in (1) and (2) above. As a result, 1,000 yen of the deposit of 3,000 yen is allocated to the sales item dated 9/5, which had a balance of 1,000 yen, and 2,000 yen of the deposit of 3,000 yen is allocated to the sales item dated 9/15. In this way, since the sales item dated 9/5 is less than the deposit dated 8/15 and the sum of the sales item dated 9/5 and the sales item dated 9/15 is greater than or equal to the deposit dated 8/15, the process described in (2) above is executed, and the entire amount of the deposit dated 8/15 is allocated to the two sales items dated 9/5 and 9/15. The same allocation will be carried out for the deposit made on November 1st.

The data management unit 220 generates allocation data 440 as shown in FIG. 3(a) for each deposit, according to the details of the allocation. Each allocation item in the allocation data 440 indicates the association between each sales item and the deposit, the amount allocated, and has the same date as the date of the deposit.

Regarding the allocation of payments, the data management unit 220 generates allocation data 440 based on the details entered by the accounting staff or the like via the screen IMI50. This allows payments to be allocated to each purchase item in the same way as payments are allocated to each sales item. The data management unit 220 generates allocation data 440 according to the details of such allocation. Each allocation item in the allocation data 440 indicates the association between each purchase item and payment, the amount allocated, and has the same date as the date of payment.

The data management unit 220 also calculates the unpaid amount and the unpaid amount based on the results of the above allocation. Specifically, the data management unit 220 determines the unpaid amount by subtracting the amount of the deposit allocated to each sales item from the amount of sales for that sales item. If the unpaid amount is 0 yen, the data management unit 220 determines that the deposit has been completed for that sales item. The data management unit 220 also calculates the unpaid amount by subtracting the amount of the payment allocated to each purchase item from the amount of purchases for that item. If the unpaid amount is 0 yen, the data management unit 220 determines that payment has been completed for that purchase item.

In addition, the data management unit 220 processes the receipt and disbursement data 400 in response to changes in the invoice amount, etc., made to deposits after the journalization processing by the journalization processing unit 230, as described below. Specifically, as shown in the example of FIG. 3(b) above, a VOID process is executed to change the contents of the data indicating the post-journalization allocation (1,000 yen each dated 9/30 as shown in FIG. 3(b)) corresponding to the change in the invoice amount, etc., in the allocation data 440 to 0 yen on a date after the journalization processing date. In addition, new sales (2,000 yen dated 9/15 as shown in FIG. 3(b)) are generated in response to the change in the invoice amount, and a new allocation (2,000 yen dated 10/1 as shown in FIG. 3(b)) to which the deposit is allocated is generated.

The journal processing unit 230 executes journal processing for the accounting information indicated by the receipt and disbursement data 400 according to the journal method data 460 in the storage unit 210, and generates journal result data 470 indicating the results. The journal result data 470 indicates the contents of each journal voucher, as well as the association between each of the items of sales items, purchase items, purchase adjustment amounts, deposits, payments, and allocations in the receipt and disbursement data 400 that became the original data of the journal voucher and each journal voucher. The generated journal result data 470 is stored in the storage unit 210. The journal evaluation unit 240 evaluates whether the accounting information such as sales and deposits indicated by the receipt and disbursement data 400 is consistent with the journal result indicated by the journal result data 470 in the storage unit 210. Details of the processing by the journal processing unit 230 and the journal evaluation unit 240 will be described later.

As other processes, the server 200 generates programs and various data written in HTML (HyperText Markup Language) that instruct the processes to be executed by the terminal 100 based on the functions of the browser 130, and transmits them to the terminal 100. In addition, the server 200 transmits data such as the contents stored in the memory unit 210 to the terminal 100 in response to a request received from the terminal 100.

The terminal 100 may be a notebook or desktop personal computer, a tablet terminal, a smartphone, or the like. A display 110 for displaying information is connected to or mounted on the terminal 100. A printing device 140 such as a printer for recording on paper media is also connected to the terminal 100. Furthermore, one or more input devices 120 such as a pointing device such as a mouse, a touchpad or a touch panel display, and a keyboard are connected to or mounted on the terminal 100. By using the input device 120, a user can select and operate various control images in a graphical user interface (GUI) image described below, and input text into a selected control image.

A web browser application (hereinafter referred to as "browser 130") is installed in the terminal 100. The browser 130 causes the terminal 100 to execute the following various processes based on data sent from the server 200. For example, the terminal 100 displays GUI images shown in Figures 4 to 8 on the display 110 to allow the user to input reservation details, sales and purchase details, etc. related to travel through the input device 120. The terminal 100 also transmits the details input through the GUI images to the server 200, and requests information required for various processes, such as information to be displayed on the GUI images, from the server 200. Such GUI images include a login image (not shown). Travel agency employees can start using the system by entering their ID and password into the login image using the login ID assigned to them. The login ID has authority set according to the user's job responsibilities.

<GUI in Terminal>
Various processes through GUI images in the terminal 100 will be described below. IMI 300 shown in Fig. 4 is a GUI image of a main screen for inputting and viewing information about one reservation card. The input and viewing of such information is mainly performed by the person in charge of reservation operations using the login ID to the system assigned to him/her. Note that the general manager of operations and the person in charge of operations other than reservation operations may input and view information using the login ID assigned to him/her.

IMI300 corresponds to one reservation card selected or newly created through another GUI image (not shown) for selecting or creating a new reservation card. In such another GUI image, the screen display of IMI300 is instructed by user input using the input device 120, and IMI300 is displayed on the display 110. IMI300 includes a card basic area (not shown) for inputting basic information and travel information (travel period, destination, traveler's name, contact information, etc.) for the reservation card, a main area 370 for inputting reservation details, and a menu area 380 including a menu control image for displaying a GUI image different from the main screen and a display column for displaying sales and purchase information for the entire reservation card. Of these areas, the main area 370 is displayed vertically on the screen of the display 110 (hereinafter referred to as the "vertical screen direction"). In many cases, the main area 370 cannot be displayed on a single screen, so the display contents are scrolled vertically by using the input device 120 to operate a scroll bar control image (not shown) displayed on the right side of the IMI 300 or by operating a mouse button. This causes information and input areas in each part of the main area 370 to be displayed on the screen in sequence. Meanwhile, the menu area 380 does not follow the scrolling of the main area 370, but remains in a specified position on the left side of the IMI 300.

The main area 370 includes one or more trip-specific areas 350. The trip-specific areas 350 are areas for each type of trip, such as arranged trips, packaged trips, and commissioned trips. The trip-specific area 350 for which the main area 370 is to be displayed is specified when an instruction to display the IMI 300 screen is given by user input using the input device 120, as described above. In this embodiment, the trip-specific area 350 for arranged trips is mainly described as an example, but the configuration of the trip-specific area 350 for arranged trips in the following description can also be applied to the trip-specific area 350 for packaged trips and commissioned trips.

In the main area 370, one or more trip-specific areas 350 are displayed in a line in the vertical direction of the screen. These are displayed so that they can be scrolled in the vertical direction of the screen as described above. As shown in FIG. 4, each trip-specific area 350 includes one or more arrangement input image areas 310. The arrangement input image area 310 is an area for inputting specific information such as reservation contents. Each arrangement input image area 310 corresponds to each unit reservation. Services related to the contents input in the arrangement input image area 310 include overseas air, domestic air, hotel, ship, rental car, railway, travel documents, insurance, etc. In the trip-specific area 350, an area is divided in the vertical direction of the screen for each service, and in each area for each service, the arrangement input image area 310 related to that service is displayed continuously in the vertical direction of the screen. In the trip-specific area 350 related to the arranged trip, a control image 311 for adding the arrangement input image area 310 is displayed at the bottom of the arrangement input image area 310 related to each service. By selecting each control image 311 using the input device 120, the arrangement input image area 310 related to the corresponding service is added to the bottom. The entire arrangement input image area 310 is displayed so that it can be scrolled vertically on the screen as described above.

Each arrangement input image area 310 related to arranged travel is an image area for inputting reservation details, etc. The arrangement input image area 310 includes a reservation image area 320 and a sales/purchase information area 330.

The reservation image area 320 is an area where the user inputs reservation details and displays the input results. The reservation image area 320 includes a basic arrangement area 321, a reservation details area 322, and a customer list area 323, which are aligned vertically on the screen. The sales/purchase information area 330 is located to the right of the customer list area 323. Of these, the basic arrangement area 321 includes common content regardless of the type of service, and includes a control image that allows the user to input information such as reservation status, PAX information, arrangement deadline, and person in charge, and displays the input results.

The reservation content area 322 includes different contents for each service, and includes control images for inputting and displaying specific information of the reservation contents. For example, in the case of an air service such as overseas air, such specific information includes a PNR (passenger name record) including one reservation number (or confirmation number) assigned by a supplier, flight information of the reserved flight (flight name, departure date, departure point, arrival point, departure and arrival time, seat class, number of seats, etc.), mileage card number, ticket number, etc., as shown in FIG. 4. The reservation content area 322 includes one or more control images and their item names for inputting dates. Such items include, for example, the issuance date of an air ticket or a train ticket, the start and end dates of a stay period, the start and end dates of use of a ship or a rental car, etc. In the arrangement input image area 310 for each service, the above-mentioned date items included in the reservation content area 322 always include an item corresponding to the sales date of the trip related to that service. And the item name corresponding to the sales date is displayed in a manner that is visually distinguishable from other item names. The arrangement input image area 310 in FIG. 4 includes, as an example, a date input field C1 for inputting the ticket issuance deadline date and its item name C2 "Ticket Issuance Deadline", and a date input field C3 for inputting the ticket issuance date, which is the sales date, and its item name C4 "Ticket Issue Date". Of these, the item name C4 is underlined in a wavy manner, and is displayed in a manner that is visually distinguishable from the item names in the other fields. As an example of such a manner, for example, the characters indicating the item name of the sales date may be in a different color, size, or thickness from the other item names, or may be underlined or surrounded. As shown in this example, the sales date corresponds to a date in the future at the time of information input in the reservation details area 322. The user list area 323 is an area that displays a list of users of the service. Users included in the user list are travelers indicated by the PAX information input in the arrangement basic area 321, among the travelers indicated by the traveler information input in the card basic area described above.

The information entered in the reservation image area 320 is transmitted from the terminal 100 to the server 200. Based on this, the data management unit 220 generates reservation data 420 as described above. Such reservation data 420 includes data indicating each piece of information entered in the reservation image area 320.

The sales and purchase information area 330 contains common content regardless of the type of service, and includes a control image that allows the user to input sales and purchase details for one or more sales items corresponding to the reservation details, and displays the input results. The sales details include the name, label, PAX information, sales price, and quantity of each sales item. The name of the sales item is input by selecting one from a pre-set name list using the input device 120. Other sales details are input for each sales item. PAX information and quantity are automatically input based on the PAX information input in the basic arrangement area 321. Of these, the PAX information can be changed for each sales item. The quantity indicates the number of people corresponding to the PAX information and cannot be changed. The purchase details include the purchase currency, purchase price, and supplier as purchase items that correspond one-to-one to the sales items. The sales and purchase information area 330 also includes a control image C5 for date input. When a date is entered in the date input field C3 of the reservation content area 322, that date is automatically entered in the date input field C5 of the sales and purchase information area 330. When sales and purchase details are entered, the top of the sales and purchase information area 330 displays the total amount obtained by multiplying the sales price by the quantity for the entered sales details, and also displays the total amount obtained by multiplying the purchase price by the quantity for the entered purchase details.

The information entered in the sales/purchase information area 330 is sent from the terminal 100 to the server 200. Based on this, the data management unit 220 generates sales/purchase data 410 as described above. In the sales/purchase data 410, sales data 411 includes information on each sales item entered in the sales/purchase information area 330, that is, data indicating the name, label, PAX information, sales price, and quantity of the sales item. In the sales/purchase data 410, purchase data 412 includes information on each purchase item entered in the sales/purchase information area 330, that is, data indicating the purchase currency, purchase price, and supplier.

The menu area 380 includes a menu control area 381 including multiple control images for selecting various processes, and a total area 382 that displays the total amount of sales and other amounts for the entire reservation card. The control images included in the menu control area 381 include a control image C10 for returning to the screen display of the IMI 300 from a state in which another screen is displayed, a control image C11 for opening a sales details screen, a control image C12 for opening a billing details screen, and a control image C13 for opening a deposit screen. When any of the control images C11 to C13 is selected, a GUI image for displaying and inputting various information, such as a sales and purchase input screen, is displayed on the display 110, as described below. The information displayed and input in these GUI images is associated with the reservation card information displayed in the main area 370 and stored in the memory unit 210 of the server 200.

When the control image C12 is selected using the input device 120 in the menu area 380, as shown in FIG. 5, screen IMI20 (the billing details screen) consisting of a GUI image related to invoice issuance is displayed on the display 110. It is assumed that the invoice issuance work through screen IMI20 will mainly be performed by a person in charge of reservations. In screen IMI20, the expected date of payment, the currency of the invoice amount, etc. can be entered as invoice contents using the input device 120, and the contents of multiple invoice items (for example, invoice items C21 to C23 in FIG. 6) can be entered as invoice details. Each invoice item corresponds to a sales item in the arrangement input image area 310. The contents of such invoice items are automatically entered according to the contents entered in the arrangement input image area 310.

For example, in the billing item C21 of FIG. 5, "Domestic Air Ticket" is displayed in the "Printing Item" column according to the contents entered in the arrangement input image area 310 for domestic air. "1" is displayed in the "PAX" column, and "Taxable" is displayed in the "Tax Classification". For sales items that are not taxed, either "Non-taxable", "Non-taxable", or "Tax-free" is displayed. In the example of FIG. 5, "Non-taxable" is displayed. 10% is displayed in the "Tax Rate" column. "1,000" is displayed in the "Unit Price" column. "1" is displayed in the "Quantity" column. The default values displayed in "Unit Price" and "Quantity" correspond to the "Unit Price" and "Quantity" of each sales item entered in the arrangement input image area 310. The "Amount" column displays the amount obtained by multiplying the "Unit Price" and "Quantity". The "Tax Included" column displays the amount "90" according to the "Tax Rate", "Unit Price", and "Quantity". The "Billing Amount" column displays "1,000" according to the "Amount". The "Unbilled Amount" column displays the amount for which no invoice has been issued in the past, "1,000." If an invoice has been issued in the past, the amount displayed is the amount for which that invoice has been issued minus the amount displayed in the "Amount" column.

Of the above, the input contents of each of the "Print Item", "Tax Rate", "Unit Price", and "Billing Amount" columns can be changed using the input device 120. However, the value of "Billing Amount" can be changed as long as it does not exceed the value entered in the arrangement input image area 310. Furthermore, for "Unit Price", an amount exceeding the value entered in the arrangement input image area 310 can be entered, as long as the total amount obtained by multiplying this by the "Quantity" for all invoice items matches the total "Billing Amount". Furthermore, the "Tax Rate" can be selected from preset values. The "Summary" column can be entered using the input device 120 as necessary.

Similarly, invoice items C22 are displayed according to the content entered in the hotel-related arrangements input image area 310, and the content of each item can be changed as necessary. Invoice items C23 are displayed according to the content entered in the railway-related arrangements input image area 310, and the content of each item can be changed as necessary.

The control image C26 placed at the beginning of each invoice item can be selectively set to an unchecked state or a checked state, and the state is switched by selection using the input device 120. When at least one of the control images is in a checked state, if the control image C24 is selected using the input device 120, the contents entered on the screen IMI20 are sent from the terminal 100 to the server 200. Based on this, as described above, the data management unit 220 generates invoice data 450 showing an invoice including the contents of the checked invoice items as invoice details. Such invoice data 450 includes data showing the unit price, quantity, tax rate, etc. for each invoice item, and data showing which sales item each invoice item corresponds to. In addition, the invoice is printed by the printing device 140 connected to the terminal 100. The invoice issued in this way is handed over or sent to the customer by, for example, a person in charge of reservation operations. On the other hand, when the control image C25 is selected, the issuance of the invoice through the screen IMI20 is canceled.

In the menu area 380 in FIG. 4, when the control image C13 is clicked using the input device 120, a screen IMI30 (the deposit screen described above) consisting of a GUI image relating to deposits and their cancellation, an example of which is shown in FIG. 6, is displayed on the display 110. There are various ways in which deposits are made from customers, such as when the person in charge of reservations directly receives cash from the customer at the counter, when the payment is accepted by credit card, or when the payment is made by transfer to a bank account. When the person in charge of reservations accepts the payment at the counter, the deposit from the customer is entered through the screen IMI30. As described below, the deposit details can be entered into each input field on the screen IMI30 using the input device 120, and the deposit can be cancelled by allocating it against the amount due on the invoice.

Screen IMI30 includes an area 30a for inputting the details of the deposit, and an area 30b showing the allocation status of the deposit to the invoice. Area 30a includes a control image C37 that can be selectively set to a planned state or a confirmed state. By default, the control image C37 is in the planned state (the state shown in FIG. 6). In this state, the deposit details are input and allocation operations are performed as follows. After the deposit details have been input and allocation operations have been performed, when "Confirm" is selected in the control image C37 using the input device 120, the control image C37 takes the confirmed state and the entered deposit details are confirmed.

Area 30a includes control images for inputting the amount of the deposit, the slip number, the date of the deposit, information about the person in charge of accepting the deposit, and the like. For example, the date of the deposit is input in the "Deposit Date" input field C31. The amount of the deposit is input in the "Deposit Amount" input field C32. Area 30b includes display fields for characters and numbers indicating the allocation status. For example, the "Unallocated Amount" display field C33 displays the amount in the input field C32 that has not yet been allocated. To the right of the display field C33 is a control image C38 for the "Refund/Transfer Request" button. The control image C38 can be selected using the input device 120 when the amount in the display field C33 is not 0 yen (when an unallocated amount has occurred). When the control image C38 is selected, a screen IMI60, described below, related to the refund/transfer process is displayed.

At the bottom of the area 30b, invoices issued within the same reservation card are displayed as a list. In the display column C34 of each invoice, the "billing amount", "unpaid amount", "allocation amount", etc. are displayed before the amount in the "unallocated amount" display column C33 is subtracted. The display column C34 includes a "allocation" control image C35 and a "cancellation" control image C36. When the control image C35 corresponding to any of the invoices is selected using the input device 120, information indicating the selected invoice is sent to the server 200. The data management unit 220 of the server 200 allocates the unallocated amount displayed in the display column C33 to the invoice based on the information sent from the terminal 100. For example, if the billing amount of the invoice is equal to or greater than the unallocated amount, the entire unallocated amount is allocated to the invoice. On the other hand, if the billing amount of the invoice is less than the unallocated amount, the portion of the unallocated amount equivalent to the billing amount is allocated to the invoice. Specifically, the allocation is performed for the sales items corresponding to each billing item included in the invoice. Details of this allocation will be described later. Depending on the content of the allocation, the amount in display field C33 and the outstanding amount and allocated amount in display field C34 are updated. When a list of multiple invoices is displayed in area 30b, the above allocation can be performed across multiple invoices to allocate any deposit that exceeds the total amount claimed for one invoice. When control image C36 is selected using input device 120, the allocation is canceled and the amount display in display fields C33 and C34 is returned to the state before allocation.

After the deposit details have been entered and the allocation operation has been performed as described above, when control image C37 is selected, the deposit and allocation details are finalized as described above. It is possible to finalize the deposit and allocation details when the total of the allocated amounts is lower than the deposit amount in input field C32. In this case, an unallocated amount will remain for the entered deposit. The finalized deposit and allocation details are sent from terminal 100 to server 200. Based on this, as described above, data management unit 220 generates deposit/withdrawal data 430 and also generates allocation data 440 indicating the allocation details.

The settlement of payments for purchases is mainly performed by the accounting staff based on invoices from suppliers or by manually entering information regarding payments. The screen IMI50 shown in FIG. 7 is used when the settlement is performed based on invoices from suppliers. The screen IMI50 is displayed on the display 110 as a result of selecting any item in the details of the supplier invoice based on user input using the input device 120 after importing a data file of an invoice from a supplier into the accounting processing system 1 through another GUI image (not shown). The server 200 searches for a purchase item that is a candidate for settlement of the payment related to the invoice from the purchase items indicated by the purchase data 412 stored in the storage unit 210 based on the supplier information, invoice amount, etc. indicated by the imported invoice data. The purchase items to be searched correspond to those entered in the sales and purchase information area 330 of the arrangement input image area 310. The search range also covers multiple purchase items across multiple reservation cards. Based on the search results, the screen IMI50 displays purchase items C51 to C53 (only a part of which is shown in the example) that are candidates for clearing. Each of the purchase items C51 to C53 includes a display field for the corresponding appointment card number, the corresponding service, the corresponding sales item name, the scheduled payment date, correction (check box), the adjustment amount, its details, and the unpaid amount. Of these, the adjustment amount and its details are displayed as is for each purchase item that is a candidate for clearing, as shown in FIG. 7, if the correction check box is not checked. The case where the correction check box is checked will be described later. The unpaid amount indicates the unpaid amount relative to the adjustment amount calculated by the data management unit 220. To the right of the display field for the unpaid amount are control images C54 to C56 for inputting the allocation amount. The control images C54 to C56 have the amount corresponding to the unpaid amount input by default. These contents can be changed using the input device 120. Above the control images C54 to C56, a display field C57 is arranged to display the amount corresponding to the total of the allocation amounts indicated by these input contents. When the "Execute allocation" control image C54 arranged at the top of the screen IMI50 is selected using the input device 120, the payment allocation is executed for each purchase item according to the allocation amount entered in the control images C54 to C56. When the allocation amount entered in the control images C54 to C56 matches the total purchase amount of each purchase item (as shown in FIG. 7), the allocation is executed without checking the correction check box. On the other hand, when the allocation amount does not match the total purchase amount due to fluctuations in the currency rate, etc., the accounting processing system 1 automatically adjusts the purchase contents when the correction check box is checked. Then, the payment allocation is executed for the total purchase amount after the adjustment. For example, suppose that the original purchase contents of a certain purchase item are unit price 101 yen and quantity 2 (i.e., a total of 202 yen), and the allocation amount is entered as 205 yen. In this case, when the correction checkbox is checked, the purchase details are adjusted by adding 1 yen to the unit price to 102 yen, and one purchase item with a unit price of 1 yen and quantity of 1 is added. This results in (original unit price 101 yen + added unit price 1 yen) * quantity 2 + added purchase item 1 yen = 205 yen. In other words, the purchase details are adjusted to match the allocation amount. Note that the addition of a purchase item as described above is only performed when the purchase details do not match the allocation amount after only adjusting the unit price. Then, the allocation amount of 205 yen is applied to the adjusted purchase details (total of 205 yen). The allocation details for such payments and purchases and the adjustment amount for the purchase details are transmitted from the terminal 100 to the server 200. Based on this, as described above, the data management unit 220 generates purchase data 412 corresponding to the added purchase item (in the above example, 1 yen was added as a purchase item) and purchase adjustment data 413 indicating the adjustment amount of the unit price (in the above example, 1 yen was added as a unit price), generates deposit/withdrawal data 430 (payment data 432), and generates allocation data 440 indicating the details of the allocation.

When manually entering payment information, the accounting staff enters the payment amount, the purchase to which the payment is to be allocated, the allocation amount, etc., through a GUI image (not shown) separate from the screen IMI50. The entered payment and allocation details are sent from the terminal 100 to the server 200. Based on this, as described above, the data management unit 220 generates deposit/withdrawal data 430 (payment data 432) and also generates allocation data 440 indicating the allocation details.

Screen IMI40 shown in FIG. 8 is an example of an image for displaying details of sales and purchases. Screen IMI40 corresponds to the sales and purchases for one sales item entered in one of the arrangement input image areas 310. Screen IMI40 is displayed by selecting control image C11 (see FIG. 4) using input device 120 in menu area 380 in FIG. 4, and then selecting one item corresponding to one sales item entered in one arrangement input image area 310 (one unit reservation) from the sales and purchase item list in the reservation card through another GUI image (not shown). In the example of FIG. 8, the contents of the sales items for overseas train tickets are displayed as screen IMI40. The screen IMI40 includes display columns for the name of the sales item, the label, the tax classification, the PAX information, the supplier, information on the sales amount and the purchase amount (unit price, quantity, total amount, tax amount, etc.), the profit (difference between sales and purchase), information on the billing amount (currency and total amount), and information on the payment amount (same as above). On the right side of the display column for information on the billing amount, a display column C40 for "Not billed", a display column C41 showing the billing status, a display column C42 for "Unpaid/Unpaid", and a display column C43 showing the payment status are arranged. Of these, the display column C41 displays whether or not the invoice has been issued through the screen IMI20 of FIG. 5. As an example, FIG. 8 displays "Billed", which indicates that the invoice has been issued. The display column C42 displays the unpaid amount calculated by the data management unit 220. As an example, FIG. 8 displays the unpaid amount "0". The display column C43 displays whether or not the payment has been settled for the entire amount of the sales. In FIG. 8, "Payment completed" is displayed, indicating that the entire amount of the sales has been settled. To the right of the display column for information regarding the payment amount are a display column C44 for "unpaid/unpaid", a display column for "scheduled date", and a display column C45 showing the payment status. Of these, display column C44 displays the unpaid amount calculated by the data management unit 220. As an example, FIG. 8 displays an unpaid amount of "2,000". Display column C45 indicates whether or not the entire amount of the purchase has been settled. As an example, FIG. 8 displays "unpaid" which indicates that no settlement has been made for the purchase (not even partially). Note that if a payment corresponding to a portion of the amount of the purchase has been allocated, "partial payment" is displayed.

Screen IMI40 also includes a control image C46 that can be selectively set to a planned state or a confirmed state. By default, control image C46 is set to the planned state (the state shown in FIG. 8). In this state, the details of the sales and purchase contents are displayed as described above. In this state, when "Confirm" is selected on control image C46 using input device 120, control image C46 is set to the confirmed state and the contents of the sales and purchase items corresponding to the displayed contents are confirmed. Note that the contents of the purchase adjustment amount indicated by purchase adjustment data 413 are confirmed using a screen different from screen IMI40.

When the control image C38 is selected on the screen IMI30 in FIG. 6, a screen IMI60 consisting of GUI images related to refunds and transfers is displayed on the display 110, as shown in FIG. 9 as an example. A refund is a process of returning the excess amount to a customer when a deposit is made that exceeds the total amount of the invoice. A transfer is a process of allocating the excess amount of a similar deposit to the invoice of another reservation card. The screen IMI60 includes a control image C61 of a button for proceeding with a refund or transfer request, an area 60a that displays basic information about the refund or transfer, an area 60b that displays the details of the unallocated deposit that is the subject of the refund or transfer, an area 60c for inputting the necessary information for the refund or transfer, an area 60d that displays the details of the deposit related to the deposit that is the subject of the refund or transfer, and an area 60e that displays the details of the request if the refund request is approved.

The control image C61 can be selected through the input device 120. When the control image C61 is selected after information related to a refund or transfer is entered in the areas 60a to 60c, a refund or transfer request is generated based on the input contents, and the state is awaiting approval. The area 60a includes a request number that identifies the refund or transfer request, a request amount that is the total amount of the refund, etc., a sales destination corresponding to the refund destination or transfer destination, person in charge information, an input field for the reason for the refund or transfer, and the like. The area 60a also includes control images C62 and C63. The control image C62 is an image for the business general manager to approve the request contents after the refund or transfer request is awaiting approval, and it selectively takes the "unapproved" state or the "approved" state. These states are switched by selecting an image through the input device 120. The state is displayed by switching the appearance of the image. The unapproved state is shown in FIG. 9. The control image C63 is an image for inputting whether the accounting staff has executed the process after the request has been approved by the general manager, and can selectively take the "unprocessed" or "executed" state. These states are switched by selecting an image via the input device 120. The state that is currently in is displayed by switching the appearance of the image. Figure 9 shows the "unprocessed" state.

Area 60b includes a list of unallocated deposits. In the example of FIG. 9, only one item is displayed, but one or more items consisting of all the candidates in the same appointment card are displayed in the list. Each item in the list includes a column displaying the details of the deposit, such as the date of deposit and the amount of deposit, a column displaying the unallocated amount of the deposit amount corresponding to the unallocated amount, and a column C64 for inputting the amount of the unallocated amount to be refunded or transferred using the input device 120. Area 60c includes a control image C65 for selecting either refund or transfer, and input columns C66 and C67 for necessary information. The control image C65 includes a "refund" radio button and a "transfer" radio button, which can be selected alternatively using the input device 120. When the "refund" radio button is selected, the input column C66 becomes ready for input. In the input column C66, the transfer information of the refund destination (bank name, account number, account name, etc.) is input using the input device 120. When the "transfer" radio button is selected, the input column C67 becomes ready for input. In the input field C67, the invoice information (invoice number) of the transfer recipient is entered using the input device 120.

Area 60d displays a list of deposits and refunds for the same reservation card that have the same deposit source as the deposit selected in area 60b or the same transfer destination entered in area C66.

In the default state shown in FIG. 9, the area 60e does not display any content. After a refund request is made by selecting the "Refund" radio button and the control image C61, and the request is approved by selecting the control image C62, the refund content entered in the areas 60b and 60c is sent from the terminal 100 to the server 200. Based on this, the data management unit 220 generates deposit data 431 indicating the refund content. The data management unit 220 then distributes the deposit indicating the refund content to the excess deposit, and generates allocation data 440 indicating the allocation content (see FIG. 12). This allocation data 440 is data for distributing the deposit indicating the refund content to the excess deposit. Then, the area 60e displays information on the refund corresponding to the deposit data 431 generated as described above, as shown in FIG. 10 as an example. This information includes the deposit status, the deposit amount, etc. The deposit amount has a negative value corresponding to the refund amount.

After a transfer request is made by selecting the "Transfer" radio button and control image C61, the request is approved and processing is carried out by selecting control images C62 and C63, and a notification to that effect is sent from terminal 100 to server 200. Based on this, data management unit 220 allocates the excess amount of the payment to the invoice of the transfer destination entered in area 60c, and generates allocation data 440 indicating the details of the allocation.

<Journal entry processing>
The journalization processing by the journalization processing unit 230 will be described below with reference to FIGS. 11 to 21. The journalization target items according to this embodiment (see FIGS. 11 to 13) include sales amount, sales tax amount, purchase amount (total amount), purchase tax amount (total amount), purchase amount (net amount), purchase adjustment amount (net amount), purchase adjustment tax amount (net amount), purchase adjustment amount (total amount), purchase adjustment tax amount (total amount), deposit, payment, deposit allocation (split, first half), payment allocation (split, first half), deposit allocation (deposits), deposit/withdrawal type department, deposit allocation (split, second half), payment allocation (split, second half), and deposit allocation (reverse journalization). Among these items, "total amount" means that the corresponding sales are recorded as sales. Also, "net amount" means that the corresponding profit (sales minus purchases) is recorded as sales. Whether to record the total amount or the net amount is selected according to the type of travel. For example, in the case of arranged travel, net amount is selected, and in the case of packaged travel, total amount is selected.

The journal entry processing unit 230 executes journal entry processing for each of the above journal entry target items based on the contents of the journal entry indicated by the journal entry method data 470. Each table in Figures 11 to 13 shows the contents of the journal entry indicated by the journal entry method data 470. Each table includes the journal entry voucher date, debit account item and credit account item, and the responsible department (division) for each account item for each journal entry target item. For those tables with multiple voucher dates, the latest date among the multiple dates is selected as the voucher date.

The items to the right of the "Debit" and "Credit" in each table show how to calculate the specific account item. This item has the format "AAAA (BBBB) @ CCCC", and the elements AAAA, BBBB, and CCCC show the following. AAAA indicates the classification of the account item, and has one of the following values: "Sales", "Purchases", "Advance receipt", "Advance payment", "Accounts receivable", and "Accounts payable (temporary tax receipt, provisional tax payment)". In the table, if the data to be processed for journalization directly has an account item, it is written as "Account item". BBBB is the type of journalization processing, and has one of the following values: "Arrangements", "Contract", "Insurance", "Planning", "Payment", and "Deposit". Of these, "Arrangements", "Contract", "Insurance", and "Planning" are types of journalization related to sales items or purchase items (written as [Sales] in the table), and are set depending on whether the sales item or purchase item belongs to arranged travel, commissioned travel, insurance, or packaged travel. Deposits and payments each have a fixed dedicated type. CCCC indicates where the money is being handled, and can have any of the following values: sales item, type of deposit/withdrawal, or something else (the other party is an individual or corporation). In the table, the "Sales Department" is, for example, the department to which the person in charge of reservations belongs, and the "Deposit/Withdrawal Department" is the department to which the person in charge of accounting belongs.

The journalizing processing unit 230 obtains the journalizing amount for each journalizing target item from the receipt and disbursement data 400 based on the following correspondence between each journalizing target item and the amount indicated by the receipt and disbursement data 400. Among the journalizing target items, the sales amount shown in FIG. 11 corresponds to the amount of each sales item indicated by the sales data 411 in the case of gross amount accounting, and corresponds to the amount obtained by subtracting the corresponding purchase item indicated by the purchase data 412 from the sales item indicated by the sales data 411 in the case of net amount accounting. The sales tax amount indicates the amount of tax on sales, and is calculated based on the sales amount and the tax rate indicated by the sales data 411. The purchase amount (total amount) corresponds to the amount of each purchase item indicated by the purchase data 412. The purchase tax amount (total amount) indicates the amount of tax on purchases, and is calculated based on the purchase amount (total amount) and the tax rate indicated by the purchase data 412. The purchase amount (net amount) corresponds to the amount of each purchase item indicated by the purchase data 412.

The purchase adjustment amount (net amount) and purchase adjustment amount (gross amount) are the amounts of purchase items associated with the purchase adjustment carried out through screen IMI50 shown in FIG. 7 in order to match the payment and purchase data when the payment does not match the original purchase due to exchange rate fluctuations or other reasons, as described above.

The deposits shown in FIG. 12 correspond to the amounts of each deposit indicated by the deposit data 431. The payments correspond to the amounts of each payment indicated by the payment data 432. The deposit allocation (split, first half) shown in FIG. 12 and the deposit allocation (split, second half) shown in FIG. 13 correspond to the allocation of deposits to sales indicated by the allocation data 440. In this embodiment, the journal processing is performed twice for one allocation: the deposit allocation (split, first half) and the deposit allocation (split, second half). In these journal entries, the credit account items (corresponding to the first account item in this invention) of the deposit allocation (split, first half) and the debit account items (split, second half) of the deposit allocation (split, second half) match each other. As a result, these two journal entries play a role in linking the deposit and sales items. The payment allocation (split, first half) shown in FIG. 12 and the payment allocation (split, second half) shown in FIG. 13 correspond to the allocation of payments to purchases indicated by the allocation data 440. In this embodiment, journal processing is performed twice for one allocation: payment allocation (split, first half) and payment allocation (split, second half). In these journal entries, the credit account for the payment allocation (split, first half) and the debit account for the payment allocation (split, second half) match each other (corresponding to the second account in this invention). As a result, these two journal entries play a role in linking payments and purchase items. As described above, the deposit allocation (between deposits) shown in Figure 12 is an allocation indicated by allocation data 440, and corresponds to the allocation of deposits that indicates the details of refunds for deposits that have exceeded the limit. The type department indicates the type of deposit or withdrawal (the form of deposit or withdrawal, account, etc.).

The deposit allocation (reversal journal entry) shown in Figure 13 relates to journal entries accompanying changes to the invoice amount for the allocation after journal entry processing. This journal entry has content that cancels the journal entry of an allocation that has already been journalized. Specifically, the debit account item of the deposit allocation (reversal journal entry) becomes the credit account item of the journal entry of the allocation that is the subject of cancellation (the "original credit account" in the figure), and the credit account item of the deposit allocation (reversal journal entry) becomes the debit account item of the journal entry of the allocation that is the subject of cancellation (the "original debit account" in the figure).

When performing journal entry processing, the journal entry processing unit 230 executes processing in accordance with the flowcharts in Figures 14 to 21. Note that in the following, the execution of journal entry for "XXX" corresponds to the execution of the journal entry content shown in Figures 11 to 13 in which the journal entry target item is "XXX".

The flowchart in FIG. 14 corresponds to the main routine of the accounting process related to sales and purchases. This routine is executed for each fixed closing period according to the travel agency's accounting policy, for example, for each closing period of one month from the beginning of the month to the end of the month in the case of closing at the end of the month. First, the accounting processing unit 230 executes the sales/purchase accounting subroutine and the purchase adjustment accounting subroutine in order in steps S1 and S2, with each date belonging to the closing period as the accounting date. In the sales/purchase accounting subroutine and the purchase adjustment accounting subroutine, as described below, accounting is executed for the items to be accounted for, such as the sales amount, the purchase amount, and the purchase adjustment amount. The accounting date starts from the day after the last day of the previous closing period, and is advanced by one day each time these subroutines are executed. Next, the accounting processing unit 230 adds data indicating the results of the accounting executed in S1 and S2 to the accounting result data 470 in the memory unit 210 (S3). Next, the accounting processing unit 230 determines whether accounting has been executed up to the last day of the current closing period (S4). If it is determined that the accounting has not been performed until the last day (S4, No), the accounting processing unit 230 executes the processing from step S1 for the next day's accounting. If it is determined that the accounting has been performed until the last day (S4, Yes), the accounting processing unit 230 ends the series of processes related to the flowchart in FIG. 14. This completes all accounting processing related to sales and purchases until the last day of the closing period.

If the execution of the subroutine in steps S1 and S2 ends prematurely due to an error, the journal entry processing unit 230 executes rollback processing (S5). The rollback processing is executed only for the journal entry processing for the date on which journal entry was being executed at that time. In other words, the rollback processing returns the journal entry processing for the closing period to the state immediately after the journal entry up to the day before the date that was the subject of journal entry in the subroutine was completed when the error occurred. The journal entry processing unit 230 then ends the series of processes related to the flowchart in FIG. 14.

The journal processing unit 230 executes the process corresponding to the flowchart of FIG. 15 as a sales/purchase journalizing subroutine. First, the journal processing unit 230 acquires a list of sales items and purchase items to be closed based on the sales data 411 and purchase data 412 (S11). The sales items and purchase items to be closed are the sales items and purchase items whose sales date or purchase date matches the journalizing date. Next, the journal processing unit 230 executes the process of steps S12 to S17 for one item pair consisting of one sales item and one corresponding purchase item in the list. In step S12, the journal processing unit 230 determines whether the sales items and purchase items of the above item pair have both been confirmed. If it is determined that they are not confirmed (S12, not confirmed), the journal processing unit 230 terminates the execution of the subroutine as an error has occurred and returns to the process according to the flowchart of FIG. 14, which is the main routine. The error processing thereafter is as described above. If it is determined that the transaction has been confirmed (S12, confirmed), the journalizing unit 230 executes journalizing of the "sales amount" and "sales tax amount" for the sales items of the above item pair (S13 and S14). The contents of such journalizing are as shown in FIG. 11.

Next, the journalizing processing unit 230 judges whether the journalizing method of the purchase items included in the above item pair is gross amount accounting or net amount accounting (S15). This judgment is made based on the reservation data 420 and according to the type of trip corresponding to the purchase item. For example, if the type of trip is an arranged trip, it is judged to be net amount accounting, and if the type of trip is a package trip, it is judged to be gross amount accounting. Next, for the purchase items of the above item pair, journalizing is performed as "purchase amount (gross amount)" and "purchase tax amount (gross amount)" or "purchase amount (net amount)" according to the judgment of step S15 (S15, gross amount → S17 and S18 / S15, net amount → S20 and S21). Next, the journalizing processing unit 230 judges whether there are any items (unjournalized items) that have not been journalized in any of steps S13, S14, S16, S17, and S20 among the items acquired in step S11 (S17). If it is determined that there are unjournaled items (S18, Yes), the journalizing processing unit 230 executes the process from step S12 for one of the unjournaled items.

When it is determined that there are no unjournalized items (S18, No), the journalizing processing unit 230 executes the additional journalizing subroutine described later (S19). When executing the additional journalizing subroutine, the journalizing processing unit 230 creates an "additional journalizing execution list". The "additional journalizing execution list" is a list of allocations that require additional journalizing. Such allocations correspond to those in the "additional journalizing list" created in step S69 of the allocation journalizing subroutine described later, for which the sales item or purchase item to which the allocation is assigned has been journalized in step S13, S16, or S20 in the execution of the current sales/purchase journalizing subroutine. Then, the journalizing processing unit 230 executes the additional journalizing subroutine based on the allocations included in the "additional journalizing execution list". Next, the journalizing processing unit 230 ends the execution of the sales/purchase journalizing subroutine and returns to the processing according to the flowchart of FIG. 14, which is the main routine.

The journal processing unit 230 executes the process corresponding to the flowchart in FIG. 16 as the purchase adjustment journal entry subroutine. First, the journal processing unit 230 acquires a list of purchase adjustments to be closed based on the purchase adjustment data 413 (S31). The purchase adjustments to be closed are the purchase adjustments corresponding to the purchase items with purchase dates that match the journal entry date. Next, the journal processing unit 230 executes the process of steps S32 to S38 for one purchase adjustment in the list (hereinafter referred to as the "purchase adjustment"). In step S32, the journal processing unit 230 determines whether the purchase adjustment has been confirmed. If it is determined that the purchase adjustment has not been confirmed (S32, not confirmed), the journal processing unit 230 terminates the execution of the subroutine as an error has occurred and returns to the process according to the flowchart in FIG. 14, which is the main routine. The error processing thereafter is as described above.

If it is determined that the amount has been confirmed (S32, confirmed), the accounting processing unit 230 determines whether the accounting method for the purchase adjustment is gross accounting or net accounting (S33). This determination is made based on the reservation data 420 and on the type of trip in the purchase item corresponding to the purchase adjustment. For example, if the type of trip is an arranged trip, it is determined to be net accounting, and if the type of trip is a packaged trip, it is determined to be gross accounting. Next, depending on the determination in step S33, the accounting is performed for the "purchase adjustment amount (gross amount)" and the "purchase adjustment tax amount (gross amount)" or the "purchase adjustment amount (net amount)" and the "purchase adjustment tax amount (net amount)" (S33, gross amount → S34 and S35 / S33, net amount → S37 and S38). The contents of such accounting are as shown in FIG. 11. Next, the journal processing unit 230 determines whether or not there is any of the purchase adjustments acquired in step S31 for which no journalization has been performed in steps S34, S35, S37, or S38 (unjournalized purchase adjustments) (S36). If it is determined that there is an unjournalized purchase adjustment (S36, Yes), the journal processing unit 230 executes the process from step S32 for any one of the unjournalized purchase adjustments. If it is determined that there is no unjournalized item (S36, No), the journal processing unit 230 ends the execution of the purchase adjustment journalization subroutine and returns to the main routine, which is the process according to the flowchart of FIG. 14.

The flowchart in FIG. 17 corresponds to the main routine of the journal processing related to deposits, withdrawals, and allocation. This routine is executed for each fixed closing period according to the travel agency's accounting policy, for example, for each closing period of one month in the case of closing at the end of the month. First, the journal processing unit 230 executes the deposit and withdrawal journal subroutine, the allocation journal subroutine, and the allocation reversal journal subroutine in order as steps S41 to S43, with each date belonging to the closing period as the journal entry date. As described below, these subroutines execute journal entries for items to be journalized, such as deposits, payments, deposit allocation, and payment allocation. The journal entry date starts from the day after the last day of the previous closing period, and is advanced by one day each time these subroutines are executed. Next, the journal processing unit 230 adds data showing the results of the journal entries executed in S41 to S43 to the journal entry result data 470 in the memory unit 210 (S44). Next, the journal processing unit 230 determines whether journal entries have been executed up to the last day of the current closing period (S45). If it is determined that the accounting has not been performed until the last day (S45, No), the accounting processing unit 230 executes the process from step S41 for the next day's accounting. If it is determined that the accounting has been performed until the last day (S45, Yes), the accounting processing unit 230 ends the series of processes related to the flowchart in FIG. 17. This completes all accounting processes related to deposits, withdrawals, and allocations until the last day of the closing period.

The journalizing processing unit 230 executes the process corresponding to the flowchart of FIG. 18 as a deposit/withdrawal journalizing subroutine. First, the journalizing processing unit 230 acquires a list of deposits and payments to be closed based on the deposit data 431 and payment data 432 (S51). The deposits and payments to be closed are those whose deposit date or payment date matches the journalizing date. Next, the journalizing processing unit 230 executes the process of steps S52 to S55 for one deposit/withdrawal in the list (referred to as the "received deposit/withdrawal" in the following explanation of the deposit/withdrawal journalizing subroutine). In step S52, the journalizing processing unit 230 judges whether the deposit/withdrawal is a deposit or a payment. Next, depending on the judgment of step S52, a "deposit" journalizing or a "payment" journalizing is executed (S52, deposit → S53/S52, payment → S55). The contents of such journalizing are as shown in FIG. 12. Next, the journalizing processing unit 230 determines whether or not there are any deposits or withdrawals that have not been journalized in steps S53 and S55 (unjournalized deposits and withdrawals) among the deposits and withdrawals acquired in step S51 (S54). If it is determined that there are unjournalized deposits and withdrawals (S54, Yes), the journalizing processing unit 230 executes the process from step S52 for any one of the unjournalized deposits and withdrawals. If it is determined that there are no unjournalized items (S54, No), the journalizing processing unit 230 ends the execution of the deposit and withdrawal journalizing subroutine and returns to the main routine, which is the process according to the flowchart of FIG. 17.

The journalizing processing unit 230 executes the process corresponding to the flowchart of FIG. 19 as a distribution journalizing subroutine. First, the journalizing processing unit 230 acquires a list of distributions to be closed based on the deposit/withdrawal data 430 and the distribution data 440 (S61). The distributions to be closed are those whose distribution date matches the journalizing date, whose distribution source is a closed deposit/withdrawal, and whose distribution destination is a sales item or purchase item or a closed (journalized) deposit. Next, the journalizing processing unit 230 executes the process of steps S62 to S67 for one distribution in the list (hereinafter referred to as the "distribution"). In step S62, the journalizing processing unit 230 determines whether the distribution destination of the distribution is sales or purchase, or a closed deposit (S62). If it is determined that the deposit is closed (S62, closed deposit), the journalizing processing unit 230 executes the "deposit distribution (deposits)" journalizing (step S71) and executes the process of step S67 described later.

If it is determined that the allocation destination is a sales item or a purchase item (S62, sales item/purchase item), the journal processing unit 230 executes a "type department" journal entry (S63). The contents of such journal entry are as shown in FIG. 12. Next, the journal entry processing unit 230 determines whether the item to which the allocation is to be allocated has been closed (journalized) (S64). If it is determined that it has been closed (S64, Yes), it executes the processing of step S65. If it is determined in step S64 that the item to which the allocation is to be allocated has not been closed (S64, No), it adds the allocation to the "additional journal entry required list" (S69). The "additional journal entry required list" is a list of allocations for which journal entry has not been performed for the allocation destination at the time of addition to the list, and additional journal entry (referred to as "additional journal entry" in this embodiment) is required after journal entry has been performed for the allocation destination. Next, the journal entry processing unit 230 determines whether the allocation source of the allocation is a deposit or a payment (S65). If it is determined that the source of the allocation is a deposit (S65, deposit), the journalizing processing unit 230 executes the journalizing process of "Deposit allocation (split, first half)" (corresponding to the first journalizing process of the present invention) (S66). On the other hand, if it is determined that the source of the allocation is a payment (S65, payment), the journalizing processing unit 230 executes the journalizing process of "Payment allocation (split, first half)" (corresponding to the third journalizing process of the present invention) (S70). The contents of such journalizing are as shown in FIG. 12. These journalizing processes are executed regardless of whether the base date of the sales item or purchase item to which the allocation is assigned is later than the base date of the deposit or payment to which the allocation is assigned. Then, the journalizing processing unit 230 executes the process of step S67.

In step S67, the journalizing processing unit 230 determines whether or not there is any of the allocations acquired in step S61 for which no journalizing has been performed in steps S66, S70, or S71 (unjournalized allocations). If it is determined that there is an unjournalized allocation (S67, Yes), the journalizing processing unit 230 executes the process from step S62 for one of the unjournalized allocations. If it is determined that there is no unjournalized item (S67, No), it executes the additional journalizing subroutine described below (S68). When executing the additional journalizing subroutine, the journalizing processing unit 230 creates an "additional journalizing execution list". The "additional journalizing execution list" is a list of allocations that require additional journalizing. Such allocations correspond to those that have been journalized in step S66 or S70 in the current execution of the allocation journalizing subroutine, and for which it has been determined in step S64 that the item to which the allocation is to be assigned has been closed. Then, the journalizing processing unit 230 executes the additional journalizing subroutine based on the allocation included in the "additional journalizing execution list." Next, the journalizing processing unit 230 ends the execution of the allocation journalizing subroutine and returns to the main routine, which is the processing according to the flowchart of FIG. 17.

The journalizing processing unit 230 executes the process corresponding to the flowchart of FIG. 20 as a reversal of allocation subroutine. First, the journalizing processing unit 230 acquires a list of allocations to be closed based on the allocation data 440 (S81). The allocations to be closed are those whose allocation reference date matches the journalizing date and that have been subjected to VOID processing. Next, the journalizing processing unit 230 executes the journalization of "Deposit allocation (reversal)" for one of the allocations in the list. The contents of such journalization are as shown in FIG. 13. Next, the journalizing processing unit 230 determines whether or not there is any of the allocations acquired in step S81 for which no journalization has been performed in step S82 (unjournalized allocation) (S83). If it is determined that there is an unjournalized allocation (S83, Yes), the journalizing processing unit 230 executes the process of step S82 for any one of the unjournalized allocations. If it is determined that there are no unjournalized items (S83, No), the journalization processing unit 230 ends the execution of the allocation reversal subroutine and returns to the main routine, which is the processing according to the flowchart in FIG. 17.

The journalizing processing unit 230 executes the process corresponding to the flowchart in FIG. 21 as an additional journalizing subroutine. First, the journalizing processing unit 230 acquires a list of deposits and withdrawals to be closed based on the "additional journalizing execution list" created in the subroutine that called the additional journalizing subroutine (sales/purchase journalizing subroutine or allocation journalizing subroutine) (S91). The deposits and payments to be closed are those corresponding to the allocation sources included in the "additional journalizing execution list". Next, the journalizing processing unit 230 executes the process of steps S92 to S95 for one deposit or withdrawal in the list (referred to as "the deposit or withdrawal in question" in the following explanation of the additional journalizing subroutine). In step S92, the journalizing processing unit 230 determines whether the deposit or withdrawal in question is a deposit or a payment. Next, depending on the judgment of step S92, either the journal entry of "Deposit allocation (split, latter half)" (corresponding to the second journal entry process in the present invention) or the journal entry of "Payment allocation (split, latter half)" (corresponding to the fourth journal entry process in the present invention) is executed (S92, deposit → S93/S92, payment → S95). The contents of such journal entry are as shown in FIG. 13. Next, the journal entry processing unit 230 judges whether or not there is any of the deposits and withdrawals acquired in step S91 that have not been journalized in steps S93 and S95 (unjournalized deposits and withdrawals) (S94). If it is judged that there is an unjournalized deposit or withdrawal (S94, Yes), the journal entry processing unit 230 executes the process from step S92 for any one of the unjournalized deposits and withdrawals. If it is judged that there is no unjournalized item (S94, No), the journal entry processing unit 230 ends the execution of the additional journal entry subroutine and returns to the processing by the subroutine that called it.

The table in FIG. 22 shows the contents of the journal entry result data 470 generated by the journal entry processing unit 230 based on the receipt and disbursement data 400 shown in FIG. 3(a). The contents of the journal entry vouchers are arranged in order of the voucher date. In the table in FIG. 22, dates such as "7/1" indicate the voucher date. "Deposit" and "Sales amount" indicate the items to be journalized (see FIG. 11 and FIG. 12). "Deposit allocation (before)" and "Deposit allocation (after)" indicate the items to be journalized, deposit allocation (split, first half) and deposit allocation (split, second half), respectively. "Sales", "Accounts receivable", "Advance receipt", and "Deposits and withdrawals" indicate the contents of the account items. "Reservations" and "Accounting" indicate the departments in charge of each account item. "Debit" and "Credit" indicate debit and credit account items, respectively. "1", "2", "3", and "6" indicate the size of the amount. Specifically, "1" indicates 1,000 yen, "2" indicates 2,000 yen, "3" indicates 3,000 yen, and "6" indicates 6,000 yen. The server 200 outputs the contents of these journal vouchers, for example, at the end of the month. As shown in FIG. 22, in the case of the end of July, the contents of journal vouchers with voucher dates in the range of 7/1 to 7/31 are output together. In the case of the end of August, the contents of journal vouchers with voucher dates in the range of 8/1 to 8/31 are output together. The same applies to the end of September, October, November, and December. Output may be done in various ways, such as displaying on the display 110, printing on paper by the printer 140, or recording on a recording medium.

<Journal Entry Evaluation Processing>
The journal evaluation process executed by the server 200 will be described below. As described above, the journal evaluation process is a process for evaluating whether the accounting information such as sales and deposits indicated by the receipt and disbursement data 400 is consistent with the journal result indicated by the journal processing unit 230 and stored in the storage unit 210. The journal evaluation process may be automatically executed by the server 200 at an appropriate timing, or may be executed by the server 200 at a timing specified by the user. The target of the journal evaluation process in the receipt and disbursement data 400 is all data included in the receipt and disbursement data 400 that has been journalized. The target of the journal evaluation process in the journal result data 470 corresponds to the target of the journal evaluation process in the receipt and disbursement data 400. The evaluation of consistency is performed based on the association of each item of sales items, purchase items, purchase adjustment amount, deposit, payment, and allocation indicated by the journal result data 470 with the journal voucher.

The journal entry evaluation process performs the following evaluations [1] to [6] on the target. If any of these evaluations result in a "no" result, the server 200 reports to the system administrator or developer, etc., information such as the date and amount related to the item that resulted in a "no" result, the corresponding journal entry slip, and which of [1] to [6] the evaluation was for. The report may be output in various ways, such as displaying on the display 110, printing on paper by the printer 140, or recording on a recording medium.

[1] Evaluation of the relationship between each item and the journal entry slip It is evaluated whether or not one journal entry consisting of one pair of debit and credit is generated from each item of the accounting information indicated by the receipt and disbursement data 400. According to the specifications of this embodiment, one journal entry is generated from each item. For example, one journal entry consisting of a credit "sales amount" and a debit "accounts receivable" is generated from one sales item indicated by the sales data 411. Based on this, it is determined whether or not one journal entry is generated from each item of the sales item, purchase item, purchase adjustment amount, deposit, payment, and allocation indicated by the receipt and disbursement data 400. If it is determined that it has been generated, the evaluation result is positive, and if it is determined that it has not been generated, the evaluation result is negative. Note that for allocations that have been subjected to VOID processing, an additional journal entry of "deposit allocation (reverse journal entry)" is generated by the allocation reversal journal entry subroutine shown in FIG. 20. Therefore, two journal entries are generated: the journal entry of the allocation itself and the additional journal entry. Therefore, for a distribution that has been subjected to VOID processing, it is determined whether or not the above two journal entries have been generated from one item, and an evaluation is performed based on the result of this determination.

[2] Evaluation of the agreement between the unpaid amount in sales and the accounts receivable in journal entries For one sales item with an unpaid amount of 0 yen and the journal entry generated from the allocation corresponding to this (corresponding to the first set in this invention), in the summation result obtained by subtracting the total of the debit amounts from the total of the credit amounts for each account item, it is determined whether the accounts receivable after the summation matches the unpaid amount of 0 yen for that one sales item. If it is determined that they match, the evaluation result is positive, and if it is determined that they do not match, the evaluation result is negative.

For example, suppose that the cash flow data 400 shows the sales shown in FIG. 23(a) and the allocation of two corresponding deposits of 500 yen, with the resulting amount receivable being 0 yen, and the corresponding journal entry voucher shown in journal entry result data 470 has the contents of journal entries 1 to 3 in FIG. 23(b). In this case, the total credit amount for the account item "Sales" is 1,000 yen (= 1,000 yen for journal entry 1) and the total debit amount is 0 yen. The total credit amount for the account item "Accounts receivable" is 1,000 yen (= 500 yen for journal entry 2 + 500 yen for journal entry 3), while the total debit amount is 1,000 yen (= 1,000 yen for journal entry 1), so subtracting the total debit amount from the total credit amount gives 0 yen. The account item "Advance Received (Reservation)" has a total credit of 0 yen and a total debit of 1,000 yen (= 500 yen in journal entry 2 + 500 yen in journal entry 3). Therefore, the sum of these amounts results in sales of 1,000 yen on the credit side and advance received (reservation) of 1,000 yen on the debit side, as shown in Figure 23 (c). Furthermore, the account item "Accounts Receivable" has neither a credit nor a debit as a result of the summation. This summation result matches the outstanding amount of 0 yen shown in the receipts and disbursements data 400. Therefore, the evaluation result is positive.

[3] Evaluation of the Consistency between the Unpaid Amount in Purchases and the Accounts Payable in Journal Entry For a purchase item with an unpaid amount of 0 yen and a journal entry generated from the allocation corresponding to this (corresponding to the second group in the present invention), the sum of the debit amounts is subtracted from the sum of the credit amounts for each account item to determine whether the sum of the accounts payable after the summation matches the unpaid amount of 0 yen for that one purchase item. If it is determined that they match, the evaluation result is positive, and if it is determined that they do not match, the evaluation result is negative. This evaluation corresponds to changing the sales item to a purchase item, the unpaid amount to the unpaid amount, and the accounts receivable to accounts payable in the evaluation of [2].

[4] Evaluation of the Match between the Unallocated Amount of a Deposit and the Advance Received in an Entry For one deposit with an unallocated amount of 0 yen and the entry corresponding to this (corresponding to the third group in the present invention), in the summation obtained by subtracting the total of the debit amounts from the total of the credit amounts for each account item, it is determined whether the summed advance received (accounting) matches the unallocated amount of 0 yen for that one deposit. If it is determined that they match, the evaluation result is positive, and if it is determined that they do not match, the evaluation result is negative.

For example, suppose that the receipt and disbursement data 400 shows the deposit shown in Figure 24(a) and two allocations of 500 yen for this, i.e., an unallocated amount of 0 yen, and the corresponding journal entry voucher shown in the journal entry result data 470 has the contents of journal entries 1 to 3 in Figure 24(b). In this case, the account item "Advance Received (Accounting)" has a total credit of 1,000 yen (= 1,000 yen for journal entry 1) and a total debit of 1,000 yen (= 500 yen for journal entry 2 + 500 yen for journal entry 3), so subtracting the total debit from the total credit results in 0 yen. The account item "Type" has a total credit of 0 yen and a total debit of 1,000 yen (= 1,000 yen for journal entry 1). The account item "Advance Received (reservation)" has a total credit of 1,000 yen (= 500 yen in journal entry 2 + 500 yen in journal entry 3), while the total debit is 0 yen. Therefore, the sum of these amounts results in a credit of 1,000 yen for advance received (reservation) and a debit of 1,000 yen, as shown in Figure 24 (c). Furthermore, the account item "Advance Received (accounting)" has neither a credit nor a debit as a result of the summation. This summation result matches the unallocated amount of 0 yen shown in the receipt and disbursement data 400. Therefore, the evaluation result is positive.

[5] Evaluation of the consistency between the unallocated amount in the payment and the advance payment in the journal entry For a journal entry generated from one payment and its corresponding allocation (corresponding to the fourth group in this invention), in the summation obtained by subtracting the total of the debit amounts from the total of the credit amounts for each account item, it is determined whether the summed advance payment (accounting) matches the unallocated amount for that one payment. If it is determined that they match, the evaluation result is positive, and if it is determined that they do not match, the evaluation result is negative. This evaluation corresponds to changing the deposit to a payment and the advance receipt to an advance payment in the evaluation of [4].

[6] Evaluation of offsetting of advance receipts (reservations) and advance payments (reservations) The evaluation of advance receipts (reservations) is performed on the allocations that have already been journalized for both the deposit allocation (split, first half) and the deposit allocation (split, second half). In the journalization generated from such allocations, the result of subtracting the total of the debits from the total of the credits for the account item "Advance receipts (selling)" should be 0 yen. In other words, if it is 0 yen, the evaluation result is positive, and if it is not 0 yen, the evaluation result is negative.

Valuation of prepayments (reservations) is done for the allocations that have already been book-entered for both the payment allocation (installment, first half) and the payment allocation (installment, second half). In the journal entry generated from such an allocation, the result of subtracting the total of the debits from the total of the credits for the account item "Prepayment (sale)" should be 0 yen. In other words, if the result is 0 yen, the valuation result is positive, and if it is not 0 yen, the valuation result is negative.

Effects of the embodiment
According to the receipt and disbursement data 400 in the present embodiment described above, the sales data 411 indicates the contents of the sales items for each unit reservation or a more detailed unit. The purchase data 412 indicates the contents of the purchase items for each unit reservation or a more detailed unit. The deposit data 431 indicates the deposit, and the payment data 432 indicates the contents of the payment. The allocation data 440 indicates the allocation of deposits or payments to the sales items of the sales data 411 or the purchase items of the purchase data 412. In addition, in the allocation of deposits and payments indicated by the allocation data 440, the base date can be set to a date earlier than the base date of the sales item or purchase item to which the deposit is allocated. In other words, regardless of the timing of deposits or payments relative to the base date of the sales item or purchase item, it is possible to allocate deposits or payments to sales items or purchase items while setting a base date earlier than the base date of the sales item or purchase item (see the allocation of deposits dated 7/1 and 8/15 corresponding to the sales dated 9/1, 9/5, and 9/15 in FIG. 3(a)). This allows for matching and evaluation of receipts or payments to sales items or purchase items (e.g., grasping unpaid or unpaid amounts) prior to the base date of the sales or purchase items. In addition, detailed matching and evaluation is possible because the allocation of receipts or purchases is performed to sales items or purchase items.

In addition, according to the accounting processing system 1 of this embodiment, if a deposit or purchase occurs prior to a sales item or purchase item, accounting processing can be performed for the allocation related to the deposit or purchase even if it is before the reference date of the sales item or purchase item (see the accounting content in Figure 22 related to the sales, allocation, and deposit in Figure 3 (a)). Therefore, closing processing for deposits and payments and their allocation can be performed early.

In addition, in the journalization process of the deposit according to this embodiment, regardless of whether the sales item to which the allocation is to be made has been journalized, the "deposit allocation (split, first half)" is journalized (S66 in FIG. 19). Then, if the journalization process of the sales item has been executed (if it is included in the "additional journalization execution list" in S19 of FIG. 15 or S68 of FIG. 19), the "deposit allocation (split, second half)" is journalized (S93 in FIG. 21), thereby generating a journalization voucher that links the deposit and the sales. In addition, in the journalization process of the payment, regardless of whether the purchase item to which the allocation is to be made has been journalized, the "payment allocation (split, first half)" is journalized (S70 in FIG. 19). Then, if the journalization process of the purchase item has been executed (if it is included in the "additional journalization execution list" in S19 of FIG. 15 or S68 of FIG. 19), the "payment allocation (split, second half)" is journalized, thereby outputting a journalization voucher that links the payment and the purchase. Therefore, accounting can be performed regardless of whether the destination has already been accounted for, making it possible to quickly close out deposits, payments, and their allocations.

<Modification>
The above is a description of a preferred embodiment of the present invention, but the present invention is not limited to the above embodiment, and various modifications are possible within the scope of the means for solving the problems. Below, modifications of the above embodiment will be described.

For example, in the above embodiment, an invoice for a positive amount is issued to a customer through screen IMI30 in FIG. 4. However, an invoice for a negative amount may also be issued to a customer. Such invoices are issued for various purposes, such as when applying a discount. In this case, it is conceivable that a refund will be made in response to such an invoice. For this reason, in screen IMI60 in FIG. 9, which is made up of GUI images related to refunds and transfers, an item related to an issued invoice for a negative amount may be displayed in area 60b as an element of a list of candidates for processing such as refunds, in addition to or instead of unallocated deposits.

In the above embodiment, the person in charge of reservations accepts deposits at the counter and inputs the details of the deposits through the screen IMI 30. However, the accounting system 1 may be configured to accept other types of deposits. For example, when multiple deposits are made by bank transfer and a data file showing a list of the deposits is received from a customer, the accounting system 1 may be configured to import the data file and automatically allocate it to sales items. In this case, it is preferable that the accounting system 1 is configured to obtain which deposits correspond to which sales items based on the information related to the deposits shown in the data file. For example, the invoice data 450 may include account data showing a transfer account (such as a virtual account), and the data file may also include such account data for each deposit. This makes it possible to identify the invoices corresponding to each deposit by searching for the invoices shown in the invoice data 450 using the account data as a key.

In the above-described embodiment, the accounting processing system according to the present invention is realized using multiple computers including one or more terminals 100 and a server 200. However, it may also be realized using a single computer. Also, one or more terminals 100 and a server 200 are connected to each other via the Internet. However, they may also be connected to each other via a communication network other than the Internet, such as a LAN (Local Area Network).

In the above-described embodiment, the functions of the terminal 100 are realized in a so-called browser-based manner using the browser 130, which is a general-purpose application. However, the functions may also be realized using an application dedicated to this system, rather than being browser-based.

1 Accounting system 100 Terminal 110 Display 120 Input device 130 Browser 140 Printing device 200 Server 210 Storage unit 220 Data management unit 230 Journalizing unit 240 Journalizing evaluation unit 400 Receipts and payments data 410 Sales and purchase data 411 Sales data 412 Purchase data 413 Purchase adjustment data 420 Reservation data 430 Deposit and withdrawal data 431 Deposit data 432 Payment data 440 Allocation data 450 Invoice data 460 Journalizing method data 470 Journalizing result data

Claims (4)

A data structure for travel business related to accounting information including sales, purchases, receipts, and payments,
Sales data showing unit sales, which are sales per unit reservation, which is one reservation for one supplier, or per unit more detailed than that;
Purchase data indicating unit purchases, which correspond one-to-one to the unit sales and are purchases for each of the unit reservations or for each unit more detailed than the unit purchases;
deposit data indicating the deposit;
payment data indicative of a payment;
Deposit allocation data indicating how the deposit indicated by the deposit data is allocated to the sales indicated by the sales data for each unit of sales;
Payment allocation data indicating a payment allocation for allocating the payment indicated by the payment data to the purchase indicated by the purchase data for each unit purchase;
The base date data indicates the base dates of the unit sales, the unit purchase, the deposit, the payment, the deposit allocation, and the payment allocation,
In the reference date data, at least one of the reference date of the deposit allocation and the reference date of the payment allocation can be set to a date in the past with respect to the reference date of the unit sales or the unit purchase to which the allocation is made,
A storage means for storing the receipt and payment data and data indicating credit account items and debit account items for each of the unit sales, the unit purchase, the deposit, the payment, the deposit allocation, and the payment allocation;
and a journal processing means for executing a journal processing to generate journal vouchers for each of the unit sales, the unit purchase, the deposit, the payment, the deposit allocation, and the payment allocation based on the stored contents in the storage means,
An accounting processing system characterized in that the accounting processing means is configured to be able to execute the accounting processing for each of the deposit allocation and the payment allocation at a timing in the past with respect to the reference date of the unit sale or unit purchase to which the allocation is made. The journalization processing means,
For each of one or a plurality of consecutive journal entry dates, the journal entry process can be executed for the unit sales, unit purchases, deposits, payments, deposit allocations, and payment allocations indicated by the receipt and disbursement data, for which the reference date indicated by the reference date data corresponds to the journal entry date;
As a journal entry for the deposit allocation, a first journal entry process is executed in which the debit is a credit account item in the journal entry voucher for the deposit and the credit is a first account item, and if the journal entry process has been executed for the unit sales to which the deposit allocation is allocated, a second journal entry process is further executed in which the debit is the first account item and the credit is a debit account item in the journal entry voucher for the unit sales;
The accounting processing system described in claim 1, characterized in that as a journal entry for the payment allocation, a third journal entry process is executed in which the debit is a credit account item in the journal entry voucher for the payment and the credit is a second account item, and if the journal entry process has already been executed for the unit purchase to which the payment allocation is allocated, a fourth journal entry process is further executed in which the debit is the first account item and the credit is a debit account item in the journal entry voucher for the unit purchase. The accounting processing system described in claim 1 or 2, characterized in that the results of the journal entry processing are evaluated by comparing the result of adding up the debit and credit amounts contained in the journal entry voucher generated from the elements that make up at least one of the groups, i.e., a first group consisting of the unit sales and the deposit allocation, a second group consisting of the unit purchase and the payment allocation, a third group consisting of the deposit and the deposit allocation, and a fourth group consisting of the payment and the payment allocation, for each account item, with the corresponding unpaid amounts, unpaid amounts, and unallocated amounts indicated by the receipt and disbursement data. The result of the journalization process is evaluated based on whether or not the amounts of the debit and credit included in the journalization slip generated from the deposit allocation for which both the first and second journalization processes have been executed match when the amounts of the debit and credit included in the journalization slip are added up for the first account item, and
The accounting processing system described in claim 2, characterized in that the result of the journal entry processing is evaluated based on whether the debit and credit amounts included in the journal entry voucher generated from the payment allocation for which both the third and fourth journal entry processing have been executed match when the amounts are added up for the second account item.

Images