Как исправить ошибку RLS «Поле не найдено ТекущаяТаблица.Ссылка.ВидОперации» в 1С?

Настройка ограничений доступа на уровне записей (Record Level Security, RLS) в платформе «1С:Предприятие 8» — мощный инструмент, требующий от разработчика глубокого понимания механизмов работы базы данных. Часто при написании универсальных шаблонов RLS возникает ошибка: «Поле не найдено <ТекущаяТаблица.Ссылка.ВидОперации>». Она проявляется при попытке открыть динамический список документов, для которых данное ограничение настроено, хотя логически код написан так, что обращение к этому полю происходить не должно. В этой статье мы подробно разберем причины этой ошибки и рассмотрим эффективные методы её устранения.

Почему возникает ошибка «Поле не найдено» в условиях RLS?

Проанализируем исходную ситуацию. Разработчик создает шаблон RLS, содержащий логическую ветку ВЫБОР КОГДА ... ТОГДА ... ИНАЧЕ ... КОНЕЦ. В этом шаблоне первой веткой идет проверка типа документа:

ВЫБОР
    КОГДА ТИПЗНАЧЕНИЯ(ТекущаяТаблица.Ссылка) = ТИП(Документ.ВнутреннееПеремещениеНаличныхДенежныхСредств)
         ИЛИ ТИПЗНАЧЕНИЯ(ТекущаяТаблица.Ссылка) = ТИП(Документ.ДенежныйЧек)
         ТОГДА ИСТИНА
    ИНАЧЕ НЕ ТекущаяТаблица.Ссылка.ВидОперации В (...)
КОНЕЦ

Логика разработчика понятна: если тип текущего документа равен ВнутреннееПеремещениеНаличныхДенежныхСредств, система должна сразу вернуть ИСТИНА и не переходить к ветке ИНАЧЕ, где проверяется реквизит ВидОперации (которого у этого документа физически нет). Однако на уровне СУБД эта логика не работает. Выясним причину этого поведения.

Когда пользователь открывает список документов или выполняет запрос к базе данных, платформа 1С производит компиляцию запроса RLS:

1. Платформа берет текст шаблона RLS и транслирует его в чистый SQL-запрос для СУБД применительно к конкретной таблице (в нашем случае — к таблице документа ВнутреннееПеремещениеНаличныхДенежныхСредств).
2. Перед отправкой запроса СУБД, синтаксический анализатор платформы 1С проверяет все поля, упомянутые в тексте шаблона, на предмет их физического существования в метаданных выбранного объекта.
3. Поскольку у документа ВнутреннееПеремещениеНаличныхДенежныхСредств реквизит ВидОперации отсутствует в метаданных, транслятор запроса падает с синтаксической ошибкой СУБД. Тот факт, что логически выполнение не должно дойти до ветки ИНАЧЕ, платформой на этапе проверки схемы метаданных полностью игнорируется.

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

---

Способы решения проблемы с реквизитами в шаблонах RLS

Рассмотрим несколько эффективных подходов для обхода этой ошибки, от классической параметризации шаблонов до современных стандартов разработки 1С.

Вариант 1. Параметризация шаблона ограничений (Рекомендуемый классический метод)

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

Шаг 1. Объявим в свойствах роли на вкладке «Шаблоны ограничений» новый шаблон с параметром, например: #ОграничениеПоВидуОперации(ИмяПоляВидаОперации).

Шаг 2. В тексте шаблона пропишем универсальный запрос:

ТекущаяТаблица
ИЗ
    #ТекущаяТаблица КАК ТекущаяТаблица
ГДЕ
    #Параметр(1) В (ЗНАЧЕНИЕ(Перечисление.ВидыОперацийСписаниеБезналичныхДенежныхСредств.ПеречислениеЗП), ЗНАЧЕНИЕ(Перечисление.ВидыОперацийППИсходящее.ПеречислениеЗП))

Шаг 3. При назначении ограничения RLS на конкретные документы будем передавать в качестве параметра нужные значения:

• Для документов, имеющих реквизит ВидОперации (например, СписаниеБезналичныхДенежныхСредств), укажем ограничение:
  #ОграничениеПоВидуОперации("ТекущаяТаблица.ВидОперации")
• Для документов, у которых нет этого реквизита (например, ВнутреннееПеремещениеНаличныхДенежныхСредств), передадим безопасную заглушку, которая не вызовет ошибку компиляции:
  #ОграничениеПоВидуОперации("NULL") или #ОграничениеПоВидуОперации("НЕОПРЕДЕЛЕНО")

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

Вариант 2. Разделение ограничений доступа

Посмотрим на ситуацию с точки зрения архитектуры прав доступа. Если документы принципиально отличаются по своей структуре и бизнес-логике, не стоит пытаться объединить их в рамках одного сложного шаблона RLS.

Разделим ограничения на логические группы:

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

Вариант 3. Использование БСП и производительного режима RLS

Если ваша конфигурация построена на базе «Библиотеки стандартных подсистем» (БСП), ручное написание сложных SQL-подобных запросов в ролях считается устаревшей практикой. В БСП внедрен производительный режим RLS, основанный на механизме «Ключей доступа».

При таком подходе:

1. Вся логика ограничений описывается на встроенном языке 1С в модуле менеджера объекта в процедуре ПриЗаполненииОграниченияДоступа.
2. Платформа автоматически рассчитывает права доступа при записи документов и заносит информацию в специальные регистры сведений (например, КлючиДоступаКОбъектам).
3. При чтении данных система делает быстрое соединение с регистром ключей доступа. Это полностью исключает возникновение синтаксических ошибок СУБД из-за отсутствия реквизитов в конкретных таблицах.

---

Дополнительная задача: Как ограничить Физических лиц, оставив доступ к Сотрудникам?

Разберем еще один частый вопрос, связанный с RLS: как скрыть от пользователя персональные данные физических лиц (чтобы вместо ФЛ отображалось <Объект не найден>), но при этом позволить ему полноценно просматривать и открывать элементы справочника Сотрудники?

Если просто закрыть на чтение справочник ФизическиеЛица, то при попытке открыть форму сотрудника система выдаст ошибку «Недостаточно прав!». Это происходит потому, что форма сотрудника или код конфигурации при открытии пытается неявно прочитать данные связанного физлица (ФИО, ИНН, паспортные данные).

Для решения этой задачи применим комплексный подход:

1. Настройка RLS по полям (Разделение полей).

   Вместо полного запрета на чтение справочника ФизическиеЛица, настроим ограничение на уровне полей в роли:

   • Разрешим чтение полей Ссылка, ВерсияДанных, ПометкаУдаления, Предопределенный и Наименование без ограничений. Это позволит платформе без ошибок открывать формы сотрудников и отображать текстовое представление физлица.
   • Наложим строгое ограничение (например, условие ГДЕ ЛОЖЬ) на все остальные конфиденциальные поля: ИНН, СНИЛС, паспортные данные, контактную информацию. При попытке прочесть эти поля пользователь увидит пустые значения, но ссылочная целостность интерфейса не нарушится.
2. Использование привилегированного режима на сервере.

   Если для работы формы сотрудника критически важно выводить закрытые данные физического лица (например, для внутренних алгоритмов валидации), получение этих данных нужно выполнять на сервере в привилегированных общих модулях, где RLS временно отключается:

   Скопировать код

   
   УстановитьПривилегированныйРежим(ИСТИНА);
   // Выполняем чтение необходимых данных физлица
   УстановитьПривилегированныйРежим(ЛОЖЬ);
   

3. Перехват открытия формы.

   В обработчике события ПриСозданииНаСервере формы справочника Сотрудники заменим стандартные ссылочные поля физлиц на обычные текстовые реквизиты, заполняя их безопасным образом на сервере в обход RLS.

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