In some cases (for example, with a large document flow or with complex accounting), it is much more convenient for the end user to distribute accounting between several applications, exchanging data between them from time to time. Before the release of the 1C platform version 8.3, standard data exchange occurred solely at the user’s request through uploading and downloading information using XML files. Recently, the data synchronization mechanism in 1C has been increasingly used.
There are several reasons for the popularity of synchronization:
- There is no need to separately run the processes of loading and unloading data;
- Automatic execution of information exchange does not interfere with manual exchange;
- Easy to configure (for standard configurations, you don’t even need to create exchange rules;
- It is enough to create synchronization once and declare a schedule for its execution.
Conditions of our task
At the input we have two standard database configurations:
- Salary and personnel management (version 3.1.3);
- Accounting for an agricultural enterprise (version 3.0.52).
Both databases operate in file mode. Synchronization can be configured from any database.
If synchronization will be configured from “Accounting” to “ZUP”, the “Synchronization” checkbox must be activated and vice versa.
Where are the settings
In “Accounting”, go to the “Administration” subsystem, in the “Settings” menu and find the “Data synchronization” item (Fig. 1)
The synchronization settings window will open (Fig. 2)
Rice. 2
Here we can:
- Enable or disable synchronization;
- Prohibit the loading of irrelevant data;
- Set a prefix to identify the transferred data;
- Go to other synchronization settings.
By starting synchronization by checking the appropriate box and defining a prefix, we can close the accounting department. Further work will be done in “Salary”.
The data synchronization settings window is shown in Fig. 3
Rice. 3
Let's take a closer look at it.
Synchronization settings window
Let's start in order:
Separately, I would like to draw the reader’s attention to the “Registration of changes” window (Fig. 5). At the top of which there are numbers of sent and received messages; after a successful exchange, the numbers in the source database and destination database must match. In some cases (synchronization occurred with a copy of the database, malfunctions), the numbering in the databases is broken. You can correct this situation by simply clicking on the hyperlink with numbers. This action allows you to manually set the current sent number and incoming messages(Fig. 6)
Rice. 6
Synchronization settings
There are two commands on the “Data synchronization settings” tab:
- Tune;
- Download rules.
Running the “Load Rules” command opens the form (Fig. 7)
Rice. 7
Here we can choose whether we are going to use the standard exchange rules supplied in the configuration, or whether we will synchronize according to our own rules stored in the archive file.
The remaining settings are made by clicking on the “Configure” button (Fig. 8).
Rice. 8
In the first window that opens you can:
- Open the synchronization script configuration form;
- View events of sending and receiving information;
- Determine the date from which the exchange will take place;
- If accounting is kept for several organizations, you can specify which of them will participate in the exchange;
- Define the parameters for uploading salary transactions: with or without detail by employee (summary).
The “Load set of rules” command is similar to the same command in the previous settings window.
It’s worth taking a closer look at the connection parameters (Fig. 9)
Rice. 9
In our case, the destination base and the source base are located on the same computer and work in file mode, so synchronization between them occurs through a direct connection.
We have to:
- Determine the path to the receiving base;
- Set authorization parameters (a user with administrator rights must be created in the receiving database);
- After checking the connection, we can assume that our setup is complete.
If the exchange occurs through other connection types, you need to configure their parameters on the corresponding tabs.
Schedule settings
And at the end, a few words about setting up the synchronization schedule; it is performed in the corresponding tab of the window (Fig. 3) and is no different from the corresponding form for setting up the schedule for other routine tasks.
Automated control systems in most cases consist of separate databases and often have a geographically distributed structure. At the same time, correctly implemented data exchange is a necessary condition for efficient work such systems.
The initial setup of the exchange may require a number of actions, not only in terms of programming, but also consulting, even if we are dealing with homogeneous sources, as is the case with products on the 1C:Enterprise platform. Why setting up 1C exchange (or, as it is also called, data synchronization in 1C 8.3) can become the most time-consuming and expensive task of an integration project, we will look at in this article.
Data exchange in the 1C environment allows you to:
- Eliminate double entry of documents;
- Automate related business processes;
- Optimize interaction between distributed departments;
- Promptly update data for the work of specialists from different departments;
- "Delimit" different types accounting.*
*In cases where the data of one type of accounting differ significantly from another, it is necessary to ensure the confidentiality of the information and “delimit” information flows. For example, data exchange between 1C UT and 1C Accounting does not require uploading management data into the regulatory accounting database, i.e. synchronization in 1C will be incomplete here.
If you imagine standard process implementation of primary data exchange, when at least one of its objects is a 1C product, then the following stages can be distinguished:
- Coordination of the composition of the exchange;
- Definition of transport (exchange protocols);
- Setting rules;
- Scheduling.
Identification of the composition of 1C exchange
Objects of exchange can be divided into “source” and “receiver”. At the same time, they can perform two roles at the same time, which will be called a two-way exchange. The source and destination are determined logically depending on the need or functionality systems.*
*For example, when integrating “WA: Financier” - solutions for maintaining financial accounting and management of treasury processes, developed on the basis of 1C:Enterprise, WiseAdvice experts recommend it as a master system. This is due to the availability of control tools to comply with the rules of the application policy, and, accordingly, to ensure the effectiveness of the solution.
Next, based on the received and recorded requirements from users, a list of data for exchange is created, its volume, requirements for the frequency of exchange are determined, and the process of working with errors and handling exceptional situations (collisions) is prescribed.
At the same stage, depending on the fleet of existing systems and the structure of the enterprise, the exchange format is determined:
Distributed information base
- RIB implies exchange between identical 1C database configurations, with a clear “master-slave” control structure for each exchange pair. As an element of a technology platform, RIB, in addition to data, can transmit configuration changes and administrative information of the database (but only from master to slave).
Universal data exchange in 1C
- A mechanism that allows you to configure the exchange of 1C databases, both with configurations on the 1C:Enterprise platform and with third-party systems. The exchange is carried out by transferring data into a universal xml format in accordance with the “Exchange Plans”.
EnterpriseData
- The latest development of the 1C company, designed to implement data exchange in xml format between products created on the 1C:Enterprise platform with any automation systems. The use of EnterpriseData simplifies the modifications associated with the exchange. Previously, when a new configuration was included in a system, it was necessary to implement a mechanism for importing and exporting data, both for it and for existing systems. Now systems that support EnterpriseData do not need any modifications, having only one entry-exit point.
Definition of transport (exchange protocols)
For the system on the 1C:Enterprise 8 platform, a wide range of possibilities is provided for organizing exchange with any information resources using generally accepted universal standards (xml, text files, Excel, ADO connection, etc.). Therefore, when determining the transport for exchange data, you should rely on the database capabilities of the third-party system.
Synchronization of directories
The basic principle of effective synchronization of directories is the presence of a single entry point. But if we are talking about working with directories that have historically been filled out according to different rules, it is necessary to clearly define synchronization fields to bring the exchange to a “common denominator.”*
*At this stage, it may be necessary to carry out work to normalize the reference data on the side of the data source. Depending on the state of the directories and their volume, the process of comparing elements, recognizing, identifying errors and duplicates, as well as filling in missing fields and assigning synchronization fields, may require the work of a whole group of experts, both on the part of the integrator (the owner of the master data normalization technique) and from the customer's side.
Setting rules
The ability to display data from source systems in receivers depends on correctly defined exchange rules. The rules, presented in xml format, regulate the correspondence of key details of source-receiver objects. The 1C:Data Conversion solution is designed to automate the creation of rules for implementing both one-time and permanent exchanges.
Guarantees no data loss during exchange Exchange Plan. This component any configuration on the 1C:Enterprise platform, fully describing the 1C exchange procedure: data composition (documents with “identifying” details) and nodes ( information bases receivers-transmitters), as well as activation of RIB for selected exchange directions.
Any change in the data entered into the Exchange Plan is recorded and receives the “changed” sign. Until the changed data matches each other in the receiver-transmitter nodes, the sign will not be reset, and the system will send control messages to both nodes. After uploading the data and confirming their full compliance in both systems, the sign is reset.
Exchange schedule in 1C
To automate regular exchange, the frequency of data uploading is set. The frequency of exchange depends on the need and technical capabilities. Also, configurations on the 1C:Enterprise platform allow you to configure data exchange when an event occurs.
Having considered the standard process of implementing an exchange, let’s pay attention to factors that will require improvements at different stages:
- Non-standard, highly modified database configurations;
- Different versions platforms "1C:Enterprise";
- Not updated for a long time, not current versions configurations;
- Objects of exchange that have previously undergone modifications;
- The need for non-standard exchange rules;
- A very different set and composition of details in existing reference books.
Since even standard actions to implement primary data exchange require expert knowledge, they are recommended to be carried out with the participation of 1C specialists. Only after completing all the steps described above should you proceed to setting up the exchange in the configuration. Let's look at the integration of databases using the example of 1C:UPP and 1C:Retail (exchange with 1C:UT is set up using the same scheme). Also included in standard synchronization is the SCP - SCP exchange, which is typical for large-scale automation systems at the largest industrial enterprises.
In the “Service” submenu, select “Data exchange with products on the platform...” (selecting direct exchange with “Retail” often results in errors at the COM object level). Please note the service message “This feature is not available.”
To resolve this issue, you need to select "Configure Communications"
...and check the box. Next, ignore the error message.
In the data synchronization settings, select “Create an exchange with “Retail”...
Before configuring connection settings through a local or network directory, you should make sure that there is space on the disk for the directory. Although, as a rule, it does not take up more than 30-50 MB, in exceptional cases it may require up to 600 MB. You can create the required directory directly from the configurator.
When connecting via a network directory, you are prompted to configure the connection using an FTP address and e-mail ignore by clicking “Next”.
In the settings we manually enter prefixes - symbols databases (usually BP, UPP, RO), we set the rules and the start date for downloading the data. The prefix will be indicated in the name of the documents to indicate the database in which they were created. If the upload rules are not edited, the data will be uploaded by default according to all available parameters.
We create an exchange settings file for “Retail” so as not to repeat our actions. If you need to immediately send data immediately after setting up synchronization, check the box.
To automate the exchange process, you need to set up a schedule.
Menu "Retail".
Check the box and select “Synchronization”.
We perform the “reverse” setup by selecting Production Enterprise Management.
Load the settings file created in UPP.
We put a tick, the system picks up the address automatically.
We act in the same way as in UPP.
Test data comparison (Manual data comparison is recommended to be done on preparatory stage, since these jobs can become the most labor-intensive in the process of implementing the exchange). The comparison window opens by double click mice.
In case of an error in synchronization, “Details...” will be replaced with “Never...”.
“Details...” opens the log with updated information on the exchange.
Ready.
Send this article to my email
The main reasons for the need to implement exchange between 1C databases are the presence of branches and the separation of accounting types, because Often companies operate in several information databases. Setting up 1C 8.3 exchange allows you to eliminate double work - entering the same documents and directories in two programs, as well as quickly deliver the necessary system objects for various branches and departments.
In the case when it is necessary to exchange between branches, the RIB (Distributed Information Base) is used. This is an exchange mechanism between identical configurations. It represents a tree with the most important root node on top, below a pair of interconnected nodes. Changes can be made in any node of this system, and they will be transmitted to other connected nodes. It also distributes not only data, but also configuration changes from the root node to the slave nodes.
If it is necessary to separate types of accounting, for example, maintaining operational ones in the trading database, and regulated ones in the accounting database, universal exchange mechanisms with flexible data synchronization settings are available.
One of the latest 1C developments is the EnterpriseData data exchange format. It is easy to use and is intended for exchange within the company both between 1C databases and third-party programs.
The implementation of data exchange in an enterprise can be represented in the form of sequential procedures.
First of all, it is necessary to determine between which databases there should be an exchange; will it be a two-way or one-way exchange; if one-way, then which database will transmit information and which will only receive; if this is a complex branch network, then it is necessary to register a database construction scheme.
Then select the appropriate format: RIB, universal format; exchange according to exchange rules; exchange without exchange rules.
The next step is to select a vehicle to carry out the exchange. A large selection of technologies is available, let’s highlight the main ones: directory (local or network), FTP resource, COM connections, web service, email.
The fourth step will be to identify the data: documents, reference books and, if necessary, detail them down to their individual details to be transferred.
And in conclusion, a schedule of exchange frequency is prescribed
Each option for setting up 1C 8.3 exchange requires careful preparation. Its implementation is beyond the capabilities of every user; it is necessary to take into account many nuances and understand the principles of the exchange. Particular attention will need to be paid to configuration if the databases: contain modifications or many additional ones. details, differ in platform versions or use outdated versions of configurations, the enterprise is large and uses automated system, consisting of large quantities bases Errors are unacceptable here, because... may lead to irreparable consequences. Independent implementation of exchange in 1C is recommended only if you need to set up a simple transfer of information between standard configurations.
If you doubt your abilities, it is better not to save, but to contact a competent specialist who will help solve the complex problem of setting up 1C 8.3 exchanges.
If you still decide to configure 1C exchanges without involving experts, it is recommended to first test on copies of the databases, and before starting work in the working databases, upload the configurations to be able to return to the original state in case of errors.
Below we give a detailed example of setting up 1C 8.3 exchange unilaterally between standard configurations Trade Management 11 (UT) and Enterprise Accounting 3.0 (BP). The example is relevant for many companies engaged in wholesale and retail trade. In the UT, management accounting is maintained, in the BP - regulated, the exchange is necessary to facilitate the work of users.
This algorithm is also suitable for other standard configurations on the 1C 8.3 platform
First of all, we will carry out preparatory work for the information receiver, i.e. for BP. We launch the program in Enterprise mode. You need to set the Data synchronization constant (section Administration → Data synchronization).
Pay attention to the Prefix field; here you need to specify a value that will allow you to subsequently distinguish (by the value of the directory code or document number) in which program the objects were originally created. In our example, the usual abbreviation is suitable - BP and UT, if the 1C 8.3 exchange setup is performed for a complex exchange between big amount bases, as well as identical configurations, you will need to enter each base with its own clear designation.
Since the power supply unit is only a receiver of information, we proceed to setting up the UT.
Here, just like in the BP, you need to enable synchronization and specify a prefix. This information is available in the Master data and administration section → Data synchronization settings.
Select the setup method: Specify settings manually. Further.
Let's set up a direct connection option, when both programs are located in one local network, we will indicate the parameters for connecting to the information security directory on this network, and also fill in the authentication information about the user (in the BP database). Further.
The system will check the correctness of the specified data and, if the result is positive, will display the 1C 8.3 exchange settings window.
Click the Change data upload rules link to access settings for the exchange. We will clarify the master data - upload only those used in documents, select organizations and the option of working with contracts - without reference, separation of documents by warehouse. The exchange begins on March 1 of the current year.
We write down the introduced rules and close them.
Since the example is about one-way transmission of information, in the next settings window to receive data from another program, you should set the values to Do not send. Record and close. Further.
Now you need to check the entered parameters and if they are correct, click Next, otherwise return to the previous step by clicking Back.
You will then be prompted to synchronize. Click Finish.
If it is necessary to correlate identical objects of two configurations, a window for comparing data will open. We perform the comparison and click Next.
When transferring objects, problematic situations may arise; you can view the results by clicking the Warnings during data synchronization link.
After synchronization is completed, a window will be displayed confirming the successful completion of this process.
Here, using the Configure command or later, in the synchronization script, you can configure a schedule for automatically performing the exchange.
To facilitate integration with software products 1C company has developed the EnterpriseData data exchange format. The format is based on XML and is business-oriented - the data structures described in it correspond to business entities (documents and directory elements) presented in 1C programs, for example: act of completion, cash receipt order, counterparty, agreement, etc. This makes the format intuitive and easy to use.
The EnterpriseData format is intended for data exchange within a company (including between heterogeneous and geographically remote information systems) and is designed to cover all areas of the enterprise’s activities - finance, production, purchasing and sales, warehouse operations, etc.
Format Description
Version 1.0.1 of the format includes a description of 94 types of business entities from various business areas ( detailed description format can be found). The format is extensible - 1C will add descriptions of new business entities to it and expand existing entities with new fields. Support for the format in 1C products ensures bottom-up compatibility - all third-party programs that exchange data in the EnterpriseData format with 1C products will continue to work correctly when new versions of the format are released.
The format is intended for the exchange of information between any information systems: it does not depend on the characteristics of its own software or information base structures that participate in the exchange and do not contain explicit restrictions on use.
The format is used to synchronize data between software products of the 1C company itself. The following products currently support this format:
- "1C:ERP Enterprise Management 2.0",
- "Enterprise Accounting", edition 3.0,
- "Accounting for a KORP enterprise", edition 3.0,
- "Retail", edition 2.0,
- "Basic Trade Management", edition 11,
- "Trade Management", edition 11,
- “Salaries and personnel management CORP”, edition 3.
|
|
|
Possible data exchange option |
Data exchange with 1C programs
Pre-configuration on the 1C side
To start exchanging data in the EnterpriseData format between the 1C application and a third-party application, you need to configure data synchronization on the 1C side. During setup, a unique code of the application with which the exchange will be carried out is indicated, as well as through which channel the data will be exchanged. The following options are currently available:
- web service,
- file exchange via directory,
- file exchange via FTP,
- exchange via email.
In the case of exchange via a web service, a third-party application will initiate a data exchange session by calling the corresponding web methods of the 1C application. In other cases, the initiator of the exchange session will be the 1C application.
Also on the “1C” side you can configure how often synchronization will occur (for options with file exchange via a directory and email):
- according to schedule (with a given frequency);
- manually; the user will have to manually start synchronization every time he needs it.
Exchange File Format
During synchronization, 1C applications and third-party applications exchange messages - XML files of a certain structure. These files consist of two sections −
|
|
|
Example message |
Section
If the message goes in the opposite direction - from third party application into the 1C application, the third-party application must fill out the section accordingly
1C applications keep records of sent and received synchronization messages and expect the same from third-party applications. Why this is done is outlined below.
Handshake mechanism
During synchronization, 1C applications transmit only information about changes that have occurred with business entities since the last synchronization (to minimize the amount of information transferred). During the first synchronization, the 1C application will upload all business entities in the EnterpriseData format to an XML file (since they are all “new” for the external application). The next step is for the third-party application - it must process the information from the XML file and place it in the section during the next synchronization session
After receiving the receipt message, the 1C application marks all changes transmitted in the previous message as successfully synchronized. Only unsynchronized changes to business entities (creating new ones, changing and deleting existing ones) will be sent to the external application during the next synchronization session.
When transferring data from an external application to the 1C application, the picture is reversed. The application must fill out the section
After processing the file, the 1C application will generate an XML file that will contain a receipt message and new data for synchronization from 1C (if there is any since the last synchronization session).
Exchange via web service
When using a web service, the exchange session is initiated by a third-party application. To receive data from the 1C application, it needs to call the GetData web method, passing the unique application code entered in the . In response, 1C will return a file containing data about business entities in the EnterpriseData format. The file format is described.
To transfer data to 1C, the application must call the PutData web method, passing the unique application code and the zipped file in the format described above as parameters.
Exchange through other channels
In the case of data exchange via a directory/FTP directory or email, the initiator of the exchange will be the 1C application. It will be placed in the appropriate channel (directory or Mailbox) file of the format described above and expect response files from a third-party application in the same channel. In the case of directory/FTP directory exchange, the file name must be composed in a special way so that the 1C application can process it. In the case of an exchange by e-mail, the subject line of the letter must follow a specific rule, and a zipped file with data must be attached to the letter.
Conclusion
The range of integration scenarios using the EnterpriseData format is wide. This includes data exchange within one organization, for example, data transfer to 1C:Accounting from other applications for maintaining holistic accounting, or data exchange between the central office and remote warehouses. The format is also suitable for data exchange between different organizations.
Each plan has a specific list of elements that it can store information about changes to. This list is called “Exchange Plan Contents.” The composition can be expanded, but configuration support is removed.
The “Plan Layout” stores the very rules on the basis of which synchronization works. It is precisely this conversion package (Registration Rules, Exchange Rules, Correspondent Exchange Rules) that we need for further study.
Let's consider an example of data synchronization between the configurations “1C: Salary and HR 3” (ZUP) and “1C: Enterprise Accounting 3” (BP). Let us note right away that in this task we will have to remove the configuration from support. This is required according to the condition.
A living example of the need to refine standard exchange rules
For example, a customer contacted us with the following problem: when synchronizing between ZUP and BP, it is not possible to transfer the data from the “Registration with the tax authority” directory, which is necessary to fill out the document “Reflection of salaries in accounting.” Now tabular section of this document, on the receiver side, the BP contains an empty “Registration...” and users have to manually create such entries in the directory. Agree, this is inconvenient. We can improve this point. 
Solution to the problem: let’s finalize the conversion package from the exchange plan ExchangeSalary3Accounting3. Let’s add to the standard “1C Exchange Rules” a new “Object Conversion Rule” (PKO) for the “Registration with the Tax Authority” directory and, accordingly, “Property Conversion” of this directory (PCS). We will definitely finalize the standard “Rules for registering objects”, because there was a need to register directory changes on the exchange site. And we will review the “1C Exchange Rules” of the correspondent’s database.
Where will we edit all this? To write and change the rules, we need the “1C: Data Conversion 2” configuration.
Finalization of standard conversion rules from the ZUP - BP Exchange Plan
So, we’ll start finalizing the 1C exchange rules by adding new element- Directory of Registration in the Tax Authority. We will make this change in both configurations “1C: Salaries and Enterprise Management 3” and “1C: Enterprise Accounting 3”.
Let's save and update the configurations.
In enterprise mode, for each database we will upload a description of the metadata structure using MD83Exp.epf processing for the 1C:Enterprise 8.3 platform. The processing can be found in the “1C: Data Conversion” package.
At the next stage, we will unload the conversion package from the ZUP and BP. The package must consist of 3 files: Registration Rules, Exchange Rules, Correspondent Exchange Rules.
This article will not describe how data synchronization is configured; you can read this on the Coderline website in the “Expert Articles” section or watch webinar recordings. Now this option is already configured in the databases. Therefore, go to the synchronization settings (Administration -> Data synchronization -> Data synchronization settings), click the “Load rules” button. The “Rules for synchronization” form will open in front of us. Click the “More” button and select the “Save rules to file” option.
This is the package we should get after unloading.
We will perform similar actions for another information base “1C: Enterprise Accounting”.
In the end everything preparatory work ready for editing the rules. We have:
Description of the metadata structure for loading into “1C: Data Conversion 2” (for ZUP and BP);
Conversion package, which contains 1C exchange rules and registration rules necessary for loading into “1C: Data Conversion 2” (for ZUP and BP).
Go to “1C: Data Conversion 2”. Let's perform the following steps in order for both infobases:
Loading the metadata structures of our configurations;
We create conversions and load 1C data exchange rules from conversion packages (the rules file is called ExchangeRules);
We create registrations and load registration rules from conversion packages (the rules file is called RegistrationRules).
Let's move on to our revision. We are adding a new object conversion rule (PKO) to the 1C exchange rules - the “Registrations with the tax authority” directory. We add a property conversion rule (PCR) for this directory and a data upload rule (DRU). This kind of modification must be performed both for the rules from the ZUP package and for the exchange rules from the BP package. We upload our exchange rules to the corresponding ExchangeRules files.
Let's move on to the rules for registering a new element. We are adding a reference book “Registrations with the tax authority”. We upload the registration rules to the appropriate file from the RegistrationRules package. We also perform this action for both databases.
The revised exchange rules and registration rules are ready. Now we copy the contents of the exchange rules (ExchangeRules) from the BP package into the correspondent rules (CorrespondentExchangeRules) from the ZUP package. In the correspondent rules (CorrespondentExchangeRules) from the BP package, we copy the contents of the exchange rules (ExchangeRules) from the ZUP package.
The result should be the following:
This completes the work in “1C: Data Conversion 2”. The modified packages of conversion rules are ready, all that remains is to upload them back to the information databases and check the synchronization.
We archive the files from the packages into a ZIP Archive and upload our conversion packages to the ZUP and BP.
All is ready. It remains to be tested.
Let us recall the conditions of the problem. It was necessary to register the “Registration with the tax authority” directory for downloading and check how the TC of the document “Reflection of wages in accounting” is filled out on the “1C: Enterprise Accounting 3” side.
In the source “1C: Salaries and Enterprise Management 3” we register our directory for downloading. We perform synchronization. We go to the receiver database and also perform synchronization to receive data. Please note that now the exchange plan has the necessary directory for registering changes.
We check on the “1C: Enterprise Accounting 3” side:
Summarize. The result of the task was completed successfully. We have finalized the ZUP - BP exchange plan, adding a new element for registering changes and added conversion rules for data synchronization.