Menu
homeBrowsers

Exchange through a universal format. Automatic data exchange using the "Universal XML Data Exchange" processing, without changing the configuration

In almost all 1C 8 configurations, there are predefined exchanges between other standard releases, for example with: "1C Trade Management 8", "1C ZUP 8", "1C Retail 8". However, what if you need to exchange between different configurations with completely different metadata structures? In this case, the processing “Universal Data Interchange in XML Format” will help, which can be downloaded free of charge for and

To work with these processing, we need a rules file in xml format. It describes exactly how data from one information base is transferred to another. It is created using a specialized “Data Conversion” configuration, which is supplied on disk or on the ITS website. We will look at how to create it in the next article, but for now let’s imagine that we already have it. There are 4 tabs in processing. Let's look at them all in order:

Uploading data

  • First of all, we indicate the name of the rules file on the basis of which the upload will take place.
  • Specify the name of the data file in which all information will be saved.
  • You can check the box: compress the received file or not.

After the rules file has been specified, the “Uploaded data” tab will display the metadata objects for which the data will be saved. Here you can also specify the period for which the sampling will take place. In the “Upload Options” tab, you can specify additional values ​​accordingly. The comment tab speaks for itself

Loading Data

In this tab, only the data file is indicated, since all the rules are already in the uploaded file along with the data. Here you can set the number of elements that will be downloaded in one transaction. There are additional Boolean options on the form, based on which the loading will occur. If you want all the built-in checks to be disabled when performing processing, then select the item Setting up automatic data loading speaks for itself.

Additional settings

The additional settings tab allows you to fine-tune the processing execution

  • Debug mode allows you to not stop the upload or download procedure if any unexpected error occurs. After completing the operation, a detailed report will be displayed.
  • To monitor the exchange process, you can check the “Output information messages” checkbox.
  • Number of processed objects for status update - determines the number of processed elements after which the information in the information window will be updated.
  • “Use an optimized format for data exchange (V8 - V8, processing version no lower than 2.0.18)” is a specialized format that requires the “Information ON Data Types” tag in the message header, which speeds up the execution process.
  • Use transactions when unloading for exchange plans – when this flag is set, the unloading will be performed in one transaction (an indivisible, logically connected sequence)
  • Number of elements in a transaction - determines the number of elements that will be uploaded/loaded in one transaction. If set to 0, then the entire procedure will take place in one transaction. This option is recommended, since the guarantee of logical data connectivity will remain.
  • Upload objects for which there are access rights - a flag based on which objects are determined for unloading to which the current user has access rights.
  • Automatically remove invalid characters from strings for entries in XML – when this item is set, all entries in the message are checked for XML 1.0 validity and characters that do not comply with the standard are removed.
  • Registration changes for exchange nodes after uploading – defines the method of working with registration of data changes after the end of data uploading (do not delete registration, completely delete registration, delete registration only for downloaded metadata).
  • Exchange protocol file name—specify the file name for logging the exchange procedure.
  • Download protocol (for COM connection) - the name of the log file when exchanging via a COM connection.
  • Append data to the exchange protocol—when this flag is set, the log file will be appended rather than overwritten.
  • Output of information messages to the log - not only information about errors, but also information messages will be added to the log file.
  • Open exchange protocol files after performing operations - the flag speaks for itself

Deleting data

Processing Universal Data Interchange in XML format (processing Universal Data Exchangexml)

Processing "Universal data exchange in XML format" is intended for loading and unloading data into a file from any configuration implemented on the 1C:Enterprise 8 platform.

Operating mode
When using a managed form, processing has two modes of operation:
1. 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.
2. On the server. In this mode, files are not transferred to the client and the paths to them must be specified on the server.
Note: The external processing file and exchange protocol files must always be located on the server, regardless of the operating mode.

Download Universal Data Interchange in XML format- Only registered users can download files!


Processing has four tabs

Uploading data
To upload data, you must specify the name of the file into which the data will be uploaded and select the exchange rules file. Exchange rules for any configuration can be configured in the specialized configuration "Data Conversion, Edition 2".

To upload documents and records from independent periodic information registers, you must specify the period - “Start Date” and “End Date”. The resulting file with the downloaded data can be compressed.

On the "Rules for uploading 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.

It is possible to configure the loading of data into transactions. To do this, you need to select 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 loading 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.

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 when unloading data when fetching changes on exchange plan nodes. If the flag is set, then data upload will be performed in a transaction.

"Number of items per transaction" - defines the maximum number of data items that are 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 display of information messages in the message window, maintenance and recording of the exchange protocol in a separate file.

“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, then the contents of the exchange protocol file are saved if the protocol file already exists.

“Output informational messages to 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 the exchange protocol files will be automatically opened for viewing.

Deleting data
The bookmark is needed only for developers of exchange rules. Allows you to delete arbitrary objects from the infobase.

Debugging data upload and download
Processing allows you to debug event handlers and generate a debug module from a rules file or data file.

Enabling the debug mode for upload handlers is done on the "Data Upload" tab by checking the "Debug mode for upload handlers" checkbox. Accordingly, on the “Data Loading” tab, the loading debugging mode is enabled by checking the “Load handlers debugging mode” checkbox.

After setting the debugging mode for handlers, the debugging settings button will become available. Clicking this button will open a settings window.

Setting up debugging handlers is performed in four steps:

Step 1: Selecting the algorithm debugging mode

At the first step, you need to decide on the algorithm debugging mode:

No algorithm debugging
Call algorithms as procedures
Substitute algorithm code at the place of call

The first mode is convenient to use when we know for sure that the error in the handler is not related to the code of any algorithm. In this mode, the algorithm code is not uploaded to the debugging module. Algorithms are executed in the context of the "Run()" operator and their code is not available for debugging.

The second mode must be used in cases where the error is in the algorithm code. When this mode is set, algorithms will be unloaded as separate procedures. At the moment the algorithm is called from any handler, the corresponding processing procedure is called. This mode is convenient to use when the global variable "Parameters" is used to pass parameters to algorithms. The limitations of using this mode are that when debugging the algorithm, the local variables of the handler from which it is called are not available.

The third debugging mode is used, as in the second case, when debugging algorithm code and in cases in which the second debugging mode is not suitable. When this mode is set, the algorithms will be unloaded as integrated code in handlers. Those. Instead of the algorithm call operator, the full code of the algorithm is inserted, taking into account nested algorithms. In this mode there are no restrictions on the use of local handler variables, but there is a restriction when debugging algorithms with a recursive call.

Step 2: Formation of the debugging module

In the second step, you need to unload the handlers by clicking on the “Create unloading (loading) debugging module” button. The generated handlers and algorithms will be displayed in a separate window for viewing. The contents of the debugging module must be copied to the clipboard by clicking on the "Copy to clipboard" button.

Step 3: Create External Processing

At this step, you need to launch the configurator and create a new external processing. You must paste the contents of the clipboard into the processing module (debugging module) and save the processing under any name.

Step 4: Connecting External Processing

At the fourth and final step, you must specify the name of the external processing file in the input field. In this case, the program checks the time of creation (update) of the processing file. If the processing has an earlier version than the version of the debugging module file, a warning will be displayed and the configuration form will not be closed.

Note: The ability to debug the global conversion handler "After loading exchange rules" is not supported.

When maintaining several working 1C databases, sometimes there is a need to exchange data between them. There are 2 ways to transfer data:

  1. Data transfer using the exchange and processing rules “XML Data Exchange”. Exchange rules are created using the 1C:Data Conversion configuration.
  2. Transferring data between similar infobases using the “Uploading and loading XML data” processing.

Let's consider the second option, i.e. uploading and loading data from/to configurations that contain the same (identical) objects we need. To do this, we will use the external processing “Uploading and loading XML data”, which can be used.

The condition for using this processing is as follows: The information base from which data is downloaded must contain the same objects and with the same details (name and data type) as in the database into which the data is loaded.

Let's consider an example with data transfer using this processing. Suppose you need to transfer the documents “Incoming payment order” and “Outgoing payment order”. The solution to this problem will be as follows.

We open the external processing “Uploading and loading XML data” through the main menu: File? Open... On the “Upload” tab we specify the XML file into which we will save the data.

Then you need to specify the period for which we will unload data objects from the 1C database and the objects themselves. We mark the documents we need for uploading with a tick in the configuration object structure field in the “Data for uploading” column. If the uploaded documents contain links to directory elements that are not in another configuration, then it makes sense to check the boxes in the “If necessary” column so that these elements are also uploaded along with the documents.

Now at this step you need to decide whether to upload their movements along the registers along with the documents or transfer these documents to another database? To re-post uploaded documents in another database, you can use the “Group processing of directories and documents” processing. If the processing algorithms in these information databases differ in some way, then the checkbox next to “Upload all its movements with the document” should not be checked.

That's it, the upload setup is complete, everything is simple here! Click the “Upload data” button and wait until the data is saved to an XML file. For more complex unloadings, you can specify selection for unloaded objects not only by period.

After unloading, go to the second 1C database and open the same processing there. Go to the “Download” tab and indicate here the same XML file into which we uploaded the data.

On this tab, check the box next to “Continue loading objects if an error occurs” and click on the “Load data” button. We do not consider other functions, for example, the use of totals, although this function can significantly speed up the loading of objects (records by registers).

Automated control systems in most cases consist of separate databases and often have a geographically distributed structure. At the same time, correctly implemented data exchange is a necessary condition for the effective operation of 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;
  • “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 from 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 COM object level). 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.

Quite often in the work of large enterprises and retail chains there is a need to exchange data between databases. Each programmer and administrator solves this issue differently. Some write uploads and downloads through intermediate table files, others use COM connection mode to connect to the source database. However, recently 1C’s own mechanism called “Universal Data Exchange in XML Format” has become increasingly popular.

Appearance of processing

In the Full interface, you can open processing at Service->Other data exchanges->Universal data exchange in XML format.

The processing form (Fig. 1) contains four tabs:

  • Additional settings;
  • Deleting data.

    • The interface of each of the bookmarks is heavily loaded with elements and therefore requires separate consideration.

    Uploading data

    At the very top of the tab there is a field for selecting an exchange rules file. For non-standard databases and exchanges, you will have to create the exchange file yourself.

    On the next line of the form there are two radio buttons:

    1. Uploading to an exchange file (Fig. 2);
    2. Connecting and uploading data to information security (Fig. 3).

    As you can see from the pictures above, the appearance of the form differs depending on the switch. If the file sharing option is selected, the user is prompted to select the location of the file where it will be uploaded and the possibility of compressing it to save space and protect it with a password.

    The option of direct connection to the receiving base supports both file and client-server modes of operation. In this case, you will need to enter the database address and fill in the “User” and “Password” fields. Before you start exchanging data, it is advisable to test the connection.

    The tabular section below allows you to configure selections and other unloading parameters.

    To debug algorithms and correct errors, you can use the mechanism built into exchange processing. It is activated by checking the corresponding checkbox at the bottom of the form. Clicking on the “Debugging settings…” button brings up a window (Fig. 4).

    Fig.4

    A distinctive feature of this form is the informative help on the left side of the layout, which describes each of the three possible debugging modes. Any file in the epf format can serve as an external processing file for the module.

    Clicking on the “Finish” button checks the correctness and completeness of the filled in data.

    Unlike “Upload”, this tab (Fig. 5) does not have a tabular part, but there are many more checkboxes that allow you to adjust the parameters for recording new and changed objects.

    Fig.5

    First of all, you need to select a file that will serve as a source of information. This can be done in the “File name to upload” input field. If the data was uploaded to a password-protected archive, it will need to be entered in the appropriate field.

    The corresponding checkboxes allow you to configure:

    • Transaction when writing objects (this sometimes speeds up the process);
    • Loading data in exchange mode (in this case, all platform checks, with the exception of checking when posting documents, will be ignored when recording);
    • Overwriting changed elements;
    • Setting a deletion mark for downloaded items;
    • The mode of writing new data to the register (either one at a time or in a set);
    • Trimming of insignificant characters (spaces and tabs) for string values.

    Additional settings

    As the name of the bookmark implies, it contains tools the use of which allows you to more accurately customize the exchange process. In particular:

    1. Enables debugging mode;
    2. Allows the use of a transaction during the unloading process;
    3. Optimizes exchange between databases of version 8 of 1C;
    4. Upload only those objects that are allowed for use by the current user;
    5. Enable logging of the exchange process between databases.

    These and some other functions are enabled by checking the appropriate boxes on the form (Fig. 6).

    Fig.6

    Deleting data

    This tab is only used by developers in debug mode. Allows you to remove unnecessary objects from the database.

    Briefly about setting up exchange rules

    Using a standard handler greatly simplifies life for programmers. At the same time, one of the most difficult moments for someone who first encountered “Universal Data Interchange in XML Format” is the question: “Where can I get the exchange rules file?”

    First of all, to independently create exchange rules, you need a special configuration called “Data Conversion”. It contains several interesting files that allow you to configure almost any exchange between various 1C databases 7 and 8 versions:

    1. epf – required for downloading the metadata structure for 1C 8 databases;
    2. epf – if the 1C 8 configuration is self-written or not standard, it may not have the “Universal Data Exchange” processing, this file is this processing;
    3. ert – file contains code for downloading the metadata structure of configurations of 1C versions 7.7;
    4. ert – file for processing data upload and download for the seven.

    Having launched the appropriate processing, it is necessary to unload the metadata structures for the source and destination databases. Then, in the “Conversion” configuration, you need to enter information about the source and destination configurations into the “Configurations” directory.

    Then an element is created in the Conversion directory containing information about the direction of data exchange. You can set up Exchange Rules for it.