Почему при обмене через EnterpriseData не обновляются ранее загруженные объекты и как это исправить?

При разработке и отладке обменов данными на базе технологии «Конвертация данных 3.0» (формат EnterpriseData) разработчики часто сталкиваются с ситуацией: в базе-источнике реквизиты объекта скорректированы, выгрузка сформирована успешно, но в базе-приемнике (например, 1С:Бухгалтерия предприятия) существующий объект не обновляется. Программа находит элемент по идентификаторам или ключевым свойствам, однако оставляет старые значения реквизитов без изменений.

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

Причины, по которым объект не обновляется при загрузке

Проанализируем две ключевые причины такого поведения механизма обмена:

1. Разделение данных на ключевые свойства и основные реквизиты:

   В формате EnterpriseData XML-структура объекта делится на две секции: КлючевыеСвойства (поля для поиска: ИНН, КПП, Наименование, УИД и т.д.) и блок остальных свойств объекта. Если справочник или документ выгружается не как самостоятельный объект по правилу обработки данных (ПОД), а транзитивно (по ссылке из другого документа), в выгрузку попадают только ключевые свойства. Принимающая сторона при обработке таких данных выполняет только поиск существующей ссылки. Если объект найден, его перезапись блокируется, чтобы случайно не затереть локальные реквизиты ссылочной нормативно-справочной информации.

2. Кэширование сопоставлений в регистре сведений:

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

Способы решения проблемы и принудительного обновления данных

Рассмотрим по шагам варианты действий для корректного обновления объектов в базе-приемнике.

1. Регистрация объекта к полной выгрузке:

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

2. Очистка связей в регистре соответствий:

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

3. Использование программных обработчиков в правилах конвертации:

   Если требуется принудительно обновлять реквизиты даже у найденных объектов, используем обработчики событий в менеджере обмена (или модуле конвертации данных). Например, в обработчике ПослеЗагрузкиОбъекта или ПередЗаписьюПолученныхДанных перенесем значения из входящих данных XDTO напрямую в объект приемника:

   Скопировать код

   
   // Пример переноса реквизита в обработчике загрузки
   Если НЕ Объект.ЭтоНовый() Тогда
       // Принудительно заполняем реквизит из входящего XDTO-пакета
       Если ДанныеXDTO.Свойства.Свойство("СтранаРегистрации") Тогда
           Объект.СтранаРегистрации = ДанныеXDTO.Свойства.СтранаРегистрации;
       КонецЕсли;
   КонецЕсли;
   

Особенности выгрузки составных ключевых свойств (на примере банковских счетов)

Рассмотрим частую ошибку, возникающую при ручном формировании ключевых свойств в обработчике ПриОтправке:

Ошибка проверки данных XDTO: Структура объекта '/БанковскийСчетОрганизации' не соответствует типу: КлючевыеСвойстваБанковскийСчет. Проверка свойства 'Владелец': Отсутствует обязательное свойство

Выясним причину этой ошибки: в схеме EnterpriseData свойство Владелец является составным типом (Choice), который может содержать либо ключевые свойства организации, либо ключевые свойства контрагента. Попытка поместить в ДанныеXDTO.КлючевыеСвойства внутреннюю служебную структуру платформы {Ссылка, ПКО} приводит к сбою валидации XDTO-пакета.

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

1. Настраиваем стандартное правило конвертации свойства (ПКС) для Владелец со ссылкой на соответствующее ПКО (например, Организация_КлючевыеСвойства или Контрагент_КлючевыеСвойства), отключив флаг ручного алгоритма.
2. Если заполнение выполняется кодом, формируем полноценный XDTO-объект нужного типа схемы через функции модуля конвертации:

// Формирование XDTO-объекта ключевых свойств владельца через модуль конвертации
ВладелецXDTO = МенеджерКонвертации.КонвертироватьСвойствоВXDTO(
    СсылкаНаОрганизацию, 
    "Организация", 
    "КлючевыеСвойства"
);
ДанныеXDTO.КлючевыеСвойства.Вставить("Владелец", ВладелецXDTO);

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