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

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

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

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

Дата запрета изменения данных — основной способ

Дата запрета изменения данных — штатный механизм, доступный в большинстве типовых конфигураций на БСП (Библиотека стандартных подсистем): 1С:Бухгалтерия, 1С:ЗУП, 1С:Управление торговлей и других. Он запрещает изменять и проводить документы, дата которых раньше установленной границы, а также изменять связанные данные.

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

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

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

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

Запрет редактирования через права и профили доступа

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

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

Если типовых профилей не хватает, создают копию существующего профиля и корректируют состав ролей. Затем профиль привязывается к группе доступа, в которую включают нужных пользователей. Изменения вступают в силу после повторного входа пользователя в программу — об этом стоит предупреждать заранее.

Запрет на уровне записей (RLS)

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

Запрет редактирования конкретного документа или элемента

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

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

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

Такой код блокирует запись через любой путь: интерактивное редактирование, обмены, обработки. Исключение делают для полноправного пользователя или отдельной роли «РедактированиеУтвержденныхДокументов», чтобы у администратора оставался аварийный канал исправления ошибок.

Сравнение способов запрета редактирования

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

Проверка результата и типичные ошибки

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

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

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

Как временно снять или обойти запрет

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

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

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