Как включить версионирование объектов при обмене данными в 1С через КД 3.0?

← На главную

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

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

Почему версионирование не работает при синхронизации по умолчанию

Проанализируем архитектуру подсистем Библиотеки стандартных подсистем (БСП). В типовых решениях подсистема версионирования опирается на подписки на события записи объектов (например, ЗаписьОбъектаДляВерсионирования или ВерсионированиеОбъектовПередЗаписьюДокумента).

В начале процедур-обработчиков этих подписок всегда выполняется стандартная проверка:


Если Источник.ОбменДанными.Загрузка Тогда
    Возврат;
КонецЕсли;

При обмене данными через КД 3.0 (формат EnterpriseData) объект всегда записывается в режиме обмена, когда свойство ОбменДанными.Загрузка установлено в значение Истина. Это штатное платформенное поведение, заложенное разработчиками «1С» для исключения лишней нагрузки на базу данных и предотвращения дублирования истории при регулярной массовой синхронизации.

Почему нельзя устанавливать ОбменДанными.Загрузка = Ложь

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

Объект.ОбменДанными.Загрузка = Ложь;

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

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

Поэтому сохранять флаг ОбменДанными.Загрузка = Истина критически важно для целостности механизма синхронизации.

Способ 1. Вызов процедур версионирования в правилах конвертации КД 3.0

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

Разберем по шагам, как реализовать запись версии:

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

Посмотрим на пример программного кода в обработчике события:


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

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

Способ 2. Переопределение логики через расширение конфигурации

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

Разберем реализацию с помощью механизма расширений:

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

Посмотрим на пример кода в модуле расширения:


&Вместо("ЗаписатьВерсиюОбъекта")
Процедура Расш1_ЗаписатьВерсиюОбъекта(Источник, Отказ)
    // Проверяем, является ли объект тем документом, историю которого нужно отслеживать
    Если ТипЗнч(Источник) = Тип("ДокументОбъект.ЗаказКлиента") Тогда
        // Выполняем запись версии даже в том случае, если ОбменДанными.Загрузка = Истина
        ВерсионированиеОбъектов.ЗаписатьВерсию(Источник);
    Иначе
        // Для остальных объектов сохраняем типовое поведение
        ПродолжитьВызов(Источник, Отказ);
    КонецЕсли;
КонецПроцедуры

Важные нюансы: автор версий и оптимизация базы

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

Автор версии в регистре: при синхронизации фоновое задание выполняется под учетной записью служебного пользователя обмена (или системного процесса). Если требуется видеть реального автора документа, передадим реквизит Ответственный или Автор в составе пакета обмена EnterpriseData и явно укажем его в реквизите АвторВерсии при вызове подсистемы версионирования.
Рост объема базы данных: регистр сведений ВерсииОбъектов хранит упакованные XML-копии данных. При частой синхронизации таблица регистра может быстро разрастись. Обязательно перейдем в раздел администрирования истории изменений и настроим регламентное задание очистки устаревших версий (например, хранить не более последних 10 версий или очищать версии старше одного месяца).