Синхронизация ЗУП и БП: где регистрируется связь объектов и как определить механизм обмена программно?

При работе с синхронизацией данных между конфигурациями «Зарплата и управление персоналом» (ЗУП 3.1) и «Бухгалтерия предприятия» (БП 3.0) разработчики часто сталкиваются с ситуацией, когда записи о соответствии объектов (например, Организаций или Контрагентов) хранятся в разных местах или вовсе отсутствуют в привычных регистрах. Разберем подробно, от чего это зависит и как программно определить логику связи в вашей обработке.

Два механизма синхронизации: КД 2.0 и КД 3.0

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

1. Механизм на базе «Конвертации данных 2.0» (КД 2.0): Это классический обмен, использующий правила обмена (XML), зашитые внутри конфигурации. В этом случае связь объектов регистрируется в регистре сведений СоответствияОбъектовИнформационныхБаз.
2. Механизм на базе «Конвертации данных 3.0» (КД 3.0 / Enterprise Data): Это современный обмен через универсальный формат данных. Здесь соответствия фиксируются в регистре сведений ПубличныеИдентификаторыСинхронизируемыхОбъектов.

Рассмотрим подробнее ситуацию, когда в одной паре баз регистр заполнен, а в другой — пуст. Проанализируем, как это проверить программно.

Как программно определить используемый план обмена

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

Посмотрим на пример реализации логики выбора регистра:

// Определяем тип узла обмена
ТипУзла = ТипЗнч(УзелОбмена);

Если ТипУзла = Тип("ПланОбменаСсылка.СинхронизацияДанныхЧерезУниверсальныйФормат") Тогда
    // Используется КД 3.0 (Enterprise Data)
    // Данные ищем в РС "ПубличныеИдентификаторыСинхронизируемыхОбъектов"
    ИмяРегистра = "ПубличныеИдентификаторыСинхронизируемыхОбъектов";
    
ИначеЕсли ТипУзла = Тип("ПланОбменаСсылка.ОбменЗарплата3Бухгалтерия3") Тогда
    // Используется КД 2.0 (Классический обмен)
    // Данные ищем в РС "СоответствияОбъектовИнформационныхБаз"
    ИмяРегистра = "СоответствияОбъектовИнформационныхБаз";
    
КонецЕсли;

Если вы пишете универсальный запрос, можно использовать конструкцию ССЫЛКА непосредственно в тексте запроса или проверять метаданные объекта УзелОбмена.Метаданные().Имя.

Почему регистры могут быть пустыми при работающей синхронизации?

Бывают ситуации, когда оба указанных регистра сведений пусты, но при выполнении синхронизации объекты всё равно успешно сопоставляются. Разберем по шагам, как работает механизм сопоставления «по умолчанию».

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

Важные моменты:

• Если GUID объектов совпадают, системе не требуется создавать запись в регистрах соответствий. Она находит объект напрямую по его внутреннему ID.
• Записи в регистрах СоответствияОбъектов... или ПубличныеИдентификаторы... появляются только тогда, когда объекты в разных базах были созданы независимо (имеют разные GUID) и были сопоставлены вручную пользователем в окне сопоставления или по полям поиска (например, по ИНН и КПП).

Поэтому в вашей обработке первым делом стоит проверить прямое совпадение GUID. Проанализируем ситуацию с помощью кода:

// Получаем GUID объекта в текущей базе
ИдентификаторТекущейБазы = ОбъектСсылка.УникальныйИдентификатор();

// Попытка найти объект с таким же GUID в приемнике (логика поиска зависит от реализации)
// Если объект найден по GUID, значит запись в регистре соответствий не обязательна.

Использование инструментов БСП для поиска соответствий

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

Для универсального поиска рекомендуется использовать методы общего модуля ОбменДаннымиСервер. Рассмотрим подробнее, как это может выглядеть:

Для КД 3.0 (Enterprise Data) часто используются методы модуля МенеджерОбменаЧерезУниверсальныйФормат, однако они требуют инициализации контекста обмена. В простом случае достаточно выполнить запрос к соответствующему регистру, зная узел обмена и ссылку на объект.

Резюме для разработчика

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

1. Определите, какой план обмена используется (СинхронизацияДанныхЧерезУниверсальныйФормат для КД3 или ОбменЗарплата3Бухгалтерия3 для КД2).
2. Проверьте наличие прямой связи по УникальныйИдентификатор().
3. Если прямой связи нет, обратитесь к регистру ПубличныеИдентификаторыСинхронизируемыхОбъектов (для КД3) или СоответствияОбъектовИнформационныхБаз (для КД2).
4. Учитывайте, что в КД3 связь строится через текстовый идентификатор (строковый GUID), а в КД2 — через хранилище значения или поля ссылок.

Такой системный подход позволит вашей обработке работать корректно на любых релизах ЗУП 3.1 и БП 3.0, независимо от того, когда и как настраивалась синхронизация между базами.