В практике администраторов и программистов 1С часто встречается коварная ситуация: пользователь с ролью «Кадровик» не может провести документ (например, Больничный лист), получая сообщение о недостаточности прав доступа. При этом стандартные настройки профилей групп доступа проверены многократно, ограничения на уровне записей (RLS) по организациям и физическим лицам настроены корректно, а другие сотрудники проводятся без проблем. В этой статье мы подробно разберем, почему «чистая» настройка прав не всегда помогает и как найти скрытые ошибки в данных, которые провоцируют сбои RLS.
Типичная ситуация разворачивается в конфигурациях на базе подсистемы «Зарплата и кадры» (1С:Комплексная автоматизация 2.5, 1С:ERP 2.5 или 1С:ЗУП 3.1). При попытке проведения или даже записи документа система выбрасывает исключение:
«Ошибка выполнения запроса по причине: У пользователя недостаточно прав на исполнение операции над базой данных».
Рассмотрим подробнее стек вызова из журнала регистрации. Ключевые точки отказа обычно находятся здесь:
{ОбщийМодуль.КадровыйУчет.Модуль(3241)}:Запрос.Выполнить;
{ОбщийМодуль.КадровыйУчет.Модуль(432)}:СоздатьВТСотрудникиОрганизации(Запрос.МенеджерВременныхТаблиц, ТолькоРазрешенные, Параметры);
{Документ.БольничныйЛист.Форма.ФормаДокумента.Форма(2324)}:ДругиеСотрудники = КадровыйУчетРасширенный.ДругиеСотрудникиФизическогоЛица(...);
Из этого фрагмента мы видим, что ошибка возникает не в самом моменте записи объекта Больничный лист, а в процессе работы программных механизмов проверки пересечения периодов отсутствия. Система пытается найти все рабочие места (карточки сотрудников), привязанные к физическому лицу, чтобы убедиться, что сотрудник не «болеет» в двух местах одновременно или не находится в отпуске.
Механизм RLS в современных конфигурациях работает по принципу «Разрешено все, что не запрещено» или наоборот, но всегда опирается на значения в ключевых полях (Организация, Группа доступа физлиц). Если в базе данных существует запись о сотруднике, которая была создана некорректно (например, при программном переносе данных или через прямое удаление объектов), она становится «невидимой» для обычных списков, но продолжает участвовать в запросах.
Когда запрос выполняется с параметром ТолькоРазрешенные, платформа 1С пытается наложить условия RLS на выборку. Если у физлица есть «скрытый» сотрудник с пустыми реквизитами или незаполненной историей, механизм RLS может интерпретировать это как обращение к объекту, на который у пользователя нет прав. Вместо того чтобы просто исключить эту запись из результата, запрос падает с системной ошибкой доступа.
Рассмотрим подробнее, что означает упоминание поля ДатаИстории в контексте данной проблемы. В подсистеме кадрового учета 1С данные о сотрудниках хранятся не только в справочнике Сотрудники, но и в ряде связанных регистров сведений, таких как Данные состояний сотрудников или Основные сотрудники. Поле ДатаИстории часто является техническим разрезом в запросах, которые собирают срез последних данных на конкретную дату.
Если при переносе данных запись в справочнике Сотрудники была создана, а записи в регистрах истории (приемы, переводы) отсутствуют или имеют пустые даты, запрос КадровыйУчет.СотрудникиОрганизации возвращает некорректный результат, на котором «спотыкается» RLS. Это происходит потому, что шаблон доступа не может вычислить принадлежность такой записи к разрешенной организации.
Если вы столкнулись с подобной ситуацией, выполните следующие действия вместе с нами:
Сотрудники, установив отбор по конкретному Физическому лицу, с которым возникла проблема.
ВЫБРАТЬ
Сотрудники.Ссылка КАК Сотрудник,
Сотрудники.Код,
Сотрудники.Организация,
Сотрудники.ПометкаУдаления
ИЗ
Справочник.Сотрудники КАК Сотрудники
ГДЕ
Сотрудники.ФизическоеЛицо = &ФизическоеЛицо
Физические лица, откройте нужного человека и нажмите кнопку «Работа». Здесь отображаются все трудовые договоры. Если в списке есть «пустые» строки или записи без организации, их необходимо вычистить.Основные сотрудники. Если за физлицом закреплен «фантомный» сотрудник, RLS будет блокировать любые проверки по этому человеку для обычного пользователя.Обновление прав доступа (оперативное) или воспользоваться обработкой Управление доступом (в разделе Администрирование), чтобы пересчитать таблицы разрешений для конкретного пользователя.Как показывает практика, наиболее эффективным решением при обнаружении «криво» перенесенного сотрудника является его физическое удаление (если на него нет ссылок в реальных документах). Рассмотрим алгоритм:
Шаг 1: Убедитесь, что найденный «лишний» сотрудник не имеет заполненных реквизитов (пустая организация, пустой табельный номер).
Шаг 2: Попробуйте пометить его на удаление и воспользоваться стандартной обработкой Удаление помеченных объектов. Если система сообщает о наличии связей в регистрах сведений (например, в истории периодов), эти записи также нужно удалить.
Шаг 3: После удаления «фантомной» записи попробуйте снова провести Больничный лист под пользователем-кадровиком. В 99% случаев документ проведется успешно, так как механизм проверки пересечений больше не будет натыкаться на невалидные данные, заблокированные RLS.
Подведем итог: ошибка Запрос.Выполнить с сообщением о правах доступа при работе с кадровыми документами — это не всегда проблема настроек прав. В сложных конфигурациях, таких как 1С:КА 2.5 и 1С:ERP, это индикатор нарушения целостности данных. Всегда проверяйте состав сотрудников физического лица «под капотом», особенно если база пережила перенос данных из других систем. Помните, что механизм RLS крайне чувствителен к незаполненным ключевым полям в объектах, участвующих в запросе.