Почему при включенном RLS в ведомость не попадают договорники ГПХ и как это исправить

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

В работе с крупными конфигурациями на базе 1С:Зарплата и управление персоналом 3.1 (особенно в версиях КОРП) или 1С:ERP часто возникает необходимость разграничения прав доступа на уровне записей (RLS). Типичная ситуация: расчетчик имеет доступ только к своей организации или подразделению. Однако пользователи часто сталкиваются с неприятной ошибкой: при попытке заполнить ведомость на выплату зарплаты в список попадают штатные сотрудники, но полностью игнорируются физические лица, работающие по договорам гражданско-правового характера (ГПХ). Проанализируем, почему это происходит и как решить проблему программными средствами.

Выясним причину ошибки

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

В случае с договорниками ГПХ ситуация иная. Формально они не являются сотрудниками подразделений в штатном расписании. При заполнении ведомости срабатывает механизм ТолькоРазрешенные. Из-за некорректной работы внутренних запросов библиотеки БЗКР в версиях 3.1.5 — 3.1.7 (и некоторых последующих), система накладывает слишком жесткий фильтр по организации и подразделению, который не находит связки между «физическим лицом — договорником» и разрешенными пользователю «организационными единицами». Фирма «1С» зарегистрировала это поведение как официальную ошибку под номером 10196887.

Вариант 1: Программное исправление через модификацию модуля

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

Нам необходимо найти функцию ЗапросВТСведенияКадровойИсторииСотрудников. Именно в ней формируется временная таблица с данными сотрудников, которая позже используется для заполнения документов выплаты. Проанализируем участок кода, который отвечает за наложение фильтров при включенном RLS:


// В модуле КадровыйУчетБазовый находим функцию ЗапросВТСведенияКадровойИсторииСотрудников
// Ищем блок, где накладываются отборы по организациям
Если ТолькоРазрешенные Тогда
    ДоступныеОрганизации = ЗарплатаКадры.ДоступныеОрганизации;
    Если ЗначениеЗаполнено(ДоступныеОрганизации.Организации) Тогда
        // Следующие строки могут блокировать видимость договорников ГПХ
        // ЗарплатаКадрыОбщиеНаборыДанных.ДобавитьВКоллекциюОтбор(ПараметрыПостроения.Отборы, "ГоловнаяОрганизация", "В" , ДоступныеОрганизации.Организации);
        // ЗарплатаКадрыОбщиеНаборыДанных.ДобавитьВКоллекциюОтбор(ПараметрыПостроения.ОтборыПрименяемыеКСрезу, "Организация", "В" , ДоступныеОрганизации.Филиалы);
    КонецЕсли;
КонецЕсли;

Специалисты рекомендуют временно закомментировать данные строки, чтобы ослабить жесткий фильтр именно в момент формирования кадровых сведений для выплаты. Это позволит системе «увидеть» договорников, так как запрос перестанет требовать от них строгого соответствия штатной структуре подразделений, которое для ГПХ часто не определено или определено иначе.

Вариант 2: Использование механизма расширений (рекомендуемый)

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

Разберем по шагам, как это реализовать:

  1. Создадим новое расширение и добавим в него общий модуль КадровыйУчетБазовый.
  2. Используем аннотацию &Вместо("ЗапросВТСведенияКадровойИсторииСотрудников") или &Перед.
  3. В коде расширения проанализируем тип договора. Если тип данных указывает на работу по договору ГПХ, мы можем принудительно передать в параметры запроса флаг ТолькоРазрешенные = Ложь или модифицировать коллекцию отборов так, чтобы проверялась только Организация, но не Подразделение.

Такой подход сохранит безопасность данных (RLS продолжит работать для кадровых документов), но решит точечную проблему заполнения ведомостей.

Вариант 3: Настройка групп доступа физических лиц

Если вы не хотите менять программный код, проанализируем возможность настройки прав в пользовательском режиме. В конфигурациях ЗУП КОРП и ERP существует механизм «Группы доступа физических лиц». Посмотрим, как это может помочь:

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

Выясним ситуацию с обновлениями

Рассмотрим долгосрочное решение. Ошибка 10196887 была признана критической и исправлена в более поздних релизах. Если вы работаете на ветках 3.1.5 или 3.1.7, самым правильным решением будет переход на актуальные версии (начиная с 3.1.23, 3.1.27 и выше). В новых версиях системная библиотека БЗКР была существенно переработана, и механизмы RLS теперь корректно обрабатывают сотрудников, не входящих в постоянный штат организации.

Подведем итог: если обновление невозможно в ближайшее время, используйте расширение для корректировки запроса в модуле КадровыйУчетБазовый. Если же вы столкнулись с проблемой разово — попробуйте заполнить ведомость под пользователем с полными правами или временно расширьте права расчетчика до группы доступа всех физических лиц.

← На главную