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

Защита данных от случайного или намеренного изменения — одна из базовых задач администрирования 1С. Бухгалтер закрыл квартал, сдал отчётность, а через неделю кто-то перепровёл документ прошлого периода — и цифры в отчётах «поплыли». Чтобы этого не происходило, в типовых конфигурациях на платформе 1С:Предприятие 8.3 предусмотрено несколько независимых механизмов запрета редактирования.

Выбор способа зависит от задачи. Если нужно закрыть прошлый период для всех пользователей — используйте дату запрета изменения данных. Если ограничить конкретного сотрудника — настройте права и профили групп доступа. Если требуется тонкое разграничение, например запрет на чужие подразделения или контрагентов, — применяется механизм ограничения доступа на уровне записей (RLS). Для нестандартных сценариев доступны программные средства: подписки на события и блокировки.

Все перечисленные механизмы работают в типовых конфигурациях «1С:Бухгалтерия 8», «1С:Зарплата и управление персоналом», «1С:Управление торговлей», «1С:ERP» и других решениях на базе Библиотеки стандартных подсистем. Названия пунктов меню могут незначительно отличаться в зависимости от версии конфигурации.

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

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

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

Дата запрета изменения данных

Подходит для закрытия периода (месяц, квартал, год) для всех или отдельных пользователей. Не защищает текущие документы и не различает виды операций внутри открытого периода.

Права и профили групп доступа

Подходит для запрета действий конкретным пользователям: например, только просмотр документов без изменения. Не привязано к датам — действует постоянно.

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

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

Программные механизмы

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

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

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

Дата запрета изменения данных — это граница, раньше которой пользователи не могут создавать, изменять и удалять документы и другие объекты. Механизм встроен в Библиотеку стандартных подсистем и доступен в большинстве типовых конфигураций. Проверка срабатывает и в пользовательском режиме, и при обменах данными, если это предусмотрено настройками.

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

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

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

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

Исключения для отдельных пользователей

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

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

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

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

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

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

Если нужно заблокировать отдельный объект — например, конкретный договор или элемент справочника, — штатного универсального переключателя нет. Практикуются такие варианты: установка пометки удаления (объект перестаёт участвовать в движениях и недоступен для проведения), использование реквизита статуса с проверкой в подписке на событие, либо доработка с установкой свойства формы «Только просмотр» по условию. Выбор зависит от того, должен ли объект оставаться видимым и участвовать в отчётах.

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

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

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

Программные способы для нестандартных сценариев

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

Основные приёмы: подписка на событие «ПриЗаписи» или «ОбработкаПроверкиЗаполнения» с вызовом исключения при нарушении условия; установка свойства формы «ТолькоПросмотр» в обработчике «ПриОткрытии»; программная проверка даты запрета функцией БСП. Пример проверки в подписке на событие:

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

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

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

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

Контрольные точки

Контрольные точки проверки

Открытие документа закрытого периода под обычным пользователем

Норма

При попытке записи появляется сообщение о дате запрета, изменения не сохраняются

Тревожный признак

Документ сохраняется и перепроводится без предупреждений

Проведение нового документа задним числом

Норма

Система отказывает в проведении с указанием даты запрета

Тревожный признак

Документ проводится в закрытом периоде

Изменение данных через обработку или групповое изменение реквизитов

Норма

Обработка также получает отказ при записи

Тревожный признак

Обработка изменяет объекты в обход запрета

Права пользователя с профилем «только просмотр»

Норма

Кнопки создания и изменения недоступны, запись невозможна

Тревожный признак

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

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

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

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

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

Почему дата запрета не срабатывает для некоторых пользователей?

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

Можно ли запретить редактирование, но оставить просмотр документов?

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

Что делать, если нужно срочно исправить документ в закрытом периоде?

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

Работает ли запрет редактирования при обмене данными между базами?

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

Как заблокировать изменение конкретного элемента справочника без доработок?

Штатного переключателя «запретить редактирование этого элемента» в типовых конфигурациях нет. Ближайшие варианты: пометка на удаление, если элемент больше не используется; RLS, если элемент можно выделить условием (группа, владелец, организация); либо небольшая доработка через расширение с проверкой условия при записи.