Публичные идентификаторы синхронизируемых объектов 1С: для чего нужны и как работают

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

Публичный идентификатор — это общий «паспорт» объекта, единый для всех баз, участвующих в обмене. Он формируется при первой отправке объекта через план обмена и далее передаётся вместе с данными. Принимающая база по этому идентификатору ищет у себя уже сопоставленный объект и, если находит, обновляет его, а не создаёт дубль.

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

Что такое публичный идентификатор синхронизируемого объекта

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

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

Технически связь между публичным идентификатором и локальной ссылкой хранится в служебных регистрах сведений, которые ведут механизмы обмена (в типовых конфигурациях это регистры сопоставления объектов, используемые БСП — библиотекой стандартных подсистем). Именно эти записи и есть «таблица соответствий» между базами.

Как механизм работает при обмене данными

При отправке объекта через план обмена система проверяет, зарегистрирован ли для него публичный идентификатор. Если объект отправляется впервые, идентификатор формируется и записывается в регистр сопоставления. В сообщение обмена уходит не внутренняя ссылка, а именно публичный идентификатор вместе с данными объекта.

Принимающая база выполняет обратную операцию: извлекает публичный идентификатор из сообщения и ищет его в своём регистре сопоставления. Дальше возможны два сценария. Если соответствие найдено — объект обновляется по локальной ссылке. Если нет — система пытается найти объект по полям поиска (например, по ИНН и КПП контрагента) и либо привязывает найденное, либо создаёт новый объект и фиксирует для него полученный публичный идентификатор.

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

На этапе первоначальной настройки обмена в типовых решениях есть шаг сопоставления объектов: система показывает списки несопоставленных элементов обеих баз и предлагает связать их вручную или автоматически. Результат этого шага — те самые записи публичных идентификаторов, от которых зависит вся дальнейшая чистота синхронизации.

Где хранятся и как посмотреть идентификаторы

В конфигурациях на базе БСП (Управление торговлей, Бухгалтерия предприятия, ERP и другие) сопоставления хранятся в регистрах сведений, предназначенных для публичных идентификаторов синхронизируемых данных. Найти их можно через «Все функции» → «Регистры сведений» по словам «сопоставление» или «публичные идентификаторы». Отбор по конкретному узлу обмена покажет все связи, действующие для этого направления синхронизации.

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

Запрос = Новый Запрос("ВЫБРАТЬ ПЕРВЫЕ 100 Сопоставление.УзелИнформационнойБазы, Сопоставление.УникальныйИдентификаторПриемника, Сопоставление.УникальныйИдентификаторИсточника ИЗ РегистрСведений.ПубличныеИдентификаторыСинхронизируемыхОбъектов КАК Сопоставление");

При работе с регистром важно понимать: это служебные данные, которые механизм обмена ведёт автоматически. Ручное редактирование записей допустимо только осознанно и после резервного копирования, поскольку ошибочная правка разрывает связь объектов и приводит к дублям или потере обновлений.

Типичные проблемы и их причины

Самая частая жалоба — дубли контрагентов и номенклатуры после обмена. Причина почти всегда одна: объекты в двух базах не были сопоставлены на старте, и принимающая сторона создала новые элементы со своими публичными идентификаторами. Дальше система честно обновляет «свои» объекты, а исходные так и остаются непривязанными.

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

Как исправить сопоставление и устранить дубли

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

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

Когда идентификаторы формируются по-разному: варианты обмена

Поведение механизма зависит от способа обмена. При синхронизации через правила конвертации (Конвертация данных 2.0/3.0, EnterpriseData) публичный идентификатор обычно совпадает с GUID объекта-источника, а сопоставление ведётся по правилам поиска, заданным в правилах обмена. При универсальном обмене через планы обмена БСП регистрация и сопоставление полностью автоматизированы.

Выбор варианта определяется состоянием баз на момент настройки. Если обе базы уже наполнены независимо введёнными данными, без ручного этапа сопоставления обойтись сложно. Если одна база пустая или данные переносятся впервые, автоматика справится сама.

Как проверить, что синхронизация работает корректно

После настройки или исправления сопоставления нужно убедиться, что обмен идёт правильно. Контрольные признаки: количество несопоставленных объектов в мониторе синхронизации стремится к нулю, изменения тестового объекта в одной базе появляются в другой без создания нового элемента, а в регистре сопоставления нет записей с пустыми ссылками.

Полезно периодически контролировать дубли штатными средствами поиска и удаления дублей, особенно после массовых загрузок, переносов данных и изменений правил обмена. Ранняя диагностика обходится намного дешевле, чем чистка тысяч задвоенных элементов.

Часто задаваемые вопросы