Как правильно настроить правила регистрации объектов в 1С:Конвертация данных 2.1

При настройке обмена данными между конфигурациями 1С программисты часто сталкиваются с ситуацией, когда объекты регистрируются к обмену не так, как ожидалось, или не регистрируются вовсе. Особенно много вопросов вызывает работа с правилами регистрации (ПР) в инструменте Конвертация данных 2.1 (КД 2.1). Разберем по шагам, как управлять процессом регистрации объектов, почему стандартные настройки в конфигураторе могут конфликтовать с правилами КД и как добиться филигранной точности в отборе данных для обмена, используя в том числе RabbitMQ для передачи объектов по одному.

Проблема 1: Объект не регистрируется при запрете авторегистрации

Рассмотрим ситуацию: в конфигураторе в составе плана обмена для конкретного справочника установлено свойство Авторегистрация — Запретить. Программист создает правила регистрации в КД 2.1, загружает их в базу (поможет подсистема настройки регулярного обмена по правилам конвертации), но элементы справочника при записи всё равно не попадают в таблицу регистрации изменений. Почему так происходит?

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

1. Активность узла обмена: Правила регистрации срабатывают только для тех узлов, которые созданы в режиме «1С:Предприятие» и не помечены на удаление. Проверить свойства поможет информер по метаданным.
2. Наличие обработчиков: В модуле объекта (например, справочника) должны присутствовать вызовы процедур БСП в событиях ПередЗаписью или ПриЗаписи. Если конфигурация самописная и не использует БСП, загруженные XML-правила сами по себе не «оживут» — нужен программный вызов ПланыОбмена.ЗарегистрироватьИзменения().
3. Флаг стандартной обработки: В самих правилах регистрации в КД 2.1 проверьте, не стоит ли программный отказ в обработчиках, который блокирует процесс.

Проблема 2: Видны только предопределенные элементы при ручной регистрации

Часто при попытке зарегистрировать данные вручную через типовую обработку «Регистрация изменений для обмена», пользователь видит в списке выбора только предопределенные элементы. Проанализируем, с чем это может быть связано. Чаще всего это не ошибка правил, а особенность интерфейса или настроек прав:

1. Кэш метаданных: После изменения состава плана обмена или загрузки новых правил регистрации платформа может использовать старое представление данных. Рекомендуется очистить кэш или перезапустить сеанс.
2. Ограничение RLS: Проверьте, не наложены ли ограничения на уровне записей. Если у текущего пользователя нет прав на чтение определенных элементов справочника, они не будут отображаться в списке для регистрации.
3. Динамические списки: В некоторых версиях платформы форма выбора может иметь встроенные фильтры. Попробуйте воспользоваться альтернативными обработками для регистрации изменений, чтобы исключить ошибку конкретной формы — для этого подойдёт универсальная обработка массовой регистрации объектов.

Проблема 3: Почему удаление правила не отключает регистрацию

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

Если в файле правил регистрации отсутствует информация об объекте, но сам объект включен в состав плана обмена в конфигураторе с включенной авторегистрацией, платформа будет регистрировать его по стандартному алгоритму. Отсутствие правила в КД воспринимается системой как «использовать поведение по умолчанию».

Чтобы полностью исключить объект из регистрации, у нас есть два пути:

1. Исключить объект из состава плана обмена в конфигураторе (требует изменения метаданных).
2. Оставить правило регистрации в КД 2.1, но прописать в нем явный отказ.

Использование обработчика Отказ = Истина

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

Рассмотрим пример кода в обработчике «Перед обработкой». Этот обработчик выполняется в самом начале, и если мы установим Отказ = Истина здесь, система даже не будет тратить ресурсы на анализ свойств объекта.

// Пример: запрещаем регистрацию для всех элементов
Отказ = Истина;

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

// Пример: регистрируем только активные элементы
Если Объект.ПометкаУдаления Тогда
    Отказ = Истина;
КонецЕсли;

Важный нюанс: Если вы используете программный отказ, убедитесь, что в настройках правила снят флаг «Выполнить стандартную обработку», если вы хотите полностью переопределить логику БСП.

Алгоритм обновления правил в базе данных

Чтобы ваши изменения вступили в силу, недостаточно просто сохранить их в КД 2.1. Пройдем по шагам процесс корректного обновления:

1. В Конвертации данных 2.1 выгрузите правила регистрации (это отдельный файл XML, отличный от правил обмена).
2. Перейдите в рабочую базу в режиме «1С:Предприятие».
3. Откройте «Синхронизацию данных» и найдите настройки вашего узла обмена.
4. Воспользуйтесь командой «Загрузить правила регистрации объектов».
5. Обязательно: Если объект уже был зарегистрирован до того, как вы прописали Отказ = Истина, он сам не исчезнет из таблицы изменений. Вам нужно зайти в обработку «Регистрация изменений» и вручную удалить ненужные записи. Правила регистрации работают только в момент события (запись, проведение), они не фильтруют уже накопленные изменения ретроспективно.

Таким образом, мы видим, что ключом к решению проблем с регистрацией является правильное сочетание настроек в конфигураторе и использование программных обработчиков в КД 2.1. Никогда не удаляйте правила из списка, если хотите запретить регистрацию — всегда используйте явный Отказ.