При настройке или использовании синхронизации данных между конфигурациями 1С:Управление торговлей 11 и 1С:Бухгалтерия предприятия 3.0 (особенно если версии конфигураций существенно различаются по дате выпуска) пользователи часто сталкиваются с критической ошибкой в журнале регистрации. Текст ошибки выглядит следующим образом: {ОбщийМодуль.ДлительныеОперации.Модуль(376)}: Ошибка проверки данных XDTO: Структура объекта не соответствует типу: {http://www.1c.ru/SSL/Exchange/Message}Header.
Эта проблема блокирует загрузку данных и не позволяет завершить цикл обмена. В рамках данной статьи мы подробно разберем причины возникновения этой ситуации и рассмотрим пошаговые алгоритмы её решения, начиная от простых манипуляций с данными и заканчивая доработкой конфигурации через расширения.
Проанализируем механику работы универсального формата обмена (EnterpriseData). Обмен данными между современными конфигурациями 1С строится на базе Библиотеки стандартных подсистем (БСП). Когда одна из баз (в нашем случае БП 3.0) обновляется до актуального релиза, в ней обновляется и версия БСП. В новых версиях библиотеки формат сообщения обмена расширяется: в заголовок (Header) XML-файла добавляются новые поля, которые необходимы для более сложной логики сопоставления узлов или поддержки новых версий формата.
Рассмотрим конкретные теги, вызывающие конфликт:
Когда принимающая сторона (УТ 11) пытается прочитать сообщение методом ФабрикаXDTO.ПрочитатьXML(), она сверяет содержимое файла со своей внутренней схемой (пакетом XDTO). Видя «лишние» с её точки зрения элементы, платформа выдает ошибку валидации, так как структура объекта перестает соответствовать строгому описанию типа.
Первым делом попробуем решить проблему без изменения программного кода. Одной из частых причин появления тега NewFrom является наличие записей в специальном техническом регистре. Давайте разберем, как его очистить:
1. В программе 1С:Бухгалтерия предприятия перейдем в меню «Функции для технического специалиста» (ранее «Все функции»).
2. Найдем регистр сведений ПсевдонимыПредопределенныхУзлов.
3. Если в этом регистре есть записи, относящиеся к вашему плану обмена (например, СинхронизацияДанныхЧерезУниверсальныйФормат), попробуем их удалить.
4. После удаления записей необходимо повторно инициировать выгрузку данных из БП.
Важный нюанс: Этот метод помогает убрать тег NewFrom, но он может оказаться бесполезным, если ошибка вызвана тегом AvailableObjectTypes, который генерируется новой версией БСП автоматически.
Если обновление УТ 11 до актуального релиза невозможно, самым правильным и стабильным решением будет адаптация схемы XDTO под требования нового формата. Для предотвращения подобных разрывов версий при обслуживании нескольких баз можно использовать программу для их автоматического пакетного обновления. Чтобы не снимать конфигурацию с поддержки, создадим расширение. Разберем процесс по шагам:
1. Создадим новое расширение в базе УТ 11.
2. Добавим в расширение пакет XDTO с именем ExchangeMessage (пространство имен http://www.1c.ru/SSL/Exchange/Message).
3. В этом пакете найдем тип объекта Header.
4. Нам необходимо добавить в структуру Header те свойства, которые присылает БП, но которых нет в УТ. Добавим свойство NewFrom:
string (из пространства имен XML Schema).Истина.0 (это критически важно, чтобы свойство было необязательным).5. Аналогичным образом добавим свойство AvailableObjectTypes:
anyType или соответствующий тип из новой схемы.0.После применения расширения ФабрикаXDTO при чтении сообщения будет видеть эти поля в схеме и успешно игнорировать их содержимое, не прерывая процесс загрузки ошибкой.
Если вы уже вносите изменения в конфигурацию, можно выполнить «пересадку» схемы. Посмотрим, как это сделать:
ExchangeMessage. Сохраним его в файл через контекстное меню «Экспортировать схему XML».Проанализируем риски: Полная замена пакета в старой конфигурации может повлечь за собой необходимость обновления сопутствующих пакетов (например, тех, что описывают само EnterpriseData), поэтому ручное добавление свойств NewFrom и AvailableObjectTypes с минимальной границей 0 является более щадящим методом.
Рассмотрим ситуацию, когда обмен нужно провести «здесь и сейчас». Если файл обмена не заархивирован или вы можете его разархивировать, структуру заголовка можно поправить вручную. Удалим лишние элементы, чтобы заголовок выглядел привычно для старой УТ:
<msg:Header>
<msg:Format>http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.2</msg:Format>
<msg:CreationDate>2023-10-27T10:00:00</msg:CreationDate>
<msg:Confirmation>
<msg:ExchangePlan>СинхронизацияДанныхЧерезУниверсальныйФормат</msg:ExchangePlan>
<msg:To>УТ</msg:To>
<msg:From>БП</msg:From>
<msg:MessageNo>100</msg:MessageNo>
<msg:ReceivedNo>50</msg:ReceivedNo>
</msg:Confirmation>
<!-- Удаляем тег msg:NewFrom и msg:AvailableObjectTypes, если они есть -->
</msg:Header>
После сохранения исправленного XML-файла и его загрузки в УТ через «Состав отправляемых данных» или стандартную обработку, система примет квитанцию, и номера сообщений синхронизируются.
Подводя итог, можно сказать, что ошибка Структура объекта не соответствует типу: Header — это классический симптом «разрыва» версий БСП.
Основные выводы:
Header в пакете ExchangeMessage.Помните, что после успешной загрузки «проблемного» сообщения в УТ, база сформирует ответную квитанцию. Это позволит подтвердить прием данных в БП, и при следующем сеансе обмена система может не включать некоторые дополнительные блоки в заголовок, если конфликт был связан именно с регистрацией изменений узлов.