Запрет изменения документов: даты запрета, права доступа и расширения

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

В 1С 8.3 для этого есть четыре независимых механизма: дата запрета изменения данных, права доступа через профили групп, режим «только чтение» формы и расширение конфигурации . Какой выбрать — зависит от того, что именно вы закрываете: период, пользователя или конкретный документ. Ниже — все четыре, с путями меню и порядком действий, плюс как потом снять запрет.

Дата запрета изменения: закрыть прошлый период для всех

Это самый быстрый способ и чаще всего нужен именно он: защитить уже сданный период от случайной правки. Во всех типовых конфигурациях на библиотеке стандартных подсистем (Бухгалтерия 3.0, ЗУП 3.1, Управление торговлей 11) путь одинаковый:

Администрирование → Настройки пользователей и прав → Даты запрета изменения.

Порядок действий:

1. Поставьте флажок Даты запрета изменения данных.
2. Нажмите ссылку Настроить рядом с флажком.
3. Выберите способ: общая дата для всех, по разделам учёта или по разделам и объектам.
4. Укажите дату. Запрет действует на всё, что датировано этим числом и раньше.

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

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

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

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

Отдельно существует Дата запрета загрузки данных — она блокирует изменение документов, которые приходят по обмену (из другой базы, из клиент-банка). Это не то же самое, что дата запрета изменения, и настраивается она рядом, своим флажком. В базах с распределёнными информационными базами (РИБ) или синхронизацией её тоже стоит выставить, иначе данные закрытого периода будут переписываться входящими сообщениями обмена.

Права доступа и профили групп: кто и что может менять

Дата запрета закрывает период для всех сразу. Если же нужно ограничить конкретного пользователя — чтобы кладовщик видел реализации, но не правил их, — это делается через права доступа.

В пользовательском режиме доступ выдаётся не ролями напрямую, а через профили групп доступа:

Администрирование → Настройки пользователей и прав → Профили групп доступа.

Профиль — это набор ролей. У каждой роли по каждому объекту (справочнику, документу) задан перечень прав: чтение, добавление, изменение, удаление, проведение, отмена проведения. Чтобы разрешить просмотр, но запретить правку, нужна роль, в которой по нужному документу есть Чтение и Просмотр, но нет Изменение и Интерактивное изменение.

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

• берут роль-основу (например, ту, что даёт просмотр);
• недостающие ограничения добавляют отдельной ролью, созданной в расширении (см. ниже), чтобы не снимать конфигурацию с поддержки;
• собирают из них профиль и назначают его группе доступа пользователя.

Полезно различать близкие права, потому что именно их путают:

• Изменение — программное изменение (в том числе при обмене и обработках). Убрав его, вы закрываете и запись из кода.
• Интерактивное изменение — правка руками через форму. Убрав только его, вы оставляете обмену возможность записывать документ, а пользователю — нет.
• Проведение и Отмена проведения — отдельные права. Можно разрешить открыть и подправить комментарий, но запретить перепроводить документ, если движения уже учтены.

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

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

Только чтение: документ видно, но изменить нельзя

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

Если у пользователя есть право на чтение, но нет интерактивного изменения по этому объекту, 1С открывает документ в режиме только для чтения автоматически: поля серые, провести и записать нельзя. Отдельную «кнопку только чтение» в пользовательском режиме искать не нужно — поведением управляют права.

Когда нужно открыть только для чтения не навсегда, а по условию (например, всем, кроме автора документа), это уже логика, и задаётся она в расширении через свойство формы ТолькоПросмотр. Разово, для одного сеанса, форму документа можно открыть на просмотр и из списка — но как постоянное ограничение это не работает , при следующем открытии документ снова будет доступен для правки.

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

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

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

Два рабочих приёма.

1. Блокировать запись документа. В модуле объекта документа расширением добавляют обработчик, который отменяет запись для всех, кроме полных прав:

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

Здесь РольДоступна проверяет роль текущего пользователя, а Отказ = Истина отменяет запись.

2. Открывать форму только для чтения. В модуле формы документа:

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

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

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

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

Клиент-серверная база: что меняется и чего делать нельзя

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

Чего в клиент-серверном варианте делать нельзя категорически — это пытаться запретить правку на уровне СУБД: ставить триггеры, отзывать права у таблиц SQL Server или PostgreSQL, менять данные напрямую запросами. Структуру базы ведёт платформа; прямое вмешательство в неё нарушает лицензионное соглашение, лишает базу поддержки и почти гарантированно приводит к рассинхронизации и порче данных.

Что администратор действительно может на уровне сервера:

• через консоль администрирования серверов посмотреть активные сеансы и, при необходимости, завершить чей-то сеанс;
• управлять назначением профилей и прав централизованно.

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

Снятие — это обратная операция к тому, чем вы запрещали. Разберитесь сначала, какой именно механизм сработал.

• Дата запрета изменения. Администрирование → Настройки пользователей и прав → Даты запрета изменения → снимите флажок или сдвиньте дату назад. Чтобы разово поправить закрытый документ, перенесите дату на день раньше его даты, внесите правку, верните дату обратно.
• Права доступа. Верните пользователю профиль с нужными правами или добавьте в его профиль право Интерактивное изменение / Проведение по этому объекту.
• Расширение. Администрирование → Печатные формы, отчёты и обработки → Расширения → снимите флажок у нужного расширения или удалите его, затем обновите конфигурацию базы данных.
• Только чтение по коду. Правится там же, где и задавалось, — в модуле формы расширения.

Если непонятно, почему документ не даёт себя записать, проверяйте по очереди: сначала дату запрета (самое частое), потом права пользователя, потом подключённые расширения.

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

Эти промахи встречаются чаще всего и к самим шагам не относятся — поэтому вынесены отдельно.

• 🔸 Сняли роль целиком вместо одного права. Пользователь теряет доступ и к просмотру. Нужно убирать конкретное право (изменение, проведение), а не всю роль.
• 🔸 Поставили дату запрета, но забыли про дату запрета загрузки. Документы из обмена продолжают переписываться. Для баз с обменом настраивайте обе даты.
• 🔸 Правили права прямо в типовой конфигурации. База ушла с поддержки, обновления встают тяжело. Любые изменения прав — только расширением.
• 🔸 Ждут, что дата запрета скроет документы. Она блокирует запись, но не видимость. Чтобы спрятать документы от пользователя, нужны права на чтение, а не дата.

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