Кто, когда и что сделал в базе 1С: инструменты контроля работы сотрудников

Отследить действия пользователей в 1С проще всего по журналу регистрации: в БП 3.0, ЗУП 3.1 и УТ 11 он открывается из раздела Администрирование → Обслуживание, в Конфигураторе — через Администрирование → Журнал регистрации. Журнал показывает, кто вошёл в базу, с какого компьютера, какие документы создал, изменил, провёл или удалил. Чтобы увидеть, какие именно поля поменялись, включают историю изменений объектов. Для разбора медленных операций и запросов к СУБД подключают технологический журнал.

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

Настройка журнала регистрации перед аудитом

Журнал пишет столько, сколько ему разрешили. Если уровень занижен, искать «кто удалил накладную» будет не по чему. Проверьте настройку заранее, а не в день инцидента.

1. Откройте базу в Конфигураторе под администратором.
2. Выберите Администрирование → Настройка журнала регистрации.
3. Установите уровень «Регистрировать все события» или хотя бы «ошибки, предупреждения и информацию». Изменения данных пишутся с уровнем «Информация», поэтому уровень «Регистрировать ошибки» их не сохранит.
4. Задайте разделение журнала по периодам, например по месяцам. Так старые части проще архивировать.
5. Нажмите «ОК». Настройка применяется сразу, перезапуск не нужен.

Где физически лежит журнал:

В платформе 8.3 журнал по умолчанию хранится в формате SQLite — файл 1Cv8.lgd. Старый текстовый формат (.lgf и .lgp) встречается в базах, перенесённых со старых версий.

Как посмотреть действия пользователей в журнале регистрации

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

Главная работа — отбор. Без него вы получите сотни тысяч строк.

1. Нажмите «Установить отбор».
2. Задайте интервал: день, когда заметили проблему, плюс один-два дня до него.
3. В поле «Пользователи» выберите сотрудника или оставьте пустым, если ищете неизвестного.
4. В «События» отметьте нужные группы. Для правок данных это Данные. Изменение, Данные. Удаление, Данные. Проведение, Данные. Отмена проведения.
5. В «Метаданные» укажите объект, например документ «Реализация (акты, накладные, УПД)».
6. Примените отбор и отсортируйте по дате.

Что видно в каждой записи:

• 👤 Пользователь и Компьютер — кто и откуда работал;
• 🖥️ Приложение — тонкий клиент, веб-клиент, Конфигуратор, COM-соединение, фоновое задание;
• 📄 Метаданные и Данные — тип объекта и ссылка на конкретный документ;
• 🔁 Сеанс и Транзакция — номер сеанса и признак, была ли транзакция зафиксирована или отменена;
• 💬 Комментарий — текст ошибки или пояснение, если его записал программный код.

Типовые сценарии поиска:

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

Что именно поменяли: история изменений объектов

Журнал отвечает на вопрос «кто и когда». На вопрос «что было до правки» отвечает версионирование объектов из БСП.

Включение в БП 3.0, ЗУП 3.1, УТ 11:

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

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

История пишется только с момента включения. Прошлые правки она не восстановит, поэтому включайте её на рабочей базе до того, как возникнет спор «кто поменял цену».

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

Кто работает в базе прямо сейчас

Для контроля в реальном времени нужен список сеансов, а не журнал.

В пользовательском режиме. Администрирование → Обслуживание → «Активные пользователи». Показаны имя, компьютер, приложение, время начала сеанса. Отсюда же администратор может завершить сеанс.

В Конфигураторе. Администрирование → Активные пользователи. Из списка можно сразу открыть журнал регистрации с отбором по выбранному сеансу.

В консоли кластера (клиент-серверный вариант). Разверните Информационные базы → <база> → Сеансы. Здесь больше данных, чем в программе:

• ⏱️ последняя активность — когда пользователь в последний раз что-то делал;
• 🔒 захвачено СУБД и блокировки — кто прямо сейчас держит транзакцию;
• 📈 время вызовов и объём прочитанных данных — кто нагружает сервер.

Тот же список можно получить из командной строки через сервер администрирования ras и утилиту rac:

rac cluster list
rac session list --cluster=<UUID кластера>
rac session list --cluster=<UUID кластера> --licenses

Второй вариант покажет, какой сеанс какую лицензию занимает. Другие параметры смотрите в справке rac help session.

Технологический журнал для глубокого аудита

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

Включается файлом logcfg.xml. Положите его в каталог conf установленной платформы, например C:\Program Files\1cv8\conf\. Платформа подхватит файл примерно через минуту, перезапускать службу не нужно.

Пример: собирать запросы к СУБД длительностью больше 1 секунды и все исключения конкретного пользователя.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <gt property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="EXCP"/>
      <eq property="Usr" value="Петрова"/>
    </event>
    <property name="all"/>
  </log>
</config>

Как это читать:

• location — папка для логов, лучше на отдельном диске;
• history="24" — хранить 24 часа, старое удаляется само;
• условия внутри одного <event> работают как «И», разные <event> — как «ИЛИ»;
• duration на платформе 8.3 задаётся в микросекундах, поэтому 1000000 — это 1 секунда.

Полезные события для аудита:

Не включайте ТЖ «на всё» без фильтров на рабочем сервере. При 50 пользователях полный журнал с <property name="all"/> набирает десятки гигабайт за час и может забить диск, после чего сервер 1С остановится. Включайте на время расследования, с отбором по событиям и пользователю, а потом удаляйте logcfg.xml.

Логи — обычный текст, их разбирают grep, PowerShell или специализированными анализаторами.

Трассировка на уровне СУБД

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

Главная сложность: все пользователи 1С ходят в СУБД под одной учётной записью сервера 1С. В трассировке SQL вы увидите запрос, но не сотрудника. Связка делается через ТЖ: событие DBMSSQL содержит и имя пользователя (Usr), и текст запроса (Sql), а таблицы СУБД сопоставляют с объектами 1С по структуре хранения.

Чем пользоваться:

• 🗄️ MS SQL Server — Extended Events вместо устаревшего Profiler, для формального аудита — встроенный SQL Server Audit;
• 🐘 PostgreSQL — параметр log_min_duration_statement для медленных запросов, расширение pg_stat_statements для статистики, расширение pgAudit для журнала изменений.

Где SQL-трассировка действительно нужна:

1. Подозрение, что данные правили напрямую в базе, минуя 1С. Журнал регистрации такие правки не увидит вообще.
2. Расследование блокировок и деградации: какой запрос и сколько ждёт.
3. Требования внутреннего аудита к журналу доступа на уровне БД.

Структуру хранения, то есть соответствие таблиц вида _Document123 объектам конфигурации, получают методом ПолучитьСтруктуруХраненияБазыДанных() или внешними обработками.

Свои события и внешние системы контроля

Если типового журнала не хватает, есть три пути.

Записывать свои события. В доработке или расширении конфигурации вызывают:

ЗаписьЖурналаРегистрации("Аудит.ПечатьДоговора",
    УровеньЖурналаРегистрации.Информация,
    Метаданные.Документы.РеализацияТоваровУслуг,
    ДокументСсылка,
    "Распечатан договор, копий: " + Формат(КоличествоКопий, "ЧГ=0"));

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

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

Подключить внешние системы.

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

Организационные меры: без них аудит бесполезен

Технические журналы показывают имя учётной записи, а не человека. Если весь отдел сидит под «Бухгалтер» без пароля, журнал ответит только «кто-то из бухгалтерии».

Минимальный набор правил:

• 🔑 Персональные учётные записи. Одна учётка — один человек. Общих логинов нет, в том числе «Администратор».
• 🧩 Права по ролям. Пользователь видит и меняет только своё. Полные права — у одного-двух человек.
• 🔐 Пароли или вход через Windows. Аутентификация операционной системы закрывает проблему «подсмотрел пароль коллеги».
• 📅 Дата запрета изменения. Закрытые периоды защищены, и любая попытка правки видна как ошибка в журнале.
• 💾 Хранение журналов. Срок хранения зафиксирован, архив лежит отдельно от базы.
• 👁️ Регулярный просмотр. Раз в неделю администратор смотрит удаления и перепроведения в закрытых периодах.

Контроль сотрудников затрагивает их персональные данные. Работодатель обрабатывает их по правилам главы 14 ТК РФ и закона № 152-ФЗ. На практике сотрудников знакомят под подпись с положением об информационной безопасности, где сказано, что работа в учётных системах протоколируется.

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