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