Администрирование · 12 мин
Как сделать запрет изменения данных в 1С 8.3
Как установить запрет изменения данных в 1С 8.3: дата запрета редактирования, права доступа, RLS и программные проверки. Пошаговая настройка и типичные ошибки.
Запрет изменения данных в 1С 8.3 нужен в двух типовых ситуациях: закрыть уже сданный период (чтобы бухгалтер случайно не поменял прошлогодние документы после сдачи отчётности) и разграничить права пользователей (чтобы менеджер не мог редактировать чужие документы или справочники). Для этого в платформе и типовых конфигурациях есть несколько независимых механизмов, которые дополняют друг друга.
Основные инструменты: дата запрета изменения данных, роли и профили групп доступа, ограничение доступа на уровне записей (RLS), а также программные проверки в подписках на события. Выбор зависит от задачи: одно дело — закрыть период для всех, другое — запретить конкретному пользователю правку конкретных объектов.
Ниже разобраны все четыре способа с пошаговыми инструкциями, признаками корректной настройки и типичными ошибками. Материал ориентирован на типовые конфигурации на БСП (Бухгалтерия предприятия 3.0, Управление торговлей 11, ERP, ЗУП 3.1), но принципы работают и в самописных решениях.
Какой механизм запрета выбрать под вашу задачу
Прежде чем настраивать, определите, что именно нужно запретить. От этого зависит инструмент: ошибочный выбор приводит либо к дырам в защите, либо к избыточным ограничениям, мешающим работе.
Если нужно закрыть прошлый период для всех или части пользователей — используйте дату запрета изменения данных. Если нужно, чтобы сотрудник видел документы, но не мог их менять, — настройте роли «только чтение» в профиле группы доступа. Если доступ должен зависеть от содержимого (например, менеджер работает только со своей организацией или складом) — нужен RLS. Для особых условий вида «нельзя менять документ после выгрузки в банк» применяют программные проверки.
Как выбрать действие
Дата запрета изменения данных: закрытие периода
Дата запрета изменения данных — штатный механизм библиотеки стандартных подсистем (БСП), встроенный в большинство типовых конфигураций. Все документы и записи регистров с датой раньше установленной становятся недоступными для изменения и проведения. Это основной способ защитить закрытый месяц, квартал или год от случайной правки.
Важно понимать: дата запрета не шифрует и не блокирует данные на уровне СУБД. Это программная проверка, которая срабатывает при записи объектов через стандартные механизмы. Пользователь с правами администратора может изменить или снять дату, поэтому механизм эффективен в связке с грамотной настройкой прав.
Пошаговая настройка даты запрета
- 1Откройте раздел «Администрирование» → «Поддержка и обслуживание» → «Регламентные операции» (в некоторых конфигурациях путь: «Администрирование» → «Настройки пользователей и прав»).
- 2Установите флажок «Даты запрета изменения данных» и перейдите по ссылке «Настроить».
- 3В поле «Дата запрета» укажите дату, по которую данные закрыты. Например, 31.12 — все документы до конца прошлого года станут недоступны для правки.
- 4Выберите способ установки: «Общая дата» для всех пользователей, «По пользователям» — если кому-то нужно оставить право правки старого периода, или «По разделам и объектам» — чтобы закрыть только бухгалтерский учёт, оставив склад открытым.
- 5Запишите настройку и проверьте результат под обычным пользователем: попробуйте изменить документ закрытого периода — должно появиться сообщение о запрете.
Отдельно полезна возможность задавать дату запрета индивидуально. Например, для всех пользователей период закрыт по 31 марта, а для главного бухгалтера — по 31 января: он сможет вносить корректировки в первый квартал, пока остальные уже не могут. Настраивается это на закладке «По пользователям» в той же форме.
В типовых конфигурациях есть и регламентное задание, которое автоматически сдвигает дату запрета. Если оно включено, проверьте его расписание: автоматика может «закрыть» период раньше, чем вы закончите сверку, или наоборот — не закрыть вовремя.
Запрет редактирования через роли и профили групп доступа
Ролевая модель — фундамент разграничения прав в 1С. Каждой роли назначены права на объекты метаданных: чтение, добавление, изменение, удаление, проведение и другие. Если у пользователя нет права «Изменение» на справочник или документ, он сможет открыть и посмотреть данные, но сохранить правки не получится.
В типовых конфигурациях напрямую роли пользователям не назначают — используются профили групп доступа. Профиль объединяет набор ролей, а пользователь включается в группу доступа с этим профилем. Так проще управлять правами десятков сотрудников.
Как настроить режим «только просмотр»
Откройте «Администрирование» → «Настройки пользователей и прав» → «Профили групп доступа». Создайте новый профиль копированием существующего (например, профиля менеджера) и снимите в списке ролей те, что дают права на изменение нужных объектов. В типовых конфигурациях многие роли так и называются: «Добавление изменение…» и «Чтение…» — оставьте только роли чтения.
После этого включите пользователя в группу доступа с новым профилем и исключите из старой. Проверьте результат под учётной записью пользователя: документы должны открываться, но кнопки записи и проведения должны быть недоступны, а при попытке правки появится сообщение о нарушении прав доступа.
Ограничение доступа на уровне записей (RLS)
RLS (Record Level Security) позволяет ограничивать доступ не к виду документов целиком, а к конкретным записям по условию. Классический пример: менеджер видит и меняет документы только своей организации или своего склада, а чужие либо не видит, либо не может редактировать.
В типовых конфигурациях RLS включается флажком «Ограничивать доступ на уровне записей» в настройках пользователей и прав. Затем в профиле группы доступа на закладке «Ограничения доступа» задаются виды доступа (организации, склады, контрагенты, подразделения — состав зависит от конфигурации), а в группах доступа пользователей указываются разрешённые значения.
Учтите ограничения механизма. Во-первых, RLS заметно усложняет запросы к базе и может снизить производительность на больших объёмах данных. Во-вторых, набор видов доступа фиксирован конфигурацией: произвольное условие «по статусу документа» штатно не настроить. В-третьих, в некоторых конфигурациях RLS действует только в клиент-серверном варианте работы — уточните это в документации к вашей версии.
Сравнение вариантов
Подходит для закрытия периода. Простая настройка, но действует только по дате и не различает содержимое документов.
Подходят для режима «только чтение» по видам объектов. Гибко, но не различают записи внутри одного вида документов.
Подходит для разграничения по организациям, складам, подразделениям. Мощно, но влияет на производительность и ограничено предопределёнными видами доступа.
Подходят для любых нестандартных условий. Требуют доработки конфигурации или расширения и сопровождения кода.
Программный запрет через расширение конфигурации
Когда штатных механизмов недостаточно — например, нужно запретить изменение документа после его выгрузки в банк или после присвоения определённого статуса — используют подписку на событие «ПередЗаписью» или «ПриЗаписи». В обработчике проверяется условие, и при его выполнении вызывается отказ от записи.
Рекомендуемый способ реализации — расширение конфигурации, а не прямое изменение типового кода: тогда обновления конфигурации не будут конфликтовать с доработкой. Пример логики обработчика:
Процедура ЗапретИзмененияПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Если Не Источник.ЭтоНовый()
И Источник.Ссылка.Статус = Перечисления.СтатусыДокументов.Выгружен Тогда
Отказ = Истина;
ВызватьИсключение "Документ выгружен в банк. Изменение запрещено.";
КонецЕсли;
КонецПроцедуры
Обратите внимание на первую проверку: пропуск при загрузке через обмен данными обязателен, иначе запрет сломает синхронизацию между базами. Также продумайте исключения для служебных пользователей (например, под которыми работают регламентные задания) — иначе автоматические операции начнут завершаться ошибкой.
Программные запреты в подписках на события выполняются при любой записи объекта, включая фоновые задания и обмены. Перед внедрением протестируйте обработчик на копии базы: проверьте ручную запись, проведение, отмену проведения, групповое изменение реквизитов и обмен данными. Часто забывают именно про отмену проведения — она тоже является записью.
Проверка результата и типичные ошибки
Любую настройку запрета нужно проверять под учётной записью того пользователя, для которого она предназначена. Проверка под администратором бессмысленна: полные права обходят большинство ограничений, и вы увидите ложную картину «всё работает».
Как проверить результат
Документ открывается на просмотр, при попытке записи — сообщение о дате запрета
Документ свободно сохраняется и проводится
Проведение датой раньше даты запрета блокируется
Документ проводится задним числом без сообщений
Кнопки записи и проведения недоступны, правка невозможна
Пользователь может изменить и сохранить объект
Синхронизация и фоновые операции выполняются без ошибок
В журнале регистрации ошибки отказа в записи от служебных операций
Отдельно проверьте журнал регистрации после включения запретов: там видны отказы в доступе и ошибки записи. Если обмены или отчёты начали падать с ошибками прав — значит, запрет задел служебную операцию, и нужно либо скорректировать настройку, либо добавить исключение.
Частые вопросы
Почему пользователь всё равно может менять документы закрытого периода?
Наиболее вероятные причины: у пользователя есть полные права или роль администратора, для него индивидуально установлена более ранняя дата запрета на закладке «По пользователям», либо дата запрета вообще не включена (снят флажок «Даты запрета изменения данных»). Проверьте настройку и состав групп доступа пользователя.
Можно ли запретить изменение только одного справочника, например «Номенклатура»?
Да. Создайте профиль группы доступа, в котором для этого справочника оставлены только роли чтения, без ролей добавления и изменения. Включите нужных пользователей в группу с этим профилем и уберите у них другие профили, дающие право правки этого справочника.
Действует ли дата запрета на загрузку данных через обмен?
В типовых конфигурациях при загрузке через механизмы обмена данными проверка даты запрета обычно не выполняется — данные загружаются в режиме обмена. Это нужно учитывать: закрытый период может быть изменён через синхронизацию с другой базой, если там документ отредактировали.
Как временно открыть период для одной правки и не забыть закрыть обратно?
Безопасный порядок: зафиксируйте текущее значение даты запрета, установите индивидуальную дату только для себя на закладке «По пользователям» (не снимая общий запрет), внесите правку и сразу верните индивидуальную настройку. Не снимайте общий флажок даты запрета — так проще всего забыть восстановить защиту.
Что делать, если после включения RLS база стала работать медленно?
Сначала убедитесь, что включены только реально нужные виды доступа — каждый дополнительный вид усложняет запросы. Проверьте, нет ли у пользователей нескольких групп доступа с пересекающимися ограничениями. Если замедление критично, рассмотрите замену части ограничений на разделение по ролям или перенос особо тяжёлых отчётов на копию данных.
Можно ли запретить удаление документов, но разрешить их изменение?
Да, на уровне ролей права «Изменение» и «Удаление» разделены. В профиле оставьте роли, дающие изменение, но исключите роли с правом интерактивного удаления. Дополнительно в типовых конфигурациях есть настройка запрета пометки удаления документов определённого периода через дату запрета.
Что важно запомнить
Для закрытия периода используйте дату запрета изменения данных, для режима «только чтение» — профили групп доступа, для разграничения по организациям и складам — RLS, для нестандартных условий — расширение с подпиской ПередЗаписью. Всегда проверяйте настройку под обычным пользователем и контролируйте, что запреты не сломали обмены и регламентные задания.