Как отменить проведение документа в базе-приемнике при изменении типа объекта в источнике?

← На главную

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

Типичный пример: в «1С:Управление торговлей» оформлен документ, который при установленном флаге должен загружаться в «1С:Бухгалтерию предприятия» как Передача товаров (передача в переработку), а при снятом флаге — как Реализация товаров и услуг. Если пользователь сначала провел документ с признаком передачи, объект успешно выгрузился в приемник и сформировал проводки. Однако, если затем в источнике флаг сняли и повторно запустили синхронизацию, в приемник загрузится реализация, а ранее созданный документ передачи останется проведенным, что приведет к задвоению движений и остатков.

Проанализируем причины такого поведения платформы и подробно разберем практические способы решения этой проблемы.

Почему возникает рассинхронизация данных?

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

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

Способ 1. Программный поиск и отмена проведения в обработчике «После загрузки» (ПКО)

Рассмотрим наиболее популярный и надежный подход: при загрузке документа в базу-приемник программно проверять наличие альтернативного документа по тому же идентификатору и отменять его проведение (или помечать на удаление).

Разберем реализацию этого алгоритма по шагам в обработчике «После загрузки» целевого правила конвертации объекта (ПКО):

Получаем уникальный идентификатор загружаемого объекта с помощью метода Объект.Ссылка.УникальныйИдентификатор().
Формируем ссылку на альтернативный документ того же идентификатора через менеджер соответствующего документа или выполняем поиск по реквизитам (организация, номер, дата).
Проверяем, существует ли альтернативный документ в базе и проведен ли он.
Если документ проведен, отменяем проведение и при необходимости устанавливаем пометку удаления.

Посмотрим на пример кода на встроенном языке 1С:


УИД = Объект.Ссылка.УникальныйИдентификатор();

// Формируем ссылку на альтернативный документ по тому же УИД
СсылкаДубль = Документы.ПередачаТоваров.ПолучитьСсылку(УИД);

// Проверяем физическое существование объекта в информационной базе
ОбъектДубль = СсылкаДубль.ПолучитьОбъект();

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

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

Способ 2. Выгрузка двух объектов из источника («ВыгрузитьПоПравилу»)

Второй вариант заключается в том, чтобы решать задачу непосредственно на стороне базы-источника в обработчике «Перед выгрузкой» или «После выгрузки» основного правила:

Анализируем условия выгрузки документа.
По основному условию передаем объект в штатное ПКО.
Для альтернативного документа явно вызываем метод ВыгрузитьПоПравилу(...), передавая специальную структуру или объект с признаками Проведен = Ложь и ПометкаУдаления = Истина.

Разберем пример вызова выгрузки пустого объекта-заглушки для нейтрализации альтернативного типа документа:


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

Важные ограничения и риски при отмене проведения

При реализации автоматической отмены проведения документов в процессе загрузки обмена необходимо учитывать следующие платформенные ограничения:

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

Альтернативные архитектурные решения

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

Запрет изменения ключевых реквизитов после выгрузки: Включение типового механизма БСП «Разрешение редактирования реквизитов объектов». После того как документ был единожды отправлен в приемник, ключевой признак блокируется для редактирования. Если тип операции изменился, пользователю необходимо пометить старый документ на удаление и создать новый.
Разделение документов в источнике: Отказ от использования одного документа с переключателем в пользу двух специализированных видов документов еще на уровне базы-источника.