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:

1. Salary and personnel management (version 3.1.3);
2. 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:

1. Enable or disable synchronization;
2. Prohibit the loading of irrelevant data;
3. Set a prefix to identify the transferred data;
4. 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 number of sent 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:

1. Open the synchronization script configuration form;
2. View events of sending and receiving information;
3. Determine the date from which the exchange will take place;
4. If accounting is kept for several organizations, you can specify which of them will participate in the exchange;
5. 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.

1C presented the first version of the new business data exchange format EnterpriseData, which is based on XML and, according to its authors, is intended not only to unify the interaction of application solutions and their individual components created by the company itself, but also to be used as a universal information integration mechanism any business applications on any software platforms, including, of course, 1C:Enterprise.

The company has long been practicing the creation and use of open standards for information interaction of its applications with software from independent developers, but until now this has only concerned certain specialized subject areas. This is exactly what the CommerceML format, created almost fifteen years ago, is for solving the problem of e-commerce, as well as “Client-Bank” and DirectBank for communicating between 1C applications and external banking systems. EnterpriseData, on the other hand, is a universal mechanism that can cover all areas of an enterprise’s activities - finance, production, purchasing and sales, warehouse operations, etc. The first version of the format includes a description of 94 types of documents from various areas of business. 1C plans to add new documents to it and detail existing ones.

As 1C representatives explain, the emergence of EnterpriseData is explained by the need not only to integrate the company's applications into software from other developers, but also - perhaps even primarily - to create a unified mechanism for information communication within the 1C:Enterprise software family. Until recently, a wide range of solutions were used to solve these problems, often created on a case-by-case basis. The transition of 1C products to EnterpriseData has already begun; it is used in all the latest versions of its key applications (“1C: ERP Enterprise Management 2.0”, “1C: Accounting 8” 3.0, “1C: Accounting 8 KORP” 3.0, “1C: Retail” "2.0, "1C: Trade Management" 11). At the same time, replacing already used standards (CommerceML, working with banks) with EnterpriseData is not expected, since time-tested specialized algorithms work more efficiently than universal tools.

1C believes that the new format will find wide use among independent developers creating applications on the 1C:Enterprise platform; ready-made software components are offered for them as part of the Library of Standard Subsystems (something like the SDK for 1C:Enterprise).

When using the EnterpriseData standard, data is transferred between applications in the form of an XML file using appropriate XML schemas, while the physical transfer of information can be performed using various mechanisms: web services, file sharing through a directory, FTP and email. An important point is that the interaction algorithm implies the ability for the recipient to confirm the fact of receiving and processing the data sent to him. The XML file itself is physically supplied in compressed form (ZIP), which often allows you to reduce information traffic significantly.

1C promises further development of the EnterpriseData format and its support in an increasing number of its applications. This standard will be managed by the company itself; its creators do not yet have any plans to transform it into an independent industry standard.

In this article I will describe my, so far small, experience in organizing data exchange through the universal EnterpriseData format.

In my case, the exchange is configured between the “Trade Management 11.2” (hereinafter UT) and “Enterprise Accounting 3.0.43” (hereinafter BP) configurations. The exchange is one-way, from UT to BP. Before upgrading Trade Management 11.1 to 11.2, data exchange was configured using the Data Conversion 2.0 configuration. However, after switching to “11.2”, errors appeared in “Trade Management” for users. The procedure for updating the exchange rules was carried out, but it did not produce any results. The debugger showed that the problem was in data exchange. It was decided to remove the data exchange setting in both configurations and configure it again.

Both “Trade Management” and “Enterprise Accounting” work in a client-server version. I started setting up synchronization with UT. I performed it in such a way that the data was uploaded from the UT to a file. That is, synchronization through a network directory. In the BP I configured the exchange in such a way that no data is downloaded from the BP.

Error when calling context method (Verify): XDTO data validation error:
The structure of the object "/Counterparty Bank Account/Bank" does not correspond to the type: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)KeyPropertiesBank
Checking the "BIK" property:
shape: Element
name: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIK
type:
Required property missing
Object: Agreement with Counterparty No. ...

To analyze the error, I clicked on the “Composition of sent data” icon and in the list of contractor agreements registered for sending, I found the agreement for which the error appeared. I opened the agreement and remembered the counterparty’s bank account specified in the agreement. Then I moved on to the bank accounts registered for shipping. It turned out that the required account was not in the list of registered ones. I redid the problematic bank account and contract. After that, I manually registered the required bank account.

I tried again to synchronize data from UT. This time the data was successfully uploaded. An XML file was generated in the network folder containing data to be transferred from the UT to the BP.

The next step is to load the data from the file into the enterprise accounting department. In the "Enterprise Accounting" configuration, I clicked the "Synchronize" button, a processing form opened with the message "Data analysis in progress." A little later the message changed to “Data upload in progress.” At the same time, the indicator and counter showed that more than 80 thousand objects were being unloaded from the power supply unit. This confused me, because I indicated in the settings that nothing should be unloaded from the power supply. The processing took quite a long time and ended with the error:

Event: Data Exchange
(GeneralModule.Long-runningOperations.Module(371)): Background job worker process terminated abnormally
RaiseException(ErrorText);

To localize the error, I tried changing the synchronization settings and operation options of the power supply base. As a result, when I converted the database to a file version, the system worked adequately: a form for comparing two databases opened. After matching the objects, the initial synchronization was successful. Then I switched the database back to the client-server version.

With further testing of synchronization, it was necessary to make some changes to the rules for converting objects. It's time to use the Data Conversion 3.0 configuration. The built-in configuration help describes how it works. Articles on the ITS website also helped.

As a result, I loaded the following data into "Data Conversion 3.0":

• Texts of the general module "Data Exchange Manager Through a Universal Format" from two databases
• Layout of both bases
• Description of the EnterpriseData format (from any one database)
• Conversion rules

After downloading, I opened the rules for converting data, objects, and properties in “Data Conversion 3.0”. Made the changes I needed. Then I used the "Unload exchange manager module" button. The module text has been copied to the clipboard. All that remains is to insert it into the configuration.

Having experimented with setting up the rules in "Data Conversion 3.0", I concluded for myself that in the case when the changes being made are insignificant, it is easier to set up the rules directly in the UT and BP configurations, in the general module "Data Exchange Manager Through the Universal Format". If the edits are serious, such as, for example, adding a new object to the exchange, then you should use the configuration " Data conversion 3.0".

I performed the task of adding the document "Order to supplier" to the exchange plan using " Data conversion 3.0". In the standard version of UT - BP this document is not included in the exchange plan.

Let's remember that the rules for registering objects for uploading are still configured in the "Data Conversion 2.0" configuration.

These are the first impressions of data synchronization through the universal EnterpriseData format.

P.S. If you have questions or your own observations about data exchange via the Universal Format and Configurations" Data conversion 3.0", write in the comments. We will exchange experiences.

• Data synchronization
• Universal EntepriseData Format
• Data conversion 3.0
• Data conversion 2.0
• Trade management
• Enterprise accounting

Print (Ctrl+P)

Exchange via a universal format

The “Data Exchange” subsystem of the library of standard subsystems contains 4 options (technologies) for information exchange between various information bases:

• distributed information bases (RIB);
• data exchange through a universal format;
• data exchange according to exchange rules (exchange rules are created using the “Data Conversion” configuration, edition 2.1);
• data exchange without exchange rules.

This article discusses the technology of data exchange through universal EnterpriseData format. This technology is available in the “Standard Subsystems Library” starting with version 2.3.1.62. released in early 2016. Currently, the latest edition of BSP 2.3 (for use with the 1C:Enterprise 8.3 platform no lower than version 8.3.8.1652 with compatibility mode disabled) has release 2.3.6.17.

Rice. 1 Latest releases of BSP 2.3

Among the files for supplying 1C application solutions, there is a text file “Library Versions”, where it is written on the basis of which version of the BSP the application was developed, for example, based on the application solution UT 11.3.3.231, BSP 2.3.5.65 was formed.

Please note that for use with the “1C:Enterprise 8.3” platform version no lower 8.3.10.2168 edition was released with compatibility mode disabled BSP 2.4.

Description of the EnterpriseData format

What is the EnterpriseData format?

This is a format that allows you to describe an information base object (counterparty, invoice, etc.) or report the fact that this object has been deleted. It is expected that the configuration that receives the file in the EnterpriseData format will react accordingly - it will create new objects and delete those that are marked as deleted in the file. It is intended for information exchange between UT, RT, UNF, BP configurations. The format can also be used to exchange information with any other information systems: it does not depend on the features of its own software or information base structures that participate in the exchange and does not contain obvious restrictions on use.

EnterpriseData format version

The format data is stored in XDTO packages in the general database configuration branches, as shown in Fig. 2

Fig. 2 XDTO – EnterpriseData data format packages

In Fig. 2 shows that there are several XDTO packages. These are different versions of the format. The format version number consists of X.Y.Z, where X.Y is the version, Z is the Minor version. The Minor version is increased in case of bug fixes and other changes in which: the functionality of the data conversion logic based on the previous version of the format is maintained (maintaining backward compatibility of current data transfer algorithms through the format); Support for new format capabilities for conversion logic is voluntary. An example of such changes could be correcting an error, changing the properties of format objects, adding properties whose use is not mandatory when converting data. In other cases, when the format changes, the Major version increases: X – in the case of global restructuring, Y – in other cases.
The format describes the representation of objects (documents or directory elements) in the form of XML files. Version 1.0.1 contains a description of 94 objects from various areas (finance, production, purchasing and sales, warehouse operations). The names of the types, as a rule, are well understood and do not need additional explanations: for example, “Document.Act of Completed Work” or “Directory.Counterparties”. As you can see, the description of document types begins with the prefix “Documentary.”, and the directory element begins with the prefix “Directory.”. A more detailed description of the format can be found
The latest version is 1.3, however, the most commonly used version is 1.0. There isn't much difference between the versions. Format EnterpriseDataExchange_1_0_1_1 used when exchanging via a web service.
Note that that the EnterpriseData data format package is used together with ExchangeMessage when creating conversion rules. It is this package that contains the type object AdditionalInfowhich can have any value type and is used when creating a conversion rule between configuration objects. that are not in the data format. Exactly, thanks AdditionalInfoYou can adapt and customize exchange rules without changing the format data in XDTO packages.

Rice. 3 Structure of the XDTO packageExchangeMessage

How to exchange data in EnterpriseData format?

Exchange of data in EnterpriseData format with configuration is a file exchange. In response to the file received from the external application, the configuration will process it and create a response file. Files can be exchanged:

• via a dedicated file directory,
• via FTP directory,
• through a web service deployed on the infobase side. The data file is passed as a parameter to web methods.

Note. For two-way data exchange between a third-party application and the configuration on the infobase side, a number of settings must be made - the third-party application must be registered in the infobase, an exchange channel must be defined for it (via a file or FTP directory), etc. But for cases of simple integration, when it is enough to only transfer information from a third-party application to the infobase and reverse transfer of data from the infobase to a third-party application is not required (for example, integration of an online store that transfers sales information to 1C: Accounting), there is a simplified version of working through a web service that does not require settings on the side.

When exchanging using configuration exchange plans during synchronization, only information about changes that have occurred since the last synchronization is transmitted (to minimize the amount of information transferred). The first time you sync, the configuration will dump all EnterpriseData formatted objects into an XML file (since they are all “new” to the third party 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 information that a message from the configuration with a certain number was successfully received (place the number of the message received from the configuration in the ReceivedNo field). The receipt message is a signal to the configuration that all objects have been successfully processed by the external application and there is no need to transmit information about them anymore. In addition to the receipt, the XML file from a third-party application can also contain data for synchronization (in the section ).

After receiving the receipt message, the configuration marks all changes sent in the previous message as successfully synchronized. Only unsynchronized changes to objects (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 configuration, the picture is reversed. The application must fill out the section accordingly, and in the section place objects to be synchronized in EnterpriseData format.

After processing the file, the configuration will generate an XML file that will contain a receipt message and new data for synchronization from the configuration side (if there is any since the last synchronization session).

You can see more details about data exchange with application solutions on the 1C:Enterprise platform in the EnterpriseData format

General module of “exchange manager through a universal format”.

Procedures and functions that fully describe the rules for downloading data from the information base into the exchange format and the rules for loading data from the exchange format into the information base are developed in a common module - the exchange manager module through a universal format.

Rice. 4 Structure of the exchange manager module through a universal format

The module is created automatically using the “Data Conversion” configuration, edition 3.0, based on configured exchange rules, or manually in the configurator.

The module consists of several large sections, each of which contains its own group of procedures and functions.

1. A comment. The first line of the module contains a comment with the name of the conversion. This line is necessary to identify the module when using the command in the Data Conversion program, edition 3.0, for example. // Conversion UP2.2.3 from 06/01/2017 19:51:50
2. Conversion procedures. Contains predefined procedures that are performed at different stages of data synchronization: before conversion, after conversion, before deferred filling.
3. Data Processing Rules (DPR). Contains procedures and functions that describe the rules for processing data.
4. Object Conversion Rules (OCR). Contains procedures and functions that describe the rules for converting objects, as well as the rules for converting properties of these objects.
5. Predefined Data Conversion Rules (PDC). Contains a procedure that fills in the rules for converting predefined data.
6. Algorithms. Contains arbitrary algorithms that are called from other rules (POD or PKO).
7. Options. Contains the logic for filling in the conversion parameters.
8. General purpose. Contains procedures and functions that are widely used in rules and algorithms.

The parameters of procedures and functions that are used in several types of procedures in the manager module are described below.

Exchange Components. Type - Structure. Contains parameters and exchange rules initialized as part of the exchange session.

Direction of Exchange. Type – String. Either "Send" or "Receive".

IB data. Type – DirectoryObject or DocumentObject.

Procedures related to conversion events

There are three predefined procedures that are called during the conversion process:

• Before Conversion. Called before data synchronization occurs. This procedure typically houses the logic for initializing various conversion parameters, populating default values, etc. Parameters: ComponentsExchange.
• AfterConversion. Called after data synchronization has completed, but before lazy padding has occurred. Options: ComponentsExchange.
• BeforeDelayedFilling. Called before lazy filling occurs. The logic for sorting or adjusting the table of objects subject to lazy filling can be located here. Options: ComponentsExchange.

AML procedures

Fill in the Data Processing Rules. An export procedure that contains the logic for filling out data processing rules. Contains calls to other procedures that add a rule for processing a specific object to the rules table (see procedures below Add AML). Options: Direction of Exchange, Data Processing Rules

Add UNDER_<ИмяПОД>. A set of procedures that populate the table UNDER the rules for specific objects. The number of such procedures corresponds to the number of AML provided for this conversion in the Data Conversion program, version 3.0. Options: Data Processing Rules(a table of values ​​initialized as part of the exchange session).

UNDER_<ИмяПОД>_WhenProcessing. The procedure contains the handler text During Processing for a specific AML. The handler is designed to implement conversion logic at the object level. For example, assign a specific PQO to a specific object depending on the contents of the object. Options:

• InformationB data or DataXDTO(depending on the direction of exchange):
• when sending – object ( DirectoryObject,DocumentObject);
• upon receipt - a structure with a description of the XDTO object.
• Use of PKO. Type - Structure. The key contains a string with the name of the PCO, and the value of type Boolean (True– PKO is used, Lie– PKO is not used).
• ComponentsExchange.

UNDER_<ИмяПОД>_Data Sampling. The function contains the handler text When Unloading. The handler is designed to implement an arbitrary algorithm for selecting objects to be unloaded. Return value: an array of objects to be unloaded. The array can contain both links to infobase objects and a structure with data for uploading. Options: ComponentsExchange.

PKO procedures

Fill in the Object Conversion Rules. An export procedure that contains the logic for filling out the rules for converting objects. Contains calls to other procedures that add a specific object conversion rule to the rules table (see procedures below Add PKO). Options: Direction of Exchange, Conversion Rules(a table of values ​​initialized as part of the exchange session).

AddPKO_<ИмяПКО>. A set of procedures that populate the PKO table with rules for specific objects. The number of such procedures corresponds to the number of PKOs provided for this conversion in the Data Conversion program, version 3.0. Options: Conversion Rules(a table of values ​​initialized as part of the exchange session).

PKO_<ИмяПКО>_WhenSendingData. The procedure contains the handler text When Sending for a specific PKO. The handler is used when uploading data. Designed to implement the logic for converting data contained in an infobase object into a description of an XDTO object. Options:

• InformationB data. Type - DirectoryObject, DocumentObject. The information base object being processed.
• DataXDTO. Type - Structure. Designed to access XDTO object data.
• ComponentsExchange.
• StackUploads. Type - Array. Contains links to unloaded objects, taking into account nesting.

PKO_<ИмяПКО>_When Converting XDTO Data. The procedure contains the handler text When Converting DataXDTO for a specific PKO. The handler is used when loading data. Designed to implement arbitrary XDTO data conversion logic. Options:

• DataXDTO. Type - Structure. XDTO object properties that have been preprocessed to make them easier to access.
• ReceivedData. Type - DirectoryObject, DocumentObject. An infobase object formed by converting XDTO data. Not recorded in the information database.
• ComponentsExchange.

PKO_<ИмяПКО>_Before Recording the Received Data. The procedure contains the handler text Before Recording the Received Data for a specific PKO. The handler is used when loading data. Designed to implement additional logic that must be performed before recording an object in the infobase. For example, should changes be loaded into existing information security data or should they be loaded as new data. Options:

• ReceivedData. Type - DirectoryObject, DocumentObject. A data element generated by converting XDTO data.

Recorded if this data is new for the infobase (parameter InformationB data contains the value Undefined).

Otherwise ReceivedData replace InformationB data(all properties from ReceivedData transferred to InformationB data).

If standard replacement of information security data with received data is not required, you should write your own transfer logic, and then set the parameter ReceivedData meaning Undefined:

• InformationB data. Type - DirectoryObject, DocumentObject. An infobase data element corresponding to the received data. If no matching data is found, contains Undefined.
• ConvertingProperties. Type - Table of values. Contains rules for converting properties of the current object, initialized as part of the exchange session.
• ComponentsExchange.

PCPD procedures

Fill in the Conversion Rules of Predefined Data. An export procedure that contains the logic for filling in the rules for converting predefined data. Options: Direction of Exchange, Conversion Rules(a table of values ​​initialized as part of the exchange session).

Algorithms

In the “Data Conversion” program, edition 3.0, it is possible to create arbitrary algorithms that are called from the AML and PKPD handlers. The name, parameters and content of the algorithms are determined when developing the rules.

Options

Fill inConversionParameters. An export procedure in which the structure with conversion parameters is filled in. Options: Conversion Options(type - Structure).

General Purpose Procedures and Functions

ExecuteManagerModuleProcedure. Options: ProcedureName(line), Options(structure). An export procedure, which is intended to call a non-export module procedure, the name and parameters of which are received as input. Allows you to call a procedure or function on a line without using a method Execute.

ExecuteManagerModuleFunction. Options: ProcedureName(line), Options(structure). Function, purpose similar ExecuteManagerModuleProcedure. The difference is that it calls a function and returns its value.

Let's look at a simple real life example. Let's say we have a company that is engaged in wholesale and retail trade, and in this company, like in any other, accounting is done. The enterprise has two standard databases, these are UT (trade management) and BP (accounting of the enterprise), respectively, in each of the databases its own records are kept, in UT there is management to reflect all transactions related to trade, in BP there is accounting. In order not to do double work, i.e. do not create the same documents in two databases (after all, movements should be in management and accounting) we will just set up synchronization between these databases.

We will set up data exchange one-way, from UT ---> BP. It is also possible to set up a two-way exchange, but in practice this is not often required, so we will not consider it in our example.

Preparatory steps for setting up exchange in BP

Let's start setting up synchronization, first go to the 1C "Enterprise Accounting 3.0" database (receiver), we need to check whether synchronization is enabled for this database, in order to do this we need to first go to the database. As soon as the database opens, go to the tab "Administration" ---> "Data synchronization settings"

A new tab opens in front of us; it must be filled out in the same way as in the screenshot below, with the exception of the information base prefix. The prefix must consist of two letters, you can set any, but according to the 1C standard it is better to set the prefix by the name of the configuration, that is, for “Enterprise Accounting” the prefix will be “BP”. If you are setting up complex exchanges and there are several accounting databases, then the prefixes should clearly differ from each other; here you can use the first two letters of the organization’s name as an abbreviation.

We continue setting up data synchronization in UT

After we have done all the necessary actions in the receiver database (BP 3.0), to continue setting up data exchange we need to open the source database (UT 11.1). Go to the "Administration" tab, select "Data synchronization settings" in the menu on the left. If synchronization is not enabled, then enable it using the checkbox, and do not forget to specify the source base prefix. Once we have completed all steps 1-4 as shown in the image below, you need to click on the “Data Synchronization” hyperlink (step 5).

In the new window that appears, you need to click on the green plus sign (Set up data synchronization), in the drop-down menu select the item “Enterprise Accounting 3.0”.

Setting up important points in data exchange between UT and BP

Now we see a window with settings for data synchronization in 1C, select “Specify settings manually” and click “Next”.

We continue to set up data exchange in 1C, on the next tab we need to select the option of connecting to the receiver infobase (direct connection to the program), connection parameters (on this computer or on the local network), the directory where the receiver base is located, as well as the necessary authentication data ( username and password in the database).

On the next page we must fill in the rules for sending and receiving data from the BP 3.0 (receiver) configuration. Click "change data upload rules".

The “Rules for sending data” window has opened in front of us, in it we set the following parameters:

• Which reference data will be sent (in our example, we are only interested in documents and the reference data used in them, so we selected the appropriate item; if you select the first item “Send all”, then all reference books will be reloaded along with the documents, often if the information is not used in the documents then it is useless for the receiver, because it does not affect the accounting in any way)
• From what date should all information be sent (we will not consider manual synchronization in this article)
• To which or which organizations to send data (in our example, we chose one organization, IP "Entrepreneur")
• Rules for forming contracts
• Generalized warehouse
• Should I roll up documents by warehouse?

After we have made the settings, click “Save and close”.

Since in our example we set up and use one-way exchange, from UT to BP, then the settings for the rules for obtaining data from “Enterprise Accounting 3.0” are not of interest to us, so we click “Next”.

In a new window, we are asked to configure rules for the receiver base (RB). In point 1, we name our database, give it a prefix. The PREFIX must be the same as we set it in the BP database itself at the beginning of this article; if the prefixes are different, data synchronization in the 1C program will not work. After that, click point 2, and then point 3.

In point 3, we need to allow documents to be processed when they are loaded into the database. Click "Save and close".

Now the window should look something like the one shown below, click “Next”.

This window contains reference information about the synchronization being created in 1C. Just click the "Next" button. If the program generated an error when setting up data synchronization, then you need to contact us so that our 1C specialist can help you right now!

Next step the program will offer to synchronize immediately after creating the data exchange settings. Let's agree to this and click "Done".

A window will appear in front of you in which you will see information about how the synchronization is proceeding. If the receiver base is not empty, i.e. records have already been kept in it, then the user in the 1C program will be asked to make a comparison of objects manually. Comparison of objects in 1C when synchronizing data is a comparison of identical objects of the receiver with identical objects in the source.

Let's look at an example, let's say in UT there is a counterparty with the name "PharmGroup LLC" and TIN 1234567, and in BP there is also a counterparty with TIN 1234567, but the name "PharmGroup", if we do not compare these two objects when comparing data at the synchronization stage, then after synchronization in the receiver (Enterprise Accounting 3.0), we will have two counterparties with TIN 1234567 and two names “PharmGroup LLC” and “PharmGroup”, respectively. In order to avoid such situations, a mechanism for comparing objects was invented.

In our example, the receiver database is empty, and therefore the object comparison window did not open. But after performing some operations, the system will definitely prompt the user to add some additional data and display the following window. We don’t need to transfer any additional data, we’ve already configured everything we need earlier, so at this step we select “Do not add documents to sending.” Click "Next".

The final stage of data exchange between 1C

At the final stage, the program will display the following window, in which the user will be informed that the synchronization was successful, click “Finish”. At this point, synchronization between databases in a one-way exchange from “Trade Management 11.1” (UT) to “Enterprise Accounting 3.0” (BP) is completed.