Как ограничить права на проведение расходных накладных в 1С без снятия с поддержки

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

Принцип сложения прав в 1С: почему "запрещающие" роли не существуют

Прежде всего, проанализируем фундаментальный механизм системы 1С. Права доступа в платформе работают по принципу сложения (логическое ИЛИ). Если пользователю назначено несколько ролей, и хотя бы в одной из них разрешено действие Проведение, то система позволит провести документ, независимо от того, что указано в других ролях.

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

Способ 1. Использование расширений конфигурации (рекомендуемый метод)

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

Выполним следующие шаги:

1. Создадим новое расширение в конфигураторе.
2. Добавим в расширение документ РасходнаяНакладная.
3. Создадим в расширении процедуру-обработчик события ПередЗаписью для модуля объекта документа.

Проанализируем пример кода, который нужно разместить в расширении:

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

КонецПроцедуры

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

Способ 2. Редактирование профилей групп доступа и анализ ролей

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

Рассмотрим по шагам процесс анализа:

1. Откроем отчет "Анализ прав доступа" (доступен в разделе Администрирование - Настройки пользователей и прав).
2. Выберем интересующего нас пользователя и объект (Документ Расходная накладная).
3. Система сформирует дерево ролей. Нам нужно найти ветку Проведение.
4. Посмотрим, какие именно роли (например, ДобавлениеИзменениеРасходныхНакладных) предоставляют это право.

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

1. Создадим копию стандартного профиля.
2. В списке ролей найдем ту, что дает право проведения.
3. Если эта роль отвечает только за проведение, снимем флажок. Если же роль "смешанная" (дает и чтение, и изменение, и проведение), то без создания новой роли в конфигураторе или использования расширения обойтись не получится.

Способ 3. Создание собственной роли в расширении

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

Посмотрим на алгоритм действий:

1. В расширении создаем новую роль, назовем ее ТолькоПросмотрИСозданиеРасходных.
2. Настраиваем права для документа РасходнаяНакладная: устанавливаем галочки на Чтение, Просмотр, Добавление, Изменение, но не отмечаем Проведение и Отмена проведения.
3. В пользовательском режиме (в интерфейсе "1С:Предприятие") создаем новый профиль групп доступа, куда включаем эту новую роль из расширения.
4. Назначаем этот профиль продавцу вместо стандартного профиля, дающего право на проведение.

Важные замечания по сопровождению

Автор темы на форуме выбрал путь снятия "замка" с метаданных документа. Это крайне не рекомендуется, так как при следующем обновлении конфигурации изменения в правах могут быть затерты или привести к конфликтам при объединении.

Использование расширений позволяет:

• Видеть все свои доработки в одном окне.
• Не мешать процессу автоматического обновления через конфигуратор.
• Быстро отключать ограничения в случае необходимости, просто деактивировав расширение.

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