Почему при синхронизации через КД 3.0 в документах появляется «Объект не найден» и как исправить поиск договоров

При настройке обмена данными между конфигурациями (например, 1С:Управление торговлей 11 и 1С:Бухгалтерия предприятия 3.0) через формат EnterpriseData (Конвертация данных 3.0) разработчики нередко сталкиваются с проблемой задвоения справочников. Попытка решить проблему «в лоб» — отключить сопоставление по УИД в правилах конвертации объектов (ПКО) и оставить только поиск по полям — часто приводит к другой неприятной ситуации: в загруженных документах реквизиты договоров оказываются пустыми либо содержат битые ссылки вида «Объект не найден».

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

Внутренняя механика сопоставления в БСП и регистр публичных идентификаторов

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

Когда в ПКО включен типовой режим «Сначала по уникальному идентификатору, затем по полям поиска», алгоритм модуля ОбменДаннымиXDTOСервер отрабатывает следующим образом:

1. Система проверяет наличие записи в регистре ПубличныеИдентификаторыСинхронизируемыхОбъектов по полученному GUID и узлу обмена. Если соответствие найдено, возвращается связанная ссылка.
2. Если записи нет, выполняется поиск по заданным полям (например: Организация, Владелец, Номер, Дата). Однако в поисковый запрос система принудительно добавляет левое соединение с регистром публичных идентификаторов с отбором: ПубличныеИдентификаторы.Ссылка IS NULL.

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

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

Причины появления битых ссылок («Объект не найден»)

Выясним, откуда берутся битые ссылки при загрузке документов:

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

Пошаговый порядок исправления сопоставления

Разберем правильный алгоритм действий для восстановления корректной синхронизации:

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

   
   ВЫБРАТЬ
       Регистр.УзелИнформационнойБазы,
       Регистр.Идентификатор,
       Регистр.Ссылка
   ИЗ
       РегистрСведений.ПубличныеИдентификаторыСинхронизируемыхОбъектов КАК Регистр
   ГДЕ
       Регистр.Ссылка.Ссылка ЕСТЬ NULL
       И Регистр.УзелИнформационнойБазы = &УзелОбмена
   

   Все найденные записи с «битыми» ссылками должны быть удалены из регистра.
2. Ручная привязка эталонных элементов. Если в БП были объединены дубли с помощью обработки «Поиск и удаление дублей», необходимо в регистре ПубличныеИдентификаторыСинхронизируемыхОбъектов вручную или программно указать в качестве значения ресурса Ссылка оставшийся рабочий договор для соответствующего внешнего идентификатора.
3. Настройка правил конвертации объектов (ПКО). Рекомендуется использовать режим «Сначала по уникальному идентификатору, затем по полям поиска». Это позволит системе сохранить скорость работы и корректно кэшировать сопоставления. Убедимся, что в полях поиска договора обязательно присутствуют Владелец, Организация, Номер, Дата и ВидДоговора.
4. Регистрация данных к обмену. После очистки и настройки правил выполняем регистрацию самих справочников:
   1. Регистрируем справочники Контрагенты и ДоговорыКонтрагентов в базе УТ.
   2. Выполняем сеанс обмена (выгрузка из УТ, загрузка в БП). Проверяем, что договоры сопоставились без дублей и зафиксировались в регистре публичных идентификаторов.
   3. Регистрируем к выгрузке документы и повторно запускаем обмен. Теперь документы без ошибок подхватят существующие договоры.

Альтернативное решение: программный поиск в обработчиках КД 3.0

Если типовой механизм поиска по полям не подходит из-за специфики ведения учета (например, разные номера договоров в УТ и БП при одинаковом смысле), сопоставление можно реализовать программно в модуле интеграции базы-приемника.

Для этого в ПКО договора в обработчике ПередЗаписьюПолученныхДанных или ПриКонвертацииДанныхXDTO выполняем собственный произвольный запрос к базе без оглядки на регистр публичных идентификаторов:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ ПЕРВЫЕ 1
    |	Ссылка
    |ИЗ
    |	Справочник.ДоговорыКонтрагентов
    |ГДЕ
    |	Владелец = &Владелец
    |	И Организация = &Организация
    |	И Не ПометкаУдаления";

Запрос.УстановитьПараметр("Владелец", ПолученныеДанные.Владелец);
Запрос.УстановитьПараметр("Организация", ПолученныеДанные.Организация);

Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
    ДанныеИБ = Выборка.Ссылка.ПолучитьОбъект();
КонецЕсли;

Использование явного переопределения ДанныеИБ позволяет точно спозиционировать загрузку на нужный договор даже в тех случаях, когда типовой механизм БСП дает сбой из-за накопившихся исторических расхождений в базах данных.