Как исправить ошибку XDTO-валидации при программном заполнении табличных частей в 1С:Конвертация данных 3.0?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Анализ проблемы: почему возникает ошибка структуры XDTO

Рассмотрим ситуацию: разработчик пытается вручную заполнить таблицу значений и передать ее в ДанныеXDTO. Типичная ошибка выглядит так: «Структура объекта не соответствует типу... Не установлено значение одного из следующих свойств...». Проанализируем причины этого поведения системы:

  1. Несоответствие имен свойств: В КД 3.0 имена колонок в вашей таблице значений или ключи в структуре должны строго соответствовать именам свойств (Property) в XDTO-пакете, а не именам типов или именам реквизитов в метаданных 1С.
  2. Обязательность полей в схеме (XSD): Формат EnterpriseData часто требует передачи не только ссылки (UUID), но и ключевых полей для идентификации (например, Наименование, Артикул, Дата, Номер). Если в схеме указано minOccurs="1", отсутствие этого поля приведет к ошибке еще на этапе выгрузки.
  3. Использование групп свойств: В некоторых версиях формата данные объекта могут быть обернуты в дополнительные узлы, такие как ДанныеНоменклатуры или СведенияОСкладе. Программный код должен учитывать эту вложенность.

Решение 1: Программное заполнение через Таблицу Значений в обработчике

Если вы решили заполнять табличную часть документа вручную в обработчике «При отправке», необходимо подготовить таблицу значений с правильными именами колонок. Выясним на примере, как это сделать правильно. Допустим, мы переносим табличную часть документа УстановкаЦенНоменклатуры.

Проанализируем исправленный код заполнения:


// Создаем таблицу значений с колонками, именами которых являются свойства формата
ТабТовары = Новый ТаблицаЗначений;
ТабТовары.Колонки.Добавить("Номенклатура"); // Важно: имя должно совпадать с Property в XSD
ТабТовары.Колонки.Добавить("Цена");

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   УстановкаЦенТовары.Товар КАК Товар,
    |   УстановкаЦенТовары.Товар.Наименование КАК ТоварНаименование,
    |   УстановкаЦенТовары.Цена КАК Цена
    |ИЗ
    |   Документ.УстановкаЦенНоменклатуры.Товары КАК УстановкаЦенТовары
    |ГДЕ
    |   УстановкаЦенТовары.Ссылка = &Ссылка";

Запрос.УстановитьПараметр("Ссылка", ДанныеИБ.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();

Пока Выборка.Следующий() Цикл
    НоваяСтрока = ТабТовары.Добавить();
    
    // Вместо простой ссылки передаем структуру с обязательными полями
    НоваяСтрока.Номенклатура = Новый Структура("Ссылка, Наименование", 
        Выборка.Товар, 
        Выборка.ТоварНаименование);
    
    НоваяСтрока.Цена = Выборка.Цена;
КонецЦикла;

// Вставляем подготовленную таблицу в данные XDTO
ДанныеXDTO.Вставить("Товары", ТабТовары);

Почему это работает? Мы заменили обращение к ДанныеНоменклатуры на Номенклатура, так как именно это имя ожидает формат в составе строки табличной части. Кроме того, мы передали Наименование внутри структуры, что удовлетворило требование валидатора о наличии обязательных полей для идентификации объекта Номенклатура.

Решение 2: Использование стандартного механизма ПКС и «Коллекции объектов»

Разберем более «штатный» способ работы в КД 3.0, который позволяет избежать ручного заполнения ДанныеXDTO.Вставить(). Вместо того чтобы писать код в обработчике «При отправке» всего объекта, мы можем использовать обработчик «Перед обработкой» для конкретной группы свойств (табличной части).

Рассмотрим алгоритм действий:

  1. В правилах конвертации объектов (ПКО) найдите правило для вашего документа.
  2. Перейдите к правилам конвертации свойств (ПКС) для табличной части (например, Товары).
  3. В обработчике «Перед обработкой» напишите код, который подготавливает данные и помещает их в переменную КоллекцияОбъектов.

Пример кода в обработчике «Перед обработкой» ПКС:


// Формируем ТЗ, которую система сама обработает согласно настройкам ПКС
Запрос = Новый Запрос("ВЫБРАТЬ ... ИЗ Документ.ВашДокумент.Товары ГДЕ Ссылка = &Ссылка");
Запрос.УстановитьПараметр("Ссылка", ДанныеИБ.Ссылка);
КоллекцияОбъектов = Запрос.Выполнить().Выгрузить();
// Теперь система сама сопоставит колонки ТЗ с ПКС и применит нужные ПКО

Этот способ предпочтительнее, так как он позволяет использовать визуальные настройки ПКС и ПКО для каждой колонки ТЧ, включая автоматическую конвертацию ссылочных типов.

Решение 3: Проверка настроек ПКО для вложенных объектов

Если система по-прежнему выдает ошибку о незаполненном поле (например, Наименование), проанализируем настройки ПКО для этого типа данных (например, для справочника Номенклатура). В КД 3.0 для каждого объекта есть список «Ключевых свойств».

Если в ПКО Номенклатуры поле Наименование отмечено как обязательное или входит в состав полей поиска, то при любой выгрузке ссылки на номенклатуру система будет ожидать наличие этого поля. Выясним, как это исправить:

Важные рекомендации по отладке

Чтобы быстрее найти причину ошибки «Структура объекта не соответствует типу», рекомендуем выполнить следующие действия:

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

Таким образом, успех выгрузки табличных частей в КД 3.0 зависит от точного соответствия вашей программной модели данных (Таблицы значений или Структуры) и жесткой схемы XDTO-пакета EnterpriseData.

← На главную