Почему при понижении версии платформы 1С не работают правила обмена КД 2.0 и как это исправить

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

Анализ проблемы: почему файлы обмена отличаются?

Проанализируем ситуацию, когда при выгрузке одного и того же документа с движениями по регистрам сведений мы получаем разные XML-файлы на разных платформах. Основная причина кроется в порядке следования объектов внутри файла обмена. Выясним причину этой зависимости.

В современных версиях платформы (например, 8.3.15) механизмы сериализации объектов в XML работают более предсказуемо, выстраивая иерархию «от владельца к подчиненному». В более старых версиях (например, 8.3.10) порядок обхода метаданных при автоматической выгрузке может зависеть от внутренних идентификаторов (Internal ID) таблиц в СУБД или даже от порядка следования типов в коллекции метаданных, который может меняться от версии к версии.

Рассмотрим конкретный пример: документ и связанные с ним записи регистра сведений. На платформе 8.3.15: сначала выгружается Документ, затем РегистрСведений1 и РегистрСведений2. На платформе 8.3.10: сначала выгружаются наборы записей РегистрСведений1 и РегистрСведений2, а только потом сам Документ.

При загрузке в базу-приемник такая последовательность на старой платформе приводит к фатальной ошибке:

«Ошибка при вызове метода контекста (Записать): Ошибка записи! Не установлен отбор по регистратору».

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

Решение №1: Явная установка приоритетов в ПВД

Для того чтобы сделать правила обмена независимыми от «настроения» платформы, мы должны жестко зафиксировать порядок выгрузки. Основным инструментом для этого в КД 2.0 являются ПВД (Правила выгрузки данных). Разберем по шагам, как настроить приоритеты:

1. Откроем базу «Конвертация данных» и перейдем в список ПВД.
2. Найдем правила выгрузки для нашего документа и для связанных регистров.
3. Обратим внимание на колонку «Приоритет». По умолчанию там может стоять 0 для всех объектов.
4. Установим для документа меньшее числовое значение (например, 100), а для регистров — большее (например, 200).

Важно: В КД 2.0 объекты с меньшим значением приоритета выгружаются раньше. Установив документу приоритет выше, мы гарантируем, что в XML-файле узел документа появится раньше, чем узлы связанных с ним движений.

Решение №2: Настройка ПКО и ссылочной выгрузки

Иногда изменение приоритета ПВД недостаточно, особенно если объекты выгружаются не напрямую, а по ссылкам. Проанализируем настройки ПКО (Правила конвертации объектов). Посмотрим на пример настройки свойства «Регистратор» в правилах для регистра сведений.

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

Также полезно проверить обработчик ПередВыгрузкой в ПКО регистра. Мы можем принудительно вызвать выгрузку регистратора, чтобы гарантировать его наличие:

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

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

Решение №3: Обновление обработки выгрузки и кэша

Проблема часто кроется в самой внешней обработке V8Exch82.epf (или её аналогах для разных версий). Выясним, почему это важно. Внутри обработки используется таблица объектов, подготовленных к выгрузке. Метод ТаблицаОбъектов.Сортировать("Приоритет, ИмяТипа") может отрабатывать по-разному, если приоритеты не заданы явно. На платформе 8.3.10 алгоритм сортировки может выдавать другой результат для одинаковых приоритетов по сравнению с 8.3.15.

Рекомендуем выполнить следующие действия:

• Убедитесь, что вы используете последнюю версию обработки V8Exch82.epf, входящую в состав конфигурации «Конвертация данных» вашей версии.
• Обязательно очистите кэш метаданных в самой обработке выгрузки перед началом процесса.
• Если вы правили правила в КД, не забудьте пересохранить файл правил xml и заново выбрать его в обработке выгрузки на «проблемной» платформе.

Почему это происходит «под капотом» платформы?

Разберем техническую подоплеку. Платформа 1С использует разные механизмы обхода коллекций объектов. При понижении версии платформы мы сталкиваемся с тем, что:

1. Оптимизация XDTO: В версии 8.3.12 и выше механизмы работы с XML были переписаны для ускорения работы с памятью. Это изменило логику формирования потока данных.
2. Порядок в СУБД: Если запрос в коде обработки выгрузки не содержит явного УПОРЯДОЧИТЬ ПО, СУБД (MS SQL, PostgreSQL) возвращает записи в порядке физического расположения на диске или согласно кластерному индексу. Разные версии платформы могут генерировать слегка отличающиеся SQL-запросы для получения метаданных, что косвенно влияет на итоговый файл.
3. Отложенная загрузка: В КД 2.0 есть механизм отложенной загрузки (когда объект создается как «пустышка», если на него есть ссылка, но самого объекта еще нет). На более старых платформах этот механизм может давать сбой при работе с регистрами, требующими жесткого отбора по регистратору в момент записи.

Практические советы по работе с КД 2.0

Чтобы избежать подобных проблем в будущем, придерживайтесь следующих правил при проектировании обменов:

Во-первых, всегда устанавливайте явные приоритеты ПВД. Не оставляйте их равными нулю. Используйте шаг в 10 или 100 единиц (например: Справочники — 100, Документы — 200, Регистры — 300). Это гарантирует, что справочники, на которые ссылаются документы, всегда будут в файле первыми.

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

В-третьих, используйте программную выгрузку через ВыгрузитьПоПравилу() в сложных случаях. Рассмотрим пример, когда нам нужно гарантированно выгрузить связанные данные:

// В обработчике ПВД документа "После выгрузки"
// Если нужно принудительно выгрузить движения именно после документа
Набор = РегистрыСведений.МинимальныеОстатки.СоздатьНаборЗаписей();
Набор.Отбор.Регистратор.Установить(Объект.Ссылка);
Набор.Прочитать();

Если Набор.Количество() > 0 Тогда
    ВыгрузитьПоПравилу(Набор, , , , "МинимальныеОстатки");
КонецЕсли;

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

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