Как исправить ошибку отображения типов XDTO при обмене УТ 11 – БП 3 через EnterpriseData 1.7?

← На главную

Синхронизация данных между конфигурациями «1С:Управление торговлей» (редакция 11) и «1С:Бухгалтерия предприятия» (редакция 3.0) на основе универсального формата EnterpriseData — это мощный и гибкий инструмент. Однако при обновлении релизов и переходе на новые версии формата (например, с 1.6 на 1.7) разработчики часто сталкиваются со сложными техническими ошибками. Одной из самых распространенных и труднодиагностируемых является ошибка отображения типов XDTO при выгрузке объектов, таких как договоры контрагентов, номенклатура или документы.

В этой статье мы подробно разберем, почему возникает ошибка вида «Ошибка формирования объекта XDTO: Тип свойства. Имя свойства: . Ошибка отображения типов», проанализируем внутреннее устройство пакетов XDTO в платформе «1С:Предприятие 8» и рассмотрим несколько эффективных способов решения этой проблемы: от простого исправления схемы в конфигураторе до продвинутых архитектурных подходов с использованием расширений и механизма AdditionalInfo.

Суть проблемы: почему возникает ошибка отображения типов XDTO?

Рассмотрим ситуацию. В конфигурации были доработаны типовой XDTO-пакет EnterpriseData_1_6_21 и соответствующие правила обмена (менеджеры конвертации). Все работало корректно. После очередного обновления конфигурация автоматически перешла на использование формата версии 1.7.5. Разработчик перенес свои доработки в новый пакет EnterpriseData_1_7_5, однако при первой же попытке синхронизации процесс прервался с критической ошибкой в общем модуле ОбменДаннымиXDTOСервер.Модуль:


Ошибка формирования объекта XDTO: Тип свойства . Имя свойства: . 
Ошибка отображения типов: Отображение типа 'СправочникСсылка.ДоговорыКонтрагентов' в тип...
по причине: Ошибка отображения типов: Отображение типа 'СправочникСсылка.ДоговорыКонтрагентов' в тип...
{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(913)}: ВызватьИсключение СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(...

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

Выясним причину: почему пропадает базовый тип при импорте XSD-схем?

Давайте разберем по шагам, что происходит «под капотом» системы, когда мы дорабатываем XDTO-пакеты через внешние файлы. Стандартный сценарий работы многих разработчиков выглядит следующим образом:

Экспорт пакета XDTO EnterpriseData_1_7_5 из конфигуратора 1С во внешний файл с расширением .xsd.
Редактирование полученного XML/XSD-файла в стороннем текстовом редакторе (Notepad++, VS Code) или специализированной среде (XMLSpy) для добавления новых реквизитов и табличных частей.
Импорт измененного XSD-файла обратно в конфигуратор 1С поверх существующего пакета.

Именно на третьем шаге кроется архитектурная ловушка платформы 1С. Пакет EnterpriseData не является изолированным — он активно импортирует типы данных из других пространств имен, в частности, базовые сообщения обмена из пакета ExchangeMessage. При экспорте схемы в XSD-файл автоматически генерируется директива импорта:

<xs:import namespace="http://www.1c.ru/SSL/Exchange/Message"/>

В этой директиве указано только целевое пространство имен, но отсутствует атрибут schemaLocation, указывающий на физическое местоположение файла с описанием этой схемы. Когда мы загружаем отредактированный файл обратно в конфигуратор, платформа 1С не может разрешить зависимости внешних типов (таких как базовый объект ns1:Object, от которого наследуются все сущности обмена).

В результате этого у большинства типов объектов в импортированном XDTO-пакете сбрасывается свойство «Базовый тип» (Base Type) или устанавливается в значение anyType. Без явного указания базового типа платформа теряет правила сопоставления сложных типов данных 1С со структурой XML, что моментально приводит к ошибкам отображения типов при выгрузке любого объекта.

Ниже приведены 5 способов решения этой проблемы — от оперативного исправления до системных архитектурных решений.

Решение 1: Внесение изменений непосредственно в конфигураторе 1С

Самый надежный способ избежать проблем с потерей базовых типов при импорте — полностью отказаться от редактирования схемы во внешних текстовых файлах. Если вам нужно добавить несколько реквизитов, выполните это непосредственно внутри среды разработки 1С:

Откройте конфигуратор вашей информационной базы (например, «Управление торговлей»).
Найдите ветку Общие -> XDTO-пакеты -> EnterpriseData_1_7_5.
Разверните пакет и перейдите к нужному типу объекта (например, Справочник.ДоговорыКонтрагентов).
Добавьте новое свойство (клик правой кнопкой мыши -> Добавить -> Свойство).
В палитре свойств укажите имя нового реквизита и выберите его тип (например, string из пространства имен XML-схемы или ссылку на другой объект из пакета).
Сохраните конфигурацию и обновите базу данных.

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

Решение 2: Правильный импорт связанных схем с указанием schemaLocation

Если специфика доработки требует редактирования схемы именно во внешнем XML-редакторе (например, при масштабных изменениях структуры), необходимо правильно организовать процесс экспорта и импорта связанных схем. Рассмотрим этот процесс по шагам:

Выгрузите из конфигуратора 1С в одну общую папку на диске два пакета: основной EnterpriseData_1_7_5 (назовем его ED.xsd) и зависимый ExchangeMessage (назовем его EM.xsd).
Откройте файл ED.xsd в текстовом редакторе и найдите строку импорта пространства имен сообщений обмена.
Вручную модифицируйте строку импорта, добавив атрибут schemaLocation, указывающий на файл зависимой схемы:
```
<xs:import schemaLocation="EM.xsd" namespace="http://www.1c.ru/SSL/Exchange/Message"/>
```
Внесите необходимые изменения в структуру бизнес-объектов внутри файла ED.xsd и сохраните его.
При обратном импорте схемы в 1С выберите **оба файла схемы одновременно** (или загружайте основной файл, предварительно убедившись, что все зависимые файлы лежат в той же директории).

Платформа успешно считает относительный путь, восстановит связи типов, и свойство Базовый тип у объектов не будет утеряно.

Решение 3: Использование поля AdditionalInfo без изменения схемы XDTO

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

Мы можем упаковать любые нетиповые реквизиты объекта в формат JSON или XML, передать их через это поле, а на стороне получателя — распаковать и записать в соответствующие реквизиты.

Проанализируем пример передачи произвольного реквизита договора контрагента. На стороне базы-отправителя (УТ 11) в модуле менеджера обмена напишем следующий код:


Процедура ПКО_Справочник_ДоговорыContragenty_Отправка_ПриОтправкеДанных(ДанныеXDTO, ДанныеИБ, КомпонентыОбмена) Экспорт
    // Создаем структуру для хранения нетиповых данных договора
    СтруктураДопПараметров = Новый Структура;
    СтруктураДопПараметров.Вставить("ДополнительныйСрокОплаты", ДанныеИБ.ДополнительныйСрокОплаты);
    СтруктураДопПараметров.Вставить("УсловиеСпецификации", ДанныеИБ.УсловиеСпецификации);
    
    // Сериализуем структуру в формат JSON
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, СтруктураДопПараметров);
    СтрокаJSON = ЗаписьJSON.Закрыть();
    
    // Записываем сериализованную строку в стандартное поле AdditionalInfo
    ДанныеXDTO.AdditionalInfo = СтрокаJSON;
КонецПроцедуры

На стороне получателя (БП 3) в правилах конвертации (ПКО договора при получении) десериализуем данные и запишем их в объект информационной базы:


Процедура ПКО_Справочник_ДоговорыContragenty_Получение_ПриКонвертацииДанных(ДанныеXDTO, ПолученныеДанные, КомпонентыОбмена) Экспорт
    Если ДанныеXDTO.Свойство("AdditionalInfo") И ЗначениеЗаполнено(ДанныеXDTO.AdditionalInfo) Тогда
        Попытка
            // Читаем JSON из поля AdditionalInfo
            ЧтениеJSON = Новый ЧтениеJSON;
            ЧтениеJSON.УстановитьСтроку(ДанныеXDTO.AdditionalInfo);
            СтруктураДопПараметров = ПрочитатьJSON(ЧтениеJSON);
            ЧтениеJSON.Закрыть();
            
            // Заполняем реквизиты создаваемого/обновляемого договора в БП
            ПолученныеДанные.ДополнительныйСрокОплаты = СтруктураДопПараметров.ДополнительныйСрокОплаты;
            ПолученныеДанные.УсловиеСпецификации     = СтруктураДопПараметров.УсловиеСпецификации;
        Исключение
            // Записываем предупреждение в журнал регистрации при ошибке парсинга
            ЗаписьЖурналаРегистрации("ОбменДанными.ДопРеквизиты",
                УровеньЖурналаРегистрации.Предупреждение, , ,
                "Не удалось обработать дополнительные параметры договора: " + ОписаниеОшибки());
        КонецПопытки;
    КонецЕсли;
КонецПроцедуры

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

Решение 4: Перенос изменений в расширение конфигурации

Если вам все же необходимо физически расширить схему XDTO (например, этого требуют внешние веб-сервисы), делайте это с помощью механизмов расширения конфигурации. Начиная с версии платформы 8.3.11, расширения поддерживают полноценную работу с собственными XDTO-пакетами.

Рассмотрим порядок действий для переноса доработок в расширение:

Создайте новое расширение конфигурации (или используйте существующее для доработки обмена).
Добавьте в расширение собственный пакет XDTO. Рекомендуется задать ему уникальное пространство имен, отличное от типового (например, http://www.yourcompany.ru/EnterpriseData/1.7.5/custom).
В этом пакете опишите только ваши новые типы или расширения существующих типов.
С помощью аннотаций &Вместо или &После переопределите методы общего модуля обмена данными или менеджера обмена, чтобы задействовать вашу кастомную схему при формировании XML-сообщения.

Этот способ позволяет изолировать ваши доработки от типового функционала, исключая затирание метаданных и схем при накатывании официальных обновлений от 1С.

Решение 5: Временный откат на формат EnterpriseData 1.6

Если ошибка возникла внезапно в процессе рабочей смены, бизнес-процессы стоят, а времени на детальный анализ и перенос доработок в формат 1.7 прямо сейчас нет, можно временно принудительно вернуть обмен на использование стабильной версии формата 1.6.

Для этого выполните следующие шаги в конфигурации источника данных:

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


Процедура ПриПолученииНастроек(Настройки) Экспорт
    // Находим массив поддерживаемых версий формата обмена
    ДоступныеВерсии = Настройки.ВерсииФормата;
    
    // Обходим массив с конца и удаляем все форматы выше 1.6
    Индекс = ДоступныеВерсии.Количество() - 1;
    Пока Индекс >= 0 Цикл
        Если ДоступныеВерсии[Индекс] > "1.6" Тогда
            ДоступныеВерсии.Удалить(Индекс);
        КонецЕсли;
        Индекс = Индекс - 1;
    КонецЦикла;
КонецПроцедуры

После сохранения изменений базы данных инициализируют сессию обмена, согласуют версию формата 1.6 как максимально доступную для обеих систем, и обмен успешно отработает по старым стабильным правилам. Используйте этот метод как временную меру для оперативного восстановления работы пользователей перед полноценным переходом на новый формат.