Как программно зарегистрировать справочники и документы по правилам регистрации КД 2.1

← На главную

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

Разбираемся в режимах выгрузки объектов

В настройках правил регистрации объектов существует ключевой флаг «Режим выгрузки». Мы часто видим его при редактировании ПРО в КД 2.1. Давайте проанализируем, что означает каждое значение, так как именно от них зависит поведение программных методов регистрации:

Выгружать всегда (РежимВыгрузкиДокументов / РежимВыгрузкиСправочников): В этом режиме система считает объект «самостоятельным». Как только происходит запись объекта (или вызов процедуры регистрации), программа проверяет его на соответствие фильтрам (например, по организации или складу). Если условия соблюдены, объект регистрируется на узле.
Выгружать при необходимости: Это «ленивый» режим. Объект не будет зарегистрирован самостоятельно, даже если вы его записали. Он попадет в очередь на выгрузку только в том случае, если на него ссылается другой объект, который уже зарегистрирован. Например, справочник «Номенклатура» приедет в базу-приемник только вместе с «Расходной накладной». Это критически важно понимать при отладке программного кода: если вы пытаетесь зарегистрировать справочник с таким режимом через правила, система может его проигнорировать, так как «необходимость» еще не возникла.
Выгружать вручную: Автоматика здесь полностью отключена. Регистрация возможна только через специализированные обработки (например, «Состав отправляемых данных») или прямой вызов методов платформы.

Почему стандартные процедуры БСП могут не регистрировать справочники

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

Настройка режима в ПРО: Как мы упоминали выше, если для справочника установлен режим «При необходимости», то универсальная процедура проверки правил «увидит» этот флаг и откажет в прямой регистрации.
Отсутствие изменений в реквизитах: Некоторые версии БСП оптимизированы так, что если объект не менялся (не был модифицирован), процедура регистрации по правилам может решить, что регистрировать его не нужно.
Обработчик «Перед регистрацией»: Проверьте правила регистрации в КД 2.1. Если в обработчике стоит условие типа Отказ = Истина для определенных условий или если обмен выполняется в режиме загрузки, регистрация не произойдет.

Способ 1: Принудительная регистрация (Платформенный метод)

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

Рассмотрим пример кода:


// Выбираем конкретный узел плана обмена
УзелОбмена = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("Бухгалтерия Предприятия");

// Регистрируем ссылку на объект
Если Не УзелОбмена.Пустая() Тогда
    ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ОбъектСсылка);
    Сообщить("Объект успешно зарегистрирован для обмена");
КонецЕсли;

Способ 2: Программная регистрация с проверкой правил (БСП)

Когда нам все же нужно, чтобы система проверила правила (например, чтобы справочник не улетел в базу другой организации), следует использовать специализированные функции БСП. В современных версиях конфигураций (на базе БСП 2.x и 3.x) для этого лучше всего подходит модуль ОбменДаннымиСервер или ОбменДаннымиСобытия.

Выясним, какой метод использовать для массовой или одиночной регистрации:


// Используем метод БСП для регистрации с учетом логики ПРО
// Этот метод имитирует стандартный процесс записи объекта
УзлыДляРегистрации = Новый Массив;
УзлыДляРегистрации.Добавить(НужныйУзел);

// Важно: передаем именно объект или ссылку в зависимости от версии БСП
ОбменДаннымиСобытия.ЗарегистрироватьИзмененияПоПравиламРегистрации(УзлыДляРегистрации, СсылкаНаСправочник);

Если вы работаете с конкретными планами обмена в распределенных информационных базах (РИБ), обратите внимание на метод ЗарегистрироватьДанныеДляВыгрузки. Он позволяет регистрировать данные более гибко:


// Пример регистрации данных через серверный модуль БСП
ОбменДаннымиСервер.ЗарегистрироватьДанныеДляВыгрузки(УзелОбмена, СсылкаНаОбъект);

Как проверить работоспособность правил регистрации

Если программная регистрация все равно не дает результата, выполним следующие шаги по шагам:

Проверка состава плана обмена: Убедитесь, что нужный тип справочника или документа включен в состав плана обмена в метаданных (конфигураторе). Если его там нет, ПланыОбмена.ЗарегистрироватьИзменения выдаст ошибку.
Режим авторегистрации: Посмотрите, стоит ли в метаданных «Разрешить» или «Запретить» для авторегистрации. Хотя БСП управляет этим процессом через свои таблицы, платформенные ограничения имеют приоритет.
Отладка обработчиков ПРО: В КД 2.1 выгрузите правила регистрации в файл и посмотрите код в обработчиках ПередОбработкой, ПриОбработке и ПослеОбработки. Часто там стоят проверки на Параметры.РежимЗаписи, которые отсекают программную регистрацию, если она инициирована не интерактивно пользователем.

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