Администрирование · 13 мин
Дата запрета изменения данных в 1С: настройка и поиск того, кто её менял
Где в 1С настраивается дата запрета изменения данных, как проверить текущее значение и выяснить через журнал регистрации, кто и когда её изменил.
Дата запрета изменения данных — штатный механизм 1С, который блокирует редактирование и проведение документов за закрытые периоды. Бухгалтерия закрыла квартал, сдала отчётность — и никто случайно не перепроведёт январский документ. Но на практике регулярно возникает обратная задача: дата внезапно «отъехала» назад, старые документы изменились, и нужно понять, кто это сделал.
Стандартных средств «истории изменений даты запрета» в типовых конфигурациях нет — сама дата хранится как константа или параметр, а не как объект с версионированием. Поэтому ответ на вопрос «кто менял» приходится искать косвенно: через журнал регистрации, права пользователей, расширенные настройки и дополнительные механизмы аудита.
Ниже — практический разбор: где лежит настройка, как проверить её текущее состояние, какие события искать в журнале регистрации и как организовать контроль, чтобы в следующий раз вопрос «кто менял» решался за минуту.
Где в 1С хранится и настраивается дата запрета
В конфигурациях на базе Библиотеки стандартных подсистем (БСП) — «Бухгалтерия предприятия», «Зарплата и управление персоналом», «Управление торговлей», ERP — настройка находится по пути: Администрирование → Поддержка и обслуживание → Регламентные операции → Настроить дату запрета изменения данных. В некоторых интерфейсах пункт называется «Даты запрета изменения данных» и доступен из раздела «Настройка прав и реквизитов».
Технически значение хранится в константе «Дата запрета изменения данных» (или в структуре констант, если используется раздельная настройка по разделам и организациям). Механизм поддерживает несколько режимов: единая дата для всей информационной базы, отдельные даты по разделам учёта (бухгалтерский учёт, зарплата, склад) и уточнение по организациям.
Дополнительно существует понятие «дата запрета для загрузки данных» — она ограничивает обмены (например, синхронизацию между базами), но не мешает ручному редактированию. Эти две даты настраиваются независимо, и путать их — частая причина ложных выводов при расследовании.
Как проверить текущее значение и кто имеет право его менять
Первый шаг при любом подозрении — зафиксировать текущее состояние. Откройте форму настройки даты запрета и запишите: какая дата установлена, включены ли разделы и организации, стоит ли флаг «Дата запрета для загрузки данных». Это точка отсчёта для сравнения с тем, что «должно быть».
Второй шаг — определить круг лиц, которые физически могли изменить настройку. Право на изменение даты запрета даёт роль «Изменение дат запрета изменения данных» (входит в профиль администратора и может выдаваться отдельно). Откройте Администрирование → Настройка пользователей и прав → Пользователи и проверьте, у кого есть административные права или эта роль.
На практике круг подозреваемых обычно сужается до 2–5 человек, если права раздавались осознанно. Если же половина пользователей работает под полными правами — это отдельная организационная проблема, и расследование усложняется.
- 1Откройте Администрирование → Поддержка и обслуживание → Настроить дату запрета и зафиксируйте текущее значение
- 2Проверьте, включена ли раздельная настройка по разделам и организациям
- 3Откройте список пользователей и определите, у кого есть роль изменения даты запрета или полные права
- 4Сверьте фактическую дату с утверждённым графиком закрытия периодов
- 5Зафиксируйте расхождение письменно (скриншот, время) до начала изменений
Как узнать, кто менял дату запрета: работа с журналом регистрации
Основной источник информации — журнал регистрации: Администрирование → Поддержка и обслуживание → Журнал регистрации (в клиент-серверном варианте также доступен через консоль кластера). Изменение даты запрета фиксируется как изменение константы, поэтому нужно настроить отбор.
Откройте отбор журнала и установите фильтры: событие — «Данные. Изменение» (и при необходимости «Данные. Добавление»), метаданные — константа «Дата запрета изменения данных» и связанные константы настройки. Ограничьте период анализа, иначе выборка будет тяжёлой. В результате вы увидите строки вида: пользователь, время, компьютер, имя константы.
Важный нюанс: в типовом журнале регистрации для констант обычно виден факт изменения и автор, но не всегда — старое и новое значение. Представление данных в событии зависит от версии платформы и уровня регистрации. Если значения не видно, автора изменения всё равно установить можно, а вот «на что именно поменяли» придётся восстанавливать по косвенным признакам: резервным копиям, истории обменов, показаниям пользователей.
Если база файловая
В файловом варианте журнал регистрации хранится в каталоге базы (файл 1Cv8.lgd). Он доступен тем же способом через меню, но при большом объёме работает медленнее. Учтите: технологически файл журнала можно удалить или подменить при доступе к каталогу базы — поэтому в спорных ситуациях ограничивайте файловый доступ к каталогу ИБ на уровне ОС.
Если событий в журнале нет
Отсутствие записей об изменении константы при фактически изменённой дате означает одно из трёх: журнал регистрации был очищен (событие «Журнал регистрации. Очистка» — ищите его отдельно), изменение выполнялось напрямую в СУБД в обход платформы, либо дату меняли до начала периода хранения журнала. Все три варианта — тревожные признаки, требующие участия администратора.
Косвенные способы установить автора изменений
Если журнал регистрации не дал однозначного ответа, используются дополнительные источники. Первый — сеансы пользователей: события «Сеанс. Начало» и «Сеанс. Завершение» покажут, кто работал в базе в интересующий промежуток, с каких компьютеров и под какими учётными записями ОС.
Второй источник — история изменённых документов закрытого периода. Если дату запрета отодвинули ради правки конкретных документов, отберите в журнале регистрации события изменения данных по этим документам: автор правки документа с высокой вероятностью связан с автором сдвига даты. Совпадение по времени и пользователю — сильное косвенное доказательство.
Третий источник — резервные копии. Если копии делаются регулярно, можно поднять копию на дату до предполагаемого изменения и сравнить значение константы. Это даст точную вилку «когда» и иногда — «на что меняли». В клиент-серверных базах аналогичную роль играют копии средствами СУБД.
Сверьте пользователя с графиком работы и списком уполномоченных
Ищите событие очистки журнала, проверяйте доступ к СУБД
Сопоставьте авторов правок документов и сдвига даты по времени
Проверьте настройки синхронизации и регламентные задания обмена
Как защититься: контроль изменений даты запрета на будущее
Чтобы вопрос «кто менял» больше не возникал, нужны превентивные меры. Первая и главная — минимизация прав: роль изменения даты запрета должна быть только у одного-двух ответственных, а не у всех администраторов. Проверьте также внешние обработки и расширения: код с полными правами может менять константу мимо интерфейса.
Вторая мера — программный аудит. В конфигурациях на БСП можно включить версионирование объектов для справочников и документов, а для контроля самой даты запрета внедрить несложную доработку: подписку на событие записи константы, которая пишет в отдельный регистр сведений автора, старое и новое значение, дату и время. Это штатный приём, который внедряет разработчик за короткое время, но он требует аккуратности при обновлениях конфигурации.
Третья мера — регламентная: утвердите порядок, по которому сдвиг даты запрета выполняется только по письменной заявке (хотя бы по электронной почте) с фиксацией причины. Совместно с техническим аудитом это закрывает вопрос полностью: любое изменение либо санкционировано, либо сразу видно как нарушение.
Сравнение вариантов контроля
Ничего внедрять не нужно, но виден автор без гарантии старого/нового значения, журнал можно очистить
Полная история: кто, когда, что менял; требует доработки и сопровождения при обновлениях
Независим от платформы 1С, но сложен в настройке и не показывает пользователя 1С напрямую
Самый дешёвый вариант; не даёт технических доказательств, но резко сужает круг возможных авторов
Типичные ошибки при расследовании и настройке
Самая распространённая ошибка — искать историю изменений даты запрета там, где её нет: в типовой конфигурации нет отчёта «кто менял дату запрета», и время на поиски такой кнопки тратится впустую. Сразу идите в журнал регистрации с отбором по константам.
Вторая ошибка — путать дату запрета редактирования и дату запрета загрузки. Если у пользователей «вдруг» перестали проводиться старые документы после обмена, причина может быть именно в дате загрузки, и расследование уйдёт по ложному следу.
Третья ошибка — анализировать журнал без ограничения периода на большой базе: отбор по всем событиям за год может выполняться очень долго и нагружать сервер. Всегда сужайте диапазон дат и состав событий. И четвёртая ошибка — делать выводы до резервной копии: любая «проверочная» правка данных закрытого периода до фиксации состояния может смешать следы.
Проверка результата: как убедиться, что механизм работает
После настройки или восстановления даты запрета проверьте механизм под тестовым пользователем без специальных прав: попытка провести документ датой раньше даты запрета должна завершаться сообщением о запрете. Если документ проводится — либо у пользователя есть обходное право, либо дата настроена не для того раздела учёта или организации.
Для механизма аудита (если внедрён) выполните контрольное изменение даты под своей учётной записью и убедитесь, что в регистре аудита появилась запись с корректными старым и новым значениями. Без такой проверки доработка считается непроверенной.
Как проверить результат
Сообщение о запрете изменения данных
Документ проводится — дата не действует или есть обходные права
Событие изменения константы с указанием пользователя
Событий нет — проверьте уровень регистрации и отбор
Запись с автором, старым и новым значением
Записи нет — подписка не срабатывает, нужна отладка
1–2 ответственных сотрудника
Право есть у широкого круга или у всех администраторов
Частые вопросы
Можно ли в типовой 1С увидеть, какое значение даты запрета было раньше?
Штатно — нет: константа не версионируется. Старое значение восстанавливают по резервным копиям, данным обменов или по записям журнала регистрации, если в представлении события сохранилось значение. Для постоянного контроля внедряют регистр аудита через подписку на запись константы.
Почему в журнале регистрации нет событий изменения даты запрета?
Возможные причины: установлен слишком узкий отбор, журнал был очищен (ищите событие очистки), изменение выполнялось напрямую в СУБД либо период хранения журнала истёк. Проверьте также, что вы ищете именно события изменения данных по константе, а не по документам.
Может ли дата запрета измениться сама, без действий пользователя?
Да: в некоторых конфигурациях есть регламентные задания и обработчики, автоматически сдвигающие дату (например, при закрытии месяца или после синхронизации). Проверьте список регламентных заданий и настройки обменов — в журнале регистрации такое изменение будет записано от имени пользователя, под которым выполняется задание, часто это служебная учётная запись.
Кто по умолчанию может менять дату запрета?
Пользователи с полными правами и те, кому явно назначена роль изменения дат запрета (в конфигурациях на БСП). Точный состав проверяется через профили групп доступа в разделе настройки пользователей и прав.
Блокирует ли дата запрета удаление документов закрытого периода?
Да: пометка удаления и снятие пометки для объектов раньше даты запрета также блокируются для пользователей без специального права. Однако «Контроль остатков» и операции в обход проверок (обмены с отключенной проверкой, обработки с привилегированным режимом) могут обходить ограничение — это учитывайте при расследовании.
Что делать, если дату запрета меняли в обход платформы, через СУБД?
Это признак серьёзного нарушения: платформа таких изменений не фиксирует. Ограничьте прямой доступ к базе данных на уровне СУБД (отдельные учётные записи, аудит средствами сервера БД), проверьте логи СУБД за интересующий период и пересмотрите, кому выданы пароли администратора кластера и сервера баз данных.
Что важно запомнить
Штатной истории изменений даты запрета в 1С нет: автора изменения ищут через журнал регистрации с отбором по константе, список пользователей с соответствующей ролью и косвенные признаки (сеансы, правки документов, резервные копии). Для постоянного контроля минимизируйте права, внедрите регистр аудита через подписку на запись константы и закрепите регламент согласования сдвига даты.