Как настроить историю изменения документа в 1С

История изменения документа в 1С позволяет увидеть, кто, когда и что именно поменял в документе: какие реквизиты были отредактированы, какие строки табличной части добавлены или удалены, кто отменил проведение. Это один из главных инструментов разбора спорных ситуаций — например, когда сумма в счёте «вдруг» изменилась после согласования или документ оказался непроведённым перед закрытием периода.

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

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

Что такое версионирование объектов и когда оно нужно

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

Механизм фиксирует не только редактирование, но и проведение, отмену проведения и пометку удаления — каждое такое действие создаёт новую версию. Это позволяет восстановить цепочку событий: кто создал документ, кто его провёл, кто и когда поменял сумму и кто в итоге распровёл документ.

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

Как включить историю изменений в типовой конфигурации

Для настройки нужны права администратора. В типовых конфигурациях на БСП путь примерно одинаковый: раздел «Администрирование» → «Общие настройки» (в некоторых конфигурациях — «Настройки программы» → «Поддержка и обслуживание»). Найдите группу «История изменений» или пункт «Настроить историю изменений».

Установите флаг «Хранить историю изменений» (в ряде версий — «Версионирование объектов»). После этого откроется список видов документов и справочников, для которых можно включить запись версий. Для каждого вида объекта выберите режим: «Версионировать» или «Не версионировать», а также срок хранения версий.

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

1. 1
   Откройте «Администрирование → Общие настройки» и найдите блок «История изменений».
2. 2
   Установите флаг «Хранить историю изменений».
3. 3
   Отметьте виды документов, для которых нужно версионирование.
4. 4
   Для каждого вида выберите срок хранения версий.
5. 5
   Сохраните настройки и проверьте, что регламентное задание очистки версий активно.
6. 6
   Создайте тестовый документ, измените его и откройте «История изменений» для проверки.

Как посмотреть и сравнить версии документа

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

Чтобы увидеть, что именно поменялось, выделите две версии и нажмите «Сравнить версии» (или «Сравнить с предыдущей версией»). 1С построит табличный отчёт, где разными цветами подсвечены изменённые реквизиты, добавленные и удалённые строки табличных частей. Так видно, например, что в строке 3 табличной части «Товары» количество изменено с 10 на 15.

Если документ испорчен, версию можно восстановить: выделите нужную версию и выполните команду «Перейти на версию» (или «Откатить к версии»). Текущее состояние документа при этом тоже сохранится как новая версия, то есть откат обратим — данные не теряются.

Настройка в нестандартной конфигурации через конфигуратор

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

Минимальный набор объектов: регистр сведений «ИсторияИзмененийДокументов» с измерением «Документ» (документ-ссылка), ресурсами «ДатаИзменения», «Пользователь», «ДанныеВерсии» (хранилище значения) и подписка на событие, которая при записи сериализует объект. Сериализацию удобно делать через ЗначениеВСтрокуВнутр или через запись XML.

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

Обратите внимание: подписку нужно назначить на событие «ПриЗаписи» именно с обработчиком в общем модуле с флагом «Сервер», иначе в клиент-серверном режиме код не выполнится. Для просмотра версий сделайте простую форму списка регистра с отбором по документу и кнопку вызова из формы документа.

Ограничения и влияние на производительность

Главная цена версионирования — рост объёма базы. Каждая запись документа создаёт полную копию его данных в регистре версий. Если в базе ежедневно проводятся тысячи документов с крупными табличными частями, регистр версий может стать одной из самых больших таблиц базы. Поэтому сроки хранения нужно выбирать осознанно и периодически контролировать размер регистра.

Второе ограничение — версии фиксируют только изменения через штатную запись объекта. Обмен данными, загрузка через обработки и фоновые задания тоже создают версии, но автором будет тот пользователь, под которым выполняется операция (часто — служебный пользователь обмена). Это нормально, но при разборе инцидентов вводит в заблуждение.

Третий момент: версионирование не заменяет журнал регистрации. Журнал фиксирует все события (входы, открытие данных, ошибки), но не хранит содержимое. Версии хранят содержимое, но только для выбранных видов объектов. Для полноценного аудита используют оба механизма вместе.

Типичные ошибки при настройке истории изменений

Самая частая жалоба — «включили, а история не пишется». Причины обычно три. Первая: для конкретного вида документов не выбран режим версионирования — общий флаг включён, но список объектов пуст. Вторая: пользователь ищет историю в документах, созданных до включения механизма, — у них версий просто нет. Третья: в файловой базе не выполняются регламентные задания, из-за чего очистка не работает, а иногда и связанные подсистемы ведут себя некорректно.

Обратная ошибка — версии пишутся, но база раздувается. Это происходит, когда включено версионирование для всех документов с хранением «бессрочно», а регламентная очистка отключена. Решение — ограничить список версионируемых объектов, сократить сроки хранения и проверить расписание регламентного задания очистки.

Как проверить, что всё работает правильно

После настройки выполните контрольный тест. Создайте новый документ того вида, для которого включено версионирование, проведите его. Затем измените любой реквизит (например, комментарий или количество в строке), запишите, после чего отмените проведение. Откройте «История изменений»: должно быть минимум три версии — создание/проведение, изменение, отмена проведения — с вашим именем пользователя и корректным временем.

Далее сравните две соседние версии и убедитесь, что отчёт о различиях показывает именно то поле, которое вы меняли. Затем выполните откат к первой версии и проверьте, что документ вернулся в исходное состояние, а в истории появилась новая версия отката. Если все три проверки пройдены — механизм настроен корректно.

Частые вопросы