Как исключить неактуальные объекты из обмена данными в 1С: настройка правил регистрации и конвертации

При настройке нетиповых обменов данными между конфигурациями (например, между 1С:Зарплата и управление персоналом 3.1 и 1С:Управление производственным предприятием) часто возникает необходимость отсекать выгрузку устаревших, помеченных на удаление или неактуальных данных. Типичный пример — справочник ПодразделенияОрганизаций, в котором расформированные подразделения (Расформировано = Истина) не должны переноситься в базу-приемник.

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

Вариант 1. Фильтрация в правилах конвертации объектов (ПКО)

Самый быстрый и надежный способ исключить объект из выгрузки — перехватить его обработку непосредственно в обработчике события ПередВыгрузкой правила конвертации соответствующего справочника в конфигурации «Конвертация данных 2».

Рассмотрим пошагово реализацию данного подхода:

1. Откроем правила обмена в конфигурации «Конвертация данных 2.1».
2. Найдем необходимое Правило конвертации объекта (ПКО) для справочника ПодразделенияОрганизаций.
3. Перейдем на вкладку Обработчики событий и выберем событие ПередВыгрузкой.
4. Напишем условие проверки реквизита объекта-источника:

Если Источник.Расформировано = Истина Тогда
    Отказ = Истина;
КонецЕсли;

Проанализируем, как работает этот механизм. Когда система начинает выгрузку зарегистрированных изменений, она считывает объект из базы-источника и передает его в обработчик. Переменная Отказ = Истина; сообщает процедуре выгрузки, что данный объект не нужно сериализовать в результирующий XML-пакет. Формирование узла объекта прерывается, и в файл попадают только актуальные элементы.

Почему отмененные объекты не зависают в очереди плана обмена

У многих разработчиков возникает резонный вопрос: если объект был зарегистрирован к обмену, но в момент выгрузки сработал Отказ = Истина;, не останется ли он в таблице регистрации изменений бесконечно?

Разберем внутренний механизм работы планов обмена платформы 1С:Предприятие 8:

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

Таким образом, «хвостов» в зарегистрированных изменениях не остается, если сеансы обмена проходят штатно с фиксацией квитанций.

Вариант 2. Фильтрация на этапе регистрации (ПРО)

Более академичный и производительный подход — предотвратить саму регистрацию изменений в базе, чтобы не создавать лишних записей в таблицах плана обмена. Для этого используются Правила регистрации объектов (ПРО).

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

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

Как корректно настроить обработчик в ПРО

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

// Проверяем заполненность реквизита объекта
Если ЗначениеЗаполнено(Объект.Расформировано) И Объект.Расформировано = Истина Тогда
    Отказ = Истина;
КонецЕсли;

Обратите внимание: в контексте обработчика ПередОбработкой параметр Объект представляет собой объектную сущность или ссылку, переданную из подписки на событие. Присвоение Отказ = Истина; отменяет запись в таблицу изменений только для текущего события.

Рекомендации для надежной архитектуры обмена

Для создания отказоустойчивой системы обмена данными рекомендуется сочетать оба метода:

1. В ПРО настраивать отборы по реквизитам для минимизации размера таблицы изменений и снижения нагрузки на СУБД при частых перезаписях объектов.
2. В ПКО дублировать условие через Отказ = Истина в событии ПередВыгрузкой, что гарантирует защиту от передачи нежелательных данных в случаях ручной регистрации изменений или связанных ссылочных выгрузок.