При выполнении обмена данными между двумя, казалось бы, идентичными конфигурациями 1С через универсальный обмен XML часто возникает специфическая ошибка: «Ошибка преобразования данных XDTO: НачалоСвойства: ... Тип: ... по причине: Ошибка преобразования данных XDTO: НачалоСвойства: Артикул Форма: Элемент». На первый взгляд ситуация кажется парадоксальной: реквизиты в обеих базах называются одинаково, имеют один и тот же тип, но загрузка обрывается. Давайте разберем по шагам, почему это происходит, как устроены механизмы XDTO в платформе «1С:Предприятие» и какими способами можно решить эту проблему.
Для начала проанализируем ситуацию с точки зрения механизмов платформы. Когда мы выгружаем объект (например, справочник Номенклатура) через стандартную фабрику XDTO, система использует описание типа из так называемой глобальной фабрики (пакет current-config). Этот пакет формируется платформой динамически на основе дерева метаданных вашей конфигурации.
Ключевой момент заключается в том, что в схеме XSD, которая лежит в основе XDTO, составные типы данных (объекты) чаще всего описываются через конструктор xs:sequence (последовательность). Это накладывает жесткое ограничение: элементы в XML-файле должны следовать строго в том порядке, в котором они описаны в схеме. Рассмотрим подробнее, как это работает в 1С:
Артикул был перемещен с помощью синих стрелок «Вверх» или «Вниз» и стоит, к примеру, вторым в списке, а в базе-приемнике он находится на пятой позиции — для десериализатора XDTO эти структуры будут считаться разными.Артикул, он сверяет его со своей внутренней картой (схемой). Если по схеме в этом месте ожидается другой реквизит (например, Наименование), платформа выбрасывает ошибку НачалоСвойства.Таким образом, фраза «две одинаковые конфигурации» может быть верна с точки зрения функционала, но ошибочна с точки зрения структуры XDTO, если порядок объектов в дереве метаданных был изменен.
Нередко причиной «внезапного» изменения структуры становятся расширения. Если в одной из баз подключено расширение, которое добавляет собственные реквизиты в справочник Номенклатура, оно модифицирует глобальную фабрику XDTO. Даже если эти реквизиты не заполнены, само их наличие в структуре типа current-config меняет ожидаемую последовательность тегов в XML. При попытке загрузить файл из базы без расширения в базу с расширением (или наоборот), вы гарантированно столкнетесь с ошибкой преобразования, так как цепочка xs:sequence будет нарушена.
Если ваша задача носит разовый характер (например, перенос остатков или разовое обновление справочников), самым эффективным решением будет использование обработки «Выгрузка и загрузка данных XML (адаптивная)». В чем ее преимущество перед стандартным универсальным обменом?
Рассмотрим алгоритм ее работы: в отличие от стандартного механизма, который пытается прочитать весь объект целиком через ФабрикаXDTO.ПрочитатьXML(), адаптивная обработка работает более гибко. Она анализирует файл поэлементно и сопоставляет данные по именам реквизитов, игнорируя их порядок в XML-файле и наличие лишних или отсутствие недостающих свойств. Это позволяет успешно переносить данные между конфигурациями с небольшими различиями в структуре.
Для постоянного обмена данными использование адаптивных обработок может быть не всегда удобным или производительным. В этом случае нам необходимо привести конфигурации к идентичному виду. Проанализируем последовательность действий:
Номенклатура (или тот объект, на котором падает обмен).НачалоСвойства исчезнет.Если вы хотите точно выяснить, в каком именно месте расходятся схемы, вы можете программно выгрузить XSD-описание из обеих баз и сравнить их в текстовом редакторе. Посмотрим на пример кода, который позволяет выгрузить текущую схему конфигурации в файл:
// Выгрузка схемы для анализа различий
ИмяФайлаСхемы = "C:\Temp\ConfigSchema.xsd";
НаборСхем = ФабрикаXDTO.ЭкспортСхемы("http://v8.1c.ru/8.1/data/enterprise/current-config");
Для Каждого Схема Из НаборСхем Цикл
// Записываем каждую схему из набора в файл
Схема.Записать(ИмяФайлаСхемы);
КонецЦикла;
ИнформироватьПользователя("Схема успешно выгружена в " + ИмяФайлаСхемы);
Сделав это в обеих базах и воспользовавшись любым инструментом сравнения текстов (например, встроенным в 1С сравнением файлов или внешними утилитами типа WinMerge), вы увидите конкретную разницу в тегах <xs:element> внутри блока <xs:sequence>. Это позволит не гадать, а точно знать, какой реквизит стоит «не на своем месте».
Если конфигурации изначально предполагаются разными и будут развиваться независимо, правильным стратегическим решением будет отказ от «универсального обмена» в пользу обмена по правилам, созданным в конфигурации «Конвертация данных 2.0» или 3.0.
В этом случае вы создаете ПВД (Правила выгрузки данных) и ПКС (Правила конвертации свойств), где жестко прописываете соответствие полей. Механизм конвертации данных не опирается на последовательность тегов в current-config, а ищет соответствия по именам, указанным в правилах. Это наиболее надежный метод для промышленной эксплуатации систем, гарантирующий стабильность обмена при обновлениях любой из сторон.
Подведем итог нашему анализу ситуации с ошибкой XDTO:
current-config) базы-приемника.Помните, что платформа 1С при работе с XDTO строго следует стандартам XML-сериализации, где структура и последовательность типов являются частью определения самого типа данных. Тщательное соблюдение идентичности метаданных — залог успешной работы стандартных механизмов обмена.