Как в Конвертации данных 2.1 передать ДополнительныеСвойства в набор движений документа?

Программист 1С v8.3 (Обычные формы) IT и автоматизация бизнеса
← На главную

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


Если ЗарплатаКадры.ОтключитьБизнесЛогикуПриЗаписи(ЭтотОбъект) Тогда
    Возврат;
КонецЕсли;

Внутри этой функции платформа проверяет режим загрузки данных и наличие определенного флага в дополнительных свойствах объекта. Если нам требуется обойти эту проверку (или, наоборот, принудительно заставить систему выполнить бизнес-логику при загрузке), нам необходимо передать в коллекцию ДополнительныеСвойства набора записей регистра накопления или регистра сведений определенный флаг — например, "ПроверятьБизнесЛогикуПриЗаписи" = Истина.

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

Решение 1. Инициализация свойств в обработчике «После загрузки» ПКО документа

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

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

Давайте разберем по шагам, как написать этот код в ПКО документа:

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

// Обращаемся к конкретному набору движений документа
НаборЗаписей = Объект.Движения.ИмяВашегоРегистраНакопления; 
НаборЗаписей.ДополнительныеСвойства.Вставить("ПроверятьБизнесЛогикуПриЗаписи", Истина);

Если у вашего документа переносится сразу несколько регистров, и для каждого из них требуется применить данную настройку, мы можем обойти всю коллекцию движений в цикле. Проанализируем этот универсальный код:


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

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

Решение 2. Использование глобального обработчика конвертации

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

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

Выясним, как правильно написать такое условие, чтобы не вызвать ошибок при загрузке справочников или других объектов, у которых нет движений:


// Проверяем, является ли загруженный объект документом
Если Лев(ИмяТипаОбъекта, 8) = "Документ" Тогда
    // Защита на случай, если у объекта по какой-то причине нет коллекции Движения
    Попытка
        Для Каждого НаборЗаписей Из Объект.Движения Цикл
            НаборЗаписей.ДополнительныеСвойства.Вставить("ПроверятьБизнесЛогикуПриЗаписи", Истина);
        КонецЦикла;
    Исключение
        // Записываем предупреждение в журнал регистрации при необходимости
    КонецПопытки;
КонецЕсли;

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

Решение 3. Реализация логики на стороне базы-приемника (Подписка на события)

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

Чтобы не засорять XML-правила сложным кодом, мы можем решить задачу непосредственно в базе-приемнике с помощью механизмов платформы 1С — Подписки на события или Расширения конфигурации.

Выполним следующие действия в конфигураторе базы-приемника:

  1. Создадим новую Подписку на событие.
  2. В качестве источника выберем наборы записей необходимых регистров (например, РегистрНакопленияНаборЗаписей.ИмяРегистра).
  3. Событие выберем как ПередЗаписью.
  4. В модуле подписки напишем обработчик, который будет проверять, происходит ли запись в режиме обмена данными:

Процедура ПередЗаписьюРегистраПередЗаписью(Источник, Отказ, Замещение) Экспорт
    // Если запись набора происходит в режиме загрузки данных (при обмене)
    Если Источник.ОбменДанными.Загрузка Тогда
        Источник.ДополнительныеСвойства.Вставить("ПроверятьБизнесЛогикуПриЗаписи", Истина);
    КонецЕсли;
КонецПроцедуры

Этот подход гарантирует стабильность обмена, так как правила КД 2.1 остаются "чистыми", а при обновлении метаданных или конфигурации логика обхода проверок не потеряется и легко поддастся отладке стандартными средствами конфигуратора 1С.

Решение 4. Передача динамического флага через ПараметрыОбъекта

Что делать, если решение о проверке бизнес-логики должно приниматься динамически на стороне базы-источника на основании каких-либо условий (например, даты документа или его заполненности)? Для этого мы можем передать параметр через правила обмена.

Посмотрим на пример реализации этой схемы:

  1. В ПКО документа на вкладке «Параметры» добавим новый параметр с именем ПроверятьБизнесЛогику.
  2. В ПКО документа в обработчике «Перед выгрузкой» установим значение этого параметра на основе нашей логики в источнике:

// Пример условия на стороне источника
Если Источник.Дата < '20230101000000' Тогда
    Параметры.ПроверятьБизнесЛогику = Ложь;
Иначе
    Параметры.ПроверятьБизнесЛогику = Истина;
КонецЕсли;
  1. В ПКО документа в обработчике «После загрузки» на стороне приемника прочитаем этот параметр и транслируем его значение в коллекцию дополнительных свойств движений:

Если ПараметрыОбъекта <> Неопределено Тогда
    ПроверятьЛогику = Ложь;
    Если ПараметрыОбъекта.Свойство("ПроверятьБизнесЛогику", ПроверитьЛогику) И ПроверитьЛогику Тогда
        Для Каждого НаборЗаписей Из Объект.Движения Цикл
            НаборЗаписей.ДополнительныеСвойства.Вставить("ПроверятьБизнесЛогикуПриЗаписи", Истина);
        КонецЦикла;
    КонецЕсли;
КонецЕсли;

Таким образом, мы получаем гибкий инструмент управления проведением документов непосредственно из базы-источника.

Мы подробно разобрали различные способы передачи ДополнительныеСвойства в наборы движений документов при конвертации данных. Выбор конкретного метода зависит от архитектуры вашей системы и необходимости динамического управления логикой загрузки.

← На главную