Как реализовать версионирование и хранение промежуточных состояний документа в 1С

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

Вариант 1. Цепочка документов (ввод на основании)

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

Рассмотрим особенности реализации этого подхода:

1. Статусная модель и блокировка: при создании следующей версии предыдущий документ переводится в статус закрытого или заблокированного от редактирования (по аналогии с исправлениями в ЗУП).
2. Связь через структуру подчиненности: пользователи получают наглядное дерево версий через стандартный механизм связанных документов без дополнительной разработки.
3. Отчет по изменениям: для сравнения двух версий пишется отчет, который сопоставляет реквизиты и строки табличных частей двух выбранных документов из цепочки.

Преимущества: каждый этап является полноценной учетной единицей; можно гибко разграничивать права доступа (например, запретить редактировать согласованные этапы); удобный просмотр промежуточных печатных форм.

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

Вариант 2. Типовое версионирование из БСП

Подсистема ВерсионированиеОбъектов из Библиотеки стандартных подсистем (БСП) фиксирует изменения объекта целиком в регистре сведений ВерсииОбъектов при каждой записи.

Проанализируем технические нюансы работы подсистемы:

1. Принцип хранения: БСП сериализует весь объект в XML (FastInfoset) и помещает сжатый снимок в реквизит с типом ХранилищеЗначения.
2. Сравнение версий: БСП предоставляет готовую форму сравнения, в которой подсвечиваются измененные, добавленные и удаленные реквизиты и строки.
3. Совместимость с обычными формами: актуальные версии БСП рассчитаны на управляемый интерфейс. Для конфигураций на базе обычных форм (например, УТ 10.3) потребуется адаптировать формы либо переносить устаревшие ветки БСП (1.x–2.x).

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

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

Вариант 3. Хранение дельты изменений в регистре сведений

Если требуется легкий аудит конкретных ключевых полей без раздувания базы данных, создадим собственный непериодический регистр сведений (например, ИсторияИзмененияРеквизитов).

Разберем логику фиксации изменений по шагам:

1. В подписке на событие ПередЗаписью документа считываем его исходное состояние из базы с помощью метода Ссылка.ПолучитьОбъект().
2. Построчно и поколоночно сравниваем текущие значения с новыми.
3. Записываем в регистр только те реквизиты, которые действительно изменились, фиксируя дату, автора, старое и новое значения.

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

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

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

Вариант 4. Платформенный механизм «История данных»

Начиная с версии платформы 8.3.11, в 1С доступен встроенный механизм версионирования, работающий на уровне ядра СУБД.

Рассмотрим его особенности:

1. Включается установкой свойства объекта метаданных ИсторияДанных в значение Использовать.
2. Платформа автоматически сохраняет дельту изменений в системных таблицах при фиксации транзакции записи.
3. Для просмотра истории доступна стандартная форма платформы, а для программного доступа используется менеджер ИсторияДанных.

Ограничение: для работы механизма требуется отключенный режим совместимости конфигурации (или режим совместимости не ниже 8.3.11).

Как выбрать оптимальное решение

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

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