Логирование действий пользователей в 1С через регистр сведений

Аудит операций в 1С помогает понять, кто, когда и какие изменения внес в информационную базу. Такая информация нужна при расследовании ошибок, контроле доступа, проверке работы сотрудников и подтверждении корректности бизнес-процессов.

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

Архитектура журнала действий

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

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

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

Проектирование регистра сведений

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

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

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

Где перехватывать события

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

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

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

Запись через общий модуль

Создайте серверный общий модуль, например АудитПользователейСервер, и экспортную процедуру ЗаписатьСобытие. Она принимает вид операции, объект, описание и дополнительные параметры. Внутри процедуры определяется текущий пользователь, формируется набор записей и выполняется запись.

Пример упрощенной реализации:

Процедура ЗаписатьСобытие(ВидОперации, ОбъектСобытия, Описание = "") Экспорт

    НаборЗаписей = РегистрыСведений.ЖурналДействийПользователей.СоздатьНаборЗаписей();
    Запись = НаборЗаписей.Добавить();

    Запись.Период = ТекущаяДатаСеанса();
    Запись.Пользователь = ПользователиИнформационнойБазы.ТекущийПользователь();
    Запись.ВидОперации = ВидОперации;
    Запись.Описание = Описание;

    Если ЗначениеЗаполнено(ОбъектСобытия) Тогда
        Запись.ОбъектСсылка = ОбъектСобытия;
        Запись.ОбъектМетаданных = ОбъектСобытия.Метаданные().ПолноеИмя();
        Запись.ПредставлениеОбъекта = Строка(ОбъектСобытия);
    КонецЕсли;

    НаборЗаписей.Записать();

КонецПроцедуры

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

Разбор изменений реквизитов

Факт записи объекта показывает, что данные изменились, но не объясняет, какие именно реквизиты были затронуты. Для детального аудита можно сравнить текущий объект с его копией до записи. Такой подход особенно полезен для договоров, цен, статусов документов и настроек доступа.

Список изменений можно сохранить одной строкой в формате «Реквизит: было → стало» или отдельными строками регистра. Первый вариант экономит место и упрощает запись, второй удобнее для аналитики и отчетов. При работе с табличными частями следует отдельно учитывать добавление, изменение и удаление строк.

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

Надёжность, производительность и безопасность

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

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

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

Практические рекомендации по внедрению

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

• Зафиксируйте перечень аудируемых объектов и операций.
• Определите единый формат даты, пользователя и описания события.
• Вынесите запись в серверный общий модуль.
• Используйте подписки на события там, где это возможно.
• Добавьте индексы для периода, пользователя и вида операции.
• Ограничьте доступ к журналу ролями администратора и аудита.
• Настройте архивирование или очистку устаревших записей.

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

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

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