При настройке обмена данными между информационными базами «1С:Предприятие» разработчики часто сталкиваются с проблемой появления дублей. Казалось бы, включена синхронизация по внутреннему идентификатору, но в базе-приемнике всё равно появляются копии объектов. Разберем детально механизмы работы идентификаторов, роль префиксов и причины, по которым стандартные механизмы поиска могут давать сбой.
Для начала проанализируем ситуацию, описанную в вопросе: связаны ли префиксы и уникальные идентификаторы? Префикс — это текстовая часть кода справочника или номера документа (например, «МГ-0001»). Он предназначен в первую очередь для визуального разделения данных, созданных в разных узлах распределенной информационной базы, и обеспечения уникальности «человекочитаемых» номеров.
Уникальный идентификатор (UUID/GUID) — это скрытое системное поле типа «УникальныйИдентификатор», которое представляет собой 128-битное число. Рассмотрим основные моменты его работы:
Таким образом, префикс никак не влияет на генерацию UUID. Префиксы защищают от коллизий в номерах, а UUID обеспечивает уникальность объекта на уровне ссылочной целостности базы данных.
Выясним причину парадокса: если UUID уникальны, почему при включенной настройке «искать объект приемника по внутреннему идентификатору объекта источника» в «Конвертации данных» (КД) возникают дубли? Проанализируем механику процесса.
Ситуация 1: Объект создан вручную в обеих базах
Это самая распространенная причина. Если бухгалтер создал контрагента «Поставщик» в базе «Магазин 1» и того же контрагента в «Центральном офисе» до начала обмена, платформа присвоила им разные UUID. Для системы 1С это два абсолютно разных объекта, несмотря на идентичность ИНН и названия. При обмене система ищет в приемнике объект с UUID из источника, не находит его и создает новый. Так появляется дубль.
Ситуация 2: Настройка «Продолжить поиск по полям поиска»
В правилах конвертации объектов (ПКО) часто стоит флаг «Продолжить поиск по полям поиска, если по идентификатору объект не найден». Разберем, как это работает:
Ситуация 3: Клонирование баз
Если вы создали новую базу путем простого копирования файла .1CD или восстановления бэкапа SQL, вы получили полную копию всех UUID. Если после этого базы начали работать независимо и обмениваться данными, новые объекты могут начать конфликтовать, если алгоритм генерации UUID завязан на системное время и один и тот же сетевой узел, хотя в современных реалиях это встречается редко.
Хотя префикс не связан с UUID напрямую, он критически важен для корректного обмена. Рассмотрим ситуацию, когда префиксов нет. Если в двух разных магазинах одновременно создадут «Товар №001», то при попытке загрузки данных в центральную базу возникнет конфликт. Даже если поиск идет по UUID (которые разные), система может попытаться записать объект с кодом «001». Если в базе уже есть «001» (но с другим UUID), вы получите ошибку нарушения уникальности кода.
Использование префиксов решает несколько задач:
Для устранения задвоения проанализируем настройки правил обмена. Выполним следующие шаги:
Убедимся, что в XML-файле обмена реально передается тег {InternalId}. Если объект выгружается как свойство другого объекта, и для него не включена выгрузка идентификатора, приемник всегда будет пытаться найти его только по полям поиска или создавать новый.
Посмотрим на настройки поиска в КД. Если вы хотите, чтобы объекты сопоставлялись строго по UUID, убедитесь, что:
Важно помнить, что записи регистров сведений и накопления в 1С не имеют собственного UUID. Рассмотрим код записи в регистр:
МенеджерЗаписи = РегистрыСведений.ЦеныНоменклатуры.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Номенклатура = СсылкаНаТовар;
МенеджерЗаписи.Период = ТекущаяДата();
МенеджерЗаписи.Прочитать();
// Если запись не найдена по измерениям, будет создана новая
Задвоение в регистрах всегда связано с различием в ключевых полях (измерениях), таких как Номенклатура, Склад или Период, а не в уникальных идентификаторах самих записей.
ПубличныеИдентификаторыОбъектов для хранения маппинга между разными информационными системами.Проанализировав вышесказанное, мы видим, что само по себе отсутствие префикса не является причиной несовпадения UUID, но оно значительно повышает риск логических ошибок и конфликтов при записи объектов. Для решения проблемы задвоения всегда начинайте с анализа того, как объекты были созданы и какой приоритет поиска задан в правилах конвертации.