При организации обмена данными между конфигурациями на платформе 1С:Предприятие с помощью конфигурации «Конвертация данных 2.1» (КД 2.1) одним из наиболее важных вопросов является сохранение уникальных идентификаторов (GUID / UUID) переносимых объектов. Понимание того, как ведет себя идентификатор ссылки при выгрузке и загрузке, позволяет избежать появления дублей в базе-приемнике, предотвратить проблему битых ссылок (появление объектов с пометкой <Объект не найден...>) и правильно спроектировать логику синхронизации.
В этой статье мы подробно разберем технические нюансы работы платформы 1С и правил конвертации объектов, выясним, в каких случаях GUID переносимого элемента меняется, когда он остается прежним и как разработчик может гибко управлять этим процессом с помощью программного кода.
Каждая ссылка на любой объект в базе данных 1С (будь то элемент справочника, документ, бизнес-процесс или задача) физически идентифицируется уникальным 128-битным числом — GUID (Globally Unique Identifier). В платформе 1С этот тип данных называется УникальныйИдентификатор. Он записывается в виде строки из 36 символов в шестнадцатеричном формате (например, 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d).
Когда мы выполняем перенос данных, перед нами встает ключевая задача: сопоставить объект в источнике с аналогичным объектом в приемнике. Если сопоставление настроено неверно, система либо создаст дублирующий элемент, либо перезапишет не те данные. Поведение GUID в этом процессе полностью определяется настройками правил конвертации объектов (ПКО) в КД 2.1.
Давайте проанализируем, как Конвертация данных 2.1 управляет выгрузкой уникального идентификатора на физическом уровне. За это отвечает важный флаг в настройках ПКО (Правила конвертации объектов) — «Искать объект приемника по внутреннему идентификатору объекта источника».
Рассмотрим два возможных сценария настройки этого флага:
На практике разработчики часто используют комбинированные правила сопоставления. Например, в ПКО включают одновременно и поиск по GUID, и флаг «Продолжить поиск по полям поиска, если по идентификатору объект приемник не найден». Разберем по шагам три возможных сценария, которые могут возникнуть при загрузке данных в базу-приемник.
Если в базе-приемнике уже существует элемент с точно таким же уникальным идентификатором, система сопоставляет их. Данные объекта обновляются (если в правилах разрешено замещение существующих объектов). В этом случае GUID в приемнике не меняется — он остается прежним, так как изначально совпадал с идентификатором источника.
Этот сценарий является критически важным для понимания архитектуры платформы 1С. Представим ситуацию: в источнике и приемнике есть контрагент «ООО Вектор». Однако в приемнике он был создан вручную, поэтому его GUID отличается от GUID в источнике. Мы настроили правила поиска по ИНН и КПП.
При загрузке происходит следующее:
Почему платформа ведет себя именно так? Физически изменить уникальный идентификатор (ссылку) у уже существующего в базе 1С элемента напрямую невозможно. Ссылка является неизменяемым первичным ключом записи в таблице СУБД. Если бы платформа позволила изменить GUID существующего элемента справочника, во всей базе данных мгновенно «побились» бы ссылки: в документах, регистрах сведений и накоплениях, где этот элемент уже был выбран, вместо него отобразилась бы надпись <Объект не найден...>. Это привело бы к фатальному нарушению целостности базы данных.
Если поиск по уникальному идентификатору не дал результатов, а поиск по полям сопоставления также завершился неудачно, КД 2.1 принимает решение о создании нового элемента справочника. Поскольку в настройках ПКО был активен поиск по внутреннему идентификатору, новый объект в базе-приемнике будет создан с точно таким же GUID, какой был у элемента в базе-источнике. В результате мы получаем полную синхронизацию ссылок между двумя базами.
Иногда стандартных механизмов синхронизации КД 2.1 оказывается недостаточно. Например, если источником данных выступает внешняя система (SQL-база, JSON-файл или таблица Excel), у которой нет «родного» GUID 1С, либо если бизнес-логика требует принудительного связывания объектов. В таких ситуациях мы можем прибегнуть к программному управлению ссылками через события (обработчики) КД 2.1.
Если нам необходимо создать новый элемент справочника в приемнике с заранее определенным уникальным идентификатором, мы можем использовать метод УстановитьСсылкуНового(). Это делается в обработчиках событий ПКО, например, в событии «Поля поиска» или «Перед загрузкой».
Рассмотрим пример кода, который позволяет переопределить GUID создаваемого объекта:
// Пример кода в обработчике ПКО "Поля поиска"
Если ЭтоНовыйОбъект Тогда
// Получаем переданный строковый идентификатор из источника
СтрокаGUID = ПараметрыОбъекта.Получить("ИдентификаторИзВнешнейСистемы");
Если ЗначениеЗаполнено(СтрокаGUID) Тогда
// Создаем объект типа УникальныйИдентификатор
НовыйGUID = Новый УникальныйИдентификатор(СтрокаGUID);
// Формируем ссылку для нового элемента
СсылкаНового = Справочники.Номенклатура.ПолучитьСсылку(НовыйGUID);
// Устанавливаем ссылку, которая запишется при создании
Объект.УстановитьСсылкуНового(СсылкаНового);
КонецЕсли;
КонецЕсли;
Использование метода УстановитьСсылкуНового() гарантирует, что при физической записи элемента в базу данных СУБД выделит под него именно ту ссылку, которую мы сгенерировали программно.
Что делать, если мы столкнулись со Сценарием Б, когда объекты сопоставились по полям поиска, но их идентификаторы в базах отличаются, и нам критически важно сделать их одинаковыми (например, для последующего прямого обмена без правил конвертации)?
Просто перезаписать существующий объект не получится. Единственный корректный путь решения этой задачи выглядит так:
УстановитьСсылкуНового().Такой подход является абсолютно безопасным с точки зрения ссылочной целостности базы данных 1С и позволяет привести идентификаторы в обеих базах к единому значению.
Подведем итог. При переносе элемента справочника через КД 2.1 его GUID: