Многие разработчики 1С сталкиваются с ситуацией, когда разработанный отчет на Системе Компоновки Данных (СКД) прекрасно работает под полными правами (у администратора), но при запуске под пользователем с ограниченными правами часть полей исчезает из списка доступных полей или просто не выводится в результат. При этом ошибок доступа может не возникать — поля просто "испаряются".
Разберем детально причины этого поведения и способы решения проблемы, опираясь на коллективный опыт разработчиков.
Это самая распространенная и неочевидная причина. В системе прав доступа 1С существуют два независимых права, влияющих на отображение данных:
СКД перед формированием отчета анализирует права текущего пользователя. Если у пользователя есть право на Чтение регистра или справочника, но снята галочка Просмотр, СКД исключит поля этого объекта из списка доступных, чтобы пользователь их не увидел.
Решение:
В конфигураторе откройте роль пользователя и проверьте права на объекты, участвующие в запросе (регистры, справочники, документы). Убедитесь, что установлены обе галочки:
ЧтениеПросмотрТакже важно проверить права не только на сам объект (например, Регистр Накопления), но и на его реквизиты, измерения и ресурсы. Бывает так, что на сам регистр права есть, а на конкретное измерение право "Просмотр" снято.
Частая ошибка при проектировании запросов — обращение к реквизитам поля составного типа через точку. Классический пример — получение данных из поля Регистратор регистра накопления.
Пример проблемного кода в запросе:
ВЫБРАТЬ
ДокументыОплаты.Регистратор.СуммаДокумента
ИЗ
...
В этом случае поле Регистратор может содержать ссылки на множество типов документов (ПКО, РКО, Списание с расчетного счета и т.д.). Если у пользователя нет прав на Чтение хотя бы одного из типов документов, которые могут быть регистраторами (даже если в текущей выборке их нет), платформа может полностью закрыть доступ к этому полю в целях безопасности (механизм RLS и проверки прав).
Решение №1: Использование конструкции ВЫРАЗИТЬ
Мы должны явно указать системе, какой тип данных мы ожидаем, чтобы проверка прав шла только по этому типу. Используйте конструкцию ВЫРАЗИТЬ для приведения типов:
ВЫБРАТЬ
ВЫРАЗИТЬ(ДокументыОплаты.Регистратор КАК Документ.ПлатежноеПоручениеВходящее).СуммаДокумента КАК СуммаПлатежки,
ВЫРАЗИТЬ(ДокументыОплаты.Регистратор КАК Документ.ПриходныйКассовыйОрдер).СуммаДокумента КАК СуммаПКО
...
Это подскажет платформе, что право доступа нужно проверять конкретно к документу ПлатежноеПоручениеВходящее, а не ко всем возможным регистраторам.
Решение №2: Получение данных из ресурсов регистра
Архитектурно более правильный подход — не "тянуть" данные из документа-регистратора через точку (это вызывает неявное соединение с таблицей документа), а брать данные непосредственно из ресурсов регистра накопления, если они там дублируются.
Вместо:
Взаиморасчеты.Регистратор.СуммаДокумента
Используйте:
Взаиморасчеты.СуммаВзаиморасчетов
(или соответствующий ресурс, хранящий сумму).
Похожая проблема возникает при обращении к реквизитам справочников через точку. Например, мы хотим получить "Организацию" из аналитики:
ВЫБРАТЬ
КлючиАналитики.Организация
ИЗ
Справочник.КлючиАналитикиУчетаПоПартнерам КАК КлючиАналитики
Если у пользователя нет прав на просмотр самого справочника КлючиАналитикиУчетаПоПартнерам (или его реквизита "Организация"), поле будет недоступно, даже если права на справочник Организации есть.
Решение: Явное соединение
Замените неявное обращение через точку на левое соединение с нужным справочником. Это часто решает проблему видимости, так как мы обращаемся к таблице, на которую у пользователя точно есть права.
ВЫБРАТЬ
Организации.Ссылка КАК Организация
ИЗ
Справочник.КлючиАналитикиУчетаПоПартнерам КАК КлючиАналитики
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Организации КАК Организации
ПО КлючиАналитики.Организация = Организации.Ссылка
В современных конфигурациях (ERP, КА, УТ 11) широко используются Функциональные опции. Если в базе отключена какая-то функциональность (например, "Использовать заказы поставщикам"), то все реквизиты и объекты, привязанные к этой опции, становятся невидимыми для системы компоновки данных.
Иногда при обновлении или переносе кода из БСП (Библиотеки Стандартных Подсистем) разработчики забывают включить нужные константы, управляющие функциональными опциями.
Диагностика:
ФункциональныеОпции.Бывают ситуации, когда права настроены корректно, но отчет все равно не работает из-за кэширования.
Важный нюанс работы RLS (ограничения доступа на уровне записей) и СКД: если в запросе используется поле только для соединения или фильтрации, но пользователь не имеет прав на чтение этого поля, весь запрос может "посыпаться" или вернуть пустые данные по связанным полям.
Если вы используете виртуальные таблицы (например, Остатки), убедитесь, что у пользователя есть права на просмотр всех измерений регистра, даже если вы не выводите их в отчет. СКД строит запрос к виртуальной таблице, используя все её измерения.
Если поле пропадает в СКД под пользователем, выполните следующие шаги:
Регистратор), убедитесь, что у пользователя есть права на чтение всех возможных типов документов, входящих в этот тип. Если нет — используйте ВЫРАЗИТЬ.ЛЕВОЕ СОЕДИНЕНИЕ вместо Документ.Контрагент.Менеджер.