Converting data exchange between application solutions. Real world tasks

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

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

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

The configuration is very convenient to use when.

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

For learning how to work with configuration, the best solution is practical tasks... Try to come up with tasks for yourself, for example: transfer any information from one database to another, turn a sales document into a receipt document, "drive" current balances into accounting in the document "input balances" and other tasks.

It will be very useful to understand the "typical" exchange rules 1C 8.3, there you can often find interesting examples implementation of tasks.

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

Video conversion instructions

The basics of setting up data exchange in 1C using the "1C Data Conversion" configuration, for example, see the video:

Materials, textbooks for studying 1C Data Conversion 2.0

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

0. First of all, I advise Ilya Leontyev's free video course, it is available at link.

1. I would advise you to use the built-in help in the configuration first of all. 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 been closed), which is specialized in data conversion. There you can download a large number of conversion materials.

3. Separately, I would like to highlight the manual - (by Olga Kuznetsova).

Books, brochures, articles

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

"1C: Enterprise" is a universal system for automating enterprise activities and can be used to solve various management and accounting tasks. 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.

The ability to organize exchange between different information systems is of great importance for effective work. The 1C: Enterprise platform provides a variety of tools for data exchange and integration of applied solutions.

The book describes in detail the exchange of data in the 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 data exchange between typical 1C: Enterprise configurations.

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

Attention! In the first edition, a technical defect was allowed at the end of the book. The corrected pages can be

Currently, the remnants of the marriage are withdrawn from sale and a revised edition has been released.
We apologize for any inconvenience caused and are ready to replace defective copies free of charge.


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

Buy:

Contact a 1C partner who serves your organization and place an order by 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)
  • in bookstores in 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 applied solutions (with an application on CD-ROM) (article 4601546049094) 240 150 135 120

Book structure

Introduction

Chapter 1. General principles of setting up rules

Chapter 2. Using Rules

Chapter 3. Automatic rule creation

Chapter 4. Structure of the rules

Chapter 5. Detailed study of the rules

Chapter 6. Event Handlers

  • Options
  • Conversion handlers
  • Data Upload Rules handlers
  • Object Conversion Rules Handlers
  • Property Group Conversion Rules Handlers
  • Property Conversion Rules Handlers

Chapter 7. Search Fields

Chapter 8. Data cleansing rules

Chapter 9. Algorithms and Queries

Chapter 10. Typical examples of rules. Workaround

  • Converting enumerations
  • Converting directories
  • Converting documents
  • Converting information registers
  • Conversion of chart of accounts
  • Converting a Chart of Property Types
  • Converting a Chart of Calculation Types
  • Converting constants 1C: Enterprise 7.7
  • Conversion of accounting transactions 1C: Enterprise 7.7

Chapter 11. Rule Optimization

  • Data upload rules
  • Object conversion rules
  • Generic XML Data Interchange Processing

1. Introduction.

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

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

For example, we have already deployed the conversion base and launched it.

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

3. We will need Processing for unloading the metadata structure and exchange.

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

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

Further, for uploading and downloading 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 the like. And accordingly V8Exchan83.epf - for configurations on regular forms.

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

Let's start by unloading 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 unload registers and movements in 1C. There is also a choice where the unloading will take place: on the 1C server or "on the client." We indicate the name of the file where the data structure will be unloaded. In the same way, we unload the configuration metadata structure Trade Management 11.

Now you need to load the configuration into the conversion database. You can come to this point both from the list of configurations and from the list of conversions. Let's just load from the desktop:

Load the BP structure in the dialog box:

And similarly - the structure of the Trade Office.

At the end of the download, a dialog box will appear where you can specify a name convenient for you.

6. Creation of conversion rules in 1C on specific example tasks.

Next, go to the "Setting up object rules", where we create a new setting.
In the dialog box for creating a conversion, select the "source" configuration and the "receiver" configuration (which were previously loaded) and click OK.

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

We will not do anything in this dialog box, just click - "Close".

Let's create rules for unloading not one document into one, but one type into another, for example, the Document of the Implementation of Goods / Services from UT 11 with the necessary reference books to the document Receipt of Goods / Services in BP 3.

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

Select the source of Sale of Goods and Services and the receiver of Receipt of Goods and Services and click OK.
In this case, a dialog box will appear, where again we refuse to automatically create a PCS (Property Conversion Rules). Next, we will select only the necessary ones.

But to the proposal to create a PVD (data unloading 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 the POC by default is proposed to search by the internal identifier of the object. This is indicated by a magnifying glass near the PKO. We will do our search, and we will do it according to the document number and date at the beginning of the day.

We remove the search by UIO:

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

For example, select the necessary:

I draw your attention to the fact that we will make the PCS of the counterparty to the organization, and the organization to the counterparty, and we will also compare some details that do not match by name, for example, "Currency" and "Currency of the document".

Where we see that there are no conversion rules yet.

Let's start to go through the details and describe. First, we set up the search for the document as we wrote earlier, we do the unloading and search for the document at the beginning of the date, and we will change the numbering. We will replace the first three characters with our own prefix "UTB". And since in BP and UT there are 11 characters each, we make a composite number: our prefix and 8 characters from the source. An example is shown below.

The unloading of documents is always done without being posted and without movement. We assume that the documents will be posted in the receiver after verification by the user.

To do this, the PCN, setting as not carried out, 0 or 1, we use as a boolean.

Using the currency as an example, create an object conversion rule for the PCS. At the same time, we believe that currencies are available in both bases, and they must be synchronized by code. Therefore, in the PKO currencies we will not create all the PCS, but only add the Code for the search. Those. we refuse the proposal to create a PCS for the object.

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

As a result, we get the option:

Further, by analogy, we create for the rest of the requisites PKO and PKS. Moreover, we set the search for an organization by counterparty and vice versa by TIN. This is approximately how it looks with minimal details (you can add it if necessary).

For PKO Contracts of counterparties, we do a search by PKS Counterparty, name and owner.

Let's see how to specify the desired value in the enumeration type in the PCN. For example, the "TypeOperation" attribute. Here you can use various conditions and substitute values. For example, we need the "type of operation" to always be unloaded "Products", in this case, it is enough to write the desired value in a string on the "forehead".

It is shown below how to set without complications and in most cases PKS for Mutual Settlement Frequency, Mutual Settlement Rate, Accounting Accounts.

For PKO Nomenclature, let's leave the search by the internal unique identifier. But I will pay attention to how you can redefine your group. For example, we agree that it will be unloaded new nomenclature from the configuration 1C: Trade Management 11, but it is necessary that the nomenclature was collected in a certain group "OurGroup".

To accomplish 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 two searches: by name, where the name is rigidly indicated for our group, and the mandatory property of the "ThisGroup" attribute is true.

Since we have made a decision that we have all the nomenclature falling into our group, there is no need to unload groups from UT 11 when unloading. To do this, in the PKO Nomenclature in the "Before Unloading" event handler, we will set the filter that it is not necessary to unload the "Refusal = Source" groups. This group;".

In the PVD (data unloading rules) Implementation of GoodsServices, add a filter so that documents marked for deletion are not unloaded. To do this, in the "Before Unloading" event handlers in the PTP, we will write the filter "Refusal = Object. Deletion Mark;".


Let's save the developed rules to a file.


7. To summarize: Upload and download data using the developed data exchange rules.

We open in 1C: Trade Management 11 processing "Universal data exchange in XML format" V8Exchan83.epf.

The unloading took place, now we use the same processing to load it into 1C: Enterprise Accounting 3.


The download is complete. We check what is loaded as. So, the document is uploaded, 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 the details that you have registered are filled in.

Checking the loading of the item. We see that everything turned out as we planned.


We have created and filled in the requisites as we intended. There are many subtleties in the conversion and some simple, but necessary things that help to 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 most simple examples... You can also convert one object into many, or vice versa, many into one.

Now there is 3 data conversion, it solves other problems. Therefore, conversion 2 is also needed. 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 this task ask the professionals to execute.

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

The problem of data migration (we are talking especially about 1C products) from one solution to another did not arise yesterday. The 1C company perfectly understands what difficulties developers face during the creation of 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 are built into everything standard solutions and the problem of migrations between identical configurations was generally 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. Wide choose technologies allows developers to independently choose the best way to solve the problem from their point of view.

Let's consider some of them:

  • exchange via text files;
  • using exchange plans;
  • etc.

Each of them has its own pros and cons. To summarize, the main disadvantage will be verbosity. Self-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 pushed 1C to create a universal solution. Technology that makes it possible to simplify the development and maintenance of migrations as much as possible. As a result, the idea was realized in the form of a separate configuration - "Data Conversion".

Data conversion is a typical solution, self-configuration. Any user with the ITS: Prof subscription can download this package completely free of charge from the user support site or from the ITS disk. Installation is carried out in a standard way - like all other typical solutions from 1C.

Now a little about the pluses 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 typical configurations and self-written ones. Developers have access to 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 visuals. Simple migrations are created without coding. Yes, yes, without a single line of code! Just for the sake of this, it is worth spending time once on learning the technology, and then using invaluable skills many times.

The third advantage I would point out is the absence of restrictions on data distribution. The developer himself chooses the method of data delivery to the receiver configuration. Two options are available out of the box: upload to xml file and direct connection to infobase (COM / OLE).

We study architecture

We already know that data conversion can work wonders, but it is not yet entirely clear what the technical advantages are. The first thing to learn is that any data migration (conversion) is based on the exchange rules. Exchange rules - a regular xml file with a description of the structure into which data from IB will be uploaded. Service processing, which unloads / loads data, analyzes the exchange rules and, based on them, performs unloading. The process is reversed during boot.

Configuration "KD" is a kind of visual constructor, with the help of which the developer creates exchange rules. It does not know how to unload data. Additional external service processing included in the CD distribution kit 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 unload the description of the infobase structure into an xml file. The structure description is loaded into the CD for further analysis and creation of exchange rules.
  • V8ExchanXX.epf- unloads / loads data from the infobase 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 configuration / rules.

Okay, now, based on 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 a description of configuration structures (Source / Receiver) for subsequent loading into the CD. The task is solved by service processing MDXXExp.epf.
  3. Loading prepared descriptions of structures into IB.
  4. Creation of exchange rules using visual CD tools.
  5. Performing upload / download according to the created data conversion rules by using V8ExchanXX.epf processing.
  6. Debugging exchange rules (if necessary).

Simplest conversion

For the demonstration, we need two deployed configurations. I decided to stick with the 10th edition “Trade Management” option and a small self-written solution. The task will be to transfer data from a typical UT configuration. For brevity, let's call a self-written solution “Receiver”, and trade management “Source”. Let's start solving the problem by transferring the elements of the "Nomenclature" reference book.

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 shine with an abundance of settings. The user only needs to specify the types of metadata objects that will not be included in the description of the structure. In most cases, these settings do not need to be changed. there is no special sense in unloading movements in accumulation registers (as an example).

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

Some documents (especially in typical configurations) generate movements across multiple registers. Dumping this entire farm would make the resulting XML file too large. This can complicate subsequent transportation and loading into the base of the receiver. The larger the data file, the more RAM is required to process it. During my practice, I have come across obscenely large upload files. Such files completely refused to be parsed by standard means.

So, we leave all the default settings and export 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 reference contains descriptions of the structures of all configurations, which will help to be used to create conversions. We load the configuration description once, and then we can use it repeatedly to create various conversions.

In the reference window, press the button “ Add”And in the window that appears, select the file with the configuration description. We mark the checkbox “Load to new configuration” and click on the button “Execute loading”. We do the same with the description of the structure of the second configuration.

Now everything is ready to create exchange rules. In the main menu of the CD, select "References" -> "Conversions". Add new item... In the window for creating a new conversion, you need to specify: the source configuration (select UT) and the receiver 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. The file name can be changed at any time, but it is more profitable to set it now. This will save time in the future. I named the rules for the demo: "rules-ut-to-priemnik.xml".
  • name - the name of the conversion. The name can be absolutely anything, I limited myself to “Demo. UT into the Receiver ”.

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

Let's dot the “and” right away. The master will not be able to generate anything serious. However, this feature should not be discounted. If it is necessary to establish an exchange between identical configurations, then the services of the wizard 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 can seem a little confusing - a large number of tabs crammed with controls. In fact, everything is not so difficult, you start to get used to this madness after a few hours of working with the application.

On this stage we are interested in two tabs: "Object conversion rules" and "Data upload rules". At the first, we have to set up the matching rules, i.e. compare objects of two configurations. On the second, to determine the possible objects that will be available to the user for unloading.

In the second half of the "Object conversion rules" tab there is an additional panel with two tabs: "Properties conversion" and " Converting values”. The first will select the properties (attributes) of the selected object, and the second is needed to work with predefined values ​​(for example, predefined catalog elements or enumeration elements).

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

To save space, let's use the first option. In the wizard window, uncheck the boxes from the “ The documents"(We are only interested in reference books) and open 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 reference book Clients, which fulfills the same semantic load as “ Contractors"From the configuration" NS”. True, the master could not match them due to their excellent names.

We can fix this flaw ourselves. We find in the window " Object matching"Reference book" Clients", And in the column" Source "select the directory" Contractors ". Then check the box in the "Type" column and press the "Ok" button.

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

The basis for the exchange rules is ready. We chose the objects for synchronization, and the rules for converting properties and unloading 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 start the service processing in it V8Exchan82.epf.

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

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

Real world tasks

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 by visual means alone (without programming).

In order not to be disappointed in the technology, I have prepared several real problems. You must come across them when working. They do not look so trivial and make you look at data conversion from a new angle. Carefully consider the examples presented, and feel free to use them as snippets when solving real problems.

Problem number 1. We fill in the missing details

Suppose we need to transfer from UT the directory “ Contractors”. The receiver has a similar "Clients" directory for this. It is completely suitable for storing data, but it has the props “ Organization”, Which allows you to separate contractors according to their affiliation with the organization. By default, all contractors must refer to the current organization (it can be obtained from the constant of the same name).

The problem has several solutions. We will consider the option of filling in the requisite “ Organization"Right in the database" Receiver”, I.e. at the time of loading the data. The current organization is stored in a constant, therefore, there is no obstacle to getting this value. Let's open the object conversion rule (hereinafter PCO) “ Clients”(Double click on the object) and in the rules wizard go to the“ Event handlers ”section. In the list of handlers we find “ After loading”.

Let's describe the code for obtaining the current organization with the subsequent assignment to the requisite. At the moment of activation of the "After loading" handler, 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.EtoGroup Then Object.Organization = Constants.CurrentOrganization.Get (); EndIf;

Before filling in the requisite " Organization"It is imperative to check the value of the variable" This group". For the reference “ Clients»The hierarchy flag is set, so a check for a group is necessary. In a similar way, any details are filled in. Be sure to read the help for other handler parameters " After Download". For example, among them there is a parameter “ Refusal". If it is assigned the value "True", then the object will not be written to the database. Thus, it becomes possible to restrict objects for recording at the time of loading.

Problem number 2. Details in the information register

In the reference “ Contractors"UT configuration, there are details" Customer" and " Provider”. Both attributes are of the type “ Boolean”And are used to determine the type of counterparty. In IB " Receiver", At the reference book" Clients"There are no similar details, but there is a register of information" Types of Clients”. It performs a similar function and can store several features for one client. Our task is to transfer the attribute values ​​to separate records of the information register.

Unfortunately, visual means alone cannot cope with this. Let's start small, create a new PKO for the information register “ Types of Clients”. Do not specify anything as a source. Refuse to automatically create unloading rules.

The next step is to form the unloading rules. Go to the corresponding tab and press the button “ Add”. In the window for adding unloading rules, fill in:

  • Sampling method. Change to "Free Algorithm";
  • Conversion rule. We select the register of information "Kinds of Clients";
  • Code (name) of the rule. We write it down as “Unloading Client Views”;

Now you need to write the code to select the data for unloading. The parameter “ Data Fetch”. We can put a collection with a prepared dataset in it. Parameter " Data Fetch”Can take 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 Fetch"Followed by filling with data from the reference book" Contractors”. Here you should pay attention to the filling of the column “ Client Type”. In "UT" we have signs of the "Boolean" type, and in the recipient - enumeration.

At this stage, we cannot reduce them to the required type (it is not in UT), so for now we will leave them in the form of strings. You don't need to do this, but I just want to show you how to cast to a missing type in the source.

DataFetch = NewValuesTable (); FetchData.Columns.Add ("Client"); FetchData.Columns.Add ("ClientType"); FetchDataFromDirectory = Directories.Contractors.Select (); While FetchingDataFromDirectory.Next () Loop IfFetchingDataFromDirectory.ThisGroup Then Continue; EndIf; If DataFetchFromDirectory.Buyer Then NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Buyer"; EndIf; If DataFetchFromDirectory.Provider Then NewRow = DataFetch.Add (); NewString.Client = DataFetchFromDirectory.Link; NewString.ClientType = "Supplier"; EndIf; End of Cycle;

Let's save the data unloading rule and return to the “ Object conversion rules”. Add for the information register “ Types of Clients”Property conversion rules: client and client type. Leave the source empty, and write in the “Before unloading” event handler:

// For the “Client” property Value = Source.Client; // For property “ClientType” If Source.Client = "Customer" Then Expression = "Enumerations.ClientTypes.Customer" OtherwiseIf Source.Client = "Supplier" Then Expression = "Enumerations.ClientTypes.Supplier"; EndIf;

In the listing, the details are filled in based on the data selection made. We transfer the client simply as a link, and write the type of the client in the parameter “ Expression". The data of this parameter will be interpreted in the receiver, and when executed, the variable 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 requisites.

Problem number 3. Tabular section tricks

Quite often you come across tasks that require posting the rows of one tabular section into several. For example, in the initial configuration, services and goods are arranged in one tabular section, and the storage of these entities is separated in the receiver. Again, the problem cannot be solved by visual means. 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 get data from the tabular section.

To save space, I will not cite the code (you can always refer to the source code) of the request - there is nothing unusual in it. We iterate over the resulting selection, and place the sorted results into the already familiar parameter “ Data Fetch”. It is also convenient to use a table of values ​​as a collection:

DataFetch = NewValuesTable (); // There will be one more tabular section DataFetch.Columns.Add (“Products”); // There will also be a tabular section DataFetch.Columns.Add (“Services”); FetchData.Columns.Add (“Link”);

Problem number 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 formation of transactions.

In the configuration “ BP"There is a universal document" Operation”And is ideal for generating more leads. Here is just one non-task - the document is made cunningly, and it is not so easy to transfer the data to it.

An example of such a conversion can be found in the source code for the article. The volume of the code turned out to be quite large, so there is no point in publishing it for the article. Let me just say that the unloading again uses an arbitrary algorithm in the data unloading rules.

Problem number 5. Synchronization of data for several requisites

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

The first one is based on a unique identifier. Many objects have a unique identifier that guarantees uniqueness within a table. For example, in the reference “ Contractors”There cannot be two elements with the same identifier. The CD makes a calculation for this, and for all created PQS, the search by identifier is turned on by default at once. During the creation of the PCO, you should have paid attention to the image of the magnifying glass next to the name of the object.

Synchronizing by unique identifier is a reliable method, but it is far from always appropriate. When combining directories “ Contractors”(From several different systems) it doesn'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 TIN, KPP, Name, or to split the search into several stages.

Data conversion does not restrict the developer in defining the search criteria. Let's look at an abstract example. Suppose we need to synchronize directories “ Contractors”From different information bases. Let's prepare the POC and in the settings of the object conversion rules set the checkbox “ Continue searching the search fields if the target object is not found by the identifier”. By this action, we immediately defined two search criteria - by a unique identifier and custom fields.

We have the right to choose the fields ourselves. Having noted the INN, KPP, 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 look for the INN + KPP link, and if we don't find anything, then we start trying our luck with the name.

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

If SearchVariantNumber = 1 then SearchPropertyNameString = “INN, KPP”; OtherwiseIf SearchVariantNumber = 2 Then SearchPropertyNameString = “Name”; EndIf;

There are always several solutions

Any task has several solutions and data transfer 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 that you pay attention to the "" configuration. Let it first be necessary to invest resources (time) in training, but they will more than pay off on the first more or less serious project.

In my opinion, 1C undeservedly bypasses the topic of using data conversion. For the entire existence of the technology, only one book has been published on it: “1C: Enterprise 8. Data Conversion: Exchange between Application Solutions”. The book is quite old (2008), but it is still desirable 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 getting to know the built-in language. The syntax and ideology of the language is very different, so you have to spend time studying. The rest of 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 tasks. Currently, a large number of standard and specialized solutions on the platform have been developed." 1C: Enterprises"that can work in close integration with other solutions, both on this platform, and with third-party software.

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

The book describes in detail the exchange of data in the 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 typical 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 rule settings

Chapter 2. Using rules

Chapter 3. Automatic rule creation

Chapter 4. Rule structure

Chapter 5. Detailed study of the rules

Chapter 6. Event handlers

  • Options
  • Conversion handlers
  • Data Upload Rules handlers
  • Object Conversion Rules Handlers
  • Property Group Conversion Rules Handlers
  • Property Conversion Rules Handlers

Chapter 7. Search fields

Chapter 8. Data cleansing rules

Chapter 9. Algorithms and Queries

Chapter 10. Typical examples of rules. Workaround

  • Converting enumerations
  • Converting directories
  • Converting documents
  • Converting information registers
  • Conversion of chart of accounts
  • Converting a Chart of Property Types
  • Converting a Chart of Calculation Types
  • Converting constants 1C: Enterprise 7.7
  • Conversion of accounting transactions 1C: Enterprise 7.7

Chapter 11. Optimizing rules

  • Data upload rules
  • Object conversion rules
  • Generic XML Data Interchange Processing

 

It might be helpful to read: