Property of the exchanged data. Universal data exchange Separation by type of accounting

If you do a global search for the word in any standard configuration Data exchange, you will see a lot of links to it. Both in general modules and in modules of directories, documents, registers, etc. Let's consider what this property is and what it is used for.

Short review

If you open a branch in the syntax assistant Application objects, you will find that many of them: DirectoryObject, DocumentObject, for registers Set of Records etc. there is a property Data exchange.

The type of this object is: Data Sharing Options, which in turn contains three properties

Sender

Recipients

These properties are used in the exchange process between nodes distributed information base . In property Sender a link to the node in which the object was changed is stored. Recipients contains a set of exchange plan nodes into which changes will be uploaded. If some non-standard actions are necessary when exchanging data between databases and the sender, the composition of the set of nodes can be changed programmatically. But I would like to dwell on the third property in more detail.

Property Data Exchange.Load

If this property is set to True, this indicates that an object received through data exchange mechanisms is being written. This assumes that the object contains correct data and the 1C platform performs a minimum number of checks. But very often when recording an object, a lot of things are done program checks in predefined procedures of an object module. And this code is also executed when writing an object received from the exchange file. And in this case, errors may occur, for example, due to the fact that the data being checked is simply not recorded yet.

Therefore, very often in object modules you can find the following code:

Procedure Before Recording (Rejection) If Data Exchange Return ; EndIf ; //Here is the code with data verification End of Procedure

This allows you to avoid unnecessary checks when exchanging data between databases. Of course, if some code must be executed in any case, it must be placed before checking the property. This point must be taken into account when designing new metadata objects if you have a distributed database and the new object is involved in the exchange.

On the other hand, the presence of such code allows the developer to illegally bypass data verification when program recording object, because The property is writable too. For example, using this code:

NewProduct = Directories. Goods. CreateItem() ; New product. Name = "Recording test"; New product. DataExchange True ; New product. Write() ;

And in some exceptional situations this can really help as a temporary measure. But you should not abuse this.

What is Data Exchange.Load = True, how to use Data Exchange.Load.

Data Exchange.Loading is an attribute of any object in the 1C Enterprise system. It allows you to indicate when recording an object that it is necessary to disable any checks (including checks at the 1C platform level). This was done in order to avoid conflicts during data exchange.

If you are developing your own configuration, in all data correctness checks (for example, the BeforeWrite procedure), you must add the following line as the first line:

Get 267 video lessons on 1C for free:

This is good form among 1C developers.

Record control in standard 1C processing

If you have ever used standard ones (for example, Search and replace values, Group data processing, Universal data exchange, etc.), you probably noticed a setting that is usually called “Write Control”. This setting is responsible for turning on/off the “Data Exchange.Download” attribute.

How to set the Data Exchange mode Download

It is very convenient to use this attribute in program code, to disable all checks. For example, this attribute is necessary if you need to record an object, but it has unfilled required details. This can also be used as a way to increase the speed of bulk data processing - if you disable all checks, the system writes the object faster.

Automated systems In most cases, management systems consist of separate databases and often have a geographically distributed structure. At the same time, correctly implemented data exchange is a necessary condition for efficient work such systems.

The initial setup of the exchange may require a number of actions, not only in terms of programming, but also consulting, even if we are dealing with homogeneous sources, as is the case with products on the 1C:Enterprise platform. Why setting up 1C exchange (or, as it is also called, data synchronization in 1C 8.3) can become the most time-consuming and expensive task of an integration project, we will look at in this article.

Data exchange in the 1C environment allows you to:

• Eliminate double entry of documents;
• Automate related business processes;
• Optimize interaction between distributed departments;
• Promptly update data for the work of specialists from different departments;
• "Delimit" different types accounting.*

*In cases where the data of one type of accounting differ significantly from another, it is necessary to ensure the confidentiality of information and “delimit” information flows. For example, data exchange between 1C UT and 1C Accounting does not require uploading management data into the regulatory accounting database, i.e. synchronization in 1C will be incomplete here.

If we imagine the standard process for implementing primary data exchange, when at least one of its objects is a 1C product, then we can distinguish the following stages:

• Coordination of the composition of the exchange;
• Definition of transport (exchange protocols);
• Setting rules;
• Scheduling.

Identification of the composition of 1C exchange

Objects of exchange can be divided into “source” and “receiver”. At the same time, they can perform two roles at the same time, which will be called a two-way exchange. The source and destination are determined logically depending on the need or functionality systems.*

*For example, when integrating “WA: Financier” - a solution for maintaining financial accounting and managing treasury processes, developed on the basis of “1C:Enterprise”, WiseAdvice experts recommend it as a master system. This is due to the availability of control tools to comply with the rules of the application policy, and, accordingly, to ensure the effectiveness of the solution.

Next, based on the received and recorded requirements from users, a list of data for exchange is created, its volume, requirements for the frequency of exchange are determined, and the process of working with errors and handling exceptional situations (collisions) is prescribed.

At the same stage, depending on the fleet of existing systems and the structure of the enterprise, the exchange format is determined:

Distributed information base

• RIB implies an exchange between identical configurations 1C databases, with a clear “master-slave” management structure for each exchange pair. As an element of a technology platform, RIB, in addition to data, can transmit configuration changes and administrative information of the database (but only from master to slave).

Universal data exchange in 1C

• A mechanism that allows you to configure the exchange of 1C databases, both with configurations on the 1C:Enterprise platform and with third-party systems. The exchange is carried out by transferring data into a universal xml format in accordance with the “Exchange Plans”.

EnterpriseData

• The latest development of 1C, designed to implement data exchange in xml format between products created on the 1C:Enterprise platform with any automation systems. The use of EnterpriseData simplifies the modifications associated with the exchange. Previously, when a new configuration was included in a system, it was necessary to implement a mechanism for importing and exporting data, both for it and for existing systems. Now systems that support EnterpriseData do not need any modifications, having only one entry-exit point.

Definition of transport (exchange protocols)

The system on the 1C:Enterprise 8 platform provides a wide range of possibilities for organizing exchange with any information resources through generally accepted universal standards (xml, text files, Excel, ADO connection, etc.). Therefore, when determining the transport for exchange data, you should rely on the database capabilities of the third-party system.

Synchronization of directories

The basic principle of effective synchronization of directories is the presence of a single entry point. But if we are talking about working with directories that have historically been filled out according to different rules, it is necessary to clearly define synchronization fields to bring the exchange to a “common denominator.”*

*At this stage, it may be necessary to carry out work to normalize the reference data on the side of the data source. Depending on the state of the directories and their volume, the process of comparing elements, recognizing, identifying errors and duplicates, as well as filling in missing fields and assigning synchronization fields, may require the work of a whole group of experts, both on the part of the integrator (the owner of the master data normalization technique) and from the customer's side.

Setting rules

The ability to display data from source systems in receivers depends on correctly defined exchange rules. The rules, presented in xml format, regulate the correspondence of key details of source-receiver objects. The 1C:Data Conversion solution is designed to automate the creation of rules for implementing both one-time and permanent exchanges.

Guarantees no data loss during exchange Exchange Plan. This component any configuration on the 1C:Enterprise platform, fully describing the procedure for 1C exchange: data composition (documents with “identifying” details) and nodes (receiver-transmitter information bases), as well as activation of RIB for selected exchange directions.

Any change in the data entered into the Exchange Plan is recorded and receives the “changed” sign. Until the changed data matches each other in the receiver-transmitter nodes, the sign will not be reset, and the system will send control messages to both nodes. After uploading the data and confirming their full compliance in both systems, the sign is reset.

Exchange schedule in 1C

To automate regular exchange, the frequency of data uploading is set. The frequency of exchange depends on the need and technical capabilities. Also, configurations on the 1C:Enterprise platform allow you to configure data exchange when an event occurs.

Having considered the standard process of implementing an exchange, let’s pay attention to factors that will require improvements at different stages:

• Non-standard, highly modified database configurations;
• Different versions platforms "1C:Enterprise";
• Not updated for a long time, not current versions configurations;
• Objects of exchange that have previously undergone modifications;
• The need for non-standard exchange rules;
• A very different set and composition of details in existing reference books.

Since even standard actions to implement primary data exchange require expert knowledge, they are recommended to be carried out with the participation of 1C specialists. Only after completing all the steps described above should you proceed to setting up the exchange in the configuration. Let's look at the integration of databases using the example of 1C:UPP and 1C:Retail (exchange with 1C:UT is set up using the same scheme). Also included in standard synchronization is the SCP - SCP exchange, which is typical for large-scale automation systems at the largest industrial enterprises.

In the “Service” submenu, select “Data exchange with products on the platform...” (selecting direct exchange with “Retail” often results in errors at the level of COM objects). Let's pay attention to the service message " This opportunity not available."

To resolve this issue, you need to select "Configure Communications"

...and check the box. Next, ignore the error message.

In the data synchronization settings, select “Create an exchange with “Retail”...

Before configuring connection settings through a local or network directory, you should make sure that there is space on the disk for the directory. Although, as a rule, it does not take up more than 30-50 MB, in exceptional cases it may require up to 600 MB. You can create the required directory directly from the configurator.

When connecting via a network directory, you are prompted to configure the connection using an FTP address and e-mail ignore by clicking “Next”.

In the settings we manually enter prefixes - symbols databases (usually BP, UPP, RO), we set the rules and the start date for downloading the data. The prefix will be indicated in the name of the documents to indicate the database in which they were created. If the upload rules are not edited, the data will be uploaded by default according to all available parameters.

We create an exchange settings file for “Retail” so as not to repeat our actions. If you need to immediately send data immediately after setting up synchronization, check the box.

To automate the exchange process, you need to set up a schedule.

Menu "Retail".

Check the box and select “Synchronization”.

We perform the “reverse” setup by selecting Production Enterprise Management.

Load the settings file created in UPP.

We put a tick, the system picks up the address automatically.

We act in the same way as in UPP.

Verification data comparison (Manual data comparison is recommended to be done at the preparatory stage, since this work can become the most labor-intensive in the process of implementing the exchange). The comparison window opens by double click mice.

In case of an error in synchronization, “Details...” will be replaced with “Never...”.

“Details...” opens the log with updated information on the exchange.

Ready.

Textbook on 1C Data Conversion (edition 2) Optimization

Data Upload Rules

1. Order of data upload rules

It is recommended to arrange data upload rules in such an order that the links of dependent objects are from bottom to top. that is, the rules for unloading data whose objects do not refer to anyone should be placed first, followed by the rules for unloading objects that refer to the first group, etc.

Example: You need to download two directories Users and Individuals. Directory Users has the requisite Physical. person - link to the directory Individuals. That is, the Users directory refers to the Individuals directory. The recommended sequence of upload rules in this case: Individuals, users.

2. Select data for uploading in one request

If there is no carryover in the conversion rule tabular parts and movements, as well as in events before unloading there are no direct calls to the object being unloaded, it is recommended to use the “Select data for unloading in one request” mode in the data unloading rule. This mode will allow you to receive all uploaded data of a certain type with one request, rather than building separate queries to upload each object.

Object Conversion Rules

3. Use quick search while loading

This mode of unloading and loading is recommended to be used for those object conversion rules that unload reference types, the total number of which is relatively small (up to approximately 1000 elements), to which there are many references in other objects.

Example: Directory Users. Almost all documents have a link to this directory and the number of elements in the directory does not exceed 1000.

4. Do not unload property objects by reference

The mode allows for the object conversion rule not to unload all elements to which there are links. If the mode is set, then when unloading the object itself and information for searching all its links will be unloaded, but complete information about dependent elements will not be unloaded. This optimization can speed up the upload and download of data several times.

5. Don't remember unloaded objects

For conversion rules for non-reference objects (registers), you need to check the "Do not remember unloaded objects" checkbox, since you cannot refer to register lines, so there is no point in remembering those register lines that have been unloaded. For reference objects, this flag is usually needed to optimize repeated access for unloading the same object.

6. Do not create common event handlers for all objects

It is not recommended to use common event handlers before uploading and loading data for all objects. The upload and download handlers do not know what will be executed in these handlers, so some optimizations (for example, when loading only writes changed objects) will not take effect. If there is a need to use the same data processing algorithms when unloading and loading, then it is recommended to create a new Algorithm and call it in events for the necessary objects.

Universal XML Data Interchange processing

7. Use an optimized format for data exchange

8. Upload data in exchange mode

Allows you to avoid unnecessary checks at the data loading stage

9. Record only changed objects

Allows you to record only changed objects to the infobase. If the object has not been changed, then when loading from the exchange file it will not be overwritten.

10. Optimized object recording

The mode allows you to sharply reduce the number of hits in the infobase for recording objects.

11. Write registers with sets of records

The mode allows register changes to be written by record sets rather than record managers.

12. Data exchange via COM

For V8-V8 exchange, if the source and receiver information bases are within the same local network, it is recommended to use exchange via a COM connection. It is only necessary that Universal Data Exchange processing be present in the receiver configuration.

Sincerely, Vladimir Milkin(teacher and developer

Last modified: 09/01/2015

Select clarification:

Universal Data Interchange is designed to upload and download data to a file in XML format between different 1C configurations according to configured exchange rules.

Nomenclature, barcodes, fixed assets, etc. will be loaded from standard 1C configurations into the Cleverens: Property Accounting database, and vice versa, from the Cleverens: Property Accounting database, inventory, nomenclature, divisions, etc. will be uploaded to the working client database.

Operating mode

Processing has two operating modes:

On the client. When using this mode, the rules and download data files are transferred from the client to the server, and the download data file is transferred from the server to the client. The paths to these files located on the client must be specified in the dialog box immediately before performing the action.

On server. In this mode, files are not transferred to the client and the paths to them must be specified on the server.

The external processing file and exchange protocol files must always be on the server, regardless of the operating mode.

Uploading data

Data upload procedure:

1. select the exchange rules - indicate XML file exchange rules, each 1C configuration has its own rules (will be gradually added to the Cleverence: Property Accounting assembly);
2. read the exchange rules;
3. after reading, the uploaded data will be filled in, you can specify which objects will be uploaded;
4. select an XML file (you can create an empty file - specify the file name and it will be created automatically) into which the data or receiver infobase will be loaded;
5. upload data.

Uploading to an exchange file.

Specify the name of the file into which the data will be uploaded. The resulting file with the downloaded data can be compressed.

Connecting and uploading data to the information security receiver.

Select the type of information base:

• On this computer or on a computer on a local network;
• On the 1C:Enterprise server.

We select the 1C platform and the information base directory to connect to.

On the “Uploaded data” tab, you can select the types of objects that should be uploaded, set up selections for selecting objects, or specify the data exchange node for which you want to upload data.

On the “Upload Options” tab, you can specify Extra options data upload.

On the “Comment” tab, you can write arbitrary comment text to be included in the exchange file.

To download data, you must specify the name of the file from which the data will be downloaded; if you entered a password for compression during upload, you must specify it for decompression.

• “Use transactions” - the ability to configure the loading of data into transactions (a transaction is a logically related, indivisible sequence of actions). To do this, you need to check the “Use transactions” checkbox and specify the number of elements in one transaction when loading.
• “Load data in exchange mode” (Data Exchange.Load = True) – if the flag is set, then loading of objects will be performed with the download flag set. This means that when objects are written to the database, all platform and application checks will be disabled. The exception is for documents that are recorded in the posting or cancellation mode. Posting and canceling the posting of a document is always performed without setting the loading mode, i.e. checks will be performed.
• “Write only changed objects to the infobase” – if the flag is set, then only changed objects are written to the infobase. If the object has not been changed, then when loading from the exchange file it will not be overwritten.
• “Download objects from the link without a deletion mark.”
• “Optimized recording of objects” – if the flag is set, a mode is activated that allows you to sharply reduce the number of hits in the infobase for recording objects.
• “Write registers with record sets” – if the flag is set, then a mode is enabled that allows changes in registers to be written by record sets, rather than by record managers.
• “Trim lines on the right” – if the flag is set, then when loading lines, spaces on the right are trimmed.
• "Settings automatic download data" - allows you to configure the use of automatic loading (use, not use, ask a question before performing the operation).

"Boot handler debugging mode" is recommended for use by developers only!

Additional settings

The bookmark is used for detailed settings uploading and downloading data.

• “Debug mode” – flag for setting the exchange debugging mode. If this flag is set, the data exchange process will not be stopped if any error occurs. The exchange will be completed and debug messages will be output to the exchange log file. This mode is recommended to be used when debugging exchange rules.
• "Conclusion information messages to the message window” – if the flag is set, the protocol of the data exchange process will be displayed in the message window.
• “Number of processed objects for status update” – the parameter is used to determine the number of processed elements before changing the loading/unloading status line
• “Data upload settings” - allow you to determine the number of elements processed in one transaction when uploading data, upload and process only those objects for which you have access rights, configure the type of registration change for uploaded objects through exchange plans.
• “Use an optimized format for data exchange (V8 - V8, processing version no lower than 2.0.18)” – the optimized exchange message format assumes the presence of an “InformationOnDataTypes” node in the message header, into which information about data types is uploaded. This allows you to speed up the data loading process.
• “Use transactions when unloading for exchange plans” – the flag determines the mode of using transactions (a transaction is a logically related, indivisible sequence of actions) when unloading data when selecting changes on nodes of exchange plans. If the flag is set, then data upload will be performed in a transaction.
• Number of Items Per Transaction—Determines the maximum number of data items that can be placed in a message within a single database transaction. If the parameter value is 0 (the default value), then all data is placed within one transaction. This mode is recommended because it guarantees the consistency of the data included in the message. But when you create a message in multi-user mode, there may be lock conflicts between the transaction that is putting the data into the message and transactions performed by other users. To reduce the likelihood of such conflicts, you can set this parameter to a value other than the default. The lower the value of the parameter, the lower the likelihood of a lock conflict, but the higher the likelihood of putting inconsistent data in the message.
• “Unload objects for which there are access rights” – if the flag is set, then the selection of infobase objects will be performed taking into account the access rights of the current user of the program. This involves using the literal "ALLOWED" in the query body to retrieve the data.
• “Automatically remove invalid characters from strings for writing in XML” – if the flag is set, then when writing data to an exchange message, invalid characters will be removed. Characters are checked against the XML 1.0 recommendation.
• “Registration changes for exchange nodes after uploading” – the field determines the mode of operation with registration of data changes after completion of data upload.
  Possible values:
  Do not delete registration – after uploading the data, registration of changes on the node will not be deleted.
  Completely delete registration for the exchange node - after uploading the data, registration of changes on the node will be completely deleted.
  Remove registration only for downloaded metadata – after downloading the data, registration of changes on the node will be deleted only for metadata objects that were specified for download.
• “Exchange protocol” – allows you to configure the output of information messages to the message window, maintaining and recording in separate file exchange protocol.
• “File name, exchange protocol” – file name for outputting the protocol of the data exchange process.
• “Download protocol (for COM connection)” – file name for outputting a protocol of the data exchange process in the receiving base when exchanging via a COM connection. Important: the path to the file must be accessible from the computer on which the receiving base is installed.
• “Append data to the exchange protocol” – if the flag is set, the contents of the exchange protocol file are saved if the protocol file already exists.
• “Output information messages into the protocol” – if the flag is set, then informational messages will be output to the exchange protocol, in addition to messages about exchange errors.
• “Open exchange protocol files after performing operations” – if the flag is set, then after data exchange is completed, exchange protocol files will be automatically opened for viewing.

Deleting data

Bookmark needed only for developers exchange rules. Allows you to delete arbitrary objects from the infobase.