Как запретить изменение документов после их проведения в 1С?

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

Способ 1. Настройка стандартных прав доступа в ролях

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

В конфигураторе для каждого объекта метаданных типа Документ в составе роли предусмотрены специализированные флаги прав:

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

Проанализируем нюансы этого подхода:

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

Способ 2. Использование механизма «Даты запрета изменения данных»

В типовых конфигурациях (включая 1С:Бухгалтерию предприятия 3.0 на базе БСП) реализован гибкий механизм контроля периода редактирования. Посмотрим, как применить его для ограничения корректировок:

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

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

Способ 3. Ограничение на уровне записей (RLS)

Если требуется жестко запретить изменение любых проведенных документов в базе (в том числе при программных вызовах и обработках), используем механизм RLS (Record Level Security).

Разберем логику настройки условия ограничения для права Изменение в пользовательской роли:

1. В конфигураторе открываем нужную роль и переходим к объекту Документ.
2. Для права Изменение добавляем шаблон или условие ограничения доступа.
3. Условие разрешает запись только при условии: ГДЕ Проведен = ЛОЖЬ.

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

Способ 4. Программный контроль через подписку на событие

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

Посмотрим на пример обработчика подписки на событие:

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

Способ 5. Оптимизация интерфейса формы (UX)

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

В процедуре ПриЧтенииНаСервере или ПриСозданииНаСервере модуля формы пропишем блокировку элементов управления:

&НаСервере
Процедура ПриЧтенииНаСервереПосле(ТекущийОбъект)
    
    Если Объект.Проведен И Не РольДоступна("ПравоРедактированияПроведенных") Тогда
        ЭтаФорма.ТолькоПросмотр = Истина;
    КонецЕсли;
    
КонецПроцедуры

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