Как передать GUID объекта и записать его в регистр сведений в Конвертации данных 2.1

← На главную

При выполнении задач по слиянию нескольких информационных баз 1С в одну общую базу программисты часто сталкиваются с необходимостью сохранения связей между объектами. Одной из ключевых задач здесь является передача уникального идентификатора (GUID) источника в базу-приемник и его последующая фиксация, например, в специализированном регистре сведений. В рамках этого руководства мы подробно разберем, как реализовать этот процесс с помощью конфигурации «Конвертация данных 2.1».

Зачем передавать GUID отдельно, если он и так передается?

Важно понимать, что по умолчанию механизм Конвертация данных всегда передает внутренний идентификатор объекта. Однако, если в правилах конвертации объекта (ПКО) не установлена галочка «Использовать для идентификации объекта приемника внутренний идентификатор объекта источника», система создаст в приемнике объект с новым GUID, а связь со старым будет потеряна. Если же нам нужно не просто сопоставить объекты, а сохранить «след» старого GUID в отдельном регистре (например, для последующей отладки или работы внешних систем), нам потребуется передать это значение как дополнительное свойство.

Способ 1. Передача через дополнительное свойство (ПКС)

Проанализируем самый простой и наглядный способ — создание виртуального правила конвертации свойства (ПКС) внутри существующего правила конвертации объекта (ПКО).

Рассмотрим последовательность действий:

Откройте необходимое ПКО (например, для справочника Номенклатура).
На закладке «Конвертация свойств» добавьте новую строку.
Оставьте поле «Источник» пустым. В поле «Приемник» также можно ничего не выбирать, если вы не планируете записывать данные непосредственно в реквизит справочника-приемника.
В обработчике «Перед выгрузкой» этого ПКС напишите следующий код:


// Передаем GUID источника в виде строки
Значение = XMLСтрока(Источник.Ссылка);

Обратите внимание, что использование функции XMLСтрока является предпочтительным, так как она корректно сериализует УникальныйИдентификатор в строковый формат, понятный платформе. Если вы используете просто Строка(Источник.Ссылка.УникальныйИдентификатор()), результат будет аналогичным, но первый вариант считается более «стандартным» для механизмов обмена.

Способ 2. Использование параметров объекта

Если вы не хотите загромождать список свойств ПКС виртуальными полями, более профессиональным подходом будет использование механизма «Параметры». Это позволяет передавать сопутствующую информацию «в конверте» вместе с объектом, не привязываясь к его реквизитам.

Разберем, как это настроить:

В ПКО на закладке «Параметры» добавьте новый параметр с именем ГуидИсточника.
В обработчике «Перед выгрузкой» самого ПКО пропишите:


// Заполняем параметр перед отправкой объекта
Параметры.Вставить("ГуидИсточника", XMLСтрока(Источник.Ссылка));

Теперь выясним, как получить эти данные на стороне приемника. Перейдите в обработчик «После загрузки» вашего ПКО. Здесь нам доступна коллекция ПараметрыОбъекта, из которой мы можем извлечь переданное значение и записать его в нужный нам регистр сведений.


// Проверяем наличие параметра и записываем в регистр
Если ПараметрыОбъекта <> Неопределено И ПараметрыОбъекта.Свойство("ГуидИсточника") Тогда
    ГуидСтрокой = ПараметрыОбъекта.ГуидИсточника;
    
    // Пример записи в произвольный регистр сведений
    МенеджерЗаписи = РегистрыСведений.СоответствиеОбъектовБаз.СоздатьМенеджерЗаписи();
    МенеджерЗаписи.ОбъектПриемник = Объект.Ссылка;
    МенеджерЗаписи.ИдентификаторИсточника = ГуидСтрокой;
    МенеджерЗаписи.Период = ТекущаяДата();
    МенеджерЗаписи.Записать();
КонецЕсли;

Способ 3. Использование типового регистра «Соответствие объектов для обмена»

Проанализируем ситуацию, упомянутую опытными разработчиками: в большинстве типовых конфигураций 1С уже существует механизм для хранения связей между объектами разных баз. Это регистр сведений СоответствиеОбъектовДляОбмена.

Если ваша задача — обеспечить работу типовых планов обмена или механизмов синхронизации, возможно, вам не нужно изобретать велосипед. При использовании стандартных обработок обмена данными (например, через БСП), система сама заполняет этот регистр, если настроены соответствующие узлы планов обмена. В этом регистре хранятся:

УзелИнформационнойБазы — ссылка на узел плана обмена, из которого пришли данные.
СобственнаяСсылка — ссылка на объект в текущей базе.
УникальныйИдентификаторИсточника — тот самый GUID в виде строки или уникального идентификатора.

Посмотрим на преимущество этого метода: вам не нужно писать код записи. Достаточно правильно настроить правила обмена и указать в настройках выгрузки использование идентификации по внутреннему идентификатору. Система сама проверит наличие записи в этом регистре при загрузке.

Нюансы идентификации объектов

Выясним важный момент относительно поиска объектов. В КД 2.1 в правилах конвертации объекта есть настройка «Продолжить поиск по полям поиска, если по идентификатору объект не найден». Рассмотрим сценарий:

Вы выгружаете объект с GUID "A".
В базе-приемнике уже есть такой же объект (например, созданный вручную), но с GUID "B".
Если вы настроите Поля поиска (например, по Артикулу или Наименованию), система найдет объект "B" и обновит его, не создавая дубль.
В этот момент в обработчике После загрузки вы сможете записать связь: GUID "A" (из параметров) соответствует объекту "B" (текущий Объект.Ссылка).

Такой подход гарантирует, что даже при несовпадении внутренних идентификаторов вы всегда сможете восстановить историю происхождения данных.