How 1C:Enterprise produce GUID number for objects?

Hi,

I want to ask how plaform does produce Reference - GUID (Unique) number for an object (catalog, document etc).

Does Number or Code of object effect to this number while producing a reference?

Aim of question:
I have two seperate 1C:Enterprise based infobases.
I'm planning to develope exchange plan between two different bases. As unique sync. number planning to use Reference of an object.

Hello, Murat!
It is better to sync by code or date + number if you can be sure that users input them unique. To make sure that numbers that were inputed in different infobase nodes are unique, you should set up prefixes for codes and numbers.

As an example, in infobase node A users input codes 1, 2, 3, the application saves them as A0000001, A0000002, A0000003. In the infobase node B codes will be B0000001, B0000002. Thus when you merge the data in the master node, you will have both A0000001, A0000002, A0000003, B0000001, B0000002 and there will be no conflict between them.

Using Ref attribute leads to the following effect: when you delete an item in the infobase with the Delete marked objects data processor, and create a new one with the same code as a replacement, they will not merge. The difference is in merge effect. If you would like items to merge, you need to use a set of another attributes, if you don't - use Ref.

The algorithm of UUID generation does not depend on Code or Number and you can't extract or replace it in the UUID.

I think ı could not explain my aim.

My situation is, I have main company and many partner companies of main company. So in some parts is businness partner companies should work as main company says. For example, Catalog Items will be as main company says.

So, we planning to use exchange plan (it's useful object type for us). So when writing xml file from main company base, for example for Items, we will convert xml structure of Items to xml structure of Items catalog in partner configuration. So in partner configuration it's yet to use Readxml, that will automatically execute related changes.

So here I should say, that partners' configuration main company produce.

P.S. I forgot to say that: ıtems can be added in main company and in partner too. So I wander, readxml is orientated in reference. Is there may be some conflicts between created references? So for that I asked even if some situation that will effect ref generation.

So, deleted Item in main company, will be deleted in partners too. It's not problem in platform, we have deletionobject.

Basically they are not possible, the chances are as low as 1 duplicate per 3.4E38 of generated GUIDs.

Timofey thanks for information.

I would mind to check some other fields too, for garantee.

For example, readxml returns object of that ıtem. Before write an object I can control some fields in ref of an object. Even if that reference is existing, I think I can compare the fields between CatalogObjectItem.Brand <> CatalogObjectItem.Ref.Brand.

So thanks for information.

This is not necessary. The common practice is if you want to make items not not merged (but still they can be transferred from one node to others), use Ref as the field to compare items. To merge use a set of other fields.