Синхронизация данных между 1С:Управление торговлей 11 и 1С:Бухгалтерия предприятия 3.0 — один из самых востребованных механизмов. Однако на определенных релизах пользователи массово сталкиваются с критическим сбоем на этапе анализа данных. Система выдает сообщение: «Не удалось загрузить данные из 1С:Управление торговлей, редакция 11 (этап анализа данных)», а в журнале регистрации фиксируется ошибка Поле объекта не обнаружено (КлючевыеСвойства).
В этой статье мы подробно разберем природу этой ошибки, выясним, почему она возникает в общих модулях ОбменДаннымиXDTOСервер, и рассмотрим несколько способов решения — от простого обновления до написания программной «заплатки» через расширение.
Рассмотрим ситуацию с технической стороны. Ошибка чаще всего проявляется при использовании формата обмена EnterpriseData версии 1.7. Этот формат использует технологию XDTO (XML Data Transformation Objects) для описания структуры передаваемых данных. В процессе загрузки программа-приемник (в данном случае БП 3.0) получает XML-пакет и пытается преобразовать его во внутренние объекты 1С.
Выясним причину сбоя: в коде типового общего модуля ОбменДаннымиXDTOСервер (процедура КонвертацияСвойстваСтруктурыОбъектаXDTO) система ожидает, что у определенного свойства будет вложенная структура КлючевыеСвойства. Однако в некоторых случаях (например, при передаче справочников Статьи движения денежных средств или Прочие доходы и расходы внутри документов Списание безналичных денежных средств) этот узел в XML отсутствует или имеет иную структуру. Программный код не содержит проверки на наличие этого свойства и пытается обратиться к нему напрямую, что и вызывает исключение.
Прежде чем приступать к правке кода, разберем самый правильный и безопасный метод. Данная проблема была официально признана багом компании «1С» и исправлена в последующих выпусках конфигураций. Если ваша текущая версия позволяет произвести обновление, рекомендуем установить следующие релизы (или более новые):
После обновления необходимо заново выгрузить данные из источника, чтобы пакет сформировался с учетом исправленных правил.
Если по каким-то причинам оперативное обновление невозможно (например, конфигурация сильно доработана), мы можем внести изменения в код. Рассмотрим, как это сделать правильно. Нам потребуется вмешательство в общий модуль ОбменДаннымиXDTOСервер. Чтобы не снимать конфигурацию с поддержки, крайне желательно использовать Расширение конфигурации с методом &Вместо.
Найдем в модуле процедуру КонвертацияСвойстваСтруктурыОбъектаXDTO. В типовом коде проблемный участок выглядит примерно так:
Если ПКС.ОбработкаКлючевогоСвойства И Не ДанныеXDTO.Свойство("ЭтоНаборКлючевыхСвойств") Тогда
ИсточникДанных = ДанныеXDTO.КлючевыеСвойства;
Иначе
ИсточникДанных = ДанныеXDTO;
КонецЕсли;
Проанализируем логику: если свойство помечено как ключевое, программа пытается принудительно взять его из узла КлючевыеСвойства. Мы добавим проверку, которая позволит избежать ошибки, если этого узла нет в данных XDTO. Изменим код следующим образом:
Если ПКС.ОбработкаКлючевогоСвойства И Не ДанныеXDTO.Свойство("ЭтоНаборКлючевыхСвойств") Тогда
// Начало исправлений
Если ДанныеXDTO.Свойство("Значение") И ДанныеXDTO.Значение.ТипЗначения = "СтатьяДДС" Тогда
ИсточникДанных = ДанныеXDTO;
ИначеЕсли ДанныеXDTO.Свойства().Найти("КлючевыеСвойства") = Неопределено Тогда
ИсточникДанных = ДанныеXDTO;
Иначе
ИсточникДанных = ДанныеXDTO.КлючевыеСвойства;
КонецЕсли;
// Конец исправлений
Иначе
ИсточникДанных = ДанныеXDTO;
КонецЕсли;
Такая проверка делает механизм более устойчивым к изменениям формата XML и позволяет успешно завершить этап анализа данных даже при наличии несоответствий в структуре пакета.
Рассмотрим еще один эффективный способ, который не требует программирования. Поскольку ошибка специфична для EnterpriseData 1.7, мы можем попробовать переключить обмен на более старую, стабильную версию формата (например, 1.6 или 1.5).
Для этого выполним следующие шаги:
Посмотрим на результат: после смены версии формата правила обработки объектов изменятся, и обращение к КлючевыеСвойства в проблемных участках может исчезнуть вовсе.
Иногда ошибка провоцируется конкретными объектами, которые были некорректно записаны или имеют дубли. Проанализируем ситуацию в журнале регистрации. Если ошибка указывает на конкретный документ (например, Списание безналичных ДС ТИНБ-000269), попробуем следующее:
Мы выяснили, что ошибка «Поле объекта не обнаружено (КлючевыеСвойства)» носит системный характер и связана с переходом на новые версии формата обмена. Оптимальный путь решения — комплексное обновление конфигураций. Если же вы ограничены в возможностях обновления, использование расширения с исправленным кодом модуля ОбменДаннымиXDTOСервер является наиболее профессиональным и стабильным выходом из ситуации.
Не забывайте перед любыми изменениями кода или обновлением делать резервную копию информационных баз!