Each plan has a certain list of elements, information about the change of which it can store. This list is called the “Composition of the exchange plan”. 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 this conversion package (Registration Rules, Exchange Rules, Correspondent Exchange Rules) that we need for further study.
Consider an example of data synchronization between the configurations "1C: Payroll and HR 3" (ZUP) and "1C: Enterprise Accounting 3" (BP). We note right away that in this task we will have to remove the configuration from support. This is required by condition.
A living example of the need to refine the model 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 of the “Registration with the tax authority” directory, which are necessary to fill out the “Reflection of wages in accounting” document. Now tabular part of this document on the side of the BP receiver contains an empty "Registration ..." and users have to manually create such entries in the directory. Agree, it's inconvenient. We can improve this point. 
Solution to the problem: we will 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, the "Property Conversion" of this directory (PKS). We will definitely finalize the standard "Rules for registering objects", because there was a need to register the directory changes on the exchange node. And we will revise the "1C Exchange Rules" of the correspondent's base.
Where will we edit this? to write and change the rules, we need the "1C: Data Conversion 2" configuration.
Refinement of standard conversion rules from the PZUP-BP exchange plan
So, let's start finalizing the 1C exchange rules by adding a new element to the composition in the configurator for the exchange plan ExchangeSalary3Accounting3 - the RegistrationIn Tax Authority directory. We will make this change in both configurations "1C: Salary and Enterprise Management 3" and "1C: Enterprise Accounting 3".
Save and update the configurations.
In the enterprise mode, for each database, we will upload a description of the metadata structure using the processing of MD83Exp.epf for the 1C:Enterprise 8.3 platform. Processing can be found in the "1C: Data Conversion" kit.
At the next stage, we will unload the conversion package from the ZUP and BP. The package should consist of 3 files: Registration Rules, Exchange Rules, Correspondent Exchange Rules.
Within the framework of this article, there will be no description of how data synchronization is configured, you can read it 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. We will see the form "Rules for synchronization". Click the "More" button and select the "Save rules to file" option.
Here is a package after unloading we should get.
We will perform similar actions for another information base "1C: Enterprise Accounting".
As a result, all the preparatory work for editing the rules is ready. We have:
Description of the metadata structure for loading into "1C: Data Conversion 2" (for ZUP and BP);
A conversion package that contains 1C exchange rules and registration rules required for uploading to 1C: Data Conversion 2 (for ZUP and BP).
Go to "1C: Data Conversion 2". 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);
Create registrations and load registration rules from conversion packages (rules file is called RegistrationRules).
We proceed directly to our refinement. We add a new object conversion rule (PKO) to the 1C exchange rules - the "Registration with the tax authority" reference book. We add a property conversion rule (PCS) for this directory and a data upload rule (PDS). This kind of refinement must be performed both for the rules from the ZUP package and for the exchange rules from the BP package. We unload our exchange rules into the corresponding files ExchangeRules.
Let's move on to the rules for registering a new element. We add the reference book "Registration with the tax authority". Upload the registration rules to the appropriate file from the RegistrationRules package. This action is also performed for both bases.
Modified 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, 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, it remains to upload them back to the infobases and check the synchronization.
Archive files from packages to ZIP archive and upload our conversion packages to ZUP and BP.
All is ready. It remains to be tested.
Let's remember the conditions of the problem. It was necessary to register for unloading the directory "Registration with the tax authority" and check how the PM of the document "Reflection of wages in accounting" is filled out on the side of "1C: Enterprise Accounting 3".
In the source "1C: Salary and Enterprise Management 3" we register our directory for unloading. We perform synchronization. We go to the receiver database and also perform synchronization to receive data. Please note that now the necessary directory for registering changes has appeared in the exchange plan.
We check on the side of "1C: Enterprise Accounting 3":
Summarize. The result of the task was completed successfully. We have finalized the plan for the exchange of ZUP - BP, adding a new element for registering changes and completing the conversion rules for data synchronization.
Automated systems management in most cases consist of separate databases and often have a geographically distributed structure. At the same time, a correctly implemented data exchange - necessary condition For effective work such systems.
In this case, the initial exchange setup 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 based on the 1C:Enterprise platform. Why setting up a 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 consider 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;
- "Demarcate" different types accounting.*
*In the case when the data of one type of accounting differs significantly from another, it is necessary to ensure the confidentiality of information and “separate” information flows. For example, data exchange between 1C UT and 1C Accounting does not require uploading management data to the regulatory accounting database, i.e. synchronization in 1C will be incomplete here.
If we represent the standard process for implementing the 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 the exchange 1C
Exchange objects can be conditionally 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 definition of the source and destination occurs in a logical way, depending on the need or on functionality systems.*
*For example, when integrating WA: Financier, a solution for financial accounting and managing 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.
Further, based on the received and recorded requirements from the users, a list of data for exchange is created, their volume, requirements for the exchange frequency are determined, 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 infobase
- RIB implies an exchange between identical 1C database configurations, with a clear master-slave control structure for each exchange pair. Being an element of the technological platform, the RIB, in addition to data, can transfer changes in the configuration and administrative information of the database (but only from the master to the slave).
universal exchange data 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 improvements associated with the exchange. Previously when logged in new configuration 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 to be modified, having only one entry-exit point.
Definition of transport (exchange protocols)
The system based on the 1C:Enterprise 8 platform provides a wide range of options for organizing exchange with any information resources through generally accepted universal standards (xml, text files, Excel, ADO connection, etc.). Therefore, when determining the transport for data exchange, one should start from the capabilities of the database of a third-party system.
Synchronization of directories
The main principle of effective directory synchronization is the presence of one entry point. But if we are talking about working with directories that were historically filled out according to different rules, it is necessary to clearly define the synchronization fields to bring the exchange to a “common denominator.”*
*At this stage, it may be necessary to carry out work on the normalization of reference data on the side of the data source. Depending on the state of directories and their volume, the process of comparing elements, recognizing, identifying errors and duplicates, as well as filling in the missing fields and assigning synchronization fields, may require the work of a whole group of experts, both from the side of the integrator (the owner of the reference data normalization methodology) and from the side of the customer.
Setting rules
The ability to display data from source systems in receivers depends on correctly defined exchange rules. The rules presented in the xml format regulate the correspondence of the key attributes of the source-destination objects. The 1C: Data Conversion solution is designed to automate the creation of rules for the implementation of both a one-time exchange and a permanent one.
Ensures no data loss during exchange Exchange plan. This is an integral part of any configuration on the 1C:Enterprise platform, which fully describes the 1C exchange procedure: data composition (documents with "identifying" details) and nodes (receiver-transmitter information bases), as well as the activation of RIB for selected exchange directions.
Any change in the data entered in the Exchange Plan is fixed and receives the sign of "change". As long as the changed data does not correspond to each other in the receiver-transmitter nodes, the flag will not be reset, and the system will send control messages to both nodes. After unloading the data and confirming their full compliance in both systems, the sign is reset.
Exchange schedule in 1C
To automate the regular exchange, the frequency of data upload 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 for implementing the exchange, let's pay attention to the factors that will require improvements at different stages:
- Non-standard, heavily modified database configurations;
- Different versions of the 1C:Enterprise platform;
- Not updated for a long time, not up-to-date versions of the configuration;
- Exchange objects that have been previously modified;
- The need for non-standard exchange rules;
- A very different set and composition of details in the available directories.
Since even standard actions for the implementation of the primary data exchange require expert knowledge, they are recommended to be carried out with the participation of 1C specialists. Only after completing all the above steps, you should proceed to setting up the exchange in the configuration. Consider the integration of databases on the example of "1C: UPP" and "1C: Retail" (according to the same scheme, the exchange with "1C: UT" is configured). Also, typical synchronization includes the exchange of SCP - SCP, 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 ..." (selection direct exchange with "Retail" often threatens with errors at the level of COM objects). Pay attention to the official message " This opportunity unavailable."
To solve this problem, you must select "Data Sharing Settings"
...and check the box. Further, the error message is ignored.
In the data synchronization settings, select "Create an exchange with" Retail "...
Before configuring connection settings through a local or network directory, make sure that there is space on the disk for the directory. Although, as a rule, it does not take 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 through the network directory, we ignore the proposals to configure the connection via the FTP address and by e-mail by clicking "Next".
In the settings manually put down the prefixes - conventions bases (as a rule, BP, SCP, RO), we set the rules and the start date for uploading data. The prefix will be indicated in the title of the documents to indicate the base in which they were created. If the upload rules are not edited, the default data will be uploaded according to all available parameters.
We create an exchange settings file for Retail so as not to repeat our actions. If you need to send data immediately after setting up synchronization, check the box.
To automate the exchange process, you need to set up a schedule.
Retail menu.
Check the box and select Sync.
We make a “reverse” setting by choosing Managing a manufacturing enterprise.
Load the file with the settings created in SCP.
We put a tick, the system picks up the address automatically.
We act in the same way as in the UPP.
Verification comparison of data (Manual comparison of data is recommended to be done at the preparatory stage, since this work can become the most time-consuming in the process of implementing the exchange). The comparison window is opened by double-clicking the mouse.
In case of an error in synchronization, “Details…” will be replaced with “Never…”.
“Details…” opens the registration log with updated information on the exchange.
Ready.
Universal Data Exchange Mechanism is intended both for creating geographically distributed systems based on 1C:Enterprise 8, and for organizing data exchange with other information systems not based on 1C:Enterprise 8.
This mechanism allows you to transfer only 1C:Enterprise data; transferring the configuration and administrative information of 1C: Enterprise 8 using this mechanism is not possible.
Possibilities
- data exchange can be implemented both with 1C:Enterprise information bases and with other information systems;
- organization of various messaging strategies;
- implementation various ways resolving collisions while changing data in different nodes of a distributed system;
- implementation of data exchange recovery in such cases as infobase recovery from backups etc.
Peculiarities
- XML documents are used as an exchange format;
- when exchanging data between 1C:Enterprise 8 infobases, no restrictions are imposed on the identity of the configuration and structure of specific objects;
- in one configuration, several independent exchange schemes with various information systems can be created;
- when organizing an exchange scheme, no restrictions are imposed on the structure of a distributed system. It can be organized as a classic star-type structure, as well as more complex multi-level snowflake-type structures and others;
- the developer of the applied solution is given the opportunity to flexibly control the composition of the exchange, both in terms of the structure of the transmitted data, and in terms of the composition of the information transmitted to specific exchange nodes;
- the database object is initially created in one of the exchange nodes. The composition of the transmitted information can be adjusted depending on the content of the data, and does not depend on the place of the initial input of information.
Components
A universal data exchange mechanism is not a rigid solution. Its work is implemented by a set of tools of the 1C: Enterprise 8 technological platform, which can be used in application solutions in various combinations.
- Exchange plan
Configuration objects The exchange plan is the center around which other means of communication are grouped. With the help of these objects, a set of nodes of a distributed system and the composition of the data that are supposed to be exchanged within the framework of this exchange plan are described.
In addition, exchange plans implement two important mechanisms involved in data exchange:- Change Registration Service
Allows you to get information about which data elements have been changed and to which exchange node they need to be transferred.
- Change Registration Service
IN real life a rare company manages with one 1C base. The most common situation is two bases, accounting and salary.
The bases must be connected - the salary has been calculated, the accrued taxes must go to the accounting department for payment.
To connect several databases, there is Exchange 1C. How does he work?
What is Exchange 1C?
There is a network of shops and a central office. Every store and office has a warehouse. Goods are moved from warehouse to warehouse (mainly from the central warehouse to stores), and in stores they are sold.
The base 1C Retail is used in the office and the same base in each store. Bases in stores are subordinate to the base in the office.
The office creates documents on the movement of goods from warehouse to warehouse, prices are assigned. Documents are uploaded to the subordinate bases and the goods “appear” there.
In stores, documents are created on the sale of goods. Documents are uploaded to the office base and sales “appear” there.
Such a scheme is called a distributed information base (DIB). Procedures for "filling" documents - two-way exchange 1C. And the setting of this scheme is URIB or URIBD (management of distributed information databases).
Principles of Directory Exchange in 1C
1C directories (and the set of all directories "in the complex" is called NSI - regulatory reference information) - in different databases should usually be the same. This means that even if there are several databases, the list of goods, warehouses, contractors is the same in different databases.
It is a common practice when in one database the directory is allowed to be edited, and it is copied (“migrates”) to the rest. As we discussed earlier, each 1C element has a unique identifier - GUID. Directories are usually copied along with their GUID, and thus are identical throughout the distributed information system.
Otherwise, when several initially existing databases are connected, or when directories can be created in different databases at the same time, their GUIDs will be different. There is a matching mechanism for this. During the 1C exchange, information is recorded in a special information register that an element from base No. 1 with GUID xxx is equal to an element in this base with GUID yyy. Initially, the existing elements that are no longer equal must be matched automatically (by other details, for example, by name or by TIN and KPP) or manually.
Principles of Document Exchange in 1C
Documents in 1C are posted by registers and after that they are considered "posted". This gives rise to understandable difficulties in the transfer.
One option is to transfer only the documents and post them again after uploading. This method is often used, but it may give rise to errors - the document may not be posted in the new database, since the conditions during posting may be different than they were at the time of posting this document in the original database.
Another option is to transfer documents and registers together. As we understand it, the question immediately arises - either we transfer all documents in general and then the entire register in general, or we are forced to choose to transfer only movements on transferred documents.
Let's say we need to transfer an element of the Nomenclature directory. This directory has 10 fields, of which 5 are strings and numbers, and 5 are links to other directories.
Accordingly, when transferring one element of the Nomenclature, we are forced to search and transfer also 5 elements of other directories.
Thus, when transferring one element of the directory or one document, 100 or more other 1C objects can be transferred by reference.
In fact, almost all configuration directories are said to refer to each other in one way or another.
1C exchange plans
Suppose we have created a distributed database and exchanged 1C. Goods are purchased at the central warehouse and prepared for shipment to stores. In 1C, the office entered the necessary documents for the movement of goods. It is required that they are loaded into stores.
What to do? Carry out a full exchange again 1C? Long and inefficient! It would be much better to calculate what exactly was added or changed by users to the office, so that only changes get into the stores.
For this, there are 1C exchange plans. The programmer creates a 1C exchange plan in advance to carry out 1C exchanges with some other database, for example, with our stores.
The 1C exchange plan notes, when users work with directories and documents, what has been added or changed since the last 1C exchange with this database.
Creation of URIB 1C
So, we will create a distributed database from scratch. Initially, we have a "parent" office base. From it we will select the bases of stores that will be subordinate to it.
In typical configurations, there are already standard 1C exchange plans. The types of bases for which they are intended are intuitively clear from the name:
- Exchange 1C with the site: exchange with the site 1C: Bitrix
- Exchange 1C UPP-UT or UT-Retail: typical exchanges with sister configurations
- Full - 1C exchange with a database based on the same configuration.
RIB - a distributed information base - can also be made on the basis of the 1C "Full" exchange plan. In the configurator, in this 1C exchange plan, the “Distributed infobase” checkbox should be checked.
The 1C exchange plan created in the configurator indicates that we are going to exchange with such a configuration. In the Enterprise mode in the same 1C exchange plan, you now need to specify specific databases based on this configuration.
Let's go to the 1C exchange plan (Operations / Exchange plan; they can also be in another menu, often in the Service / XXX menu).
In the list of databases in the 1C exchange plan, there is one with a green circle in the picture. This element stands for THIS BASE. The remaining elements denote OTHER bases with which 1C is being exchanged.
It is necessary that both the name and the code are filled in for all elements.
To create a "shop" subbase:
- Set the cursor in the list to the element of the 1C exchange plan, which we created as a “store base”
- Select the menu item "Actions/Create initial image".
As a result, one database will be created, with the initial data uploaded to it. This must be repeated for each element of the 1C exchange plan, except for the CURRENT BASE.
Theory of exchanges 1C
The 1C exchange theory is quite simple:
- One of the bases (more often the base of the center) initiates the 1C exchange according to the schedule or “on an event” (login to the base of a certain user, etc.)
- 1C exchange consists in unloading a file from the database
- The file must be moved to a place where the subordinate base can pick it up (usually a share or ftp, less often email)
- The slave database downloads the received file
- As confirmation that the information has been received, the slave base uploads a “response” file, which is uploaded back to the central base in the same way.
- Exchange session 1C completed.
There are other methods of 1C exchange, not through files, but, for example, through a direct COM connection between two databases. Its advantages:
- No "space to store and transfer files" required
- No need to re-upload confirmation
- Everything happens faster due to the first two points.
However, the limitation is clear - the bases must be in such proximity to each other in order to be able to initiate a COM connection.
Setting up RIB 1C
In the constants of typical configurations (Operations / Constants; or Service / Program Settings) - usually there is general setting exchanges 1C. This is a prefix in element codes and document numbers to easily determine in which database it was created. As well as an internal method for saving information about the place where directories and documents were created.
Now you need to configure how the process of periodic exchange of 1C information between the created databases will take place.
All RIB settings in 1C are in typical configurations, usually in the Service / Distributed infobases / Configure RIB nodes menu.
For each previously created "remote store base" element, you need to add a configuration element.
The setting specifies the 1C exchange method: file (share), file (FTP), file (e-mail).
Creating and configuring a distributed 1C infobase in a thin client
Let's see a similar setting in a typical configuration based on thin client– Trade management edition 11.
Settings (and creation from scratch) are located on the Administration tab of the interface. Item "Data Exchange".
Select "Create an exchange in a distributed infobase".
From the very beginning, 1C will prompt us to indicate how we are going to exchange information with the subordinate database. Here is the configuration option "via a file on the ball."
Here's a configuration option via a file on FTP.
The name of our exchange setting is 1C.
And immediately a proposal to create an "initial image" - that is, the slave database itself with uploading primary information into it.
Unlike the configuration on a thick client, both 1C exchange settings are in the same place.
Loading...