1c universal data exchange in xml format. Appearance and features of using universal data exchange. Why then do we need KD3? Advantages and disadvantages

• Video – 21 teaching hours
• Teaching materials in PDF - 117 A4 pages
• 16 practical tasks with teacher solutions

Course format, support

The materials are available immediately after payment for the order - you download them from the site and study them at any convenient time.

Support is provided through the Master Group on the website.

Full access to the Master group must be activated no later than 100 days after purchase.

Relevance of the course

The course materials are relevant for BSP version 2.3.2.73.

If you plan to use older versions of the BSP, then please note that the operating mechanisms of the BSP “Data Exchange” subsystem have changed, and the interfaces have also changed.

A new course for the latest versions of the BSP is under development and will be released in a few months. But for versions of BSP 2.3.2.73 and younger, the current rate will be relevant.

Course fee

9,700 rubles

Guarantee

We have been teaching since 2008, we are confident in the quality of our courses and give our standard 60-day warranty.

This means that if you started taking our course, but suddenly change your mind (or, say, do not have the opportunity), then you have a 60-day period to make a decision - and if you make a return, we return 100% of the payment.

Installment payment

Our courses can be paid for in installments or in installments, including without interest. Wherein You get immediate access to materials.

This is possible with payments from individuals in the amount of RUB 3,000 or more. up to 150,000 rub.

All you need to do is select the payment method “Payment via Yandex.Checkout”. Next, on the payment system website, select “Pay in installments”, indicate the term and amount of payments, fill out a short form - and in a couple of minutes you will receive a decision.

Payment options

We accept all major forms of payment.

From individuals– payments from cards, payments with electronic money (WebMoney, YandexMoney), payments through Internet banking, payments through communication shops, and so on. It is also possible to pay for the order in installments (in installments), including without additional interest.

Start placing your order - and in the second step you can choose your preferred payment method.

From organizations and individual entrepreneurs– cashless payment, delivery documents are provided. You enter an order and you can immediately print an invoice for payment.

Training of several employees

Our courses are designed for individual learning. Group training on one set is illegal distribution.

If a company needs to train multiple employees, we typically offer “add-on kits” that cost 40% less.

To place an order for an “additional kit” select 2 or more course sets in the form, starting from the second set the cost of the course will be 40% cheaper.

There are three conditions for using additional kits:

• You cannot purchase only an additional set if at least one regular set was not purchased before (or along with it)
• There are no other discounts for additional sets (they are already discounted, it would be a “discount on a discount”)
• promotions are not valid for additional sets (for example, compensation of 7,000 rubles) for the same reason

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 is 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 files for supplying 1C application solutions, there is a 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 features of its own software or information base structures that participate in the exchange and does not contain obvious 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. These are different versions of the 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 the previous version of the format is maintained (maintaining backward compatibility of current data transfer algorithms 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 a third-party application to 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 configuration exchange plans during synchronization, only information about changes that have occurred since the last synchronization is transmitted (to minimize the amount of information transferred). 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).

You can see more details about data exchange with application solutions on the 1C:Enterprise platform in the EnterpriseData format

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, version 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.

When developing 1C 8 exchange rules, the ability to programmatically redefine the behavior of exchange rules is widely used - the handler mechanism. Event handlers significantly expand the functionality and are an indispensable tool for setting up exchange rules in cases where interactive configuration capabilities are not enough.

Handlers and algorithms are written in the language of the platform in which they will be executed during the exchange.

If this is a 1C: Enterprise 7.7 platform, then the handler code is integrated into the upload or download processing code. Accordingly, each handler or algorithm is separated into a separate function and is available for debugging during exchange.

If uploading or downloading occurs on the 1C: Enterprise 8 platform, then the handler code is not integrated into the data exchange processing code, but is uploaded to the exchange rules file. During the data exchange process, the code of handlers or algorithms is taken from the rules file and executed directly in the context of the “Run” statement. To debug the code of handlers and algorithms, you can use the “Universal XML Data Interchange” processing.

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

What is needed for automatic data exchange, without making configuration changes:
1) Processing "Universal Data Interchange 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 tutorials. 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; //!Set the necessary 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 a 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 the file database from which we will upload 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).
Creating a Bat download file 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.