Как настроить и исправить работу механизма истории изменений (версионирования) в 1С:ERP?

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

Механизм версионирования объектов является одной из ключевых функций в современных конфигурациях 1С, таких как 1С:ERP Управление предприятием, Комплексная автоматизация или Управление торговлей. Он позволяет отслеживать, кто, когда и какие изменения вносил в документ или справочник. Однако при разработке новых документов или доработке существующих программисты часто сталкиваются с тем, что кнопка «История изменений» либо отсутствует, либо не фиксирует новые версии. Разберем подробно, как устроен этот механизм и что нужно проверить, чтобы он заработал корректно.

Понимание архитектуры версионирования: Платформа vs БСП

Прежде чем приступать к исправлению ошибок, проанализируем, какой именно механизм используется. В экосистеме 1С существует два подхода к хранению истории:

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

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

Шаг 1. Настройка в пользовательском интерфейсе

Часто проблема заключается не в коде, а в том, что для конкретного типа документа версионирование просто не включено в настройках программы. Рассмотрим, как это проверить:

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

Далее перейдем по ссылке Настройки хранения. В списке объектов найдем наш документ. Посмотрим на колонку «Вариант хранения». Возможны несколько вариантов:

Если наш документ отсутствует в этом списке или для него установлено «Не использовать», изменим настройку на нужную и проверим результат.

Шаг 2. Проверка метаданных и определяемых типов

Если настройки в интерфейсе заданы верно, но история всё равно не пишется для нового (нетипового) документа, проблема кроется в конфигураторе. Проанализируем состав определяемых типов. Чтобы подсистема БСП «узнала» о существовании вашего документа, он должен быть включен в специальные списки на уровне метаданных.

Откроем дерево конфигурации и найдем раздел Определяемые типы. Нам важны следующие типы:

  1. ВерсионируемыйОбъект: Включим наш документ в состав этого типа. Это позволит системе передавать ссылку на документ в процедуры версионирования.
  2. ВерсионируемыйОбъектОбъект: Здесь должен быть тип ДокументОбъект.ИмяВашегоДокумента. Это необходимо для непосредственной работы с данными объекта при записи.

Также проверим включение объекта в состав функциональной опции ИспользоватьВерсионированиеОбъекта. Если документ не входит в эту опцию, настройки в пользовательском режиме могут игнорироваться.

Шаг 3. Подписки на события — сердце механизма

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

Найдем в дереве конфигурации раздел Общие -> Подписки на события. Нас интересует подписка, которая отвечает за обработку события ПриЗаписи. Убедимся, что наш новый документ включен в список Источник этой подписки. Если его там нет, обработчик просто не вызовется, и данные в регистр ВерсииОбъектов не попадут.

Шаг 4. Программный код в форме документа

Хотя в современных версиях ERP кнопка «История изменений» часто добавляется в командную панель автоматически (через механизм подключаемых команд), для стабильной работы и корректной инициализации рекомендуется добавить вызов метода БСП в модуле формы документа.

Рассмотрим пример кода, который должен присутствовать в процедуре ПриСозданииНаСервере:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Инициализация механизма версионирования объектов
    Если ОбщегоНазначения.ПодсистемаСуществует("СтандартныеПодсистемы.ВерсионированиеОбъектов") Тогда
        МодульВерсионированиеОбъектов = ОбщегоНазначения.ОбщийМодуль("ВерсионированиеОбъектов");
        МодульВерсионированиеОбъектов.ПриСозданииНаСервере(ЭтаФорма);
    КонецЕсли;
    
КонецПроцедуры

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

Шаг 5. Анализ хранения данных в регистре

Если визуально всё настроено, но история кажется пустой, проверим, создаются ли записи «под капотом». Все версии хранятся в регистре сведений ВерсииОбъектов. Выполним следующие действия:

  1. Откроем Функции для технического специалиста (или «Все функции»).
  2. Найдем регистр сведений ВерсииОбъектов.
  3. Установим отбор по полю Объект, выбрав наш проблемный документ.

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

Шаг 6. Контроль очистки версий

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

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

← На главную