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

В типовых механизмах обмена данными 1С, построенных на базе Библиотеки стандартных подсистем (БСП) и «Конвертации данных 2.1», регистрация документов для обмена обычно привязана к стандартному реквизиту Дата. Однако на практике часто возникают задачи, когда документ должен попадать в обмен не по основной дате, а по иному критерию. Например, когда документ ПриходныйКассовыйОрдер должен регистрироваться только в том случае, если его ДатаПробитияЧека входит в интервал синхронизации, независимо от даты самого документа.

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

Понимание механизмов регистрации объектов

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

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

Проанализируем ситуацию: если мы хотим регистрировать документ по спец-дате, нам нужно либо скорректировать ПР, либо вмешаться в процесс выгрузки. Рассмотрим наиболее правильный и производительный метод — настройку правил регистрации в «Конвертации данных 2.1».

Способ 1. Изменение правил регистрации (ПР) в КД 2.1

Этот способ является наиболее корректным, так как он отсекает лишние данные еще на этапе записи объекта в базу, не перегружая таблицу регистрации. Выполним следующие шаги.

Шаг 1. Подготовка конфигураций и выгрузка правил

Рассмотрим процесс выгрузки необходимых данных для работы в КД 2.1. Нам понадобятся описания структур метаданных обеих баз и текущий пакет правил синхронизации.

1. Используем обработку MD8xExp.epf (идет в комплекте с КД 2.1) в обеих базах, чтобы получить файлы описания конфигураций.
2. В базе-источнике перейдем в настройки синхронизации и выгрузим комплект правил. Обычно это ZIP-архив, внутри которого находятся файлы: RegistrationRules.xml (правила регистрации) и ExchangeRules.xml (правила обмена).

Шаг 2. Загрузка данных в «Конвертацию данных 2.1»

Запустим информационную базу КД 2.1 и загрузим туда наши структуры метаданных и правила регистрации. Перейдем в раздел «Правила регистрации объектов» и найдем нужное правило для нашего документа.

Шаг 3. Настройка обработчика «Перед обработкой»

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

Проанализируем пример кода, который нужно вставить в этот обработчик:

// 1. Получаем дату начала выгрузки из настроек узла плана обмена
// В БСП этот параметр обычно называется ДатаНачалаВыгрузкиДокументов
ДатаНачала = УзелОбмена.ДатаНачалаВыгрузкиДокументов;

// 2. Проверяем наличие нашего специфичного реквизита
Если ЗначениеЗаполнено(Объект.ДатаПробитияЧека) Тогда
    // Если дата пробития чека меньше даты начала — отменяем регистрацию
    Если Объект.ДатаПробитияЧека < ДатаНачала Тогда
        Отказ = Истина;
    КонецЕсли;
Иначе
    // Решаем, что делать, если реквизит не заполнен. 
    // Например, если чека нет, мы можем вообще не передавать документ.
    Отказ = Истина; 
КонецЕсли;

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

Способ 2. Использование обработчика «При обработке»

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

Посмотрим на пример ситуации, когда дата регистрации хранится в дополнительных сведениях:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ДополнительныеСведения.Значение КАК ДатаРегистрации
    |ИЗ
    |	РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения
    |ГДЕ
    |	ДополнительныеСведения.Объект = &Объект
    |	И ДополнительныеСведения.Свойство = &Свойство";

Запрос.УстановитьПараметр("Объект", Объект.Ссылка);
Запрос.УстановитьПараметр("Свойство", ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("ДатаАктуальности"));

РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();

Если Выборка.Следующий() Тогда
    Если Выборка.ДатаРегистрации < УзелОбмена.ДатаНачалаВыгрузкиДокументов Тогда
        Отказ = Истина;
    КонецЕсли;
Иначе
    // Если сведения не найдены, отказываемся от регистрации
    Отказ = Истина;
КонецЕсли;

Способ 3. Фильтрация в правилах обмена (ПКО)

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

В правилах обмена (ExchangeRules.xml) найдите Правило Конвертации Объекта (ПКО) для вашего документа. Перейдите в обработчик «Перед выгрузкой» и напишите:

ДатаНачала = Параметры.ДатаНачалаВыгрузки; // Имя параметра зависит от настроек правил

Если Объект.ДатаПробитияЧека < ДатаНачала Тогда
    Отказ = Истина;
КонецЕсли;

В этом случае, когда база попытается отправить данные, обработчик установит Отказ = Истина. Объект не попадет в файл обмена, но при этом пометится в плане обмена как успешно переданный (регистрация снимется). Это предотвратит повторные бесполезные попытки выгрузки этого документа до его следующего изменения.

Завершение настройки и загрузка правил

После того как мы внесли изменения в КД 2.1, выполним обратный процесс:

1. В КД 2.1 нажмем кнопку «Сохранить правила». Сформируем новый ZIP-архив с комплектом правил. Обратите внимание, что при сохранении нужно правильно указать правила для корреспондента и правила регистрации, чтобы сформировался полный пакет для БСП.
2. Вернемся в нашу информационную базу 1С. Откроем настройки синхронизации данных.
3. Воспользуемся командой «Загрузить комплект правил» и выберем наш новый архив.
4. Обязательно: После загрузки правил рекомендуется перерегистрировать объекты, которые ранее не попадали в обмен, или выполнить полную синхронизацию для проверки работы фильтров.

Рекомендации по отладке

Проанализируем, как можно проверить работу наших правил, не запуская реальный обмен. Для этого можно использовать обработку «Регистрация изменений для обмена» (входит в состав БСП или консоль запросов).

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

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

Таким образом, мы рассмотрели комплексный подход к изменению логики регистрации. Использование обработчика «Перед обработкой» в правилах регистрации является «золотым стандартом» для подобных задач, обеспечивая чистоту таблицы регистрации и высокую скорость работы обмена.