Как вывести отчет или историю изменений по конкретному документу на его форму в 1С

← На главную

В процессе разработки конфигураций на платформе «1С:Предприятие 8» часто возникает задача отслеживания изменений в документах. Пользователям важно знать, кто, когда и какие именно данные изменил. В этой статье мы подробно разберем, как реализовать механизм логирования изменений, используя как ручные методы создания регистров, так и стандартные возможности платформы. Мы проанализируем различные подходы — от простого регистра сведений до сложных систем версионирования.

Решение проблемы через создание собственного регистра сведений

Рассмотрим ситуацию, когда нам необходимо создать собственный «Журнал логов». Это может быть полезно, если стандартные механизмы по какой-то причине не подходят или требуется специфическая структура хранения данных. Для начала создадим Регистр сведений (например, ЖурналЛоговЗаявки) со следующей структурой:

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

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

Программная реализация записи логов

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


МенеджерЗаписи = РегистрыСведений.ЖурналЛоговЗаявки.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Период = ТекущаяДата(); 
МенеджерЗаписи.Пользователь = Пользователи.АвторизованныйПользователь(); 
МенеджерЗаписи.Документ = Ссылка; 
МенеджерЗаписи.СведенияДО = СтрокаДо; // Предварительно подготовленные данные
МенеджерЗаписи.СведенияПосле = СтрокаПосле; // Актуальные данные
МенеджерЗаписи.Записать();

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

Отображение данных на форме документа через динамический список

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

Откроем форму документа и перейдем на вкладку «Список».
Добавим новый реквизит формы с типом ДинамическийСписок.

В свойствах списка установим галочку «Произвольный запрос» и напишем текст запроса:


ВЫБРАТЬ
    Регистр.Период,
    Регистр.Пользователь,
    Регистр.СведенияДО,
    Регистр.СведенияПосле
ИЗ
    РегистрСведений.ЖурналЛоговЗаявки КАК Регистр
ГДЕ
    Регистр.Документ = &ДокументСсылка

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

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

Использование стандартного механизма «История данных»

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

Разберем по шагам включение этого механизма:

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

Платформа сама создаст необходимые таблицы в базе данных и обеспечит интерфейс для сравнения версий. Пользователь сможет нажать на стандартную кнопку «История» и увидеть детальный отчет о том, какие поля были изменены, с подсветкой различий. Это избавляет разработчика от необходимости вручную формировать строки «До» и «После».

Версионирование объектов в БСП

В типовых решениях (УТ 11, ERP, КА, БП 3.0), построенных на базе Библиотеки стандартных подсистем (БСП), уже существует мощная подсистема «Версионирование объектов». Рассмотрим преимущества этого подхода:

Подсистема хранит версии объектов в виде сжатых XML-снимков. Это позволяет не только смотреть историю, но и при необходимости откатывать состояние документа к одной из предыдущих версий. Чтобы включить этот функционал, достаточно зайти в пользовательский режим (Администрирование — Общие настройки — История изменений) и выбрать нужные типы документов для логирования.

Для вывода этой информации на форму в БСП предусмотрена общая команда ИсторияИзменений. Мы можем просто добавить её в командную панель нашей формы, и система сама откроет стандартный отчет со списком всех версий документа.

Оптимизация и безопасность

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

Используйте ХранилищеЗначения со сжатием для больших объемов данных.
Записывайте только те реквизиты, которые действительно изменились (сравнение в цикле ЭтотОбъект[ИмяРеквизита] и Ссылка[ИмяРеквизита]).
Ограничьте права доступа к регистру логов: запись должна производиться в привилегированном режиме, а чтение должно быть доступно только ответственным лицам или администраторам.

Подводя итог, выбор метода зависит от ваших задач. Если нужна простая визуализация в специфическом виде — используйте свой регистр сведений с ведущим измерением. Если требуется полнофункциональное сравнение версий — используйте Историю данных платформы или Версионирование БСП. Сочетание этих методов позволит создать надежную систему аудита действий пользователей в программе.