Books, booklets, articles

1C:Enterprise 8. Data conversion: data exchange between application solutions (with application on CD-ROM) (article 4601546049094)

"1C:Enterprise" is a universal system for automating enterprise activities and can be used to solve various tasks management and accounting. Currently, a large number of standard and specialized solutions have been developed on the 1C:Enterprise platform, which can work in close integration with other solutions, both on this platform and with software third party manufacturers.

Great importance For efficient work has the ability to organize exchange between various information systems. The 1C:Enterprise platform provides a variety of tools for data exchange and integration of application solutions.

The book examines in detail data exchange in XML format, which is today a generally accepted means of presenting data. Procedures for developing rules are described, the application of which will ensure the transfer of information from one information system to another, including data exchange between standard 1C:Enterprise configurations.

The book is accompanied by a CD containing demo information bases with examples of exchange rules and the “1C:Enterprise. Data Conversion” configuration.

Attention! In the first printing there was a technical defect at the end of the book. Corrected pages can be

Currently, the remnants of the defect have been withdrawn from sale and a corrected edition has been released.
We apologize for the inconvenience and are ready to replace defective items free of charge.

Questions about the literature of the publishing house "1C-Publishing" can be sent to: [email protected].

Buy:

Contact the 1C partner who serves your organization and place an order, telling him the code assigned to the book (shown in the table below). You can also purchase the book from others partners of the company "1C".

• in the online store "1C-Interest" (delivery of books by courier, Russian Post, DHL, EMS)
• V bookstores your city

See also:

Book cost

Code	Name	Recommended retail price, rub. *	Dealer	Permanent partner	Distributor
4601546049094	1C:Enterprise 8. Data conversion: data exchange between application solutions (with application on CD-ROM) (article 4601546049094)	240	150	135	120

Book structure

Introduction

Chapter 1. General principles for setting up rules

Chapter 2: Using Rules

Chapter 3. Automatic creation of rules

Chapter 4. Rule structure

Chapter 5. Detailed study of the rules

Chapter 6. Event Handlers

• Options
• "Conversion" handlers
• Handlers "Data upload rules"
• Handlers "Object conversion rules"
• Handlers "Property group conversion rules"
• Handlers "Property conversion rules"

Chapter 7. Search Fields

Chapter 8. Data cleaning rules

Chapter 9. Algorithms and Queries

Chapter 10. Typical examples of rules. Troubleshooting

• Converting transfers
• Converting directories
• Converting documents
• Converting information registers
• Chart of Accounts Conversion
• Converting a characteristic type plan
• Converting calculation types plan
• Conversion of constants 1C:Enterprise 7.7
• Conversion of accounting transaction 1C:Enterprise 7.7

Chapter 11. Optimizing Rules

• Data upload rules
• Object conversion rules
• Universal XML Data Interchange processing

1. Introduction.

2. What you will need: 1C configuration: Data conversion 2.* and processing from the package. For Example tasks, let's take configurations 1C: Trade Management 11 and 1C: BP 3.*.

So, to develop rules for uploading data to 1C, you will need the 1C configuration: Object Conversion 2, as well as the processing included in the package.

For example, we have already deployed a conversion database and launched it.

We will write the development of exchange rules between the 1C: Trade Management 11 and 1C: Enterprise Accounting 3 configuration (UT / ACCOUNT exchange rules).

3. We will need Processing to unload the metadata structure and exchange.

The first thing you need to get for development is files with a metadata structure. This is done using processing for unloading the metadata structure included in the object conversion package.

Actually, in the unpacked configuration directory for configurations on controlled forms we are interested in processing MD83Exp.epf. If you need to upload from configurations to usual forms, then MD82Exp.epf processing is used. This is if, for example, you need to get a structure from configurations such as 1C: UT 10, 1C: Management manufacturing enterprise 1.3, 1C: Comprehensive automation 1.1, 1C: Zup 2.5 and so on.

Further, to upload and download data into 1C using our rules, you will need to process “Universal data exchange in XML format” V8Exchan83.epf for configurations on managed forms such as 1C: Trade Management 11.*, 1C BP 3, 1C: ERP 2. * and similar. And accordingly V8Exchan83.epf - for configurations on regular forms.

4. Uploading the metadata structure of the configuration 1C: Trade Management 11.3 and 1C: Enterprise Accounting 3.0.*

Let's start by downloading the metadata structure from the 1C: Enterprise Accounting 3 configuration.
Let's open processing MD83Exp.epf

In the processing form there are additional settings where we can enable or disable the option to upload registers and movements to 1C. There is also a choice of where the upload will take place: on the 1C server or “on the client.” Specify the name of the file where the data structure will be uploaded. In a similar way, we unload the metadata structure of the Trade Management 11 configuration.

Now you need to upload the configuration to the conversion database. This point can be reached both from the list of configurations and from the list of conversions. Let's just boot from the desktop:

In the dialog box, load the BP structure:

And similarly - the structure of Trade Management.

Once the download is complete, a dialog box will appear where you can specify a name that is convenient for you.

6. Creating conversion rules in 1C on specific example tasks.

Next, go to “Setting up object rules”, where we create a new setting.
In the conversion creation dialog box, select the “source” configuration and the “destination” configuration (which you previously loaded) and click OK.

Since in this article I planned to show creation “from scratch” and “without garbage,” I remind you that we do not create anything automatically. No prototypes.

We won’t do anything in this dialog box, just click “Close”.

Let's create rules for uploading not one document into one, but one type into another, for example, the document Sales of Goods and Services from UT 11 with the necessary reference books into the document Receipt of Goods and Services in BP 3.

So, we create a new PKO (the rule for converting objects in 1C)

Select the source Sales of Goods and Services and the destination Receipt of Goods and Services and click OK.
In this case, a dialog box will appear, where we again refuse the automatic creation of PKS (Property Conversion Rules). Next, we will select only the necessary ones.

But to the proposal to create DVP (data upload rules), we answer “Yes”.

PVDs are created, which will be reflected in the processing of the universal XML exchange for selection:

Data conversion rules with empty property conversion rules will also be created.

Moreover, it can be seen that by default the software is offered to be searched by the internal object identifier. This is indicated by the magnifying glass near the PCO. We will do our own search, and we will do it by document number and date at the beginning of the day.

We remove the search by UIO:

Now let's start comparing the necessary properties (details) of the object. To do this, click “Synchronize Properties” (label “1” on the screen). We remove the recursive creation of rules (“2”). Remove all the marked details ("3"). And we will choose on our own what we need.

For example, select what you need:

I draw your attention to the fact that we will make the PKS of the counterparty into the organization, and the organization into the counterparty, and we will also compare some details that do not match by name, for example, “Currency” and “Document Currency”.

Where we see that there are no conversion rules yet.

Let's start going through the details and describing them. First, we set up a document search as I wrote earlier, upload and search for a document at the beginning of the date, and change the numbering. We will replace the first three characters with our prefix “UTB”. And since the numbering in BP and UT is 11 characters each, we make a composite number: our prefix and 8 characters from the source. An example in the screenshot below.

We always upload documents unloaded and without movement. We assume that the documents will be processed in the receiver after verification by the user.

To do this, setting PKS as not carried out, 0 or 1, we use it as a Boolean.

Using currency as an example, we create an object conversion rule for PKS. At the same time, we believe that there are currencies in both databases, and they should be synchronized by code. Therefore, we will not create all PKS in the Currency PQS, but will only add a Search Code. Those. We refuse the offer to create a PKS for the object.

The created Conversion Rule was substituted into the PQR of the document for the PKS. And the default rule itself is offered by a unique identifier. We fix it, search the code and set the property so as not to create a new object.

As a result, we get the following option:

Next, by analogy, we create PKO and PKS for the remaining details. Moreover, we search for an organization by counterparty and vice versa by TIN. This is roughly what it looks like with minimal details (you can add if necessary).

For PCO Counterparty Agreements, we search by PKS Counterparty, name and owner.

Let's see how to specify the required value in the enumeration type in the PKS. For example, the “Type of Operation” attribute. Here you can use various conditions and substitute values. For example, we need the “type of operation” to always be unloaded “Goods”, in this case it is enough to write the required value in the “forehead” line.

Below is shown how to install without difficulty and in most cases PCS for Mutual Settlement Multiplicity, Mutual Settlement Rate, Accounting Account.

For PKO Nomenklatura, we will leave the search by internal unique identifier. But let me draw your attention to how you can redefine your group. For example, we agree that a new item will be uploaded from the 1C: Trade Management 11 configuration, but it is necessary that the item be collected in a specific group “OurGroup”.

To implement this task, we create another PKO. Let's call it “NomenclatureParent”, which we will indicate in the parent’s PCS in the conversion rule.

We set up two searches: by name, where we strictly indicate the name of our group, and the required property of the “This is a Group” attribute is set to true.

Since we have decided that all of our items fall into our group, there is no need to unload groups from UT 11 when unloading. To do this, in the Nomenclature software in the “Before Unloading” event handler, we will set a filter that there is no need to unload groups “Failure = Source. This group;".

In the DRP (data upload rules) for Sales of Products and Services, we will add a filter so that documents marked for deletion are not uploaded. To do this, in the VDP in the “Before Unloading” event handlers, we will write the filter “Failure = Object.DeletionMark;”.

Let's save the developed rules to a file.

7. To summarize: Uploading and loading data using developed data exchange rules.

Open in 1C: Trade Management 11 the processing “Universal data exchange in XML format” V8Exchan83.epf.

The unloading has been completed, now we use the same processing to load into 1C: Enterprise Accounting 3.

Loading completed. Let's check how it loaded. So, the document is loaded, as we wanted - our Organization is loaded into the counterparty, and the counterparty into the organization. Accounting accounts are all downloaded and installed. We got the document number with our prefix and at the beginning of the day. All details that were provided have been filled out.

We check the loading of the items. We see that everything turned out as we planned.

We have created and filled in the details as we intended. There are many subtleties in conversion and some simple but necessary things that help you accurately write the conversion. And this allows you to minimize errors, not spoil existing data and get rid of unnecessary garbage. This is one of the simplest examples. You can also convert one object into many, or, conversely, many into one.

Now there is data conversion 3, it solves other problems. Therefore, conversion 2 is also necessary. Good luck to everyone in learning and mastering.

Of course, if you are a programmer and this is your main job, you can try to write the conversion yourself. But if not, then you should value your time in your field of activity, and ask professionals to perform this task.

Migrating data between different configurations is not a trivial task. As always, there are several solutions, but not all of them are optimal. Let’s try to understand the nuances of data transfer and choose a universal strategy for resolving such issues.

The problem of data migration (we are talking purely about 1C company products) from one solution to another did not arise yesterday. The 1C company understands perfectly well what difficulties developers face when creating migrations, so it tries in every possible way to help with tools.

During the development of the platform, the company introduced a number of universal tools, as well as technologies that simplify data transfer. They're built into everything standard solutions and the problem of migrations between identical configurations has generally been resolved. The victory is once again confirmed by the close integration of standard solutions.

With migrations between non-standard solutions, the situation is somewhat more complicated. A wide selection of technologies allows developers to independently choose the optimal way to solve a problem from their point of view.

Let's look at some of them:

• exchange via text files;
• use of exchange plans;
• etc.

Each of them has its own pros and cons. To summarize, the main disadvantage will be its verbosity. Independent implementation of migration algorithms is fraught with significant time costs, as well as a long debugging process. I don’t even want to talk about further support for such decisions.

The complexity and high cost of support prompted the 1C company to create universal solution. Technologies that make it possible to simplify the development and support of migrations as much as possible. As a result, the idea was implemented in the form of a separate configuration – “Data Conversion”.

Data conversion - standard solution, independent configuration. Any user with an “ITS:Prof” subscription can download this package completely free of charge from the user support site or the ITS disk. Installation in progress in a standard way- like all other standard solutions from 1C.

Now a little about the advantages of the solution. Let's start with the most important thing - versatility. The solution is not tailored to specific platform configurations/versions. It works equally well with both standard and custom configurations. Developers have a universal technology and a standardized approach to creating new migrations. The versatility of the solution allows you to prepare migrations even for platforms other than 1C:Enterprise.

The second big plus is visual aids. Simple migrations are created without programming. Yes, yes, without a single line of code! For this alone, it’s worth spending time learning the technology once, and then using invaluable skills repeatedly.

The third advantage I would note is the absence of restrictions on data distribution. The developer himself chooses the method of delivering data to the receiver configuration. There are two options available out of the box: uploading to an xml file and direct connection with information base (COM/OLE).

Studying architecture

We already know that data conversion can work wonders, but it is not yet entirely clear what they mean technical advantages. The first thing you need to understand is that any data migration (conversion) is based on exchange rules. Exchange rules are a regular xml file describing the structure into which data from the information security will be uploaded. The service processing that uploads/downloads data analyzes the exchange rules and performs the upload based on them. During loading, the reverse process occurs.

The “CD” configuration is a kind of visual constructor with the help of which the developer creates exchange rules. It does not know how to download data. Additional external service processing included in the CD distribution package is responsible for this. There are several of them (XX in the file name is the platform version number):

• MDXXExp.epf- processing allows you to download a description of the structure information base in xml file. The structure description is loaded into the CD for further analysis and creation of exchange rules.
• V8ExchanXX.epf- uploads/downloads data from the information base in accordance with the exchange rules. In most typical configurations, processing is present out of the box (see the “Service” menu item). Processing is universal and is not tied to any specific configurations/rules.

Okay, now, based on all of the above, let’s define the stages of developing a new conversion:

1. Definition of the task. It is necessary to clearly understand what data needs to be transferred (from which configuration objects) and, most importantly, where to transfer it.
2. Preparation of descriptions of configuration structures (Source/Sink) for subsequent loading into the CD. The problem is solved by service processing MDXXExp.epf.
3. Loading prepared descriptions of structures into information security.
4. Creating exchange rules using a visual CD tool.
5. Performing upload/download according to the created data conversion rules using V8ExchanXX.epf processing.
6. Debugging exchange rules (if necessary).

The simplest conversion

For the demonstration we will need two deployed configurations. I decided to go with the option: “Trade Management” 10th edition and a small home-written solution. The task will be to transfer data from the standard “UT” configuration. For brevity, let’s call the self-written solution “Sink”, and the trade management “Source”. Let's start solving the problem by transferring elements from the “Nomenclature” directory.

First of all, let's take a look at the data conversion scheme and re-read the list of actions that need to be done. Then we launch the “Source” configuration and open the MD82Exp.epf service processing in it.

The processing interface does not have an abundance of settings. The user only needs to indicate the types of metadata objects that will not be included in the structure description. In most cases, these settings do not need to be changed, because There is no particular point in unloading movements using accumulation registers (as an example).

It is more correct to form the movement while holding documents in the receiver. All movements will be made by the document itself after the transfer. The second argument in defense of the default settings is the reduction in file size with uploading.

Some documents (especially in standard configurations) generate movements across multiple registers. Unloading all this stuff will make the resulting XML file too large. This may complicate subsequent transportation and loading into the receiver base. The larger the data file, the more RAM will be required to process it. During my practice, I had the opportunity to encounter indecently large upload files. Such files completely refused to be parsed using standard tools.

So, we leave all the default settings and upload the configuration description to a file. We repeat a similar procedure for the second base.

Open the CD and select in the main menu “Directories” -> “Configurations”. The directory stores descriptions of the structures of all configurations that can be used to create conversions. We load the configuration description once, and then we can use it multiple times to create different conversions.

In the directory window, click the button “ Add” and in the window that appears, select the file describing the configuration. Check the “Load into a new configuration” checkbox and click on the “Load” button. We perform similar actions with the description of the structure of the second configuration.

Now you are ready to create exchange rules. In the main CD menu, select “Directories” -> “Conversions”. Add new element. In the window for creating a new conversion, you need to specify: the source configuration (select UT) and the destination configuration (select “Receiver”). Next, open the “Advanced” tab and fill in the following fields:

• exchange rules file name - the created exchange rules will be saved under this name. You can change the file name at any time, but it is best to set it now. This will save time in the future. I named the rules for the demo example: “rules-ut-to-priemnik.xml”.
• name - the name of the conversion. The name can be absolutely anything, I limited myself to “Demo. UT to Receiver.”

That’s it, click “Ok”. Immediately a window appears in front of us asking us to create all the rules automatically. Agreeing to such a tempting offer will give the master a command to automatically analyze the description of the selected configurations and independently generate exchange rules.

Let’s dot the “i’s” right away. The wizard will not be able to generate anything serious. However, this possibility should not be discounted. If it is necessary to establish an exchange between identical configurations, then the services of a specialist will be very useful. For our example, manual mode is preferable.

Let's take a closer look at the “Exchange Rules Settings” window. The interface may seem a little confusing - a large number of tabs crammed with controls. In fact, everything is not so difficult; you begin to get used to this madness after a few hours of working with the application.

At this stage, we are interested in two tabs: “Object conversion rules” and “Data upload rules”. At first, we must configure the matching rules, i.e. compare objects of two configurations. On the second, determine possible objects that will be available to the user for uploading.

In the second half of the “Object Conversion Rules” tab there is an additional panel with two tabs: “Property Conversion” and “ Converting values" The first will select the properties (details) of the selected object, and the second is necessary for working with predefined values ​​(for example, predefined directory elements or enumeration elements).

Great, now let's create conversion rules for directories. You can perform this action in two ways: use the Object Synchronization Wizard (the “” button) or add correspondence for each object manually.

To save space, we will use the first option. In the wizard window, uncheck the group “ Documentation” (we are only interested in directories) and expand the group “ Directories" We carefully scroll through the list and look at the names of reference books that can be compared.

In my case, there are three such directories: Nomenclature, Organizations and Warehouses. There is also a directory called Clients, which serves the same purpose as “ Counterparties"from configuration" UT" True, the master could not compare them due to their different names.

We can fix this problem ourselves. We find in the window “ Object Matches» reference book « Clients", and in the "Source" column select the "Counterparties" directory. Then check the box in the “Type” column and click the “Ok” button.

The Object Synchronization Wizard will offer to automatically create rules for converting properties of all selected objects. The properties will be compared by name and for our demonstration this will be quite sufficient, we agree. The next question will be a proposal to create upload rules. Let's agree to it too.

The basis for the exchange rules is ready. We selected the objects for synchronization, and the rules for converting properties and uploading rules were created automatically. Let’s save the exchange rules to a file, then open the IB “Source” (in my case it’s UT) and launch service processing in it V8Exchan82.epf.

First of all, in the processing window, select the exchange rules we created. We answer the question of loading rules in the affirmative. Processing will analyze the exchange rules and build a tree of objects of the same name available for uploading. For this tree, we can set up all sorts of selections or exchange nodes, by changing which we need to select data. We want to download absolutely all the data, so there is no need to install filters.

After completing the process of uploading data to a file, go to IB “ Receiver" We also open processing in it V8Exchan82.epf, only this time we go to the “Data Loading” tab. Select the data file and click the “Download” button. That's it, the data has been successfully transferred.

Real world problems

The first demo could be misleading. Everything looks quite simple and logical. Actually this is not true. IN real work Problems arise that are difficult or completely impossible to solve using visual means alone (without programming).

In order not to be disappointed with the technology, I prepared several real-life problems. You will definitely come across them at work. They don’t look so trivial and make you look at data conversion from a new angle. Carefully consider the presented examples, and feel free to use them as snippets when solving real problems.

Task No. 1. Fill in the missing details

Suppose we need to transfer the directory “ Counterparties" The receiver has a similar “Clients” directory for this purpose. It is completely suitable for data storage, but it has props “ Organization”, which allows you to separate counterparties by belonging to the organization. By default, all counterparties must belong to the current organization (this can be obtained from the constant of the same name).

There are several solutions to the problem. We will consider the option of filling out the details “ Organization“right in the database” Receiver”, i.e. at the time of data loading. The current organization is stored in a constant, therefore, there are no barriers to obtaining this value. Let’s open the object conversion rule (hereinafter referred to as PKO) “ Clients” (double click on the object) and in the rules setup wizard, go to the “Event Handlers” section. In the list of handlers we will find “ After downloading”.

Let's describe the code for obtaining the current organization and then assigning it to the details. At the time the “After loading” handler is triggered, the object will be fully formed, but not yet written to the database. Nobody forbids us to change it at our discretion:

If NOT Object.ThisGroup Then Object.Organization = Constants.CurrentOrganization.Get(); endIf;

Before filling out the details " Organization"It is necessary to check the value of the attribute " This group" For the reference book " Clients"The hierarchical feature is set, so checking for the group is necessary. Fill in any details in a similar way. Be sure to read the help for other handler options " AfterLoading" For example, among them there is the parameter “ Refusal" If you assign it the value “True”, then the object will not be written to the database. Thus, it becomes possible to limit the objects that can be written at the time of loading.

Task No. 2. Details for the information register

In the directory “ Counterparties"UT configurations, details available" Buyer" And " Provider" Both details are of type “ Boolean” and are used to determine the type of counterparty. In IB “ Receiver”, at the directory “ Clients“There are no similar details, but there is a register of information” Types of Clients" It performs a similar function and can store multiple attributes for one client. Our task is to transfer the values ​​of the details into separate entries in the information register.

Unfortunately, visual means alone cannot cope here either. Let’s start small, create a new software for the information register “ Types of Clients" Do not cite anything as a source. Avoid automatically creating upload rules.

The next step is to create the upload rules. Go to the appropriate tab and click the “ Add" In the window for adding upload rules, fill in:

• Sampling method. Change to “Arbitrary algorithm”;
• Conversion rule. Select the information register “Types of Clients”;
• Code (name) of the rule. Write it down as “Unloading Client Types”;

Now you need to write code to select data for uploading. The parameter “ Data Sampling" We can place a collection with a prepared data set into it. Parameter " Data Sampling” can take on various values ​​- query result, selection, collections of values, etc. We initialize it as a table of values ​​with two columns: client and client type.

Below is the code for the event handler “ Before processing" It initializes the parameter “ Data Sampling” followed by filling in data from the directory “ Counterparties" Here you should pay attention to filling out the column “ Client Type" In “UT” our attributes are of the “Boolean” type, and the recipient is an enumeration.

At this stage we cannot lead them to the right type(it’s not in the UT), so for now we’ll leave it in the form of strings. You don’t have to do this, but I immediately want to show how to cast to a missing type in the source.

DataFetch = New ValueTable(); DataSelection.Columns.Add("Client"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Directories.Accounts.Select(); While SelectingDataFromDirectory.Next() Loop If SelectingDataFromDirectory.ThisGroup Then Continue; endIf; If Data Selection From Directory.Buyer Then NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "Customer"; endIf; If DataFetchFromDirectory.Supplier Then NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Supplier"; endIf; EndCycle;

Let’s save the data upload rule and return to the “ tab Object conversion rules" Let's add for the information register “ Types of Clients” property conversion rules: client and client type. We’ll leave the source empty, and in the “Before unloading” event handler we’ll write:

//For the “Client” property Value = Source.Client; //For the property “ClientType” If Source.Client = "Buyer" Then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; endIf;

In the listing, the details are filled in based on the selected data sample. We simply pass the client as a link, and write the client type in the parameter “ Expression" The data of this parameter will be interpreted in the receiver, and when executed, the prop will be filled with the correct value from the enumeration.

That's it, the exchange rules are ready. The considered example turned out to be quite universal. A similar approach is often used when migrating data from configurations created on the 7.7 platform. A striking example of this is the transfer of periodic details.

Task No. 3. Tricks with table parts

Often you come across tasks that require posting rows from one table section into several. For example, in the initial configuration, services and goods are registered in one tabular part, and in the receiver, the storage of these entities is divided. By visual means again the problem cannot be solved. Here it is convenient to take the solution of the second problem as a basis.

We make a rule for unloading data, specify an arbitrary algorithm, and in the “Before unloading” handler we write a request to obtain data from the tabular part.

To save space, I will not provide the code (you can always refer to the sources) of the request - there is nothing unusual in it. We sort through the resulting selection, and place the sorted results in the already familiar parameter “ Data Sampling" It is again convenient to use a table of values ​​as a collection:

DataFetch = New ValueTable(); //There will be another table part here Data Selection.Columns.Add(“Products”); //Here there will also be a tabular part Data Selection.Columns.Add(“Services”); SelectionData.Columns.Add(“Link”);

Task No. 4. Transferring data to an operation

If an organization uses several accounting systems, then sooner or later there will be a need to migrate data with the subsequent generation of transactions.

In the configuration “ BP“there is a universal document” Operation” and it is ideal for forming more wires. There’s just one problem - the document is made cunningly, and the data cannot be transferred into it so easily.

You will find an example of such a conversion in the source code for the article. The amount of code turned out to be quite large, so there is no point in publishing it in conjunction with the article. Let me just say that uploading again uses an arbitrary algorithm in the rules for uploading data.

Task No. 5. Data synchronization across multiple details

We've already looked at several examples, but we still haven't talked about synchronizing objects during migration. Let's imagine that we need to transfer counterparties and some of them are probably in the receiver database. How to transfer data and prevent duplicates from appearing? In this regard, CD offers several ways to synchronize transferred objects.

The first one is by unique identifier. Many objects have a unique identifier that guarantees uniqueness within a table. For example, in the directory “ Counterparties” there cannot be two elements with the same identifiers. CD makes calculations for this and for all created PCOs, a search by identifier is immediately enabled by default. During the creation of the PCO, you should have paid attention to the image of a magnifying glass next to the name of the object.

Synchronizing using a unique identifier is a reliable method, but it is not always appropriate. When merging directories “ Counterparties”(from several different systems) he won't help much.

In such cases, it is more correct to synchronize objects according to several criteria. It is more correct to search for counterparties by INN, KPP, Name or split the search into several stages.

Data conversion does not limit the developer in defining the search criteria. Let's look at an abstract example. Suppose we need to synchronize directories “ Counterparties” from different information bases. Let’s prepare the PKO and in the object conversion rules settings, check the “ Continue searching search fields if the receiver object is not found by identifier" With this action, we immediately defined two search criteria - by a unique identifier and custom fields.

We have the right to choose the fields ourselves. By checking TIN, KPP, and Name, we will immediately indicate several search criteria. Comfortable? Quite, but again this is not enough. What if we want to change the search criteria? For example, first we search for the TIN+KPP combination, and if we don’t find anything, then we start trying our luck with the name.

Such an algorithm is quite capable of being implemented. In the event handler “ Search fields” we can specify up to 10 search criteria and for each of them define its own composition of search fields:

If SearchOptionNumber = 1 then SearchPropertyNameString = “TIN, KPP”; OtherwiseIfSearchOptionNumber = 2 ThenSearchPropertyNameString = “Name”; endIf;

There are always several solutions

Any task has several solutions, and transferring data between different configurations is no exception. Each developer has the right to choose his own solution path, but if you constantly have to develop complex data migrations, then I strongly recommend paying attention to the “”. You may have to invest resources (time) in training at first, but they will more than pay off on the first more or less serious project.

In my opinion, the 1C company unfairly ignores the topic of using data conversion. During the entire existence of the technology, only one book was published on it: “1C: Enterprise 8. Data conversion: exchange between application solutions.” The book is quite old (2008), but it is still advisable to familiarize yourself with it.

Knowledge of platforms is still necessary

"is a universal tool, but if you plan to use it to create data migrations from configurations developed for the 1C:Enterprise 7.7 platform, then you will have to spend time becoming familiar with the built-in language. The syntax and ideology of the language are very different, so you will have to spend time learning. Otherwise the principle remains the same.

"1C:Enterprise"is a universal system for automating enterprise activities and can be used to solve various management and accounting problems. Currently, a large number of standard and specialized solutions have been developed on the platform" 1C:Enterprises", which can work in tight integration with other solutions, both on this platform and with third-party software.

Of great importance for effective work is the ability to organize exchange between various information systems. Platform" 1C:Enterprise" provides a variety of tools for data exchange and integration of application solutions.

The book examines in detail data exchange in XML format, which is today a generally accepted means of presenting data. The procedures for developing rules are described, the application of which will ensure the transfer of information from one information system to another, including the exchange of data between standard configurations " 1C:Enterprises".

The book is accompanied by a CD containing demo information bases with examples of exchange rules and configuration " 1C:Enterprise. Data conversion".

Book structure

Introduction

Chapter 1. General principles rules settings

Chapter 2. Using Rules

Chapter 3. Automatic creation of rules

Chapter 4. Rule structure

Chapter 5. Detailed study of the rules

Chapter 6. Event Handlers

• Options
• "Conversion" handlers
• Handlers "Data upload rules"
• Handlers "Object conversion rules"
• Handlers "Property group conversion rules"
• Handlers "Property conversion rules"

Chapter 7. Search fields

Chapter 8. Data cleaning rules

Chapter 9 Algorithms and queries

Chapter 10. Typical examples rules Troubleshooting

• Converting transfers
• Converting directories
• Converting documents
• Converting information registers
• Chart of Accounts Conversion
• Converting a characteristic type plan
• Converting calculation types plan
• Conversion of constants 1C:Enterprise 7.7
• Conversion of accounting transaction 1C:Enterprise 7.7

Chapter 11. Rule optimization

• Data upload rules
• Object conversion rules
• Universal XML Data Interchange processing

Data conversion 2.0 and 2.1 is a technological configuration of 1C, implemented on platform versions from 8.1 to 8.3.

The main task of the tool is to write rules for exchange between application solutions 1C 8 and 7. The current version of data conversion today is 3.0.

Data conversion is a very useful configuration; with its help you can solve not only the issue of transferring information from one information base to another, but also, for example, converting information within one database.

The configuration is very convenient to use with .

Data conversion will be useful to any programmer: having the skills to create exchange rules is a serious plus for professional skills.

To learn how to work with the configuration, the solution is best suited practical problems. Try to come up with tasks for yourself, for example: transfer some information from one database to another, turn a sales document into a receipt document, “drive” current balances into accounting in the document “entering balances” and other tasks.

It will be very useful to understand the “standard” exchange rules of 1C 8.3; there you can often find interesting examples of implementing tasks.

To understand the basics, you will need materials, we will consider them below.

Video instructions for conversion

For the basics of setting up data exchange in 1C using the “1C Data Conversion” configuration, see the example in the video:

Materials, textbooks for studying 1C Data Conversion 2.0

There are not too many materials and documentation on the Internet, I tried to collect the most important and interesting materials:

0. First of all, I recommend the free video course by Ilya Leontyev, it is available at link.

1. I would advise first of all to use the built-in help in the configuration. It is really well written and technically well implemented:

2. The second most important source of information is the site http://www.mykod.info/ (the site has closed), specialized specifically in data conversion. There you can download a large number of materials on conversion.

3. Separately, I would like to highlight the textbook - (author - Olga Kuznetsova).