JP2009151675A - Budget management accounting computer system and computer program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To acquire journalizing data when a transaction is actually made and a budget changes into an actual result while making the budget in "general transaction" units. <P>SOLUTION: An accounting computer system for carrying out budget management, includes an input means for inputting budget data for each transaction, a storage means for storing the input budget data, and journalizing data generating means for generating journalizing data from the budget data. The budget data includes a series of dates from the occurrence of the transaction to the account settlement of the transaction, and the amount of money of the transaction. The input means is configured to divide and input the amount of money of the transaction in the budget data into the amounts of money for each of one or more bookkeeping transactions constituting the transaction, and the journalizing data generating means is configured to generate journalizing data on the actually-made bookkeeping transactions from the data of portions on the actually-made bookkeeping transactions out of the budget data. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an accounting computer system for budget management and a computer program thereof.

  As an apparatus for performing budget management, for example, there is one described in Patent Document 1. Patent Document 1 describes a fund management apparatus for checking the presence or absence of a fund short by inputting predicted transaction data related to a payment schedule or a payment schedule. In this money management apparatus, the predicted transaction data (fund management data) is changed to fixed data and becomes accounting data over time.

This accounting data is collectively transferred to general-purpose computer accounting and used for accounting operations. In other words, the general-purpose computer accounting side can perform a series of accounting operations from creation of a trial balance, creation of a general ledger, creation of an auxiliary ledger to settlement of accounts based on the transferred accounting data.
As described above, the apparatus of Patent Document 1 is configured such that when the budget data created for budget management is changed to fixed data, the fixed data can be diverted as accounting data.
JP 2004-302979 A

In the apparatus of Patent Document 1, the budget data that is the basis of the fixed data is formed in units of “transactions on bookkeeping” so that the fixed data can be diverted to the accounting data.
In other words, in the apparatus of Patent Document 1, the data structure of budget data and fixed data is basically the same, and the budget data whose scheduled date has passed is merely handled as fixed data.
And since the said fixed data is diverted as accounting data, it needs to be comprised as a journal (journal diary). In the journal, the cause and result of the transaction are recorded separately in debits and credits for each “bookkeeping transaction”.

  For this reason, in the apparatus of Patent Document 1, budget data that is the basis of finalized data is also created on a “bookkeeping transaction” basis, such as deposit (plan) and withdrawal (plan).

  However, the concept of “book transaction” and the concept of “transaction” (hereinafter also referred to as “general transaction”) in daily corporate activities are not completely the same. The present inventor has come to realize that budget management can be performed more accurately if budget management is performed according to the concept of “general transactions”.

Here, for example, consider a transaction called accounts receivable sales with a set deadline. Here, it is assumed that the closing date is the 20th of every month and the accounts receivable sales are settled (paid) 70 days after the closing date.
In this case, for example, if there is sales of 350,000 yen (transaction occurrence) on October 16, the settlement date (payment date) is December 30.
In the concept of “general transaction”, it is considered that “one transaction” is from the generation of the accounts receivable to the settlement. In other words, this is because both the generation of accounts receivable and the settlement are related to “one commercial activity” of “sold 350,000 yen”.

  On the other hand, in the “bookkeeping transaction” concept, the transaction generation and settlement of the accounts receivable sales are two transactions. In other words, when carrying out bookkeeping journals, the journal for sales of 350,000 yen (transaction occurrence) on October 16 and the journal for payment of 350,000 yen (payment) on December 30 are performed. Is called.

  Therefore, when a budget is managed in accordance with the concept of “book transaction”, a plurality of “book transactions” related to “one business activity” are handled separately. A plurality of “bookkeeping transactions” related to “one business activity” is not limited to two as described above, but may be more. As a result, if budget management is performed in accordance with the concept of “bookkeeping transactions”, the relationship between a plurality of “bookkeeping transactions” is difficult to understand, resulting in difficult budget management.

In this way, conventional bookkeeping is excellent for recording actual transactions in the past, but it is not suitable for predicting the future based on transactions expected in the future, making budget management difficult. To.
On the other hand, in order to enable linkage with a general accounting system, the data of transactions actually performed in budget management are not data of “general transactions” but of “book transactions”. The journal data is more advantageous.

  Therefore, in the present invention, a budget can be established in units of “general transactions” rather than in units of “general transactions”, which is common sense in accounting computer systems. The purpose is to enable journal entry data to be obtained when a transaction is actually carried out and the budget is changed to an actual result, while a budget is established in units of “nasty transactions”.

  The present invention is an accounting computer system that performs budget management, and includes input means for inputting budget data for each transaction, storage means for storing input budget data, and generating journal data from the budget data. Journal data generation means, and the budget data is data including a series of dates from the occurrence of a transaction to settlement of the transaction and the amount of the transaction, and the input means is a transaction in the budget data. The journal data generation means is configured to input the bookkeeping actually performed out of the budget data. It is configured to generate journal data on bookkeeping transactions actually performed from the above transaction-related data. It is a computer system.

  The budget data indicates item data indicating a transaction item indicated by the budget data, and whether the item increases or decreases assets, liabilities, capital, revenue, or expenses. It is preferable that increase / decrease classification data is included, and the journal data generation means is configured to perform journalization of the actual bookkeeping transaction using the subject data and the increase / decrease classification data.

  The subject indicated by the subject data is preferably an account subject and a counterpart subject in which the account subject is secondarily generated.

  It is preferable that the input means is configured to be able to input a progress state of a transaction indicated by the budget data.

  The input means is configured to be able to input a transaction occurrence date as a date related to a transaction indicated by budget data, and the system is configured to set information for calculating a closing date and / or a settlement date from the transaction occurrence date; And generating means for generating a closing date and / or a settlement date as date data relating to the transaction indicated by the budget data based on the information set by the setting means when a transaction occurrence date is input. It is preferable.

  Budget generating means for generating, from a plurality of budget data belonging to the first accounting period, a plurality of budget data belonging to a second accounting period after the first accounting period, A predicted value input means for receiving an input of a predicted value of the ratio of the transaction amount indicated by the budget data of the second accounting period to the transaction amount indicated by the budget data of the first accounting period, and included in the first accounting period Conversion means for converting a plurality of budget data in the first accounting period into a plurality of budget data in the second accounting period by multiplying the transaction amount of each budget data by the predicted value of the ratio. It is preferable.

  Another aspect of the present invention is a computer program for causing a computer to function as the budget management accounting computer system.

  According to the present invention, it is possible to establish a budget in units of “general transactions” in which the period from the occurrence of a transaction to the settlement of the transaction is considered as one transaction.

  Moreover, in the present invention, the journal data generation means generates journal data on the bookkeeping transaction actually performed from the data related to the bookkeeping transaction actually performed in the budget data. Journal data can be obtained while setting a budget for each "general transaction".

[Definition of terms]
The term “transaction” refers to the period from the occurrence of revenue or expenditure (transaction occurrence) to the deposit or withdrawal (transaction settlement) of the current funds. Here, “transaction” has almost the same concept as “transaction” (general transaction) in general commercial transactions. In addition, the “transaction” here is composed of one or a plurality of “bookkeeping transactions”.
Note that terms not specifically defined here and not specifically described below follow the usage in bookkeeping or ordinary accounting computer systems.

[1. About budget bookkeeping]
Budget bookkeeping is bookkeeping for budgeting a company's management plan as a number by bookkeeping and indicating the direction in which the company should proceed. Budget bookkeeping can be performed by a budget management accounting computer system described later.
When a manager (a user of a budget management accounting computer system) predicts the near future of a company and makes a short-term and long-term management plan, the budget bookkeeping (budget management accounting computer system) uses that number as a specific budget. And provide “flow of funds” and “size of profit and loss” in real time.
In normal bookkeeping, journal entries are entered based on actual results (actual transactions), but in budget bookkeeping, transactions that are known in advance are entered, and if there are changes, future predictions are made. Can do.

[2. Budget Bookkeeping Basics]
[2.1 Budget to actual results]
Make a business plan for the company's quarter to three years, etc., subdivide the business plan for each transaction, enter it into the budget bookkeeping (to the budget management accounting computer system), and budget it specifically as a number.
Budget bookkeeping provides information on the “flow of funds” and “the magnitude of profits and losses” that are most needed by companies through this budgeting, using the expected balance sheet, profit management table, and cash flow table as future forecasts.
In budget bookkeeping, when the budget changes to actual results due to the passage of time, the budget is changed to actual results in a simple and simple way in accordance with this change, and the latest information is provided in real time at any time. .

[2.2 Flow of current funds]
Budget bookkeeping considers the flow of funds mainly from current funds that can be exchanged immediately (cash, current accounts, ordinary deposits, postal savings, notice deposits, etc.). Time deposits are not included in the current funds.

  In the budget bookkeeping, as shown in FIG. 1, if the current fund enters the company, it is processed as income, and if it comes out of the company, it is processed as expenditure. From the viewpoint of the current funds, it is income if you enter, and expenditure if you leave. It is the same way of thinking as a household account book. In addition, although there are expenses that are not related to the balance of current funds, such as depreciation expenses, among these items, these items are processed outside the funds and unrelated to the current funds.

[2.3 General transaction input method]
A feature of budget bookkeeping (budget management accounting computer system) is that a company's economic activities are input for each transaction (expected transaction) in a manner similar to a general sales management system.
Budget bookkeeping is similar to a general “transaction input method” because it inputs a business partner, a transaction amount, and a date related to a transaction (transaction occurrence date, settlement date, etc.) for each transaction.
The same transaction content is devised so that it can be easily input by copying the previous transaction or transferring the small amount of expenses.

In budget bookkeeping, anyone can enter a budget (expected transaction) using a general “transaction input method”, which is different from the “journal entry method” for debit and credit input, which is the basic principle of bookkeeping.
In the budget bookkeeping, journal entries (journal data) are automatically created when a certain condition is met by inputting the subject (• subject branch number) for automatic journal entry.
In the budget management accounting computer system described later, the computer program supports bookkeeping knowledge, so even if the user does not know bookkeeping, the “flow of current funds”, “size of profit / loss”, “date of funds shortage” ”And“ Non-collection of accounts receivable ”can be accurately grasped.

[3. Budget accounting accounting computer system]
A budget management accounting computer system (hereinafter simply referred to as “system”) 1 according to an embodiment of the present invention will be described below with reference to the drawings.

The system 1 is configured by installing a budget management accounting computer program for functioning as the system in a computer.
As shown in FIG. 2, the computer includes a processing unit (CPU), an internal storage device such as a ROM / RAM, an external storage device such as a hard disk, an input processing device 200 such as a keyboard / mouse, The image display apparatus 300 and the printing apparatus 400 are connected to each other.

  The budget accounting computer program can be recorded and sold on a (portable) recording medium such as a CD-ROM. Further, the budget management accounting computer program may be sold in a state preinstalled in the computer. When installed in a computer, the computer program is recorded on the hard disk of the computer main body 100 and executed by the CPU.

  Hereinafter, functions of the system 1 realized by the budget accounting computer program will be described. The functions of the system described below are realized by the computer according to the budget accounting computer program unless otherwise specified.

[3.1 Main functions of this system]
As shown in FIG. 2, the system 1 has, as main functions, a function as a data storage unit 110 that stores various data, and a processing unit 120 that performs various processes such as data input reception, data display, and data processing. It has the function of.
Data stored in the data storage unit 110 includes basic setting data and transaction data (budget / actual data), which are registered in the basic setting data registration unit 111 and the transaction data registration unit 112, respectively.
The processing unit 120 performs processing on input data or data registered in the data storage unit 110 to generate a screen to be displayed on the image display device 300, or perform processing such as data conversion. To do. The processing unit 120 controls the system 1, and the functions of the system described below are mainly functions of the processing unit 120.

[3.2 Menu screen of this system]
FIG. 3 shows a top menu screen D1 of the present system displayed on the image display device 300 by the processing unit 120. In the top menu, “transaction management” menu M2, “budget management” menu M3, “book inquiry” menu M4, “tabulation table” menu M5, “data linkage” menu M6, “backup” menu M7, “basic setting” menu M1 , And the menu of the “user setting” menu M8 can be selected by the user. The selection can be performed by the input processing device 200 such as a mouse.

[3.2.1 Basic setting menu]
FIG. 3 shows a state in which the “basic setting” menu M1 is selected on the menu screen D1. The “basic setting” menu M1 is for setting basic setting information unique to the user of the system 1. The “basic setting” menu M1 includes “registration information registration” M1-1, “accounting period”. “Registration” M1-2, “Account registration” M1-3, “Account / receipt address registration” M1-4, “Consumption tax rate registration” M1-5, “Cash type registration” M1-6, “Account item registration” M1-7, “Subject Branch Number Registration” M1-8, “Subject Branch Number List” M1-9, “Customer / Supplier Registration” M1-10, “Customer / Supplier List” M1-11 Various Operation Selection Buttons Is displayed.
Information set from the “basic setting” menu M 1 is registered in the basic setting data registration unit 111.

[3.2.2 Explanation of each operation of the basic setting menu]
In “office information registration” M <b> 1-1, basic setting information regarding the user of this system can be set. The basic setting information regarding the user includes the establishment name, establishment division, postal code, address, telephone number, FAX number, and consumption tax processing method. The basic setting information regarding the user includes information regarding the closing date of the user. The information on the closing date is configured as information indicating what time the closing date is (end of month end or specific day of each month).

In the “accounting period registration” M1-2, basic setting information relating to the accounting period such as the period name, the start date, the end date, and the start month of the accounting period can be registered.
In “account registration” M1-3, basic setting information (financial institution name, branch name, deposit type, account identification name, initial balance, balance date, etc.) of the account used by the user can be set.

  In “Account / Destination Registration” M1-4, it is possible to set basic setting information relating to a destination / account. The basic setting information related to the bank includes the bank book classification (cash, petty cash, deposit), item (cash, petty cash, savings, checking account), account name, bank name, balance, and the like.

In “consumption tax rate registration” M1-5, a consumption tax rate and the like can be set. In addition, in “fund type registration” M1-6, the type of funds can be set.
In “Account Item Registration” M1-7, it is possible to set basic setting information of an item (account item) input to an item input unit 512 described later.
By this account item registration, it is possible to register the account item and the classification of the input slip related to the account item, the item of the fund type, the item of profit management, the item of the balance sheet, and the item name of the settlement document. By making each registered item relevant, it is possible to create an expected balance sheet, profit management, cash flow chart, and other forms. In addition, accounts receivable and accounts payable transactions can be linked to the profit management table and the expected balance sheet by registering counterparty items.

The basic setting information for each course includes the name of each course, the classification of each course (classification of assets, liabilities, etc.), the fund type in each course (fund type in revenue / fund type in expenditure), information on profit management, balance The classification in the table is included. The course basic setting information includes information on whether each course is a cash register course. Therefore, when a subject is input to a subject input unit 512, which will be described later, the system 1 can distinguish whether the subject is a cash register subject or any other subject.
In addition, since the basic setting information of the subject includes the classification of each subject, when the subject is input in the subject input unit 512, which will be described later, the increase / decrease classification input unit 515, which is also described later, (Classification of debt, etc.) can be displayed automatically.

In “subject branch number registration” M1-8, one or a plurality of subject branch numbers can be set for each subject. In budget bookkeeping, all transactions are classified into items that can be easily budgeted and each branch is numbered and managed. Branch numbers are classified into three categories: customer, supplier, and subject branch number. In the accounts receivable transaction and the accounts payable transaction, the customer and the supplier itself are branch numbers. Account items such as other borrowings, salary allowances and entertainment expenses shall be subdivided into branch numbers.

The basic setting information of the subject branch number includes the subject, the category of the subject, the name of the subject branch number, the settlement method, the addressee, the beginning date, the beginning balance, and the description.
Further, the basic setting information of the subject branch number includes information on the closing date and / or the settlement date for the transaction registered as the subject branch number. The information on the closing date is composed of information on when the closing date is based on the transaction occurrence date, and information on what time is the closing date of each week, and information on the settlement date is what from the transaction occurrence date or the closing date. It consists of information about whether it is a day later. Since the system 1 can set basic setting information related to a closing date and / or a settlement date, when a transaction occurrence date is input as described later, the closing date and / or settlement is performed based on the transaction occurrence date. The system 1 can automatically calculate the day.
In the “subject branch number list” M1-9, a list of subject branch numbers registered in the “subject branch number registration” M1-8 can be displayed.

  In “customer / vendor registration” M1-10, basic setting information regarding the customer / vendor can be set. Basic setting information related to customers / suppliers includes customer / supplier distinction, customer / supplier name, transaction item with customer / supplier, item branch number, department, increase / decrease It is possible to register in advance “information indicating the type of transaction” entered on a transaction input screen 500, which will be described later, such as a classification, a settlement method, and a payment address. Therefore, the system 1 automatically inputs other “information indicating the type of transaction” simply by inputting (selecting) the name of the customer / vendor on the transaction input screen 500.

  Further, the basic setting information related to the customer / vendor includes a tax classification, a journal entry item, and an item branch number that are input in an amount input unit 530 of the transaction input screen 500 described later. Therefore, by registering tax classification, journal entry item, and item branch number for each transaction with the customer / supplier, the user enters the name of the customer / supplier on the transaction input screen 500. By simply selecting (selecting), the system 1 automatically inputs information on the tax classification, journal entry item, and item branch number in the amount input unit 530.

Further, the basic setting information related to the customer / vendor includes information related to the closing date and / or settlement date for the transaction with the customer / vendor. The information related to the closing date here is also composed of information about when the closing date is based on the date when the transaction occurs, and information about when the closing date is in each week. It consists of information on how many days after the closing date. This information is also used by the system 1 to automatically calculate the closing date and / or the settlement date based on the transaction occurrence date.
In the “customer / vendor list” M1-11, a list of customers / vendors registered in the “customer / vendor registration” M7-10 can be displayed.

[3.2.3 Transaction management menu]
FIG. 4 shows a state where the “transaction management” menu M2 is selected on the menu screen D1. The “transaction management” menu M2 is used to input a transaction that will occur in the future (or actually occurs), or to display a list of input transactions.

[3.3 Transaction input screen (transaction input slip screen)]
FIG. 5 shows a transaction input screen 500 displayed when “transaction input” M2-2 in the “transaction management” menu M2 is selected. This transaction input screen 500 is for inputting or displaying the contents of the transaction as budget data.
Data input on the transaction input screen 500 is registered in the transaction data registration unit 112 as budget / actual data (hereinafter also referred to as “budget data” or “transaction data”). Also, on this screen 500, once registered budget data can be corrected, and the amount of money in the budget data can be corrected to an actual value.
In addition, in the screen 500 of the present system 1, what has been described as “˜input unit” below also has a function as a “display unit” for displaying data, and thus can be rephrased as “˜display unit”. .

In this transaction input screen 500, data of a transaction in which a cash register item (current funds (cash, current account, ordinary deposit, etc.) or time deposit) is generated can be input. In addition, the transaction in which the account book item is generated can be divided into a balance item (income / expenditure) transaction and an expense item transaction.
Transactions in which a cash register item occurs can be divided into three categories No1 to No3 as shown in FIG.

  Of the three categories shown in FIG. 6, the first category (No. 1) is a transaction in which the “Account book item” occurs directly. Examples of transactions include “cash sales”, “cash purchase”, “ Social insurance premium cash payment, temporary payment cash payment, etc. In FIG. 6, these transactions are illustrated as transactions in which “cash” or “current account” is generated as a bank book item.

The second classification (No. 2) shown in FIG. 6 is a transaction in which a cash register item partially occurs, for example, a transaction such as “business trip temporary payment settlement”. When various account items are generated as in “Temporary payment settlement for business trip”, when journalizing is performed, for example, there are four journals as in the example of No. 2 in FIG. Of these four journals, the only item that has a deposit / debit item is [debit / credit] = [cash / units], which is a transaction in which a deposit / department item is partially generated. Note that the journal [debit / credit] = [cash / various] is a journal for the amount of the deposit / withdrawal amount input unit 571 of the transaction input screen 500.
The second division (No 2) can be omitted.

The third category (No. 3) shown in FIG. 6 is a transaction in which a cash register item is generated secondarily (a transaction in which a cash register item is not directly generated but payment or payment occurs at a later date). There are “sales sales”, “purchase purchases”, “payments payable”, and the like.
In the case of "account sales", for example, even if accrued sales occur and are recorded, the journal entry is [Debit / Credit] = [Accounts receivable / sales] as shown in the journal entry example, and there is a book item. do not do. However, if this account receivable is subsequently credited to the checking account, the journal entry is [Debit / Credit] = [Checking account / Accounts receivable], and the account item “Checking account” is secondary. To do.
Similarly, the “book deposit” and “payment unpaid” shown in FIG.

  Transactions for which no account book items are generated can be input not by the transaction input screen 500 but by the “subject transfer input” M2-7 in FIG. 4, but the details are omitted.

In the transaction input screen 500 of FIG. 5, budget data can be input for each transaction. That is, each item input from the screen 500 of FIG. 5 becomes a data item that constitutes budget data (transaction data) of one transaction.
The budget data input on the transaction input screen 500 includes information indicating the type of the transaction (including information used to convert the budget data into journal data), information on the settlement conditions of the transaction, and the amount related to the transaction (Settlement amount).
Further, on the transaction input screen 500, the state of budget data can be input. That is, when the budget data becomes a record, the change can be input.

  In the transaction screen 500, each time new budget data (transaction data) is input, a transaction NO (transaction ID: an identifier for individually identifying budget data (transaction data)) is given. It is displayed on the NO display unit 502. The transaction NO is registered in the transaction data registration unit 112 in association with each budget data.

  Among the budget data, the above-mentioned “information indicating the type of transaction” includes input classification, transaction partner, subject / subject branch number, department, increase / decrease classification of subject, summary, and the like.

  The “input classification” is input by the input classification input unit 501 and is information indicating whether the input transaction is a “income / expenditure” item transaction or an expense item transaction. The input classification input unit 501 is formed of a radio button GUI (graphical user interface), and can select either “income / expense” 501a or “expense” 501b.

  The “transaction partner” is information indicating a transaction partner such as a customer (seller) or a supplier, and can be input to the partner input unit 511 in the screen 500.

  The “subject” is information indicating a subject indicating the content of the transaction, and can be input to the subject input unit (subject field) 512. The transaction entered on this screen 500 is a transaction in which a cash register item is generated as described above, and the items entered in the course input unit 512 are “pay book item”, “multi-course subject”, and “other subject”. One of them.

The above three types of subjects input to the subject input unit 512 are prioritized according to the transaction categories shown in FIG. That is, if the first priority is given to No. 1 (transaction in which the cash register item directly occurs) in FIG. 6 and the account item is directly generated, the “account item” when the transaction is journalized. (Cash, checking account, etc.) is input to the subject input unit 512.
In addition, if the second priority is given to No. 2 (transaction in which the account book item is partially generated) in FIG. The data is input to the unit 512.

Further, in the case of No. 3 in FIG. 6 (transaction in which the account book item is generated secondarily), the partner item of the “account / book item” that is generated secondarily is input to the item input unit 512. For example, in the case of a transaction called credit sales, when a “bookkeeping transaction” called “payment” that occurs secondarily after a primary “bookkeeping transaction” called credit sales is journalized [debit / credit] If it becomes = [Checking Account / Accounts Receivable], “Accounts Receivable” which is the counterpart item of “Checking Account” which is “Account Book Item” is input to the item input unit 512.
It should be noted that courses other than “Account book subjects”, “Various course subjects”, and “Partner subjects” cannot be entered on this screen 500.

  The “subject” input in the subject input part (subject field) 512 is automatically transferred to the “journal item” field of the deposit amount display part 571 by the system 1. That is, the other subject of the “subject” entered in the subject input portion (subject column) 512 (the opposite subject when the journal is entered) is entered in the “Journaled subject” column of the transaction amount input portion 550 and the deduction amount input portion 560. Entered. These points will be described later.

The “subject branch number” is information indicating the branch number of the subject, and can be input to the subject branch number input unit 512.
The “department” is information indicating a department (sales department, personnel department, etc.) of a system user (company) involved in the transaction, and can be input to the department input unit 514.

The contents input to the destination input unit 511, the subject input unit 512, and the subject branch number input unit 512 are selected by selecting the search units 511a, 512a, and 513a to search for the pre-registered content. can do.
Further, in FIG. 5 and other display screens, the input contents do not have to be input from the keyboard, and can be simplified by selecting a registered item using a pull-down menu (not shown), inputting a date using a calendar, and inputting an amount using a calculator. Input is possible. These simple inputs can be input from a mouse without using a keyboard. Further, each piece of information to be input does not need to be input one by one. When certain information is input, the system 1 refers to the registered basic setting information and automatically generates other input target information. If possible, other input target information is automatically generated and displayed on the screen.

The “subject increase / decrease category” is information indicating whether the target transaction (subject entered in the subject input unit 512) increases or decreases assets / liabilities. Yes, input by the increase / decrease classification input unit 515. The target of increase / decrease is any of assets / liabilities / capital / revenue / expenses. The target of increase / decrease is based on the basic setting information according to the type of subject entered in the subject entry unit 512. Determine automatically.
This increase / decrease classification is an unnecessary input item from the viewpoint of simply entering a transaction, but it is necessary when generating journal data that is recorded separately from the budget data (transaction data) into debits and credits. .

  The “summary” is information indicating a summary of the transaction, and is input by the summary input unit 516.

  Further, in the budget data, information related to transaction settlement conditions includes information indicating a date (scheduled date) from the occurrence of the transaction to settlement. Information indicating the date (scheduled date) includes “transaction occurrence date”, “recording date”, “closing date”, “settlement date”, “bill delivery date”, and “bill maturity date”. These pieces of information are input from the settlement condition input unit 520.

  In this system 1, a transaction input method is adopted, and one or more “transactions on bookkeeping” can be input on one slip (transaction input screen 500). By having multiple dates from transaction to settlement as budget data (transaction data), even if one transaction is composed of multiple "bookkeeping transactions", it is the bookkeeping data from the budget data for each transaction Journal data can be created. Further, from the budget data, a cash flow chart / profit management table and various books described later can be created with transaction relevance.

The “transaction occurrence date” is information indicating a date (year / month / day) when the transaction occurs, and is input from the transaction occurrence date input unit 521. The “recording date” is information indicating a date when the profit / loss from the transaction is recorded, and is input from the recording date input unit 522.
As a general rule, the date of recording is the same as the date of transaction occurrence, so the date of the transaction occurrence date input section 521 is automatically posted, but if you want to make the profit / loss recording date different from the date of recording The recording date may be corrected in the recording date input unit 52.

The “closing date” is information indicating a closing date for summarizing bills every week, every 10 days, every month, and the like, and is input from the closing date input unit 523. When the information for calculating the closing date is set as the basic setting information, the closing date is automatically calculated based on the recording date and displayed on the closing date input unit 522.
For example, when “20th of every month” is set as the closing date, as shown in FIG. 5, if the transaction occurrence date is August 5, “August 20” is set as the closing date. (Closed date display section) 522.

The “settlement date” is information indicating the date of deposit or withdrawal to the current fund, and is input from the settlement date input unit 524. When the information for calculating the settlement date is set as the basic setting information, the settlement date is automatically calculated based on the recording date or the closing date and displayed on the settlement date input unit 524.
For example, when the settlement date is set to be “the end of the month following the closing date”, as shown in FIG. 5, “September 30” is set as the settlement date, and the settlement date input unit (settlement date display unit) 523.
In the case of cash transactions, the transaction occurrence date and the settlement date are the same date. In the case of bill settlement, the date is the same as the date of receipt and receipt of the bill (the date of receipt or the date of withdrawal).

The “Bill Transfer Date” is information indicating the date of receipt or the date of payment, and is input from the bill transfer date input unit 528.
The “note maturity date” is information indicating a settlement date in the case of bill settlement, and is input from the bill maturity date input unit 529. When the settlement method is a bill, the settlement date is preferentially used as the settlement date, not the date entered in the settlement date input unit 524 but the one entered in the bill maturity date input unit 529.

Further, in the budget data, information relating to the settlement conditions for transactions includes information relating to settlement methods. The information related to the payment method is information indicating a payment method with the other party that performs the transaction, and is input from the payment method input unit 525. The types of information indicated by the settlement method include cash, petty cash, check, bank transfer, bill and others.
Of the types of payment, “cash” is a payment method in which the payment details are reflected in the cash book, and “small cash” is a payment method in which the payment details are reflected in the cash book. “Check”, “Bank transfer” and “Bill” are settlement methods in which settlement details are reflected in the bank book.

In the case of the settlement method reflected in the bank book, the information regarding the transaction settlement conditions includes information regarding the bank account (bank). Information relating to the bank account (bank name, branch name, account type, etc.) is input from the bank account input unit 526. In the case of bill settlement, the bill settlement number (bill number) is included in the information regarding the transaction settlement conditions. The bill number included is input from the bill number input unit 527.

Furthermore, the transaction input screen 500 includes an amount input unit 530 for inputting a planned amount (settlement amount etc.) related to the transaction.
The amount related to the transaction is not limited to the settlement amount. In other words, the transaction amount with the business partner may be used as the settlement amount as it is, or the deposit or withdrawal will be made, or the amount deducted from the transaction amount or the amount deducted from the fee will be the settlement amount, Or it may be withdrawn.

Therefore, the amount input unit 530 of the present system 1 includes a deduction amount input unit 560 for inputting a deduction amount to be deducted, such as a discount, in addition to the transaction amount input unit 550 for inputting the transaction amount. The deposit / withdrawal amount after deduction is calculated.
The transaction amount input unit 550 is configured to be able to input a plurality of transaction amounts, and the deduction amount input unit 560 is also configured to be able to input a plurality of deduction amounts. ”Is displayed.
Deposit / withdrawal amounts are calculated by subtracting the sum of one or more deduction amounts, if any, from the sum of one or more transaction amounts. The calculated deposit / withdrawal amount is displayed on the deposit amount display unit 571.
The money amount input unit 530 is provided with a payment fee input unit 572 for inputting a payment fee such as a transfer fee at the time of withdrawal.

Thus, a plurality of amounts (transaction amount, deduction amount, acquisition amount, payment fee, etc.) associated with one transaction can be input or generated in the amount input unit 530.
Also, each of a plurality of amount input fields associated with one transaction corresponds to a “bookkeeping transaction” that constitutes one transaction, and one amount can be entered by inputting the amount into each field of the amount input unit 530. Transaction data can be broken down into multiple “bookkeeping transactions” to create multiple journal entries.

  In addition, in the input field for each amount in the amount input section 530, in addition to “Amount” in each column, “Consumption tax”, “Total” indicating the sum of the amount and consumption tax, and the tax classification of transaction amount or deduction amount "Tax category" to be displayed, "Journal item" and "Category branch number" when the journal entry is made can be entered.

As the “journal item”, the item entered in the item input unit (subject column) 512 when journalizing the transaction amount input unit 550 and the deduction amount input unit 560 corresponding to the “bookkeeping transaction” is entered. The subject to be the other subject is entered. For example, as shown in FIG. 5, when the item input to the item input unit 512 is “Accounts receivable”, the “Transaction amount 1” column in which the amount “40,000” is input in the transaction amount input unit 550 is displayed. When journalizing, this is a “bookkeeping transaction” called credit sales, and [Debit / Credit] = [Accounts receivable / Sales].
Therefore, “Sales”, which is the counterpart item of “Accounts receivable”, is input to “Journal item” in the “Transaction amount 1” column of the amount input section 530.
Similarly, in the “transaction amount 2” field and the “deduction amount 1” to “deduction amount 4” fields, when amounts are entered in the respective fields, they are similarly input to the item input section (subject field) 512. The subject that is the subject of the selected subject is entered.

  As described above, in the “Journal item” field of the deposit / withdrawal amount input unit (withdrawal amount display unit) 571, “Accounts receivable” input to the item input unit 512 is automatically transferred and displayed by the system.

  In addition, “branch number” for “journal item” is input to “subject branch number” in each column of transaction amount input unit 550 and deduction amount input unit 560.

  As described above, since the amount and the journal entry are entered in the amount input section in the transaction unit on the bookkeeping, the system 1 converts each amount entered in each column of the amount input section 530 into the journal data. When converting to, the item (and item branch number) in each journal data can be determined using the “journal item” (and “subject branch number”) input to the money amount input unit 530. Details of the method for converting to journal data will be described later.

  Furthermore, the transaction input screen 500 is provided with a state input unit 540 for inputting a progress state of budget data. The states that can be input from the state input unit 540 include “transaction occurrence”, “bill exchange”, “payment”, and “payment / withdrawal”. Since each state can be input in a check box format, a plurality of states can be selected. Further, when any state is selected in the state input unit 54, journal data is automatically generated from the budget data. This point will also be described later.

  “Transaction occurrence” in the status input unit 540 indicates that the expected transaction occurrence indicated by the budget data has actually been performed. “Bill exchange” indicates that the bill exchange for the transaction indicated by the budget data was actually performed. “Schedule” indicates that the transaction indicated by the budget data has been settled by partial payment. “Payment / withdrawal” indicates that the transaction indicated by the budget data has been settled.

FIG. 7 shows an input example on the screen 500 when a transaction actually occurs on August 5, 2007 for the budget data input as shown in FIG. Here, in the budget of FIG. 5, “transaction amount 1” was “40,000”, but the actual result was “45,000”. Note that the amount in the deposit / withdrawal amount display section 571 is automatically corrected.
In FIG. 7, the “transaction occurrence” check box in the state input unit 540 is selected, indicating that an actual transaction has occurred. In this case, the part (“transaction amount 1”) of the transaction amount input part 550 and the deduction amount 560 of the transaction budget data (transaction data) is the actual data, and the remaining part (the amount of money in and out) is Budget data remains.

  That is, if each state of the state input unit 540 is not selected, all of the transaction data of the transaction is budget data. However, when the “transaction occurrence” check box is selected, a part (of the amount and Date) becomes the actual data, and the budget and actual data are mixed. When the settlement of the transaction is completely completed, all the transaction data becomes actual data.

  Until the transaction is completed, a “continuing” display 504 is displayed on the screen. When the transaction is completed, the “continuing” display is deleted. In addition, when “payment / withdrawal” is selected in the status input unit 540, the transaction is completed. However, when special completion processing is required due to circumstances, the special completion input unit 570 causes the transaction to be completed. Make input for completion.

Further, the screen 500 has a registration button 505 and a cancel button 506. When the input content is stored in the transaction data storage unit 112, the user only has to press the registration button 5005 and want to cancel the input content. In that case, a cancel button 506 may be pressed.
Furthermore, the screen 500 has a data copying unit 503, and by selecting this, another transaction data having the same content is created.

[3.4 Example of transaction input]
Hereinafter, based on FIG. 8, an example of budget data (transaction data) about sales receivable with the customer “Company A” will be described.
Here, the settlement conditions with Company A are as follows.
1) Closing date: Closed on the 20th of every month 2) Settlement date: The end of the month following the closing date 3) Settlement method: Transfer (Bank B, C branch, current account transfer)
The current date is assumed to be August 15th.

Assume that the planned amount (budget) of the transaction with Company A assumed by the user (manager) of the system 1 in advance (before August 5) is as follows.
No. 1: August 5 Multi-sale scheduled amount 40,000 yen No. 2: August 10 wallet planned amount 50,000 yen No. 3: August 15 wallet planned amount 60,000 yen No. 4: August 20 wallet scheduled amount 70,000 yen No. 5: August 25th scheduled sale amount 80,000 yen No, 6: August 31th scheduled sale amount 90,000 yen

In addition, the transaction No. 1-No. 6, No1. ~ No. Reference numeral 3 denotes an actual transaction in which a transaction has actually occurred. The actual amount is as follows and is slightly different from the planned amount.
No. 1: August 5 Planned sales 45,000 yen No. 2: August 10 wallet planned amount of money 52,000 yen No. 3: August 15 wallet planned amount of money 59,000 yen

No. above. 1-No. 6 is input from the transaction input screen 500 in FIG. Here, the input values in FIG. Corresponds to one transaction. Other No. 2-No. No. 6 is also No. As in 1, the input is performed from the screen 500.
In addition, the above-mentioned No. 1-No. About each transaction of 6, "No101" thru | or "No106" are provided as an identifier (transaction NO) which this system provides.
Prior to August 5, any transaction (No. 101 to No. 106) is only a plan, and therefore the state selection by the state input unit 540 is not performed.

  Then, on August 5, since the transaction No. 101 of the transaction No. 101 to the transaction No. 106 has been confirmed as a record, a process for converting a part of the transaction data of the transaction No. 101 to record data is performed. Specifically, FIG. 7 shows a screen 500 for making the occurrence of a transaction No. 101 occur. That is, as shown in FIG. 7, the user changes the actual budget amount (transaction amount 1) 40,000 yen from the screen 500 to the actual amount 45,000 yen, and sets “transaction occurrence” in the state input unit 504. select. Thereby, the part of “transaction amount 1” of the amount input unit 530 in the transaction data of transaction No. 101 becomes the actual data.

Similarly, processing for making a transaction is performed for transaction No 102 and transaction No 103 as well.
FIG. 8 shows a transaction list screen 600 showing a transaction list when the generation of transactions from transaction No. 101 to transaction No. 103 is made a record. The transaction list screen 600 is a screen displayed when the “transaction list” button M2-1 is selected in the “transaction management” menu M2 shown in FIG.
When the “transaction list” button M2-1 is selected, the processing unit 120 of the system 1 refers to the transaction data registration unit 112, extracts transactions to be displayed, and forms the screen 600. Generate screen data.

As shown in FIG. 8, in the transaction list screen 600, there are a mixture of actual transactions in which transactions have already occurred (including transactions for which transactions have not been completed) and scheduled transactions in which transactions have not yet occurred. In order to make it easy for the user to distinguish between both transactions, both are displayed in different colors.
In FIG. 8, transaction No 101 to transaction No 103 are actual transactions, and transaction No 104 to transaction No 106 are scheduled transactions. In FIG. 8, the “transaction occurrence” column check box for each transaction No. 101 to transaction No. 103 is selected, and the “transaction occurrence” column check box for each transaction No. 104 to transaction No. 106 is not selected. However, by displaying the scheduled transaction and the actual transaction in different colors (highlight display; highlighting), the user can easily distinguish between the two.

  In FIG. 8, the actual transaction and the scheduled transaction are distinguished by the shading of characters. However, since the actual transaction list screen 600 is a color screen, the actual transaction character color (for example, black) and the scheduled transaction are displayed. The transaction color (for example, blue) is displayed in a different color.

  In addition, in the transaction list screen 600 of FIG. 8, in addition to the checkboxes, highlights are displayed for each state so that the user can easily understand the progress state (transaction occurrence to deposit / withdrawal) of each transaction. The In other words, in FIG. 8, a display that distinguishes between a state that has already occurred in each transaction (for example, the occurrence of a transaction) and a state that may occur in the future for each transaction but has not yet occurred (for example, a bill has been received or deposited). Is done.

Specifically, among the columns in FIG. 8 corresponding to the states “transaction occurrence”, “bills exchange”, “payment”, and “payment / withdrawal” that can be input in the state input unit 540 shown in FIG. The check box for the state that has occurred (actual part) is displayed on the white ground, and the check box for the state that may occur in the future but has not yet occurred is displayed on the blue background (the shaded area in FIG. 8 is highlighted). Has been.
Here, since there is no bill transaction in FIG. 8, the “Bill Exchange” column is not highlighted in any transaction.

The transaction list screen 600 can display the transaction data registered in the transaction data registration unit 112 (see FIG. 2) by narrowing it down with designated display conditions (filtering conditions). The display condition can be specified by a condition specifying unit 610 in the screen 600. The processing unit 120 of the system 1 extracts transactions that meet the conditions specified by the condition specifying unit 610 and displays them on the list display unit 620.
The list display unit displays almost all of the transaction data (budget data) of each transaction, but for ease of viewing the list, some of the items included in the transaction data may be omitted. In FIG. 8, the display of the transaction amount and the deduction amount is omitted.
In the transaction list screen 600, each transaction data can be corrected (amount of money, state, etc.).

[3.5 Borrow / Lease Entry and Other Entry]
As shown in FIG. 4, borrowing / lease other than transactions can be performed from “borrowing / lease input” M2-4, and the list can be displayed by “borrowing / lease list” M2-3, but the details are omitted. Also, “small expense transfer input” M2-5, “account transfer input” M2-6, and “subject transfer input” M2-7 can be performed, but details thereof are also omitted.

[3.6 Book inquiry menu]
FIG. 9 shows a state in which the “book inquiry” menu M4 is selected on the menu screen D1. The “book inquiry” menu M4 is for displaying various books based on the transaction data (budget / actual data) registered in the transaction data registration unit 112. In addition, the process part 120 produces | generates various books by referring basic setting information based on transaction data.

  This “book entry inquiry” menu M4 includes “account book” M4-1, “account balance confirmation table” M4-2, “subsidiary ledger” M4-3, “notes received” M4-4, “payment bills” Various selection buttons of “M4-5” and “Journal diary” M4-6 are displayed. When these buttons are selected, the processing unit 120 of the system 1 generates a corresponding book based on the transaction data (budget / actual data) registered in the transaction data registration unit 112 and displays it on the screen. To do.

  In the following, it is assumed that the transaction data regarding the transaction described in “3.2.3.2 Transaction Input Example” is registered in the transaction data registration unit 112, and the various books described below are 8 As of the 15th of the month.

[3.7 Account book]
FIG. 10 shows a deposit / departure screen 700 displayed when “account / paybook” M4-1 is selected. This cash register screen 700 has a display condition specifying unit 710 and a list display unit 720 showing the contents of the cash register.
The processing unit 120 generates a cash register with the cashier (B bank C branch current account) designated by the display condition designation unit 710 based on the payment date to the cashier (B bank C branch current account). The balance (expected balance) etc. is calculated and displayed.
In order to generate a cash register, it is only necessary to have data of a cash book item that occurs when journalizing among the “book transactions” constituting each transaction. Therefore, the processing unit 120 generates the data of the accounting book based on the data in which the accounting book item is specified in the “subject” or “journal item” input on the screen 500. In the case of FIG. 10, the processing unit 120 generates data of the cashbook from the date and amount of deposit / withdrawal in each transaction.

Similarly to the transaction list screen 600, the transaction book screen 700 also displays the scheduled transactions and the actual transactions in different colors, highlights the status of each transaction, and allows the user to easily grasp the status of each transaction.
According to the cash register screen 700, the expected balance at the cash register can be grasped. Further, since the user can grasp the relationship between the expected balance and the state of each transaction (whether actual transaction has occurred or not), it is easy to raise funds.

  Note that the screen when the “Account book balance confirmation table” M4-2 is selected is omitted, but the balance (expected balance) for each account destination is displayed in date order. Can be easily grasped.

[3.8 Subledger]
FIG. 11 shows an auxiliary ledger screen 800 displayed when “auxiliary ledger” M4-3 is selected. The auxiliary ledger screen 800 includes a display condition specifying unit 810 and a list display unit 820 showing the contents of the auxiliary ledger.
In order to generate the auxiliary ledger, the processing unit 120 narrows down the transaction data that is the target of the transaction data by the specified customer (customer / supplier) or item (subject branch number).
For example, as shown in FIG. 11, if the business partner is “Company A” and the item is “Accounts receivable”, the business partner input in the customer / vendor input unit 511 of the transaction input screen 500 is “A”. The transaction is “company” and the subject entered in the subject entry unit 512 or the subject entered in the “other subject” column of the amount input unit 530 is “Accounts receivable”. And in this case, transaction No101-No106 are extracted.

  When the processing unit 120 generates the auxiliary ledger, each transaction No. 101 to No. 106 is disassembled into “transactions on bookkeeping”, and “accounts receivable” (display conditions) are debited or credited when the transaction on bookkeeping is journalized. The auxiliary ledger is generated from the subject specified by the specifying unit 810. Therefore, a plurality of transactions having the same transaction NO exist in the auxiliary ledger. However, even if the “transaction” is broken down into multiple “bookkeeping transactions”, the same “transaction” is displayed in the subledger for the same “transaction”, so there are multiple “bookkeeping transactions”. The user can determine which is the same “transaction”.

Further, in order for the processing unit 120 to divide each transaction into “transactions on bookkeeping”, with reference to a plurality of amounts input by the amount input unit 530 on the screen 500, “ “Trade”.
In the “subject” column of the auxiliary ledger, the counterpart subject of the subject specified by the display condition specifying unit 810 is displayed.

  Also, in the auxiliary ledger screen 800, similar to the transaction list screen 600, the scheduled transaction and the actual transaction are displayed in different colors, and the state of each transaction is also highlighted, so that the user can easily grasp the state of each transaction.

  FIG. 12 shows another display example of the auxiliary ledger. In FIG. 12, unlike FIG. 11, the case where “subject” is designated as “sales” in the display condition designation unit 810 is shown.

  In addition, the balance of the subledger of the items (accounts receivable, accounts payable, accounts receivable, accounts payable, various accounts, etc., excluding the account book items) entered in the item input section 512 is always zero on the final settlement date. Become. Thereby, if the auxiliary ledger of the present system 1 is used, it is possible to easily find a delay in payment, delay in payment, omission of payment, omission of payment, and prevent these.

[3.9 Bills and Journal Diary]
When “Billing note book” M4-4 or “Billing note book” M4-5 is selected in the menu of FIG. 9, a billing note screen or a billing note screen is generated in the same manner as the auxiliary ledger. The process for generating the bill of exchange screen or the bill of exchange screen is the same as assuming that “notes of payment” or “notes of payment” are specified as the display condition designation item in the subledger. Detailed description is omitted.
Further, when “journal diary” M4-6 is selected in the menu of FIG. 9, a journal diary is generated. The journal diary is generated by extracting only “transactions on bookkeeping” that have been achieved from transaction data registered in the transaction data registration unit 112. Details of the journal diary generation process will be described later.

  As described above, in this system 1, the unit of transaction data is not “book transaction”, but the processing unit 120 has a function of decomposing transaction data into “book transaction”. As with a general accounting system, it is possible to generate data for various books such as a cash register and auxiliary ledger. And in each book data, since a scheduled transaction and a performance transaction are distinguished and displayed, it is easy for a user to grasp a schedule and a performance.

[3.10 Summary table menu]
FIG. 13 shows a state where the “tabulation table” menu M5 is selected on the menu screen D1. The “total table” menu M5 is used to display various total tables based on transaction data (budget / actual data) registered in the transaction data registration unit 112.

The “summary table” menu M5 includes “detail table” M5-1, “cash flow chart” M5-2, “profit plan table” M5-3, “manufacturing cost plan table” M5-4, and “marginal profit table”. Various selection buttons of M5-5, “Expected balance sheet” M5-7, and “Shareholders' equity change statement” M5-8 are displayed.
When these buttons are selected, the processing unit 120 of the system 1 generates a corresponding tabulation table based on the transaction data (budget / actual data) registered in the transaction data registration unit 112, and displays it on the screen. indicate. Further, the processing unit 120 generates various tabulation tables by referring to the basic setting information based on the transaction data. In the drawings related to the following description, it is assumed that only a part of the total table is displayed, not the entire total table, but in reality, the entire total table is displayed on the screen.

  Here again, it is assumed that the transaction data for the transaction described in “3.2.3.2 Transaction Input Example” is registered in the transaction data registration unit 112, and the various tabulation tables described below are as follows. As of August 15th.

Also, here, the cash flow schedule screen 900 when the “cash flow schedule” M5-2 is selected, the profit plan schedule screen 1000 when the “profit schedule table” M5-3 is selected, and the “expected balance sheet” M5. An example of the expected balance sheet 1100 when −7 is selected will be described.
FIG. 14 shows a cash flow table screen 900. The processing unit 120 calculates the monthly income from the settlement date (payment date) and the deposit / withdrawal amount (payment amount) of transactions No101 to No106 registered in the transaction data registration unit 112, and the cash flow chart shown in FIG. Is generated.

  FIG. 15 shows a profit plan table (profit statement) screen 1000. The processing unit 120 calculates the sales from the sales No. 101 to No. 106 registered in the transaction data registration unit 112 to the current month. Although omitted in FIG. 15, the profit plan table displays profits up to each month of the current fiscal year after deducting the cost of sales and expenses.

  FIG. 16 shows an expected balance sheet screen 1100. The processing unit 120 calculates items necessary for the balance sheet for each month in this period from the transactions No 101 to No 106 registered in the transaction data registration unit 112.

  Thus, even when displaying various summary tables, the processing unit 120 can divide the budget data into a plurality of “bookkeeping transactions”, and thus can create various summary tables in the same manner as a normal accounting system. These summary tables are based on the budget, and each summary table with the planned budget can be analyzed.

[3.11 Generation of journal diary]
FIG. 17 shows the relationship between transaction data (budget / actual data) registered in the transaction data registration unit 112 and journal diary data (journal data) generated from the transaction data by the processing unit 120. . As shown in FIG. 17, journal diary data (final journal) is generated from transaction data in which a budget and an actual result are mixed based on the “dealing transaction” as an actual result. Therefore, the journal diary data of the present system 1 does not have data relating to unconfirmed transactions.

On the other hand, in the above-described various books (excluding the journal diary) and various tabulation tables, forecast numbers that are generated from transaction data in which a budget and actual results are mixed for budget management and reflect the budget appear.
Here, if a journal is included in the journal diary data generated by the system 1, the journal for the budget is related to a bookkeeping transaction that does not yet exist. Should not be present in journal diary data in the accounting system.

  As a result, if the budget is included in the journal diary data generated by the system 1, the consistency with the journal diary data in a general accounting system is lost. Moreover, if journal diary data that can be used in a general accounting system is required, daily performance transactions must be recorded in a general accounting system different from the system 1.

On the other hand, in this system 1, various books (excluding journal diary) and various summary tables are generated from transaction data in which budgets and results are mixed, so that the user can see the numbers that reflect the budgets. Budget management can be appropriately performed using (except journal diary) or a summary table.
Moreover, in this system 1, since journal diary data can be created only from the actual transaction part excluding the planned transaction part of the transaction data, final journal diary data based only on the actual transaction can be obtained. Consistency with the accounting system is ensured.

Hereinafter, processing for generating journal diary data (journal data) from transaction data will be described.
In the journal diary data generation processing, the processing unit 120 inputs “subject” (subject information input in the subject input unit 512) and “increase / decrease category” (increase / decrease category input unit 515) included in each transaction data. This is done by generating journal data for each amount entered in each column of the amount input section 530 using the increase / decrease classification information).

Here, in order to generate journal data, it is necessary to determine what kind of courses the two courses in each journal have, and to decide whether the two courses are debits or credits.
Therefore, when generating the journal data, the processing unit 120 refers to the reference information shown in FIG. 18 and FIG. 19 based on the “subject” and “increase / decrease classification”, and determines what the debit item and the credit item in the journal data. Decide what will be.
The reference information shown in FIGS. 18 and 19 is configured as a table in which journal information for generating journal data is associated with input information “subject” and “increase / decrease”.

For example, reference information No. 1 shown in FIG. 18 indicates journal information when “subject” is an accounts receivable and “increase / decrease” is an increase. In addition, this transaction is a transaction in which the account book item occurs secondarily.
The journal information in the reference information No1 includes the journal information (No1-1) for the amount entered in the transaction amount input section (transaction amount column) 550, and the amount entered in the deduction amount input section (deduction item column) 560. Journal information (No1-2) and journal information (No1-3) about the amount of money in the deposit / withdrawal amount display section 571 are included.

In the journal information No. 1-1, information for journalizing individual amounts (“transactions on bookkeeping”) input in “transaction amount 1” or “transaction amount 2” in the amount input section 530 of the screen 500 is displayed. Show.
In journal information No. 1-1, [Debit item / Credit item] = “Accounts receivable / Journal item”, and “Accounts receivable”, which is “Item” input in the item input unit 512, becomes “Debit”. It shows that the counterpart item of “Accounts receivable” (the journal item entered in the “Journal item” field of the transaction amount input section 550) becomes “Credit”.

  In journal information No. 2-2, [Debit item / Credit item] = “Journal item / Accounts receivable”, “Accounts receivable”, which is the “Item” input in the item input unit 512, becomes “Credit”. It shows that the counterpart item of “Accounts receivable” (the journal item entered in the “Journal item” field of the deduction amount input section 560) becomes “debit”.

  In journal information No. 2-3, [debit item / credit item] = [account / account for accounts receivable], the account item related to the acquisition amount becomes “debit”, It shows that “Accounts receivable” in the “Account” column becomes “Credit”.

  In this way, by using the reference information, from the “subject” and “increase / decrease” included in the transaction data, the “subject” entered in the subject input unit 512 and the “journal subject” in the amount input unit 530 are displayed. It is possible to determine which is a debit and which is a credit among “journal subjects” (partner subjects of “subjects” input in the subject input unit 512) input in the “” column.

  In addition, the transaction indicated in the reference information No1 is a “transaction in which a cash register item is generated secondarily”, and a bookkeeping transaction (cash / withdrawal) in which the cash register item is generated is as follows: It is possible to determine which of the subjects in the “Journaling subject” column of the input unit 530 (the counterpart subject of the cash register subject) is debited and which is credited.

  That is, the processing unit 120 of the system 1 divides the transaction data into one or more “bookkeeping transactions” and then refers to the reference information so that the “subject” and “journal item” Two subjects can be identified. Moreover, since each transaction data has “increase / decrease” data for “subject” (item data), the transaction type is distinguished according to the increase / decrease category, and these two items are either debit or debit. Can be determined.

  When a plurality of amounts are input to the transaction amount input unit 550, a journal is generated for each amount. Further, when a plurality of amounts are input to the deduction amount input unit 560, a journal is generated for each amount.

  Further, the transactions shown in the reference information No. 2 to No. 4 shown in FIG. 18 and the reference information No. 12 to No. 13 shown in FIG. 19 are also “transactions in which a cash register item is secondarily generated”. Is set, and each amount in the amount input unit 530 can be journalized in the same manner as the reference information No1.

  Reference information No. 5 to No. 10 in FIG. 18 is reference information for “a transaction in which a cash register item directly occurs”. In the case of “transactions in which a bank account item is directly generated”, one of two subjects related to a bookkeeping transaction is a “book item” (the item input in the item input unit 512), and the other is “ "Another subject of the cash register subject". The “counter account subject” is a subject entered in the “journal subject” field of the transaction amount input section 530.

  For example, the reference information No. 5 is reference information for a transaction called cash sales, and the “subject” input to the subject input unit 512 is “account entry / exit”, and the “increase / decrease category” input to the increase / decrease category input unit 515. "Is" increase ", and the item entered in the" Journal item "field of the transaction amount input unit 550 is" cash sales ". In this No. 5, [Debit item / Credit item] = [Account book item / Cash sales], “Account book item” related to the acquisition amount becomes “Debit”, and “Journal” in the transaction amount input section 550 It shows that “cash sales” in the “subject” column becomes “credit”.

Reference information No. 11 in FIG. 19 is reference information for “a transaction in which a cash register item partially occurs”. In the case of a “transaction in which a cashier subject is partially generated” (when “subject” is “Momoguchi”), “Momoguchi” is debited from the amount entered in the transaction amount input unit 550 as shown in FIG. Journal entries ([Debit item / Credit item] = [Various accounts / Temporary payments]) and multiple journal entries (Debit item / Credit item) where [Various accounts] are credited = [Travel expenses / Expenses], [Entertainment expenses] / Various Accounts] and [Communication Fee / Various Accounts] are generated.
Further, from the amount input to the acquisition amount input unit 570, a journal entry of [debit item / credit item] = [account book item / units] is generated.

  The reference information shown in FIG. 18 and FIG. 19 is a representative example, and actually, a large amount of reference information is prepared according to the number of “subjects”.

  Further, as described above, the journal data is not generated from the entire transaction data including the budget, but is generated from the actual part of the transaction data. Which of the amounts (transactions on bookkeeping) input to the amount input unit 530 is the actual part is determined by the processing unit 120 according to the state of the transaction input by the state input unit 540.

  Here, the timing at which journal data is generated from transaction data is as follows. First, if the recorded date (transaction occurrence date) and the settlement date are the same date, journal data is generated when the planned transaction changes to an actual transaction (when the “transaction occurrence” state is selected). The Also, if the recording date (transaction occurrence date) and the settlement date are different, the journal data will be displayed when the “transaction occurrence” state is selected and when the “payment / withdrawal” state is selected. Generated. When a bill maturity date is entered in the bill maturity date input section 529 of the screen 500, when a “transaction occurrence” state is selected, a “bill transfer” state is selected, and a “payment / withdrawal” state is displayed. Journal data is generated when selected.

Hereinafter, the process of generating journal data from the actual part of the transaction data will be described based on a specific example.
Here, it is assumed that data shown in FIG. 20 is input as transaction data. This transaction data is budget data for which no transaction has yet occurred, as is clear from the fact that no state is selected in the state input unit 504.

In the budget data shown in FIG. 20, it is assumed that actual transaction occurrence (accounting for accounts receivable) is on October 16, 2007, and the “transaction occurrence” state of the state input unit 504 is selected.
In the “transaction occurrence” state, the information input to the transaction amount input unit 550 and the deduction amount input unit 560 in the amount input unit 530 becomes the actual part, and the date (recorded year) input to the recording date input unit 522 The date of October 16, 2007, which is the date, is also the actual result), so that a journal is generated for each amount (bookkeeping transaction) input to the transaction amount input unit 550 and the deduction amount input unit 560. .

That is, in the example of FIG. 20, since the item input unit 512 is “Accounts receivable” and the increase / decrease classification input unit 515 is “Increase”, the processing unit 120 refers to the reference information No1 shown in FIG. Based on the information of the input unit 550 and the deduction amount input unit 560, the following two items are generated as journal data dated October 16th.
10/16 [Debit / Credit] = [Accounts receivable: 350,000 yen / Sales: 350,000 yen]
10/16 [Debit / Credit] = [Sales rebate: 3,500 yen / Accounts receivable: 3,500 yen]

Then, when the settlement date (deposit date) of December 30, 2007 is reached and there is actually a deposit for the accounts receivable, and the “deposit / withdrawal” state of the status input unit 504 is also selected, the deposit / withdrawal amount input unit 571 The information entered in the field is the actual part, and the amount entered in the amount input unit 530 is input based on the date entered in the settlement date input unit 524 (the date of settlement, December 30, 2007 is also the actual result). Journal data regarding the amount of money (bookkeeping transaction) input to the section 571 is generated as follows with reference to the reference information No1 shown in FIG.
12/30 [Debit / Credit] = [Checking account: 346,500 yen / Accounts receivable: 346,500 yen]

  In addition to the above information, information included in transaction data such as “subject branch number” and “summary” is appropriately added to each journal data.

FIG. 21 shows other transaction data. This transaction data is also budget data for which a transaction has not yet occurred.
In the budget data shown in FIG. 21, it is assumed that actual transaction occurrence (payment of payables) is on October 20, 2007, and the “transaction occurrence” state of the state input unit 504 is selected.
Then, in the example of FIG. 21, since the item input unit 512 is “payable” and the increase / decrease classification input unit 515 is “increase”, the processing unit 120 refers to the reference information No. 12 shown in FIG. Based on the information of the input unit 550 and the deduction amount input unit 560, the following four items are generated as journal data dated October 20, which is the date of recording.
10/20 [Debit / Credit] = [Salary allowance: 350,000 yen / Accounts payable: 350,000 yen]
10/20 [Debit / Credit] = [Accounts payable: 35,000 yen / Legal welfare expenses: 35,000 yen]
10/20 [Debit / Credit] = [Accounts payable: 5,000 yen / Deposit: 5,000 yen]
10/20 [Debit / Credit] = [Accounts payable: 10,000 yen / Deposits: 10,000 yen]

Then, when the settlement date (payment date) on October 25, 2007 is actually withdrawn and the “withdrawal / withdrawn” state in the state input unit 504 is also selected, input to the settlement date input unit 524 Journal data about the amount (bookkeeping transaction) input to the deposit / withdrawal amount input unit 571 in the amount input unit 530 on the date (October 25, 2007) is the reference information No. 12 shown in FIG. With reference, it is generated as follows.
10/25 [Debit / Credit] = [Accounts payable: 300,000 yen / Current account: 300,000]

  20 and FIG. 21 is a case where a transaction in which transaction generation and deposit / withdrawal (settlement) occur on different days is input as “subject”, and a plurality of amounts in the amount input unit 530 are If a transaction that is accounted for on multiple dates but has a transaction and a deposit / withdrawal at the same time, such as a cash transaction (a transaction in which a cash register item occurs directly), is entered as an item, the transaction occurs. Journal entries are made when a state is selected.

  When the settlement method is a bill, bill exchange is performed for settlement. When the bill exchange is actually performed and the “Bill exchange” state is selected in the state selection unit 540, the journal with the acquisition amount entered in the deposit / withdrawal amount input unit 571 is made on the bill receipt date (settlement date) ( Recorded in bills book). Further, when the date entered in the bill maturity date input unit 529 is reached in the state where the “Bill Transfer” state is selected, the journal is automatically made with the deposit / withdrawal amount entered in the deposit / withdrawal amount input unit 571 (for the time being) Booked in funds).

FIG. 22 shows the flow of processing using the present system 1. When information regarding the closing date / settlement date is set as the basic setting information (step S1), transaction data serving as a budget is input on the transaction input screen 500 (step S2). At this time, the budget data may be “invoiced individual input” in which the invoiced amount is divided for each transaction occurrence, or multiple transactions with the same closing date are considered as one transaction in a lump sum, You may enter in.
Then, based on the transaction occurrence date input in step S2, the settlement date is automatically input on the screen 500.

  Further, when information regarding the closing date / settlement date is not set as the basic setting information (step S1), when entering transaction data as a budget on the transaction input screen 500 (step S4), a settlement date (necessary If there is a closing date, it is manually input (step S5).

  Then, the actual date has passed the transaction occurrence date input to the system, and the transaction is actually generated (from the budget to the actual result; step S6). At this time, if the actual transaction content is different from the transaction data content (amount, transaction occurrence date, etc.) as a budget (step S7), the transaction data content is adjusted from the screen 500 to the actual transaction. Correction is made (step S8).

  When a transaction occurs and transaction data is corrected or no correction is required, the user selects “transaction occurrence” in the status input unit 540 of the screen 500 (step S9).

  Further, the actual date passes the settlement date input to the system, and the settlement (payment / withdrawal) is actually performed (step S10). If the actual settlement amount (transfer amount) is the same as the deposit / withdrawal amount of the transaction data and there is no need to correct the amount or the like (step S11), the user selects the “paid / withdrawn” state in the state input unit 540. (Step S12). Then, it is assumed that the transaction has been completed, and the transaction data is in a completed state (step S13).

If it is necessary to make some corrections regarding the settlement in step S10 such that the actual settlement amount (transfer amount) is different from the deposit / withdrawal amount of the transaction data (step S11), processing for that is performed (steps S14, 15). ). For example, in the case of partial payment instead of batch, the “schedule” state is selected by the state input unit 540, and the partial payment processing is performed on a payment processing screen (not shown). The installment process is performed by setting the amount of each of multiple installments and the corresponding settlement date (transfer date).
In addition, when there is a situation in which transfer is not possible, special completion processing is performed in the special completion input unit 570 of the screen 500.

  Further, when an actual “bookkeeping transaction” occurs and is input to the system 1 as in the case of the transaction occurrence in step S9, the deposit / withdrawal in step S12, and the special completion process in step S15, the processing unit 120 Automatically creates journal data (final journal) based on the actual data of the transaction data (step S16). The journal data can be output to the outside of the system 1, and in a general accounting system, the journal data can be taken in and processed.

[3.12 Creating the next budget]
The processing unit 120 of the present system 1 inputs conditions for the forecasted forecast rate of the next budget on a monthly, quarterly, or year basis based on the transaction data (budget / actual data) for the current period, and automatically It also has a function as a budget creation means for creating budget data (transaction data).

  Budget data that can be created by the budget creation means is limited to transactions (income items, expenditure items, expense items) that can be entered from the screen 500. Borrowings / lease transactions cannot be included in the next budget because they can be entered for one to several years when creating a budget. In addition, with respect to the transfer of account book, small expense transfer, and item transfer, the system 1 does not automatically create a budget in order to accurately represent the state before the transfer. In addition, for transactions relating to the transfer of accounts, small expense transfers, and item transfers, after the next budget has been created, it may be input manually.

FIG. 23 shows a predicted value input screen (predicted value input means) 1200 for inputting a predicted value of the ratio between the transaction amount in the current period and the transaction amount in the next period. In the screen 1200 of FIG. 23, a predicted ratio value can be input for each month. The screen in FIG. 23 is a tabulation table of transaction data for the current period, and here, the sales to Company A are tabulated monthly. In the screen of FIG. 23, the forecast / actual amount for the current period (10,000 yen) can be displayed, and the ratio predicted value for each month can be input from the ratio predicted value input unit 1201. In the screen of FIG. 23, an amount obtained by multiplying the predicted / actual amount for the current period (10,000 yen) in the summary table by the predicted value of the ratio is displayed as an amount for the next period (10,500 yen).
With the screen of FIG. 23, it is possible to grasp the budget / actual results for the current period and the budget for the next period.

  Further, when the ratio predicted value is input, the transaction amount indicated by the individual transaction data (budget / actual data) belonging to the current period is multiplied by the predicted value to obtain the transaction data (budget data) for the next period. The forecast value is comprehensive in monthly units (quarterly or yearly), and is used for each transaction data for the current period included in the period to which the forecast value is applied.

In other words, it is assumed that the following transaction data (sales to company A) is as follows.
January 10: 3,000 yen January 15: 3,000 yen January 20: 4,000 yen

Then, as shown in FIG. 23, assuming that the predicted value of the ratio between the current period value and the predicted value for the next period is “105”%, the processing unit 120 determines that the predicted value of 105% for the three current periods. Multiply each transaction amount in the transaction data. Thereby, the processing unit 120 creates budget data for the next period with the amount of 105% from the transaction data (budget / actual data) for the current period.
FIG. 24 is a screen 1300 showing a transaction list showing each budget data for the next period. As shown in FIG. 23, in the display unit 1301 for the amount of three transactions in the current period, a numerical value multiplied by 105% is displayed.
The budget data for the next period generated by the processing unit 120 is registered in the transaction data registration unit 112.

The transaction data for the current fiscal year includes a mixture of budget and actual results. However, when the processing unit 120 generates the next transaction data (budget data) from the current transaction data, the progress status of each transaction data is all reset. , The transaction is left open. That is, the next transaction data is generated as complete budget data with no actual part.
Of the items included in the transaction data, items other than the amount, progress status, and date are copied directly to the next budget data as they are. The date included in the transaction data is changed from a numerical value indicating the current period to a numerical value indicating the next period, and the date is the same as that of the current period.

In the present embodiment, since the predicted value of the ratio can be input to the numerical value of the monthly unit (or quarter quarter / year unit) summarized in the aggregation table, the annual budget of the next budget in the monthly unit (or quarter quarter / year unit) The overall picture can be easily grasped.
Moreover, in order to create budget data for the next period by multiplying the forecast values entered in monthly units (or quarterly / yearly units) with individual transaction data, detailed daily transactions based on the current period transaction data. Next budget data for can be created. Therefore, the user can browse various forms and tabulation tables on the system 1 based on the budget data for the next period, and easily obtain various materials related to the management for the next period.
Note that the function for creating the next budget data described above is not limited to creating the next budget data from the current transaction data, but can create budget data for the second and subsequent periods from the current transaction data, It is also used to create budget data for the next and subsequent periods from transaction data for the next period.

  In addition, this invention is not limited to the said embodiment, A various deformation | transformation is possible within the range of the matter described in the claim.

Further, this specification is not intended to disclose only the invention described in the claims, but also to disclose various inventions other than the invention described in the claims.
In particular, the description of the above embodiment includes a description of another invention that does not require some or all of the elements in the invention described in the claims. Should be understood without being bound by the problems and solutions relating to the invention described in the claims.

It is a figure which shows the flow of the current fund in a budget bookkeeping. It is a functional block diagram of this system. It is a menu screen of this system. It is a menu screen of this system. It is a transaction input screen of this system. It is a division figure of the subject inputted into a subject input part. It is a transaction input screen of this system. It is a transaction list screen of this system. It is a menu screen of this system. It is a cash register screen of this system. It is a subledger screen of this system. It is a subledger screen of this system. It is a menu screen of this system. It is a cash flow chart screen of this system. It is a profit plan table screen of this system. It is an expected balance sheet screen of this system. It is a relationship diagram of budget / actual data and journal diary data. It is a figure which shows a reference information table. It is a figure which shows a reference information table. It is a transaction input screen of this system. It is a transaction input screen of this system. It is a flowchart which shows the flow of the process using this system. It is a summary table screen for inputting the ratio forecast value of the next budget. It is a transaction list screen showing the budget data of the next budget.

Explanation of symbols

1 Budget management accounting computer system 112 Transaction data registration section (storage means)
120 processing unit (journal data generation means, setting means, generation means, etc.)
500 Transaction input screen (input means)

Thus, a plurality of amounts (transaction amount, deduction amount, deposit / withdrawal amount, payment fee, etc.) associated with one transaction can be input or generated in the amount input unit 530.
Also, each of a plurality of amount input fields associated with one transaction corresponds to a “bookkeeping transaction” that constitutes one transaction, and one amount can be entered by inputting the amount into each field of the amount input unit 530. Transaction data can be broken down into multiple “bookkeeping transactions” to create multiple journal entries.

In addition, the transaction No. 1-No. 6, No1. ~ No. Reference numeral 3 denotes an actual transaction in which a transaction has actually occurred. The actual amount is as follows and is slightly different from the planned amount.
No. 1: August 5 Actual sales amount 45,000 yen No. 2: August 10 Actual sales amount 52,000 yen No. 3: August 15 Actual sales amount 59,000 yen

In journal information No. 1-2 , [Debit item / Credit item] = “Journal item / Accounts receivable”, and “Accounts receivable” which is “Item” input in the item input unit 512 becomes “Credit”. , The counterpart item of “Accounts receivable” (the journal item entered in the “Journal item” column of the deduction amount input section 560) is “debit”.

In the journal information No 1 -3, has become a [debit / credit courses] = [journal subjects / accounts receivable], journal subjects related to obtaining money becomes "debit", of the deposit and withdrawal amount display part 571 It shows that “Accounts receivable” in the “Journal item” column becomes “Credit”.

  The present invention relates to an accounting computer system for budget management and a computer program thereof.

  As an apparatus for performing budget management, for example, there is one described in Patent Document 1. Patent Document 1 describes a fund management apparatus for checking the presence or absence of a fund short by inputting predicted transaction data related to a payment schedule or a payment schedule. In this money management apparatus, the predicted transaction data (fund management data) is changed to fixed data and becomes accounting data over time.

This accounting data is collectively transferred to general-purpose computer accounting and used for accounting operations. In other words, the general-purpose computer accounting side can perform a series of accounting operations from creation of a trial balance, creation of a general ledger, creation of an auxiliary ledger to settlement of accounts based on the transferred accounting data.
As described above, the apparatus of Patent Document 1 is configured such that when the budget data created for budget management is changed to fixed data, the fixed data can be diverted as accounting data.
JP 2004-302979 A

In the apparatus of Patent Document 1, the budget data that is the basis of the fixed data is formed in units of “transactions on bookkeeping” so that the fixed data can be diverted to the accounting data.
In other words, in the apparatus of Patent Document 1, the data structure of budget data and fixed data is basically the same, and the budget data whose scheduled date has passed is merely handled as fixed data.
And since the said fixed data is diverted as accounting data, it needs to be comprised as a journal (journal diary). In the journal, the cause and result of the transaction are recorded separately in debits and credits for each “bookkeeping transaction”.

  For this reason, in the apparatus of Patent Document 1, budget data that is the basis of finalized data is also created on a “bookkeeping transaction” basis, such as deposit (plan) and withdrawal (plan).

  However, the concept of “bookkeeping transactions” and the concept of “transactions” (hereinafter also referred to as “general transactions”) in daily corporate activities are not completely the same. The present inventor has come up with the idea that budget management can be performed more accurately if budget management is performed according to the concept of “general transactions”.

Here, for example, consider a transaction called accounts receivable sales with a set deadline. Here, it is assumed that the closing date is the 20th of every month and the accounts receivable sales are settled (paid) 70 days after the closing date.
In this case, for example, if there is sales of 350,000 yen (transaction occurrence) on October 16, the settlement date (payment date) is December 30.
In the concept of “general transaction”, it is considered that “one transaction” is from the generation of the accounts receivable to the settlement. In other words, this is because both the generation of accounts receivable and the settlement are related to “one commercial activity” of “sold 350,000 yen”.

  On the other hand, in the “bookkeeping transaction” concept, the transaction generation and settlement of the accounts receivable sales are two transactions. In other words, when carrying out bookkeeping journals, the journal for sales of 350,000 yen (transaction occurrence) on October 16 and the journal for payment of 350,000 yen (payment) on December 30 are performed. Is called.

  Therefore, when a budget is managed in accordance with the concept of “book transaction”, a plurality of “book transactions” related to “one business activity” are handled separately. A plurality of “bookkeeping transactions” related to “one business activity” is not limited to two as described above, but may be more. As a result, if budget management is performed in accordance with the concept of “bookkeeping transactions”, the relationship between a plurality of “bookkeeping transactions” is difficult to understand, resulting in difficult budget management.

In this way, conventional bookkeeping is excellent for recording actual transactions in the past, but it is not suitable for predicting the future based on transactions expected in the future, making budget management difficult. To.
On the other hand, in order to enable linkage with a general accounting system, the data of transactions actually performed in budget management are not data of “general transactions” but of “book transactions”. The journal data is more advantageous.

  Therefore, in the present invention, a budget can be established in units of “general transactions” rather than in units of “general transactions”, which is common sense in accounting computer systems. The purpose is to enable journal entry data to be obtained when a transaction is actually carried out and the budget is changed to an actual result, while a budget is established in units of “nasty transactions”.

The present invention is an accounting computer system for performing budget management,
A transaction input screen (500) for receiving input of budget data for each transaction is displayed on the image display device (300) of the computer, and the budget data input on the transaction input screen (500) is received. A processing unit (120) for performing data processing for generating various book data such as a cash book or various summary table data such as an expected balance sheet based on the inputted budget data;
Storage means (112) for storing the inputted budget data;
With a computer that functions as
The budget data for one transaction is
Subject data indicating the subject of the transaction indicated by the budget data;
Increase / decrease classification data indicating whether the item indicated by the item data is to increase or decrease assets, liabilities, capital, revenue, or expenses;
A transaction date indicating the date on which the transaction occurs and a date indicating the scheduled date of the settlement date of the transaction;
A transaction amount of the transaction, a deduction amount to be deducted from the transaction amount, and a deposit / withdrawal amount obtained by subtracting the deduction amount from the transaction amount;
A first journal entry for the transaction amount;
A second journal entry for the deduction amount;
A third journal entry for the deposit and withdrawal amount;
Information indicating the state of occurrence of the transaction to indicate that the transaction amount and the deduction amount in the budget data are actual amounts;
Information indicating the state of deposit / withdrawal to indicate that the deposit / withdrawal amount in the budget data is an actual amount;
Including data,
The transaction input screen (500) displayed on the image display device (300) by the processing unit (120) is:
A subject input section (512) for inputting the subject data;
An increase / decrease classification input unit (515) for inputting the increase / decrease classification data;
A payment condition input unit (520) for inputting the date;
The transaction amount, the deduction amount, and the deposit / withdrawal amount can be separately input, and each has an input field for each amount, and the first journal item for the transaction amount, the deduction amount An amount entry section (530) having a journal entry field for inputting a second journal entry item and a third journal entry item for the deposit / withdrawal amount;
In order to indicate that the transaction amount, the deduction amount, and the deposit / withdrawal amount in the budget data have become actual amounts, it is possible to input a transaction occurrence state and a deposit / withdrawal state as the progress state of the budget data. A state input unit (540) capable of
Comprising a plurality of data items constituting one budget data corresponding to one transaction, and configured as a single screen.
The journal information for generating journal data including data indicating the debit item, the credit item, the amount of the debit item, and the amount of the credit item is associated with each combination of the plurality of item data and the increase / decrease classification data. The computer has a reference information table;
The journal information includes the item data in the budget data and the first to third journal item data, which is the debit item data in the journal data, and which is the credit item data in the journal data. A debit item that becomes a debit and a credit that becomes a credit when the transaction amount is converted into journal data, and a debit and a credit that becomes a credit item that becomes a debit when the deduction amount is converted into journal data The debit item to be debited and the credit item to be credited when the deposit / withdrawal amount is used as journal data are set for the transaction amount, the deduction amount, and the deposit / withdrawal amount, respectively.
The processing unit (120)
For the budget data in which the transaction occurrence state is input to the state input unit (540), journal data for each of the transaction amount and the deduction amount in the budget data in which the transaction occurrence state is input is generated, and the state input For the budget data in which the state of deposit / withdrawal has been input to the part (540), the journal data of the deposit / withdrawal amount in the budget data in which the state of deposit / withdraw has been input is entered through the transaction input screen (500) Means to generate from the budgeted data,
The means for generating the journal data includes:
When the state of transaction occurrence is input to the state input unit (540), the reference information table is referred to based on the subject data and the increase / decrease classification data, and the transaction amount in the reference information table is journalized. The debit item and the credit item determined by the information and the debit item and the credit item determined by the journal information about the transaction amount are set as the debit item and the credit item constituting the journal data about the transaction amount. By generating the transaction amount as the amount of the debit item and the amount of the credit item constituting the journal data for the transaction amount, the journal data for the transaction amount at the transaction date is generated, and the reference information table Determine the debit item and credit item according to the journal information about the deduction amount in The debit item and credit item determined by the journal information about the debit item and the credit item that constitutes the journal data for the deduction amount, and the deduction amount in the budget data is the debit that constitutes the journal data for the deduction amount By using the amount of the item and the amount of the credit item, the journal data for the deduction amount at the transaction date is generated,
When the state of deposit / withdrawal is input to the status input unit (540), the reference information table is referred to based on the subject data and the increase / decrease classification data, and the deposit / withdrawal amount in the reference information table is determined. The debit item and the credit item are determined by the journal information, and the debit item and the credit item determined by the journal information about the deposit / withdrawal amount are set as the debit item and the credit item constituting the journal data about the deposit / withdrawal amount, By generating the deposit / withdrawal amount in the budget data as the debit item amount and the credit item amount constituting the journal data for the deposit / withdrawal amount, the journal data for the deposit / withdrawal amount at the settlement date is generated. To
This is a budget management accounting computer system .

−

  The subject indicated by the subject data is preferably an account subject and a counterpart subject in which the account subject is secondarily generated.

−

  The input means is configured to be able to input a transaction occurrence date as a date related to a transaction indicated by budget data, and the system is configured to set information for calculating a closing date and / or a settlement date from the transaction occurrence date; And generating means for generating a closing date and / or a settlement date as date data relating to the transaction indicated by the budget data based on the information set by the setting means when a transaction occurrence date is input. It is preferable.

Budget generating means for generating, from a plurality of budget data belonging to the first accounting period, a plurality of budget data belonging to a second accounting period after the first accounting period;
The budget creation means includes
Predicted value input means for receiving an input of a predicted value of the ratio of the transaction amount indicated by the budget data of the second accounting period to the transaction amount indicated by the budget data of the first accounting period;
The progress state of the individual budget data included in the first accounting period is reset to a state in which no transaction has occurred, and the year of the dates of the individual budget data included in the first accounting period is the first 2 to the numerical value indicating the accounting period, and by multiplying the transaction amount of each budget data included in the first accounting period by the predicted value of the ratio, a plurality of budget data for the first accounting period is obtained. Conversion means for converting into a plurality of budget data for the second accounting period;
Is preferably provided .

  Another aspect of the present invention is a computer program for causing a computer to function as the budget management accounting computer system.

  According to the present invention, it is possible to establish a budget in units of “general transactions” in which the period from the occurrence of a transaction to the settlement of the transaction is considered as one transaction.

  Moreover, in the present invention, the journal data generation means generates journal data on the bookkeeping transaction actually performed from the data related to the bookkeeping transaction actually performed in the budget data. Journal data can be obtained while setting a budget for each "general transaction".

[Definition of terms]
The term “transaction” refers to the period from the occurrence of revenue or expenditure (transaction occurrence) to the deposit or withdrawal (transaction settlement) of the current funds. Here, “transaction” has almost the same concept as “transaction” (general transaction) in general commercial transactions. In addition, the “transaction” here is composed of one or a plurality of “bookkeeping transactions”.
Note that terms not specifically defined here and not specifically described below follow the usage in bookkeeping or ordinary accounting computer systems.

[1. About budget bookkeeping]
Budget bookkeeping is bookkeeping for budgeting a company's management plan as a number by bookkeeping and indicating the direction in which the company should proceed. Budget bookkeeping can be performed by a budget management accounting computer system described later.
When a manager (a user of a budget management accounting computer system) predicts the near future of a company and makes a short-term and long-term management plan, the budget bookkeeping (budget management accounting computer system) uses that number as a specific budget. And provide “flow of funds” and “size of profit and loss” in real time.
In normal bookkeeping, journal entries are entered based on actual results (actual transactions), but in budget bookkeeping, transactions that are known in advance are entered, and if there are changes, future predictions are made. Can do.

[2. Budget Bookkeeping Basics]
[2.1 Budget to actual results]
Make a business plan for the company's quarter to three years, etc., subdivide the business plan for each transaction, enter it into the budget bookkeeping (to the budget management accounting computer system), and budget it specifically as a number.
Budget bookkeeping provides information on the “flow of funds” and “the magnitude of profits and losses” that are most needed by companies through this budgeting, using the expected balance sheet, profit management table, and cash flow table as future forecasts.
In budget bookkeeping, when the budget changes to actual results due to the passage of time, the budget is changed to actual results in a simple and simple way in accordance with this change, and the latest information is provided in real time at any time. .

[2.2 Flow of current funds]
Budget bookkeeping considers the flow of funds mainly from current funds that can be exchanged immediately (cash, current accounts, ordinary deposits, postal savings, notice deposits, etc.). Time deposits are not included in the current funds.

  In the budget bookkeeping, as shown in FIG. 1, if the current fund enters the company, it is processed as income, and if it comes out of the company, it is processed as expenditure. From the viewpoint of the current funds, it is income if you enter, and expenditure if you leave. It is the same way of thinking as a household account book. In addition, although there are expenses that are not related to the balance of current funds, such as depreciation expenses, among these items, these items are processed outside the funds and unrelated to the current funds.

[2.3 General transaction input method]
A feature of budget bookkeeping (budget management accounting computer system) is that a company's economic activities are input for each transaction (expected transaction) in a manner similar to a general sales management system.
Budget bookkeeping is similar to a general “transaction input method” because it inputs a business partner, a transaction amount, and a date related to a transaction (transaction occurrence date, settlement date, etc.) for each transaction.
The same transaction content is devised so that it can be easily input by copying the previous transaction or transferring the small amount of expenses.

In budget bookkeeping, anyone can enter a budget (expected transaction) using a general “transaction input method”, which is different from the “journal entry method” for debit and credit input, which is the basic principle of bookkeeping.
In the budget bookkeeping, journal entries (journal data) are automatically created when a certain condition is met by inputting the subject (• subject branch number) for automatic journal entry.
In the budget management accounting computer system described later, the computer program supports bookkeeping knowledge, so even if the user does not know bookkeeping, the “flow of current funds”, “size of profit / loss”, “date of funds shortage” ”And“ Non-collection of accounts receivable ”can be accurately grasped.

[3. Budget accounting accounting computer system]
A budget management accounting computer system (hereinafter simply referred to as “system”) 1 according to an embodiment of the present invention will be described below with reference to the drawings.

The system 1 is configured by installing a budget management accounting computer program for functioning as the system in a computer.
As shown in FIG. 2, the computer includes a processing unit (CPU), an internal storage device such as a ROM / RAM, an external storage device such as a hard disk, an input processing device 200 such as a keyboard / mouse, The image display apparatus 300 and the printing apparatus 400 are connected to each other.

  The budget accounting computer program can be recorded and sold on a (portable) recording medium such as a CD-ROM. Further, the budget management accounting computer program may be sold in a state preinstalled in the computer. When installed in a computer, the computer program is recorded on the hard disk of the computer main body 100 and executed by the CPU.

  Hereinafter, functions of the system 1 realized by the budget accounting computer program will be described. The functions of the system described below are realized by the computer according to the budget accounting computer program unless otherwise specified.

[3.1 Main functions of this system]
As shown in FIG. 2, the system 1 has, as main functions, a function as a data storage unit 110 that stores various data, and a processing unit 120 that performs various processes such as data input reception, data display, and data processing. It has the function of.
Data stored in the data storage unit 110 includes basic setting data and transaction data (data in which budget / actual results are mixed ), which are registered in the basic setting data registration unit 111 and the transaction data registration unit 112, respectively.
The processing unit 120 performs processing on input data or data registered in the data storage unit 110 to generate a screen to be displayed on the image display device 300, or perform processing such as data conversion. To do. The processing unit 120 controls the system 1, and the functions of the system described below are mainly functions of the processing unit 120.

[3.2 Menu screen of this system]
FIG. 3 shows a top menu screen D1 of the present system displayed on the image display device 300 by the processing unit 120. In the top menu, “transaction management” menu M2, “budget management” menu M3, “book inquiry” menu M4, “tabulation table” menu M5, “data linkage” menu M6, “backup” menu M7, “basic setting” menu M1 , And the menu of the “user setting” menu M8 can be selected by the user. The selection can be performed by the input processing device 200 such as a mouse.

[3.2.1 Basic setting menu]
FIG. 3 shows a state in which the “basic setting” menu M1 is selected on the menu screen D1. The “basic setting” menu M1 is for setting basic setting information unique to the user of the system 1. The “basic setting” menu M1 includes “registration information registration” M1-1, “accounting period”. “Registration” M1-2, “Account registration” M1-3, “Account / receipt address registration” M1-4, “Consumption tax rate registration” M1-5, “Cash type registration” M1-6, “Account item registration” M1-7, “Subject Branch Number Registration” M1-8, “Subject Branch Number List” M1-9, “Customer / Supplier Registration” M1-10, “Customer / Supplier List” M1-11 Various Operation Selection Buttons Is displayed.
Information set from the “basic setting” menu M 1 is registered in the basic setting data registration unit 111.

[3.2.2 Explanation of each operation of the basic setting menu]
In “office information registration” M <b> 1-1, basic setting information regarding the user of this system can be set. The basic setting information regarding the user includes the establishment name, establishment division, postal code, address, telephone number, FAX number, and consumption tax processing method. The basic setting information regarding the user includes information regarding the closing date of the user. The information on the closing date is configured as information indicating what time the closing date is (end of month end or specific day of each month).

In the “accounting period registration” M1-2, basic setting information relating to the accounting period such as the period name, the start date, the end date, and the start month of the accounting period can be registered.
In “account registration” M1-3, basic setting information (financial institution name, branch name, deposit type, account identification name, initial balance, balance date, etc.) of the account used by the user can be set.

  In “Account / Destination Registration” M1-4, it is possible to set basic setting information relating to a destination / account. The basic setting information related to the bank includes the bank book classification (cash, petty cash, deposit), item (cash, petty cash, savings, checking account), account name, bank name, balance, and the like.

In “consumption tax rate registration” M1-5, a consumption tax rate and the like can be set. In addition, in “fund type registration” M1-6, the type of funds can be set.
In “Account Item Registration” M1-7, it is possible to set basic setting information of an item (account item) input to an item input unit 512 described later.
By this account item registration, it is possible to register the account item and the classification of the input slip related to the account item, the item of the fund type, the item of profit management, the item of the balance sheet, and the item name of the settlement document. By making each registered item relevant, it is possible to create an expected balance sheet, profit management, cash flow chart, and other forms. In addition, accounts receivable and accounts payable transactions can be linked to the profit management table and the expected balance sheet by registering counterparty items.

The basic setting information for each course includes the name of each course, the classification of each course (classification of assets, liabilities, etc.), the fund type in each course (fund type in revenue / fund type in expenditure), information on profit management, balance The classification in the table is included. The course basic setting information includes information on whether each course is a cash register course. Therefore, when a subject is input to a subject input unit 512, which will be described later, the system 1 can distinguish whether the subject is a cash register subject or any other subject.
In addition, since the basic setting information of the subject includes the classification of each subject, when the subject is input in the subject input unit 512, which will be described later, the increase / decrease classification input unit 515, which is also described later, (Classification of debt, etc.) can be displayed automatically.

In “subject branch number registration” M1-8, one or a plurality of subject branch numbers can be set for each subject. In budget bookkeeping, all transactions are classified into items that can be easily budgeted and each branch is numbered and managed. Branch numbers are classified into three categories: customer, supplier, and subject branch number. In the accounts receivable transaction and the accounts payable transaction, the customer and the supplier itself are branch numbers. Account items such as other borrowings, salary allowances and entertainment expenses shall be subdivided into branch numbers.

The basic setting information of the subject branch number includes the subject, the category of the subject, the name of the subject branch number, the settlement method, the addressee, the beginning date, the beginning balance, and the description.
Further, the basic setting information of the subject branch number includes information on the closing date and / or the settlement date for the transaction registered as the subject branch number. The information on the closing date is composed of information on when the closing date is based on the transaction occurrence date, and information on what time is the closing date of each week, and information on the settlement date is what from the transaction occurrence date or the closing date. It consists of information about whether it is a day later. Since the system 1 can set basic setting information related to a closing date and / or a settlement date, when a transaction occurrence date is input as described later, the closing date and / or settlement is performed based on the transaction occurrence date. The system 1 can automatically calculate the day.
In the “subject branch number list” M1-9, a list of subject branch numbers registered in the “subject branch number registration” M1-8 can be displayed.

  In “customer / vendor registration” M1-10, basic setting information regarding the customer / vendor can be set. Basic setting information related to customers / suppliers includes customer / supplier distinction, customer / supplier name, transaction item with customer / supplier, item branch number, department, increase / decrease It is possible to register in advance “information indicating the type of transaction” entered on a transaction input screen 500 to be described later, such as a classification, a settlement method, and a payment address. Therefore, the system 1 automatically inputs other “information indicating the type of transaction” simply by inputting (selecting) the name of the customer / vendor on the transaction input screen 500.

  Further, the basic setting information related to the customer / vendor includes a tax classification, a journal entry item, and an item branch number that are input in an amount input unit 530 of the transaction input screen 500 described later. Therefore, by registering tax classification, journal entry item, and item branch number for each transaction with the customer / supplier, the user enters the name of the customer / supplier on the transaction input screen 500. By simply selecting (selecting), the system 1 automatically inputs information on the tax classification, journal entry item, and item branch number in the amount input unit 530.

Further, the basic setting information related to the customer / vendor includes information related to the closing date and / or settlement date for the transaction with the customer / vendor. The information related to the closing date here is also composed of information about when the closing date is based on the date when the transaction occurs, and information about when the closing date is in each week. It consists of information on how many days after the closing date. This information is also used by the system 1 to automatically calculate the closing date and / or the settlement date based on the transaction occurrence date.
In the “customer / vendor list” M1-11, a list of customers / vendors registered in the “customer / vendor registration” M7-10 can be displayed.

[3.2.3 Transaction management menu]
FIG. 4 shows a state where the “transaction management” menu M2 is selected on the menu screen D1. The “transaction management” menu M2 is used to input a transaction that will occur in the future (or actually occurs), or to display a list of input transactions.

[3.3 Transaction input screen (transaction input slip screen)]
FIG. 5 shows a transaction input screen 500 displayed when “transaction input” M2-2 in the “transaction management” menu M2 is selected. This transaction input screen 500 is for inputting or displaying the contents of the transaction as budget data.
The data input on the transaction input screen 500 is registered as budget data (hereinafter also referred to as “transaction data”) in the transaction data registration unit 112. Also, on this screen 500, once registered budget data can be corrected, and the amount of money in the budget data can be corrected to an actual value.
In addition, in the screen 500 of the present system 1, what has been described as “˜input unit” below also has a function as a “display unit” for displaying data, and thus can be rephrased as “˜display unit”. .

In this transaction input screen 500, data of a transaction in which a cash register item (current funds (cash, current account, ordinary deposit, etc.) or time deposit) is generated can be input. In addition, the transaction in which the account book item is generated can be divided into a balance item (income / expenditure) transaction and an expense item transaction.
Transactions in which a cash register item occurs can be divided into three categories No1 to No3 as shown in FIG.

  Of the three categories shown in FIG. 6, the first category (No. 1) is a transaction in which the “Account book item” occurs directly. Examples of transactions include “cash sales”, “cash purchase”, “ Social insurance premium cash payment, temporary payment cash payment, etc. In FIG. 6, these transactions are illustrated as transactions in which “cash” or “current account” is generated as a bank book item.

The second classification (No. 2) shown in FIG. 6 is a transaction in which a cash register item partially occurs, for example, a transaction such as “business trip temporary payment settlement”. When various account items are generated as in “Temporary payment settlement for business trip”, when journalizing is performed, for example, there are four journals as in the example of No. 2 in FIG. Of these four journals, the only item that has a deposit / debit item is [debit / credit] = [cash / units], which is a transaction in which a deposit / department item is partially generated. Note that the journal [debit / credit] = [cash / various] is a journal for the amount of the deposit / withdrawal amount input unit 571 of the transaction input screen 500.
The second division (No 2) can be omitted.

The third category (No. 3) shown in FIG. 6 is a transaction in which a cash register item is generated secondarily (a transaction in which a cash register item is not directly generated but payment or payment occurs at a later date). There are “sales sales”, “purchase purchases”, “payments payable”, and the like.
In the case of "account sales", for example, even if accrued sales occur and are recorded, the journal entry is [Debit / Credit] = [Accounts receivable / sales] as shown in the journal entry example, and there is a book item. do not do. However, if this account receivable is subsequently credited to the checking account, the journal entry is [Debit / Credit] = [Checking account / Accounts receivable], and the account item “Checking account” is secondary. To do.
Similarly, the “book deposit” and “payment unpaid” shown in FIG.

  Transactions for which no account book items are generated can be input not by the transaction input screen 500 but by the “subject transfer input” M2-7 in FIG. 4, but the details are omitted.

In the transaction input screen 500 of FIG. 5, budget data can be input for each transaction. That is, each item input from the screen 500 of FIG. 5 becomes a data item that constitutes budget data (transaction data) of one transaction.
The budget data input on the transaction input screen 500 includes information indicating the type of the transaction (including information used to convert the budget data into journal data), information on the settlement conditions of the transaction, and the amount related to the transaction (Settlement amount).
Further, on the transaction input screen 500, the state of budget data can be input. That is, when the budget data becomes a record, the change can be input.

  In the transaction screen 500, each time new budget data (transaction data) is input, a transaction NO (transaction ID: an identifier for individually identifying budget data (transaction data)) is given. It is displayed on the NO display unit 502. The transaction NO is registered in the transaction data registration unit 112 in association with each budget data.

  Among the budget data, the above-mentioned “information indicating the type of transaction” includes input classification, transaction partner, subject / subject branch number, department, increase / decrease classification of subject, summary, and the like.

  The “input classification” is input by the input classification input unit 501 and is information indicating whether the input transaction is a “income / expenditure” item transaction or an expense item transaction. The input classification input unit 501 is formed of a radio button GUI (graphical user interface), and can select either “income / expense” 501a or “expense” 501b.

  The “transaction partner” is information indicating a transaction partner such as a customer (seller) or a supplier, and can be input to the partner input unit 511 in the screen 500.

  The “subject” is information indicating a subject indicating the content of the transaction, and can be input to the subject input unit (subject field) 512. The transaction entered on this screen 500 is a transaction in which a cash register item is generated as described above, and the items entered in the course input unit 512 are “pay book item”, “multi-course subject”, and “other subject”. One of them.

The above three types of subjects input to the subject input unit 512 are prioritized according to the transaction categories shown in FIG. That is, if the first priority is given to No. 1 (transaction in which the cash register item directly occurs) in FIG. 6 and the account item is directly generated, the “account item” when the transaction is journalized. (Cash, checking account, etc.) is input to the subject input unit 512.
In addition, if the second priority is given to No. 2 (transaction in which the account book item is partially generated) in FIG. The data is input to the unit 512.

Further, in the case of No. 3 in FIG. 6 (transaction in which the account book item is generated secondarily), the partner item of the “account / book item” that is generated secondarily is input to the item input unit 512. For example, in the case of a transaction called credit sales, when a “bookkeeping transaction” called “payment” that occurs secondarily after a primary “bookkeeping transaction” called credit sales is journalized [debit / credit] If it becomes = [Checking Account / Accounts Receivable], “Accounts Receivable” which is the counterpart item of “Checking Account” which is “Account Book Item” is input to the item input unit 512.
It should be noted that courses other than “Account book subjects”, “Various course subjects”, and “Partner subjects” cannot be entered on this screen 500.

  The “subject” input in the subject input part (subject field) 512 is automatically transferred to the “journal item” field of the deposit amount display part 571 by the system 1. That is, the other subject of the “subject” entered in the subject input portion (subject column) 512 (the opposite subject when the journal is entered) is entered in the “Journaled subject” column of the transaction amount input portion 550 and the deduction amount input portion 560. Entered. These points will be described later.

The “subject branch number” is information indicating the branch number of the subject, and can be input to the subject branch number input unit 512.
The “department” is information indicating a department (sales department, personnel department, etc.) of a system user (company) involved in the transaction, and can be input to the department input unit 514.

The contents input to the destination input unit 511, the subject input unit 512, and the subject branch number input unit 512 are selected by selecting the search units 511a, 512a, and 513a to search for the pre-registered content. can do.
Further, in FIG. 5 and other display screens, the input contents do not have to be input from the keyboard, and can be simplified by selecting a registered item using a pull-down menu (not shown), inputting a date using a calendar, and inputting an amount using a calculator. Input is possible. These simple inputs can be input from a mouse without using a keyboard. Further, each piece of information to be input does not need to be input one by one. When certain information is input, the system 1 refers to the registered basic setting information and automatically generates other input target information. If possible, other input target information is automatically generated and displayed on the screen.

The “subject increase / decrease category” is information indicating whether the target transaction (subject entered in the subject input unit 512) increases or decreases assets / liabilities. Yes, input by the increase / decrease classification input unit 515. The target of increase / decrease is any of assets / liabilities / capital / revenue / expenses. The target of increase / decrease is based on the basic setting information according to the type of subject entered in the subject entry unit 512. Can be determined automatically .
This increase / decrease classification is an unnecessary input item from the viewpoint of simply entering a transaction, but it is necessary when generating journal data that is recorded separately from the budget data (transaction data) into debits and credits. .

  The “summary” is information indicating a summary of the transaction, and is input by the summary input unit 516.

  Further, in the budget data, information related to transaction settlement conditions includes information indicating a date (scheduled date) from the occurrence of the transaction to settlement. Information indicating the date (scheduled date) includes “transaction occurrence date”, “recording date”, “closing date”, “settlement date”, “bill delivery date”, and “bill maturity date”. These pieces of information are input from the settlement condition input unit 520.

  In this system 1, a transaction input method is adopted, and one or more “transactions on bookkeeping” can be input on one slip (transaction input screen 500). By having multiple dates from transaction to settlement as budget data (transaction data), even if one transaction is composed of multiple "bookkeeping transactions", it is the bookkeeping data from the budget data for each transaction Journal data can be created. Further, from the budget data, a cash flow chart / profit management table and various books described later can be created with transaction relevance.

The “transaction occurrence date” is information indicating a date (year / month / day) when the transaction occurs, and is input from the transaction occurrence date input unit 521. The “recording date” is information indicating a date when the profit / loss from the transaction is recorded, and is input from the recording date input unit 522.
As a general rule, the date of recording is the same as the date of transaction occurrence, so the date of the transaction occurrence date input section 521 is automatically posted, but if you want to make the profit / loss recording date different from the date of recording The recording date may be corrected in the recording date input unit 52.

The “closing date” is information indicating a closing date for summarizing bills every week, every 10 days, every month, and the like, and is input from the closing date input unit 523. When the information for calculating the closing date is set as the basic setting information, the closing date is automatically calculated based on the recording date and displayed on the closing date input unit 522.
For example, when “20th of every month” is set as the closing date, as shown in FIG. 5, if the transaction occurrence date is August 5, “August 20” is set as the closing date. (Closed date display section) 522.

The “settlement date” is information indicating the date of deposit or withdrawal to the current fund, and is input from the settlement date input unit 524. When the information for calculating the settlement date is set as the basic setting information, the settlement date is automatically calculated based on the recording date or the closing date and displayed on the settlement date input unit 524.
For example, when the settlement date is set to be “the end of the month following the closing date”, as shown in FIG. 5, “September 30” is set as the settlement date, and the settlement date input unit (settlement date display unit) 523.
In the case of cash transactions, the transaction occurrence date and the settlement date are the same date. In the case of bill settlement, the date is the same as the date of receipt and receipt of the bill (the date of receipt or the date of withdrawal).

The “Bill Transfer Date” is information indicating the date of receipt or the date of payment, and is input from the bill transfer date input unit 528.
The “note maturity date” is information indicating a settlement date in the case of bill settlement, and is input from the bill maturity date input unit 529. When the settlement method is a bill, the settlement date is preferentially used as the settlement date, not the date entered in the settlement date input unit 524 but the one entered in the bill maturity date input unit 529.

Further, in the budget data, information relating to the settlement conditions for transactions includes information relating to settlement methods. The information related to the payment method is information indicating a payment method with the other party that performs the transaction, and is input from the payment method input unit 525. The types of information indicated by the settlement method include cash, petty cash, check, bank transfer, bill and others.
Of the types of payment, “cash” is a payment method in which the payment details are reflected in the cash book, and “small cash” is a payment method in which the payment details are reflected in the cash book. “Check”, “Bank transfer” and “Bill” are settlement methods in which settlement details are reflected in the bank book.

In the case of the settlement method reflected in the bank book, the information regarding the transaction settlement conditions includes information regarding the bank account (bank). Information relating to the bank account (bank name, branch name, account type, etc.) is input from the bank account input unit 526. In the case of bill settlement, the bill settlement number (bill number) is included in the information regarding the transaction settlement conditions. The bill number included is input from the bill number input unit 527.

Furthermore, the transaction input screen 500 includes an amount input unit 530 for inputting a planned amount (settlement amount etc.) related to the transaction.
The amount related to the transaction is not limited to the settlement amount. In other words, the transaction amount with the business partner may be used as the settlement amount as it is, or the deposit or withdrawal will be made, or the amount deducted from the transaction amount or the amount deducted from the fee will be the settlement amount, Or it may be withdrawn.

Therefore, the amount input unit 530 of the present system 1 includes a deduction amount input unit 560 for inputting a deduction amount to be deducted, such as a discount, in addition to the transaction amount input unit 550 for inputting the transaction amount. The deposit / withdrawal amount after deduction is calculated.
The transaction amount input unit 550 is configured to be able to input a plurality of transaction amounts, and the deduction amount input unit 560 is also configured to be able to input a plurality of deduction amounts. ”Is displayed.
Deposit / withdrawal amounts are calculated by subtracting the sum of one or more deduction amounts, if any, from the sum of one or more transaction amounts. The calculated deposit / withdrawal amount is displayed on the deposit amount display unit 571.
The money amount input unit 530 is provided with a payment fee input unit 572 for inputting a payment fee such as a transfer fee at the time of withdrawal.

Thus, a plurality of amounts (transaction amount, deduction amount, deposit / withdrawal amount, payment fee, etc.) associated with one transaction can be input or generated in the amount input unit 530.
Also, each of a plurality of amount input fields associated with one transaction corresponds to a “bookkeeping transaction” that constitutes one transaction, and one amount can be entered by inputting the amount into each field of the amount input unit 530. Transaction data can be broken down into multiple “bookkeeping transactions” to create multiple journal entries.

  In addition, in the input field for each amount in the amount input section 530, in addition to “Amount” in each column, “Consumption tax”, “Total” indicating the sum of the amount and consumption tax, and the tax classification of transaction amount or deduction amount "Tax category" to be displayed, "Journal item" and "Category branch number" when the journal entry is made can be entered.

As the “journal item”, the item entered in the item input unit (subject column) 512 when journalizing the transaction amount input unit 550 and the deduction amount input unit 560 corresponding to the “bookkeeping transaction” is entered. The subject to be the other subject is entered. For example, as shown in FIG. 5, when the item input to the item input unit 512 is “Accounts receivable”, the “Transaction amount 1” column in which the amount “40,000” is input in the transaction amount input unit 550 is displayed. When journalizing, this is a “bookkeeping transaction” called credit sales, and [Debit / Credit] = [Accounts receivable / Sales].
Therefore, “Sales”, which is the counterpart item of “Accounts receivable”, is input to “Journal item” in the “Transaction amount 1” column of the amount input section 530.
Similarly, in the “transaction amount 2” field and the “deduction amount 1” to “deduction amount 4” fields, when amounts are entered in the respective fields, they are similarly input to the item input section (subject field) 512. The subject that is the subject of the selected subject is entered.

  As described above, in the “Journal item” field of the deposit / withdrawal amount input unit (withdrawal amount display unit) 571, “Accounts receivable” input to the item input unit 512 is automatically transferred and displayed by the system.

  In addition, “branch number” for “journal item” is input to “subject branch number” in each column of transaction amount input unit 550 and deduction amount input unit 560.

  As described above, since the amount and the journal entry are entered in the amount input section in the transaction unit on the bookkeeping, the system 1 converts each amount entered in each column of the amount input section 530 into the journal data. When converting to, the item (and item branch number) in each journal data can be determined using the “journal item” (and “subject branch number”) input to the money amount input unit 530. Details of the method for converting to journal data will be described later.

  Furthermore, the transaction input screen 500 is provided with a state input unit 540 for inputting a progress state of budget data. The states that can be input from the state input unit 540 include “transaction occurrence”, “bill exchange”, “payment”, and “payment / withdrawal”. Since each state can be input in a check box format, a plurality of states can be selected. Further, when any state is selected in the state input unit 54, journal data is automatically generated from the budget data. This point will also be described later.

  “Transaction occurrence” in the status input unit 540 indicates that the expected transaction occurrence indicated by the budget data has actually been performed. “Bill exchange” indicates that the bill exchange for the transaction indicated by the budget data was actually performed. “Schedule” indicates that the transaction indicated by the budget data has been settled by partial payment. “Payment / withdrawal” indicates that the transaction indicated by the budget data has been settled.

FIG. 7 shows an input example on the screen 500 when a transaction actually occurs on August 5, 2007 for the budget data input as shown in FIG. Here, in the budget of FIG. 5, “transaction amount 1” was “40,000”, but the actual result was “45,000”. Note that the amount in the deposit / withdrawal amount display section 571 is automatically corrected.
In FIG. 7, the “transaction occurrence” check box in the state input unit 540 is selected, indicating that an actual transaction has occurred. In this case, the amount fields of the parts (transaction amount, deducting the amount) of the transaction amount input unit 550 and the deduction input unit 560 of the budget data of the transaction (transaction data) track record portion, and the remaining portion (input and amount) of The budget remains.

That is, if each state of the state input unit 540 is not selected, all of the transaction data of the transaction is a budget , but when the “transaction occurrence” check box is selected, a part (of the amount and date) ) Is the actual part , and the budget and actual data are mixed. When the transaction is completely settled, all the transaction data is a record .

  Until the transaction is completed, a “continuing” display 504 is displayed on the screen. When the transaction is completed, the “continuing” display is deleted. In addition, when “payment / withdrawal” is selected in the status input unit 540, the transaction is completed. However, if special completion processing is required due to circumstances, the special completion input unit 570 causes the Make input for completion.

Further, the screen 500 has a registration button 505 and a cancel button 506. When the input content is stored in the transaction data storage unit 112, the user only has to press the registration button 5005 and want to cancel the input content. In that case, a cancel button 506 may be pressed.
Furthermore, the screen 500 has a data copying unit 503, and by selecting this, another transaction data having the same content is created.

[3.4 Example of transaction input]
Hereinafter, based on FIG. 8, an example of budget data (transaction data) about sales receivable with the customer “Company A” will be described.
Here, the settlement conditions with Company A are as follows.
1) Closing date: Closed on the 20th of every month 2) Settlement date: The end of the month following the closing date 3) Settlement method: Transfer (Bank B, C branch, current account transfer)
The current date is assumed to be August 15th.

Assume that the planned amount (budget) of the transaction with Company A assumed by the user (manager) of the system 1 in advance (before August 5) is as follows.
No. 1: August 5 Multi-sale scheduled amount 40,000 yen No. 2: August 10 wallet planned amount 50,000 yen No. 3: August 15 wallet planned amount 60,000 yen No. 4: August 20 wallet scheduled amount 70,000 yen No. 5: August 25th scheduled sale amount 80,000 yen No, 6: August 31th scheduled sale amount 90,000 yen

In addition, the transaction No. 1-No. 6, No1. ~ No. Reference numeral 3 denotes an actual transaction in which a transaction has actually occurred. The actual amount is as follows and is slightly different from the planned amount.
No. 1: August 5 Multi-sale sales amount 45,000 yen No. 2: August 10 wallet actual amount 52,000 yen No. 3: August 15 wallet actual amount 59,000 yen

No. above. 1-No. 6 is input from the transaction input screen 500 in FIG. Here, the input values in FIG. Corresponds to one transaction. Other No. 2-No. No. 6 is also No. As in 1, the input is performed from the screen 500.
In addition, the above-mentioned No. 1-No. About each transaction of 6, "No101" thru | or "No106" are provided as an identifier (transaction NO) which this system provides.
Prior to August 5, any transaction (No. 101 to No. 106) is only a plan, and therefore the state selection by the state input unit 540 is not performed.

Then, on August 5, since the transaction No. 101 is determined as a record among the transaction No. 101 to the transaction No. 106, a process for making a part of the transaction data of the transaction No. 101 into a record part is performed. Specifically, FIG. 7 shows a screen 500 for making the occurrence of a transaction No. 101 occur. That is, as shown in FIG. 7, the user changes the actual budget amount (transaction amount 1) 40,000 yen from the screen 500 to the actual amount 45,000 yen, and sets “transaction occurrence” in the state input unit 504. select. Thus, the “transaction amount 1” portion of the amount input unit 530 in the transaction data of transaction No. 101 becomes the actual result portion .

Similarly, processing for making a transaction is performed for transaction No 102 and transaction No 103 as well.
FIG. 8 shows a transaction list screen 600 showing a transaction list when the generation of transactions from transaction No. 101 to transaction No. 103 is made a record. The transaction list screen 600 is a screen displayed when the “transaction list” button M2-1 is selected in the “transaction management” menu M2 shown in FIG.
When the “transaction list” button M2-1 is selected, the processing unit 120 of the system 1 refers to the transaction data registration unit 112, extracts transactions to be displayed, and forms the screen 600. Generate screen data.

As shown in FIG. 8, in the transaction list screen 600, there are a mixture of actual transactions in which transactions have already occurred (including transactions for which transactions have not been completed) and scheduled transactions in which transactions have not yet occurred. In order to make it easy for the user to distinguish between both transactions, both are displayed in different colors.
In FIG. 8, transaction No 101 to transaction No 103 are actual transactions, and transaction No 104 to transaction No 106 are scheduled transactions. In FIG. 8, the “transaction occurrence” column check box for each transaction No. 101 to transaction No. 103 is selected, and the “transaction occurrence” column check box for each transaction No. 104 to transaction No. 106 is not selected. However, by displaying the scheduled transaction and the actual transaction in different colors (highlight display; highlighting), the user can easily distinguish between the two.

  In FIG. 8, the actual transaction and the scheduled transaction are distinguished by the shading of characters. However, since the actual transaction list screen 600 is a color screen, the actual transaction character color (for example, black) and the scheduled transaction are displayed. The transaction color (for example, blue) is displayed in a different color.

  In addition, in the transaction list screen 600 of FIG. 8, in addition to the checkboxes, highlights are displayed for each state so that the user can easily understand the progress state (transaction occurrence to deposit / withdrawal) of each transaction. The In other words, in FIG. 8, a display that distinguishes between a state that has already occurred in each transaction (for example, the occurrence of a transaction) and a state that may occur in the future for each transaction but has not yet occurred (for example, a bill has been received or deposited). Is done.

Specifically, among the columns in FIG. 8 corresponding to the states “transaction occurrence”, “bills exchange”, “payment”, and “payment / withdrawal” that can be input in the state input unit 540 shown in FIG. The check box for the state that has occurred (actual part) is displayed on the white ground, and the check box for the state that may occur in the future but has not yet occurred is displayed on the blue background (the shaded area in FIG. 8 is highlighted). Has been.
Here, since there is no bill transaction in FIG. 8, the “Bill Exchange” column is not highlighted in any transaction.

The transaction list screen 600 can display the transaction data registered in the transaction data registration unit 112 (see FIG. 2) by narrowing it down with designated display conditions (filtering conditions). The display condition can be specified by a condition specifying unit 610 in the screen 600. The processing unit 120 of the system 1 extracts transactions that meet the conditions specified by the condition specifying unit 610 and displays them on the list display unit 620.
The list display unit displays almost all of the transaction data (budget data) of each transaction, but for ease of viewing the list, some of the items included in the transaction data may be omitted. In FIG. 8, the display of the transaction amount and the deduction amount is omitted.
In the transaction list screen 600, each transaction data can be corrected (amount of money, state, etc.).

[3.5 Borrow / Lease Entry and Other Entry]
As shown in FIG. 4, borrowing / lease other than transactions can be performed from “borrowing / lease input” M2-4, and the list can be displayed by “borrowing / lease list” M2-3, but the details are omitted. Also, “small expense transfer input” M2-5, “account transfer input” M2-6, and “subject transfer input” M2-7 can be performed, but details thereof are also omitted.

[3.6 Book inquiry menu]
FIG. 9 shows a state in which the “book inquiry” menu M4 is selected on the menu screen D1. The “book inquiry” menu M4 is for displaying various books based on the transaction data registered in the transaction data registration unit 112 (data in which budget / actual results are mixed ). In addition, the process part 120 produces | generates various books by referring basic setting information based on transaction data.

This “book entry inquiry” menu M4 includes “account book” M4-1, “account balance confirmation table” M4-2, “subsidiary ledger” M4-3, “notes received” M4-4, “payment bills” Various selection buttons of “M4-5” and “Journal diary” M4-6 are displayed. When these buttons are selected, the processing unit 120 of the present system 1 generates a corresponding book based on the transaction data registered in the transaction data registration unit 112 (data with mixed budget / actual results), Display on the screen.

  In the following, it is assumed that the transaction data regarding the transaction described in “3.2.3.2 Transaction Input Example” is registered in the transaction data registration unit 112, and the various books described below are 8 As of the 15th of the month.

[3.7 Account book]
FIG. 10 shows a deposit / departure screen 700 displayed when “account / paybook” M4-1 is selected. This cash register screen 700 has a display condition specifying unit 710 and a list display unit 720 showing the contents of the cash register.
The processing unit 120 generates a cash register with the cashier (B bank C branch current account) designated by the display condition designation unit 710 based on the payment date to the cashier (B bank C branch current account). The balance (expected balance) etc. is calculated and displayed.
In order to generate a cash register, it is only necessary to have data of a cash book item that occurs when journalizing among the “book transactions” constituting each transaction. Therefore, the processing unit 120 generates the data of the accounting book based on the data in which the accounting book item is specified in the “subject” or “journal item” input on the screen 500. In the case of FIG. 10, the processing unit 120 generates data of the cashbook from the date and amount of deposit / withdrawal in each transaction.

Similarly to the transaction list screen 600, the transaction book screen 700 also displays the scheduled transactions and the actual transactions in different colors, highlights the status of each transaction, and allows the user to easily grasp the status of each transaction.
According to the cash register screen 700, the expected balance at the cash register can be grasped. Further, since the user can grasp the relationship between the expected balance and the state of each transaction (whether actual transaction has occurred or not), it is easy to raise funds.

  Note that the screen when the “Account book balance confirmation table” M4-2 is selected is omitted, but the balance (expected balance) for each account destination is displayed in date order. Can be easily grasped.

[3.8 Subledger]
FIG. 11 shows an auxiliary ledger screen 800 displayed when “auxiliary ledger” M4-3 is selected. The auxiliary ledger screen 800 includes a display condition specifying unit 810 and a list display unit 820 showing the contents of the auxiliary ledger.
In order to generate the auxiliary ledger, the processing unit 120 narrows down the transaction data that is the target of the transaction data by the specified customer (customer / supplier) or item (subject branch number).
For example, as shown in FIG. 11, if the business partner is “Company A” and the item is “Accounts receivable”, the business partner input in the customer / vendor input unit 511 of the transaction input screen 500 is “A”. The transaction is “company” and the subject entered in the subject entry unit 512 or the subject entered in the “other subject” column of the amount input unit 530 is “Accounts receivable”. And in this case, transaction No101-No106 are extracted.

  When the processing unit 120 generates the auxiliary ledger, each transaction No. 101 to No. 106 is disassembled into “transactions on bookkeeping”, and “accounts receivable” (display conditions) are debited or credited when the transaction on bookkeeping is journalized. The auxiliary ledger is generated from the subject specified by the specifying unit 810. Therefore, a plurality of transactions having the same transaction NO exist in the auxiliary ledger. However, even if the “transaction” is broken down into multiple “bookkeeping transactions”, the same “transaction” is displayed in the subledger for the same “transaction”, so there are multiple “bookkeeping transactions”. The user can determine which is the same “transaction”.

Further, in order for the processing unit 120 to divide each transaction into “transactions on bookkeeping”, with reference to a plurality of amounts input by the amount input unit 530 on the screen 500, “ “Trade”.
In the “subject” column of the auxiliary ledger, the counterpart subject of the subject specified by the display condition specifying unit 810 is displayed.

  Also, in the auxiliary ledger screen 800, similar to the transaction list screen 600, the scheduled transaction and the actual transaction are displayed in different colors, and the state of each transaction is also highlighted, so that the user can easily grasp the state of each transaction.

  FIG. 12 shows another display example of the auxiliary ledger. In FIG. 12, unlike FIG. 11, the case where “subject” is designated as “sales” in the display condition designation unit 810 is shown.

  In addition, the balance of the subledger of the items (accounts receivable, accounts payable, accounts receivable, accounts payable, various accounts, etc., excluding the account book items) entered in the item input section 512 is always zero on the final settlement date. Become. Thereby, if the auxiliary ledger of the present system 1 is used, it is possible to easily find a delay in payment, delay in payment, omission of payment, omission of payment, and prevent these.

[3.9 Bills and Journal Diary]
When “Billing note book” M4-4 or “Billing note book” M4-5 is selected in the menu of FIG. 9, a billing note screen or a billing note screen is generated in the same manner as the auxiliary ledger. The process for generating the bill of exchange screen or the bill of exchange screen is the same as assuming that “notes of payment” or “notes of payment” are specified as the display condition designation item in the subledger. Detailed description is omitted.
Further, when “journal diary” M4-6 is selected in the menu of FIG. 9, a journal diary is generated. The journal diary is generated by extracting only “transactions on bookkeeping” that have been achieved from transaction data registered in the transaction data registration unit 112. Details of the journal diary generation process will be described later.

  As described above, in this system 1, the unit of transaction data is not “book transaction”, but the processing unit 120 has a function of decomposing transaction data into “book transaction”. As with a general accounting system, it is possible to generate data for various books such as a cash register and auxiliary ledger. And in each book data, since a scheduled transaction and a performance transaction are distinguished and displayed, it is easy for a user to grasp a schedule and a performance.

[3.10 Summary table menu]
FIG. 13 shows a state where the “tabulation table” menu M5 is selected on the menu screen D1. The “total table” menu M5 is used to display various total tables based on transaction data registered in the transaction data registration unit 112 (data in which budget / actual results are mixed ).

The “summary table” menu M5 includes “detail table” M5-1, “cash flow chart” M5-2, “profit plan table” M5-3, “manufacturing cost plan table” M5-4, and “marginal profit table”. Various selection buttons of M5-5, “Expected balance sheet” M5-7, and “Shareholders' equity change statement” M5-8 are displayed.
When these buttons are selected, the processing unit 120 of the present system 1 generates a corresponding tabulation table based on the transaction data registered in the transaction data registration unit 112 (data in which budget / actual results are mixed ). Display on the screen. Further, the processing unit 120 generates various tabulation tables by referring to the basic setting information based on the transaction data. In the drawings related to the following description, it is assumed that only a part of the total table is displayed, not the entire total table, but in reality, the entire total table is displayed on the screen.

  Here again, it is assumed that the transaction data for the transaction described in “3.2.3.2 Transaction Input Example” is registered in the transaction data registration unit 112, and the various tabulation tables described below are as follows. As of August 15th.

Also, here, the cash flow schedule screen 900 when the “cash flow schedule” M5-2 is selected, the profit plan schedule screen 1000 when the “profit schedule table” M5-3 is selected, and the “expected balance sheet” M5. An example of the expected balance sheet 1100 when −7 is selected will be described.
FIG. 14 shows a cash flow table screen 900. The processing unit 120 calculates the monthly income from the settlement date (payment date) and the deposit / withdrawal amount (payment amount) of transactions No101 to No106 registered in the transaction data registration unit 112, and the cash flow chart shown in FIG. Is generated.

  FIG. 15 shows a profit plan table (profit statement) screen 1000. The processing unit 120 calculates the sales from the sales No. 101 to No. 106 registered in the transaction data registration unit 112 to the current month. Although omitted in FIG. 15, the profit plan table displays profits up to each month of the current fiscal year after deducting the cost of sales and expenses.

  FIG. 16 shows an expected balance sheet screen 1100. The processing unit 120 calculates items necessary for the balance sheet for each month in this period from the transactions No 101 to No 106 registered in the transaction data registration unit 112.

  Thus, even when displaying various summary tables, the processing unit 120 can divide the budget data into a plurality of “bookkeeping transactions”, and thus can create various summary tables in the same manner as a normal accounting system. These summary tables are based on the budget, and each summary table with the planned budget can be analyzed.

[3.11 Generation of journal diary]
FIG. 17 shows the relationship between transaction data registered in the transaction data registration unit 112 (data in which budget / actual results are mixed ) and journal diary data (journal data) generated from the transaction data by the processing unit 120. Show. As shown in FIG. 17, journal diary data (final journal) is generated from transaction data in which a budget and an actual result are mixed based on the “dealing transaction” as an actual result. Therefore, the journal diary data of the present system 1 does not have data relating to unconfirmed transactions.

On the other hand, in the above-described various books (excluding the journal diary) and various tabulation tables, forecast numbers that are generated from transaction data in which a budget and actual results are mixed for budget management and reflect the budget appear.
Here, if a journal is included in the journal diary data generated by the system 1, the journal for the budget is related to a bookkeeping transaction that does not yet exist. Should not be present in journal diary data in the accounting system.

  As a result, if the budget is included in the journal diary data generated by the system 1, the consistency with the journal diary data in a general accounting system is lost. Moreover, if journal diary data that can be used in a general accounting system is required, daily performance transactions must be recorded in a general accounting system different from the system 1.

On the other hand, in this system 1, various books (excluding journal diary) and various summary tables are generated from transaction data in which budgets and results are mixed, so that the user can see the numbers that reflect the budgets. Budget management can be appropriately performed using (except journal diary) or a summary table.
Moreover, in this system 1, since journal diary data can be created only from the actual transaction part excluding the planned transaction part of the transaction data, final journal diary data based only on the actual transaction can be obtained. Consistency with the accounting system is ensured.

Hereinafter, processing for generating journal diary data (journal data) from transaction data will be described.
In the journal diary data generation processing, the processing unit 120 inputs “subject” (subject information input in the subject input unit 512) and “increase / decrease category” (increase / decrease category input unit 515) included in each transaction data. This is done by generating journal data for each amount entered in each column of the amount input section 530 using the increase / decrease classification information).

Here, in order to generate journal data, it is necessary to determine what kind of courses the two courses in each journal have, and to decide whether the two courses are debits or credits.
Therefore, when generating the journal data, the processing unit 120 refers to the reference information shown in FIG. 18 and FIG. 19 based on the “subject” and “increase / decrease classification”, and determines what the debit item and the credit item in the journal data. Decide what will be.
The reference information shown in FIGS. 18 and 19 is configured such that the computer has a table in which journal information for generating journal data is associated with input information “subject” and “increase / decrease”.

For example, reference information No. 1 shown in FIG. 18 indicates journal information when “subject” is an accounts receivable and “increase / decrease” is an increase. In addition, this transaction is a transaction in which the account book item occurs secondarily.
The journal information in the reference information No1 includes the journal information (No1-1) for the amount entered in the transaction amount input section (transaction amount column) 550, and the amount entered in the deduction amount input section (deduction item column) 560. Journal information (No1-2) and journal information (No1-3) about the amount of money in the deposit / withdrawal amount display section 571 are included.

In the journal information No. 1-1, information for journalizing individual amounts (“transactions on bookkeeping”) input in “transaction amount 1” or “transaction amount 2” in the amount input section 530 of the screen 500 is displayed. Show.
In journal information No. 1-1, [Debit item / Credit item] = “Accounts receivable / Journal item”, and “Accounts receivable”, which is “Item” input in the item input unit 512, becomes “Debit”. It shows that the counterpart item of “Accounts receivable” (the journal item entered in the “Journal item” field of the transaction amount input section 550) becomes “Credit”.

  In the journal information No. 1-2, [Debit item / Credit item] = “Journal item / Accounts receivable”, and “Accounts receivable” which is “Item” input in the item input unit 512 becomes “Credit”. It shows that the counterpart item of “Accounts receivable” (the journal item entered in the “Journal item” field of the deduction amount input section 560) becomes “debit”.

  In the journal information No. 1-3, [debit item / credit item] = [account / account for accounts receivable], the account item related to the acquisition amount becomes “debit”, and “journal entry” in the deposit / withdrawal amount display section 571 It shows that “Accounts receivable” in the “Account” column becomes “Credit”.

  In this way, by using the reference information, from the “subject” and “increase / decrease” included in the transaction data, the “subject” entered in the subject input unit 512 and the “journal subject” in the amount input unit 530 are displayed. It is possible to determine which is a debit and which is a credit among “journal subjects” (partner subjects of “subjects” input in the subject input unit 512) input in the “” column.

  In addition, the transaction indicated in the reference information No1 is a “transaction in which a cash register item is generated secondarily”, and a bookkeeping transaction (cash / withdrawal) in which the cash register item is generated is as follows: It is possible to determine which of the subjects in the “Journaling subject” column of the input unit 530 (the counterpart subject of the cash register subject) is debited and which is credited.

  That is, the processing unit 120 of the system 1 divides the transaction data into one or more “bookkeeping transactions” and then refers to the reference information so that the “subject” and “journal item” Two subjects can be identified. Moreover, since each transaction data has “increase / decrease” data for “subject” (item data), the transaction type is distinguished according to the increase / decrease category, and these two items are either debit or debit. Can be determined.

  When a plurality of amounts are input to the transaction amount input unit 550, a journal is generated for each amount. Further, when a plurality of amounts are input to the deduction amount input unit 560, a journal is generated for each amount.

  Further, the transactions shown in the reference information No. 2 to No. 4 shown in FIG. 18 and the reference information No. 12 to No. 13 shown in FIG. 19 are also “transactions in which a cash register item is secondarily generated”. Is set, and each amount in the amount input unit 530 can be journalized in the same manner as the reference information No1.

  Reference information No. 5 to No. 10 in FIG. 18 is reference information for “a transaction in which a cash register item directly occurs”. In the case of “transactions in which a bank account item is directly generated”, one of two subjects related to a bookkeeping transaction is a “book item” (the item input in the item input unit 512), and the other is “ "Another subject of the cash register subject". The “counter account subject” is a subject entered in the “journal subject” field of the transaction amount input section 530.

  For example, the reference information No. 5 is reference information for a transaction called cash sales, and the “subject” input to the subject input unit 512 is “account entry / exit”, and the “increase / decrease category” input to the increase / decrease category input unit 515. "Is" increase "and the item entered in the" Journal item "field of the transaction amount input unit 550 is" cash sales ". In this No. 5, [Debit item / Credit item] = [Account book item / Cash sales], “Account book item” related to the acquisition amount becomes “Debit”, and “Journal” in the transaction amount input section 550 It shows that “cash sales” in the “subject” column becomes “credit”.

Reference information No. 11 in FIG. 19 is reference information for “a transaction in which a cash register item partially occurs”. In the case of a “transaction in which a cashier subject is partially generated” (when “subject” is “Momoguchi”), “Momoguchi” is debited from the amount entered in the transaction amount input unit 550 as shown in FIG. Journal entries ([Debit item / Credit item] = [Various accounts / Temporary payments]) and multiple journal entries (Debit item / Credit item) where [Various accounts] are credited = [Travel expenses / Expenses], [Entertainment expenses] / Various Accounts] and [Communication Fee / Various Accounts] are generated.
Further, from the amount input to the acquisition amount input unit 570, a journal entry of [debit item / credit item] = [account book item / units] is generated.

  The reference information shown in FIG. 18 and FIG. 19 is a representative example, and actually, a large amount of reference information is prepared according to the number of “subjects”.

  Further, as described above, the journal data is not generated from the entire transaction data including the budget, but is generated from the actual part of the transaction data. Which of the amounts (transactions on bookkeeping) input to the amount input unit 530 is the actual part is determined by the processing unit 120 according to the state of the transaction input by the state input unit 540.

  Here, the timing at which journal data is generated from transaction data is as follows. First, if the recorded date (transaction occurrence date) and the settlement date are the same date, journal data is generated when the planned transaction changes to an actual transaction (when the “transaction occurrence” state is selected). The Also, if the recording date (transaction occurrence date) and the settlement date are different, the journal data will be displayed when the “transaction occurrence” state is selected and when the “payment / withdrawal” state is selected. Generated. When a bill maturity date is entered in the bill maturity date input section 529 of the screen 500, when a “transaction occurrence” state is selected, a “bill transfer” state is selected, and a “payment / withdrawal” state is displayed. Journal data is generated when selected.

Hereinafter, the process of generating journal data from the actual part of the transaction data will be described based on a specific example.
Here, it is assumed that data shown in FIG. 20 is input as transaction data. This transaction data is budget data for which no transaction has yet occurred, as is clear from the fact that no state is selected in the state input unit 504.

In the budget data shown in FIG. 20, it is assumed that actual transaction occurrence (accounting for accounts receivable) is on October 16, 2007, and the “transaction occurrence” state of the state input unit 504 is selected.
In the “transaction occurrence” state, the information input to the transaction amount input unit 550 and the deduction amount input unit 560 in the amount input unit 530 becomes the actual part, and the date (recorded year) input to the recording date input unit 522 The date of October 16, 2007, which is the date, is also the actual result), so that a journal is generated for each amount (bookkeeping transaction) input to the transaction amount input unit 550 and the deduction amount input unit 560. .

That is, in the example of FIG. 20, since the item input unit 512 is “Accounts receivable” and the increase / decrease classification input unit 515 is “Increase”, the processing unit 120 refers to the reference information No1 shown in FIG. Based on the information of the input unit 550 and the deduction amount input unit 560, the following two items are generated as journal data dated October 16th.
10/16 [Debit / Credit] = [Accounts receivable: 350,000 yen / Sales: 350,000 yen]
10/16 [Debit / Credit] = [Sales rebate: 3,500 yen / Accounts receivable: 3,500 yen]

Then, when the settlement date (deposit date) of December 30, 2007 is reached and there is actually a deposit for the accounts receivable, and the “deposit / withdrawal” state of the status input unit 504 is also selected, the deposit / withdrawal amount input unit 571 The information entered in the field is the actual part, and the amount entered in the amount input unit 530 is input based on the date entered in the settlement date input unit 524 (the date of settlement, December 30, 2007 is also the actual result). Journal data regarding the amount of money (bookkeeping transaction) input to the section 571 is generated as follows with reference to the reference information No1 shown in FIG.
12/30 [Debit / Credit] = [Checking account: 346,500 yen / Accounts receivable: 346,500 yen]

  In addition to the above information, information included in transaction data such as “subject branch number” and “summary” is appropriately added to each journal data.

FIG. 21 shows other transaction data. This transaction data is also budget data for which a transaction has not yet occurred.
In the budget data shown in FIG. 21, it is assumed that actual transaction occurrence (payment of payables) is on October 20, 2007, and the “transaction occurrence” state of the state input unit 504 is selected.
Then, in the example of FIG. 21, since the item input unit 512 is “payable” and the increase / decrease classification input unit 515 is “increase”, the processing unit 120 refers to the reference information No. 12 shown in FIG. Based on the information of the input unit 550 and the deduction amount input unit 560, the following four items are generated as journal data dated October 20, which is the date of recording.
10/20 [Debit / Credit] = [Salary allowance: 350,000 yen / Accounts payable: 350,000 yen]
10/20 [Debit / Credit] = [Accounts payable: 35,000 yen / Legal welfare expenses: 35,000 yen]
10/20 [Debit / Credit] = [Accounts payable: 5,000 yen / Deposit: 5,000 yen]
10/20 [Debit / Credit] = [Accounts payable: 10,000 yen / Deposits: 10,000 yen]

Then, when the settlement date (payment date) on October 25, 2007 is actually withdrawn and the “withdrawal / withdrawn” state in the state input unit 504 is also selected, input to the settlement date input unit 524 Journal data about the amount (bookkeeping transaction) input to the deposit / withdrawal amount input unit 571 in the amount input unit 530 on the date (October 25, 2007) is the reference information No. 12 shown in FIG. With reference, it is generated as follows.
10/25 [Debit / Credit] = [Accounts payable: 300,000 yen / Current account: 300,000]

  20 and FIG. 21 is a case where a transaction in which transaction generation and deposit / withdrawal (settlement) occur on different days is input as “subject”, and a plurality of amounts in the amount input unit 530 are If a transaction that is accounted for on multiple dates but has a transaction and a deposit / withdrawal at the same time, such as a cash transaction (a transaction in which a cash register item occurs directly), is entered as an item, the transaction occurs. Journal entries are made when a state is selected.

  When the settlement method is a bill, bill exchange is performed for settlement. When the bill exchange is actually performed and the “Bill exchange” state is selected in the state selection unit 540, the journal with the acquisition amount entered in the deposit / withdrawal amount input unit 571 is made on the bill receipt date (settlement date) ( Recorded in bills book). Further, when the date entered in the bill maturity date input unit 529 is reached in the state where the “Bill Transfer” state is selected, the journal is automatically made with the deposit / withdrawal amount entered in the deposit / withdrawal amount input unit 571 (for the time being) Booked in funds).

FIG. 22 shows the flow of processing using the present system 1. When information regarding the closing date / settlement date is set as the basic setting information (step S1), transaction data serving as a budget is input on the transaction input screen 500 (step S2). At this time, the budget data may be “invoiced individual input” in which the invoiced amount is divided for each transaction occurrence, or multiple transactions with the same closing date are considered as one transaction in a lump sum, You may enter in.
Then, based on the transaction occurrence date input in step S2, the settlement date is automatically input on the screen 500.

  Further, when information regarding the closing date / settlement date is not set as the basic setting information (step S1), when entering transaction data as a budget on the transaction input screen 500 (step S4), a settlement date (necessary If there is a closing date, it is manually input (step S5).

  Then, the actual date has passed the transaction occurrence date input to the system, and the transaction is actually generated (from the budget to the actual result; step S6). At this time, if the actual transaction content is different from the transaction data content (amount, transaction occurrence date, etc.) as a budget (step S7), the transaction data content is adjusted from the screen 500 to the actual transaction. Correction is made (step S8).

  When a transaction occurs and transaction data is corrected or no correction is required, the user selects “transaction occurrence” in the status input unit 540 of the screen 500 (step S9).

  Further, the actual date passes the settlement date input to the system, and the settlement (payment / withdrawal) is actually performed (step S10). If the actual settlement amount (transfer amount) is the same as the deposit / withdrawal amount of the transaction data and there is no need to correct the amount or the like (step S11), the user selects the “paid / withdrawn” state in the state input unit 540. (Step S12). Then, it is assumed that the transaction has been completed, and the transaction data is in a completed state (step S13).

If it is necessary to make some corrections regarding the settlement in step S10 such that the actual settlement amount (transfer amount) is different from the deposit / withdrawal amount of the transaction data (step S11), processing for that is performed (steps S14, 15). ). For example, in the case of partial payment instead of batch, the “schedule” state is selected by the state input unit 540, and the partial payment processing is performed on a payment processing screen (not shown). The installment process is performed by setting the amount of each of multiple installments and the corresponding settlement date (transfer date).
In addition, when there is a situation in which transfer is not possible, special completion processing is performed in the special completion input unit 570 of the screen 500.

Further, when an actual “bookkeeping transaction” occurs and is input to the system 1 as in the case of the transaction occurrence in step S9, the deposit / withdrawal in step S12, and the special completion process in step S15, the processing unit 120 Automatically creates journal data (final journal) based on the actual part of the transaction data (step S16). The journal data can be output to the outside of the system 1, and in a general accounting system, the journal data can be taken in and processed.

[3.12 Creating the next budget]
The processing unit 120 of the system 1 automatically inputs the conditions of the forecasted forecast rate of the next budget on a monthly, quarterly, or year basis based on the transaction data for the current period (data with mixed budget / actual results). In addition, it has a function as a budget creation means for creating budget data (transaction data) for the next period.

  Budget data that can be created by the budget creation means is limited to transactions (income items, expenditure items, expense items) that can be entered from the screen 500. Note that borrowing / lease transactions cannot be included in the next budget because they can be entered for one to several years at the time of budget creation. In addition, with respect to the transfer of account book, small expense transfer, and item transfer, the system 1 does not automatically create a budget in order to accurately represent the state before the transfer. In addition, for transactions relating to the transfer of accounts, small expense transfers, and item transfers, after the next budget has been created, it may be input manually.

FIG. 23 shows a predicted value input screen (predicted value input means) 1200 for inputting a predicted value of the ratio between the transaction amount in the current period and the transaction amount in the next period. In the screen 1200 of FIG. 23, a predicted ratio value can be input for each month. The screen in FIG. 23 is a tabulation table of transaction data for the current period, and here, the sales to Company A are tabulated monthly. In the screen of FIG. 23, the forecast / actual amount for the current period (10,000 yen) can be displayed, and the ratio predicted value for each month can be input from the ratio predicted value input unit 1201. In the screen of FIG. 23, an amount obtained by multiplying the predicted / actual amount for the current period (10,000 yen) in the summary table by the predicted value of the ratio is displayed as an amount for the next period (10,500 yen).
With the screen of FIG. 23, it is possible to grasp the budget / actual results for the current period and the budget for the next period.

Further, when the predicted value of the ratio is input, the transaction amount indicated by the individual transaction data belonging to the current period is multiplied by the predicted value to obtain the next period transaction data (budget data). The forecast value is comprehensive in monthly units (quarterly or yearly), and is used for each transaction data for the current period included in the period to which the forecast value is applied.

In other words, it is assumed that the following transaction data (sales to company A) is as follows.
January 10: 3,000 yen January 15: 3,000 yen January 20: 4,000 yen

Then, as shown in FIG. 23, assuming that the predicted value of the ratio between the current period value and the predicted value for the next period is “105”%, the processing unit 120 determines that the predicted value of 105% for the three current periods. Multiply each transaction amount in the transaction data. By this, the processing unit 120 will out of current transaction data, the next budget data amounts to 105% was prepared.
FIG. 24 is a screen 1300 showing a transaction list showing each budget data for the next period. As shown in FIG. 23, in the display unit 1301 for the amount of three transactions in the current period, a numerical value multiplied by 105% is displayed.
The budget data for the next period generated by the processing unit 120 is registered in the transaction data registration unit 112.

The transaction data for the current fiscal year includes a mixture of budget and actual results. However, when the processing unit 120 generates the next transaction data (budget data) from the current transaction data, the progress status of each transaction data is all reset. , The transaction is left open. That is, the next transaction data is generated as complete budget data with no actual part.
Of the items included in the transaction data, items other than the amount, progress status, and date are copied directly to the next budget data as they are. The date included in the transaction data is changed from a numerical value indicating the current period to a numerical value indicating the next period, and the date is the same as that of the current period.

In the present embodiment, since the predicted value of the ratio can be input to the numerical value of the monthly unit (or quarter quarter / year unit) summarized in the aggregation table, the annual budget of the next budget in the monthly unit (or quarter quarter / year unit) The overall picture can be easily grasped.
Moreover, in order to create budget data for the next period by multiplying the forecast values entered in monthly units (or quarterly / yearly units) with individual transaction data, detailed daily transactions based on the current period transaction data. Next budget data for can be created. Therefore, the user can browse various forms and tabulation tables on the system 1 based on the budget data for the next period, and easily obtain various materials related to the management for the next period.
Note that the function for creating the next budget data described above is not limited to creating the next budget data from the current transaction data, but can create budget data for the second and subsequent periods from the current transaction data, It is also used to create budget data for the next and subsequent periods from transaction data for the next period.

  In addition, this invention is not limited to the said embodiment, A various deformation | transformation is possible within the range of the matter described in the claim.

Further, this specification is not intended to disclose only the invention described in the claims, but also to disclose various inventions other than the invention described in the claims.
In particular, the description of the above embodiment includes a description of another invention that does not require some or all of the elements in the invention described in the claims. Should be understood without being bound by the problems and solutions relating to the invention described in the claims.

It is a figure which shows the flow of the current fund in a budget bookkeeping. It is a functional block diagram of this system. It is a menu screen of this system. It is a menu screen of this system. It is a transaction input screen of this system. It is a division figure of the subject inputted into a subject input part. It is a transaction input screen of this system. It is a transaction list screen of this system. It is a menu screen of this system. It is a cash register screen of this system. It is a subledger screen of this system. It is a subledger screen of this system. It is a menu screen of this system. It is a cash flow chart screen of this system. It is a profit plan table screen of this system. It is an expected balance sheet screen of this system. It is a relationship diagram of transaction data and journal diary data in which budget / actual results are mixed. It is a figure which shows a reference information table. It is a figure which shows a reference information table. It is a transaction input screen of this system. It is a transaction input screen of this system. It is a flowchart which shows the flow of the process using this system. It is a summary table screen for inputting the ratio forecast value of the next budget. It is a transaction list screen showing the budget data of the next budget.

1 Budget management accounting computer system 112 Transaction data registration section (storage means)
120 processing unit (journal data generation means, setting means, generation means, etc.)
500 Transaction input screen (input means)

Claims (7)

An accounting computer system for budget management,
Input means for entering budget data for each transaction;
Storage means for storing the input budget data;
Journal data generation means for generating journal data from budget data,
With
The budget data is data including a series of dates from the occurrence of a transaction to settlement of the transaction and the amount of the transaction,
The input means is configured to be able to divide and input the amount of transaction in the budget data into amounts for each transaction on one or more bookkeeping constituting the transaction,
The journal data generating means is configured to generate journal data on a bookkeeping transaction actually performed from data of a part related to a bookkeeping transaction actually performed in the budget data.
A budget management accounting computer system characterized by that. The budget data indicates item data indicating a transaction item indicated by the budget data, and whether the item increases or decreases assets, liabilities, capital, revenue, or expenses. Includes increase / decrease data,
The budget management accounting computer system according to claim 1, wherein the journal data generation means is configured to journal journal transactions actually performed using the subject data and the increase / decrease classification data.   The budget management accounting computer system according to claim 2, wherein the subject indicated by the subject data is an account subject and a counterpart subject in which the account subject is secondarily generated.   The budget management accounting computer system according to any one of claims 1 to 3, wherein the input means is configured to be able to input a progress state of a transaction indicated by the budget data. The input means is configured to be able to input a transaction occurrence date as a date related to a transaction indicated by budget data,
Setting means for setting information for calculating a closing date and / or a settlement date from the transaction occurrence date;
When a transaction occurrence date is input, based on the information set by the setting unit, a generation unit that generates a closing date and / or a settlement date as date data related to a transaction indicated by budget data;
The budget management accounting computer system according to any one of claims 1 to 4, further comprising: Budget generating means for generating, from a plurality of budget data belonging to the first accounting period, a plurality of budget data belonging to a second accounting period after the first accounting period;
Budget creation means
Predicted value input means for receiving an input of a predicted value of the ratio of the transaction amount indicated by the budget data of the second accounting period to the transaction amount indicated by the budget data of the first accounting period;
Multiply the budget data of the first accounting period into the budget data of the second accounting period by multiplying the transaction value of each budget data included in the first accounting period by the predicted value of the ratio. Conversion means to
A budget management accounting computer system according to any one of claims 1 to 5.   A computer program for causing a computer to function as the budget management accounting computer system according to any one of claims 1 to 6.