1c change the exchange rules through the universal format. 1C offers the EnterpriseData format for the exchange of business data. What is EnterpriseData format

The purpose of this article is to answer the first questions on KD3 and, using a simple example, show how to modify the standard rules. The information is useful for beginners and those who have already started mastering and have new questions.

Accepted abbreviations in this publication

KD2- Configuration Data Conversion, revision 2.0.
KD3- configuration Data conversion, revision 3.0, configuration 3.0.5.3.
ED- universal exchange format EnterpriseData.

Answers to questions after a superficial acquaintance with KD3. If you know why you need KD3, you can skip this paragraph;)

Questions and answers

• KD3 is a new version of KD2? No! This is another tool that solves problems similar to KD2. Each tool has its own application.
• Is KD3 better than KD2? They cannot be compared, since they are different tools and each has its own pros and cons.
• To change the rules for exchanging KD3, you need to remove the configuration from support? No DO NOT need to withdraw from support! In typical configurations, you can standardly connect external processing with rules, and on configurations that support the platform 8.3.10 and higher, you can edit rules using the extension.
• You need to transfer data from in-house configurations. For study purposes, you can use KD3? If you are asking this question, most likely you cannot. For KD3, the configuration must include BSP 2.3 and higher with synchronization via a universal format. KD2 will suit you 100%, KD3 is questionable.
• Can KD3 be used for typical modified configurations? Yes, you can. If your atypical data can be passed using ED or AdditionalInfo props, that's fine. Otherwise, there is an option to change the exchange format (XML schema). In this case, the capabilities of CD3 will almost be equal to CD2, but the main advantage of CD3 will be lost - the versatility of the exchange format.
• Configurations that support ED can be exchanged with each other? Yes! But for the exchange of BP 3.0 - BP 3.0, when creating a synchronization, you cannot select BP 3.0. It's okay, choose "Other program". If you need a one-time exchange, it is enough to use the "Upload / Load EnterpriseData" processing in the All Functions menu.
• After updating the configuration, do you need to download the latest rules from the distribution kit? No! The rules are contained in the configuration module. To exchange with other 1C databases, you do not need to load the rules of another database. Why? Details in this article.
• After updating one database, is it necessary to bring the other database participating in the exchange up to date? No! It is not required to synchronously update all databases participating in the exchange. This is one of the advantages of KD3.
• Our configurations have been greatly improved, there are new types of documents and directories, can KD3 transfer them? There is a chance that it will not be able to without changing the format. This is one of the "disadvantages" of KD3 in comparison with KD2.

Why then do we need KD3? Advantages and disadvantages

Pros of KD3

Let's consider the main advantage of KD3 using the example of a frequently encountered task. There is a UT 11.3 configuration, which is not updated for some reason. It is necessary to organize an exchange with BP 3.0, which is constantly updated to the current release.

No problem.

• The universal exchange format that is used in KD3 is designed to solve such problems.
• Exchange rules in UT are created not for exchange with BP, but for exchange with the universal format EnterpriseData.
• If we operate in terms of KD2, then UT exchanges with the ED configuration, which does not change. BP 3.0 is also exchanged with ED.

Each configuration has its own rules for exchanging with ED. Thus, UT always uploads data to the same format. BP 3.0 configuration, no matter how new it is, should be able to receive data from this format.

It turns out that UT does not need to worry about the fact that the BP will change some details. The task is simple - upload to ED, and the PSU configuration should be able to accept data from this format.

• Due to the fact that the source always uploads configuration in one format, any configuration receiver can upload data from this universal format.
  Those. for an arbitrary combination of exchanges UT - BP, UT - KA, UT - ERP, KA-BP, ERP - BP. no need to write individual rules. In KD3, the rules are universal. Any configuration that supports universal format exchange can exchange with any configuration that supports ED format.

Debugging of algorithms and rules is available in the configuration itself, since all rules are code common module or external processing. You can do without KD3 to quickly fix the error.

Cons of KD2

The exchange rules are individual for each pair of configurations. All of the above combinations of exchange between different types of configurations and different versions of configurations need their own exchange rules. Therefore, to solve the above-mentioned problem of exchanging UT 11.3 and BP 3.0, it will be necessary to debug and refine the exchange rules almost after every update of BP 3.0.

Debugging algorithms and rules is difficult for a novice programmer or for someone who rarely faces this task. The rules are stored in an xml file. No quick fix available. It is necessary to load the rules into KD2, correct and unload them back.

Cons of KD3

The universal format imposes restrictions on the types of documents and directories. It is designed for typical configurations. If you have an atypical requisite or type of document, it may be difficult to exchange.

For synchronization in ED format, the configuration must support these mechanisms. All this is in BSP 2.3 and higher. This is not really a minus, but rather a feature.

The main plus fades a little due to the limited time frame for supporting the format. This has already been felt by the users of UT 11.1, UT 11.2, who exchange with BP 3.0. Support times are listed here. It says that the minimum guaranteed format support period is a year, in fact, about 3 years. Thus, if you set up synchronization today, then for at least a year you can not update the UT 11 database, and then either update the configuration, or simply add a new format, make a small change in the BSP and in the rules, if necessary. How to do it? Will be mentioned later in this article.

Advantages of KD2

The possibilities of KD2 are endless. You can create exchange rules for any configuration on any platform. From 1C 7.7 to the last 8.3. Nothing is required from the configuration, the BSP is optional. Rules can be created in automatic mode and refined.

Due to the above pros and cons, it is recommended to use KD3 for typical configurations. KD2 can be used for any configuration, but given its disadvantages, do not forget that sometimes it is more expedient to use KD3.

I hope you understood why KD3 is needed, we continue on the merits.

Accepted abbreviations further

BSP- Library of standard subsystems.
UNDER- data processing rule.
PKO- object conversion rule.
PKPD- rule for converting predefined data.
PKS- property conversion rule.

Consider an example - it is necessary to change the standard rules for the exchange of BP 3.0 and UT 11.3

On a yellow background, there are steps from the instructions that open in KD3. The sequence of steps proposed in this article is different, so as not to get confused and immediately logically complete the action begun.

How do I change ED rules?

1. Modify the module with exchange rules right in the configuration. We are not considering this option yet, because to understand what and where needs to be changed, it is necessary to do it at least once in KD3. In this case, it will be easier in the future to quickly solve problems, debug in the module and transfer to KD3 if necessary.
2. Use KD3.
   How is this done in KD2? We unload the metadata of both configurations and load it into KD2.
   Step 1. For KD3 we do the same - in each configuration in the enterprise mode by processing \ tmplts \ 1c \ Conversion \ 3_0_5_3 \ MD83Exp.epf upload configuration metadata,
   for example, to the folder “ D: \ Rules BP3 \ BP 3.0.54.15 \", File name " MD.xml».

It is not clear for what purpose the settings of this processing are hidden, as a result, by default, data on information registers is not unloaded. We eliminate this defect.
In the ChangeProcessingMode () procedure of the main form, comment out the line

// Elements.Settings.Visibility = False;

We save the processing, open it in enterprise mode, put the flag on "Unload information registers", unload.

Step 3. Load the previously created file “ MD.xml"In KD3, section flag" V new version configuration».

Because in KD3, the "intermediate configuration" (ED) is used for exchange, we also load its "metadata", which are XML schema, a file with the extension "xsd". Step 2. You can take it from the UT 11 or BP 3.0 configuration. They are the same. Open the configuration, in the search bar, enter “ enter", We see in the tree General - XDTO packages some packages like this: EnterpriseData_1_3_8, EnterpriseData_1_4_4 and the like .. These are versions of the format 1.3 and 1.4, respectively, and 1.2, 1.1, 1.0, if any. Right button mouse on the package, in context menu choose "".

Step 4. In the KD3 section, select the previously uploaded files with the "xsd" extension. You need to select one file! Multiple choice in conjunction with ExchangeMessage is not needed! This was suggested in the old KD3 instructions previous versions... In the last CD3, this is not required.

After loading the format in the section Data Format - Format Object Tree, select the format version. If there are documents and directories there, then you have uploaded correct file... If not, start over with a new blank CD3 and load the format first and check the tree.

Stage 2. After loading the metadata into CD3, we proceed to loading the standard exchange rules.
How is this done in KD2? The rules are loaded into conversion.
It's almost the same in KD3. We unload the rules from the standard one, create a conversion, and then load the rules into it.

Unloading typical rules from the configuration for loading into CD3

Configurations are exchanged on the maximum common version of the exchange format. For example, one configuration has a maximum format of 1.5, the other 1.6, which means they will exchange among themselves in a 1.5 format. Therefore, it is enough to unload the 1.5 format from both configurations and load it into the rules.

We open the configuration of BP 3.0 or UT 11.3 in the configurator mode, in the search bar you can enter “ men uni”, Open the general module. If this is BP 3.0, then open it. In the open module, go to the menu File - Save a copy, save the file with an arbitrary name, for example, “ D: \ Rules BP3 \ BP 3.0.54.15 \ Common module ExchangeManager Via UniversalFormat_Module».
Open configuration BP 3.0 or UT 11.3 in enterprise mode, open processing \ tmplts \ 1c \ Conversion \ 3_0_5_3 \ Upload sync rules.epf

Lack of typical processing:

• often fails;
• unloads rules from external processing connected to the node, but we need typical rules;
• does not work in BP 3.0.53 and higher.

Modification of the module of the main processing form. Making changes to procedures OnCreateAtServer.

& AtServer Procedure OnCreateAtServer (Cancel, StandardProcessing) // List of format versions selection. Format Versions = New Match; Data ExchangeRedefinable.OnGettingAvailableFormatVersions (FormatVersions); For Each ExchangePlan From DataExchangeReturnUsedExchangePlansBSP () Cycle If DataExchangeRepeat.ThisExchangePlanXDTO (ExchangePlan) Then ExchangePlan Format Versions = New Match; BSP243 Version = GeneralPurposeClientServer.CompareVersions (StandardSubsystemsServer.Library Version (), "2.4.3.1")> = 0; ModuleDataServer = General Purpose. CommonModule ("Data ExchangeServer"); If BSP243 Version Then ExchangePlaneFormatVersions = DataExchange ModuleServer.ExchangePlanSettingsValue (ExchangePlan, "ExchangeFormatVersions "); Otherwise ExchangePlans [ExchangePlan] .GetExchangeFormatVersions (ExchangePlanFormatVersions); EndIf; For Each ExchangePlaneVersion From ExchangePlanFormatVersion CycleManager Module = FormatVersions.Get (ExchangePlaneVersion.Key); If Manager Unit = Undefined Or Manager Unit<>ExchangePlaneVersion.Value ThenFormatVersions.Insert (ExchangePlaneVersion.Key, ExchangePlaneVersion.Value); EndIf; End of Cycle; EndIf; End of Cycle; For EachFormatVersion FROMFormatVersion.Loop Items.FormatVersionNumber.SelectionList.Add (FormatVersion.Key); End of Cycle; FormatVersionStoreAddress = PutToTemporaryStore (Format Versions, UniqueIdentifier); End of Procedure

• We select "Format version number", for example, " 1.3 »,
• "Exchange directory" - create a folder, for example, ""
• Press the button " Unload».

We repeat these steps for other versions of the format and save them to the corresponding folders "1.4", "1.5", etc. For BP 3.0, it is enough to unload all formats from 1.3 and higher. For other configurations from 1.2 and up.

The rules have been unloaded, now you need to load them into KD3. In KD2, the rules are loaded simultaneously with the creation of the conversion. In CD3, you need to create a conversion and load the rules into it.
In KD3 Section Conversions - Conversions - Create... ... Choosing a configuration. For convenience, you can change the name of the configuration by going to the element editing mode. For example, instead of AccountingEnterprises indicate " BP 3.0.54.15". Props Name no need to change! Name conversions can be specified the same, for example, “ BP 3.0.54.15". In the tabular section, select the supported versions of the format. The versions of the format are those that we downloaded from the database above. We save the conversion.

Go to the section Conversion - Loading sync rules from files.
:

Loading place: " Into existing conversion»

Exchange directory: " D: \ Rules BP3 \ BP 3.0.54.15 \ 1.3»

• File with the exchange module: " D: \ Rules BP3 \ BP 3.0.54.15 \ Common module Exchange Manager Via UniversalFormat13_ Module.txt»
• Conversion: " BP 3.0.54.15»

When loading synchronization rules from files for UT 11.3, an error appears " Object field not detected". The reason is for TekPKO.UseForReceive = False CD3 requires information on the identification option upon receipt. If this is not in the rules file, an error occurs. We correct this misunderstanding. Either we remove this form from support, or use the extension.

// The main form of processing LoadingSynchronizationRulesFromFiles // Before changes are made: // The procedure loads the rules for converting objects & On the Server Procedure LoadPKO () ... FillProperty Values ​​(TekPKO, Attribute Structure); // Identification option - special logic. TekPKO.ObjectIdentification Option = Enumerations.Object Identification Options [AttributesStructure.Identification Option]; ElseIf XMLReader.NodeType = XMLNodeType.EndItem Then // Write the loaded POC. ... // Changes are marked with "// ED" // The procedure loads the rules for converting objects & On the Server Procedure LoadPKO () ... FillProperty Values ​​(TekPKO, Attributes Structure); // Identification option - special logic. If TekPKO.UseFor Obtaining Then // ED TekPKO.Identification Option = Enumerations.Object Identification Options [Attributes Structure.Identifying Option]; EndIf; ElseIf XMLReader.NodeType = XMLNodeType.EndItem Then // Write the loaded POC. ...

Press the button " Download». « The handlers are intended for a different conversion: BP 3.0.44 (format 1.4). Continue downloading?"Click" Yes».
Without closing the form, select another " Exchange directory"And press the button" ". We repeat several times loading the rules for each format into the current conversion.
After successful loading, go to the section " Conversion "-" Configuring conversion rules", Open our conversion from the list form.
If we see POD, etc., then loading into CD3 was successful.

Checking the correctness of loading rules

This is an optional operation! If you will use the same version of the format in the rules, you do not need to achieve the identity of the module text.

• Open the BP configurator, create a new external processing, for example, Name “ Synchronization of EDBP", Synonym for" Synchronization ED BP 3.0».
• In KD3 in the form " Setting exchange rules"Press the" "button and paste this code from the clipboard into our new processing.
• In the BP configurator, we check the module for syntax errors. We save the processing.
• create another empty processing in the BP, for example, Name “ Synchronization EDB Typical", Synonym for" Synchronization ED BP 3.0 typical". Copy the text of the general power supply module Exchange Manager Via Universal Format13 into the processing module and save it.

Let's compare both treatments. Menu File - Compare files.

If a standard module contains procedures that are absent in our rules, it means that you have not loaded the rules for conversion for all data formats. If necessary load the rules in the missing format into the conversion and repeat the comparison of our rules with the standard ones. When we achieved identity you can safely proceed to finalizing the rules... It is not necessary to achieve complete identity if you know which of the exchange formats will not be used for synchronization.

In a similar way, we create a conversion for UT 11.3 in KD3.

BP 3.0.54.15

• Spotted incorrect loading PKO " Reference_Users". Needs to be corrected. Should.
• In PKO " Document_Product Inventory_Shipment"for PKS" Responsible Person"PQS not specified. Open, reselect the configuration property and the format property to fill in their type, after which the selection in the" Property conversion rule". Select" Directory_Persons_Send".

Consider an example of revision

The main purpose of the example is to show the possibilities of improvements for transferring additional data that do not fit into the exchange format.

You need to transfer the props " TypeNomenclature"reference book" Nomenclature ", type of variable" Directory.ViewsNomenclatures". This kind of reference book is not carried by the standard KD3 rules and is not supported by the ED format version below 1.6.

There are several options for solving this problem.

• Modification of the XDTO package, adding the "Reference.Nomenclature Types" object to the format. As a result, the main advantage of the universal format is lost - it ceases to be universal. Modification of the XDTO package will be required in all databases participating in the exchange.
• Use format property " Additional details", which is in many objects. This option will not be considered in this article due to some complexity. Note that there is such a method.
• Props AdditionalInfo. It is present in the header of all format objects. AnyType. Designed for such cases. We will use it as the simplest way.

Before proceeding with the refinement of the standard rules, let's create two groups in the rule group “ Added by», « Changed". This is done in " Conversions -".
New POD, PKO, Algorithms, etc. we will create in the "Added" group, the standard objects to which we make changes will be transferred to the "Changed" group. This will facilitate the subsequent maintenance of the changed rules.

So let's get started.

Changes to the rules in UT 11.3

In KD3 in the form " UT 11.3.4.12 Setting exchange rules"On the tab Algorithms creating a new algorithm

• Algorithm name "AdditionalInfoInsert"
• Group: "Added"

Parameters: "DataXDTO, Name, AdditionalValue"

Algorithm code

If DataXDTO.Property ("AdditionalInfo") AND TypeValue (DataXDTO.AdditionalInfo) = Type ("Structure") Then AdditionalData = DataXDTO.AdditionalInfo; Otherwise AdditionalData = New Structure; EndIf; AdditionalData.Insert (Name, AdditionalValue); DataXDTO.Insert ("AdditionalInfo", AdditionalData);

We save the algorithm and go to the “ Object conversion rules»

By button " Find"Looking for" Nomenclature ", open PKO" Reference_Nomenclature_Send". Go to the tab " When sending". There we see the field "Handler name:" "". You can make changes directly there.
More complex code that requires debugging can be written in the configuration. We are looking for in the exchange module in UT 11.3 a procedure named “ PQS_Reference_Nomenclature_Send_When SendingData"And finalizing it there.
To transfer changes from UT 11.3 to KD3, copy the entire procedure to the clipboard, to KD3 in the form “ Setting exchange rules"Press the button" ".

For our example, the code is

If ValueFilled (DataIB.NomenclatureView) Then // ED AdditionalInfoInsert (DataXDTO, "NomenclatureView ", String (DataIB.NomenclatureView.UniqueIdentifier ())); AdditionalInfo Insert (XDTO Data, "NomenclatureNomenclatureName", General Purpose.ObjectAttributeValue (DataIB.NomenclatureView, "Name")); // AdditionalInfo Insert ... // add other service details EndIf;

After transferring the changes to KD3, press the button " Save the exchange manager module"and transfer the code from the buffer to the UT module 11.3.

Changes to rules in BP 3.0

We make changes to the PKO " Reference_Nomenclature_Getting", on the" When converting XDTO data", procedure name" PKO_Reference_Nomenclature_Getting_WhenXDTODataConversion".

The code added to the module "PKO_Reference_Nomenclature_Getting_WhenXDTODataConversion"

If DataXDTO.Property ("AdditionalInfo") AND TypeValue (DataXDTO.AdditionalInfo) = Type ("Structure") Then // ED AdditionalData = DataXDTO.AdditionalInfo; If AdditionalData.Property ("NomenclatureType ") ThenNomenclatureType = ExchangeDataXDTOServer.ObjectLinkPoUIDObjectXDTO (AdditionalData.NomenclatureView, Type (" DirectoryLink.NomenclatureType "), Exchange Components); IfNomenclature.GetObject () = Undefined AND AdditionalData.Property ("NomenclatureKindName ") Then // Create a newNomenclatureKindObject = Directories.NomenclatureTypes.CreateElement (); NomenclatureKindObject.SetNewLink (NomenclatureKind); Nomenclature typeObject.Name = AdditionalData.Nomenclature typeName; // fill in other service details FillPropertyValues ​​(NomenclatureKindObject, AdditionalData); NomenclatureKindObject.Write (); NomenclatureKind = NomenclatureKindObject.Ref; EndIf; ReceivedData.NomenclatureType = NomenclatureType; EndIf; EndIf;

Code alone is not enough. It is necessary on the "Properties conversion rules" tab to add the PKS with the configuration property "" and the checkbox " Conversion algorithm used".

We transfer the exchange manager module to the BP 3 configuration module or to external processing.

How to upload the modified rules of CD3 to the database?

In configurations exchanging rules on CD2, this is done in the node settings. For the rules created in KD3, we will see there only the opportunity to change the registration rules.

The rules prepared in KD3 can be installed in the configuration in three ways

1. Remove the configuration from support and make changes to the common module Exchange Manager Via Universal Format;
2. On configurations running in platform compatibility mode 8.3.10 and higher, you can patch the shared module using an extension.
3. Connect an extension that completely replaces the general module with rules.
4. Connect external processing with rules to the node without removing the configuration from support;

With the first option, everything is clear, it is described in the documentation, the disadvantage is that you need to remove the configuration from support. The second option - correcting the selected procedure with an extension will also not be difficult for the 1C programmer - you need to compare the two processing with standard rules and with the modified ones as described above in this article, and make a change to the required procedure.

The third option is using an extension with exchange rules in a universal format currently the most optimal. There is only one drawback - it is necessary to remove the flag " Safe mode"when connecting this extension. This limits its use in cloud services... We are waiting for a decision from 1C on the procedure for replacing exchange rules in a universal format in 1C fresh.

The bottom line is that you need to find in the configuration a section of code that is responsible for choosing a common module, depending on the version of the exchange format, and replace the choice of the module with your own module. Example for BP 3.0.67:

//////// // Generic Data Exchange Module Overridden & Instead of ("On Getting Available Format Versions") Procedure ED_ When Getting Available Format Versions (Format Versions) ED_Exchanging DataServer.When Getting Available Format Versions (Format Versions); EndProcedure //////// // Exchange Plan Data Synchronization Via Universal Format: Manager Module # If Server Or Thick Client Ordinary Application Or ExternalConnection Then & Instead of ("When Receiving Settings") Procedure ED_When Receiving Settings (Settings) Settings.DefaultName = GeneralConfigurations; Settings.ThisExchangePlanXDTO = True; Settings.WarningOnMismatchRuleVersion = False; Settings.ExchangeFormat = "http://v8.1c.ru/edi/edi_stnd/EnterpriseData"; Format Versions = New Match; ED_DataServer.When Receiving AvailableFormat Versions (Format Versions); // ED Settings.ExchangeFormatVersions = FormatVersions; Settings.ExchangePlanUsedInServiceModel = True; Settings.Algorithms.WhenGettingExchangeSettingsVariants = True; Settings.Algorithms.OnGettingOptionDescriptionSettings = True; Settings.Algorithms.InteractiveOfSelectionPresentation = True; Settings.Algorithms.ConfigureInteractiveOffload = True; EndProcedure #EndIf //////// // Generic module in extension ED_DataServer Procedure OnGetAvailableFormatVersions (FormatVersions) ExportFormatVersion.Insert ("1.2", ExchangeManagerViaUniversalFormat); Format Versions.Insert ("1.3", ED_ExchangeManagerViaUniversalFormat); Format Versions.Insert ("1.4", ED_ExchangeManagerViaUniversalFormat); Format Versions.Insert ("1.5", ED_ExchangeManagerViaUniversalFormat); Format Versions.Insert ("1.6", ED_ExchangeManagerViaUniversalFormat); EndProcedure //////// // Common module in the extension ED_ExchangeManagerThrough the UniversalFormat // Conversion of BP3.0.44 (format 1.6) from 11/27/2018 11:23:58 // Improvement for BP 3.0.67.x from 31.12 ... ...

Let's consider the 4th option, which is not described in the documentation, since there is no such possibility in BSP. This option is already deprecated. External processing with rules was used in the first versions with a universal exchange format. Now 1C is gradually getting rid of this functionality.

In enterprise mode, in the administration section, follow the link Data Sync - Data Sync Settings, press the button " Tune..."if the setting is one or" Change"if there are several settings. Go to the form editing mode through the menu" " , Expand " Group", there we include the hidden form element" "," OK".
On the " Service information"choose" Path to exchange manager", we substitute our processing with the rules there.

Connecting external processing with rules to BP 3.0.52 and higher

In BP 3.0.52 and higher for unknown reasons external processing with rules is not used. The interface for connecting processing remains. Thanks for that.

You can enable processing with rules using an extension. The common module needs to be corrected " Data ExchangeXDTOServer", function" Format VersionsExchange".

EDm_PoluchitVersiyuFormataObmena procedure (VersiiFormata means UzelInformatsionnoyBazy) query = new Query ( "SELECT VARIOUS | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzheruObmena AS PutKMenedzheruObmena, | SinhronizatsiyaDannyhCherezUniversalnyyFormat.VersiyaFormataObmena AS VersiyaFormataObmena | FROM | PlanObmena.SinhronizatsiyaDannyhCherezUniversalnyyFormat SinhronizatsiyaDannyhCherezUniversalnyyFormat HOW | WHERE | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzheruObmena<>"" "" "| And Data Synchronization Via GenericFormat.Ref = & Link "); Query.SetParameter (" Reference ", InformationBase Node); Fetch = Query.Run (). Select (); While Fetch.Next () Loop ProcessingName = Fetch.Path to the Manager If the SharedOnder is NOT available; () Then ProcessingData = New BinaryData (ProcessingName); ProcessingAddress = PutToTemporaryStore (ProcessingData); If GeneralPurpose.There is Protection Against Dangerous Actions () Then ProcessingName = ExternalProcessing.Descriptions. EndIf; EndIf; ExchangeManager = ExternalProcessing.Create (ProcessName); Format Versions.Insert (Selection.ExchangeFormatVersion, ExchangeManager); End of Loop; EndProcedure & Instead of ("ExchangeFormatVersion") EDMNodeVersionNodeVersionValue Added (InfoBase Node) Then ExchangePlaneName = InfoBaseNode.Metadata () .Name; ExchangeFormatVersions = DataExchangeServer.ExchangePlanSettingsValue (ExchangePlaneName, "ExchangeFormatVersions "); EDm_GetExchangeFormatVersion (ExchangeFormatVersions, InformationBase Node); OtherwiseDataExchangeRedefinable.WhenGettingAvailableFormatVersions (ExchangeFormatVersions); EndIf; If ExchangeFormatVersions.Number () = 0 Then CallExceptionStringFunctionsClientServer.SubstituteParametersVSString (HStr ("ru =" Exchange format versions are not specified. | Exchange plan name:% 1 | Procedure: GetExchangeFormatVersions (<ВерсииФорматаОбмена>) ""), DatabaseNode.Metadata (). Name); EndIf; Result = New Match; For Each Version FromVersionFormatExchange Cycle Result.Insert (AbbrLP (Version.Key), Version.Value); End of Cycle; Refund Result; EndFunction

How to Debug Rules in External Processing

In the configurator " Service -> Parameters -> Start 1C: Enterprise -> Start Parameter", specify the parameter" ".

• Below is the code for the extension, for UT 11.4, KA 2.4, ERP 2.4. The code for BP 3.0 is given above. Exchange plan manager module Data Synchronization Via Universal Format.

ED Extension Code Debug

& Instead of ("GetExchangeFormatVersions") Procedure ED_GetExchangeFormatVersions (FormatVersions) DataExchangeUT.AvailableUniversalFormatVersions (FormatVersions); Request = New Query ("SELECT DIFFERENT | Data Synchronization Via UniversalFormat.PathTo Exchange Manager, | Data Synchronization Via UniversalFormat.ExchangeFormatVersion | FROM | Exchange Plan.<>"" "" "); Fetch = Query.Execute (). Select (); While Fetch.Next () Loop ProcessingName = Fetch.PathToExchange Manager; IF NOT SharedPurposeClientServer.Debug Mode () Then // EDProcessingData = New BinaryData) (NameProcessingData ; AdresObrabotki = PomestitVoVremennoeHranilische (DannyeObrabotki) If ObschegoNaznacheniya.EstZaschitaOtOpasnyhDeystvy () Then ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki, ObschegoNaznacheniya.OpisanieZaschityBezPreduprezhdeny ()); otherwise ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki); ENDIF; ENDIF; MenedzherObmena VneshnieObrabotki.Sozdat = ( ImyaObrabotki) VersiiFormata.Vstavit (Vyborka.VersiyaFormataObmena, MenedzherObmena) KonetsTsikla; KonetsProtsedury & instead ( "DostupnyeVersiiFormataObmena") ED_DostupnyeVersiiFormataObmena procedure (VersiiFormata) ObmenDannymiUT.DostupnyeVersiiUniversalnogoFormata (VersiiFormata) Query = new Query ( "SELECT VARIOUS | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzher at the exchange, | Data SynchronizationViaUniversalFormat.ExchangeFormatVersion | FROM | Exchange Plan.Data SynchronizationThrough the UniversalFormat AS Data SynchronizationThrough the UniversalFormat | WHERE | Data Synchronization Via Universal Format.Path To Exchange Manager<>"" "" "); Fetch = Query.Execute (). Select (); While Fetch.Next () Loop ProcessingName = Fetch.PathToExchange Manager; IF NOT SharedPurposeClientServer.Debug Mode () Then // EDProcessingData = New BinaryData) (NameProcessingData ; AdresObrabotki = PomestitVoVremennoeHranilische (DannyeObrabotki) If ObschegoNaznacheniya.EstZaschitaOtOpasnyhDeystvy () Then ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki, ObschegoNaznacheniya.OpisanieZaschityBezPreduprezhdeny ()); otherwise ImyaObrabotki = VneshnieObrabotki.Podklyuchit (AdresObrabotki); ENDIF; ENDIF; MenedzherObmena VneshnieObrabotki.Sozdat = ( ProcessingName); Format Versions.Insert (Fetch.ExchangeFormatVersion, ExchangeManager); EndLoop; EndProcedure

Debugging is easiest to do in the file database. We set a breakpoint in processing with rules. To find the required procedure, use KD3. We find PKO, POD or Algorithm, look " Handler name" or " Algorithm name", we are looking for this procedure in the rules module. After editing the module, do not forget to copy the procedure to the clipboard and press the button" "in CD3. Be careful, the same conversion must be open.

That's all for now. This information is already enough for a 1C programmer to independently master KD3 and maintain a modern method of synchronization between 1C bases in working order. If there are white spots, ask, the article will be supplemented and you can return to it if you forgot something.

Well-known links to documentation on KD3:

• 1C-Training Center No. 3, "Data Conversion 3.0" - http://www.1c-uc3.ru/konvert30.html

You can expand the scope of application of KD3 using these publications:

• - configurations of previous versions on platform 8.2 and below become ED compliant.

Save time and use ready-made rules for latest versions configurations can be here

• - extended functionality, bug fixes.

In this article I will describe my, so far small, experience in organizing data exchange through the universal EnterpriseData format.

In my case, the exchange is configured between the configurations "Trade Management 11.2" (hereinafter UT) and "Enterprise Accounting 3.0.43" (hereinafter BP). The exchange is one-way, from UT to BP. Prior to the upgrade from Trade Management 11.1 to version 11.2, data exchange was configured using the Data Conversion 2.0 configuration. However, after switching to "11.2" in "Trade Management", errors appeared in the work of users. The procedure for updating the exchange rules was carried out, but this did not give any result. The debugger showed that the problem was communication. It was decided to remove the communication setting in both configurations and set it up again.

Both "Trade Management" and "Enterprise Accounting" work for us in a client-server version. I started setting up synchronization with UT. I executed it in such a way that the data was unloaded from UT to a file. That is, synchronization via a network directory. In the power supply unit, I set up the exchange in such a way that no data is unloaded from the power supply unit.

An error occurred when calling the context method (Check): Error checking XDTO data:
The structure of the object "/ Counterparty's Bank Account / Bank" does not correspond to the type: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)
Checking the "BIC" property:
Shape: Element
name: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1) BIC
type of:
Required property missing
Object: Contract with counterparty No. ...

To analyze the error, I clicked on the icon "Composition of the data to be sent" and in the list of contractors registered for dispatch, I found an agreement under which an error appeared. Opened a contract, remembered the counterparty's bank account specified in the contract. Then I went over to the bank accounts registered for shipment. It turned out that the required account is not in the list of registered ones. I repost the problem bank account and contract. After that, I manually registered the required bank account.

I tried to synchronize data from UT again. This time, the data was successfully unloaded. V network folder formed XML file containing data for transfer from UT to BP.

The next step is to load data from a file into the Enterprise Accounting Department. In the "Enterprise Accounting" configuration, I pressed the "Synchronize" button, a processing form with the message "Data analysis in progress" was opened. A little later, the message changed to "Unloading data". At the same time, the indicator and counter showed that more than 80 thousand objects were being unloaded from the power supply unit. This confused me, because I indicated in the settings that nothing should be unloaded from the power supply unit. The processing took quite a long time and ended with an error:

Event: Data Exchange
(SharedModule.LongedOperations.Module (371)): Background job workflow terminated abnormally
CallException (ErrorText);

To localize the error, I tried to change the synchronization settings and operation options of the BP base. As a result, when I switched the database to the file version, the system worked adequately: the form for comparing two databases opened. After matching the objects, the initial synchronization was successful. Then I switched the database back to the client-server version.

During the further "run-in" of synchronization, it was necessary to make some changes to the rules for converting objects. Now is the time to use the Data Conversion 3.0 configuration. The online configuration help describes how to work. Articles on the ITS website also helped.

As a result, I loaded the following data into "Data Conversion 3.0":

• Texts of the common module "DataExchangeManagerViaUniversalFormat" from two bases
• Scheme of both bases
• Description of the EnterpriseData format (from any one database)
• Conversion rules

After loading, I opened the rules for converting data, objects, properties in "Data Conversion 3.0". Made the necessary edits for me. Then I used the button "Unload exchange manager module". The module text has been copied to the clipboard. It remains only to insert it into the configuration.

Having experimented with setting the rules in "Data Conversion 3.0", I concluded for myself that in the case when the changes made are insignificant, it is easier to set up the rules directly in the UT and BP configurations, in the common module "DataExchange ManagerVia UniversalFormat". If the edits are serious, such as, for example, adding a new object to the exchange, then you should use the configuration " Data Conversion 3.0 ".

I performed the task of adding the document "Order to supplier" to the exchange plan using " Data Conversion 3.0 ". standard version UT - BP of this document in the exchange plan is not.

Remember that the rules for registering objects for uploading are still configured in the "Data Conversion 2.0" configuration.

These are the first impressions of data synchronization through the universal EnterpriseData format.

P.S. If you have questions and your own observations on the exchange of data through the Universal Format and Configuration " Data Conversion 3.0 ", write in the comments. We will exchange experience.

• Data sync
• Generic EntepriseData Format
• Data Conversion 3.0
• Data Conversion 2.0
• Trade management
• Enterprise accounting

Let's take a look at a simple real-life example. Let's say we have a company that is engaged in wholesale and retail trade, also in this company, as in any other, accounting is conducted. The enterprise has two standard bases, these are UT (trade management) and BP (enterprise accounting), respectively, each of the bases maintains its own accounting, in the UT managerial to reflect all transactions related to trade, in the BP accounting. In order not to do double work, i.e. do not create the same documents in two bases (after all, the movements must be for management and accounting) we will just set up the synchronization between these bases.

We will set up data exchange one-way, from UT ---> BP. It is also possible to set up a two-way exchange, but in practice this is not so often required, so we will not consider it in our example.

Preparatory steps for setting up the exchange in the BP

Let's start setting up synchronization, first go to the 1C "Enterprise Accounting 3.0" database (receiver), we need to check if synchronization is enabled for this database, in order to do this, we first need to go to the database. As soon as the base opens, go to the tab "Administration" ---> "Data synchronization settings"

A new tab opens in front of us, it must be filled in the same way as in the screenshot below, with the exception of the infobase prefix. The prefix should consist of two letters, you can set any one, but according to the 1C standard it is better to set the prefix by the name of the configuration, that is, for "Enterprise Accounting" the prefix will be "BP". If you set up complex exchanges and there are several accounting databases, then the prefixes should clearly differ from each other, here you can use the first two letters of the organization's name as an abbreviation.

We continue to configure data synchronization in UT

After we have done all the necessary actions in the receiver base (BP 3.0), in order to continue setting up the data exchange, we need to open the source base (UT 11.1). We go to the "Administration" tab, on the left in the menu, select the item "Data synchronization settings"... If synchronization is not enabled, then enable it using the checkbox, and do not forget to specify the prefix of the source base. Once we have completed all points 1-4 as shown in the image below, you must click on the "Data Synchronization" hyperlink (point 5).

In the new window that appears, you need to click on the green plus sign (Configure data synchronization), in the drop-down menu, select the item "Enterprise Accounting 3.0".

Configuring important points in the exchange of data between UT and PSU

Now we see a window with setting up data synchronization in 1C, select the "Specify settings manually" item and click "Next".

We continue to configure the exchange of data in 1C, on the next tab we need to select the option of connecting to the receiver infobase ( direct connection to the program), connection parameters (on this computer or in local network), the directory where the receiver base is located, as well as the necessary authentication data (username and password in the base).

On the next page, we must fill in the rules for sending and receiving data from the BP 3.0 configuration (receiver). Click "change the rules for uploading data."

The "Data sending rules" window has opened before us, in it we set the following parameters:

• Which NSI will be sent (in our example, we are only interested in documents and the NSI used in them, so we went to the appropriate item, if you select the first item "Send all", then all directories will be reloaded along with the documents, often if the information is not used in the documents, then it is useless for the receiver, because it does not affect the accounting in any way)
• From what date to send all information (we will not consider manual synchronization in this article)
• For which or which organizations to send data to (in our example, we chose one organization IE "Entrepreneur")
• Rules for the formation of contracts
• Generalized warehouse
• Whether to fold documents in the warehouse

After we have made the settings, click "Save and Close".

Since in our example we are setting up and using a one-way exchange, from UT to BP, then the settings of the rules for obtaining data from "Enterprise Accounting 3.0" are not of interest to us, so click "Next".

In a new window, we are invited to configure the rules for the receiver base (BP). In point 1, we call our base some name, give it a prefix. The PREFIX should be the same as we set it in the BP database itself at the beginning of this article, if the prefixes differ, data synchronization in the 1C program will not work. After that we press point 2, and then point 3.

In paragraph 3, we need to allow documents to be posted when they are loaded into the database. Click "Save and Close".

Now the window should look something like the one shown below, click "Next".

This window contains reference information about the created synchronization in 1C. Just click the "Next" button. If the program displays an error when setting up data synchronization, then you need to contact us so that our 1C specialist will help you right now!

In the next step the program will offer to perform synchronization immediately after creating the data exchange settings... Let's agree with this and click "Finish".

A window will appear in front of you in which you will see information about how the synchronization is proceeding. If the receiver base is not empty, i.e. since accounting has already been kept in it, the user in the 1C program will be prompted to make a comparison of objects manually. Comparison of objects in 1C during data synchronization is a comparison of the same objects of the receiver with the same objects in the source.

Let's consider an example, let's say in UT there is a counterparty with the name "PharmGroup LLC" and TIN 1234567, and BP also has a counterparty with TIN 1234567, but the name "PharmGroup", if we do not compare these two objects when comparing data at the synchronization stage, then after synchronization in the receiver (Enterprise Accounting 3.0), we will have two counterparties with TIN 1234567 and two names "PharmGroup LLC" and "PharmGroup", respectively. In order to avoid such situations, a mechanism for matching objects was invented.

In our example, the receiver base is empty, and therefore the object mapping windows did not open for us. But after performing some operations, the system will certainly prompt the user to add some additional data and display the following window. We do not need to transfer any additional data, we have already configured everything that is needed before, so at this step we select "Do not add documents to sending". Click "Next".

The final stage of data exchange between 1C

At the final stage, the program will display the following window, in which the user will be informed that the synchronization was successful, click "Finish". This completes the synchronization between the bases in the one-way exchange from "Trade Management 11.1" (UT) to "Enterprise Accounting 3.0" (BP).

Automated systems management in most cases consists of separate databases and often have a geographically distributed structure. At the same time, correctly implemented data exchange is a prerequisite for the effective operation of such systems.

At the same time, the initial exchange setup 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 consider in this article.

Data exchange in the 1C environment allows:

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

* In the case when 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, the exchange of data between 1C UT and 1C Accounting does not require uploading management data to the routine accounting database, i.e. synchronization in 1C will be incomplete here.

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

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

Revealing the composition of exchange 1C

The objects of exchange can be conditionally divided into “source” and “receiver”. At the same time, they can perform two roles simultaneously, which will be called - bilateral exchange. Determination of the source and destination occurs in a logical way, depending on the need or on functionality system. *

* For example, when integrating WA: Financier, a solution for financial accounting and treasury process management, 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.

Further, on the basis of the received and recorded requirements from the users, a list of data for exchange is created, their volume, requirements for the exchange frequency are determined, the process of working with errors and processing of 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 configurations of 1C databases, with a clear master-slave control structure for each exchange pair. As an element of the technological platform, the RIB, in addition to data, can transfer changes to the configuration and administrative information of the database (but only from the master to the 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 development systems. The exchange is carried out by converting data into a universal xml format in accordance with the "Exchange Plans".

EnterpriseData

• The latest development of the company 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 exchange-related enhancements. Previously, when a new configuration was included in the system, it was necessary to implement a mechanism for importing and exporting data, both for it and for existing systems. Now the systems supporting EnterpriseData do not need any modifications, having only one "entry-exit" point.

Definition of transport (exchange protocols)

For the system based on the 1C: Enterprise 8 platform, a wide range of opportunities is provided for organizing exchange with any information resources through generally accepted universal standards (xml, text files, Excel, ADO connection, etc.). Therefore, when defining a transport for exchange data, one should proceed from the capabilities of a third-party system database.

Synchronization of directories

The main principle of effective synchronization of directories is the presence of one entry point. But if we are talking about working with reference books that were historically filled in according to different rules, it is necessary to clearly define the synchronization fields to bring the exchange to a “common denominator”. *

* At this stage, it may be necessary to carry out work on the normalization of the reference data on the side of the data source. Depending on the state of the reference books and their volume, the process of matching elements, recognizing, detecting 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 from the integrator (owner of the standardization method of reference data) and from the customer's side.

Setting rules

The ability to display data from source systems in receivers depends on correctly specified exchange rules. The rules, presented in the xml format, regulate the correspondence of the key attributes of the source-destination objects. The solution "1C: Data Conversion" is designed to automate the creation of rules for the implementation of both a one-time exchange and a permanent one.

Ensures no data loss when exchanging the Exchange Plan. This is an integral part of any configuration on the 1C: Enterprise platform, which fully describes the procedure for exchanging 1C: data composition (documents with "identification" details) and nodes ( information bases transmitters-receivers), as well as the activation of the RIB for the selected directions of exchange.

Any change in the data entered in the Exchange Plan is recorded and receives a sign of “change”. Until the changed data match each other in the transmitter-receiver nodes, the flag will not be cleared, and the system will send control messages to both nodes. After unloading the data and confirming their full correspondence in both systems, the sign is reset.

Exchange schedule in 1C

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

Having considered the standard exchange implementation process, let's pay attention to the factors that will require improvements at different stages:

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

Since even standard actions for the implementation of the primary data exchange require expert knowledge, they are recommended to be carried out with the participation of 1C specialists. Only after completing all the above steps should you proceed to setting up the exchange in the configuration. Let's consider the integration of databases using the example of "1C: UPP" and "1C: Retail" (according to the same scheme, the exchange with "1C: UT" is configured). Also, the typical synchronization includes the exchange of the SCP - the SCP, 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 ..." (the choice of direct exchange with "Retail" often threatens with errors at the level of COM objects). Let's pay attention to the service message "This feature is not available".

To solve this problem, you must select "Communication settings"

... and tick the box. Next, we ignore the error message.

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

Before configuring the settings for connecting through a local or network directory, make sure that there is enough space on the disk for the directory. Although, as a rule, it does not take 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, the offers to configure the connection via an FTP address and via e-mail ignored by clicking "Next".

In the settings, we manually put down prefixes - the conventions of the bases (as a rule, BP, UPP, RO), set the rules and the start date of data upload. The prefix will be indicated in the name of the documents to indicate the base in which they were created. If the unloading rules are not edited, the data will be unloaded by default for 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.

Retail menu.

Check the box and select "Synchronization".

We make the "reverse" setting by choosing Manufacturing Enterprise Management.

Load the settings file created in the SCP.

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

We act in the same way as in the UPP.

Verification data comparison (Manual data comparison is recommended at the preparatory stage, since this work can become the most time-consuming in the process of implementing the exchange). The mapping window is opened by double click mice.

In case of an error in synchronization, "Details ..." will be replaced by "Never ...".

"In detail ..." opens a registration log with updated information on the exchange.

Ready.