Как узнать историю установки даты запрета изменения данных в 1С?

В процессе ведения учета в любой конфигурации «1С:Предприятие» (например, в «1С:Бухгалтерия предприятия 3.0») одной из важнейших задач администратора и главного бухгалтера является контроль закрытых периодов. Установка даты запрета изменения данных позволяет предотвратить случайное или намеренное редактирование документов прошлых периодов. Однако на практике часто возникает ситуация, когда дата запрета неожиданно сдвигается «назад», открывая период для редактирования. В этот момент возникает необходимость выяснить: кто, когда и на какое значение изменил дату запрета?

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

Способ 1. Анализ истории через стандартный Журнал регистрации

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

Для того чтобы проанализировать историю изменений дат запрета, выполним следующие действия:

1. Перейдем в раздел Администрирование, затем выберем пункт Обслуживание и откроем Журнал регистрации.
2. В открывшемся окне журнала нажмем кнопку Установить отбор (значок воронки на панели инструментов).
3. В окне настройки фильтра перейдем на вкладку Данные.
4. В поле выбора метаданных нам необходимо указать конкретный объект конфигурации. Настройки дат запрета изменений хранятся в специальном регистре сведений. Найдем и отметим флагом объект РегистрСведений.ДатыЗапретаИзменения (в интерфейсе он может отображаться как Даты запрета изменения (загрузки) данных).
5. Перейдем на вкладку События. Чтобы исключить лишнюю информацию, оставим только события, связанные с модификацией данных. Выберем следующие системные события:
   • Данные.Новый — фиксация создания новых правил запрета (например, добавление нового пользователя или организации в список исключений).
   • Данные.Изменение — фиксация редактирования существующих настроек (сдвиг даты вперед или назад).
   • Данные.Удаление — фиксация удаления правил запрета.
6. Нажмем кнопку Применить.

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

Техническая особенность: почему стандартный Журнал регистрации не всегда удобен?

Проанализируем архитектуру хранения этих данных в 1С. В типовых конфигурациях, разработанных на базе БСП (Библиотеки стандартных подсистем), за хранение дат отвечает непериодический регистр сведений ДатыЗапретаИзменения. Поскольку этот регистр является непериодическим, платформа хранит в базе данных исключительно текущее («срезовое») состояние настроек. История изменений в самих таблицах СУБД не накапливается.

При использовании стандартного Журнала регистрации мы сталкиваемся со следующими трудностями:

• Журнал регистрации фиксирует факт изменения набора записей регистра целиком. В колонке «Данные» отображается лишь представление измененного набора записей, но платформа по умолчанию не пишет в лог подробную текстовую расшифровку: какая дата стояла до изменения и какая была записана после.
• Если в системе настроена сложная схема (даты запрета установлены отдельно по организациям, по разделам учета или по конкретным пользователям), то при записи изменений в Журнал будет выводиться массив XML-данных, расшифровать который «на лету» рядовому администратору крайне тяжело.
• Если Журнал регистрации регулярно сокращается (архивируется или очищается) для экономии места на диске сервера, старая история изменений дат запрета будет безвозвратно утеряна.

Способ 2. Детализированное логирование изменений с помощью расширения (для программистов)

Для того чтобы обойти ограничения стандартного Журнала регистрации и фиксировать четкие, понятные человеку логи (например: «Пользователь Администратор изменил дату запрета для Организации "Конфетпром" с 31.12.2023 на 31.03.2024»), мы можем использовать механизм расширения конфигурации.

Рассмотрим пример создания такого расширения. Нам необходимо перехватить событие записи набора записей регистра сведений ДатыЗапретаИзменения, сравнить старые данные в базе с новыми, поступающими на запись, и зафиксировать разницу в Журнале регистрации в виде простого и понятного текста.

Выполним следующие шаги для реализации этой задачи:

1. Создадим новое расширение в конфигураторе и добавим в него регистр сведений ДатыЗапретаИзменения.
2. Добавим модуль набора записей этого регистра в расширение.
3. Создадим обработчик события ПередЗаписью с методом перехвата &Перед или &Вместо для вычисления старых значений, а также обработчик ПриЗаписи для фиксации итоговых изменений.

Рассмотрим пример программного кода, который решает эту задачу:

&Вместо("ПередЗаписью")
Процедура Расш_ПередЗаписью(Отказ, Замещение)
	// Инициализируем структуру для хранения старых значений в свойствах набора записей
	ЭтотОбъект.ДополнительныеСвойства.Вставить("СтарыйНаборДанных", ПолучитьТекущийНаборИзБазы(ЭтотОбъект.Отбор));
КонецПроцедуры

&Вместо("ПриЗаписи")
Процедура Расш_ПриЗаписи(Отказ)
	// Получаем сохраненные на этапе "ПередЗаписью" старые данные
	СтарыйНабор = Неопределено;
	Если ЭтотОбъект.ДополнительныеСвойства.Свойство("СтарыйНаборДанных", СтарыйНабор) Тогда
		ПроанализироватьИЗаписатьИзменения(СтарыйНабор, ЭтотОбъект);
	КонецЕсли;
КонецПроцедуры

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

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

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

Безопасность и разграничение прав доступа

Помимо фиксации уже произошедших изменений, важно превентивно ограничить круг лиц, имеющих техническую возможность менять эти настройки. Выясним, какие роли отвечают за редактирование дат запрета изменений в конфигурациях на базе БСП (включая БП 3.0, ERP, КА 2):

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

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