Как узнать, кто редактировал документ в 1С

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

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

Ниже разобраны рабочие способы для типовых конфигураций на управляемых формах (Бухгалтерия предприятия, Управление торговлей, ERP, Зарплата и управление персоналом), а также варианты для самописных и старых конфигураций.

Способ 1. Журнал регистрации — универсальный инструмент

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

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

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

В результате отбора вы увидите строки вида «Документ. Реализация товаров и услуг 0000-001234 от 15.03 — Изменение», а в колонке «Пользователь» — имя сотрудника, выполнившего запись. Двойной клик по строке открывает детали события: компьютер, с которого выполнялось действие, разделённый по сеансам.

Учтите: журнал показывает факт изменения и его автора, но не показывает, какие именно реквизиты были изменены и какие значения были до правки. Для сравнения «было/стало» нужен механизм версионирования, описанный ниже.

Способ 2. Версионирование объектов — кто, когда и что именно поменял

Версионирование объектов — механизм из состава Библиотеки стандартных подсистем, который сохраняет снимок объекта при каждой записи. Это самый информативный способ: видно не только автора, но и различия между версиями.

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

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

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

Способ 3. Отчёт «История изменений» и данные самого документа

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

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

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

Способ 4. Программный запрос к истории и журналу

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

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

Запрос = Новый Запрос("ВЫБРАТЬ Версии.НомерВерсии, Версии.АвторВерсии, Версии.ДатаВерсии ИЗ РегистрСведений.ВерсииОбъектов КАК Версии ГДЕ Версии.Объект = &Ссылка УПОРЯДОЧИТЬ ПО Версии.НомерВерсии"); Запрос.УстановитьПараметр("Ссылка", ДокументСсылка); Результат = Запрос.Выполнить().Выгрузить();

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

Что делать, если истории нет: восстановление картины по косвенным признакам

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

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

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

Профилактика: настройте контроль до появления инцидентов

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

В-третьих, разграничьте права: если пользователю не нужно редактировать чужие документы, ограничьте это на уровне ролей. Механизм RLS и запрет изменения данных прошлых периодов (дата запрета редактирования в разделе Администрирование) снижают и число инцидентов, и круг потенциальных авторов правок.

Проверка результата и ограничения

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

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

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