Как отследить события в 1С: рабочие способы контроля действий пользователей

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

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

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

Журнал регистрации: главный источник событий

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

Открыть журнал можно двумя путями. В режиме предприятия: раздел «Администрирование» → «Обслуживание» → «Журнал регистрации» (в некоторых конфигурациях путь отличается, но раздел называется так же). В конфигураторе: меню «Администрирование» → «Журнал регистрации».

Чтобы найти нужное событие в большом объёме записей, обязательно используйте отбор через кнопку «Отбор». Доступны фильтры по периоду, пользователю, уровню важности (информация, предупреждение, ошибка), виду события, объекту метаданных и конкретным данным. Например, чтобы узнать, кто изменил конкретный документ, установите отбор по событию «Данные. Изменение» и укажите ссылку на документ в поле «Данные».

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

1. 1
   Откройте Администрирование → Обслуживание → Журнал регистрации
2. 2
   Нажмите «Отбор» и задайте период, в который могло произойти изменение
3. 3
   В поле «Событие» выберите «Данные. Изменение» (и при необходимости «Данные. Удаление»)
4. 4
   В поле «Данные» укажите ссылку на нужный документ или элемент справочника
5. 5
   Нажмите «ОК» — в списке останутся все изменения объекта с указанием пользователя и времени
6. 6
   Откройте запись двойным щелчком и проверьте сеанс и комментарий

Что фиксирует журнал регистрации, а что нет

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

Если нужно знать не только «кто и когда», но и «что именно поменял» — требуется версионирование объектов, о котором ниже. Если нужно фиксировать просмотры данных — штатных средств недостаточно, такую задачу решают программно или специализированными средствами защиты.

Объём фиксируемых событий можно настроить: в конфигураторе откройте «Администрирование» → «Настройка журнала регистрации». Там выбирается режим — от регистрации только ошибок до регистрации всех событий. Полный режим полезен при расследовании инцидентов, но ускоряет рост журнала.

История изменений объектов: версионирование

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

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

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

Подписки на события для автоматического контроля

Если требуется не просто наблюдать события, а реагировать на них автоматически — писать в отдельный лог, отправлять уведомление, блокировать действие — используются подписки на события. Это инструмент конфигуратора: объект метаданных «Подписка на событие» привязывает обработчик к событиям вроде «ПриЗаписи», «ПередЗаписью», «ПередУдалением» для выбранных видов объектов.

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

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

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

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

Контроль фоновых заданий и обменов данными

Значительная часть «событий» в 1С происходит без участия пользователя — это регламентные и фоновые задания: обмены, расчёты итогов, рассылки отчётов. Их отслеживают в разделе «Администрирование» → «Обслуживание» → «Регламентные и фоновые задания».

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

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

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

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

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

Производительность и хранение журналов

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

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

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