В практике администрирования 1С:Управление производственным предприятием (УПП 1.3) часто встречается парадоксальная ситуация: пользователю запрещено изменять проведенные документы, отраженные в бухгалтерском (БУ) и налоговом (НУ) учете, однако он беспрепятственно может пометить такой документ на удаление. В результате пометки удаления документ автоматически отменяет свои движения по регистрам, что фактически является «обходом» запрета на отмену проведения. Разберем подробно, почему так происходит, и как правильно настроить систему, чтобы закрыть эту лазейку.
Рассмотрим фундаментальное устройство системы прав доступа 1С:Предприятие. В метаданных любого документа существуют два отдельных права:
ПометкаУдаления.Проблема заключается в том, что пометка удаления — это комплексная операция. Если документ на момент установки пометки был проведен, платформа 1С принудительно запускает механизм отмены проведения. Это сделано для обеспечения целостности данных: помеченный на удаление объект не должен влиять на итоги в регистрах. При этом проверка права «Интерактивная отмена проведения» в этот момент не выполняется, так как инициировано другое действие. Таким образом, право на пометку удаления функционально оказывается «сильнее» и поглощает запрет на отмену проведения.
Проанализируем ситуацию в контексте конфигурации УПП 1.3. В этой системе права часто настраиваются не только через роли, но и через интерфейс «Дополнительные права пользователей» (меню Сервис — Пользователи). Там можно найти настройки:
Выясним причину, почему эти настройки не всегда срабатывают при пометке удаления. Программные проверки в типовых документах УПП обычно сосредоточены в процедуре ПередЗаписью модуля объекта. Проверка часто выглядит упрощенно:
Если РежимЗаписи = РежимЗаписиДокумента.ОтменаПроведения Тогда
// Проверка прав на отмену проведения
КонецЕсли;
Когда пользователь выбирает «Установить пометку удаления», РежимЗаписи принимает значение Запись, а свойство объекта ПометкаУдаления становится Истина. Если разработчик конфигурации не предусмотрел в коде отдельную проверку на изменение пометки удаления для документов с установленными флагами ОтражатьВБухгалтерскомУчете или ОтражатьВНалоговомУчете, то система пропускает транзакцию, считая её просто «записью» объекта.
Если мы хотим гарантированно запретить пользователям снимать движения с учетных документов через пометку удаления, нам необходимо внедрить проверку в модуле документа или, что более правильно, в общей подписке на событие ПередЗаписью. Посмотрим на пример кода, который может решить задачу:
Процедура ПроверитьПравоНаПометкуУдаления(Источник, Отказ, ТекущийРежимЗаписи) Экспорт
// Проверяем, что это не новый документ и он уже проведен
Если Источник.ЭтоНовый() Тогда
Возврат;
КонецЕсли;
// Считываем старое состояние из базы данных для сравнения
СтароеСостояние = ОбщегоНазначения.ЗначенияРеквизитовОбъекта(Источник.Ссылка, "Проведен, ПометкаУдаления, ОтражатьВБухгалтерскомУчете");
// Если документ был проведен и отражен в БУ, а сейчас ставится пометка удаления
Если СтароеСостояние.Проведен И Источник.ПометкаУдаления И НЕ СтароеСостояние.ПометкаУдаления Тогда
Если СтароеСостояние.ОтражатьВБухгалтерскомУчете Тогда
// Здесь проверяем наличие специфической роли или настройки
Если НЕ РольДоступна("ПолныеПрава") Тогда
Сообщить("У вас недостаточно прав для пометки на удаление документа, отраженного в учете!");
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Использование ОбщегоНазначения.ЗначенияРеквизитовОбъекта позволяет нам увидеть состояние документа до записи и понять, что именно сейчас происходит попытка удаления уже отраженного в учете факта хозяйственной деятельности.
Проанализируем ситуацию с точки зрения ограничений доступа на уровне записей. В УПП активно используется RLS для разделения доступа по организациям или подразделениям. Часто в шаблонах ограничений для операции «Изменение» прописываются строгие условия, но для операции «Удаление» (к которой относится пометка удаления) условия могут быть более мягкими или отсутствовать вовсе.
Важно помнить: если пользователь имеет право на «Изменение» объекта, он может изменить реквизит ПометкаУдаления. Чтобы предотвратить это через RLS, необходимо в тексте запроса ограничения доступа добавить условие на проверку значений ОтражатьВБухгалтерскомУчете = Ложь или аналогичных флагов при попытке записи. Однако это значительно усложняет поддержку ролей и может замедлить работу системы.
Выясним еще один важный технический момент. В 1С существует стандарт разработки: движения документа должны записываться и удаляться в привилегированном режиме. Это делается для того, чтобы пользователю не нужно было давать прямые права на запись в регистры бухгалтерии (например, «Хозрасчетный»).
Поскольку очистка движений при пометке удаления происходит «от имени системы», проверка прав на сами регистры не срабатывает. Система проверяет только право на сам Регистратор (документ). Поэтому единственный способ контроля — это жесткое ограничение прав на сам документ в состоянии «Проведен».
Подводя итог, можно выделить три способа решения проблемы, от простого к сложному:
ПередЗаписьюДокумента, в которой программно проверять: если документ проведен, имеет флаги БУ/НУ и устанавливается ПометкаУдаления = Истина — выдавать Отказ = Истина.Рассмотренная ситуация — это не «баг» конкретного релиза 154.1, а особенность взаимодействия прав платформы и логики типовых конфигураций на обычных формах. Понимая этот механизм, вы сможете обеспечить надежную защиту данных в вашей базе 1С.