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

← На главную

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

В этой статье мы подробно рассмотрим несколько эффективных способов решения этой задачи — от настройки штатных механизмов до использования современных возможностей платформы 1С:Предприятие 8.3.

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

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

Рассмотрим ключевые преимущества этого подхода, которые часто упускают из виду:

Динамические (относительные) даты запрета: Вместо ручной установки фиксированной даты (например, последнего числа прошлого месяца), мы можем настроить автоматический сдвиг. Платформа позволяет выбрать относительные значения: «Конец прошлого месяца», «Конец предыдущей недели» или «Предыдущий день». Система будет самостоятельно сдвигать границу запрета без участия администратора.
Гибкая детализация: Мы можем установить запрет не для всех пользователей сразу, а настроить его индивидуально. Например, разрешить редактирование документов прошлого периода только сотрудникам бухгалтерии или конкретному пользователю (главному бухгалтеру), заблокировав эту возможность для менеджеров. Также доступна детализация по объектам (организациям, складам и т.д.).
Режим «Защита от случайных изменений»: Этот режим временно блокирует изменение данных ранее определенной даты для всех пользователей, создавая дополнительный барьер для случайного перепроведения.
Статусы документов (в ERP-решениях): Для крупных систем доступен механизм контроля статусов. Когда документ проверен, ему присваивается статус Проверен. После этого любые изменения блокируются на уровне бизнес-логики конфигурации, а право на изменение статуса обратно на В работе предоставляется только выделенным ролям.

Способ 2. Блокировка на уровне формы через расширение (Режим «Только просмотр»)

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

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

Создаем новое расширение в базе данных.
Захватываем форму нужного документа в расширение.
Добавляем обработчик события формы ПриСозданииНаСервере в режиме «После».

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


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

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

Способ 3. Использование подписок на события в расширении

Начиная с версий платформы 1С:Предприятие 8.3.15 / 8.3.17, разработчики получили возможность создавать собственные подписки на события непосредственно внутри расширений. Это самый надежный способ блокировки, так как он работает на уровне СУБД (в транзакции записи) и предотвращает изменения, даже если документ пытаются перезаписать программно (например, через внешнюю обработку или интеграцию).

Выясним, как реализовать этот алгоритм:

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

Рассмотрим пример кода обработчика подписки:


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

Важный нюанс: Использование функции ОбщегоНазначения.ЗначениеРеквизитаОбъекта позволяет быстро получить состояние флага проведения напрямую из базы данных, не считывая весь объект целиком, что положительно сказывается на производительности системы.

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

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

Выясним особенности реализации данного метода:

Добавляем в расширение новую или существующую роль пользователя.
Для требуемого документа ограничиваем право Изменение.
Прописываем шаблон ограничения (RLS). Условие должно проверять статус проведения документа. На уровне запроса это выглядит следующим образом:

ГДЕ НЕ Таблица.Проведен

Осторожно! Использование RLS требует тщательного тестирования. При записи нового документа или при самом процессе проведения система меняет статус поля Проведен с Ложь на Истина. Некорректно настроенное правило RLS может заблокировать проведение новых документов самим же автором. Также стоит учитывать, что RLS накладывает дополнительную нагрузку на СУБД при массовой обработке данных.

Резюме

Мы детально разобрали четыре подхода к решению проблемы редактирования проведенных документов. Для простых случаев и оперативного решения идеально подойдет Способ 1 (Дата запрета). Если же вам требуется гибкий программный контроль без снятия с поддержки, мы рекомендуем комбинировать Способ 2 (Блокировка интерфейса формы) для удобства пользователей и Способ 3 (Подписка на событие ПередЗаписью) для гарантированной защиты данных на уровне платформы.