← На главную

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

Причины возникновения ошибки сериализации XDTO

Выясним причину такого поведения системы. Механизмы обмена в КД 3 и платформенная XDTO-сериализация строго контролируют передаваемые типы данных. Если в свойство, где по формату ожидается набор строк (коллекция или табличная часть), передать объект типа Структура или Соответствие, сериализатор 1С может попытаться автоматически привести переданный объект к итерируемому типу. Платформа предполагает, что передана ТаблицаЗначений. Из-за этого происходит внутреннее обращение к свойству Колонки, которого у структуры или соответствия нет. Именно это и вызывает критическую ошибку.

Вторая частая ошибка — неправильная настройка самого свойства в правилах. Использование элемента «Группа свойств» в схеме XDTO вместо конкретного комплексного типа (например, ОбщиеСвойства) приводит к тому, что система не может инстанцировать объект. Группы свойств в XML-схемах предназначены исключительно для логической маршрутизации, а для хранения реальных данных в структуре ДанныеXDTO требуется конкретный описанный тип.

Основное решение: правильная настройка типа свойства в формате

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

После правильного указания типа свойства платформа перестает ругаться на незаполненность обязательных полей и корректно воспринимает передаваемые данные.

Правила передачи табличных частей в ДанныеXDTO

Разберем подробнее, как безошибочно передавать табличные части в обработчиках КД 3 (например, в обработчике ПриОтправкеДанных). Посмотрим на проверенные способы:

1. Использование правильного типа: Для передачи табличной части в структуру ДанныеXDTO всегда используйте тип ТаблицаЗначений. Не пытайтесь заменить его структурами или массивами структур, если формат строго ожидает таблицу.
2. Точное совпадение имен: Имя ключа при вставке таблицы должно строго совпадать с именем табличной части, как оно задано в формате обмена. ДанныеXDTO.Вставить("ИмяТабличнойЧастиВФормате", ТаблицаЗначений);
3. Синхронизация колонок: Имена колонок созданной ТаблицыЗначений должны в точности соответствовать именам свойств, которые определены в правилах (свойствах формата). Таблицу можно заполнить выгрузкой из исходной табличной части объекта или сформировать прямым запросом к базе данных.
4. Явное создание объектов XDTO: При работе с очень сложными иерархическими свойствами надежнее не полагаться на автоматическую конвертацию коллекций платформой. Создавайте объекты явно с помощью метода ФабрикаXDTO.Создать(ТипОбъекта) и уже их помещайте в итоговую структуру.

Альтернативные варианты и обход ограничений

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

1. Использование AdditionalInfo
Базовые объекты формата EnterpriseData имеют встроенное свойство AdditionalInfo. В него можно поместить структуру, которая будет содержать массивы, таблицы значений и другие дополнительные реквизиты. На стороне приемника эти данные легко прочитать и обработать в обработчике ПриКонвертацииДанныхXDTO.

2. Расширяющий XDTO-пакет
Если требуется добавить сложную группу свойств или новую таблицу в обмен, методология фирмы «1С» рекомендует использовать расширяющий XDTO-пакет. В нем вы явно прописываете новые типы, которые без конфликтов интегрируются в механизмы КД 3 через правила конвертации свойств. Это защищает от ошибок приведения типов и неверных обращений к методам несовместимых коллекций.

3. Использование ДополнительныеСвойства
На стороне получения (в правилах загрузки) удобно использовать структуру ПолученныеДанные.ДополнительныеСвойства. Туда можно временно поместить прочитанные из ДанныеXDTO таблицы, чтобы обработать их в событиях перед или при записи объекта, обходя таким образом ограничения стандартного маппинга реквизитов.