Почему не работает новая роль в УТ 10.3 при проведении документов и как это исправить?

При работе со старыми конфигурациями, такими как «Управление торговлей 10.3», программисты часто сталкиваются с ситуацией, когда создание новой роли «с нуля» превращается в квест. Вроде бы все необходимые «галочки» в Конфигураторе проставлены, права на документы и регистры даны, но при попытке провести документ пользователь получает лаконичное сообщение: «Нарушение прав доступа». При этом Журнал регистрации не дает четкого ответа, на какой именно объект не хватило прав.

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

Причина 1: Забытые права на Последовательности

Проанализируем механику работы 1С:Предприятие 8 при проведении документов. В УТ 10.3 ключевым механизмом является партионный учет. Он опирается не только на РегистрыНакопления, но и на специальный объект метаданных — Последовательности. Рассмотрим подробнее, как это реализовано в Конфигураторе.

Когда вы открываете дерево метаданных в роли и ставите отметку на ветке «Документы», чтобы дать права на все объекты внутри, система помечает сами документы и их журналы. Однако Последовательности, которые физически находятся внутри ветки документов, часто игнорируются при массовом выделении. Это и есть главная ловушка.

Разберем по шагам, что нужно проверить:

1. Откройте вашу роль в Конфигураторе.
2. Перейдите к ветке Документы -> Последовательности.
3. Найдите последовательность ПартионныйУчет (в некоторых редакциях их может быть несколько, например, по БУ и УУ).
4. Убедитесь, что у роли стоят права на «Чтение» и «Запись».

Без права на «Запись» в последовательность система не сможет обновить границу партионного учета при проведении Реализации товаров и услуг. Поскольку запись в последовательность происходит в той же транзакции, что и движения по регистрам, отказ в правах на этот «незначительный» объект приводит к полной отмене проведения всего документа.

Причина 2: Хардкодинг ролей в программном коде

Выясним вторую вероятную причину. Конфигурация УТ 10.3 проектировалась в эпоху, когда многие проверки прав доступа выполнялись не через механизм RLS (Record Level Security), а путем прямого обращения к имени роли в коде. Проанализируем типичный пример кода, который можно встретить в общих модулях УправлениеПользователями или ПроцедурыУправленияТиповымиРешениями.

Система может содержать проверки вида:

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

Если вы создали абсолютно новую роль РеализацияПеремещения и не добавили её название в подобные проверки, стандартные механизмы УТ 10.3 просто «не узнают» вашего пользователя, даже если в метаданных разрешено всё. Посмотрим на список мест, где чаще всего прячутся такие проверки:

• Общий модуль УправлениеПользователями: функции проверки прав на редактирование цен и складов.
• Модули наборов записей критичных регистров (например, ПартииТоваровНаСкладах), где может проверяться право на ручную корректировку.
• Процедура ПередЗаписью или ОбработкаПроведения в модуле самого документа.

Причина 3: Права на служебные регистры и константы

Зачастую ошибка прав доступа возникает при обращении к вспомогательным данным. Рассмотрим ситуацию: документ успешно формирует движения, но в конце транзакции срабатывает подписка на событие, которая проверяет настройки пользователя. Если у роли нет права на «Чтение» регистра сведений НастройкиПользователей, система выдаст ошибку.

Проанализируем список объектов, права на которые должны быть у любой «рабочей» роли в УТ 10.3 (помимо основных документов):

• Регистры сведений: НастройкиПользователей, ПолномочияПользователей, ГраницыЗапретаИзмененияДанных.
• Константы: ИспользоватьПартионныйУчет, СпособОценкиМПЗ, ВалютаУправленческогоУчета.
• Справочники: Пользователи, Организации, Склады (как минимум на чтение).

Практические рекомендации по созданию ролей

Выяснив все тонкости, мы можем сформулировать наиболее эффективную стратегию создания ролей в УТ 10.3, чтобы не тратить часы на поиск недостающей «галочки»:

Способ 1: Копирование существующей роли
Это самый надежный метод. Если вам нужна роль для менеджера, возьмите типовую роль МенеджерПоПродажам, скопируйте её и затем аккуратно убирайте лишнее или добавляйте нужное. При копировании сохраняются все системные права на последовательности, константы и служебные регистры, о которых легко забыть при ручном создании.

Способ 2: Использование роли «Пользователь»
В УТ 10.3 роль Пользователь является базовой. Она содержит минимальный набор прав, необходимый для запуска сеанса и чтения основных справочников. Никогда не давайте пользователю только одну «самописную» роль — всегда комбинируйте её с ролью Пользователь.

Способ 3: Отладка под ограниченными правами
Если проблема сохраняется, воспользуйтесь методом замера производительности в отладчике. Рассмотрим, как это сделать:

1. Запустите сеанс под пользователем с проблемной ролью.
2. В Конфигураторе включите замер производительности.
3. Нажмите «Провести» в документе.
4. Остановите замер. В списке выполненных строк кода найдите последнюю перед возникновением ошибки. Обычно это будет либо метод Записать() набора записей регистра, либо обращение к функции проверки прав в общем модуле.

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

Для Каждого Роль Из Метаданные.Роли Цикл
    Если РольДоступна(Роль.Имя) Тогда
        Сообщить("Доступна роль: " + Роль.Имя);
    КонецЕсли;
КонецЦикла;

Резюме

В 90% случаев проблема «тихого» нарушения прав доступа в УТ 10.3 при проведении документов связана с отсутствием прав на Последовательность.ПартионныйУчет. В оставшихся 10% случаев виноваты программные проверки имен ролей в общих модулях. Следуя нашим рекомендациям и используя метод копирования типовых ролей, вы сможете избежать подобных ошибок и обеспечить корректную работу прав доступа в системе.