Почему при регламентном проведении по партиям срабатывают проверки параметров сеанса и как это исправить?

При разработке и доработке конфигураций на платформе 1С:Предприятие часто возникает ситуация, когда в модуле объекта документа прописана проверка параметров сеанса, например, для ограничения прав доступа по складам или подразделениям. При интерактивной работе пользователя такой код функционирует корректно, однако при запуске регламентных или фоновых заданий (в частности, при автоматическом проведении по партиям) алгоритм неожиданно начинает заходить в блоки проверок, блокируя проведение или вызывая ошибки.

Рассмотрим подробно, почему это происходит и какими способами можно предотвратить ложные срабатывания проверок в серверных и фоновых контекстах.

Почему параметр сеанса принимает значение Истина в регламентных заданиях

Проанализируем механику работы платформы при выполнении бизнес-логики. Попытка вычисления логического выражения вида:

Если ПараметрыСеанса.ОграничениеПоСкладам И РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
    // Логика проверки прав и ограничений
КонецЕсли;

Заходит внутрь условия исключительно в том случае, если оба проверяемых значения равны Истина. Если код выполняется при регламентном проведении, значит, параметр сеанса ОграничениеПоСкладам действительно был инициализирован со значением Истина.

Это происходить по следующим причинам:

1. Изолированный контекст фонового сеанса. Регламентные и фоновые задания выполняются в отдельном автономном сеансе на сервере. Контекст этого сеанса, его права и окружение не зависят от настроек текущего интерактивного пользователя.
2. Автоматическая инициализация в модуле сеанса. При первом обращении к любому параметру сеанса внутри фонового задания платформа вызывает обработчик УстановкаПараметровСеанса в модуле сеанса. Если в коде инициализации не предусмотрена обработка системных сеансов, логика по умолчанию может заполнять параметр значением Истина.
3. Запуск от имени системной учетной записи. Настройки прав доступа, заданные в интерфейсе для обычных пользователей, не применяются автоматически к пользователю, под которым стартует регламентное задание.

Способ 1. Передача флага через ДополнительныеСвойства объекта

Самым методически верным решением для управления логикой проведения из внешних обработок или регламентных заданий является использование коллекции ДополнительныеСвойства объекта документа.

Перед вызовом метода Записать() в регламентном задании или обработке проведения по партиям необходимо установить специальный флаг:

ДокументОбъект.ДополнительныеСвойства.Вставить("ПроведениеПоПартиям", Истина);
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);

В модуле объекта документа (в обработчиках ПередЗаписью или ОбработкаПроведения) проверяем наличие этого флага перед вычислением условий, связанных с параметрами сеанса:

ОтключениеПроверок = Ложь;
ДокументОбъект.ДополнительныеСвойства.Свойство("ПроведениеПоПартиям", ОтключениеПроверок);

Если НЕ ОтключениеПроверок И ПараметрыСеанса.ОграничениеПоСкладам И РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
    // Логика проверки ограничений для интерактивных пользователей
КонецЕсли;

Способ 2. Проверка привилегированного режима и фонового контекста

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

Чтобы игнорировать интерактивные проверки при выполнении фоновых процессов, доработаем условие в модуле объекта с помощью функции ПривилегированныйРежим():

Если НЕ ПривилегированныйРежим() И ПараметрыСеанса.ОграничениеПоСкладам И РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
    // Выполнение проверок только для обычных пользователей в непривилегированном режиме
КонецЕсли;

Способ 3. Корректировка обработчика УстановкаПараметровСеанса

Если параметры сеанса используются для управления доступом, необходимо проверить модуль сеанса и его обработчик УстановкаПараметровСеанса. Для фоновых заданий следует явно прописать алгоритм, определяющий контекст выполнения.

Разберем пример настройки инициализации параметра сеанса:

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

КонецПроцедуры

Рекомендации по архитектуре проверок

Для предотвращения подобных проблем в дальнейшем рекомендуется разделять интерактивные проверки и бизнес-логику проведения:

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