Rules for data exchange 1s 8.3 accounting. Appearance and features of using universal data exchange

How to use exchange rules

How to create exchange rules

Information bases created by 1C have a similar data structure. Therefore, it will be easier to write rules for these databases. If the information base manufacturers are different, then it is more difficult to write transfer rules, and in some cases it is not advisable.

Rules are created in the infobase with the "Data Conversion" configuration.

1) Infobase configurations

After downloading the database structure, it must be added to the list of configurations.

2) Data exchange rules

Adding a new conversion

Editing exchange rules

A conversion rule for an object can be created automatically by clicking on the "Synchronize objects..." button. Below is an example of creating a rule manually for the "Currencies" directory. After clicking the "Add" button on the "Object Conversion Rules" tab, the assistant for adding a new rule will open.

1) First you need to select the source and destination infobase objects.

2) Here you need to set the transfer settings.

3) In event handlers in the built-in language, you can write your own algorithms for processing data during transfer.

Task

Transfer information about counterparties from UP V BP. Data is transferred unilaterally, identification is made using a unique identifier. Conversion rules are configured using a special configuration Data conversion, edition 3.0(Further - KD 3.0).

Actions Performed

Stage 1. Preparing to configure the rules.

To configure conversion rules in the configuration KD 3.0 must contain information about the structure of the information bases between which data is synchronized, as well as about the structure of the format Enterprise Data.

Step 1. Uploading the structure of the UP and BP information bases.

To download information about the structure of the infobase, processing is used MD83Exp.epf, included in the configuration package KD 3.0.

For each infobase ( UP And BP) you must perform the following steps:

1. Open the infobase in Enterprise mode.
2. Open external processing MD83Exp.epf(Menu File & Open).
3. Specify the name of the file in which to save the infobase structure.
4. Check the settings in the processing form (all flags must be cleared).
5. Press the button Unload.

Step 2. Export the xml exchange format scheme

To download the exchange format scheme, use standard features platforms.

You need to do the following:

1. Open one of the information databases (or UP or BP) in the “Configurator” mode.
2. In the metadata tree, find XDTO packages with names ExchangeMessage And EnterpriseData_1_0_beta.
3. Place the cursor on the XDTO package, right-click and context menu select item Export XML Schema. Specify the path and file name to export. Perform this step for each of the two packages, saving the XML schemas in two different files.

Step 3. Loading the infobase structure into the CD 3.0 configuration

Loading is performed into the configuration KD 3.0 in Enterprise mode. The steps listed below should be performed for each of the configurations for which conversion rules are configured ( UP And BP).

1. Go to section Configurations, and select the command
2. Specify the path to the file with the infobase structure (see. Stage 1, Step 1).
3. Specify download method & V new version configurations.
4. Press the button Execute download

Step 4. Loading the exchange format structure into the CD 3.0 configuration

1. Go to section Data Format, and select the command.
2. Specify files with format structure (see. Stage 1, Step 2). You must specify both files at once using multiple selection.
3. Check the main XDTO package name - must match the XDTO package namespace EnterpriseData_1_0_beta(see in the configurator UP or BP).
4. Specify download method & to the new version of the format.
5. Press the button Execute download, wait for the download to finish.

Stage 2. Creating conversions

To solve the described problem, you need to create two conversions:

• UE (for downloading data from UP to exchange format)
• BP (for loading data from the exchange format to BP)

Conversions are created in the section Conversions, team Conversions. For a new conversion, you must specify the name, configuration and exchange format. For example, conversion for the UE configuration:

• Name& “UP2.0.7”.
• Configuration& “Enterprise Management”.
• Supported format versions& one line in which a single directory entry is selected Format versions.

• data processing rules,
• object conversion rules,
• rules for converting predefined data.

To go to a set of rules for a specific conversion, you need to go to the section Conversions, select team Setting up conversion rules and select a specific conversion from the list for which the rules will be configured. As a result, the form will open Setting up exchange rules, which contains all the rules for a specific conversion.

Stage 3. Creating object conversion rules

Step 1. Conversion rule for unloading counterparties from the UE

1. UP.
2. Go to bookmark
3. Basic information:
   1. Rule ID: “Directory_Counterparties_Dispatch”,
   2. Configuration object
   3. Format object: “Directory. Counterparties”,
   4. Application area: To send.
4. Press the button Write down and go to bookmark Property conversion rules:
   1. Use the automatic property matching service
      1. Press the button Setting up PKS
      2. In the form that opens, click Automatch. The properties “TIN”, “KPP”, “Name”, “Full Name”, “Additional Information”, “LegalIndividual” will be compared.
      3. and close the form for setting up property conversion rules
5. Press the button Save and close.

Step 2. Conversion rule for loading counterparties into the BP

1. Open the exchange rules setting for conversion BP.
2. Go to bookmark Rules for converting objects.
3. Create a new conversion rule and fill in the data on the tab Basic information:
   1. Rule ID: “Directory_Counterparties_Receipt”,
   2. Configuration object: “DirectoryLink.Counterparties”,
   3. Format object: “Directory. Counterparties”,
   4. Application area: For getting.
4. Press the button Write down and go to bookmark Identification. Specify the identification method “By unique identifier”.
5. Go to bookmark Property conversion rules
   1. Use the automatic property matching service:
      1. Press the button Setting up PKS
      2. In the form that opens, click Automatch. The properties “TIN”, “KPP”, “Name”, “Full Name”, “Additional Information”, “LegalIndividual” will be compared.
      3. Save the result of automatic matching & press the button Create property conversion rules and close the form for setting up property conversion rules.
   2. Manually add a property conversion rule for OKPO (configuration property & “CodePoOKPO”, format property & “OKPO”).
   3. Later, you will need to return to the property conversion rules to populate the property conversion rule for the “LegalIndividual” property, which is an enumeration.
6. Go to bookmark Before Recording the Received Data and write an algorithm to fill in the country of registration of a new counterparty. The algorithm contains the following text: “Received Data. Country of Registration = Directories. Countries of the World. Russia;”.
7. Press the button Save and close.

Stage 4. Creating rules for converting predefined data

1. UP or BP)
2. Go to bookmark Rules for converting predefined data
3. Create a new conversion rule and fill in its properties:
   1. Rule ID: “Transfer_LegalIndividual”
   2. Configuration object: “TransferLink.LegalIndividual”
   3. Format object: “LegalIndividual”
   4. Application area: for sending and receiving
   5. In the table field, fill in the correspondence between the configuration and format enumeration values: “Individual” & “Individual” and “Legal Entity” & “Legal Entity”
   6. Press the button Save and close
4. Specify a new rule in the conversion rule for the “LegalIndividual” property of the directory Counterparties
   1. Go to bookmark Object conversion rules
   2. Counterparties, open the rule form
   3. Go to bookmark Property conversion rules and find the rule for the property “LegalIndividual”
   4. Open the property conversion rule form and indicate in it the object conversion rule & “Transfer_LegalIndividual”.
   5. Save your changes

Stage 5. Creating data processing rules

The procedure is the same for both conversions.

1. Open the exchange rules setting for conversion ( UP or BP)
2. Go to bookmark Object conversion rules
3. Find directory conversion rule Counterparties, open the rule form
4. Press the button Create based on & Data Processing Rule
5. In the created data processing rule, check the automatically filled properties:
   1. Rule ID& specify the same as for the data processing rule (“Directory_Counterparties_Sending” or “Directory_Counterparties_Receiving”)
   2. Application area& same as for data processing rule
   3. Sample object:
      1. for conversion UP& “DirectoryLink.Counterparties”
      2. for conversion BP& “Directory. Counterparties”
   4. Object conversion rule& link to the object conversion rule.
6. Press the button Record and close.

Stage 6. Obtaining data exchange manager modules

The data exchange manager module is required to exchange data between configurations in accordance with those configured in KD 3.0 rules.

The procedure is the same for both conversions:

1. Open information base UP or BP in the “Configurator” mode. Find in metadata tree common module Exchange Manager Through Universal Format and open it for editing. The module must be empty.
2. Open information base KD 3.0 in Enterprise mode.
3. Go to section Conversions and select a team Unloading the module.
4. In the form that opens, indicate the appropriate conversion and click the button Unload. The module will be copied to the clipboard.
5. Go to the infobase configurator UP or BP and paste the contents of the clipboard into the shared module Exchange Manager Through the Universal Format.
6. Save the configuration.

The module can also be uploaded to the clipboard from the form for setting up exchange rules using the button Save exchange manager module.

In order for data to be exchanged according to the configured rules, it is necessary to configure data synchronization through a universal format in both information bases in the “Enterprise” mode.

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 we 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 a large number of 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 BP and UT is suitable, if the 1C 8.3 exchange setup is performed for a complex exchange between a large number of databases, as well as identical configurations, you will need to enter each database 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 after, in the synchronization script, you can configure the schedule automatic execution exchange.

Need to set up data exchange?

WE'VE BEEN PROGRAMMING 1C FOR 15 YEARS AND MAKING FREE VIDEO INSTRUCTIONS

We have a team of programmers who have extensive experience in setting up 1C exchange:

Between 1C configurations,

In setting up 1C exchange with other programs.

Why choose us?

Up to 2 hours response time for urgent tasks, even on weekends and holidays.

40+ full-time programmers with 1C experience from 5 to 20 years.

We make video instructions on completed tasks.

Live communication via any convenient for the client messengers.

99% of tasks are completed through remote access(TeamViewer or RDP), which significantly reduces task completion time.

Official partners of the 1C company since 2006.

Experience of successful automation from small firms to large corporations.

99% of clients are satisfied with the results, which is confirmed by letters of gratitude.

In real life, it’s a rare company that gets by with just one 1C database. The most common situation is two bases, accounting and payroll.

The bases must be connected - salaries have been accrued, 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 chain of stores and a central office. Every store and office has a warehouse. Goods are moved from warehouse to warehouse (mainly from the central warehouse to store warehouses), and are sold in stores.

The 1C Retail database is used in the office and the same database in each store. Bases in stores are subordinate to the base in the office.

In the office, documents are created on the movement of goods from warehouse to warehouse, and prices are set. Documents are uploaded to subordinate databases and goods “appear” there.

Stores create documents about completed sales of goods. Documents are uploaded to the office database and sales “appear” there.

This scheme is called a distributed information base (RIB). Procedures for “uploading” documents – two-way 1C exchange. And setting up this scheme is URIB or URIBD (distributed information database management).

Principles of exchanging directories in 1C

1C directories (and the set of all directories “in the complex” is called NSI - normative reference Information) – should usually be the same in different databases. This means that even if there are several databases, the list of goods, warehouses, and contractors is the same in different databases.

A common practice is when a directory is allowed to be edited in one database, and it is copied (“migrated”) to the others. As we have discussed before, each 1C element has a unique identifier - GUID. Directories are usually copied together with their GUID, and are thus 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. In a special information register during 1C exchange, information is recorded that the element from database No. 1 with GUID xxx is equal to the element in this database with GUID yyy. Initially, existing elements that are no longer equal must be compared automatically (using other details, for example, by name or by tax identification number and checkpoint) or manually.

Principles of Document Exchange in 1C

Documents in 1C are posted according to registers and are then considered “posted”. This gives rise to understandable difficulties during transfer.

One option is to transfer only the documents and transfer them again after downloading. This method is often used, but it can give rise to errors - the document may not be posted in the new database, since the conditions during the posting may be different than they were at the time the document was posted in the original database.

Another option is to transfer documents and registers together. As we understand, the question immediately arises - either we transfer all documents in general and then the entire register in general, or we are forced to choose for transfer only movements on the transferred documents.

Let's say we need to transfer an item from 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 for and transfer also 5 elements of other directories.

Thus, when transferring one directory element or one document, 100 or more other 1C objects can be transferred via link.

In fact, it is said that almost all configuration references refer to each other in one way or another.

1C exchange plans

Let's assume that we have created a distributed database and carried out a 1C exchange. Goods have been purchased to the central warehouse and prepared for shipment to stores. In 1C in the office they introduced necessary documents movement of goods. Requires them to be loaded into stores.

What to do? Carry out a full 1C exchange again? Long and ineffective! It would be much better to calculate what exactly was added or changed by users in the office, so that only changes would be sent to stores.

There are 1C exchange plans for this. The programmer creates a 1C exchange plan in advance for carrying 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 databases of stores that will be subordinate to it.

Typical configurations already have standard 1C exchange plans. The types of bases for which they are intended are intuitively clear from the name:

• Exchange 1C with a website: exchange with a 1C:Bitrix website
• Exchange 1C UPP-UT or UT-Retail: typical exchanges with twin configurations
• Full – 1C exchange with a database based on the same configuration.

RIB - 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 this configuration. In 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; 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 indicate OTHER bases with which 1C is being exchanged.

It is necessary that both the name and code of all elements be filled in.

To create a store subbase:

• Place the cursor in the list on the 1C exchange plan element, 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 into it. This must be repeated for each element of the 1C exchange plan, except for the CURRENT BASE.

Theory of 1C exchanges

The theory of 1C exchange is quite simple:

• One of the databases (usually the center’s database) initiates 1C exchange according to a schedule or “by event” (login to the database of a specific user, etc.)
• 1C exchange consists of downloading a file from the database
• The file must be moved to a place where a slave database can pick it up (usually a share or ftp, less often e-mail)
• The slave database downloads the received file
• As confirmation that the information has been received, the slave database uploads a “response” file, which is loaded back into the central database in the same way
• The 1C exchange session is completed.

There are other methods of exchanging 1C, 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 so accessible to each other in order to be able to initiate a COM connection.

Setting up RIB 1C

In the constants of standard configurations (Operations/Constants; or Service/Program Settings) there is usually a general setting for 1C exchanges. 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 storing 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 standard configurations, usually in the Service/Distributed menu information bases/Configure RIB nodes.

For each previously created “remote store base” element, you need to add a settings element.

The settings indicate the 1C exchange method: file (share), file (FTP), file (e-mail).

Creating and setting up a distributed 1C information base in a thin client

Let's look at a similar setup in a standard configuration based on a 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 ask 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 is the configuration option via an FTP file.

The name of our 1C exchange setup.

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 one place.

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 the tabular part of this document on the BP receiver side 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 a new element to the configurator for the ExchangeSalary3Accounting3 exchange plan - the Registration with the Tax Authority directory. 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”.
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);

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.