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

Запрет на редактирование в 1С 8.3 ставят на одном из пяти уровней: правами роли (снять «Изменение»), запретом на отдельные реквизиты, ограничением на уровне записей (РЛС), программно через обработчики событий или, в крайнем случае, на уровне СУБД. Выбор зависит от того, что именно блокируем — весь объект, часть полей, записи по условию или базу целиком.

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

Запрет через роли и права доступа — базовый способ

Роль задаёт, что пользователь может делать с объектом. Чтобы запретить менять справочник или документ, у роли снимают право «Изменение».

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

• 🔒 «Изменение» — объект нельзя менять ни руками, ни программно под этой ролью;
• 🔒 «Удаление» и «Добавление» — если нужно запретить и их;
• оставьте «Чтение» и «Просмотр», чтобы документ оставался виден.

Различайте основные и интерактивные права. Если снять только интерактивное «Редактирование», но оставить «Изменение», пользователь не сможет править объект через форму руками, а программный код (обработки, обмены) продолжит писать данные. Это удобно, когда объект должен меняться автоматически, но не вручную.

В режиме «1С:Предприятие» на типовых конфигурациях (Бухгалтерия 3.0, ЗУП 3, УТ 11, ERP) в Конфигуратор не лезут. Права настраивают через профили групп доступа: Администрирование → Настройки пользователей и прав → Профили групп доступа. Создайте копию нужного профиля, уберите из неё роль, дающую изменение объекта, и назначьте этот профиль группе пользователей.

Запрет на изменение отдельных реквизитов

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

Через свойства формы. У элемента формы есть свойство ТолькоПросмотр. Поставьте его у нужного поля, и реквизит станет серым, недоступным для ввода. Делается это в обработчике формы — например, ПриСозданииНаСервере или ПриЧтенииНаСервере:

Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    Если НЕ Объект.Ссылка.Пустая() Тогда
        Элементы.Организация.ТолькоПросмотр = Истина;
        Элементы.Контрагент.ТолькоПросмотр = Истина;
    КонецЕсли;
КонецПроцедуры

Условие НЕ Объект.Ссылка.Пустая() оставляет поля доступными при создании и запирает их у уже записанного документа. Если нужно закрыть всю форму на чтение — у самой формы есть свойство ТолькоПросмотр, оно блокирует ввод во все элементы сразу.

Через типовой механизм «замка». В конфигурациях на БСП есть подсистема запрета редактирования реквизитов. На форме документа или элемента справочника вверху стоит кнопка-замок «Разрешить редактирование реквизитов». После первой записи ключевые поля блокируются автоматически; чтобы их поправить, пользователь жмёт замок (действие при этом фиксируется). Отдельно программировать ничего не нужно — механизм встроенный.

Не прячьте реквизит вместо блокировки: скрытое поле всё равно можно изменить программно или через обработку, а значение в базе останется редактируемым. ТолькоПросмотр надёжнее, чем Видимость = Ложь.

Ограничение на уровне записей (РЛС)

РЛС — это ограничение доступа на уровне записей (Record Level Security), а не регламентные задания, как иногда пишут. Механизм разрешает или запрещает операции не над всем объектом, а над конкретными строками таблицы по условию.

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

В Конфигураторе условие задают в роли: выберите объект, право «Изменение», и в поле ограничения напишите текст на языке запросов. Например, разрешить изменение только по организациям из списка пользователя:

ГДЕ Организация В (&ДоступныеОрганизации)

Параметр &ДоступныеОрганизации платформа подставляет из текущего сеанса. Для повторяющихся условий удобны шаблоны ограничений (отдельная вкладка роли) — один шаблон подключают к разным объектам.

Важная тонкость: ограничение можно задать отдельно на чтение и отдельно на изменение. Если наложить РЛС только на право «Изменение», оставив чтение свободным, пользователь будет видеть документы всех организаций, но править — только по своим. Это ровно то поведение, которое чаще всего и требуется от запрета на уровне записей.

В типовых конфигурациях РЛС настраивается без Конфигуратора — через группы доступа. В профиле группы включают ограничение по видам доступа (организации, склады, подразделения), а конкретные значения назначают пользователю в его группе доступа: Администрирование → Настройки пользователей и прав → Группы доступа.

Программный запрет через обработчики событий

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

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

Этот код не даст рядовому пользователю переписать проведённый документ, а администратору с полными правами — позволит. Проверку прав удобно делать функцией Роли.Доступна("ИмяРоли") или ПравоДоступа("Изменение", Метаданные.Документы.РеализацияТоваровУслуг).

Если правило общее для многих объектов, вместо правки каждого модуля создайте подписку на событие (ПодпискиНаСобытия) на событие ПередЗаписью и укажите в источнике нужные типы. Логика будет в одном общем модуле.

Запрет изменения данных до определённой даты

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

Путь в типовых конфигурациях: Администрирование → Настройки пользователей и прав → Даты запрета изменения (ввода) данных. Включите флажок и задайте дату — платформа запретит запись документов с датой на уровне или раньше установленной.

Дату запрета задают гибко:

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

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

Блокировка на уровне СУБД — крайняя мера

Способ «для опытных администраторов» на практике точечно не работает : 1С подключается к СУБД под одной служебной учётной записью, поэтому ограничить права одного пользователя 1С средствами MS SQL или PostgreSQL нельзя — вы заблокируете всех разом.

Где это всё-таки уместно — перевести в режим «только чтение» всю базу целиком, например архивную копию закрытого года. На MS SQL это делается командой:

ALTER DATABASE [ИмяБазы] SET READ_ONLY;

Для файловой базы аналог — поставить атрибут «Только чтение» на файл 1Cv8.1CD средствами ОС.

Какой способ выбрать под вашу задачу:

Как проверить, что запрет сработал

Настроить запрет мало — его нужно проверить под тем пользователем, для которого он предназначен, а не под администратором. У администратора почти всегда есть роль «Полные права», и под ней ограничение не видно.

Порядок проверки:

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

Если под тестовым пользователем объект по-прежнему редактируется — почти всегда дело во второй роли, которая возвращает право (см. последний вопрос ниже).

Типичные ошибки при настройке запрета

Ошибки повторяются от базы к базе — вот те, что ломают логику запрета чаще всего.

• ❌ Сняли «Просмотр» вместо «Изменение». Пользователь теряет доступ к объекту целиком и видит ошибку прав, хотя задача была лишь запретить правку.
• ❌ Спрятали поле через Видимость = Ложь. Скрытый реквизит остаётся доступным для записи программно и через групповую обработку — это не запрет, а маскировка.
• ❌ Правка ролей и модулей прямо в типовой конфигурации на поддержке. Следующее обновление либо перезапишет изменения, либо встанет с конфликтами. Работайте через профили, группы доступа и расширения.
• ❌ Проверка права через роль с жёстким именем. Роли.Доступна("Бухгалтер") сломается, если роль переименуют или пользователю назначат другую. Надёжнее ПравоДоступа(...).
• ❌ РЛС навешали на всё подряд. На крупной базе лишние ограничения на уровне записей заметно замедляют отчёты и проведение.
• ❌ Перевели рабочую базу в READ_ONLY. Пользователи встают колом: ни один документ не записывается. Этот режим — только для архивов.

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