← На главную

При настройке прав доступа в типовых конфигурациях 1С, таких как «Управление торговлей» (УТ 11), администраторы часто сталкиваются с ситуацией, когда под полными правами («Администратор») все функции работают штатно, а у пользователя с ограниченным набором ролей возникают критические ошибки. При этом тексты ошибок могут казаться не связанными с той операцией, которую пытается выполнить пользователь.

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

Анализ нетипичных ошибок прав доступа

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

1. Ошибка в запросе при оформлении возврата:
   при попытке провести документ «Возврат товаров от клиента» на основании чека ККМ система выдает сообщение:
   Скопировать код

   
   {(28,83)}: Поле не найдено "ТаблицаДокумента.Заказ.ОрганизацияПолучатель"
   ТаблицаДокумента.Заказ.Организация НЕ В (&Организация) И ТаблицаДокумента.Заказ<<?>>ОрганизацияПолучатель НЕ В (&Организация)
   

2. Ошибка при открытии списка документов:
   при переходе в раздел «Продажи — Розничные продажи — Чеки ККМ» возникает ошибка вида: Поле объекта не обнаружено (КассоваяСмена) при этом если зайти в этот же журнал через «Продажи — См. также — Чеки ККМ продажи», список открывается корректно.

Почему возникают подобные ошибки?

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

1. Разыменование составных типов данных в RLS и запросах

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

При выполнении запроса или при обработке механизмов RLS (ограничение прав на уровне записей) система обращается к свойству через точку: ТаблицаДокумента.Заказ.ОрганизацияПолучатель. В этот момент платформа неявно формирует соединение со всеми таблицами документов, входящих в составной тип этого реквизита. Если у пользователя отсутствует право на чтение хотя бы одного из документов этого списка (в данном случае документа «Передача товаров между организациями»), платформа полностью исключает соответствующее поле из схемы запроса. В результате запрос завершается ошибкой «Поле не найдено».

2. Обращение к реквизитам в формах и динамических списках

Ошибка Поле объекта не обнаружено (КассоваяСмена) возникает из-за того, что стандартная форма динамического списка обращается к колонкам и связанным объектам (например, к кассовым сменам или подарочным сертификатам). Если у пользователя нет права на просмотр одного из вспомогательных объектов, динамический список не может инициализировать поля формы.

Решение проблем: назначение недостающих ролей

Для устранения описанных ошибок в 1С:Управление торговлей 11 необходимо добавить пользователю следующие роли:

1. Для исправления ошибки Поле не найдено "ТаблицаДокумента.Заказ.ОрганизацияПолучатель" назначьте роль:
   «Чтение документов передачи товаров между организациями» (ЧтениеДокументовПередачиТоваровМеждуОрганизациями).
   Это предоставит платформе право читать структуру метаданных документа передачи при разыменовании составного поля Заказ.
2. Для исправления ошибки Поле объекта не обнаружено (КассоваяСмена) в списке чеков ККМ назначьте роль:
   «Добавление и изменение реализаций и возвратов подарочных сертификатов» (ДобавлениеИзменениеРеализацийВозвратовПодарочныхСертификатов).
   Это откроет доступ к реквизитам и обработчикам, используемым в основной форме списка розничных продаж.

Методика поиска отсутствующих прав

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

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

Для разработчиков при написании собственных запросов рекомендуется явно ограничивать составные типы с помощью конструкции ВЫРАЗИТЬ. Например:

ВЫРАЗИТЬ(ТаблицаДокумента.Заказ КАК Документ.ЗаказКлиента).Организация

Использование ВЫРАЗИТЬ предотвращает неявное соединение со всеми таблицами составного типа и исключает подобные ошибки прав доступа.