Как исправить ошибку проверки данных XDTO при синхронизации Заказов клиентов в 1С?

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

При обновлении конфигураций 1С:Управление торговлей (УТ 11) и 1С:Бухгалтерия предприятия (БП 3.0) до последних релизов пользователи часто сталкиваются с критической ошибкой синхронизации. Процесс обмена прерывается сообщением: Ошибка проверки данных XDTO: Структура объекта '/ДополнительныеРеквизиты/Строка[1]/Свойство' не соответствует типу. Особенно остро эта проблема проявляется при обмене документами Заказ клиента, которые поступают из внешних систем, таких как Битрикс.

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

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

Разберем техническую сторону вопроса. Ошибка возникает в общем модуле ОбменДаннымиXDTOСервер при выполнении метода ОбъектXDTO.Проверить(). В новых версиях формата EnterpriseData (начиная с 1.5) схема данных стала более строгой. Для типа КлючевыеСвойстваДополнительныеРеквизиты свойство Наименование теперь является обязательным (параметр minOccurs="1" в XML-схеме).

Ситуация осложняется тем, что визуально в документе Заказ клиента табличная часть Дополнительные реквизиты может быть пуста. Однако программный код выгрузки все равно находит данные для отправки. Рассмотрим, почему так происходит:

  1. Дополнительные сведения: В отличие от реквизитов, сведения хранятся в независимом регистре. Метод ВыгрузитьДополнительныеРеквизитыИСведения собирает данные из обоих источников. Если в регистре сведений осталась «битая» запись, привязанная к заказу, но с незаполненным свойством, валидатор XDTO выдаст ошибку.
  2. Интеграция с Битрикс: Модули обмена с сайтами часто записывают данные в дополнительные реквизиты или сведения. Если соответствие свойств между сайтом и 1С настроено не полностью, в базу могут попасть записи с пустой ссылкой на объект ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения.
  3. Ошибки в релизах 1С: В некоторых версиях УТ 11.4 (например, начиная с 11.4.3) разработчики добавили вызов выгрузки доп. реквизитов, но забыли корректно описать правила заполнения ключевых свойств для этих объектов в ПКО (Правилах конвертации объектов).

Способ 1: Быстрое исправление через модуль менеджера обмена

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

Выясним алгоритм действий:

  1. Перейдем в настройки синхронизации данных и выгрузим Модуль менеджера обмена в файл (обычно это обработка).
  2. Откроем модуль этой обработки и найдем процедуру, отвечающую за отправку заказа клиента. Обычно это ПКО_Документ_ЗаказКлиента_Отправка_ПриОтправкеДанных.
  3. Найдем внутри строку кода, которая инициирует выгрузку дополнительных данных.

Нам необходимо закомментировать следующий участок кода:


// В процедуре ПКО_Документ_ЗаказКлиента_Отправка_ПриОтправкеДанных
// Комментируем вызов выгрузки доп. реквизитов, чтобы избежать ошибки валидации XDTO
// ВыгрузитьДополнительныеРеквизитыИСведения(КомпонентыОбмена, ДанныеИБ, ДанныеXDTO);

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

Способ 2: Правильное исправление через Конвертацию данных 3.0

Если дополнительные реквизиты необходимы в 1С:Бухгалтерия, рассмотрим более корректный, но сложный путь — доработку правил через конфигурацию Конвертация данных 3.0 (КД 3). Для проверки корректности написанного кода в КД 3 можно использовать расширение для проверки синтаксиса обработчиков конвертации XML.

Проанализируем ситуацию в КД 3:

  1. Загрузим структуру формата EnterpriseData и текущие правила обмена в КД 3.
  2. Найдем ПКО для документа ЗаказКлиента.
  3. Проверим наличие ПКС (Правил конвертации свойств) для табличной части ДополнительныеРеквизиты.
  4. Убедимся, что для свойства Свойство (которое имеет тип КлючевыеСвойства) прописано правило, заполняющее обязательное поле Наименование.

Если ПКС отсутствует или заполнено неверно, необходимо вручную прописать алгоритм получения наименования. Пример логики в обработчике:


// Пример заполнения обязательного свойства Наименование для XDTO
Если ЗначениеЗаполнено(Источник.Свойство) Тогда
    Значение = Строка(Источник.Свойство);
Иначе
    // Если свойство пустое, запись не должна попадать в выгрузку
    Отказ = Истина; 
КонецЕсли;

Профилактика и очистка данных в базе

Иногда ошибка вызвана именно «мусором» в базе данных. Прежде чем править код, рекомендуем выполнить следующие действия:

1. Проверка через консоль запросов. Выполним запрос к табличной части документа, чтобы убедиться в отсутствии невидимых строк с пустыми ссылками:


ВЫБРАТЬ
    ЗаказКлиентаДополнительныеРеквизиты.Ссылка,
    ЗаказКлиентаДополнительныеРеквизиты.Свойство
ИЗ
    Документ.ЗаказКлиента.ДополнительныеРеквизиты КАК ЗаказКлиентаДополнительныеРеквизиты
ГДЕ
    ЗаказКлиентаДополнительныеРеквизиты.Свойство = ЗНАЧЕНИЕ(ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения.ПустаяСсылка)

2. Проверка регистра сведений. Проанализируем содержимое регистра Дополнительные сведения. Нажмите кнопку «Дополнительные сведения» (обычно со значком «i» или в меню «Еще») непосредственно в форме заказа, на который ругается обмен. Если там есть пустые строки — удалите их.

3. Использование Тестирования и исправления. Запустите штатную процедуру Тестирование и исправление в режиме конфигуратора. Установите галочки «Проверка логической целостности» и «Очистка ссылок на несуществующие объекты». Это часто помогает избавиться от некорректных записей, созданных внешними модулями интеграции (Битрикс и др.).

Подводя итог, отметим: ошибка XDTO — это всегда следствие несоответствия данных жесткой схеме формата. В случае с EnterpriseData 1.5 и выше, наиболее вероятной причиной является незаполнение обязательного поля Наименование у дополнительных реквизитов. Используйте программное комментирование вызова выгрузки как оперативное решение или правку ПКО через КД 3 для системного исправления проблемы.

← На главную