Кто исправил документ в 1С: журнал регистрации, история версий и их пределы

Проверить изменение документа в 1С можно двумя штатными способами. Журнал регистрации (Администрирование → Обслуживание → Журнал регистрации) покажет, кто, когда и с какого компьютера записал или провёл документ. История изменений (версии объектов) покажет, какие именно поля поменялись: было и стало.

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

Как включить журнал регистрации и выбрать уровень записи

Журнал ведёт сама платформа, но пишет он столько, сколько разрешено настройкой уровня. Если уровень стоит «Ошибки», события изменения данных туда просто не попадут.

Уровень задаётся в конфигураторе:

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

Где лежат файлы журнала:

С платформы 8.3.5 по умолчанию используется формат с расширением .lgd (одна база SQLite). Старые базы могут хранить журнал в прежнем текстовом формате: файл .lgf и набор файлов .lgp.

Не удаляйте и не переносите файлы журнала при работающих пользователях: платформа держит их открытыми, а запись событий оборвётся до перезапуска сеансов.

Как найти в журнале, кто изменил документ

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) журнал открывается из раздела Администрирование → Обслуживание. Если раздела нет или прав не хватает, тот же журнал доступен через Все функции → Стандартные → Журнал регистрации. Команду «Все функции» включают в параметрах программы флажком отображения этой команды.

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

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

Что означают события группы «Данные»:

• ➕ Данные. Добавление — документ создан и записан впервые.
• ✏️ Данные. Изменение — документ перезаписан, неважно, поменяли одно поле или ничего.
• ✅ Данные. Проведение — документ проведён или перепроведён.
• ↩️ Данные. Отмена проведения — проведение снято.
• ❌ Данные. Удаление — объект удалён из базы окончательно.

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

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

Пример: кто поменял сумму в реализации

Ситуация. В акте от 15 числа сумма была 120 000 руб., сейчас 102 000 руб. Бухгалтер уверен, что никто не правил.

Что делаем:

1. Отбор по документу за период с 15 числа по сегодня, события группы «Данные».
2. Находим три строки. 15-го — «Добавление» и «Проведение» от менеджера. 22-го — «Изменение» и «Проведение» от другого пользователя, с компьютера склада, приложение «Тонкий клиент».
3. Номер сеанса 22-го ведёт к цепочке: тот же сеанс перед этим записал документ возврата от покупателя.

Вывод: сумму поменял человек вручную, скорее всего после частичного возврата. Какая строка табличной части изменилась и на сколько, журнал не скажет. Это видно только в истории изменений, если она включена, или в копии базы за 21 число.

Разница 120 000 − 102 000 = 18 000 руб. сверяется с суммой возврата. Совпало — история понятна. Не совпало — ищите вторую правку в истории версий.

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

Журнал можно выгрузить кнопкой сохранения в файл (XML или табличный документ). Так удобно передать выборку аудитору или приложить к служебной записке.

История изменений: какие поля поменялись

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

Как включить в Бухгалтерии 3.0 и других конфигурациях на БСП:

1. Откройте Администрирование → Общие настройки.
2. В группе «История изменений» установите флажок хранения истории.
3. По ссылке настройки хранения выберите виды документов и момент сохранения версии: никогда, при записи или при проведении.
4. Задайте срок хранения старых версий, чтобы таблица версий не росла бесконечно.

Как посмотреть изменения конкретного документа:

1. Откройте документ.
2. В меню Ещё выберите «История изменений».
3. В списке версий отметьте две нужные (с зажатым Ctrl).
4. Нажмите «Сравнить». Откроется отчёт, где изменённые значения подсвечены.

Из той же формы версию можно открыть и вернуться к ней. Возврат создаёт новую запись документа, так что сама откатка тоже попадёт в историю.

Отладка: как поймать момент изменения

Журнал и версии отвечают на вопрос «кто». Отладчик отвечает на вопрос «каким кодом». Это нужно, когда поле меняется само: при проведении, при обмене, после обработки заполнения.

Порядок для файловой базы:

1. Сделайте копию базы и работайте на ней. В рабочей базе отладку не ведут.
2. В конфигураторе откройте модуль объекта документа и поставьте точку останова в обработчиках ПередЗаписью и ОбработкаПроведения.
3. Запустите Отладка → Начать отладку → Тонкий клиент.
4. Повторите действие, после которого поле менялось.
5. В момент остановки посмотрите стек вызовов и значения реквизитов через табло.

Для клиент-серверной базы серверную отладку нужно разрешить. Агент сервера 1С запускается с ключом -debug. Чтобы добавить ключ, службу придётся перезапустить, а это обрывает сеансы всех пользователей. Делайте это вне рабочего времени и на тестовом сервере.

Если подозрение падает на обмен или фоновое задание, поможет технологический журнал. Его включают файлом logcfg.xml в каталоге conf платформы и пишут события на сервере 1С. Технологический журнал быстро растёт, поэтому оставляйте его включённым на часы, а не на недели.

Программный аудит: свой журнал изменений нужных полей

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

Пример для модуля объекта документа в расширении (конфигурация на БСП):

&Перед("ПередЗаписью")
Процедура Аудит_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)

	Если ОбменДанными.Загрузка Или ЭтоНовый() Тогда
		Возврат;
	КонецЕсли;

	СтараяСумма = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "СуммаДокумента");

	Если СтараяСумма <> СуммаДокумента Тогда
		Комментарий = СтрШаблон("Сумма документа: было %1, стало %2",
			Формат(СтараяСумма, "ЧДЦ=2; ЧН=0"), Формат(СуммаДокумента, "ЧДЦ=2; ЧН=0"));
		ЗаписьЖурналаРегистрации("Аудит.ИзменениеСуммы",
			УровеньЖурналаРегистрации.Информация,
			ЭтотОбъект.Метаданные(), Ссылка, Комментарий);
	КонецЕсли;

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

Что важно в этом примере:

• 🔹 Проверка ОбменДанными.Загрузка отсекает записи при обмене. Если менять поле может и обмен, уберите её.
• 🔹 Для нового документа старого значения нет, поэтому ЭтоНовый() выходит из процедуры.
• 🔹 Событие «Аудит.ИзменениеСуммы» появится в журнале как отдельный тип, по нему удобно ставить отбор.

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

Сравнение способов:

Где журнал и версии не помогут

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

• 🚫 Прямой запрос к СУБД. Изменения таблиц через SQL Server или PostgreSQL в обход платформы журнал не видит.
• 🚫 Загрузка .dt или восстановление копии. Документ вернётся в состояние на дату копии, а записи журнала после неё останутся в файлах журнала, но к данным уже не относятся.
• 🚫 Сокращение журнала. Команда сокращения в конфигураторе удаляет записи до указанной даты. Перед удалением платформа предлагает сохранить их в файл, но это можно пропустить.
• 🚫 История не включена для вида документа. Версий нет, остаётся только факт записи из журнала.
• 🚫 Несколько человек под одной учётной записью. Журнал покажет одного пользователя на всех. Разделить действия можно только по колонке «Компьютер».

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

Аудит доступа: кто вообще мог изменить документ

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

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

Права смотрите в профилях групп доступа: Администрирование → Настройки пользователей и прав. Если у бухгалтера стоит профиль «Администратор», он может и менять документы, и чистить журнал. Такие профили стоит раздать минимальному числу людей.

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