1s 8.3 universal exchange. Organization of exchange with the base of a branch (retail store) in a trading network via XML (universal exchange)

Exchange plans in 1C 8.3 are a configuration metadata object used to implement data synchronization in the 1C 8 system.

An exchange plan can be compared to a directory, where elements are information base nodes. However, there are many nuances in working with exchange plans, which we will discuss below.

Typically, exchange in 1C is built using special exchange rules, which are formed using configuration.

As previously noted, the exchange plan is very similar to the regular one, and therefore we will only look at the main differences between the exchange.

How to work with the exchange plan

The exchange plan can store information and changes to elements from the exchange plan, and also stores information about the number of the current message. In general, the scheme of work is as follows:

1. We change the data (directories, documents, etc.) in the database - the exchange plan remembers the changes. Either by auto-registration or by program code (for example, the Exchange Plans.RegisterChanges method).
2. When the time comes, we get a list of changed elements - the ReadChanges() method, and upload this data.
3. When uploading/downloading, to avoid collisions, we check the message numbers against the exchange plan. If they do not match, we cancel the data exchange; if they match, we unregister changes and increase the message number.

Get 267 video lessons on 1C for free:

Distributed information base

If this flag is set in the settings, then this exchange plan is a distributed information base (RIB).

— a geographically distributed system based on the same 1C 8.3 configuration. In addition to data changes, RIB can also transmit configuration changes, which is very convenient, for example, when updating a configuration release.

Composition of the exchange plan

The setting with which the developer manages the set of objects for exchange:

An exchange plan can have 3 object states:

1. Not included in exchange plan- accordingly, for such an object you will not be able to configure data exchange according to this exchange plan in any way.
2. Auto-registration Deny- this means that it is necessary to register changes for a given node only using program code according to some condition, as a rule, . The Exchange Plans.RegisterChanges() method is used.
3. Auto-registration Allow— if this checkbox is checked, then any changes to the element will automatically appear in the list of changes to the exchange plan.

Exchange plans and 1C performance

Due to the systemic features of the implementation of exchange plans, it is not recommended to abuse the uploading of changes according to exchange plans. The fact is that when reading changes, all change tables are locked. Those. When unloading, the exchange plan does not allow new changes to be recorded, and therefore blocks the elements themselves - directories, documents, etc.

There was a need to set up an exchange between the 1C databases of the central company and sales branches. RIB was not suitable due to its sensitivity to configuration changes, especially dynamic updates. And also because exchange is required according to certain rules: all information must go in one direction - from the center to the branch. Those. if someone accidentally changes the item reference book in the branch database, this should not end up in the central database.

The following are unloaded from the central database to the branch:

• product catalogue,
• prices are only for some types of prices,
• orders from the online store.

In the central base and in the branch, trade is carried out from different legal entities. persons, the branch is managed independently.
The customer base in the center and in the branch is maintained independently; only those customers who have gone through the online store are common. Those. clients of the central database should not go to the branch, and clients of the branch should not go to the central database. But some of the customers passing through the online store must go through a central database. The problem arises if the client registered in the branch database and then decided to order something through the online store. In this case, when unloading from the center to the branch, it should not be duplicated, but an existing client should be picked up.

Based on these requirements, it was decided to try exchange through the EnterpriseData format.

Quick reference to sharing in EnterpriseData format

The exchange manager module is a 1C configuration module that actually implements the conversion rules for exchange. It will be located in external processing, which we will connect to the exchange plan node.

PKS - property conversion rules

Create an exchange plan

For convenience, we will create the subsystem "ECom_ExchangewithBranches". We will add all new objects to this subsystem. Changes to standard modules will be included in the extension (when connecting the extension, you will need to uncheck the “safe mode” checkbox, since server modules will be affected).

Copy the exchange plan “Data Synchronization Through a Universal Format” and name the new exchange plan “ECom_ExchangeWithBranches”.

In the exchange plan composition settings, do Actions - Turn everything off, and then add directories:

• TypesPrices
• Nomenclature

and documents:

• Customer Order
• Setting PricesNomenclature

Let's go to the manager module. In the GetExchangeFormatVersions procedure, you need to change the name of the exchange plan in the request.

It is also convenient to add the ability to debug the exchange manager module (external processing), how to do this is described here:

The DefineSettings procedure determines how our exchange plan will appear in the synchronization settings menu.

Procedure DefineSettings

Procedure DefineSettings(Settings, SettingsIdentifier = "") Export Settings.Warn ABOUT Exchange Rules Version Mismatches = True; Settings.Path to the Rule Set FileOn the UserSite = "https://users.v8.1c.ru/distribution/project/Trade110"; Settings.PathToRuleSetFileInTemplateDirectory = "\1c\trade"; Settings.Insert("Title of Command for Creating New Data Exchange", NStr("ru = "Exchange with branches"")); Settings.Insert("Header of the ExchangeCreation Assistant", NStr("ru = "Exchange with branches"")); Settings.Insert("ExchangePlanNodeHeader", НStr("ru = "Exchange with branches"")); Settings.Insert("This is an XDTOExchangePlan", True); End of Procedure

It is also necessary to add our exchange plan in the general Data Exchange module in the List of Exchange Plans procedure

SubsystemExchangePlans.Add(Metadata.ExchangePlans.ECom_ExchangeWithBranches);

As a result, it will be possible to configure the exchange according to our exchange plan:

To start the exchange of standard tools, you must also use common commands

• ConfigureTransportMessagingExchangeSettings
• Synchronize
• Composition of Sent Data

In the "Parameter type" property, select our exchange plan

Copy typical event subscriptions:

• Data Synchronization Through Universal FormatRegistration
• Data Synchronization Through Universal FormatDocument Registration

We indicate our objects that are part of our exchange plan.

We copy the standard module EventData ExchangeUT, in the resulting module in the procedures we change the name of the exchange plan from Data Synchronization Through the Universal Format to our ECom_ExchangeWithBranches.

In the created subscriptions we indicate handlers - procedures from our new module.

We will also add to this module the function This is CentralBase(), which we will need later. As a sign of a central base, we will consider the code of the node corresponding to the current base (“this node”) to be equal to “CB”.

Function This is CentralBase() Export

Function ThisCentralBase() Export Request = New Request; Query.Text = "SELECT | SELECT | WHEN ECom_ExchangeWithBranches.Code = ""CB"" | THEN TRUE | ELSE FALSE | END AS ThisCentralBase |FROM |ExchangePlan.ECom_ExchangeWithBranches AS ECom_ExchangeWithBranches |WHERE | ECom_ExchangeWithBranches.ThisNode" ; Select = Query.Run().Select(); If Selection.Next() Then Return Selection.ThisCentralBase; Otherwise Return False; endIf; EndFunction // This is CentralBase()

Because This function will be called constantly, you need to cache it using the reuse module.

Creating Registration Rules

To create registration rules, we need the Data Conversion v2 configuration.

I used this article to study the issue:

Using MD83Exp.epf processing, which is included in the delivery of Conversion 2, it is necessary to upload the structure of our configuration to a file.

Then you need to load the resulting configuration structure into Conversion 2.

We create registration rules.

We choose our configuration and our exchange plan.

And go to setting up registration rules.

We create registration rules for our objects:

Because We want to have a one-way exchange (only from the center to the branch), in setting up the rules for each object, we need to add our filter to the “Before processing” handler:

Failure = Not ECom_DataExchangeRepeat.This isCentralBase();

On the “Customer Order” we apply an additional filter by organization and by the start date of unloading:

For the document “Setting item prices” we also add selection by date. Plus, we add a filter by price type to the “During processing” handler.

UseCache = False; PriceTypes = Object.PriceTypes.UnloadColumn("PriceType"); Query Parameters.Insert("Types of Prices", Types of Prices); Query Text = "SELECT | ECom_ExchangeWithBranches.Link AS Link |FROM |Exchange Plan.ECom_ExchangeWithBranches.Types of PricesNomenclature AS ECom_ExchangeWithBranchesTypes of PricesNomenclatures | INTERNAL CONNECTION Exchange Plan.ECom_ExchangeWithBranches AS ECom_ExchangeWithBranches | Software ECom_ExchangeSF ilialamyTypesofPriceNomenclature.Link = ECom_ExchangeWithBranches.Link | AND (ECom_ExchangeWithTypesofPriceNomenclature.KindPriceNomenclatureB (&ObjectProperty_KindsofPrices)) | (ECom_ExchangeWithBranches.ThisNode = FALSE)" ;

This handler, using a request, allows you to determine the list of nodes in which the object will be registered. For some reason, although our query parameter is called “Price Types”, in the request we must write “Object_Property_Price Types”.

We also apply a filter to the “Types of Prices” directory:

We save the registration rules to an external file:

The resulting XML file must be loaded into the “Registration Rules” layout of our exchange plan:

Note that when the configuration is running, the registration rules are taken not from this layout at all, but from the rules stored in the “Rules for Data Exchange” information register. And the rules are loaded into this register precisely from the layout that is included in the configuration - when creating a synchronization setting. This leads to the fact that if we have already created a synchronization setting, and for some reason we needed to change the registration rules - after changing the rules in the configuration layout, we need to update them also in this register:

Conversion rules

To create conversion rules, we need the Data Conversion v3 configuration. It's better to use a clean base. For example, when developing a conversion for the EnterpriseData 1.3 data format, for some objects it was for some reason necessary to specify details (PKS), which were not seemingly mandatory. It turned out that they are required in version 1.2, and the mere presence of a loaded description of this format in the Conversion database already confused the logic of the program. Therefore, we take a clean database and load everything into it “from scratch”.

Very cool work with conversion 3.0 is described here:

We load the configuration structure from the file uploaded earlier (in Conversion 2).

We upload the XDTO package EnterpriseData_1_3_8 from UT 11 to a file

Load the resulting file into Conversion 3

Creating a conversion

The exchange manager format version is specified depending on the configuration. For example, for UT 11.3 it is “1”, for UT 11.4 it is “2”.

What is conversion? To unload and load an object we need:

1. Rule for sending data - here we can apply a filter to objects and apply different conversion rules (for example, different conversion rules are specified for item and element folders due to a different set of details)
2. Conversion rule “from 1C to XML” - here 1C data is converted into EnterpriseData format data (for example, you can convert the “Implementation” document into the “Receipt” document)
3. Conversion rule "from XML to 1C"
4. Data Retrieval Rule

If an object participates in the exchange plan, it is necessary to create a data sending rule for it. In our case it is:

• Types of prices
• Nomenclature
• Customer order
• Setting item prices

How will the details of these reference type objects behave? For example, the “Organization” attribute. Each “object” type in the EnterpriseData format (for example, Directory.Accounts) has so-called key properties. So, when we upload an order, we indicate the “Organization” detail in the conversion rules. When this attribute is unloaded, its key properties are also unloaded. We will not create sending rules for the “Organizations” directory, because this data changes extremely rarely in a working system; we will simply write an algorithm that, upon receiving an order, will correctly substitute an organization that already exists in the branch database.

So, we write sending rules for frequently changing objects, but we would rather upload “static” objects once (and again if necessary) through universal upload-loading.

We create a conversion rule for sending items.

Setting up “property conversion rules”. The point is. EnterpriseData is a data structure, essentially the same 1C configuration. Let's just say it's a little more simplified and universal. It must be suitable for different 1C configurations, therefore the composition and name of the objects differs from UT 11. Therefore, we need to register the correspondence - how the details are called in UT11, and as in EnterpriseData. There are so-called “key properties” - these are mandatory details for a given version of the format. They can be viewed in the "Format Object Tree":

So, we indicate the property conversion rules for the item:

As you can see, we have several details of a “complex” type; for them it is also necessary to create “Object Conversion Rules”, otherwise during unloading the following error message will appear: “The structure of the object “/Unit of Measure” does not match the type.”

Conversion rules for transfers and other predefined (in the configurator) data are created on the tab:

For this (and some other) data, it is convenient for the rule to work both sending and receiving.

We indicate the created rules in the PKS for the item:

Now let's create a conversion rule for "Sales Order".

Let's add conversion rules for the "Products" tabular section. First, let’s indicate the correspondence of the details in the PKS. It is necessary to check the "Algorithm is used" checkbox, because The values ​​of the tabular part will not be generated “by themselves”; you still need to write a small algorithm. When using the algorithm, we do not have to indicate the details of the object from 1C, because the values ​​for uploading to the XML file will still be generated by the algorithm. It is also necessary to specify a property conversion rule for "complex" types.

Now you need to add an algorithm for filling the table part into the "On sending" handler.

#Area Products // Table parts Request = New Request; Query.Text = "SELECT | Products.LineNumber AS DocumentLineNumber, | Products.Nomenclature AS Nomenclature, | SELECT | WHEN NomenclatureDirectory.NameFull = """" | THEN NomenclatureDirectory.Name | ELSE NomenclatureDirectory.NameFull | END AS NomenclatureName, | ISNULL( NomenclatureDirectory.Unit of Measurement, VALUE(Directory.PackagingUnits of Measurement.Empty Link)) AS Unit of Measurement, | EXPRESS(""OwnProducts"" AS ROW(18)) AS Inventory Type, | Products.Price AS Price, | | Products.VAT Rate | FROM | Document.Customer Order. Products | LEFT CONNECTION Directory. Nomenclature Reference | Products. Nomenclature = Reference. Link | WHERE | Products. Link = & Products. Canceled LIE" ; Request.SetParameter("Link", IB Data.Link); DataXDTO.Insert("Products", Query.Run().Upload()); #EndArea

In the conversion rules when receiving an order, you need to specify an algorithm that performs the reverse operation

The algorithm fills in the Received Data. Additional Properties. Products, which are then automatically recorded in the “Products” tabular part of the loaded object.

ArrayStringProducts = New Array; Fill Rules = New Match; Filling Rules.Insert("Nomenclature", "Nomenclature"); Filling Rules.Insert("Quantity", "Quantity"); Filling Rules.Insert("Amount", "Amount"); Filling Rules.Insert("Price", "Price"); Filling Rules.Insert("VAT Rate", "VAT Rate"); Filling Rules.Insert("VAT Amount", "VAT Amount"); Filling Rules.Insert("Warehouse", "Warehouse"); If DataXDTO.Property("Products") And ValueFilled(DataXDTO.Products) Then For Each Row From DataXDTO.Products Loop DataStructureRows = New Structure; For Each Filling Rule From Filling Rule Loop StructureForTransferValues ​​= New Structure(FillingRule.Key, Undefined); FillPropertyValues(StructureToTransferValues, String); Value = StructureForTransferValue[FillRule.Key]; If Value<>Undefined Then RowDataStructure.Insert(FillRule.Value, Value); endIf; EndCycle; Row DataStructure.Insert("Number of Packages", RowDataStructure.Quantity); If DataXDTO.Property("Warehouse") Then DataStructureRows.Insert("Warehouse", DataXDTO.Warehouse); endIf; RowArrayProducts.Add(RowDataStructure); EndCycle; endIf; If RowArrayProducts.Quantity() > 0 Then ReceivedData.AdditionalProperties.Insert("Products", RowArrayProducts); endIf;

Now we implement the following mechanism for exchanging counterparties (buyers): when loading an order into the branch database, we look for an existing client by phone (for example, the client bought something at the branch, registered, and then decided to purchase something in the online store, and the order ended up in central base). If a customer is found by phone, we add him to the order; if not, we create a new one. To do this, we will need to provide the client's phone number along with the order. The standard order fields in the EnterpriseData format do not include a telephone number; to transfer it, you can use the AdditionalInfo field, where you can record additional information. We will pass additional information in the form of a structure with the necessary fields. Both structures and tables of values ​​can be passed through AdditionalInfo. In the "When sending" handler in the order conversion rules when sending

add the code:

Handler text "On sending"

StructureAdditionalData = New Structure; Request = New Request; Request.Text = "SELECT | PartnersContactInformation.Phone Number |FROM | Directory.Partners.ContactInformation AS PartnersContactInformation |WHERE | PartnersContactInformation.Link = &Partner | And PartnersContactInformation.View = VALUE(Directory.Types of ContactInformation.PartnerPhone)" ; Request.SetParameter("Partner", IB Data.Partner); Select = Query.Run().Select(); If Selection.Next() Then structureAdditionalData.Insert("PhoneNumber", Selection.PhoneNumber); endIf; DataXDTO.Insert("Additionalinfo", structAdditionalData);

Accordingly, in the "When converting XDTO data" handler in the conversion setting when receiving

Add the code:

Handler text "When converting XDTO data"

If DataXDTO.Property("AdditionalInfo") Then If DataXDTO.AdditionalInfo.Property("PhoneNumber") Then PhoneNumber = DataXDTO.AdditionalInfo.PhoneNumber; Request = New Request; Request. Text = "Choose | Partners of contact information. Slink as a partner, | counterparties. Slink as a counterparty | from | reference point. Partner. Contact information as partners of contact -forming | internal connection reference. Controllers as counterparties | according to partners of contact information. Partner. Partner | and (partnership -containing information. .View = VALUE(Directory.Types of ContactInformation.PartnerPhone)) | AND (PartnersContactInformation.PhoneNumber = &PhoneNumber)" ; Request.SetParameter("PhoneNumber", PhoneNumber); Select = Query.Run().Select(); If Sample.Next() Then ReceivedData.Partner = Sample.Partner; ReceivedData.Account = Selection.Account; Otherwise PartnerObject = Directories.Partners.CreateItem(); PartnerObject.Name = DataXDTO.Counterparty.Name; PartnerObject.NameFull = PartnerObject.Name; PartnerObject.Client = True; PartnerObject.LegalPerson = Transfers.CompanyPrivatePerson.PrivatePerson; NewRow = PartnerObject.ContactInformation.Add(); NewRow.Type = Enumerations.ContactInformationTypes.Phone; NewLine.View = Directories.Types ofContactInformation.PartnerPhone; NewLine.PhoneNumber = PhoneNumber; NewRow.View = PhoneNumber; NewRow.FieldValues ​​= ManagementContactInformationServiceCallServer.ContactInformationXMLOnView(NewRow.View, Enumerations.ContactInformationTypes.Phone); PartnerObject.DataExchange.Load = True; PartnerObject.Write(); CounterpartyObject = Directories. Counterparties.CreateItem(); CounterpartyObject.Name = PartnerObject.Name; CounterpartyObject.NameFull = CounterpartyObject.Name; CounterpartyObject.LegalPhysicalPerson = Transfers.LegalPhysicalPerson.PhysicalPerson; CounterpartyObject.Partner = PartnerObject.Link; CounterpartyObject.DataExchange.Load = True; AccountObject.Write(); ReceivedData.Partner = PartnerObject.Link; ReceivedData.Account = AccountObject.Link; endIf; endIf; endIf;

There are several interesting points in unloading item prices:

• A price setting document can contain several types of prices, and we need to upload only those that match the filter.
• In the EnterpriseData format, the document "Setting Item Prices" has only one price type. Those. one document in 1C should be uploaded as several EnterpriseData objects.

To implement the filter, we will need to store the uploaded price types set in the exchange node settings somewhere. To do this we need "Conversion Options":

And also handling the "Before conversion" event:

In the data processing rules for the document “Setting item prices”, we need to disable the use of conversion “in the standard” version, and instead generate an XDTO object “on the fly”:

To do this, we will turn directly to the Data ExchangeXDTOServer.UploadSelectionObject method. Let's convert the document into an array of structures we need with one type of price, and upload each of these structures separately through the conversion rules. It certainly looks confusing.

Handler text "During processing"

If TypeValue(IB Data) = Type("Structure") Then Return; endIf; Request = New Request; Query.Text = "SELECT | Nomenclature Prices. ViewPrices AS Price Type, | Nomenclature Prices. Nomenclature AS Nomenclature, | Nomenclature Prices. Price AS Price | FROM | Document. Setting Nomenclature Prices. Products AS Nomenclature Prices | WHERE | Nomenclature Prices. Link = &Link | And Nomenclature Prices. Price<>0 | And Prices of Nomenclature. Type of Prices B (& Types of Prices of Nomenclature) | RESULTS ON | PriceType"; Request.SetParameter("Link", IB Data.Link); Request.SetParameter("Types of PriceNomenclature", Exchange Components.Conversion Parameters.Types of PriceNomenclature); Table of Products = New Table of Values(); Table of Products. Columns.Add("Nomenclature"); Table of Products .Columns.Add("Price"); SelectionViewPrices = Query.Execute().Select(BypassQueryResult.ByGrouping); RuleSetPriceSending = ExchangeComponents.DataProcessingRules.Find("Document_SettingPricesNomenclature", "Name"); .Next() Loop If NOT ValueFilled(SelectedPriceType.PriceType) Then Continue; (); While SelectionDetails.Next() Loop RowProducts = TableProducts.Add(); FillPropertiesValues(StringProducts, SelectionDetails); EndCycle; DataIBStructure.Insert("PriceType", SelectionPriceType.PriceType); DataIBStructure.Insert("Products", ProductsTable); Data ExchangeXDTOServer.UploadSelectionObject(ExchangeComponents, DataIBStructure, RuleSetPriceSending); EndCycle; endIf; UsagePKO.Document_SettingPriceNomenclature = False;

You need to add the “TypePrice” property to the conversion rule to PKS. In this case, you must select the “Manual” method for selecting properties.

Setting up synchronization

It is necessary to set the value of the constant "Infobase prefix" - "CB":

Create a new synchronization setting

Let’s set a filter in the settings by document date, organization, price type:

To connect our external processing containing the exchange manager module, you need to specify the display of the “service information” tab in the form settings:

Let's create a second clean database (for the branch) from the cf nickname of the central database. Also, don’t forget to enable our extension. When creating a database, the "Currency" and "Units of Measurement" directories are automatically created. To prevent duplication of this data when loading data from the central database, it is necessary to make identification not by UID, but by code when converting using these directories.

We set the infobase prefix to “FL” and set up synchronization, similar to the central database.

Additional files with a walk-through example.

Contents of the files attached to this article:

• cf file "Additional configuration objects.cf" for integration with the main configuration of UT 11, containing the developed exchange plan
• cfe file with configuration extension, for adjusting configuration modules
• xml file "Registration Rules.xml"
• epf file "ManagerDemo.epf"

Procedure for setting up an exchange plan. In the configurator, we launch the operation of comparing and merging with “Additional configuration objects.cf”. Uncheck all objects:

Select "Actions - mark by file subsystems", mark only "ECom_ExchangewithBranches"

Add the extension from the file "ECom_DataExchangeWithBranches.cfe", uncheck the security boxes:

To adjust the registration rules, the attached file "Registration Rules.xml" can be loaded into Conversion 2. You must first load the configuration structure as described.

To adjust the conversion rules, the attached file "ManagerDemo.epf" can be loaded into Conversion 3. You must first create a conversion description as described.

Data exchange between 1C 8 application solutions is something without which it is not possible to build a full-fledged enterprise information space.

• Why are data exchanges needed and how to use them?
• Types of exchanges between 1C.
• How to configure data exchange between 1C databases?

You will find out the answers to these questions below.

There are usually two reasons for introducing exchanges:

The organization has a branch network

In this case, you simply need to set up the exchange between different branches. For this purpose, there is a mechanism in the 1C 8.3 Enterprise system. With which you can flexibly configure the exchange of information. For example, for branches you can disable the visibility of documents for other branches and at the same time the central office will see documents of all branches. Another example is setting up an exchange between the 1C Retail databases of an office and stores.

Separation by type of accounting

As a rule, this means that the organization maintains different records in different information databases. This separation allows you to filter information that is “unnecessary” for another type of accounting for various information bases. Example: so-called “Management accounting” will be entered into the “Trade Management” database, where all transactions are reflected, and management sees the full picture of events, and only the documents necessary for accounting and tax accounting are uploaded to the regulated accounting database “Enterprise Accounting”.

What are the exchange mechanisms between 1C databases?

Data exchanges can be classified in two ways: the mechanisms used and the transport used for the exchange.

1C data exchange mechanisms

Typically, two mechanisms are used for exchange:

• Distributed information base (RIB)— a mechanism that allows you to set up data exchange between branches. The mechanism implies that absolutely identical database configurations are exchanged. The mechanism can transfer database configuration changes. The mechanism is implemented at the technology platform level.
• A universal mechanism for exchanging between configurations— the mechanism is developed by 1C for application solutions. It is universal and based on . Data exchange is carried out using xml rules, which are created in a special configuration - . Using this mechanism, you can implement both one-time exchange and constant exchange between 1C configurations. The mechanism is implemented at the configuration level; you can integrate it into your configuration from the technological configuration.

Transport for data exchange

Transport can be a fairly wide range of technologies. Let's consider the main ones implemented in the universal exchange mechanism 1C 8.2:

Get 267 video lessons on 1C for free:

• Local or network directory- the simplest transport. One information security creates a file on the disk, the second reads it and adds its own file.
• FTP resource— exchange is similar to exchange through a catalog. The difference is that the exchange is carried out via the FTP protocol.
• Postal messages or E-mail— the exchange takes place via email. The configurations send mail messages to each other and regularly check the mail address for new messages.
• Direct connection (COM)— the exchange is carried out through a direct connection of one database to another using funds.
• Internet (Web service)— the transport is a web service. One infobase connects to , the web service connects to the second infobase and transports the message. To carry out such transport you must have.

How to set up data exchange between 1C databases?

For the basics of setting up data exchange in 1C using the “1C Data Conversion” configuration, see the example in the video:

1C data exchange according to schedule in 1C 8.2

If you need to configure automatic uploading on a schedule, just configure .

For client-server version

In the “Data exchange settings” directory, on the “Automatic exchange” tab, you need to create a new scheduled task, where you specify the schedule:

For file option

In the “Data exchange settings” directory, on the “Automatic exchange” tab, you need to create a new routine task, where, on the “Exchange by events” tab, specify the events on which the exchange will be launched. For example, when a specific user starts:

  7
 1. Create an external processing or report in its form and write "Exchange Plans. Set MainNode (Undefined);" 2. Save the processing. 3. Close the configurator 4. Launch user mode. 5. Start processing. Another option   7
 Restoring 1C documents from the archive to the working database (XML exchange) It is often necessary to restore the data of a damaged 1C document from the database archive after unintentional, and often erroneous, actions of a successful user. In the simplest way I   6
 Automation of exchange between databases using the processing "Universal data exchange in XML format" This publication is based on the materials I found on creating an exchange between two databases using the processing "Universal exchange   6
 Instructions for creating one-way data exchange between the "Source" and "Sink" configurations from scratch: 1 Download the latest version of the "Data Conversion" configuration. Now for some reason they have stopped publishing complete distributions on the ITS website, but

Currently, many companies keep records in parallel in several 1C databases, each of which is designed to solve a specific range of problems:

• The Enterprise Accounting (EA) configuration is intended for accounting purposes.
• To reflect trading operations – Trade Management (TM),
• For payroll calculation – Salary and personnel management (ZUP).

These 1C programs are the most commonly used in practice.

The difficulty is to achieve accounting identity in the databases. After all, to reflect any operation, entering data in one database is not enough; you need to perform similar actions in another database, otherwise record keeping will vary. In order to solve this problem and avoid manual duplication of data in 1C, a data exchange mechanism is designed. With its help, it is possible to configure automatic transfer of information between databases according to established rules.

The exchange can be one-way or two-way. They differ in that with a one-way direction, data can only be unloaded from one database and loaded into another, the reverse action is impossible, but with a two-way direction, information can be exchanged in both directions.

For the most frequently used 1C programs, there is a standard exchange built into the default configuration. However, for modified, non-standard configurations, when using it, data transfer may not occur correctly. In such cases, the standard exchange mechanism should be modified or developed from scratch.

Before setting up synchronization, you need to update the configurations that will participate in the exchange to the latest release, and also make backup copies of them. At the same time, it is necessary to pre-fill configurations in the information databases in order for the exchange to work normally. What these actions include, see the following video:

Setting up data exchange (synchronization) between 1C 8.3 databases using the example of BP 3.0 and UT 11 configurations

Setting up synchronization in 1C 8.3 is done using the Data Synchronization Setup Assistant processing and consists of sequentially performing steps in the assistant in both databases that will exchange data:

To launch it in the UT 11 configuration, in the Administration section, click on the link Setting up data synchronization:

In the window that opens, you can make the initial settings of UT 11, which will be used by default in created exchanges, and also proceed to configuration. To do this, click on the Data synchronization link:

The List of configured data synchronizations window will open. To create a new data exchange in 1C, you need to click on the Set up data synchronization button, in the drop-down menu, select the type of exchange that will be configured:

How to add a new data exchange to the existing data exchange setup in 1C 8.3 UT 11, set up several exchanges with different filters for different organizations, see the following video:

Let's choose the option Enterprise Accounting, edition 3.0. The Synchronization with Data from Enterprise Accounting, edition 3.0 (setup) assistant window will open. Since the exchange setup in UT 11 is just beginning to be done, you should leave the default setup method: Specify settings manually and click on the Next button:

Setting up data exchange between UT 11 and BP 3.0 - step-by-step instructions

Step 1. Selecting a method for connecting to another base

You can leave the default settings in UT 11:

It is necessary to indicate:

• Location of another database in the Infobase directory field;
• Enter information in the User Authentication fields;
• Click on the Next button:

Step 2: Perform a connection test

Step 3: Configure data synchronization settings for programs

• Here you must fill in the Generalized warehouse field. The selection is made from the drop-down list.
• In addition, you can choose how regulatory and reference information will be sent to the receiving database from the source database and for which organizations the data will be transferred - for all or for specific ones.
• When making changes, you need to click on the Save and close button, and after closing this window, click on the Next button:

• No changes are required here.
• Click the Next button to go to information on the parameters by which data will be synchronized between databases.

Step 4: Create a new sync setting

Upon completion of this stage, the created setting is recorded, and the assistant proceeds to the final step:

Step 5: Perform data synchronization

All you have to do is click on the Finish button. The assistant is closed and the procedure for synchronizing (exchanging) data between the BP and the UT starts:

Step 6: Data Analysis

Step 7: Data Mapping

If the data is transferred to an empty destination database, then this step will be skipped:

If some data has already been entered into the receiving database and the comparison of objects cannot be performed, then when you click the Next button, a warning window will appear:

Step 8: Loading Data

Step 9. Configure parameters for the data to be sent

Step 10. Uploading data

Then the 1C UT program will move to the final stage:

As a result, information on the synchronization performed with BP 3.0 will be displayed:

Clicking the Configure button will open a new document Data synchronization script (creation), in which you can configure automatic data exchange between databases according to a schedule:

In our case, the source base was 1C 8.3 UT 11. Setting up data synchronization if the source base is a power supply unit is performed in the same way.

How to set up two-way data exchange in the information databases 1C 8.3 BP 3.0 and UT 11, see our video lesson:

Setting up data exchange between BP 3.0 and UT 11 - step-by-step instructions

To set up synchronization in the 1C 8.3 Accounting 3.0 program, you also need to sequentially perform several steps in the Data Synchronization Setup Assistant:

You can launch the assistant in 1C 8.3 Accounting by selecting Data synchronization settings in the Administration section:

In the window that opens, in a new tab, you need to check the Data synchronization box and then follow the Data synchronization link:

In the Data Synchronization window that opens, use the Set up data synchronization command to select the Trade management, edition 11 option from the drop-down list:

The Data Synchronization with Trade Management, edition 11 (settings) window will open:

• No changes are required here.
• Clicking the Next button will take you to the beginning of the synchronization setup process:

Step 1. Selecting an option to connect to another program

At this step, you need to specify the parameters for connecting to the data recipient database, namely the location and user directory:

Step 2: Check the connection

Step 3: Configure synchronization settings for the source and destination bases

You can edit the parameters that the system has set by default:

If the settings have been changed, you should save the changes using the Save and Close button.

Step 4: Create a new sync setting

Step 5. Synchronization