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

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

В типовых конфигурациях 1С (Бухгалтерия предприятия, Управление торговлей, Зарплата и управление персоналом, ERP) для этого есть несколько независимых механизмов: дата запрета редактирования, профили групп доступа, роли и ограничение доступа на уровне записей (RLS). Они дополняют друг друга, и правильный выбор зависит от того, что именно требуется заблокировать — период, конкретные объекты или отдельные поля.

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

Определите, что именно нужно запретить

Прежде чем открывать настройки, сформулируйте задачу конкретно. От этого зависит выбор механизма. «Запретить всем менять документы до 31 декабря» — это дата запрета редактирования. «Запретить менеджерам изменять номенклатуру» — это права на объекты через профили доступа. «Запретить видеть чужие склады» — это RLS, ограничение на уровне записей.

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

Установите дату запрета редактирования

Дата запрета редактирования — самый простой и надёжный способ закрыть период. Все документы с датой раньше указанной становятся недоступными для изменения, проведения и удаления у пользователей, на которых распространяется запрет.

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

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

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

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

Настройте права через профили групп доступа

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

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

Обратите внимание на интерактивные права. В платформе 1С права делятся на обычные и интерактивные: «Изменение» разрешает запись программно, а «Интерактивное изменение» — через интерфейс. Для надёжного запрета снимать нужно оба вида прав, иначе пользователь сможет обойти ограничение через обработки или командный интерфейс.

Ограничьте доступ на уровне записей (RLS)

Ограничение доступа на уровне записей (Record Level Security) позволяет показывать пользователю только «его» данные: документы по своей организации, складу или подразделению. Всё остальное становится невидимым — а значит, и недоступным для изменения.

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

У RLS есть цена — производительность. Запросы к базе усложняются, и на больших объёмах данных списки документов могут открываться заметно медленнее. Не включайте ограничения по всем объектам подряд: ограничивайте только те разделы, где это действительно требуется по регламенту компании.

Запретите изменение через свойства объектов и подписки

Если типовых механизмов не хватает — например, нужно запретить изменение одного конкретного реквизита или блокировать документы по сложному условию — используются средства разработки. В модуле объекта или в подписке на событие «ПередЗаписью» / «ПриЗаписи» проверяется условие, и при его выполнении вызывается отказ от записи.

Процедура ЗапретИзмененияПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения)
	Если Источник.Дата < Дата(2026, 12, 31)
		И Не Пользователи.ЭтоПолноправныйПользователь() Тогда
		Отказ = Истина;
		Сообщить("Изменение документов закрытого периода запрещено");
	КонецЕсли;
КонецПроцедуры

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

Проверьте, что запрет действительно работает

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

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

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

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

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

Для аудита изменений полезно дополнительно включить версионирование объектов или историю изменений — тогда даже при наличии прав у пользователя все его правки фиксируются, и ответственность становится персональной.

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