Контрагента поправили, а в Рознице всё по-старому. Где искать причину в правилах обмена

Поправка от 21.09.2026. В первой редакции статьи стоял вывод, что 21 объект из 75 в очередь обмена сам не встанет никогда. Вывод неверный. Объект без своего правила регистрации БСП ставит в очередь всех узлов плана, без отбора. Я проверил это на стенде и по коду, раздел "21 объект без своего правила" переписан. Спасибо Tria за возражение в комментариях, оно оказалось верным.

Жалоба, которую слышал каждый, кто вёл обмен между базами: "поправили справочник, а на той стороне старое". Дальше обычно проверяют регламентное задание, смотрят очередь сообщений, перезапускают обмен, в тяжёлом случае снимают регистрацию и гонят полную выгрузку. Иногда помогает. Потом повторяется.

Я полез разбираться в это на уровне файла правил. Взял типовые правила обмена "Управление торговлей - Розница" из поставки, те самые, которые лежат макетом в плане обмена, и свёл три списка, которые внутри них живут. У 21 объекта из 75 в составе плана обмена нет своего правила регистрации. Среди них Контрагенты, Характеристики номенклатуры, Штрихкоды, Пользователи, Физические лица, Ценовые группы. Правка любого из них уходит в очередь всех узлов плана, без отбора.

Это не поломка и не чей-то кривой доработанный обмен. Это то, что вы получаете из коробки.

Сначала про то, откуда берётся файл правил

Тут есть ловушка, на которой я сам однажды потерял половину дня, и о ней стоит сказать до всего остального.

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

Подробно этот случай я разбирал отдельно в статье "Ставку поменяли в трёх базах. Хардкод об этом не знал". Здесь важен только вывод: прежде чем разбирать правила, установите, откуда их читает ваш конкретный обмен. Дальше по тексту я считаю, что файл у вас на руках - тот самый, который реально исполняется.

Три списка, которые описывают один обмен

Комплект правил "Конвертации данных 2" это не один файл, а несколько, и они описывают разные вещи. Разбирается это за минуту, но сводят их вместе редко, потому что интерфейс обмена показывает результат, а не устройство.

Состав плана обмена отвечает на вопрос, кто в принципе участвует. Это список типов, у каждого стоит признак авторегистрации. В типовых правилах УТ - Розница таких элементов 75, и авторегистрация выключена у всех 75. Это нормально для обменов по правилам: регистрацией управляют правила регистрации, а не платформа.

Правила регистрации отвечают, в очередь каких узлов и при каких условиях встаёт изменение. Здесь их 79 штук на 68 разных объектов, плюс 312 условий отбора: не всякое изменение должно ехать, у многих объектов стоят условия вроде "только по своей организации" или "только проведённые".

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

Списки лежат в разных файлах и друг о друге ничего не знают. Никто не гарантирует, что объект, который стоит в первом, окажется во втором.

21 объект без своего правила

Свёл состав плана с правилами регистрации поимённо. Получилось 21 объект, у которого авторегистрация выключена и собственного правила регистрации нет.

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

Код. Типовая УТ 11.5.22.67, модуль ОбменДаннымиСобытия. Когда авторегистрация объекта выключена, механизм регистрации выполняет его правила регистрации. Для объекта, у которого правил нет вовсе, в коде стоит отдельная ветка с комментарием "Правила регистрации не заданы": объект регистрируется на всех узлах плана обмена, кроме предопределённого.

Стенд. Та же УТ 11.5.22.67, план обмена с Розницей, типовые правила регистрации загружены из макета, один узел, синхронизация данных включена. Поправил у контрагента одно поле, и изменение встало в очередь узла. Для контроля так же поправил номенклатуру, у которой своё правило есть: в очередь пустого узла она не встала, её отсекло собственное правило. В таблицах изменений узла после замера контрагентов 1, номенклатуры 0.

Отсюда правильный вывод: нет своего правила, значит нет и отбора. Изменение уходит на все узлы плана.

У восемнадцати есть правила выгрузки и конвертации. Их правка встаёт в очередь каждого узла и уезжает со следующим обменом, нужен там этот объект или нет:

• Контрагенты
• Характеристики номенклатуры
• Упаковки единицы измерения
• Штрихкоды номенклатуры
• Пользователи и Группы пользователей
• Физические лица и Виды документов физических лиц
• Марки, Карты лояльности, Ценовые группы
• Товарные категории, Форматы магазинов, Номенклатура сегмента
• Дополнительные сведения, Виды алкогольной продукции, Лицензии поставщиков алкогольной продукции, Правила начисления и списания бонусных баллов

У трёх нет ни правила выгрузки, ни правила регистрации: Двоичные данные файлов, Соответствия объектов информационных баз и Удалить учётная политика организаций. Первые два служебные, а третий с приставкой "Удалить" в имени - это остаток от прошлых релизов, который так и лежит в составе плана.

Практический перевод для Контрагентов. Менеджер поправил в УТ адрес доставки у контрагента. Правка встаёт в очередь каждого узла Розницы и уезжает со следующим сеансом обмена. Отбора по организации или магазину нет, потому что отбирать нечем: правила нет.

Когда правка в очередь всё-таки не встаёт

Жалоба "поправили справочник, а на той стороне старое" от этого никуда не делась, просто отсутствие правила её не объясняет. В коде БСП перед правилами регистрации стоят ещё две ступени, и обе срабатывают молча.

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

Выборочная регистрация. У плана обмена есть режим, который решает, считать ли запись объекта изменением. Когда он работает по правилам обмена, правка реквизита, которого нет в правилах конвертации свойств, изменением не считается и в очередь не встаёт. Если строк объекта в этих правилах нет совсем, фильтра нет, и изменением считается любая запись. В типовом плане УТ - Розница режим другой: там смотрят, менялся ли объект вообще.

Хорошо это или плохо

Зависит от сети. Пока узлов несколько, разницы никто не заметит. Когда их десятки, правка одного контрагента уезжает в каждый магазин, и никакие условия вроде "только по своей организации", как у соседних объектов, на неё не действуют. Нужен отбор, значит нужно своё правило регистрации.

Беда в том, что это поведение нигде не написано. Ни в интерфейсе настройки обмена, ни в описании к правилам. Чтобы его увидеть, надо открыть файл правил, свести два списка и знать, что БСП делает с объектом без правила. Последнего я, как видно, не знал.

И вот тут начинается то, ради чего я вообще в это полез.

Открыть файл правил глазами не получится

Возьмём боевые правила того же обмена, Розница в сторону ERP, обезличенно. Файл на 2,1 мегабайта. Внутри:

• 109 правил выгрузки данных;
• 202 правила конвертации объектов;
• 2 138 правил конвертации свойств, собранных в 118 групп;
• 415 правил конвертации значений;
• 18 алгоритмов и 8 запросов;
• 602 места с программным кодом, суммарно 234 451 символ.

Максимальная глубина вложенности XML - 14 уровней. Правила лежат в группах, группы в группах, и обход, который не делает рекурсию честно, теряет часть правил молча. Я на этом обжёгся сам, об этом ниже.

Открыть такой файл в редакторе можно. Прочитать его - нет. Даже на типовых правилах УТ - Розница, которые вдвое меньше, лежат 167 правил конвертации и 1 374 правила конвертации свойств.

Штатный способ на этот случай один: загрузить правила в "Конвертацию данных 2" и смотреть их там. Способ рабочий, но у него есть условие, которое выполняется не всегда: у вас должна быть развёрнута сама "Конвертация данных". На чужом проекте, на разборе инцидента, на базе заказчика её обычно нет, а разбираться надо сейчас.

Что видно по структуре, если её всё-таки прочитать

Кроме истории с регистрацией, в структуре видно ещё несколько вещей, и все они про потерю или порчу данных.

Правила без способа поиска. У правила конвертации есть три способа найти объект в приёмнике: по уникальному идентификатору, по полям поиска и по таблице сопоставления значений. Если не задан ни один, обмен не может понять, есть ли такой объект на той стороне, и создаёт его заново. Каждый раз. На боевых правилах Розница - ERP таких правил девять, на типовых УТ - Розница десять.

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

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

Смена типа объекта. На боевых правилах Розница - ERP 50 правил из 202 меняют тип объекта на той стороне: склад превращается в магазин, вид цен - в правило ценообразования, подарочный сертификат - в серийный номер. Это законная конструкция обмена между разными конфигурациями, но это же и список мест, где данные меняют смысл. Если проверять обмен выборочно, проверять надо в первую очередь их.

Проверка, которую пришлось выбросить

Теперь про то, где я ошибся, потому что это важнее удачных находок.

Первая версия проверки "нет способа поиска" показала на боевом файле 72 правила. Семьдесят два правила, каждое из которых может плодить дубли - это уже не диагноз, это приговор обмену. Я почти поверил.

Стал смотреть список поимённо. В нём оказались перечисления. У перечисления полей поиска не бывает и не должно быть: оно ищется по таблице сопоставления значений, и это штатный способ. То есть проверка считала нормальную конструкцию формата поломкой.

После оговорки про перечисления осталось девять правил. Разница между 72 и 9 - это разница между инструментом, которому верят, и инструментом, который один раз напугал и после этого закрывается не глядя.

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

Вторая ошибка была тише и опаснее. Счётчик свойств обходил дерево на семь уровней вглубь и выдавал 1 101 свойство вместо 2 138. Ровно вдвое меньше, и число при этом выглядело абсолютно правдоподобно. Поймалось это только тем, что я разобрал тот же файл независимо, на другом языке, и сравнил счётчики построчно. Совпасть они должны были до единицы. Не совпали.

Тот же приём поймал и третью ошибку, уже при подготовке этой статьи. Состав плана обмена называет объект типом значения, "РегистрСведенийЗапись.ШтрихкодыНоменклатуры", а правило регистрации - именем объекта метаданных, "РегистрСведений.ШтрихкодыНоменклатуры". Пока я не привёл их к общему виду, все регистры попадали в список "без своего правила" фальшиво, и вместо 21 объекта получалось 24.

Четвёртую ошибку этот приём поймать не мог: числа сходились, неверным был вывод о том, что с этими объектами делает платформа. Её нашли в комментариях, об этом поправка в начале статьи.

Где в правилах прячется код

И последнее, из-за чего разбор структуры имеет предел.

Мест с кодом в правилах заметно больше, чем девять глобальных обработчиков, про которые обычно помнят. Свой обработчик есть у каждого правила конвертации, у каждого правила выгрузки, у каждого отдельного свойства и у каждой группы свойств. Узел "Последовательность полей поиска" целиком состоит из кода, до 900 символов. Отдельными разделами лежат алгоритмы и запросы. В правилах регистрации код прячется в значении константы, когда у элемента отбора стоит вид "алгоритм значения".

На типовых правилах УТ - Розница это 202 места и 56 771 символ. На боевых Розница - ERP - 602 места и 234 451 символ. Двести тридцать килобайт кода, который выполняется при каждом обмене.

Отсюда граница, которую честно обозначить важнее, чем красиво её обойти. Структура правил отвечает на вопрос "что настроено". На вопрос "что произойдёт с данными" она не отвечает, потому что половину решает код. Обработчик может отменить выгрузку объекта, подменить значение реквизита, отбросить строку табличной части, и по структуре этого не видно.

Правильное поведение инструмента здесь - показать, где код есть, и не делать вид, что он понял, что этот код делает. Разбор помечает места с кодом и отдаёт их текст. Решение принимает человек.

Чем я это считал

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

Лежит здесь: Анализ правил обмена КД 2.

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

Вопрос, на который у меня нет ответа

Теперь вопрос стоит иначе. Отсутствие правила у Контрагентов в типовой поставке - это осознанное "шлём всем", потому что Рознице нужен весь справочник, или правило просто никто не написал? За первое говорит то, что в список попали справочники, которые магазину нужны целиком: пользователи, карты лояльности, штрихкоды. Против - "Удалить учётная политика организаций" в том же списке. Это забытый хвост прошлых релизов, решением его не назовёшь.

Если вы ведёте такие обмены давно и знаете, как это задумывалось, напишите. Мне интересно, где тут замысел, а где инерция. И если ставили контрагентам своё правило с отбором, расскажите, чем это кончилось.

Другие наши инструменты

• Анализ правил обмена КД 2 - обработка из этой статьи: читает файл правил конвертации или регистрации и отвечает, что выгружается, во что превращается, как ищется в приёмнике и где лежит код.
• Чек-ап чистоты базы 1С - что накопилось в базе и что из этого можно убрать без последствий.
• ИИ-анализ кода внешних обработок - разбор чужих обработок из справочника: что они делают с данными и куда ходят.
• Выгрузка структуры метаданных 1С для нейросети - конфигурация в виде, который модель читает целиком и перестаёт выдумывать реквизиты.
• Журнал регистрации, свёрнутый для нейросети - журнал в вид, который модель способна прочитать целиком.