JP7741739B2 - Data linkage system, synchronization device, and synchronization program - Google Patents

Description

The present invention relates to a data linkage system, a synchronization device, and a synchronization program.

Traditionally, accounting firms have used accounting systems to prepare tax returns based on requests from their client companies. Small and medium-sized businesses often use accounting software to manage their internal profits and finances, and outsource tax return work to tax accountants. Accounting systems are provided in a variety of formats by a variety of businesses, and the format of the journal entry data created by each accounting system varies from business to business.

In addition, the accounting systems used by accounting firms are often different from those used by small and medium-sized enterprises. It is not desirable for different journal entries to exist in each accounting system. However, unless the format of the journal entry data created in the accounting system of the small and medium-sized enterprise is converted to the format of the accounting system used by the accounting firm, the accounting system used by the accounting firm cannot import the journal entry data.

Patent Document 1 discloses a technology in which accounting firms and clients mutually modify and send journal data, thereby controlling inconsistencies in the journal data that arise from such modifications.

Patent Document 2 discloses a technology that synchronizes newly registered, modified, or deleted journal data by sending it to the other party via email as differential data or modified differential data (journal data newly registered, modified, or deleted at the accounting firm).

Japanese Patent Application Laid-Open No. 2003-141322 Japanese Patent Application Laid-Open No. 2004-054636

Traditional accounting systems used by accounting firms would read journal data in formats such as CSV (Comma Separated Value) obtained from other accounting systems used by the accounting firm's business clients, and then convert and import each item before importing it. The accounting firm would then add closing adjustments such as depreciation expenses and reserves to the journal data to complete its tax return. However, traditional accounting systems imported journal data from other accounting systems at fixed times (for example, monthly), which meant that the accounting systems used by accounting firms had to take a long time to understand their clients' journal entries.

Furthermore, when accounting firm staff enter journal entries, such as in bookkeeping services, there are no synchronization issues because the client data is stored on the accounting firm's server. Even with different accounting systems, one-way synchronization was possible, with one accounting system simply accepting journal entry data from another system. However, two-way synchronization between different accounting systems at any time has not yet been achieved.

One reason two-way synchronization is not possible is that there are differences in the information required by accounting firms and clients. For example, at accounting firms, tax accountants believe that information about clients and departments is not necessary for filing tax returns. For this reason, accounting firms have not incorporated client and department information into their systems. However, it is possible to close the books by simply importing the client's date, account title, amount, and summary into the accounting firm's accounting system. However, even if the accounting firm calculates depreciation expenses by department in closing journal entries, the accounting firm's accounting system is unable to send the calculated closing journal entries in a way that matches the accounting system used by the client.

The technologies disclosed in Patent Documents 1 and 2 do not allow for the interchange of journal entry data created in different accounting systems, which raises the risk of incorrect journal entries being recorded by both the accounting firm and the client. Furthermore, manually synchronizing the journal entry data of each accounting system is inefficient, posing the risk of incorrect journal entries being recorded.

The present invention was developed in light of this situation, and aims to synchronize data between different accounting systems.

The data linkage system of the present invention comprises a first accounting system that extracts accounting journal entry candidates and performs final journal entries, a second accounting system that accepts the final journal entries performed in the first accounting system, a conversion unit that converts the first journal entry data created by the first accounting system into a data format that can be imported by the second accounting system, and a synchronization device that has a synchronization table that stores the converted first journal entry data so that it can be imported by the second accounting system.The synchronization device has a waiting unit that waits for an import request for the first journal entry data from the second accounting system, and when it receives an import request from the second accounting system, reads the converted first journal entry data from the synchronization table and transmits it to the second accounting system.

According to the present invention, the first accounting system extracts accounting journal entry candidates and finalizes the journal entries, making it less likely that incorrect journal entries will be registered. Furthermore, the second accounting system imports the first journal entry data converted into a data format that the second accounting system can import, making it possible to synchronize the journal entries of the first and second accounting systems.
Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments.

1 is a diagram illustrating an example of a system configuration of a data linkage system according to first and second embodiments of the present invention; 2 is a block diagram showing an example of a configuration of functional blocks related to downstream of the data linkage system according to the first embodiment of the present invention; FIG. 1 is a block diagram showing an example of the configuration of functional blocks related to the upstream of a data linkage system according to a first embodiment of the present invention; FIG. 10 is a block diagram showing an example of a configuration of functional blocks related to downstream of a data linkage system according to a second embodiment of the present invention. FIG. 10 is a block diagram showing an example of the configuration of functional blocks related to the upstream of a data linkage system according to a second embodiment of the present invention. 3A and 3B are diagrams illustrating examples of table configurations of a conversion table and an inverse conversion table according to the first and second embodiments of the present invention; FIG. 10 is a diagram showing how data in a synchronization table changes during downstream addition processing according to the first exemplary embodiment of the present invention. FIG. 10 is a diagram illustrating how data in a synchronization table changes during downstream modification processing according to the first exemplary embodiment of the present invention. FIG. 10 is a diagram illustrating how data in a synchronization table changes during downstream deletion processing according to the first exemplary embodiment of the present invention. 10A and 10B are diagrams illustrating changes in data in a synchronization table during upstream addition processing according to the first embodiment of the present invention. 10A and 10B are diagrams illustrating changes in data in a synchronization table during processing to cancel an upstream addition according to the first embodiment of the present invention. FIG. 10 is a diagram showing how data in a synchronization table changes during upstream modification processing according to the first embodiment of the present invention. 10A and 10B are diagrams illustrating changes in data in a synchronization table during processing to cancel upstream modifications according to the first embodiment of the present invention. FIG. 10 is a diagram showing how data in a synchronization table changes during upstream deletion processing according to the first exemplary embodiment of the present invention. 10A and 10B are diagrams illustrating changes in data in a synchronization table during cancellation of upstream deletion according to the first exemplary embodiment of the present invention. FIG. 10 is a diagram showing an example of an import screen displayed on the target system in downstream addition, modification, and deletion processing according to the first embodiment of the present invention. FIG. 10 is a diagram illustrating an example of an export screen displayed on the target system in the upstream addition, modification, and deletion process according to the first embodiment of the present invention; FIG. 10 is a diagram showing an example of an export screen displayed on the target system in the process of canceling upstream addition, modification, or deletion according to the first embodiment of the present invention. FIG. 10 is a diagram showing an example of an import screen displayed on the target system in the upstream addition process according to the first embodiment of the present invention. FIG. 10 is a diagram showing an example of an import screen displayed on the target system in upstream modification and deletion processing according to the first embodiment of the present invention. FIG. 10 is a diagram showing an example of an import screen displayed on the target system during the process of canceling an upstream addition according to the first embodiment of the present invention. FIG. 10 is a diagram showing an example of an import screen displayed on the target system in the process of canceling upstream modification and deletion according to the first embodiment of the present invention. FIG. 10 is a diagram showing an example of a confirmation processing screen display for unconfirmed journal entries according to the first embodiment of the present invention; 1 is a block diagram illustrating an example of a hardware configuration of a computer according to first and second embodiments of the present invention. FIG. 10 is a diagram illustrating an example of the overall configuration of a data linkage system according to a modified example of the second embodiment of the present invention.

The following describes embodiments of the present invention with reference to the accompanying drawings. In this specification and drawings, components having substantially the same function or configuration are designated by the same reference numerals, and redundant description will be omitted.

In the embodiment described below, a system for managing the profit and loss management and finances of businesses that are clients of the accounting firm is treated as the first main accounting system. The first main accounting system is abbreviated as the "main system." In the main system, accounting entry candidates are automatically extracted and final entries are made. In addition, the accounting system used by the accounting firm to file tax returns on behalf of clients is treated as the second target accounting system. The second target accounting system is abbreviated as the "target system." The target system accepts the final entries made in the main system.

A system in which the main system and target system synchronize their journal entries in both directions is called a "synchronization system" or "synchronization subsystem." Both synchronization systems and synchronization subsystems are used in the data integration system described below, and their functions are performed by a synchronization device that synchronizes journal entries between the main system and target system. In the first accounting system, for example, accounting data is managed by each company department. On the other hand, in the second accounting system, accounting entries are made for the entire company's financial statements, tax returns, expenses, and revenues. For this reason, the second accounting system handles fewer items than the first accounting system. In order for the first accounting system to import data journalized in the second accounting system, it must be converted to data that matches the functions of the first accounting system. Therefore, a synchronization device has the function of synchronizing data between different accounting systems. Synchronization devices are often owned by the above-mentioned businesses, but can also be owned by data synchronization companies. A data synchronization company is a company that provides a service that synchronizes journal entry data used for accounting processing between the main system 200 and the target system 300.

[System configuration example]
FIG. 1 is a diagram showing an example of the system configuration of data linkage systems 100 and 100A according to the first and second embodiments.

The upper part of FIG. 1 shows an example of the system configuration of a data linkage system 100 according to the first embodiment.
The data linkage system 100 is made up of a main system 200 , a synchronization subsystem 210 , and a target system 300 .

The main system 200 is an example of a first accounting system used by, for example, a data synchronization company or business. In this specification, a person who uses the main system 200 to provide services to the target system 300 is called a user.
The data synchronization company or business uses the main system 200 and the synchronization subsystem 210 to manage the overall processing of the data linkage system 100. The synchronization subsystem 210 is used as an example of a synchronization device integrated with the main system 200. Therefore, data transfer from the main system 200 to the synchronization subsystem 210 does not go via an external network such as the Internet.

The target system 300 is an example of a second accounting system used in, for example, an accounting firm.
The main system 200 confirms the journal data of the target system 300 through the synchronization subsystem 210. For example, journal data that has been journalized in the target system 300 is sent to the main system 200 via the synchronization subsystem 210. The main system 200 then rewrites the data with appropriate content, and the confirmed journal data is returned to the target system 300. The target system 300 then imports the confirmed journal data. In this way, the journal data managed by the main system 200 and the journal data managed by the target system 300 are synchronized.

The lower part of FIG. 1 shows an example of the system configuration of a data linkage system 100A according to the second embodiment.
The data linkage system 100A is made up of a main system 200A, a synchronization system 400, and a target system 300A.

Main system 200A is an example of a first accounting system used by a business, for example.
The target system 300A is an example of a second accounting system used in, for example, an accounting firm. The first accounting system and the second accounting system use different accounting software, and therefore the various data items used in each system are different.
The synchronization system 400 is a web system configured on the cloud and is managed by a data synchronization company that manages the overall processing of the data linkage system 100 A. For this reason, the synchronization system 400 is used as an example of a synchronization device configured separately from the main system 200.

The main system 200A and the target system 300A each access the synchronization system 400 via a network such as the Internet. The synchronization system 400 then transmits data received from the main system 200A to the target system 300A, and transmits data received from the target system 300A to the main system 200A.

The processing of data linkage systems 100 and 100A will be described below. In the following description, the processing of synchronizing data from the main system to the target system will be referred to as "downstream synchronization." Conversely, the processing of synchronizing data from the target system to the main system will be referred to as "upstream synchronization." Here, an overview of downstream and upstream synchronization will be described based on data linkage system 100.

(Downstream Synchronization Overview)
The target system 300 holds a slip number that guarantees the uniqueness of the journal data created by the main system 200. This slip number is added to the journal data.
The journal entries created in the main system 200 are always generated in the target system 300. Therefore, the journal entry data created in the main system 200 is imported into the target system 300. The synchronization subsystem 210 deletes the synchronized data.

(Upstream Synchronization Overview)
The journal data representing the journal entries created in the target system 300 is received by the main system 200 as unapproved data. Then, when the journal data is approved in the main system 200, the approved journal data is sent to the target system 300 via the synchronization subsystem 210. The synchronization subsystem 210 then deletes the synchronized data.
It should be noted that journal data that is not approved by the main system 200 is not incorporated into the journalization of the main system 200. Then, the target system 300 deletes the journal data that is not approved.

When the journal data created by the target system 300 is corrected, two types of processing are assumed to be performed by the main system 200: accepting the correction and canceling the correction.
When the main system 200 receives unconfirmed journal data obtained by reverse-converting the journal data from the target system 300, it corrects the journal data and creates confirmed journal data.
Alternatively, the main system 200 does not correct the unconfirmed journal data, but instructs the target system 300 to delete the journal data.

Next, configuration and operation examples of the data linkage systems 100 and 100A according to each embodiment will be described, focusing on downstream processing and then upstream processing.

[First embodiment]
First, a configuration example of a data linkage system 100 according to the first embodiment will be described with reference to FIGS. 2 and 3. FIG.

Figure 2 shows an example configuration of functional blocks related to the downstream of the data linkage system 100 according to the first embodiment. Here, an example configuration and operation of functional blocks related to downstream processing via the synchronization subsystem 210 will be described. In the downstream, processing proceeds in the order of the main system 200, synchronization subsystem 210, and target system 300.

The main system 200 performs accounting journal entries using the automatic journal entry unit 22 shown in Figure 3 (described below) to create journal entry data 20. The journal entry data 20 is output to the synchronization subsystem 210. In the following description, accounting journal entries are abbreviated as "journal entries." The synchronization subsystem 210 includes a conversion unit 30, a conversion table 31, a synchronization table 33, and a standby unit 34.

The conversion unit 30 converts the journal data 20 (an example of first journal data) created by the main system 200 into a data format that can be imported by the target system 300. In doing so, the conversion unit 30 refers to the conversion table 31 to convert the journal data 20 into journal data 32 in a data format that can be imported by the target system 300.

The main system 200 and the target system 300 may manage the same items using different names, symbols, etc. For this reason, the conversion table 31, as shown in Figure 6 described below, stores the correspondence between terms used in the main system 200 and the target system 300 for each item in the journal data 20. Examples of correspondence between terms include, for example, "entertainment expenses" in the main system 200 and "entertainment expenses" in the target system 300 for debit items, and "cash" in the main system 200 and "petty cash" in the target system 300 for credit items. In the following explanation, the process of converting data items used in the main system 200 to data items used in the target system 300 is referred to as "conversion."

The synchronization table 33 stores the journal data 32 (an example of the converted first journal data) so that it can be imported by the target system 300. That is, the converted journal data 32 is stored in the synchronization table 33. This converted journal data 32 is stored in the synchronization table 33 until it is synchronized with the journal data managed by the target system 300. The standby unit 34 has the following roles (1) and (2).

(1) Controlling whether the target system 300 properly imports the journal data 32. For example, if there is unimported journal data, the target system 300 imports the unimported journal data and updates the journal in the target system 300. The standby unit 34 records in the synchronization table 33 that the target system 300 has updated the journal.

(2) The standby unit 34 performs the above control in two stages.
(First stage) When the target system 300 imports the journal data 32 read from the synchronization table 33, the standby unit 34 receives information indicating that the journal data 32 has been successfully imported from the target system 300. Using this information, the standby unit 34 manages that the target system 300 has successfully imported the journal data 32.
(Second stage) Next, the standby unit 34 receives information from the target system 300 indicating that the journal entry has been successfully updated using the journal entry data 32. Using this information, the standby unit 34 manages that the target system 300 has successfully updated the journal entry using the journal entry data 32. Furthermore, upon receiving the information indicating that the journal entry has been successfully updated, the standby unit 34 changes the record in the synchronization table 33 to "updated."

When the standby unit 34 receives an inquiry from the target system 300, it transmits the journal data 32 read from the synchronization table 33 to the target system 300. For example, when the target system 300 inquires about the presence or absence of journal data 32, if the journal data 32 is recorded in the synchronization table 33, the standby unit 34 returns the unacquired data that has not been acquired by the target system 300 to the target system 300.

At this time, the standby unit 34 sends the journal data 32 read from the synchronization table 33 as unacquired data to the target system 300 via API (Application Programming Interface) integration. Furthermore, when information indicating that the target system 300 has completed the process of acquiring unacquired data, i.e., updating the journal entries, is returned to the target system 300, the standby unit 34 writes in the synchronization table 33 that the journal entries have been updated. The standby unit 34 then deletes the journal data 32 acquired by the target system 300 from the synchronization table 33.

The target system 300 includes a journal entry creation unit 50. The target system 300 receives unacquired journal entry data 38 from the synchronization subsystem 210 via API integration. The journal entry creation unit 50 then queries the standby unit 34 to determine whether journal entry data 32 is available. When the standby unit 34 notifies the journal entry creation unit 50 that unacquired journal entry data 32 is stored in the synchronization table 33, the journal entry creation unit 50 acquires the unacquired journal entry data 32 via API integration via the standby unit 34. The journal entry creation unit 50 then imports the journal entry data 32 into the target system 300 and updates the journal entry. The journal entry creation unit 50 then outputs an import result to the standby unit 34 of the synchronization subsystem 210, including information indicating that the unacquired journal entry data 32 has been acquired and that the import process for the journal entry data 32 has been successfully completed.

As described above, API linkage is used when sending and receiving data between the standby unit 34 of the synchronization subsystem 210 and the journal entry creation unit 50 of the target system 300. In API linkage, the receiving functional unit, for example, the standby unit 34, mainly provides the API to the target system 300. In API linkage, the journal entry creation unit 50 passes information such as the type of accounting system used as the target system 300 and the ID of the accounting firm using the target system 300, and the standby unit 34 authenticates the ID of the accounting firm using an authentication unit (not shown). The journal entry creation unit 50 then returns a response to the standby unit 34 in response to the request from the standby unit 34.

In this embodiment, the journal entry creation unit 50 inquires (requests) about the presence or absence of unimported journal data from the standby unit 34, and the standby unit 34 transmits (responses) the unimported journal data to the journal entry creation unit 50. In the following explanation, when API collaboration is performed between different systems, it is assumed that the system providing the API performs authentication processing of the system sending the request using an authentication unit (not shown), and then responds to the request.

Figure 3 shows an example configuration of functional blocks related to the upstream of the data linkage system 100 according to the first embodiment. Here, an example configuration and operation of functional blocks related to upstream processing through the synchronization subsystem 210 will be described. In the upstream, processing proceeds in the order of the target system 300, synchronization subsystem 210, main system 200, synchronization subsystem 210, and target system 300.

The target system 300 includes a transmission unit 52 in addition to the journal entry creation unit 50 shown in FIG.
The transmission unit 52 transmits the journal entry data 51 of the accounting entries that have been added, modified, or deleted in the target system 300 to the synchronization subsystem 210 via API collaboration.

The synchronization subsystem 210 reverse-converts journal entry data 51 (an example of second journal entry data) created by the target system 300 into a data format that can be imported by the main system 200. The synchronization subsystem 210 also converts journal entry data 24 (an example of second journal entry data after finalized journal entry), which is journal entry data created by the main system 200 in response to journal entries made in the target system 300, into a data format that can be imported by the target system 300, and transmits journal entry data 38 (an example of second journal entry data after conversion) to the target system 300.

As shown in FIG. 3, the synchronization subsystem 210 includes a receiving unit 35, an inverse conversion unit 36, and an inverse conversion table 37 in addition to a conversion unit 30, a conversion table 31, a synchronization table 33, and a waiting unit .
The receiving unit 35 receives the journal data 51 transmitted from the transmitting unit 52 of the target system 300 to the synchronization subsystem 210 via API linkage.

As described above, API integration is used when data is sent from the sending unit 52 of the target system 300 to the receiving unit 35 of the synchronization subsystem 210. The receiving unit 35 provides an API to the target system 300. The sending unit 52 queries (requests) the synchronization subsystem 210 as to whether or not journal data 51 can be sent, and the receiving unit 35 notifies (responses) the target system 300 that it is able to receive the journal data 51. The sending unit 52 then sends the journal data 51 to the synchronization subsystem 210, and the receiving unit 35 receives the journal data 51.

The inverse conversion unit 36 refers to the inverse conversion table 37 and inversely converts the journal data 51 received from the target system 300 into a data format that can be imported by the main system 200. To this end, the inverse conversion unit 36 inversely converts the items in the journal data 51 input from the receiving unit 35 into items used by the main system 200, and stores the inversely converted journal data 51 in the synchronization table 33. This inversely converted journal data 51 becomes unconfirmed journal data by the main system 200.

The process of converting data items used in the target system 300 into data items used in the main system 200 is the reverse of the item conversion process shown in Figure 2. Therefore, in the following explanation, the process of converting data items used in the target system 300 into data items used in the main system 200 will be referred to as "reverse conversion."

The reverse conversion table 37 is a table that stores the correspondence between items used in the target system 300 and items used in the main system 200. The reverse conversion table 37 stores the correspondence between words used in the main system 200 and the target system 300 for each item in the journal data 51.

The synchronization table 33 stores the reverse-converted journal data 51 until the journal entries in the main system 200 are synchronized with the journal entries created in the target system 300. The reverse-converted journal data 51 stored in the synchronization table 33 is read by the main system 200 as unconfirmed journal data 21.

In other words, the main system 200 reads the inversely converted journal data 51 stored in the synchronization table 33 as unconfirmed journal data 21. When the main system 200 performs a confirmed journal entry on the unconfirmed journal data 21, the unconfirmed journal data 21 is imported into the synchronization subsystem 210 as journal data 24.

As shown in FIG. 3, the main system 200 includes an automatic journalizing unit 22 and a confirmation processing unit 23 .
The automatic journalizing unit 22 is used as an example of a journalizing candidate extraction unit that extracts journalizing candidates for the unconfirmed journalizing data 21 (an example of second journalizing data), which is the reverse-converted journalizing data 51. The automatic journalizing unit 22 performs the automatic journalizing invented by the present inventor, and displays the results of the automatic journalizing, in which highly probable journalizing candidates are extracted from the information on unprocessed journalizing, on the confirmation processing unit 23.

Here, an outline of the automatic journalizing process performed by the automatic journalizing unit 22 will be described.
The automatic journalizing unit 22 automatically infers journalization based on the general inference database D1, the history inference database D2, and the reconciliation inference database D3 for the unconfirmed journalizing data 21. The process by which the automatic journalizing unit 22 infers automatic journalization is explained in detail in Japanese Patent No. 4783200 by the present inventor, so only a brief explanation will be given here.

Journalization by the automatic journalizing unit 22 is performed based on the following three inferences. Journalization performed automatically based on these three inferences is called "automatic journalizing." Automatic journalizing is performed, for example, by automatic processing using AI (artificial intelligence).

(1) General inference (inference from general commercial transactions)
General inference is a process used, for example, to journalize a voucher received from a counterparty with which a user has done business for the first time. General inference uses a general inference database D1 (an example of a general inference storage unit) that is referenced to infer general debit and credit items. The automatic journalizing unit 22 references the general inference database D1 and infers general debit and credit items based on at least one or more items of the voucher date, amount, and summary contained in the unconfirmed journalizing data 21. When the automatic journalizing unit 22 performs general inference, it references wording, etc. used to determine the "summary" that is stored in the general inference database D1.

(2) Historical inference (inference from similar entries entered in the past)
Historical inference is a process used to determine the similarity between data that has been processed as a correct journal entry in the past and the data to be processed this time, and to perform journal entries similar to those previously performed with counterparties with which the transaction has been conducted in the past. That is, historical inference uses a historical inference database D2 (an example of a historical inference storage unit) that is referenced to infer specific debit and credit items based on unconfirmed journal entry data 21 that have been journalized in the past.

The automatic journalizing unit 22 references the history inference database D2 and infers specific debit and credit items based on the voucher date, counterparty, and summary contained in the unconfirmed journalizing data 21. When the automatic journalizing unit 22 performs history inference, it makes inferences based on, for example, patterns of voucher date, counterparty, and summary from the previously journalized data stored in the history inference database D2.

(3) Reconciliation inference (inference from past accounting events such as accounts receivable and borrowings)
Reconciliation inference is a process used to make journal entries based on information about an accounting event that precedes the accounting event that is processed when, for example, an account receivable is received or travel expenses are settled. In other words, reconciliation inference uses a reconciliation inference database D3 (an example of a reconciliation inference storage unit) that is referenced to infer the reconciliation of unconfirmed journal data 21 that corresponds to an accounting event that occurred in the past.

The automatic journalizing unit 22 references the reconciliation inference database D3 based on accounting events that occurred in the past, and infers reconciliation for the pending journalizing data 21. In reconciliation inference, the automatic journalizing unit 22 references the accounts receivable file, settlement file, borrowings file, etc. stored in the reconciliation inference database D3, and makes inferences based on matching events among past accounting events.

The automatic journalizing unit 22 then performs at least one of the following inferences: general inference, historical inference, and reconciliation inference, and outputs the journalizing results to the finalization processing unit 23.

The confirmation processing unit 23 confirms one journal entry from the journal entry candidates extracted by the automatic journal entry unit 22 and creates journal entry data 24 (an example of second journal entry data for which a confirmed journal entry has been performed). At this time, the confirmation processing unit 23 displays the journal entry candidates, which are the results of the automatic journal entry by the automatic journal entry unit 22, on a display device and allows the user to confirm the journal entry through operation. The confirmation processing unit 23 also outputs the results of the automatic journal entry as journal entry data 24 to the conversion unit 30 of the synchronization subsystem 210.

The conversion unit 30 of the synchronization subsystem 210 refers to the conversion table 31 and converts the journal data 24 input to the synchronization subsystem 210 into journal data 38 that can be imported by the target system 300. The conversion unit 30 then stores the converted journal data 38 in the synchronization table 33.

The standby unit 34 waits for a request from the target system 300 to import the journal data 32. When the standby unit 34 receives an import request from the target system 300, it sends the journal data 38 to the target system 300, and after the journal entry is updated in the target system 300, it deletes the journal data 32 from the synchronization table 33.

Second Embodiment
Next, a configuration example of a data linkage system 100A according to the second embodiment will be described with reference to FIGS. 4 and 5. FIG.

Figure 4 shows an example configuration of functional blocks related to the downstream of a data linkage system 100A according to the second embodiment. Here, an example configuration and operation of functional blocks related to downstream processing through the synchronization system 400 will be described. In the downstream, processing proceeds in the order of the main system 200A, synchronization system 400, and target system 300A.

The main system 200A and the synchronization system 400 are systems installed in different locations, etc. Therefore, data is sent and received between the main system 200A and the synchronization system 400 via the Internet, etc. In this embodiment, various types of data are sent and received via API linkage between the main system 200A and the synchronization system 400.

The main system 200A includes a transmitting unit 25 .
The transmission unit 25 transmits the journal entry data 20 of the accounting entries that have been added, modified, or deleted in the main system 200A to the synchronization system 400 via API linkage.

The synchronization system 400 includes a receiving unit 39 in addition to the conversion unit 30, conversion table 31, synchronization table 33, and waiting unit 34 included in the synchronization subsystem 210 shown in FIG.
As described above, the main system 200A and the synchronization system 400 are configured separately. Therefore, the main system 200A is provided with a transmitting unit 25 for transmitting the journal data 20, and the synchronization system 400 is provided with a receiving unit 39 for receiving the journal data 20.

API integration is used when data is sent from the sending unit 25 of the main system 200A to the receiving unit 39 of the synchronization system 400. The receiving unit 39 provides an API to the main system 200A. The sending unit 25 queries (requests) the synchronization system 400 as to whether or not the journal data 20 can be sent, and the receiving unit 39 notifies (responses) the main system 200A that it is able to receive the journal data 20. The sending unit 25 then sends the journal data 20, and the receiving unit 39 receives the journal data 20.

The processing flow after the receiving unit 39 receives the journalizing data 20 is the same as the processing flow in the synchronization subsystem 210 and the target system 300 shown in FIG.
That is, the conversion unit 30 refers to the conversion table 31 to convert the journal data 20 received by the receiving unit 39 from the main system 200A into journal data 32 for the target system 300A and stores it in the synchronization table 33.

Figure 5 shows an example configuration of functional blocks related to the upstream of a data linkage system 100A according to the second embodiment. Here, an example configuration and operation of functional blocks related to upstream processing through the synchronization system 400 will be described. In the upstream, processing proceeds in the order of target system 300A, synchronization system 400, main system 200A, synchronization system 400, and target system 300A.

The target system 300A includes a transmission unit 52 in addition to the journal entry creation unit 50 shown in FIG.
The transmission unit 52 transmits the journal data 51 journalized in the target system 300A to the synchronization system 400 via API linkage.

The synchronization system 400 includes a receiving unit 39 and a transmitting unit 40 in addition to the conversion unit 30, conversion table 31, synchronization table 33, standby unit 34, receiving unit 35, inverse conversion unit 36, and inverse conversion table 37 provided in the synchronization subsystem 210 shown in FIG. 3. Journal data 51 and converted journal data 38 are sent and received between the synchronization system 400 and the target system 300A via API linkage.

The items of the journal data 51 received by the receiving unit 35 of the synchronization system 400 from the target system 300A are inversely converted by the inverse conversion unit 36, which references the inverse conversion table 37, and stored in the synchronization table 33. The transmitting unit 40 (an example of a first transmitting unit) then transmits the inversely converted journal data 51 (an example of second journal data after inverse conversion) read from the synchronization table 33 to the main system 200A.

The main system 200A includes a transmitter 25 and a receiver 26 in addition to the automatic journalizing unit 22 and confirmation processing unit 23 shown in Figure 3. Unconfirmed journalizing data 21 and journalizing data 24 are sent and received between the main system 200A and the synchronization system 400 via API linkage.

The receiving unit 26 (an example of a second receiving unit) receives the reverse-converted journal data 51 transmitted from the transmitting unit 40 of the synchronization system 400 as unconfirmed journal data 21. The unconfirmed journal data 21 is automatically journalized by the automatic journalizing unit 22 of the main system 200A. Then, when the journalization is confirmed by the confirmation processing unit 23, journal data 24 is created.

API integration is used when data is sent from the transmitter 40 of the synchronization system 400 to the receiver 26 of the main system 200A. The receiver 26 provides an API to the main system 200A. The transmitter 40 of the synchronization system 400 queries (requests) the main system 200A as to whether or not it is possible to send the inversely converted journal data 51, and the receiver 26 of the main system 200A notifies (responses) the synchronization system 400 that it is able to receive the inversely converted journal data 51. The transmitter 40 then transmits the inversely converted journal data 51, and the receiver 26 receives the inversely converted journal data 51.

The transmission unit 25 (an example of a second transmission unit) of the main system 200A transmits journal data 24 (an example of second journal data for which final journalization has been performed) to the synchronization system 400. This transmission unit 25 controls requests and responses to the synchronization system 400. The transmission unit 25 then transmits the journal data 24 to the synchronization system 400 via API integration.

The receiving unit 39 of the synchronization system 400 responds to requests from the transmitting unit 25 of the main system 200A. The receiving unit 39 receives journal data 24, which is journal entries confirmed by the confirmation processing unit 23, from the transmitting unit 25 of the main system 200A. The converting unit 30 of the synchronization system 400 then refers to the conversion table 31 and converts the journal data 24 into journal data 38 for the target. The converting unit 30 then stores the journal data 38 converted from the journal data 24 in the synchronization table 33.

When the standby unit 34 of the synchronization system 400 receives an import request from the journal entry creation unit 50 of the target system 300, it sends journal entry data 38 to the target system 300. Furthermore, when the standby unit 34 receives the import results from the journal entry creation unit 50, it deletes the journal entry data 38 from the synchronization table 33.

FIG. 6 is a diagram showing an example of the table configuration of the conversion table 31 and the inverse conversion table 37. As shown in FIG.
The conversion table 31 is provided to convert items used in the main systems 200 and 200A into items used in the target systems 300 and 300A. The conversion table 31 includes items for the main system and the target system. The conversion table 31 stores source and destination data for each account item and consumption tax category. For example, the account item "Cash" used in the main systems 200 and 200A is converted to "Petty Cash" through the conversion table 31. The account item "Office Supplies Expenses" used in the main systems 200 and 200A is the same as the account item used in the target systems 300 and 300A. Since the conversion unit 30 converts journal data without determining whether the account items have the same names, the conversion table 31 may contain account items with the same names in each accounting system. Furthermore, because the codes assigned to account items exist within each accounting system, the conversion unit 30 converts the codes in actual processing. Therefore, in practice, account items used in each accounting system often have the same names.

The reverse conversion table 37 is provided to convert items used in the target systems 300 and 300A into items used in the main system 200. The configuration of the reverse conversion table 37 is similar to that of the conversion table 31. For example, the account item "petty cash" used in the target systems 300 and 300A is converted to "cash" through the reverse conversion table 37.

Conversion table 31 and inverse conversion table 37 have substantially the same content. In the description of this embodiment, in order to clearly distinguish between conversion and inverse conversion processing, conversion table 31 is used during conversion and inverse conversion table 37 is used during inverse conversion, but conversion table 31 and inverse conversion table 37 may also be used as the same table.

[Data changes in synchronized tables]
Next, changes in data in the synchronization table 33 will be described in the order of downstream and upstream. The data in the synchronization table 33 changes in the same way in both the data linkage system 100 according to the first embodiment and the data linkage system 100A according to the second embodiment. Therefore, in the following explanation, changes in data in the synchronization table 33 will be described with reference to the configuration example of the data linkage system 100 according to the first embodiment shown in FIGS. 2 and 4.

Downstream Processing
Here, downstream processing will be described in the order of addition, modification, and deletion with reference to FIGS.

<Downstream addition processing>
FIG. 7 shows how the data in the synchronization table 33 changes during downstream addition processing.
The synchronization table 33 manages vouchers (journal entries) created in the main system 200 by voucher number. This voucher record consists of the following fields: category, system name, voucher date, voucher number, debit item, credit item, consumption tax category, amount, summary, and synchronization status category. Note that the voucher record has the same fields in both the main system and the target system. Furthermore, one record is created for one voucher.

For ease of explanation, Figure 7 shows the records of the main system 200 and the target system 300 arranged vertically, but in reality, the items are arranged in the following order: category, main system 200 record (voucher date, ..., summary), target system 300 record (voucher date, ..., summary), and synchronization status category. The system item also stores an identification ID (not shown) that identifies the main system 200 or target system 300.

(Main system and synchronous subsystem processing)
When a journal entry is added in the main system 200, for example, journal entry data 20 is created with a voucher number of "00012." The voucher date of this journal entry data 20 is "2021-4-5," the debit item is "entertainment expenses," the credit item is "cash," the consumption tax classification is "taxable," the amount is "11,000," and the summary is "dining with business partner."

The conversion unit 30 refers to the conversion table 31 to convert the contents of the debit items, credit items, and consumption tax classifications in the journal data 20 into the contents of the target system 300, and creates journal data 32 for the target system.

For example, the main system 200 and the target system 300 differ in the contents of the debit items, credit items, and consumption tax classification. For the debit items, the main system 200 uses "entertainment expenses" and the target system 300 uses "entertainment expenses." For the credit items, the main system 200 uses "cash" and the target system 300 uses "petty cash." For the consumption tax classification, the main system 200 uses "taxable" and the target system 300 uses "10."

In this way, the conversion table 31 stores the correspondence for each item when converting an item from the main system 200 to the target system 300 .
Since the contents of items may differ between the main system 200 and the target system 300, the items of the journal data 20 created by the main system 200 can be converted into journal data 32, so that the target system 300 can import the journal data 32.

The conversion unit 30 also adds "1" to the synchronization status category, indicating that the journal data 32 has not been imported, and writes the journal data 32 to the synchronization table 33, leaving blank any voucher numbers that the target system 300 has not yet added. "Not imported" indicates that the target system 300 has not imported the journal data 32. Record (1) in Figure 7 shows how the converted journal data 32 is stored in the synchronization table 33.

(Target system processing)
The journal entry creation unit 50 of the target system 300 inquires of the waiting unit 34 of the synchronization subsystem 210 as to whether or not journal entry data 32 whose synchronization status classification is "not imported" is stored in the synchronization table 33. When the waiting unit 34 receives the inquiry from the journal entry creation unit 50, it replies as to whether or not the journal entry data 32 that has not been imported is stored, and also reads out the journal entry data 32 that has not been imported from the synchronization table 33 and transmits it to the target system 300.

The target system 300 updates the journal entries based on the journal entry data 32 imported from the standby unit 34. The target system 300 also stores the slip numbers assigned by the main system 200 in order to synchronize the correction or deletion of journal entries added by the main system 200.

Furthermore, the target system 300 assigns a slip number managed by the target system 300 to the journal data 32 imported from the standby unit 34. The slip number assigned by the target system 300 is "0084", which is different from the slip number assigned by the main system 200.

Then, the journal entry creation unit 50 of the target system 300 sends the voucher number "0084" assigned by the target system 300 to the standby unit 34. The standby unit 34 writes the voucher number "0084" assigned by the target system 300 and writes "2" to the synchronization status category in the synchronization table 33, indicating that the target system 300 has been updated with the journal entry data 32. Record (2) in Figure 7 indicates that the target system 300 has imported the journal entry data 32 and updated the journal entry.

Then, the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (2) in Figure 7, and after a certain period of time has passed, it deletes record (2) in Figure 7, in which the updated "2" has been written in the synchronization status section, in order to free up space in the synchronization table 33.

Handling Downstream Modifications
FIG. 8 shows how data in the synchronization table 33 changes during downstream modification processing.
When the main system 200 modifies the journal data 20 that it previously added, the target system 300 must also reflect the modified contents of the journal that it previously imported from the synchronization table 33. For example, assume that the main system 200 changes the amount of the journal entry for voucher number "00012" from "11,000" to "22,000" and adds the journal entry before and after the modification to the synchronization table 33.

When the main system 200 corrects a journal entry, it creates journal entry data 20 that includes both the journal entry before the correction and the journal entry after the correction. The reason for creating journal entry data 20 in this manner is that the record of the journal entry before the correction, which is a journal entry added in the past, is deleted after being imported into the target system 300 and does not exist in the synchronization table 33. Therefore, in order to delete the record of the journal entry before the correction that was imported into the target system 300, the record of the journal entry before the correction is stored in the synchronization table 33.

The conversion unit 30 refers to the conversion table 31 to convert the debit items, credit items, and consumption tax categories of the journal data 20. The conversion unit 30 then writes the unimported "1" into the synchronization status category corresponding to the journal entries of deletion D (before correction) and addition A (after correction). In this case, only the amount is corrected, but if other items are changed, the conversion unit 30 will create journal data 32 before and after correction.

Record (1) in Figure 8 represents the contents of synchronization table 33, listing the amounts before and after correction. Record (1) in Figure 8 stored in synchronization table 33 consists of a record with "Delete D (before correction)" stored in the category and a record with "Addition A (after correction)" stored in the category. In the record corresponding to the journal entry for Addition A (after correction), the amount in the main system 200 and target system 300 has changed from "11,000" to "22,000," as the amount is highlighted.

Record (2) in Figure 8 represents the contents of the synchronization table 33 into which records have been imported by the target system 300. The journal entry creation unit 50 of the target system 300 imports the journal entry records for deletion D (before correction) and addition A (after correction) shown in record (1) in Figure 8 via the waiting unit 34. The target system 300 then deletes the previously imported record using the deletion D (before correction) record and adds the addition A (after correction) record. In this way, the journal entries in the target system 300 are updated, and the journal entries in the main system 200 and target system 300 are synchronized.

The target system 300 also holds the voucher number "00012" assigned by the main system 200 in order to synchronize journal entry deletions and modifications with the main system 200. The target system 300 then notifies the standby unit 34 of the new voucher number "0085" assigned by the target system 300 to the record for Addition A (after modification), and the updated status of the journal entry records for Deletion D (before modification) and Addition A (after modification).

The waiting unit 34 writes the voucher number "0085" notified from the target system 300 into the target system 300 voucher number of the record for addition A (after correction) stored in the synchronization table 33. The waiting unit 34 also writes "2" into the synchronization status category of the record for deletion D (before correction) and the record for addition A (after correction) stored in the synchronization table 33, indicating that the journal entry in the target system 300 has been updated.

The target system 300 deletes the record of the voucher in the main system 200 with the voucher number "00012" added, based on the record of Deletion D (before correction). The record with "Deletion D (before correction)" stored in the category is not necessary for synchronizing the journal entries between the main system 200 and the target system 300. However, it is used by the main system 200 and the target system 300 to mutually confirm the contents of the journal entries currently being managed.

After the updated "2" is written in the synchronization status section of the Delete D (before modification) record and the Add A (after modification) record, the synchronization subsystem 210 monitors constantly or for a fixed period of time to delete record (2) in Figure 8 from the synchronization table 33. Then, after a fixed period of time has passed, the synchronization subsystem 210 deletes record (2) in Figure 8, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

<Downstream deletion processing>
FIG. 9 shows how data in the synchronization table 33 changes during downstream deletion processing.
When the main system 200 deletes a journal entry that was previously added, the target system 300 also needs to delete the journal entry that was previously imported from the synchronization table 33. For example, when the main system 200 deletes a journal entry with voucher number "00012", a record corresponding to the deleted journal entry is written in the synchronization table 33.

When the main system 200 deletes a journal entry, it creates journal entry data 20 corresponding to the deleted journal entry. The reason for creating journal entry data 20 in this way is that the record of the pre-correction journal entry, which is a journal entry added in the past, has been imported into the target system 300 and therefore does not exist in the synchronization table 33. Therefore, in order to delete the record of the pre-correction journal entry imported into the target system 300, the record of the deleted journal entry is stored in the synchronization table 33.

The conversion unit 30 refers to the conversion table 31 and converts the debit items, credit items, and consumption tax categories of the journal data 20. The conversion unit 30 then writes the unimported "1" into the synchronization status category corresponding to the journal entry for deletion D.

Record (1) in Figure 9 represents the contents of the record stored in synchronization table 33 corresponding to the journal entry to be deleted. "Delete D" is stored in the category of record (1) in Figure 9 stored in synchronization table 33. The target system 300 deletes the previously imported record using the Delete D record. In this way, the journal entry in the target system 300 is updated, and the journal entries in the main system 200 and target system 300 are synchronized.

In addition, the target system 300 holds the voucher number "00012" assigned by the main system 200 in order to synchronize journal entry deletions and modifications with the main system 200. The target system 300 then notifies the standby unit 34 of the voucher number "0085" for the journal entry for deletion D and the updated status.

The waiting unit 34 writes the voucher number "0085" notified from the target system 300 into the target system 300 voucher number of the record for deletion D stored in the synchronization table 33. The waiting unit 34 also writes "2" into the synchronization status category of the record for deletion D stored in the synchronization table 33, indicating that the journal entry in the target system 300 has been updated.

The target system 300 retrieves the record of deletion D read from the synchronization table 33 via the waiting unit 34. Then, the journal entry preparation unit 50 of the target system 300 deletes the voucher with the voucher number "00012" of the main system 200 from the journal entries managed by the target system 300 based on the record of deletion D.
Records with "Delete D" stored in the category are not necessary for synchronizing journal entries between the main system 200 and the target system 300. However, these records with Delete D are used by the main system 200 and the target system 300 to mutually confirm the contents of the journal entries currently being managed.

In other words, after the updated "2" is written in the synchronization status section of the record for deletion D, the synchronization subsystem 210 monitors the record for deletion D constantly or for a fixed period of time in order to delete record (2) in Figure 9 from the synchronization table 33. Then, after the fixed period has passed, the synchronization subsystem 210 deletes record (2) in Figure 9, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

Upstream Processing
Next, upstream processing will be described in the order of addition, undo addition, modification, undo modification, deletion, and undo deletion with reference to FIGS.

<Upstream addition process>
10 shows how data in the synchronization table 33 changes during upstream addition processing. During upstream addition processing, a finalized journal entry is added in the main system 200 to the journal entry added in the target system 300, and the finalized journal entry is reflected in the target system 300.

When the target system 300 creates a new journal entry for voucher number "0086," the transmission unit 52 of the target system 300 transmits journal entry data 51 corresponding to the added journal entry to the synchronization subsystem 210 via API integration. This journal entry data 51 passes through the reception unit 35 of the synchronization subsystem 210, is inversely converted by the inverse conversion unit 36, and is stored in the synchronization table 33.

Record (1) in Figure 10 represents the contents of the voucher with voucher number "0086" assigned to a new journal entry created by the target system 300. The synchronization subsystem 210 then outputs the journal entry data 51 received from the target system 300 to the inverse conversion unit 36. The inverse conversion unit 36 inversely converts the journal entry data 51 by referencing the inverse conversion table 37, and stores the inversely converted data in the synchronization table 33 as unconfirmed journal entry data 21.

At this time, the inverse conversion unit 36 automatically assigns and adds "00013" to the voucher number field of the main system 200. When the inverse conversion unit 36 writes the unconfirmed journal data 21 to the synchronization table 33, it assigns a voucher number from the main system 200 in this way to prevent duplicate data from existing in the main system 200. For this reason, the inverse conversion unit 36 may inquire of the main system 200 about available numbers that can be assigned. Record (1) in Figure 10 is imported into the main system 200 as unconfirmed journal data 21 whose synchronization status classification is "unimported" and whose confirmation status is "unconfirmed."

The automatic journalizing unit 22 of the main system 200 reads the unconfirmed journalizing data 21 from the synchronization table 33 and performs automatic journalizing.
The confirmation processing unit 23 displays the unconfirmed journal entry data 21 automatically journalized by the automatic journalizing unit 22 and accepts confirmation processing by the user. For this purpose, the automatic journalizing unit 22 performs automatic journalizing from the unconfirmed journal entry and causes candidate journal entries to be displayed on the confirmation processing unit 23. The user then confirms the correct journal entry from the candidate journal entries and confirms and updates the unconfirmed journal entry data 21 with the correct journal entry.

Record (2) in Figure 10 shows how the summary in the main system 200 and target system 300 has been corrected from "Stationery" to "Stationery Notebook." Then, the unconfirmed journal entry data 21, with the journal entry confirmed, is output to the synchronization subsystem 210 as journal entry data 24.

The conversion unit 30 of the synchronization subsystem 210 converts the journal data 24 received from the main system 200 into journal data 38, and then writes the journal data 38 to the synchronization table 33. At this time, the conversion unit 30 writes "2" (not yet imported) into the synchronization status category of the synchronization table 33, and sets the confirmation status column to "confirmed."

The journal entry creation unit 50 of the target system 300 queries the synchronization subsystem 210 to see if there are any records whose synchronization status category is "unacquired" and whose confirmation status is "confirmed." When the waiting unit 34 receives a query from the journal entry creation unit 50, it reads records from the synchronization table 33 whose synchronization status category is "unacquired" and whose confirmation status is "confirmed," and sends them to the target system 300.

The journal entry creation unit 50 imports records whose synchronization status category is "unimported" and whose confirmation status is "confirmed" as confirmed journal entries and performs journal entry processing in the target system 300. The journal entry creation unit 50 then deletes the previous voucher with voucher number "0086" and adds a new voucher with voucher number "0087."

The journal entry creation unit 50 also rewrites the target system 300's voucher number "0086" in the synchronization table 33 via the standby unit 34 to the added voucher number "0087" and writes the updated "2" in the synchronization status category. Record (3) in Figure 10 shows the rewrite to the added voucher number "0087" by the target system 300.

After the updated "2" is written in the synchronization status section of the record for addition A, the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (3) in Figure 10 from the synchronization table 33. Then, after a certain period of time has passed, the synchronization subsystem 210 deletes record (3) in Figure 10, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

<Upstream Addition Cancellation Process>
11 shows how data in the synchronization table 33 changes during the process of canceling an upstream addition. During the process of canceling an upstream addition, the main system 200 cancels a journal entry added by the target system 300, thereby canceling the journal entry added by the target system 300.

When the target system 300 adds a new journal entry for voucher number "0086," the transmission unit 52 of the target system 300 transmits journal entry data 51 corresponding to the added journal entry to the synchronization subsystem 210 via API integration. This journal entry data 51 passes through the reception unit 35 of the synchronization subsystem 210, is inversely converted by the inverse conversion unit 36, and is stored in the synchronization table 33.

Record (1) in Figure 11 represents the contents of the voucher with voucher number "0086" assigned to a new journal entry added by the target system 300. Record (1) in Figure 11 has the same contents as record (1) in Figure 10. This record is imported into the main system 200 as unconfirmed journal entry data 21, whose confirmation status is "unconfirmed."

The automatic journalizing unit 22 of the main system 200 reads the unconfirmed journalizing data 21 from the synchronization table 33, performs automatic journalizing, and displays journalizing candidates in the confirmation processing unit 23. Let's assume that the user cancels the addition of a journalizing entry by the target system 300 through the confirmation processing unit 23.

The conversion unit 30 of the synchronization subsystem 210 converts the journal data 24 received from the main system 200 into journal data 38, and then writes the journal data 38 to the synchronization table 33. At this time, the conversion unit 30 sets the classification of the journal data 38 to "deleted," writes "1" (not yet imported) in the synchronization status classification, and sets the confirmation status column to "confirmed." Record (2) in Figure 11 shows how the classification has changed from "addition A" to "deletion D" (deletion) when the user cancels the addition of a journal entry.

The journal entry creation unit 50 of the target system 300 queries the synchronization subsystem 210 to see if there are any records whose synchronization status category is "unacquired" and whose confirmation status is "confirmed." When the waiting unit 34 receives a query from the journal entry creation unit 50, it reads records from the synchronization table 33 whose synchronization status category is "unacquired" and whose confirmation status is "confirmed," and sends them to the target system 300.

The journal entry creation unit 50 imports records whose synchronization status category is "unimported" and whose confirmation status is "confirmed" as confirmed journal entries and performs journal entry processing in the target system 300. The journal entry creation unit 50 then deletes the added voucher with voucher number "0086." The journal entry creation unit 50 also writes the updated "2" to the synchronization status category of the record in the synchronization table 33 via the standby unit 34. Record (3) in Figure 11 shows how the synchronization status category has been rewritten to the updated "2."

After the updated "2" is written in the synchronization status section of the record for deletion D, the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (3) in Figure 11 from the synchronization table 33. Then, after a certain period of time has passed, the synchronization subsystem 210 deletes record (3) in Figure 11, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

Handling Upstream Modifications
FIG. 12 shows how the data in the synchronization table 33 changes during upstream modification processing.
In the upstream correction process, the target system 300 corrects the journal entries previously added, and the main system 200 performs a finalized journal entry to correct the journal entries, and the finalized journal entry is reflected in the target system 300.

Let's assume that the target system 300 has previously added, confirmed by the main system 200, and imported voucher number "0087," and has amended the debit item from "consumables expenses" to "office supplies expenses." The transmission unit 52 of the target system 300 transmits journal entry data 51 corresponding to the amended journal entry to the synchronization subsystem 210 via API integration.

This journal data 51 passes through the receiving unit 35 of the synchronization subsystem 210, is inversely converted by the inverse conversion unit 36, and is stored in the synchronization table 33. Here, the inverse conversion unit 36 writes the unimported "1" into the synchronization status category corresponding to the journal entries of deletion D (before correction) and addition A (after correction). The inverse conversion unit 36 also adds the voucher number "00013" assigned by the main system 200. This record is imported into the main system 200 as unconfirmed journal data 21 whose confirmation status is "unconfirmed."

Record (1) in Figure 12 represents the contents of synchronization table 33, which lists records for deletion D (before correction) and addition A (after correction). Record (1) in Figure 12 stored in synchronization table 33 consists of a record with "deletion D (before correction)" stored in the category and a record with "addition A (after correction)" stored in the category. In the record corresponding to the journal entry for addition A (after correction), the debit item has changed from "consumable expenses" to "office supplies expenses," as highlighted.

The automatic journalizing unit 22 of the main system 200 reads the unconfirmed journalizing data 21 from the synchronization table 33, performs automatic journalizing, and displays journalizing candidates in the confirmation processing unit 23. The user approves the journalizing corrections made by the target system 300 through the confirmation processing unit 23 and confirms the journalizing. The journalizing data 24 whose journalizing has been confirmed by the confirmation processing unit 23 is sent to the synchronization subsystem 210.

The conversion unit 30 of the synchronization subsystem 210 converts the journal data 24 received from the main system 200 into journal data 38, and then writes the journal data 38 to the synchronization table 33. At this time, the conversion unit 30 writes "2" (not yet imported) into the synchronization status category of the synchronization table 33, and sets the confirmation status column to "confirmed." Record (2) in Figure 12 shows how the user has confirmed the revised journal entry.

The journal entry creation unit 50 of the target system 300 queries the synchronization subsystem 210 to see if there are any records whose synchronization status category is "unacquired" and whose confirmation status is "confirmed." When the waiting unit 34 receives a query from the journal entry creation unit 50, it reads records from the synchronization table 33 whose synchronization status category is "unacquired" and whose confirmation status is "confirmed," and sends them to the target system 300.

The journal entry creation unit 50 imports records whose synchronization status category is "unimported" and whose confirmation status is "confirmed" as confirmed journal entries and performs journal entry processing in the target system 300. The journal entry creation unit 50 then deletes the pre-correction voucher with voucher number "0087." The journal entry creation unit 50 also writes the updated "2" to the synchronization status category of the record in the synchronization table 33 via the standby unit 34.

Furthermore, the journal entry preparation unit 50 updates the journal entry in the target system 300 based on the record imported from the synchronization subsystem 210 after correcting the debit item. The journal entry preparation unit 50 then retains the voucher number "00013" added by the main system 200 in order to synchronize the correction or deletion of the journal entry in the target system 300 with the journal entry in the main system 200. The journal entry preparation unit 50 also writes "0088" to the voucher number of the target system 300 in the record of Addition A in the synchronization table 33 via the standby unit 34. Record (3) in Figure 12 shows how the synchronization status classification has been rewritten to "2", indicating that the synchronization status has been updated.

The journal entry creation unit 50 then deletes the record of the voucher with voucher number "00013" from the main system 200. The record with "Deletion D (before correction)" stored in the category is not necessary for synchronizing journal entries between the main system 200 and the target system 300. However, it is used by the main system 200 and the target system 300 to mutually confirm the contents of the journal entries currently being managed.

After the updated "2" is written in the synchronization status section of the record for deletion D, the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (3) in Figure 12 from the synchronization table 33. Then, after a certain period of time has passed, the synchronization subsystem 210 deletes record (3) in Figure 12, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

Undoing Upstream Modifications
FIG. 13 shows how the data in the synchronization table 33 changes during the process of canceling an upstream modification.
In the upstream correction cancellation process, although the target system 300 has made corrections to journal entries previously added, the main system 200 performs a finalized journal entry to cancel the journal entry corrections, and the finalized journal entry is reflected in the target system 300.

Record (1) in Figure 13 has the same content as record (1) in Figure 12, so a detailed explanation will be omitted. In other words, let's assume that the debit item for voucher number "0087," which was previously added by the target system 300, confirmed by the main system 200, and imported, has been revised from "Consumables Expenses" to "Office Supplies Expenses."

The automatic journalizing unit 22 of the main system 200 reads the unconfirmed journalizing data 21 from the synchronization table 33, performs automatic journalizing, and displays journalizing candidates in the confirmation processing unit 23. The user cancels the journalizing corrections made by the target system 300 through the confirmation processing unit 23 and confirms the journalizing. The journalizing data 24 whose journalizing has been confirmed by the confirmation processing unit 23 is sent to the synchronization subsystem 210.

When the conversion unit 30 of the synchronization subsystem 210 converts the journal data 24 received from the main system 200 into journal data 38, it writes the journal data 38 to the synchronization table 33. At this time, the conversion unit 30 writes "2" (unincorporated) to the synchronization status category of the synchronization table 33 and sets the confirmation status column to "confirmed." Therefore, as shown in record (1) in Figure 13, the record whose category was "Deleted D (before modification)" changes to "Added A (before modification)," the synchronization status category changes to "1" (unincorporated), and the confirmation status changes to "confirmed." Also, the record whose category was "Added A (after modification)" changes to "Deleted D (before modification)," the synchronization status category changes to "2" (updated), and the confirmation status changes to "confirmed."

The journal entry creation unit 50 of the target system 300 queries the synchronization subsystem 210 to see if there are any records whose synchronization status category is "unacquired" and whose confirmation status is "confirmed." When the waiting unit 34 receives a query from the journal entry creation unit 50, it reads records from the synchronization table 33 whose synchronization status category is "unacquired" and whose confirmation status is "confirmed," and sends them to the target system 300.

The journal entry creation unit 50 imports the record "Addition A (before correction)" whose synchronization status category is "unimported" and whose confirmation status is "confirmed" as a confirmed journal entry and performs journal entry processing in the target system 300. The journal entry creation unit 50 then deletes the corrected voucher with voucher number "0087." The journal entry creation unit 50 also writes the updated "2" to the synchronization status category of the record in the synchronization table 33 via the standby unit 34.

The journal entry creation unit 50 also retains the voucher number "00013" added by the main system 200 in order to synchronize the modification or deletion of journal entries in the target system 300 with the journal entries in the main system 200. The journal entry creation unit 50 also writes "0088" to the target system 300 voucher number and writes the updated "2" to the synchronization status category in the "Addition A (before modification)" record in the synchronization table 33 via the standby unit 34. Record (3) in Figure 13 shows how the synchronization status category has been rewritten to the updated "2". The journal entry creation unit 50 then deletes the record of the voucher with the voucher number "00013" in the main system 200.

After the updated "2" is written in the synchronization status section of the record "Addition A (before modification)," the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (3) in Figure 13 from the synchronization table 33. After a certain period of time has passed, the synchronization subsystem 210 deletes record (3) in Figure 13, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

Upstream deletion processing
FIG. 14 shows how the data in the synchronization table 33 changes during upstream deletion processing.
In the upstream deletion process, the target system 300 deletes previously added journal entries, and when the main system 200 confirms the deletion of the journal entries, the confirmed journal entries are reflected in the target system 300 .

When the target system 300 deletes a journal entry that was previously added, the main system 200 must also delete the journal entry that was previously imported from the synchronization table 33. For example, when the target system 300 deletes the journal entry for voucher number "0088," the transmission unit 52 of the target system 300 sends the journal entry data 51 corresponding to the deleted journal entry to the synchronization subsystem 210 via API integration.

This journal data 51 passes through the receiving unit 35 of the synchronization subsystem 210, is inversely converted by the inverse conversion unit 36, and is stored in the synchronization table 33. Here, the inverse conversion unit 36 writes an unimported "1" into the synchronization status category of the record corresponding to the journal entry of deletion D. The inverse conversion unit 36 also adds the voucher number "00013" assigned by the main system 200. Record (1) in Figure 14 represents the contents of the synchronization table 33, which stores a record whose category is "deletion D," whose synchronization status category has an unimported "1" written, and whose confirmation status is "unconfirmed." This record is imported into the main system 200 as unconfirmed journal data 21 whose confirmation status is "unconfirmed."

The automatic journalizing unit 22 of the main system 200 reads the unconfirmed journalizing data 21 from the synchronization table 33, performs automatic journalizing, and displays journalizing candidates in the confirmation processing unit 23. The user confirms the deletion of the journalizing by the target system 300 through the confirmation processing unit 23 and confirms the journalizing. The journalizing data 24 whose journalizing has been confirmed by the confirmation processing unit 23 is sent to the synchronization subsystem 210.

The conversion unit 30 of the synchronization subsystem 210 converts the journal data 24 received from the main system 200 into journal data 38, and then writes the journal data 38 to the synchronization table 33. At this time, the conversion unit 30 writes "2" (not yet imported) into the synchronization status category of the synchronization table 33, as shown in record (2) in Figure 14, and sets the confirmation status to "confirmed."

The journal entry creation unit 50 of the target system 300 queries the synchronization subsystem 210 to see if there are any records whose synchronization status category is "unacquired" and whose confirmation status is "confirmed." When the waiting unit 34 receives a query from the journal entry creation unit 50, it reads records from the synchronization table 33 whose synchronization status category is "unacquired" and whose confirmation status is "confirmed," and sends them to the target system 300.

The journal entry creation unit 50 imports the record with "Deleted D" as a confirmed journal entry, with a synchronization status category of "Not imported" and a confirmation status of "Confirmed," and performs journal entry processing in the target system 300. Although the journal entry with voucher number "0088" has already been deleted in the target system 300, the journal entry creation unit 50 confirms that there is no voucher in the target system 300 with voucher number "00013" in the main system 200. The journal entry creation unit 50 then writes the updated "2" to the synchronization status category of the record in the synchronization table 33 via the standby unit 34.

The "Delete D" record is not necessary for synchronizing journal entries between the main system 200 and the target system 300. However, it is used by the main system 200 and the target system 300 to mutually confirm the contents of the journal entries currently being managed.

After the updated "2" is written in the synchronization status section of the record for deletion D, the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (3) in Figure 14 from the synchronization table 33. Then, after a certain period of time has passed, the synchronization subsystem 210 deletes record (3) in Figure 14, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

<Upstream deletion cancellation process>
FIG. 15 shows how the data in the synchronization table 33 changes during the process of canceling an upstream deletion.
In the upstream deletion cancellation process, the target system 300 deletes the journal entry, and the main system 200 performs a final journal entry to cancel the deletion of the journal entry. The final journal entry is also reflected in the target system 300.

When the target system 300 deletes the journal entry with voucher number "0088", the transmission unit 52 of the target system 300 transmits the journal entry data 51 corresponding to the deleted journal entry to the synchronization subsystem 210 via API integration.

This journal data 51 passes through the receiving unit 35 of the synchronization subsystem 210, is inversely converted by the inverse conversion unit 36, and is stored in the synchronization table 33. Here, the inverse conversion unit 36 writes the unimported "1" into the synchronization status category of the record corresponding to the journal entry of deletion D. The inverse conversion unit 36 also adds the slip number "00013" assigned by the main system 200.
15 shows the contents of the synchronization table 33, which stores a record whose classification is "Delete D," whose synchronization status classification is set to "1" (not yet imported), and whose confirmation status is "Unconfirmed." This record is imported into the main system 200 as unconfirmed journal data 21 whose confirmation status is "Unconfirmed."

The automatic journalizing unit 22 of the main system 200 reads the unconfirmed journalizing data 21 from the synchronization table 33, performs automatic journalizing, and displays journalizing candidates in the confirmation processing unit 23. The user confirms through the confirmation processing unit 23 whether or not to delete the journalizing made by the target system 300, and if the journalizing does not need to be deleted, cancels the deletion of the journalizing and confirms the journalizing. The journalizing data 24 whose journalizing has been confirmed by the confirmation processing unit 23 is sent to the synchronization subsystem 210.

The conversion unit 30 of the synchronization subsystem 210 converts the journal data 24 received from the main system 200 into journal data 38, and then writes the journal data 38 to the synchronization table 33. At this time, the conversion unit 30 sets the classification of the synchronization table 33 to "Added A," writes "2" (not yet incorporated) into the synchronization status classification, and sets the confirmation status to "Confirmed," as shown in record (2) in Figure 15.

The journal entry creation unit 50 of the target system 300 queries the synchronization subsystem 210 to see if there are any records whose synchronization status category is "unacquired" and whose confirmation status is "confirmed." When the waiting unit 34 receives a query from the journal entry creation unit 50, it reads records from the synchronization table 33 whose synchronization status category is "unacquired" and whose confirmation status is "confirmed," and sends them to the target system 300.

The journal entry creation unit 50 imports the record for "Addition A," whose synchronization status category is "Not imported" and whose confirmation status is "Confirmed," as a confirmed journal entry and performs journal entry processing in the target system 300. Although the journal entry for voucher number "0088" has already been deleted in the target system 300, the journal entry creation unit 50 confirms that there is no voucher in the target system 300 with voucher number "00013" in the main system 200. The journal entry creation unit 50 then writes the updated "2" to the synchronization status category of the record in the synchronization table 33 via the standby unit 34.

After the updated "2" is written in the synchronization status section of the record for addition A, the synchronization subsystem 210 monitors constantly or for a certain period of time to delete record (3) in Figure 15 from the synchronization table 33. Then, after a certain period of time has passed, the synchronization subsystem 210 deletes record (3) in Figure 15, in which the updated "2" has been written in the synchronization status section, in order to secure space in the synchronization table 33.

[Screen display example]
Next, examples of screen displays on the main system 200 and the target system 300 will be described with reference to FIGS.

<Import screen for downstream addition, modification, and deletion processing>
16 shows an example of the import screen W1 displayed on the target system 300 during downstream addition, modification, and deletion processing. In FIG. 16, the import of journal entries created in the main system 200 by the target system 300 is called "import."

The screen display example (1) in Figure 16 is a screen displayed on the display device of the target system 300 during downstream addition processing. When the additional journal entry shown in record (1) of the downstream addition processing in Figure 7 is performed in the main system 200, the target system 300 imports the journal entry via the synchronization subsystem 210.

At this time, the target system 300 displays the screen shown in screen display example (1) in Figure 16, with the target system 300 voucher number "0084" added, which corresponds to record (2) in Figure 7. The accounting firm employee operating the target system 300 confirms that there has been one additional journal entry from the main system 200 and checks the details of the added journal entry. When the accounting firm employee then presses the update button, the additional journal entry from the main system 200 is imported into the target system 300.

Screen display example (2) in Figure 16 is a screen displayed on the display device of the target system 300 during downstream correction processing. When the main system 200 journalizes the correction shown in Addition A (after correction) of record (1) of downstream correction processing in Figure 8, the target system 300 imports the journalization via the synchronization subsystem 210. At this time, the target system 300 displays a screen shown in screen display example (2) in Figure 16, which corresponds to record (2) in Figure 8 and includes the amounts before and after correction in the main system 200 and target system 300.
The accounting firm employee operating the target system 300 confirms that there is one corrective journal entry from the main system 200 and checks the content of the corrected journal entry. When the accounting firm employee then presses the update button, the corrective journal entry from the main system 200 is imported into the target system 300.

Screen display example (3) in Figure 16 is a screen displayed on the display device of the target system 300 during downstream deletion processing. When the deletion journal entry for the content shown in Addition A (after deletion) of record (1) of the downstream deletion processing in Figure 9 is performed in the main system 200, the journal entry is imported into the target system 300 via the synchronization subsystem 210.

At this time, the target system 300 displays the screen shown in screen display example (3) in Figure 16, which corresponds to record (2) in Figure 9 and includes the amounts before and after deletion in the main system 200 and target system 300. The accounting firm employee operating the target system 300 confirms that there has been one deletion journal entry in the main system 200 and checks the details of the deleted journal entry. When the accounting firm employee then presses the update button, the deletion journal entry from the main system 200 is imported into the target system 300.

<Export screen for adding, modifying, and deleting upstream processes>
FIG. 17 shows an example of the export screen W2 displayed on the target system 300 during upstream addition, modification, and deletion processing.
17, the process of sending journal entries created by the target system 300 to the main system 200 is called "export." The export screen W2 displays not only the journal entries sent by the target system 300 to the main system 200, but also the journal entries confirmed in the main system 200. The export screen W2 shown in FIG. 17 is displayed on the target system 300 when upstream in the data linkage system 100 has been successfully completed.

Screen display example (1) in Figure 17 is a screen displayed on the display device of the target system 300 during upstream addition processing. When the additional journal entry shown in record (1) of the upstream addition processing in Figure 10 is performed in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. After that, when the target system 300 receives the final journal entry from the main system 200, the export screen W2 of the target system 300 shown in screen display example (1) is displayed.

This export screen W2 displays side by side the contents of the journal entry sent by the target system 300 to the main system 200, corresponding to record (1) in Figure 10, and the contents of the final journal entry received by the target system 300 from the main system 200, corresponding to record (3) in Figure 10. The accounting firm employee operating the target system 300 confirms that there has been one additional journal entry from the main system 200 and checks the contents of the added journal entry. When the accounting firm employee then presses the update button, the additional journal entry from the main system 200 is imported into the target system 300.

Screen display example (2) in Figure 17 is a screen displayed on the display device of the target system 300 during upstream correction processing. When the correction journal entry for the content shown in Addition A (after correction) of record (1) of the upstream correction processing in Figure 12 is made in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. After that, when the target system 300 receives the final journal entry from the main system 200, the export screen W2 of the target system 300 shown in screen display example (2) is displayed.

This export screen W2 displays side by side the contents of the journal entry before and after correction sent by the target system 300 to the main system 200, corresponding to record (1) in Figure 12, and the contents of the revised journal entry, which is the final journal entry received by the target system 300 from the main system 200, corresponding to record (3) in Figure 12. The accounting firm employee operating the target system 300 confirms that there has been one revised journal entry from the main system 200 and checks the contents of the revised journal entry. Then, when the accounting firm employee presses the update button, the revised journal entry from the main system 200 is imported into the target system 300.

Screen display example (3) in Figure 17 is a screen displayed on the display device of the target system 300 during upstream deletion processing. When the deletion journal entry for the content shown in record (1) of the upstream deletion processing in Figure 14 is performed in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. After that, when the target system 300 receives the final journal entry from the main system 200, the export screen W2 of the target system 300 shown in screen display example (3) is displayed.

This export screen W2 displays side-by-side the contents of the deletion journal entry sent by the target system 300 to the main system 200, corresponding to record (1) in Figure 14, and the contents of the deletion, which is the confirmed journal entry received by the target system 300 from the main system 200, corresponding to record (3) in Figure 14. Note that because the journal entry was deleted in the main system 200, the "Received Content" row in screen display example (3) displays no content other than the status item. The accounting firm employee operating the target system 300 confirms that there is one deletion journal entry from the main system 200 and checks the contents of the deleted journal entry. Then, when the accounting firm employee presses the update button, the deletion journal entry from the main system 200 is imported into the target system 300.

<Export screen for canceling upstream addition, modification, and deletion>
FIG. 18 shows an example of the export screen W3 displayed on the target system 300 during the process of canceling an upstream addition, modification, or deletion.
18, the process of transmitting journal entries created by the target system 300 to the main system 200 is called "export." The export screen W3 displays not only the journal entries transmitted by the target system 300 to the main system 200, but also the journal entries confirmed in the main system 200. The export screen W3 shown in FIG. 18 is displayed on the target system 300 when the upstream transmission process from the target system 300 to the main system 200 in the data linkage system 100 has been successfully completed and the main system 200 has canceled the journal entries.

Screen display example (1) in Figure 18 is a screen displayed on the display device of the target system 300 during the upstream addition cancellation process. When the additional journal entry shown in record (1) of the upstream addition cancellation process in Figure 11 is performed in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. After that, when the target system 300 receives the confirmed journal entry from the main system 200, the export screen W3 of the target system 300 shown in screen display example (1) is displayed.

This export screen W3 displays side by side the contents of the additional journal entry sent by the target system 300 to the main system 200, corresponding to record (1) in Figure 11, and the contents of the cancelled additional entry, which is a confirmed journal entry received by the target system 300 from the main system 200, corresponding to record (3) in Figure 11. The accounting firm employee operating the target system 300 confirms that there has been one journal entry for cancelled additional entry from the main system 200 and checks the contents of the journal entry for cancelled additional entry. When the accounting firm employee then presses the update button, the journal entry for cancelled additional entry from the main system 200 is imported into the target system 300.

Screen display example (2) in Figure 18 is a screen displayed on the display device of the target system 300 during the upstream correction cancellation process. When the target system 300 makes a journal entry for the correction shown in Addition A (after correction) of record (1) of the upstream correction cancellation process in Figure 13, the main system 200 imports the journal entry via the synchronization subsystem 210. After that, when the target system 300 receives the final journal entry from the main system 200, the export screen W3 of the target system 300 shown in screen display example (2) is displayed.

This export screen W3 displays side by side the contents of the journal entry before and after correction sent by the target system 300 to the main system 200, corresponding to record (1) in Figure 13, and the contents of the correction cancellation, which is the confirmed journal entry received by the target system 300 from the main system 200, corresponding to record (3) in Figure 13. The accounting firm employee operating the target system 300 confirms that there has been one correction cancellation journal entry from the main system 200 and verifies the correction cancellation journal entry. When the accounting firm employee then presses the update button, the correction cancellation journal entry from the main system 200 is imported into the target system 300.

Screen display example (3) in Figure 18 is a screen displayed on the display device of the target system 300 during the upstream deletion cancellation process. When the deletion journal entry shown in record (1) of the upstream deletion cancellation process in Figure 15 is performed in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. After that, when the target system 300 receives the confirmed journal entry from the main system 200, the export screen W3 of the target system 300 shown in screen display example (3) is displayed.

This export screen W3 displays side by side the contents of the deletion journal entry sent by the target system 300 to the main system 200, corresponding to record (1) in Figure 15, and the contents of the deletion cancellation, which is a confirmed journal entry received by the target system 300 from the main system 200, corresponding to record (3) in Figure 15. The accounting firm employee operating the target system 300 confirms that there is one deletion journal entry from the main system 200 and checks the contents of the deleted journal entry. Then, when the accounting firm employee presses the update button, the deletion journal entry from the main system 200 is imported into the target system 300.

<Import screen for adding, modifying, and deleting upstream>
19 and 20 are diagrams showing examples of the import screen W4 displayed on the main system 200 during upstream addition, modification, and deletion processes. In FIGS. 19 and 20, the process in which the main system 200 receives journal entries created by the target system 300 is called "import." The import screen W4 displays not only the journal entries received by the main system 200 from the target system 300, but also the journal entries modified by the main system 200 and sent to the target system 300. The import screen W4 shown in FIGS. 19 and 20 is displayed on the main system 200 when the main system 200, in the upstream part of the data linkage system 100, receives journal entries from the target system 300 and confirms or cancels the journal entries.

The user of the main system 200 needs to confirm how the journal data sent by the target system 300 has been converted by the synchronization subsystem 210. The user also needs to confirm how the journal data sent by the main system 200 is reverse-converted by the synchronization subsystem 210. Therefore, the main system 200 can import from the synchronization subsystem 210 the contents of the journal data 51 before and after reverse conversion by the reverse conversion unit 36, and the contents of the journal data 24 after conversion by the conversion unit 30.

Screen display example (1) in Figure 19 is a screen displayed on the display device of the main system 200 during the upstream addition process. When the additional journal entry shown in record (1) of the upstream addition process in Figure 10 is performed in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. Thereafter, the import screen W4 of the main system 200 shown in screen display example (1) is displayed on the main system 200.

When the receiving unit 35 receives journal data 51 including additional content, it is in an unconfirmed state where final journalization has not yet been performed by the main system 200, so the status field for "Received content (reverse converted to main)" displays "Unconfirmed." Furthermore, when final journalization is performed by the main system 200, records for "Confirmed content (main)" and "Content to be sent (converted to target)" are created. At this time, the status field for the record for "Confirmed content (main)" displays "Confirmed," and the status field for the record for "Content to be sent (converted to target)" displays "Unprocessed" (not shown).

The import screen W4 shown in Figure 19 displays the contents of the additional journal entry received by the main system 200 from the target system 300, corresponding to record (1) in Figure 10, and the contents of the journal entry to be sent by the main system 200 to the target system 300, corresponding to record (3) in Figure 10, side by side. At this point, the main system 200 voucher number in the "Received contents (from target)" row and the target system 300 voucher numbers in the "Received contents (reverse converted to main)," "Confirmed contents (main)," and "Content to be sent (converted to target)" rows are blank. When the user operating the main system 200 confirms that one additional journal entry has been received from the target system 300, they can confirm or cancel the additional journal entry. Then, when the user presses the update button, the processed data is deleted.

Screen display example (2) in Figure 20 is a screen displayed on the display device of the main system 200 during upstream correction processing. When the target system 300 journalizes the correction of the content shown in Addition A (after correction) of record (1) of the upstream correction processing in Figure 12, the main system 200 imports the journalization via the synchronization subsystem 210. Thereafter, the main system 200 import screen W4 shown in screen display example (2) is displayed on the main system 200. When the receiving unit 35 receives journalization data 51 including the correction content, records of "Received content before correction (from target)," "Received content before correction (reverse converted to main)," "Received content after correction (from target)," and "Received content after correction (reverse converted to main)" are created. When the receiving unit 35 receives journalization data 51 including the correction content, it is in an unconfirmed state because the main system 200 has not yet performed a final journalization, and the status column of the record for "Received content after correction (reverse converted to main)" displays "unconfirmed."

Furthermore, when the main system 200 performs the final journal entry, records of "Finalized corrections (main)" and "Contents to be sent (converted to target)" are created. At this time, the status field of the record of "Finalized corrections (main)" displays "Final," and the status field of the record of "Contents to be sent (converted to target)" displays "Unprocessed." The standby unit 34 then imports the journal entry data 38 for which the final journal entry has been performed, and the journal entry is performed by the journal entry creation unit 50 of the target system 300.

The import screen W4 displays side by side the contents of the journal entry before correction that the main system 200 received from the target system 300, which corresponds to record (1) in Figure 12, the contents of the journal entry that the synchronization subsystem 210 reverse-converted from the contents of this journal entry before correction, and the contents of the revised journal entry that the main system 200 will send to the target system 300, which corresponds to record (3) in Figure 12.
At this point, the status fields for the records "Received content before correction (from target),""Received content before correction (reverse converted to main)," and "Received content after correction (from target)" are blank, and the status field for the record "Received content after correction (reverse converted to main)" displays "Unconfirmed." Also, the slip number for the target system 300 in the records "Confirmed correction content (in main)" and "Content to send (converted to target)" is blank. When the user operating the main system 200 confirms that there is one journal entry for correction from the target system 300, they can confirm or cancel the corrected journal entry. Then, when the user presses the update button, the processed data is deleted.

Screen display example (3) in Figure 20 is a screen displayed on the display device of the main system 200 during upstream deletion processing. When the deletion journal entry for the content shown in record (1) of the upstream deletion processing in Figure 14 is performed in the target system 300, the main system 200 imports the journal entry via the synchronization subsystem 210. Thereafter, the main system 200 import screen W4 shown in screen display example (3) is displayed on the main system 200. When the receiving unit 35 receives journal entry data 51 including the deletion content, the main system 200 has not yet performed a final journal entry, so the status is unconfirmed; once a final journal entry is performed, the status changes to normal.

Before the final journal entry is made, the status field for "Received content (from target)" is blank. Furthermore, once the main system 200 has made the final journal entry, a record for "Content to be sent (reverse converted to main)" is created. At this time, the status field for the "Content to be sent" record displays "Unprocessed." After that, the standby unit 34 imports the journal entry data 38 for which the final journal entry has been made, and the journal entry is made by the journal entry creation unit 50 of the target system 300, and the status field for "Content to be sent (reverse converted to main)" displays "Normal."

The import screen W4 displays side-by-side the contents of the deletion journal entry received by the main system 200 from the target system 300, corresponding to record (1) in Figure 14, and the contents of the confirmed deletion journal entry received by the main system 200 from the target system 300, corresponding to record (3) in Figure 14. Note that because the journal entry was deleted in the target system 300, the "Received Content (from Target)" row in screen display example (3) displays no content other than the status item. When the user operating the main system 200 confirms that there is one deletion journal entry from the target system 300, they can confirm or cancel the deleted journal entry. Then, when the user presses the update button, the processed data is deleted.

<Import screen for canceling upstream addition, modification, and deletion>
21 and 22 are diagrams showing an example of the import screen W5 displayed on the target system 300 during the process of canceling upstream additions, modifications, and deletions. In FIGS. 21 and 22, the process in which the main system 200 receives journal entries created by the target system 300 is called "import." The import screen W5 displays not only the journal entries received by the main system 200 from the target system 300, but also the journal entries modified by the main system 200 and sent to the target system 300. The import screen W5 shown in FIGS. 21 and 22 is displayed on the main system 200 when the main system 200 in the upstream part of the data linkage system 100 receives journal entries from the target system 300 and confirms or cancels the journal entries.

Screen display example (1) in Figure 21 is a screen displayed on the display device of the main system 200 during the upstream addition cancellation process. When the additional journal entry shown in record (1) of the upstream addition cancellation process in Figure 11 is performed in the target system 300, the journal entry is imported into the main system 200 via the synchronization subsystem 210. After that, the main system 200 import screen W5 shown in screen display example (1) is displayed on the main system 200.

When the receiving unit 35 receives journal data 51 including additional content, it is in an unconfirmed state where final journalization has not yet been performed by the main system 200, so the status field for "Received content (reverse conversion to main)" displays "Unconfirmed." Furthermore, when final journalization is performed by the main system 200, records for "Confirmed content (main)" and "Content to be sent (converted to target)" are created. At this time, the status field for the record for "Confirmed content (main)" displays "Cancelled," and the status field for the record for "Content to be sent (converted to target)" displays "Deletion not yet processed."

The import screen W5 shown in Figure 21 displays the contents of the additional journal entry received by the main system 200 from the target system 300, corresponding to record (1) in Figure 11, and the contents of the journal entry to be sent by the main system 200 to the target system 300, corresponding to record (3) in Figure 11, side by side. At this point, the main system 200 voucher number in the "Received contents (from target)" row and the target system 300 voucher numbers in the "Received contents (reverse converted to main)," "Confirmed contents (main)," and "Content to be sent (converted to target)" rows are blank. When the user operating the main system 200 confirms that one additional journal entry has been received from the target system 300, they can confirm or cancel the additional journal entry. Then, when the user presses the update button, the processed data is deleted.

Screen display example (2) in Figure 22 is a screen displayed on the display device of the main system 200 during the upstream correction cancellation process. When the target system 300 journalizes the correction shown in Addition A (after correction) of record (1) of the upstream correction cancellation process in Figure 13, the main system 200 imports the journalization via the synchronization subsystem 210. Thereafter, the main system 200 import screen W5 shown in screen display example (2) is displayed on the main system 200. When the receiving unit 35 receives journalization data 51 including the correction details, records of "Received pre-correction contents (from target)," "Received pre-correction contents (reverse converted to main)," "Received post-correction contents (from target)," and "Received post-correction contents (reverse converted to main)" are created. When the receiving unit 35 receives journalization data 51 including the correction details, the data is in an unconfirmed state because the main system 200 has not yet performed a final journalization, and the status column of the record for "Received post-correction contents (reverse converted to main)" displays "unconfirmed."

Furthermore, when the main system 200 performs the final journal entry, records of "Confirmed correction details (main)" and "Contents to be sent (converted to target)" are created. At this time, the status field of the record of "Confirmed correction details (main)" displays "Cancelled," and the status field of the record of "Contents to be sent (converted to target)" displays "Before correction." The standby unit 34 then imports the journal entry data 38 for which the final journal entry has been performed, and the journal entry is performed by the journal entry creation unit 50 of the target system 300.

The import screen W5 displays side by side the contents of the journal entry before correction that the main system 200 received from the target system 300, which corresponds to record (1) in Figure 13, the contents of the journal entry that the synchronization subsystem 210 reverse-converted from the contents of this journal entry before correction, and the contents of the journal entry after correction that the main system 200 will send to the target system 300, which corresponds to record (3) in Figure 13.
At this point, the status fields for the records "Received contents before correction (from target),""Received contents before correction (reverse converted to main)," and "Received contents after correction (from target)" are blank, and the status field for the record "Received contents after correction (reverse converted to main)" displays "Unconfirmed." Also, the slip number for the target system 300 in the record "Confirmed correction contents (in main)" is blank. When the user operating the main system 200 confirms that there is one journal entry for correction from the target system 300, they can confirm or cancel the corrected journal entry. Then, when the user presses the update button, the processed data is deleted.

Screen display example (3) in Figure 22 is a screen displayed on the display device of the main system 200 during the upstream deletion cancellation process. When the deletion journal entry for the content shown in record (1) of the upstream deletion cancellation process in Figure 15 is performed in the target system 300, the main system 200 imports the journal entry via the synchronization subsystem 210. Subsequently, the import screen W5 of the main system 200 shown in screen display example (3) is displayed on the main system 200. This import screen W5 displays side by side the deletion journal entry content received by the main system 200 from the target system 300, corresponding to record (1) in Figure 15, and the deletion content, which is the confirmed journal entry received by the main system 200 from the target system 300, corresponding to record (3) in Figure 15. For example, the records "Received content (from target)," "Content to be sent (reverse converted to main)," and "Content to be sent (converted to target)" are displayed on the main system 200. The status field for the "Received content (from target)" record is blank, the status field for the "Sent content (revert to main)" record displays "Cancelled", and the status field for the "Sent content (convert to target)" record displays "Before deletion".

When the user operating the main system 200 confirms that there is one journal entry to be deleted from the target system 300, they can confirm or cancel the deleted journal entry. Then, when the user presses the update button, the processed data is deleted.

Figure 23 shows an example of the confirmation processing screen display for unconfirmed journal entries. The confirmation processing screen shown in Figure 23 is displayed on the display device of the main system 200 by pressing the processing button shown for each processing item in Figures 19 to 22. Here, an example of the confirmation processing screen displayed by pressing the processing button for screen display example (2) in Figure 20 is shown.

The upper section of the confirmation processing screen displays a display field for the contents of the unconfirmed journal entry received by the main system 200 from the target system 300. This display field displays the "received contents before correction" and "received contents after correction," as shown in screen display example (2) in Figure 20. In addition, when the journal entry candidate button is pressed, multiple journal entry candidates extracted by the automatic journal entry unit 22 are displayed, and the user can select any journal entry candidate.

The bottom section of the confirmation processing screen displays the "Corrected Contents to Send" as a transfer slip, as shown in screen display example (2) in Figure 20. The user can check the transfer slip, correct the journal entry with the correct content, and confirm the journal entry. This display area also displays operation buttons for "Add," "Delete," "Revert," "Add Row," "Delete Row," "Cancel Voucher," and "Update Synchronization," allowing any operation to be performed on the transfer slip. For example, to cancel an additional journal entry received from the target system 300, the "Cancel Voucher" button is pressed, and the additional journal entry is canceled.

<Computer hardware configuration>
Next, the hardware configuration of the computer 110 that constitutes each of the data linkage systems 100 and 100A will be described.
24 is a block diagram showing an example of the hardware configuration of the computer 110. The computer 110 is an example of hardware used as a computer capable of operating as the main systems 200, 200A, synchronization subsystem 210, target systems 300, 300A, and synchronization subsystem 400 according to this embodiment. Each of the data linkage systems 100, 100A according to this embodiment realizes a data synchronization method in which the functional blocks shown in FIGS. 2 to 5 cooperate with each other by the computer 110 executing a program.

Computer 110 includes a CPU (Central Processing Unit) 111, a ROM (Read Only Memory) 112, and a RAM (Random Access Memory) 113, each connected to a bus 114. Furthermore, computer 110 includes a display device 115, an input device 116, non-volatile storage 117, and a network interface 118.

The CPU 111 reads from the ROM 112 the program code of the software that realizes each function of this embodiment, loads it into the RAM 113, and executes it. Variables, parameters, etc. generated during the calculation processing of the CPU 111 are temporarily written to the RAM 113, and these variables, parameters, etc. are read by the CPU 111 as appropriate. However, an MPU (Micro Processing Unit) may be used instead of the CPU 111. The functions of each functional unit in the main systems 200, 200A and the target systems 300, 300A, as well as the functions of each functional unit in the synchronization subsystem 210 and synchronization system 400, are realized by the CPU 111 executing the synchronization program read from the ROM 112.

The display device 115 is, for example, an LCD monitor, and displays the results of processing performed by the computer 110 to the user. The input device 116 is, for example, a keyboard, mouse, etc., and allows the user to input predetermined operations and give instructions. Note that the synchronization subsystem 210 and synchronization system 400 may be configured without the display device 115 and input device 116.

The non-volatile storage 117 may be, for example, a hard disk drive (HDD), solid state drive (SSD), flexible disk, optical disk, magneto-optical disk, CD-ROM, CD-R, magnetic tape, or non-volatile memory. This non-volatile storage 117 stores the OS (operating system), various parameters, and programs for running the computer 110. The ROM 112 and non-volatile storage 117 store programs and data necessary for the CPU 111 to operate, and are used as examples of computer-readable, non-transitory storage media that store programs executed by the computer 110. The non-volatile storage 117 stores, for example, a conversion table 31, a synchronization table 33, and a reverse conversion table 37.

The network interface 118 may be, for example, a network interface card (NIC), which allows various types of data to be sent and received between systems via a local area network (LAN) or dedicated line connected to the NIC terminal. The network interface 118 realizes the functions of the transmitter and receiver of each system.

According to the data linkage system 100 according to the first embodiment described above, the journal data created and transmitted by the main system 200 in downstream processing is converted by the synchronization subsystem 210, allowing the target system 300 to import the converted journal data. This allows the journal entries created by the main system 200 to be synchronized with the journal entries of the target system 300.

Conversely, the synchronization subsystem 210 reverse-converts the journal data created and sent by the target system 300 in upstream processing, allowing the main system 200 to confirm the journal entry and then import the reverse-converted journal entry data. This allows the journal entries created in the target system 300 to be synchronized with the journal entries in the main system 200.

Furthermore, according to the data linkage system 100A of the second embodiment, the synchronization system 400 converts the journal data created and transmitted by the main system 200A in downstream processing, allowing the target system 300A to import the converted journal data. Therefore, the journal data created by the main system 200A can be synchronized with the journal data of the target system 300A.

Conversely, the synchronization system 400 reverse-converts the journal data created and transmitted by the target system 300A in upstream processing, allowing the main system 200A to confirm the journal entry and then import the reverse-converted journal entry data. This allows the journal entries created in the target system 300A to be synchronized with the journal entries in the main system 200A.

Furthermore, in the data linkage systems 100, 100A according to the first and second embodiments, the main systems 200, 200A perform confirmation processing on journal data that has been added, modified, or deleted by the target systems 300, 300A in upstream processing. Therefore, inaccurate journal entries made by the target systems 300, 300A are corrected by the main systems 200, 200A.

Furthermore, the main systems 200, 200A can cancel additions, modifications, or deletions made by the target systems 300, 300A as a result of performing confirmation processing in upstream processing. When the canceled additions, modifications, or deletions are imported into the target system 300, the additions, modifications, or deletions made by the target systems 300, 300A are canceled.

In addition, journal entries added, modified, or deleted in the main systems 200, 200A are confirmed in the target system 300 and then imported into the target system 300. Furthermore, journal entries added, modified, or deleted in the target systems 300, 300A are also finalized in the main systems 200, 200A and imported into the main systems 200, 200A and target systems 300, 300A. The journal entry data stored in the synchronization table 33 of the synchronization subsystem 210 and synchronization system 400 is then deleted, thereby reducing the recording capacity of the synchronization table 33.

In addition, during downstream processing, an import screen is displayed on the target systems 300 and 300A. In addition, during upstream processing, an export screen is displayed on the target systems 300 and 300A, and an import screen is displayed on the main systems 200 and 200A. Users of each system can check the contents of the journal entries from the screens displayed on each system.

[Modification]
The above-described embodiment describes an example in which journal data is sent and received between accounting systems through API linkage. However, downstream processing and upstream processing often have different amounts of journal data sent. Therefore, an example in which the journal data sending process is changed depending on the amount of journal data will be described with reference to FIG. 25 .
FIG. 25 is a diagram illustrating an example of the overall configuration of a data linkage system 100A according to a modification of the second embodiment.

A confirmation screen is displayed on the display device of the main system 200A, allowing the user to confirm the journal entries for finalization by the confirmation processing unit 23. When a journal entry is added, modified, or deleted in the main system 200A during downstream processing, the main system 200A sends the journal entry data for the addition, pre- and post-modification, or deletion to the synchronization system 400. Because the number of data items in the journal entry data 20 sent from the main system 200A to the synchronization system 400 during downstream processing is large, sending each item individually via API integration takes time. Therefore, it is preferable that the journal entry data 20 sent from the main system 200A to the synchronization system 400 be sent all at once in a CSV format file.

In upstream processing, the display device of the target system 300A displays a journal entry registration screen that allows the user to register journal entries. In addition, the display device of the target system 300A displays a confirmation screen that allows the user to confirm the journal entries confirmed by the main system 200A. When a journal entry is added, modified, or deleted in the target system 300A in upstream processing, the target system 300A sends the journal entry data for the addition, before and after modification, or deletion to the synchronization system 400. Upstream processing often involves a small number of data items. For this reason, when sending journal entry data from the target system 300A to the main system 200A, API integration may be used.

The present invention is not limited to the above-described embodiment, and it goes without saying that various other applications and modifications are possible without departing from the gist of the present invention as set forth in the claims.
For example, the above-described embodiment has described the system configuration in detail and specifically in order to clearly explain the present invention, and is not necessarily limited to a system having all of the described configurations. Furthermore, it is also possible to add, delete, or replace part of the configuration of the present embodiment with other configurations.
In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected.

22...Automatic journalization unit, 23...Confirmation processing unit, 30...Conversion unit, 31...Conversion table, 33...Synchronization table, 34...Standby unit, 36...Inverse conversion unit, 37...Inverse conversion table, 50...Journalization creation unit, 100, 100A...Data linkage system, 200, 200A...Main system, 210...Synchronization subsystem, 300, 300A...Target system, 400...Synchronization system

Claims (12)

a first accounting system that extracts accounting entry candidates and performs finalized entries;
a second accounting system that accepts the finalized journal entries made in the first accounting system;
a synchronization device having a conversion unit that converts the first journal data created by the first accounting system into a data format that can be imported by the second accounting system, and a synchronization table that stores the converted first journal data so that the second accounting system can import the data ;
The synchronization device
a waiting unit that waits for an import request for the first journal data from the second accounting system, and that, upon receiving the import request from the second accounting system, transmits to the second accounting system the converted first journal data that has been read from the synchronization table and that has not yet been imported by the second accounting system;
Data linkage system. The standby unit waits for the import request, transmits the converted first journal data read from the synchronization table in response to the import request to the second accounting system, receives information from the second accounting system indicating that the converted first journal data has been successfully imported, thereby managing that the second accounting system has successfully imported the converted first journal data, receives information from the second accounting system indicating that the journal entry has been successfully updated with the converted first journal data, thereby managing that the second accounting system has successfully updated the journal entry with the converted first journal data, and changes the record in the synchronization table to "updated."
The data linkage system according to claim 1 . The synchronization device
a conversion table for storing correspondence between words and phrases used in the first accounting system and the second accounting system for each item of the first journal data ;
The data linkage system according to claim 2 , wherein the conversion unit refers to the conversion table to convert the first journal data into a data format that can be imported into the second accounting system. The data linkage system described in claim 3, wherein the synchronization device converts second journal entry data of journal entries created in the second accounting system back into a data format that can be imported by the first accounting system, converts the second journal entry data in which the first accounting system has made a final journal entry for the journal entry made in the second accounting system into a data format that can be imported by the second accounting system, and transmits the converted second journal entry data to the second accounting system. The synchronization device
a reverse conversion table that stores correspondences between words and phrases used in the first accounting system and the second accounting system for each item of second journal data;
an inverse conversion unit that refers to the inverse conversion table and inversely converts the second journal data into a data format that can be imported into the first accounting system;
The data linkage system according to claim 4 , further comprising: a synchronization table that stores the second journal data after inverse conversion. The first accounting system
a journalization candidate extraction unit that extracts journalization candidates for the second journalization data after inverse conversion;
The data linkage system according to claim 4 or 5 , further comprising: a confirmation processing unit that confirms one journal entry from the extracted journal entry candidates and creates the first journal entry data. The synchronizer is a synchronization subsystem integrated with the first accounting system,
The data linkage system according to any one of claims 4 to 6 , wherein the synchronization subsystem and the second accounting system transmit and receive the first journal data and the second journal data via API linkage. The synchronization device is a synchronization system configured separately from the first accounting system,
a first transmission unit that transmits the second journal data after reverse conversion read from the synchronization table to the first accounting system;
The first accounting system
a second receiving unit that receives the second journal data after inverse conversion from the synchronization device;
a second transmission unit that transmits the second journalized data for which final journalization has been performed to the synchronization device;
A data linkage system as described in any one of claims 4 to 6 , wherein the second journal data is sent and received between the first accounting system and the synchronization system, and between the synchronization system and the second accounting system via API linkage. a conversion unit that converts first journal entry data created by a first accounting system that extracts accounting journal entry candidates and performs final journal entries into a data format that can be imported by a second accounting system that accepts the final journal entries performed by the first accounting system;
a synchronization table that stores the converted first journal data so that the second accounting system can import the converted first journal data;
a standby unit that waits for a request to import the first journal data from the second accounting system, and that, upon receiving the import request from the second accounting system, transmits the converted first journal data that has been read from the synchronization table and that has not yet been imported by the second accounting system to the second accounting system . an inverse conversion unit that inversely converts second journal data of the journal created in the second accounting system into a data format that can be imported into the first accounting system;
The synchronization device according to claim 9 , wherein the conversion unit converts the second journal data, for which the first accounting system has performed final journalization on the reverse-converted journal data, into a data format that can be imported by the second accounting system. A procedure for converting first journal entry data created by a first accounting system that extracts accounting journal entry candidates and performs final journal entries into a data format that can be imported by a second accounting system that accepts the final journal entries performed by the first accounting system;
a step of storing the converted first journal data in a synchronization table so that the second accounting system can import the converted first journal data;
A synchronization program for causing a computer to execute the following steps: awaiting a request to import the first journal data from the second accounting system; and, upon receiving the import request from the second accounting system, sending the converted first journal data that has not yet been imported by the second accounting system and that has been read from the synchronization table to the second accounting system . a step of converting second journal entry data of the journal entry created in the second accounting system back into a data format that can be imported into the first accounting system;
A synchronization program as described in claim 11, for causing a computer to execute the following steps: converting the second journal data, which the first accounting system has confirmed and entered into a data format that can be imported by the second accounting system, for the reverse-converted journal data.