Как исправить ошибку проверки данных XDTO "ПоказательДаты" в КД 3.0 и какой инструмент выбрать для разового переноса данных?

Перенос данных между конфигурациями 1С — задача, с которой регулярно сталкивается любой разработчик. Однако при переходе на новые технологии, такие как Конвертация данных 3.0 и формат EnterpriseData, можно столкнуться с неожиданными трудностями. Типичный сценарий: при выгрузке документов (например, платежных поручений) процесс прерывается критической ошибкой валидации схемы XDTO. Ситуация усугубляется, если перед нами стоит задача разовой консолидации данных между практически идентичными базами.

В этой статье мы подробно разберем, почему возникает популярная ошибка проверки XDTO для свойства ПоказательДаты, как ее устранить программно или организационно, как настроить отсечение непроведенных документов при обмене в КД 3.0, и самое главное — выясним, правильно ли выбран инструмент КД 3.0 для разового обмена данными.

Анализ ошибки XDTO для свойства "ПоказательДаты"

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

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(912)}: Ошибка формирования объекта XDTO: Тип свойства <ОбщееСоставноеСвойство>. Имя свойства: <РеквизитыПлатежаБюджет>.
{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(912)}: Ошибка формирования объекта XDTO: Тип свойства <ОбычноеСвойство>. Имя свойства: <ПоказательДаты>.
{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(836)}: Ошибка при вызове метода контекста (Создать)
                ЗначениеXDTO = ФабрикаXDTO.Создать(Свойство.Тип, ЗначениеСвойства);
по причине:
Несоответствие типов XDTO
по причине:
Ошибка проверки данных XDTO:
Значение: '01.01.0001' не соответствует простому типу...

Выясним причину этой ошибки. В конфигурации "Бухгалтерия предприятия" реквизит ПоказательДаты (поле 109 платежного поручения, используемое при перечислении налогов и сборов в бюджет) имеет строковый тип. Пользователи могут вводить туда различные значения: конкретную дату в формате "ДД.ММ.ГГГГ", нулевое значение "0" или оставлять поле пустым. В некоторых случаях, в том числе при некорректном программном создании документов или переносе данных сторонними обработками, в это поле записывается строковое представление пустой даты: "01.01.0001".

С другой стороны, формат EnterpriseData (XDTO-схема, на которой базируется КД 3.0) имеет строгие правила валидации. Согласно XML-схеме этого формата, свойство ПоказательДаты должно строго соответствовать определенному регулярному выражению (паттерну). Схема ожидает увидеть либо строку из 10 символов, представляющую корректную дату (причем часто накладываются ограничения на диапазон лет, например, только с 1900 по 2099 год), либо одиночный символ "0". Значение "01.01.0001" валидацию по регулярному выражению не проходит, так как год "0001" выходит за рамки допустимых лет в схеме. Платформа генерирует исключение, и весь пакет выгрузки аннулируется.

Способы устранения ошибки "ПоказательДаты"

Проанализируем два основных подхода к решению этой проблемы: исправление данных в базе-источнике и программную обработку на уровне правил конвертации.

Способ 1. Исправление данных на стороне источника

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

1. С помощью стандартной обработки "Групповое изменение реквизитов" найдем все документы ПлатежноеПоручение, у которых реквизит ПоказательДаты равен "01.01.0001" или пустой строке "".
2. Для найденных документов установим корректное значение по умолчанию. По правилам заполнения платежных поручений для небюджетных платежей или незаполненных показателей даты там должен стоять символ "0".
3. Перезапишем документы. Обратите внимание, что если документы уже были зарегистрированы к обмену на узле плана обмена, после изменения данных их необходимо перерегистрировать, чтобы обновленные значения выгрузились в файл обмена.

Способ 2. Программная корректировка в правилах КД 3.0

Если мы хотим решить проблему раз и навсегда программным путем и не зависеть от "грязных" данных в базе, нам необходимо скорректировать правила конвертации свойств (ПКС). Посмотрим, как написать обработчик в модуле менеджера обмена.

Найдем в правилах конвертации ПКС для свойства ПоказательДаты и в обработчике ПередВыгрузкой добавим следующий код 1С:

// Корректируем некорректные строковые представления дат перед отправкой в XDTO
ЗначениеПоказателя = Источник.ПоказательДаты;
Если ПустаяСтрока(ЗначениеПоказателя) Или ЗначениеПоказателя = "01.01.0001" Тогда
    Значение = "0";
Иначе
    Значение = СокрЛП(ЗначениеПоказателя);
КонецЕсли;

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

Как скопом запретить выгрузку непроведенных документов в КД 3.0?

Часто при консолидации данных требуется переносить только проведенные документы, игнорируя черновики и помеченные на удаление объекты. В Конвертации данных 2.0 это решалось одной строкой в обработчике ПКО ПередВыгрузкой. В Конвертации данных 3.0 архитектура обмена построена иначе, и у нас есть два основных пути реализации этой логики.

Вариант А. На уровне правил регистрации объектов (ПРО) — рекомендуемый путь

Этот метод является наиболее производительным, так как непроведенные документы вообще не будут регистрироваться к обмену и засорять таблицу зарегистрированных изменений на узле плана обмена. Правила регистрации настраиваются в КД и выгружаются в файл ExchangeRules.xml.

Разберем по шагам реализацию этого механизма:

1. Откроем правила регистрации объектов в Конвертации данных.
2. Для каждого интересующего нас типа документа перейдем в обработчик Перед зарегистрированием объекта.
3. Напишем следующий код, проверяющий статус проведения документа:

// Проверяем, проведен ли документ. Если нет — отменяем его регистрацию к обмену.
Если Метаданные.Документы.Содержит(Объект.Метаданные()) Тогда
    Если Не Объект.Проведен Тогда
        Отказ = Истина;
    КонецЕсли;
КонецЕсли;

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

Вариант Б. Фильтрация в модуле менеджера обмена (ПОД)

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

Для этого в модуле менеджера обмена найдем обработчик ПередОбработкой для соответствующего ПОД (например, Документ_ПлатежноеПоручение_Отправка) и напишем следующий код:

// Исключаем непроведенные документы из процесса выгрузки
Если ВыборкаДанных.Свойство("Проведен") Тогда
    Если Не ВыборкаДанных.Проведен Тогда
        Отказ = Истина;
    КонецЕсли;
КонецЕсли;

Этот код проверяет свойство проведения у объекта выборки и, если документ не проведен, взводит флаг Отказ = Истина, предотвращая его сериализацию в формат XDTO.

Правильно ли выбран инструмент: КД 2.0 против КД 3.0 для разового обмена?

Проанализируем самый важный методологический вопрос: оправдано ли использование Конвертации данных 3.0 для разовой загрузки данных из нескольких баз БП в пустую БП КОРП?

Большинство опытных специалистов по интеграции сходятся во мнении: для разовой консолидации данных между идентичными конфигурациями использование КД 3.0 — это серьезная тактическая ошибка. Выясним, почему это так.

Разберем концептуальные различия между этими инструментами:

• Конвертация данных 3.0 (EnterpriseData): Предназначена для построения регулярных, долгосрочных обменов между гетерогенными (разнородными) информационными системами (например, ERP - БП, УТ - БП). Главный плюс технологии — слабая связанность конфигураций. Если обновится база-источник или база-приемник, обмен не сломается, так как обе конфигурации общаются через стабильный "переходный" стандарт — схему EnterpriseData. Но за это приходится платить жесткой валидацией XDTO, необходимостью написания сложных общих модулей менеджера обмена и внедрения расширений в БСП.
• Конвертация данных 2.0: Предназначена для обмена "напрямую" между метаданными по технологии XML. Она идеальна для переноса данных "один-в-один", миграции на новые версии аналогичных конфигураций и разовой консолидации.

Посмотрим на сравнительную таблицу применимости для нашей задачи:

Таким образом, пытаясь выполнить разовую выгрузку через КД 3.0, разработчик сталкивается с огромным оверхедом: тратит время на написание и подмену общего модуля менеджера обмена через расширение, борется с жесткими ограничениями XDTO-валидации (как в случае с ПоказательДаты или пустыми контрагентами), и решает проблемы, которых в КД 2.0 просто не возникло бы.

Рекомендации по завершению проекта консолидации

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

Однако, если ошибок по-прежнему слишком много, а сроки поджимают, мы рекомендуем отложить КД 3.0 и решить задачу с помощью проверенного стека КД 2.0:

1. Создайте новые правила обмена в КД 2.0, выбрав в качестве источника "Бухгалтерию предприятия", а в качестве приемника — "Бухгалтерию предприятия КОРП" (поскольку метаданные практически идентичны, правила сформируются автоматически).
2. Воспользуйтесь обработкой УниверсальныйОбменДаннымиXML.epf для выгрузки данных из баз-источников и загрузки в КОРП.
3. При необходимости отфильтровать непроведенные документы, просто установите галочку отбора в самой обработке выгрузки или напишите одну строчку кода Отказ = Не Источник.Проведен; в обработчиках ПКО перед выгрузкой.

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