>

1s data loading mode is true. Universal Data Exchange

Last modified: 09/01/2015

Select clarification:

Universal data exchange is intended for loading and unloading data into 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 - specify the XML file of the exchange rules, each 1C configuration has its own rules (will gradually be added to the Cloverens: 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 IS receiver.

Select the type of information base:

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

We select the 1C platform and the information base directory for connection.

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 additional parameters for 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, a mode is enabled that allows changes to 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.
  • “Setting automatic data loading” - 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 tab is used for detailed configuration of data upload and download.

  • “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.
  • “Output information messages in the message window” – if the flag is set, then 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 parameter value, the lower the likelihood of a lock conflict, but the higher the likelihood of inconsistent data being included in the message.
  • “Unload objects for which you have 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 downloading 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 uploaded metadata - after uploading the data, registration of changes on the node will be deleted only for metadata objects that were specified for upload.
  • “Exchange protocol” – allows you to configure the output of information messages in the message window, maintenance and recording of the exchange protocol in a separate file.
  • “File name, exchange protocol” – the name of the file to output 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 receiver 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.

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 SetRecords 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 any 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 writing an object, many program checks are made in the predefined procedures of the 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

    EndProcedure

    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 writing an object programmatically, because The property is writable too. For example, using this code: NewProduct = Directories. Goods. CreateItem() ; New product. Name =

    "Recording test"

    ;

    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;
    • “Differentiate” between different types of 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 the functionality of the system.*

    *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 exchange between identical 1C database configurations, with a clear “master-slave” control 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)

    For the system on the 1C:Enterprise 8 platform, a wide range of possibilities is provided for organizing exchange with any information resources using 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 is an integral part of any configuration on the 1C:Enterprise platform, which fully describes the 1C exchange procedure: data composition (documents with “identifying” details) and nodes (receiver-transmitter information bases), as well as 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 of the 1C:Enterprise platform;
    • Configuration versions that have not been updated for a long time;
    • 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). Please note the service message “This feature is 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, we ignore the offer to configure the connection via an FTP address and by email by clicking “Next”.


    In the settings, we manually enter prefixes - symbols of the databases (usually BP, UPP, RO), set the rules and the start date for data upload. 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 clicking the mouse.



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


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


    Ready.

    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 “Record 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.