1c data conversion 2. Tasks from the real world

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 typical 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. A wide range of technologies allows developers to independently choose the best way to solve the problem from their point of view.

Let's take a look at 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 is 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 the development and maintenance of migrations as easy 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 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 standard configurations and self-written ones. Developers are provided with 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 visuals. Simple migrations are created without programming. Yes, yes, without a single line of code! Just for the sake of this, it is worth spending time once on learning 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: uploading to an xml file and direct connection to the 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 understand 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. The 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. She does not know how to unload data. Additional external service processing included in the CD distribution is responsible for this. There are several of them (XX in the file name is the platform version number):

  • MDXXExp.epf - processing allows unloading 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 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. 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 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 structure description. 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. Unloading 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 you need random access memory to process it. Over the course of my practice, I have encountered obscenely large upload files. Such files completely refused to be parsed by standard means.

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

Open the CD and select in the main menu "Directories" -\u003e "Configurations"... The reference contains 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 many times to create various conversions.

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

Everything is now ready to create exchange rules. In the main menu of the CD, select "References" -\u003e "Conversions". We add a new element. 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 master 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 bit 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.

At this stage, we are interested in two tabs: "Object conversion rules" and "Data upload rules". At the first, we have to set up 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 \u200b\u200b(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 manually add matches for each object.

Let's use the first option to save space. In the wizard window, uncheck the boxes from 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" UT”. 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 for our demonstration this will be quite enough, 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. The processing will analyze the exchange rules and build a tree of objects of the same name available for unloading. 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. Everything, the data has been successfully transferred.

Real world tasks

The first demo could be misleading. Everything looks quite simple and logical. In fact 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 the directory from UT “ 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 by affiliation with the organization. By default, all counterparties must belong to 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 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 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.EtoGroup Then Object.Organization \u003d Constants.CurrentOrganization.Get (); EndIf;

Before filling in the requisite " Organization"It is absolutely necessary 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, filling in any details. Be sure to read the help on other handler parameters " After Download". For example, among them there is a parameter “ Renouncement". If you assign it 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 to the information register

In the reference “ Contractors"UT configuration, there are details" Customer”And“ The supplier”. 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 \u200b\u200bto 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 to”. In the window for adding upload rules, fill in:

  • Sampling method. Change to “Free Algorithm”;
  • Conversion rule. 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 a code to select data for upload. The parameter “ Data Fetch”. We can put a collection with a prepared dataset in it. The parameter “ Data Fetch”Can take various values \u200b\u200b- query result, selection, collections of values, etc. We initialize it as a table of values \u200b\u200bwith 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 directory" Contractors”. Here you should pay attention to the filling of the column “ Client Type”. In “UT” we have signs of the type “Boolean”, and in the receiver it is a transfer.

At this stage, we cannot bring them to the desired 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 want to show you right away how to cast to a missing type in the source.

DataFetch \u003d NewValuesTable (); FetchData.Columns.Add ("Client"); FetchData.Columns.Add ("ClientType"); FetchDataFromDirectory \u003d Directories.Contractors.Select (); While FetchingDataFromDirectory.Next () Loop If FetchingDataFromDirectory.ThisGroup Then Continue; EndIf; If DataFetchFromDirectory.Customer Then NewRow \u003d DataFetch.Add (); NewString.Client \u003d DataFetchFromDirectory.Link; NewString.ClientType \u003d "Buyer"; EndIf; IfFetchDataFromDirectory.Provider Then NewRow \u003d FetchData.Add (); NewString.Client \u003d DataFetchFromDirectory.Link; NewString.ClientType \u003d "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 \u003d Source.Client; // For property “ClientType” If Source.Client \u003d "Buyer" Then Expression \u003d "Enumerations.ClientTypes.Customer" OtherwiseIf Source.Client \u003d "Supplier" Then Expression \u003d "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 client type 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. This 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 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 again convenient to use a table of values \u200b\u200bas a collection:

DataFetch \u003d 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 for data migration with the subsequent formation of postings.

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. I will 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, search by identifier is turned on by default. During the creation of the PCO, you should have paid attention to the magnifying glass image next to the object name.

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 split the search into several stages.

Data conversion does not restrict the developer in determining the search criteria. Let's consider an abstract example. Suppose we need to synchronize directories “ Contractors”From different information bases. Let's prepare the POC and set the checkbox “ Continue searching in the search fields if the target 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. Having noted the INN, KPP, Name, we will immediately indicate several search criteria. Conveniently? 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.

It is quite possible to implement such an algorithm. 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 \u003d 1 then SearchPropertyNameString \u003d “INN, KPP”; OtherwiseIf SearchVariantNumber \u003d 2 Then SearchPropertyNameString \u003d "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 highly recommend paying 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. During 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 get acquainted 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 learning. Otherwise, the principle remains the same.

Conversion of data 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 information base 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.

Practical problems are best suited for learning to work with configuration. 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 accounting in the document "input of 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 of the implementation of tasks.

You will need materials to grasp the basics, 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, tutorials for studying 1C Data Conversion 2.0

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

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

1. I would recommend using the built-in help in the configuration first. 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), specialized just in data conversion. There you can download a large number of conversion materials.

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

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 2 objects, 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 (the rules for the exchange of UT / ACC).

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

The first thing 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 the processing of 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: Comprehensive automation 1.1, 1C: Zup 2.5 and so on.

Further, already 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. Uploading 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 Administration.

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

6. Creating conversion rules for 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, a document of Sales 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 / Services and the receiver of Receipt of Goods / Services and click OK.
At the same time, a dialog box will appear, where again we refuse to automatically create a PCC (Property Conversion Rules). Next, we will select only the necessary ones.

But to the proposal to create a PVD (data uploading 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 for the UIO:

Now let's start matching the required properties (attributes) of the object. To do this, click "Synchronize Properties" (label "1" on the screen). We remove the recursive creation of rules ("2"). Remove all 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 document search as we wrote earlier, we upload and search for a 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 is set as not carried out, 0 or 1, we use it as a boolean.

Using the currency as an example, create an object conversion rule for the PCS. At the same time, we believe that there are currencies in both bases, and they should 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 PQS of the document for the PKS. And the rule itself is proposed by default by a unique identifier. Fix it, search by code 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 roughly how it looks with minimal details (you can add it if necessary).

For PKO Contracts of contractors, 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 line "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, we will leave the search by the internal unique identifier. But I'll draw your attention to how you can redefine your group. For example, we agree that a new item will be unloaded from the 1C: Trade Management 11 configuration, but it is necessary that the item be collected in a specific "OurGroup" group.

To accomplish this task, we create one more 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 our entire stock list falls into our group, there is no need to unload groups from UT 11 when unloading. To do this, in PKO Nomenclature in the “Before Unloading” event handler, set a filter that it is not necessary to unload the “Refusal \u003d Source. This group;".

In 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 PVA, we will write the filter "Refusal \u003d 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. So, the document is uploaded, as we sought - 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 nomenclature. 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. 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 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 professionals to execute.