Почему не создаются записи в регистре «Соответствие объектов для обмена» при настроенном обмене?

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

Причины отсутствия записей в регистре

Важно понимать, что регистр СоответствиеОбъектовДляОбмена не является обязательным «журналом» для всех операций обмена. Его заполнение зависит от выбранного способа поиска объектов при загрузке данных в правилах обмена (настройки в Конвертации данных). Рассмотрим основные причины, почему записи могут отсутствовать:

1. Синхронизация по внутренним идентификаторам (GUID): Если ваша база была получена копированием, то все объекты (элементы справочников, документов) в обеих базах имеют одинаковые внутренние GUID. Платформа 1С при стандартном обмене умеет находить объекты по их УникальномуИдентификатору автоматически. В этом случае создавать дополнительную запись в регистре соответствий нет необходимости — система «узнает» объект по его внутреннему коду.
2. Работа правил обмена: Запись в данный регистр обычно создается правилами обмена только тогда, когда объект в базе-приемнике не был найден по стандартным алгоритмам, и сработал механизм сопоставления. Если поиск по Бизнес-ключам (полям поиска) или GUID проходит успешно, принудительного заполнения регистра не происходит.
3. Момент записи данных: Анализ механизма показывает, что данные в этот регистр попадают преимущественно на стороне приемника в момент разбора пакета обмена (в обработчике ПриПолученииДанных), а не на стороне отправителя.

Нужно ли заполнять этот регистр вручную?

Многие специалисты пытаются принудительно заполнить регистр, чтобы использовать его для написания внешних отчетов или интеграции через COM-соединение. Однако, как показывает практика, это не самая надежная архитектурная стратегия.

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

• Регистр может быть неполным, так как он наполняется только при определенных условиях настройки правил обмена.
• Записи могут отсутствовать, если базы «зеркальны» (созданы из копии), так как там достаточно прямого сопоставления по GUID.

Рекомендованные способы получения связей между объектами

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

1. Прямое использование GUID: Поскольку базы имеют общее происхождение, вы можете обращаться к объектам напрямую по их УникальномуИдентификатору. Это самый быстрый и надежный способ в распределенных системах.
2. Использование бизнес-ключей: Вы можете сопоставлять объекты по их «природным» ключам — артикулам, кодам, ИНН контрагентов или номерам документов. Это делает ваш код независимым от того, записаны ли данные в служебные регистры обмена.
3. План обмена: Если вам необходимо отследить историю выгрузки, обратитесь к объектам плана обмена. Там фиксируется факт регистрации изменений для конкретных узлов, что является штатным инструментом платформы для контроля синхронизации.

Как проверить, как работают правила?

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

// Пример логики, которую можно использовать при поиске объектов,
// если вы хотите программно найти соответствие без участия регистра:
НайтиПоСсылкам = ОбщегоНазначения.ПолучитьСсылкуПоУникальномуИдентификатору(УИД_Объекта, Метаданные.Справочники.Номенклатура);

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