Как создать и настроить правила конвертации данных в 1С
Содержание
Правила конвертации данных создают не в Конфигураторе, а в отдельном прикладном решении «Конвертация данных » (КД). Это набор узлов ПВД, ПКО и ПКС, который описывает, какие объекты выгрузить из базы-источника и как сопоставить их объектам базы-приёмника. На выходе — файл правил в XML, который подхватывает обработка «Универсальный обмен данными в формате XML».
Если вам нужно разово перенести справочники и документы между неоднородными базами (например, из самописной конфигурации в типовую), правила конвертации — штатный инструмент платформы 8.3. Он не требует одинаковой структуры метаданных у источника и приёмника: соответствие полей вы задаёте вручную.
Ниже — как устроены правила, как их собрать с нуля, отладить и не уронить производительность на базе в сотни тысяч документов.
Зачем нужны правила конвертации данных
Обмен между двумя базами 1С работает по одному принципу: платформа выгружает объекты источника в промежуточный XML, а на приёмнике загружает их обратно. Правила конвертации — это «переводчик» между структурами двух баз.
Без правил платформа не знает, что справочник Контрагенты источника должен лечь в справочник Контрагенты приёмника, а реквизит ИНН — в одноимённое поле. Когда конфигурации разные, автоматического сопоставления нет — его описывают правила.
Типичные задачи, где это нужно:
- 🔄 перенос данных из нетиповой или доработанной базы в типовую;
- 📦 первоначальное заполнение новой базы справочниками из старой;
- 🔗 регулярный обмен между конфигурациями без единого формата (когда синхронизация «из коробки» не настроена);
- 🧩 загрузка данных из внешней системы, выгруженной в XML по заданной структуре.
Для обмена между типовыми конфигурациями чаще используют встроенную синхронизацию на формате EnterpriseData — там правила уже готовы. Самостоятельная конвертация нужна там, где типовых правил нет.
Из чего состоят правила: ПВД, ПКО, ПКС и очистка
Файл правил — не монолит, а дерево из четырёх видов узлов. Понимание их ролей снимает половину вопросов.
| Узел | Полное название | За что отвечает |
|---|---|---|
| ПВД | Правила выгрузки данных | Какие объекты источника выгружать и каким ПКО их обрабатывать |
| ПКО | Правила конвертации объектов | Соответствие «объект-источник → объект-приёмник», поля поиска |
| ПКС | Правила конвертации свойств | Соответствие отдельных реквизитов и табличных частей |
| ПОД | Правила выгрузки данных для очистки | Удаление данных в приёмнике перед загрузкой |
Логика такая. ПВД — точка входа: вы говорите «выгружай справочник Номенклатура с таким отбором». ПВД ссылается на ПКО, которое отвечает на вопрос «во что превратить этот объект». Внутри ПКО лежат ПКС — по одному на каждый переносимый реквизит.
ПКС создаются не вручную по одному. В редакторе ПКО есть команда автоматического сопоставления свойств по именам — она закрывает большинство одноимённых реквизитов, а дорабатываете вы только расхождения.
Отдельно стоят параметры конвертации, алгоритмы (повторно используемый код) и запросы — их подключают в обработчиках.
Важно помнить про направление. Один файл правил описывает выгрузку из источника в приёмник — это односторонний маршрут. Если нужен встречный обмен (из приёмника обратно в источник), правила для него собирают отдельной конвертацией с зеркальным сопоставлением. Общего двунаправленного файла в КД 2.0 нет.
Поля поиска: как приёмник находит нужный объект
Это ключевая настройка ПКО, и именно из-за неё чаще всего появляются дубли. При загрузке платформа должна понять: создать новый объект или обновить существующий.
Есть два механизма поиска:
- По уникальному идентификатору (ссылке) — быстрый и точный. Подходит, когда приёмник получает данные только из одного источника и GUID-ы совпадают.
- По полям поиска — по значениям реквизитов (код, наименование, ИНН). Нужен, когда базы жили независимо и объекты в них уже есть под своими идентификаторами.
Поля поиска задают прямо в ПКО. Можно указать несколько вариантов, которые платформа перебирает по очереди: сначала по ИНН+КПП, если не нашла — по наименованию.
Если оставить поиск по идентификатору там, где в приёмнике уже есть свои контрагенты, обмен создаст их заново. Перед первой загрузкой в непустую базу всегда проверяйте настройку полей поиска на тестовой копии.
Как создать правила конвертации с нуля
Порядок один и тот же для любой пары конфигураций. Работаем в прикладном решении «Конвертация данных» (КД 2.0) — отдельной базе, которую ставят рядом с рабочими.
Полученный XML-файл правил используется обработкой «Универсальный обмен данными в формате XML»: на источнике ей выполняют выгрузку в файл данных, на приёмнике — загрузку.
Пример простейшего ПКС, который задаётся не полем, а кодом в обработчике «При выгрузке свойства»:
// Переносим код контрагента в артикул приёмника,
// обрезая ведущие нули
Значение = СокрЛП(Источник.Код);
Пока Лев(Значение, 1) = "0" И СтрДлина(Значение) > 1 Цикл
Значение = Сред(Значение, 2);
КонецЦикла;
Обработчики событий и алгоритмы
Чистого сопоставления «поле в поле» хватает редко. Как только нужно что-то вычислить, подставить значение по умолчанию или пропустить объект по условию — в дело идут обработчики событий.
Обработчик — это фрагмент кода на встроенном языке, который платформа выполняет в определённый момент обмена. Код пишется прямо в узле правила. Основные точки:
- Перед выгрузкой объекта — можно отменить выгрузку (
Отказ = Истина) или заполнить параметры. - При выгрузке / После выгрузки — доработать выгруженные свойства.
- Перед загрузкой / При загрузке — изменить объект до записи в приёмник.
- После загрузки — досоздать связанные данные, провести документ .
- Поле поиска — задать нестандартную логику поиска соответствия.
Повторяющийся код выносят в алгоритмы — их вызывают из нескольких обработчиков. Значения, общие для всей выгрузки (дата начала периода, узел обмена, признак первичной загрузки), держат в параметрах конвертации и заполняют один раз в обработчике «Перед выгрузкой данных».
Помимо обработчиков на уровне отдельных правил есть глобальные обработчики самой конвертации: «Перед выгрузкой данных», «После выгрузки данных», «Перед загрузкой данных», «После загрузки данных». В них удобно готовить общий контекст: открывать транзакцию, заполнять таблицы соответствий, отключать на время загрузки лишние проверки. Код глобальных обработчиков выполняется один раз за весь сеанс, а не на каждый объект, — это и дешевле, и надёжнее, чем дублировать логику в правилах объектов.
Не проводите документы прямо в обработчике «При загрузке». Сначала запишите объект, а проведение вынесите в «После загрузки» или в отдельный этап — так вы не словите ошибку из-за ещё не загруженных зависимых данных.
Соответствие реквизитов удобно держать перед глазами как карту полей:
Строковые значения из источника (ставка НДС, единица измерения) нельзя просто записать в ссылочный реквизит приёмника — их переводят в ссылки через ПКО или поиск в обработчике.
Как отладить правила конвертации
Отладка в КД отличается от обычной: сам файл правил кодом не является, обработчики выполняются внутри универсальной обработки обмена. Есть два рабочих способа.
Протокол обмена. В обработке универсального обмена включите ведение протокола с подробной информацией. В файл протокола попадут все предупреждения и ошибки с указанием объекта и правила — обычно этого хватает, чтобы найти, где обмен «спотыкается».
Пошаговая отладка обработчиков. При выгрузке правил из КД отметьте флаг выгрузки с возможностью отладки. Тогда КД сформирует внешнюю обработку , в коде которой видны все ваши обработчики. Её подключают к конфигуратору, ставят точки останова и проходят выгрузку или загрузку пошагово, как обычный код.
Что обычно отлавливают при отладке:
- 🐞 обработчик падает на
Неопределено— источник не содержит ожидаемого реквизита; - 🐞 объект не выгружается — сработал
Отказ = Истинаили нет связанного ПВД; - 🐞 свойство приходит пустым — ошибка в имени реквизита-источника или в ПКС.
Перед загрузкой в рабочую базу всегда прогоняйте обмен на свежей копии. Откатить частично загруженные данные без резервной копии нельзя.
Производительность на больших базах
На справочниках правила работают быстро. Проблемы начинаются на документах за несколько лет — выгрузка может идти часами. Что помогает:
- Отборы в ПВД. Выгружайте только нужное: период, организацию, вид документа. Лишние миллионы строк — главный пожиратель времени.
- Поиск по идентификатору вместо строковых полей. Поиск по GUID индексирован и быстр; поиск по наименованию на большой базе приёмника заметно тормозит.
- Загрузка без проведения. При массовой первичной загрузке документы записывают без проведения, а проводят отдельной обработкой группового перепроведения по периодам.
- Порции по периодам. Разбейте выгрузку на кварталы или месяцы — несколько файлов данных грузятся предсказуемее одного гигантского.
- Лёгкие обработчики. Запрос к базе внутри обработчика, который вызывается на каждый объект, умножает время в разы. Выносите выборку в параметры конвертации один раз до цикла.
На регулярном обмене включайте регистрацию изменений через план обмена — тогда повторные выгрузки берут только то, что изменилось с прошлого раза, а не весь массив заново.
Типовые правила и КД 3.0 как альтернатива
Писать правила с нуля нужно не всегда. Сначала проверьте, нет ли готового решения.
Встроенная синхронизация. Между типовыми конфигурациями (Бухгалтерия, ЗУП, Управление торговлей) обмен настраивается без КД — через раздел Администрирование → Синхронизация данных. Там правила уже зашиты в конфигурацию на формате EnterpriseData.
КД 3.0. Это следующее поколение конвертации, тоже на формате EnterpriseData. В отличие от 2.0, результат — не XML-файл правил, а модуль менеджера обмена, который подключается через подсистему обмена Библиотеки стандартных подсистем. КД 3.0 выбирают, когда нужен регулярный обмен с типовой конфигурацией и формат EnterpriseData подходит обеим базам.
КД 2.0 остаётся актуальной там, где форматы и структуры произвольные: разовый перенос, нетиповые базы, загрузка из внешних систем. Прямого соответствия между правилами 2.0 и 3.0 нет — при переходе их описывают заново.
Как выбрать направление:
| Задача | Инструмент |
|---|---|
| Обмен между двумя типовыми | Встроенная синхронизация |
| Регулярный обмен, обе базы на EnterpriseData | КД 3.0 |
| Разовый перенос из нетиповой базы | КД 2.0 |
| Загрузка из внешней системы по своему XML | КД 2.0 |