Правила обмена в 1С: где лежат, чем править и как не сломать синхронизацию

Синхронизация годами ходила без сбоев, а потом в приёмник перестало попадать новое поле документа или появился новый вид номенклатуры — и обмен его игнорирует. Значит, пора лезть в правила обмена: именно они решают, какой объект источника во что превращается в базе-приёмнике и какие реквизиты при этом переносятся.

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

С чего начать: выбор инструмента под вашу схему обмена

Сначала определите, по какой технологии построен ваш обмен — от этого зависит всё остальное.

• 🧩 Конвертация данных 2.0 (КД 2.0). Правила хранятся в отдельном XML-файле. Его загружает обработка универсального обмена в формате XML. Так работают старые самописные обмены и часть выгрузок «один в один».
• 🔄 Конвертация данных 3.0 (КД 3.0). Современный механизм на базе библиотеки стандартных подсистем (БСП). Данные идут через универсальный формат EnterpriseData, а правила выгружаются не в XML, а в модуль менеджера обмена. На КД 3.0 построена типовая синхронизация между БП 3.0, ЗУП 3.1, УТ 11, ERP и другими современными конфигурациями.

Проверить тип просто: если в настройке обмена фигурирует формат EnterpriseData и «универсальный формат» — это КД 3.0. Если вы грузите в обмен файл вида ПравилаОбмена.xml через обработку обмена XML — это КД 2.0.

Что понадобится для работы:

1. Сама конфигурация «Конвертация данных» нужной редакции — отдельная база, её ставят как типовую.
2. Доступ к структуре метаданных обеих баз — источника и приёмника. Для КД 2.0 структуру выгружают специальной обработкой и загружают в КД. Для КД 3.0 контексты конфигураций и описание формата загружаются из баз-участников.
3. Права и доступ в Конфигуратор приёмника, если правила встроены в модуль менеджера обмена (случай КД 3.0 в коробочной поставке).

Из чего состоит файл правил обмена

Чтобы осмысленно править правила, надо понимать их внутреннее устройство. Структура у КД 2.0 и 3.0 разная.

Правила КД 2.0 — это XML-документ с деревом элементов. Основные блоки:

Каждое ПКО связывает объект-источник с объектом-приёмником и содержит набор ПКС для реквизитов. У правил есть обработчики событий — куски кода на встроенном языке, которые срабатывают до выгрузки, после загрузки и в других точках.

Правила КД 3.0 устроены иначе. Здесь между базами стоит промежуточный универсальный формат EnterpriseData, описанный через XDTO-пакеты. Обмен разбивается на две конвертации:

• из объекта источника → в объект формата EnterpriseData;
• из объекта формата → в объект приёмника.

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

XDTO в этой схеме — это словарь типов: Документ.РеализацияТоваровУслуг, Справочник.Номенклатура и так далее описаны как XDTO-объекты с набором свойств. Если нужного поля нет в формате, его сперва добавляют в описание формата (в пакет XDTO), и только потом на него можно настроить правило.

Как редактировать правила в Конвертации данных

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

Порядок для КД 2.0:

1. Загрузите в базу КД актуальную структуру метаданных источника и приёмника. Если конфигурации менялись (добавили реквизит, новый вид документа) — структуру надо перезагрузить, иначе нового поля в правилах просто не будет видно.
2. Откройте нужную конвертацию (связку «источник → приёмник»).
3. Найдите правило конвертации объекта, которое переносит нужный документ или справочник.
4. Внутри ПКО добавьте или поправьте правило конвертации свойства (ПКС): сопоставьте реквизит источника реквизиту приёмника.
5. Если перенос нетривиальный (значение надо вычислить, подставить по условию) — пропишите обработчик на встроенном языке в соответствующем событии правила.
6. Выгрузите правила обмена в файл XML.
7. Загрузите файл в рабочую базу через обработку универсального обмена и прогоните тестовую выгрузку.

Порядок для КД 3.0 отличается на старте и на финише:

1. Загрузите контексты обеих конфигураций и версию формата EnterpriseData из баз-участников.
2. Откройте настройку обмена между нужными конфигурациями.
3. Поправьте правило конвертации объекта: со стороны источника — как объект кладётся в формат, со стороны приёмника — как из формата он разворачивается в документ или справочник.
4. Если поля нет в формате — сначала добавьте его в описание формата (XDTO-пакет), затем настройте на него ПКС.
5. Выгрузите правила в модуль менеджера обмена и перенесите его в приёмник (в типовых — через загрузку правил в настройке синхронизации или через расширение конфигурации ).

Для сопоставления полей держите перед глазами карту соответствий — это снижает число ошибок на правках:

Когда и как править XML правил вручную

Ручная правка XML — быстрый, но рискованный путь. Он уместен, когда:

• нужно точечно поменять один обработчик или значение параметра, а поднимать всю базу КД ради этого долго;
• вы точно знаете, какой элемент правите, и понимаете структуру файла;
• изменение не затрагивает структуру метаданных (не добавляет новых объектов), а лишь корректирует существующее правило.

Чего руками в XML лучше не делать: добавлять новые ПКО и ПКС с нуля, менять версию формата, трогать XDTO-описание. Такие правки почти всегда проще и надёжнее собрать в КД.

Технические требования к файлу, которые нельзя нарушать:

• 📄 Кодировка. Файл правил — в кодировке UTF-8. Если открыть его в редакторе, который пересохранит в другой кодировке, кириллица в синонимах и обработчиках превратится в «кракозябры», и загрузка упадёт.
• 🔖 Парность тегов. Каждый открывающий тег должен иметь закрывающий. Самая частая причина «битого» файла — случайно удалённый закрывающий тег при копировании блока.
• 🔣 Спецсимволы. Внутри текста обработчиков символы <, >, & нужно экранировать (<, >, &), иначе парсер примет их за разметку.

Правьте в текстовом редакторе с подсветкой XML и проверкой структуры — он сразу покажет непарный тег и неэкранированный символ. Обычный «Блокнот» для этого не годится: он не видит ошибок и легко меняет кодировку.

Ошибки при редактировании правил и как их устранить

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

Отдельно про версии формата в КД 3.0: источник и приёмник должны работать на совместимой версии EnterpriseData. Если вы добавили поле в формат на новой версии, а приёмник остался на старой — он это поле не примет. Версию формата поднимают согласованно в обеих базах.

Как протестировать и отладить изменённые правила

Не загружайте свежие правила сразу в рабочую синхронизацию. Проверьте их по шагам на копии.

Как ловить причину, если что-то пошло не так:

• 🔍 Протокол обмена. Обработка обмена и типовая синхронизация ведут журнал (протокол) с предупреждениями и ошибками. Начинайте разбор с него — там обычно указан объект и правило, на котором споткнулись.
• 🐞 Отладчик Конфигуратора. Обработчики правил — это код на встроенном языке. Поставьте точку останова в обработчике и прогоните выгрузку в режиме отладки, чтобы увидеть, какие значения реально приходят.
• 🧪 Контрольный пример. Держите небольшой набор эталонных документов, на которых каждый раз проверяете правила. Так регрессию (когда правка одного правила ломает другое) видно сразу.

Если после правки обмен стал вести себя непредсказуемо и быстро найти причину не удаётся — откатитесь на прежнюю версию правил из резервной копии и разбирайтесь на тесте. В рабочей базе экспериментировать с данными нельзя.

Частые вопросы