Почему возникает ошибка доступа при чтении реквизитов контрагента в УТ 11 и как это исправить?

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

Анализ стека вызова и контекста ошибки

Первым делом проанализируем ситуацию на примере вызова из модуля СПАРКРиски. Ошибка часто возникает при открытии формы документа (например, Заказа клиента), когда система пытается получить значение реквизита ЮрФизЛицо справочника Контрагенты. Стек ошибки указывает на то, что сбой происходит в момент выполнения запроса внутри функции БСП:

Ошибка при вызове метода контекста (Выполнить)
{ОбщийМодуль.ОбщегоНазначения.Модуль(617)}: Выборка = Запрос.Выполнить.Выбрать;
{ОбщийМодуль.ОбщегоНазначения.Модуль(306)}: ЗначенияРеквизитовОбъекта = ЗначенияРеквизитовОбъектов(...);

Разберем, почему это происходит. Метод ЗначениеРеквизитаОбъекта по умолчанию выполняет запрос к базе данных без использования конструкции РАЗРЕШЕННЫЕ. Если на справочник наложены ограничения RLS (Record Level Security), и конкретная запись, на которую ссылается переменная, не проходит по условиям ограничения, платформа 1С выдает критическую ошибку доступа вместо возврата пустого значения.

Скрытая связь справочников «Контрагенты» и «Партнеры»

Выясним причину, по которой RLS может блокировать доступ, даже если в конфигураторе на справочнике Контрагенты не задано явных ограничений. В УТ 11 реализована тесная интеграция между партнерами и контрагентами. Посмотрим на логику работы прав доступа в этой системе:

1. Группы доступа партнеров: Основное ограничение прав на контрагентов в УТ 11 обычно настраивается через Партнеров. Если у пользователя ограничены права по группам доступа партнеров, то доступ к контрагенту будет ограничен автоматически через его владельца (поле Партнер).
2. Независимое ведение: Даже если в настройках системы включена опция «Независимо вести партнеров и контрагентов», механизмы БСП при проверке прав могут неявно обращаться к связанным таблицам партнеров.
3. Справочник «Физические лица»: Если реквизит ЮрФизЛицо имеет значение ФизЛицо, система может дополнительно проверять права на чтение справочника ФизическиеЛица. Проанализируем, есть ли у пользователя права на этот справочник, так как отсутствие прав на связанный объект часто приводит к «падению» запроса при чтении реквизитов.

Использование параметра «ВыбратьРазрешенные»

Одним из быстрых способов избежать аварийного завершения работы является использование расширенного набора параметров метода ЗначениеРеквизитаОбъекта. Рассмотрим пример кода:

// Вместо стандартного вызова:
// Результат = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "ЮрФизЛицо");

// Используем вызов с флагом ВыбратьРазрешенные:
Результат = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, "ЮрФизЛицо", Истина);

При передаче параметра ВыбратьРазрешенные = Истина, запрос внутри общего модуля будет выполнен с ключевым словом РАЗРЕШЕННЫЕ. В этом случае, если RLS запрещает доступ к объекту, система не выдаст ошибку, а просто вернет Неопределено. Это позволит коду продолжить работу, хотя проблему с отсутствием доступа к данным это не решит.

Проблема «Производительного RLS» и ключей доступа

В современных версиях платформы 8.3 и конфигурации УТ 11.5 используется механизм производительного ограничения доступа. В этом режиме условия RLS не вычисляются «на лету» при каждом запросе, а хранятся в виде готовых ключей в специальных регистрах сведений (например, КлючиДоступаКОбъектам).

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

• В конфигураторе права настроены верно.
• В режиме «1С:Предприятие» в профиле пользователя все галки стоят.
• Но физическая таблица ключей не содержит записи для данного пользователя и данного контрагента.

Решение: необходимо запустить регламентное задание «Обновление ключей доступа» или воспользоваться обработкой «Управление доступом» в разделе Администрирование, чтобы принудительно обновить данные в регистрах доступа.

Диагностика через Технологический журнал и отчеты

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

1. Отчет по правам доступа: В типовых решениях на БСП есть встроенный отчет «Права доступа». Сформируйте его по конкретному пользователю и справочнику Контрагенты. Он покажет не только роли, но и действующие ограничения RLS.
2. Технологический журнал (ТЖ): Это самый надежный способ. Настройте сбор событий DBMSSQL (или DBORACLE/DBPOSTGRS) с фильтром по тексту Нарушение прав доступа. В логах ТЖ вы увидите реальный SQL-запрос, который отправляет платформа. Проанализируйте секцию WHERE — там будет четко видно, к какой именно таблице (партнеры, группы доступа, физические лица) добавляется ограничение, вызывающее отказ.
3. Журнал регистрации: Хотя автор темы отметил, что журнал не дает детальной информации по RLS, важно убедиться, что там зафиксирован сам факт отказа (событие «Доступ.Отказ»). Если отказа в журнале нет, проблема может быть не в RLS, а в функциональных опциях, которые скрывают реквизит на уровне платформы.

Механизм «СПАРК Риски»

Поскольку в сообщении ошибка возникает в контексте СПАРКРиски.ПриСозданииНаСервере, важно учитывать особенности этого модуля. Данный механизм обращается к собственным регистрам. Если у пользователя есть права на справочник Контрагенты, но отсутствуют права на чтение регистров сведений ИндексыСПАРКРиски или СобытияМониторингаСПАРКРиски, запрос может завершиться ошибкой доступа, если эти данные соединяются в одном запросе с основными реквизитами контрагента.

Проверьте наличие ролей, связанных с использованием сервиса 1С:СПАРК Риски, и добавьте их пользователю для тестирования.

Итоговые рекомендации

Для исправления ошибки доступа при чтении реквизитов в УТ 11 выполните следующие шаги:

1. Убедитесь, что у пользователя есть права на справочник Партнеры и Физические лица.
2. Проверьте, включено ли ограничение по группам доступа партнеров и входит ли партнер данного контрагента в разрешенную группу.
3. Обновите ключи доступа через раздел Обслуживание — Управление доступом.
4. При программном чтении используйте ОбщегоНазначения.ЗначениеРеквизитаОбъекта(..., ..., Истина) для безопасного получения данных.
5. Если проблема сохраняется, используйте Технологический журнал для анализа SQL-запроса и поиска скрытых соединений с таблицами, на которые не хватает прав.