При организации обмена данными между устаревшими конфигурациями (такими как КА 1.1 или УПП 1.3) и современными решениями (БП 3.0) через универсальный формат EnterpriseData (ED), разработчики часто сталкиваются с ошибками валидации XDTO-объектов. Одна из самых распространенных и неприятных ошибок — Ошибка при вызове метода контекста (Проверить). ОбъектXDTO.Проверить(). Рассмотрим подробно, почему она возникает и как её устранить на примере документа Поступление доп. расходов.
Ошибка валидации означает, что сформированная структура данных не соответствует схеме XDTO-пакета, используемого в обмене. В тексте ошибки часто указывается конкретный узел, не прошедший проверку. Например: Структура объекта '/Услуги/Строка[1]' не соответствует типу... Не установлено значение одного из следующих свойств: Сумма. Это говорит о том, что при формировании данных для выгрузки в табличной части «Услуги» поле Сумма оказалось пустым или не было инициализировано вовсе, хотя согласно формату EnterpriseData 1.5 оно является обязательным.
Выясним, почему так происходит. В старых конфигурациях логика формирования ДанныеXDTO в Менеджере обмена через универсальный формат может не учитывать все особенности распределения доп. расходов. Если документ ранее никогда не выгружался, стандартные правила могут содержать ошибки в запросах или в алгоритмах заполнения свойств, из-за чего данные из физических таблиц документа не «пробрасываются» в структуру XDTO.
Для исправления ситуации нам необходимо вмешаться в процесс формирования данных перед тем, как они будут переданы валидатору. Разберем по шагам, как локализовать проблему:
ОбменДаннымиXDTOСервер. Ошибка обычно происходит в строке:
ОбъектXDTO.Проверить();
ДанныеXDTO. Это структура или таблица значений, которая содержит подготовленные данные для конвертации. Если мы видим, что в табличной части Услуги (или Состав) в колонке Сумма стоит 0 или Неопределено, значит, корень проблемы находится в Правилах Конвертации Объектов (ПКО).Как правило, виновником является модуль МенеджерОбменаЧерезУниверсальныйФормат. Именно там сосредоточена вся логика преобразования внутренних данных 1С в формат ED.
Рассмотрим ситуацию, когда в исходном документе в режиме 1С:Предприятие все суммы заполнены, но в ОбъектXDTO они не попадают. Нам необходимо найти процедуру, отвечающую за выгрузку именно этого документа. Обычно она называется ПКО_Документ_ПоступлениеДопРасходов_Отправка_ПриОтправкеДанных.
Проанализируем код внутри этой процедуры. Если стандартный механизм формирования ДанныеXDTO дает сбой, мы можем дозаполнить структуру вручную. Пример того, как можно принудительно инициализировать недостающие поля:
Процедура ПКО_Документ_ПоступлениеДопРасходов_Отправка_ПриОтправкеДанных(ДанныеXDTO, ДанныеОбъекта, УзлыОбъекта)
// Перебираем строки, которые были подготовлены для выгрузки
Для Каждого СтрокаУслуг Из ДанныеXDTO.Услуги Цикл
// Проверяем заполненность обязательных полей формата ED 1.5
Если Не ЗначениеЗаполнено(СтрокаУслуг.Сумма) Тогда
// Если сумма не заполнена, пытаемся взять её из данных объекта-источника
// Здесь должна быть логика поиска соответствующей строки в ТЧ документа
СтрокаУслуг.Сумма = ...; // Ваше значение
КонецЕсли;
// Аналогично для количества и цены, если они требуются форматом
Если СтрокаУслуг.Количество = 0 Тогда
СтрокаУслуг.Количество = 1;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Часто ошибка Не установлено значение одного из следующих свойств возникает из-за сложной структуры свойства СтавкаНДС. В формате EnterpriseData это не просто ссылка на справочник или перечисление, а объект. Если в КА 1.1 ставка выбрана как «Без НДС» или вовсе не указана, конвертер может создать пустой узел СтавкаНДС, который не пройдет проверку валидатором.
Выясним причину: в современных конфигурациях БП 3.0 используется реквизит ВидСтавкиНДС, а формат ED 1.5 требует четкого соответствия типов. Проанализируем, как заполняется ставка в ПКО. Если в отладчике мы видим, что узел СтавкаНДС создан, но в нем отсутствуют внутренние обязательные свойства (например, сама ставка в процентах), необходимо явно прописать логику сопоставления в процедуре ПриОтправкеДанных.
Поскольку функция ОбъектXDTOИзДанныхXDTO работает рекурсивно, отлаживать её напрямую бывает крайне сложно. Рекомендуется использовать условные точки останова в общем модуле ОбменДаннымиXDTOСервер. Установите условие на конкретный тип документа или на конкретную ссылку:
Если Найти(ПравилоКонвертации.Имя, "ПоступлениеДопРасходов") > 0 Тогда
// Здесь можно прерваться и изучить структуру ДанныеXDTO
КонецЕсли;
Это позволит вам увидеть «чистые» данные до того, как 1С попытается построить из них XDTO-объект. Проверьте соответствие имен полей в ДанныеXDTO и имен свойств в XDTO-пакете EnterpriseData_1_5_1. Если в пакете свойство называется Сумма, а в вашей структуре СуммаДокумента, автоматического сопоставления не произойдет, и валидатор выдаст ошибку.
Подводя итог, можно выделить три основных шага для решения проблемы:
/Услуги/Строка[1]) и название поля.ПриОтправкеДанных соответствующего ПКО. Убедитесь, что все поля, требуемые форматом ED (Сумма, Количество, СтавкаНДС), принудительно заполняются валидными значениями.Такой системный подход позволяет не только временно «заткнуть» ошибку, но и восстановить полноценную работоспособность обмена для документов, которые ранее игнорировались системой.