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

← На главную

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

Причина возникновения «неограниченных» строк

Проанализируем механизм работы КД при использовании функции «Загрузить правила в новую конвертацию данных». Когда мы выбираем этот вариант и не указываем предварительно выгруженные файлы описания метаданных (созданные обработкой MD82.epf), система пытается восстановить структуру объектов конфигурации на лету, опираясь исключительно на содержимое файла ExchangeRules.xml.

Выясним причину такого поведения. В структуре XML-файла правил обмена для каждого реквизита (свойства) выгружается только его базовый тип. Узел описания свойства выглядит примерно так:

<Источник Имя="Код" Вид="Реквизит" Тип="Строка"/>

Как мы видим, в самом файле правил отсутствует информация о квалификаторах типа: длине, точности или допустимых знаках для чисел. В результате, когда КД создает «виртуальные» метаданные внутри своей базы, она подставляет значения по умолчанию. Для типа Строка — это всегда «Неограниченная», для типа Число — «15, 0».

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

Последствия потери типизации в правилах

Рассмотрим, на что влияет отсутствие жестко заданной длины строки в ПКС (Правилах конвертации свойств):

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

Способы исправления структуры метаданных

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

Шаг 1: Выгрузка актуальных метаданных. Используйте обработку MD82.epf (или аналогичную для вашей версии платформы) в конфигурациях Источника и Приемника. Убедитесь, что выгружаете метаданные из тех же баз, для которых предназначены правила.

Шаг 2: Обновление метаданных в КД. В справочнике «Конфигурации» выберите нужную запись и воспользуйтесь кнопкой «Загрузить описание конфигурации из файла». После загрузки система обновит информацию о длине строк, точности чисел и составе перечислений.

Шаг 3: Синхронизация свойств. Чтобы ПКС «подцепили» новые данные, рекомендуется выполнить следующие действия:

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

Использование глобальных обработчиков вместо ПКС

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

Проанализируем этот подход. С одной стороны, это кажется удобным — один скрипт для всех объектов. Однако у этого метода есть существенные минусы:

Производительность. Глобальный обработчик вызывается при загрузке абсолютно каждого объекта. Если вы добавите туда условие для проверки типа объекта, например:


Если ТипЗнч(Объект) = Тип("СправочникОбъект.Организации") Тогда
    // какая-то логика
КонецЕсли;

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

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

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

Таким образом, для качественной настройки обмена между конфигурациями (такими как БП 2.0 и ЗУП 2.5) всегда начинайте с корректной выгрузки метаданных через файлы .xml. Это избавит вас от необходимости ручного прописывания длин строк и позволит использовать все автоматизированные механизмы контроля данных, заложенные в «1С:Конвертация данных».