1c universal data exchange in xml format. Automatic data exchange using the "Universal XML Data Exchange" processing, without changing the configuration. Distributed information base

Print (Ctrl+P)

Exchange via a universal format

The “Data Exchange” subsystem of the library of standard subsystems contains 4 options (technologies) for information exchange between various information bases:

• distributed information bases (RIB);
• data exchange through a universal format;
• data exchange according to exchange rules (exchange rules are created using the “Data Conversion” configuration, edition 2.1);
• data exchange without exchange rules.

This article discusses the technology of data exchange through universal EnterpriseData format. This technology available in the “Standard Subsystems Library” starting with version 2.3.1.62. released in early 2016. Currently, the latest edition of BSP 2.3 (for use with the 1C:Enterprise 8.3 platform no lower than version 8.3.8.1652 with compatibility mode disabled) has release 2.3.6.17.

Rice. 1 Latest releases of BSP 2.3

Among the delivery files for 1C application solutions there is text file“Library versions”, where it is written on the basis of which version of the BSP the application was developed, for example, based on the application solution UT 11.3.3.231, BSP 2.3.5.65 was formed.

Please note that for use with the “1C:Enterprise 8.3” platform version no lower 8.3.10.2168 edition was released with compatibility mode disabled BSP 2.4.

Description of the EnterpriseData format

What is the EnterpriseData format?

This is a format that allows you to describe an information base object (counterparty, invoice, etc.) or report the fact that this object has been deleted. It is expected that the configuration that receives the file in the EnterpriseData format will react accordingly - it will create new objects and delete those that are marked as deleted in the file. It is intended for information exchange between UT, RT, UNF, BP configurations. The format can also be used to exchange information with any other information systems: it does not depend on the characteristics of its own software or information base structures that participate in the exchange and do not contain explicit restrictions on use.

EnterpriseData format version

The format data is stored in XDTO packages in the general database configuration branches, as shown in Fig. 2

Fig. 2 XDTO – EnterpriseData data format packages

In Fig. 2 shows that there are several XDTO packages. This different versions format. The format version number consists of X.Y.Z, where X.Y is the version, Z is the Minor version. The Minor version is increased in case of bug fixes and other changes in which: the functionality of the data conversion logic based on previous version format (saving backward compatibility current algorithms for transmitting data through the format); Support for new format capabilities for conversion logic is voluntary. An example of such changes could be correcting an error, changing the properties of format objects, adding properties whose use is not mandatory when converting data. In other cases, when the format changes, the Major version increases: X – in the case of global restructuring, Y – in other cases.
The format describes the representation of objects (documents or directory elements) in the form of XML files. Version 1.0.1 contains a description of 94 objects from various areas (finance, production, purchasing and sales, warehouse operations). The names of the types, as a rule, are well understood and do not need additional explanations: for example, “Document.Act of Completed Work” or “Directory.Counterparties”. As you can see, the description of document types begins with the prefix “Documentary.”, and the directory element begins with the prefix “Directory.”. A more detailed description of the format can be found
The latest version is 1.3, however, the most commonly used version is 1.0. There isn't much difference between the versions. Format EnterpriseDataExchange_1_0_1_1 used when exchanging via a web service.
Note that that the EnterpriseData data format package is used together with ExchangeMessage when creating conversion rules. It is this package that contains the type object AdditionalInfowhich can have any value type and is used when creating a conversion rule between configuration objects. that are not in the data format. Exactly, thanks AdditionalInfoYou can adapt and customize exchange rules without changing the format data in XDTO packages.

Rice. 3 Structure of the XDTO packageExchangeMessage

How to exchange data in EnterpriseData format?

Exchange of data in EnterpriseData format with configuration is a file exchange. In response to the file received from the external application, the configuration will process it and create a response file. Files can be exchanged:

• via a dedicated file directory,
• via FTP directory,
• through a web service deployed on the infobase side. The data file is passed as a parameter to web methods.

Note. For two-way data exchange between a third-party application and the configuration on the infobase side, a number of settings must be made - the third-party application must be registered in the infobase, an exchange channel must be defined for it (via a file or FTP directory), etc. But for cases of simple integration, when it is enough to only transfer information from third party application into the infobase and reverse transfer of data from the infobase to a third-party application is not required (for example, integration of an online store that transfers sales information to 1C: Accounting); there is a simplified version of working through a web service that does not require settings on the side.

When exchanging using exchange plans, configurations during synchronization transmit only information about changes that have occurred since last synchronization(to minimize the amount of information transmitted). The first time you sync, the configuration will dump all EnterpriseData formatted objects into an XML file (since they are all “new” to the third party application).

The next step is for the third-party application - it must process the information from the XML file and place it in the section during the next synchronization session information that a message from the configuration with a certain number was successfully received (place the number of the message received from the configuration in the ReceivedNo field). The receipt message is a signal to the configuration that all objects have been successfully processed by the external application and there is no need to transmit information about them anymore. In addition to the receipt, the XML file from a third-party application can also contain data for synchronization (in the section ).

After receiving the receipt message, the configuration marks all changes sent in the previous message as successfully synchronized. Only unsynchronized changes to objects (creating new ones, changing and deleting existing ones) will be sent to the external application during the next synchronization session.

When transferring data from an external application to the configuration, the picture is reversed. The application must fill out the section accordingly, and in the section place objects to be synchronized in EnterpriseData format.

After processing the file, the configuration will generate an XML file that will contain a receipt message and new data for synchronization from the configuration side (if there is any since the last synchronization session).

Learn more about exchanging data with application solutions on the 1C:Enterprise platform in EnterpriseData format you can view

General module of “exchange manager through a universal format”.

Procedures and functions that fully describe the rules for downloading data from the information base into the exchange format and the rules for loading data from the exchange format into the information base are developed in a common module - the exchange manager module through a universal format.

Rice. 4 Structure of the exchange manager module through a universal format

The module is created automatically using the “Data Conversion” configuration, edition 3.0, based on configured exchange rules, or manually in the configurator.

The module consists of several large sections, each of which contains its own group of procedures and functions.

1. A comment. The first line of the module contains a comment with the name of the conversion. This line is necessary to identify the module when using the command in the Data Conversion program, edition 3.0, for example. // Conversion UP2.2.3 from 06/01/2017 19:51:50
2. Conversion procedures. Contains predefined procedures that are performed at different stages of data synchronization: before conversion, after conversion, before deferred filling.
3. Data Processing Rules (DPR). Contains procedures and functions that describe the rules for processing data.
4. Object Conversion Rules (OCR). Contains procedures and functions that describe the rules for converting objects, as well as the rules for converting properties of these objects.
5. Predefined Data Conversion Rules (PDC). Contains a procedure that fills in the rules for converting predefined data.
6. Algorithms. Contains arbitrary algorithms that are called from other rules (POD or PKO).
7. Options. Contains the logic for filling in the conversion parameters.
8. General purpose. Contains procedures and functions that are widely used in rules and algorithms.

The parameters of procedures and functions that are used in several types of procedures in the manager module are described below.

Exchange Components. Type - Structure. Contains parameters and exchange rules initialized as part of the exchange session.

Direction of Exchange. Type – String. Either "Send" or "Receive".

IB data. Type – DirectoryObject or DocumentObject.

Procedures related to conversion events

There are three predefined procedures that are called during the conversion process:

• Before Conversion. Called before data synchronization occurs. This procedure typically houses the logic for initializing various conversion parameters, populating default values, etc. Parameters: ComponentsExchange.
• AfterConversion. Called after data synchronization has completed, but before lazy padding has occurred. Options: ComponentsExchange.
• BeforeDelayedFilling. Called before lazy filling occurs. The logic for sorting or adjusting the table of objects subject to lazy filling can be located here. Options: ComponentsExchange.

AML procedures

Fill in the Data Processing Rules. An export procedure that contains the logic for filling out data processing rules. Contains calls to other procedures that add a rule for processing a specific object to the rules table (see procedures below Add AML). Options: Direction of Exchange, Data Processing Rules

Add UNDER_<ИмяПОД>. A set of procedures that populate the table UNDER the rules for specific objects. The number of such procedures corresponds to the number of AML provided for this conversion in the Data Conversion program, edition 3.0. Options: Data Processing Rules(a table of values ​​initialized as part of the exchange session).

UNDER_<ИмяПОД>_WhenProcessing. The procedure contains the handler text During Processing for a specific AML. The handler is designed to implement conversion logic at the object level. For example, assign a specific PQO to a specific object depending on the contents of the object. Options:

• InformationB data or DataXDTO(depending on the direction of exchange):
• when sending – object ( DirectoryObject,DocumentObject);
• upon receipt - a structure with a description of the XDTO object.
• Use of PKO. Type - Structure. The key contains a string with the name of the PCO, and the value of type Boolean (True– PKO is used, Lie– PKO is not used).
• ComponentsExchange.

UNDER_<ИмяПОД>_Data Sampling. The function contains the handler text When Unloading. The handler is designed to implement an arbitrary algorithm for selecting objects to be unloaded. Return value: an array of objects to be unloaded. The array can contain both links to infobase objects and a structure with data for uploading. Options: ComponentsExchange.

PKO procedures

Fill in the Object Conversion Rules. An export procedure that contains the logic for filling out the rules for converting objects. Contains calls to other procedures that add a specific object conversion rule to the rules table (see procedures below Add PKO). Options: Direction of Exchange, Conversion Rules(a table of values ​​initialized as part of the exchange session).

AddPKO_<ИмяПКО>. A set of procedures that populate the PKO table with rules for specific objects. The number of such procedures corresponds to the number of PKOs provided for this conversion in the Data Conversion program, version 3.0. Options: Conversion Rules(a table of values ​​initialized as part of the exchange session).

PKO_<ИмяПКО>_WhenSendingData. The procedure contains the handler text When Sending for a specific PKO. The handler is used when uploading data. Designed to implement the logic for converting data contained in an infobase object into a description of an XDTO object. Options:

• InformationB data. Type - DirectoryObject, DocumentObject. The information base object being processed.
• DataXDTO. Type - Structure. Designed to access XDTO object data.
• ComponentsExchange.
• StackUploads. Type - Array. Contains links to unloaded objects, taking into account nesting.

PKO_<ИмяПКО>_When Converting XDTO Data. The procedure contains the handler text When Converting DataXDTO for a specific PKO. The handler is used when loading data. Designed to implement arbitrary XDTO data conversion logic. Options:

• DataXDTO. Type - Structure. XDTO object properties that have been preprocessed to make them easier to access.
• ReceivedData. Type - DirectoryObject, DocumentObject. An infobase object formed by converting XDTO data. Not recorded in the information database.
• ComponentsExchange.

PKO_<ИмяПКО>_Before Recording the Received Data. The procedure contains the handler text Before Recording the Received Data for a specific PKO. The handler is used when loading data. Designed to implement additional logic that must be performed before recording an object in the infobase. For example, should changes be loaded into existing information security data or should they be loaded as new data. Options:

• ReceivedData. Type - DirectoryObject, DocumentObject. A data element generated by converting XDTO data.

Recorded if this data is new for the infobase (parameter InformationB data contains the value Undefined).

Otherwise ReceivedData replace InformationB data(all properties from ReceivedData transferred to InformationB data).

If standard replacement of information security data with received data is not required, you should write your own transfer logic, and then set the parameter ReceivedData meaning Undefined:

• InformationB data. Type - DirectoryObject, DocumentObject. An infobase data element corresponding to the received data. If no matching data is found, contains Undefined.
• ConvertingProperties. Type - Table of values. Contains rules for converting properties of the current object, initialized as part of the exchange session.
• ComponentsExchange.

PCPD procedures

Fill in the Conversion Rules of Predefined Data. An export procedure that contains the logic for filling in the rules for converting predefined data. Options: Direction of Exchange, Conversion Rules(a table of values ​​initialized as part of the exchange session).

Algorithms

In the “Data Conversion” program, edition 3.0, it is possible to create arbitrary algorithms that are called from the AML and PKPD handlers. The name, parameters and content of the algorithms are determined when developing the rules.

Options

Fill inConversionParameters. An export procedure in which the structure with conversion parameters is filled in. Options: Conversion Options(type - Structure).

General Purpose Procedures and Functions

ExecuteManagerModuleProcedure. Options: ProcedureName(line), Options(structure). An export procedure, which is intended to call a non-export module procedure, the name and parameters of which are received as input. Allows you to call a procedure or function on a line without using a method Execute.

ExecuteManagerModuleFunction. Options: ProcedureName(line), Options(structure). Function, purpose similar ExecuteManagerModuleProcedure. The difference is that it calls a function and returns its value.

2018-11-15T19:32:35+00:00

Universal processing "Unloading and loading XML data" performs full or partial upload of infobase data to a file in XML format. Subsequently, this file can be loaded into the infobase using the same processing. The upload file format differs from the file format created when uploading according to an exchange plan in the header part.

Processing can only be used in cases where information base, in which the data was uploaded, and the one in which the data is loaded, are homogeneous (the configurations are identical, the data may differ), or all the uploaded objects are almost completely identical in composition and types of details and tabular parts, properties of the “leading” metadata object, and so on.

The use of this processing is possible, for example, to create complete or partial backup copy data, exchanging data between information bases, and also as an auxiliary tool for restoring faulty information bases.

Processing supports data uploading with the ability to specify selection by period. Also implemented is checking objects for the presence of invalid characters when exchanged via XML.

Sincerely, (teacher and developer).

If you exchange data between the Trade Management 10.3 and Enterprise Accounting 2.0 configurations, then after updating one of the configurations, you need to update the exchange rules.

Let's consider the case when the exchange was configured from the Trade Management configuration and configured through a direct connection to the receiver base, i.e. accounting department You need to download new rules through the data exchange settings in Trade Management. It is highly recommended to make a base before doing this.

Let's get started with 1C Trade Management 10.3. Select the item “All data exchange settings” from the Tools menu => Other data exchanges.

Select the “All exchanges” section. We find your data exchange in the list, click right click mouse and click “Change”. If you try to change the exchange settings from the “Data exchange with 1C: Accounting 8” section, then when you try to change, the data exchange setup assistant will be launched, which we do not need.

In the window that appears, we see that the exchange occurs according to the exchange rules, which can be saved and loaded. The rules for uploading to the exchange database are the rules by which information is uploaded from Trade Management to Accounting, and the rules for uploading from the exchange database to the current database are the rules by which information is loaded from Accounting to Trade Management.

Let's load the upload rules into the exchange database. Click “Load rules from file”. Attention, if you have atypical configuration and you use non-standard exchange rules, i.e. developed specifically for your modified configuration, then you should contact specialists to create new rules based on existing ones.

Do not under any circumstances replace them with standard rules. If you are not sure that you have standard configurations, just in case, save the existing rules with the “Save rules to file” button.

Since the latter came out much later than the update for Trade Management, we are looking for exchange rules in the catalog of 1C update templates for Accounting. You can find the update template directory as follows. Launch 1C and click “Settings”. In the window that appears, we see the path to the directory of configuration templates and updates.

Let's move on this path. Next: 1C => Accounting and select the folder with the name of the latest installed release of Accounting. If the rules need to be taken from the “1C: Trade Management” configuration update, the folder will be called Trade. For the “1C: Retail” configuration - Retail. It contains the “Data Exchanges” folder.

Next “Exchange with configuration Trade management, ed. 10.3". In it we see the RULES FOR BP-UT CONVERSION and RULES FOR UT-BP CONVERSION. Since we need rules for unloading from UT, select “UT-BP CONVERSION RULES” and click open. We do the same for the rules for uploading from the exchange database to the current database, just select the BP-UT CONVERSION RULES file and click open.

In the folder “Exchange with configuration Trade management, ed. 10.3” is the Sharing.htm file. If you have never read it, be sure to read it. It contains the following useful information:

• Sharing purposes
• general description
• Migration from previous versions of two-way communication
• Preliminary actions
• Procedure for setting up data exchange between configurations
• Data synchronization
• Collaboration of the “Trade Management” and “Enterprise Accounting” configurations
• Examples of user scenarios
• Correspondence table of uploaded documents UT - BP (revision 1.6, edition 2.0) Correspondence table of uploaded documents BP (revision 1.6, edition 2.0) - UT
• Features of uploading documents and reference books
• Conformity table for uploaded BP documents (revision 1.6, revision 2.0) - UT
• Transfer of documents “Invoice for payment to the buyer” and “Buyer’s order”
• Transfer of cost of write-off of goods
• Monitoring the results of data exchange

We check the rules using the check buttons. And click OK. The new rules have been saved. We start data exchange and check its operation.

How to set up two-way data exchange between the Trade Management 10.3 and Enterprise Accounting 2.0 configurations is written in my other article.

Probably every 1C specialist has encountered the need to transfer data from one information base to another. In the case where the configurations are different, you have to write data conversion rules. These rules are created in the 1C “Data Conversion” configuration.

Data can also be transferred using . Many 1C 8.3 configurations have standard functionality for setting up data synchronization between different configurations and seamless integration with 1C Document Flow.

But when data needs to be transferred between absolutely identical configurations, you can simplify your task and use standard processing for uploading and downloading via XML. Please note that this method, like data conversion, compares objects with each other by a unique identifier (GUID), and not by name.

You can download this processing on the ITS disk, or using the links:

It is universal and suitable for any configuration.

Let's consider an example of unloading the "Nomenclature" directory from one 1C 8.3 Accounting 3.0 information base to another. Required condition There will be a selection based on the parent (group) “Woodworking”.

Uploading data from 1C to XML

Go to the information base from which the data will be downloaded (source). Be sure to check them, taking into account all possible conditions to avoid undesirable consequences.

Open XML data upload and download processing (Ctrl+O).

We are interested in the “Upload” tab. First of all, specify the name of the file into which the data will be uploaded and the path for saving. In this case, the data is uploaded “to a file on the server”.

In the processing header you can configure the period for which the selection will be carried out. Likewise, for periodic registers You can specify how to apply selection by period. If it is necessary to upload movements along with documents, the corresponding flag is set. In this case, we overload the directory, so there is no need to configure anything in the header.

Let's move on to selecting data for uploading. In the tabular part of the processing form, select the checkboxes for the configuration objects that you need to transfer.

The “Unload if necessary” column indicates whether it is necessary to reload this object, if it is referenced by the attribute of the directory we are reloading. For example, the position of the item you are loading has a unit of measurement that is not in the target database. If the flag in the “Upload if necessary” column is checked opposite the reference book with units of measurement, a new position will be created. Otherwise, the value of the attribute will be “<Объект не найден>" and its unique identifier.

In a simple case without selections, the item overload setting will look like this.

IN in this example you need to select only the items that are located in the “Woodworking” folder.

Similar processing for 8.2 allows you to set selections for each configuration object in a convenient form. In 8.3, unfortunately, there is no such functionality. One way out in this situation would be to select the necessary items on the “Additional objects for unloading” tab.

You can add objects here either manually (the “Add” button) or by request (“Add by request...”). If there are a large number of them, the second option is preferable.

In this case, the request will be as follows. Fill in the parameters, complete the request after checking the data, and click on the “Select result” button.

After you have specified all the necessary objects and additional elements for uploading, click on the “Upload data” button. They will end up in an XML file, the name and path of which you specified earlier. The results of this operation will be displayed in messages.

In this example, it was necessary to unload only 3 positions, but five were unloaded. This is because a flag was set opposite the “Nomenclature” directory in the “Upload if necessary” column. Along with the necessary positions, their parents were overloaded.

Loading a directory from XML

After successfully downloading data from the source configuration into an XML file, open the destination database. The structure of objects and their details must match each other. In this case, the transfer is carried out between two standard configurations 1C: Accounting 3.0.

Open processing in the receiver database. This processing used for both uploading and downloading data. Go to the "Download" tab and specify the path to XML file, into which the data was previously uploaded. After that, click on the “Download data” button.

The download result will be displayed in messages. In our case, everything went well.

The “Nomenclature” directory in the receiving database was not filled out. Now it has five elements: three nomenclature positions and two groups.

What is needed for automatic data exchange, without making configuration changes:
1) Processing " Universal exchange data in XML format", which is included in most standard configurations. If it is not there, then it is easy to find it on the ITS disk or on the Internet. In the configuration it is called "Universal XML Data Exchange"
2) Data exchange rules. Created using "Data Conversion". A job that you will have to master. There are also video courses and teaching aids. For example: http://programmist1s.ru/wp-content/uploads/2013/06/Konvertatsiya_dannyih._Metodika_rabotyi_i_primeryi.pdf
3) External processing, containing loading/unloading procedures. Let's start creating it:
An external processing is created in the object module which will contain the text below (substitute your data for databases and users). It is advisable to create a separate user with full rights to exchange data. Let's call the processing, for example, "Data Exchange.epf".

If LaunchParameter = "Upload" Then Processing=Processing.UniversalXMLDataExchange.Create(); //Set the parameters necessary for uploading (optional for editing) Processing.ExchangeMode="Upload"; Processing.LoadDataInExchangeMode=True; Processing.WriteRegistersRecordSets = True; Processing.RememberLoadedObjects=True; Processing.UseSelectionByDateForAllObjects=True; Processing.UploadOnlyAllowed=True; //!Assigned required parameters for uploading //These parameters must be refilled MANDATORY //Set restrictions on uploading by object dates Processing.StartDate = CurrentDate() - 60*60*24*2; Processing.EndDate = "00010101"; //If we want to upload data to a file, set it to False. If True, it will be uploaded to the receiving database Processing.DirectReadingVIBReceiver=True; //If the receiving database of the uploaded data is a server one, then False. If file - True Processing.InformationBaseForConnectionType=True; //!Required parameters have been refilled //If we upload the data to a file If Not Processing.DirectReadingVIBReceiver Then Processing.ExchangeFileName = "C:\Inbox\OlegA\Conversion\upload.xml"; //If we upload the data to the database Otherwise Processing.PasswordInformationBaseForConnection="Admin"; Processing.ConnectionInfoBaseUser="supercool"; Processing.AuthenticationWindowsInformationBaseForConnection=False; //If the data receiver is server base If Processing.ConnectionInformationBaseType = False Then Processing.ConnectionInformationBaseServerName="MainServ"; Processing.InformationBaseNameOnServerForConnection="Buhia"; //If the data receiver is a file database Otherwise Processing.InformationBasePlatformVersionForConnection="V82"; Processing.InformationBaseDirectoryForConnection="C:\Inbox\OlegA\Clients\Zeus BP20\Zeus BP20"; endIf; endIf; //Actions on registration when unloading according to exchange plans Processing.RegistrationDeletionTypeofChangesForExchangeNodesAfterUpload=0; // 0 - do not deregister, // 1 - deregister Processing.LoadExchangeRules(); //IF YOU NEED TO UPLOAD ACCORDING TO EXCHANGE PLANS, THEN ENABLE THIS BLOCK AND SUBMIT YOUR OWN EXCHANGE PLAN NODE //For Each Page From Processing.UploadRulesTable.Lines Cycle //Page.Enable=1; // For Each Page1 From PageLine Loop // Line1.Enable=1; // Page1.LinkToExchangeNode=ExchangePlans.Full.FindByCode("BP20"); //EndCycle; //EndCycle; Processing.Perform Upload(); ShutdownSystem(False); ElseIf LaunchParameter = "Load" Then ExchangeProcessing = Processing.UniversalXMLDataExchange.Create(); ExchangeProcessing.ExchangeFileName = "C:\Inbox\OlegA\Upload.xml"; ExchangeProcessing.ExchangeMode = "Loading"; ExchangeProcessing.OpenDownloadFile(True); ProcessExchange.ArchiveFile = False; ProcessExchange.PerformLoad(); ExchangeProcessing = Undefined; ShutdownSystem(False); endIf;

4) Bat file upload, which will launch 1C and external processing with the launch parameter under the user, which is intended for data exchange. The file must be created, for example, in notepad++ with OEM (MS-Dos) encoding, otherwise it will not work. Let's name the file, for example, "BatVygruz.bat". The text will be as follows:

If the database is file:
"C:\Program Files (x86)\1cv82\common\1cestart.exe" ENTERPRISE /F"C:\Inbox\KBF\1Cv8_Base_8.1\Zeus 83 BP3\Zeus 83 BP3" /N"Data Exchange Robot" /P"pass " /DisableStartupMessages /RunModeManagedApplication /Execute"C:\Inbox\OlegA\DataExchange.epf" /C"Upload"
Explanations:

b) C:\Inbox\KBF\1Cv8_Base_8.1\Zeus 83 BP3\Zeus 83 BP3 - your path to file database, from which we will download data
c) Data Exchange Robot - User name under which 1C runs for data exchange
d) pass - user password
e) /DisableStartupMessages - close pop-up windows when starting 1C
e) /RunModeOrdinaryApplication - run the thick client in normal mode
g) C:\Inbox\OlegA\Data Exchange.epf - the path to our processing, which will start at startup
h) Upload - we pass the 1C launch parameter, it tells us that we need to upload data

If the database is server-based:
"C:\Program Files (x86)\1cv82\common\1cestart.exe" ENTERPRISE /S"Server1C/DataBase" /N"Data Exchange Robot" /P"pass" /DisableStartupMessages /RunModeManagedApplication /Execute"C:\Inbox\Oleg\ Data Exchange.epf" /C"Upload"
Explanations:
a) C:\Program Files (x86)\1cv82\common\1cestart.exe - your path to the 1C starter
b) Server1C/DataBase - your server on which the database is located and the name of the database itself from which we upload data.
The remaining parameters are similar to the file version of the bat file

5) Bat file download (if necessary). If you decide to upload data to a file, and not directly to the database. Then we will also need this item (usually necessary).
Creation bat file upload is similar to the upload file, but only the launch parameter is different, instead of “Upload”, we put “Download”

6) Set a launch schedule our Bat files loading/uploading on the server. To do this, you need to go to the administration of the control panel on the server and in the task scheduler create a new task to run the download file at 23 o'clock every day and a download task specifying the Bat download file (if necessary) at 04 o'clock for example.