При настройке синхронизации между конфигурациями «Бухгалтерия предприятия 3.0» и «Зарплата и управление персоналом 3.1» программисты часто сталкиваются с ситуацией, когда стандартные механизмы фильтрации данных не срабатывают. Казалось бы, в «Правилах регистрации объектов» (ПРО) прописано условие Отказ = Истина, но справочники, такие как ФизическиеЛица, все равно попадают в узел плана обмена и благополучно улетают в базу-приемник. В этой статье мы подробно разберем, почему так происходит, и как правильно настроить отсечение ненужных данных.
Прежде всего, давайте проанализируем фундаментальную разницу между двумя процессами. В системе 1С существует два этапа передачи данных:
В сообщении автора прозвучала фраза об использовании обработчика «Перед выгрузкой» внутри правил регистрации. Важно понимать: в классических правилах регистрации (созданных через «Конвертацию данных 2.0») основным обработчиком для фильтрации является Перед обработкой. Если код написан в обработчике, который относится к моменту формирования файла, регистрация на узле плана обмена уже могла произойти ранее, и объект «зависнет» в очереди.
Выясним причину, по которой физические лица часто «проползают» в обмен, даже если для них прописан безусловный отказ. Это механизм регистрации по ссылке (или транзитивная регистрация). Современные обмены, построенные на базе БСП (Библиотеки стандартных подсистем), стремятся сохранить ссылочную целостность данных.
Рассмотрим ситуацию: вы запретили регистрацию справочника ФизическиеЛица. Однако вы разрешили выгрузку документов (например, ВедомостьНаВыплатуЗарплаты) или справочника Сотрудники. Когда система регистрирует документ, она видит, что в нем есть ссылка на физическое лицо. Чтобы в базе-приемнике не возникло «битых» ссылок (объектов с пометкой <Объект не найден>), БСП автоматически регистрирует и связанные объекты, игнорируя ваши фильтры в правилах регистрации для этих справочников.
Проанализируем состояние плана обмена в конфигураторе. Даже если вы используете внешние файлы правил, поведение системы во многом определяется свойствами самого объекта ПланОбмена. Разберем по шагам, на что обратить внимание:
СинхронизацияДанныхЧерезУниверсальныйФормат).ФизическиеЛица.Если там установлено значение Разрешить, то платформа 1С будет регистрировать изменения объекта при каждой записи, даже не обращаясь к программным правилам регистрации в некоторых случаях. Для реализации сложной логики фильтрации рекомендуется устанавливать Запретить и прописывать логику регистрации программно в модуле менеджера плана обмена или через правила регистрации.
Для того чтобы эффективно отсекать объекты, необходимо использовать правильные обработчики. Рассмотрим пример кода в правилах регистрации для справочника. Наиболее подходящим местом для установки отказа является обработчик Перед обработкой.
Пример реализации логики в ПРО:
// В обработчике "Перед обработкой" правила регистрации справочника
Если Объект.ЭтоГруппа Тогда
Отказ = Истина; // Группы нам в обмене не нужны
ИначеЕсли Объект.ПометкаУдаления Тогда
// Можно оставить регистрацию для удаления в приемнике
ИначеЕсли Не СвойствоУдовлетворяетУсловию(Объект.Организация) Тогда
Отказ = Истина; // Фильтр по организации
КонецЕсли;
Обратите внимание, что если объект уже был зарегистрирован до того, как вы внесли изменения в правила, он сам из списка регистрации не исчезнет. Вам необходимо вручную очистить очередь регистрации изменений для данного узла.
Современные обмены между БП 3.0 и ЗУП 3.1 чаще всего используют XDTO-пакеты и «Универсальный формат». В этом случае логика регистрации может быть жестко зашита в модулях конфигурации. Посмотрим на функции, которые могут перекрывать работу внешних правил:
ПриРегистрацииИзмененийДляВыгрузки в модуле менеджера плана обмена.ОбменДаннымиПереопределяемый.Если логика регистрации прописана там, то никакие манипуляции с XML-файлами правил регистрации не помогут, так как программный код в модулях имеет приоритет.
Если настройка правил регистрации не помогает из-за транзитивной выгрузки, разберем альтернативные варианты решения задачи:
Вместо того чтобы бороться с регистрацией, можно поставить запрет на этапе формирования данных. В «Правилах конвертации объектов» (ПКО) для справочника ФизическиеЛица в обработчике Перед выгрузкой установите Отказ = Истина. В этом случае «метка» на плане обмена останется, но при попытке выгрузки система просто проигнорирует объект, и в файл он не попадет.
Как упоминалось в обсуждении, дата запрета загрузки — это механизм базы-приемника. Рассмотрим ситуацию: база ЗУП отказывается принимать данные старее определенной даты. Это полезно для защиты учета, но не решает проблему трафика. Объект все равно будет регистрироваться в БП, упаковываться в XML/JSON и передаваться по сети. Более того, это может привести к постоянным предупреждениям в журнале регистрации о невозможности загрузки объекта.
После любых изменений в правилах регистрации обязательно выполните следующие действия:
ФизическиеЛица.Только после этого вы сможете проверить, регистрируются ли новые изменения по вашим новым правилам.
Проанализировав ситуацию, мы выяснили, что «проползание» справочников мимо фильтров регистрации чаще всего связано с транзитивностью ссылок или использованием неверных обработчиков. Для эффективного управления обменом БП-ЗУП рекомендуем использовать комплексный подход: проверку Авторегистрации в плане обмена, корректную настройку ПР в Перед обработкой и ручную очистку старых «хвостов» в очереди регистрации.