Как подменить GUID объекта при обмене данными в 1С?

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

Ограничения платформы 1С при работе с идентификаторами

Прежде чем переходить к реализации, проанализируем базовые правила платформы 1С:Предприятие при обращении с уникальными идентификаторами ссылочных типов:

1. Неизменяемость GUID: Идентификатор является первичным ключом записи в таблицах СУБД. Изменить GUID у объекта, который уже записан в базу данных, невозможно никакими штатными средствами платформы.
2. Ограничение метода УстановитьСсылкуНового(): Данный метод менеджера объекта разрешено применять строго до момента первой записи объекта, то есть когда свойство ЭтоНовый() возвращает значение Истина. Попытка вызвать метод для ранее сохраненного объекта приведет к исключительной ситуации.
3. Метод ПолучитьСсылку(): Метод менеджера справочника или документа позволяет получить ссылку по заданному Новый УникальныйИдентификатор(СтрокаГУИД) в оперативной памяти без обращения к таблицам базы данных. Если объект с таким GUID уже существует, метод вернет ссылку на него; если еще нет — вернет ссылку на пока не созданный объект.

Способ 1. Использование обработчика «Поля поиска» в «Конвертации данных 2.1»

Если обмен настраивается через правила конвертации данных (КД 2.1), сопоставление на стороне приемника можно полностью переопределить программно в правиле конвертации объекта (ПКО).

Разберем по шагам порядок настройки ПКО в базе-приемнике:

1. Открываем нужное ПКО и переходим на вкладку Настройки.
2. Снимаем флаг Искать объект приемника по внутреннему идентификатору. Если флаг останется включенным, алгоритм загрузки сначала попытается найти объект по исходному идентификатору источника и выполнит подмену некорректно.
3. Переходим в обработчик Поля поиска данного ПКО.
4. Формируем ссылку на целевой объект с требуемым идентификатором и сообщаем механизму конвертации о завершении поиска.

Посмотрим на пример кода в обработчике Поля поиска:

ИдентификаторЦелевой = "a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d"; // Требуемый GUID приемника
СсылкаНаОбъект = Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор(ИдентификаторЦелевой));

// Предотвращаем дальнейший штатный поиск по полям
ПрекратитьОчистку = Истина;

Выясним причину использования переменной ПрекратитьОчистку = Истина;. По умолчанию механизм КД после выполнения обработчика проверяет соответствие объекта по полям поиска. Установка флага сообщает обработчику загрузки, что ссылка определена однозначно, благодаря чему стандартный поиск по реквизитам отключается, а все полученные из файла данные запишутся непосредственно в найденный объект.

Способ 2. Подмена объекта на этапе выгрузки из источника

Если в базе-источнике заранее известен целевой GUID базы-приемника, подмену можно выполнить еще до записи данных в файл выгрузки. В таком случае в обработчике Перед выгрузкой ПКО мы можем подставить ссылку с целевым идентификатором.

Рассмотрим пример кода:

ЦелевойИдентификатор = "a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d";
Источник = Справочники[Источник.Метаданные().Имя].ПолучитьСсылку(Новый УникальныйИдентификатор(ЦелевойИдентификатор));

В результате такой подмены в результирующий XML-файл обмена сразу будет выгружен узел с идентификатором приемника, и база-приемник выполнит стандартный поиск по внутреннему идентификатору без дополнительных доработок правил загрузки.

Способ 3. Использование регистра «Соответствия объектов информационных баз» (БСП)

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

Разберем логику работы механизма БСП:

1. При загрузке любого входящего пакета данных система в первую очередь обращается к регистру сведений СоответствияОбъектовИнформационныхБаз по узлу плана обмена и переданному GUID источника.
2. Если запись найдена, БСП сразу сопоставляет данные с найденной ссылкой объекта приемника, полностью игнорируя дальнейший поиск по полям (наименование, артикул, ИНН).
3. Если необходимо перенаправить поток данных в другой объект, достаточно создать или перезаписать строку в этом регистре сведений.

Для программной установки или изменения связи между объектами рекомендуется использовать метод общего модуля БСП:

ОбменДаннымиСервер.ЗаписатьСоответствиеОбъекта(
    СсылкаПриемника, 
    ИдентификаторИсточника, 
    УзелОбмена
);

Если соответствие для объекта ранее уже существовало, старую запись следует предварительно удалить или переписать, чтобы избежать неоднозначности при очередном сеансе обмена.

Возможные риски и побочные эффекты

При ручной подмене идентификаторов и сопоставлений важно учитывать технические риски:

1. Образование дубликатов: Если в базе-приемнике ранее уже был загружен объект с исходным GUID источника, то при принудительной перепривязке ко второму объекту первый останется в базе. В таком случае потребуется выполнить поиск и удаление дублей с заменой ссылок во всех проведенных документах.
2. Коллизии ссылочной целостности: Если идентификатор формируется вручную строкой, убедитесь в корректности формата UUID и в том, что по данному GUID в базе не зарегистрирован объект другого метаданного или объект, помеченный на удаление.