Под каким пользователем запускаются регламентные задания в 1С

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

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

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

Как платформа определяет пользователя регламентного задания

У каждого регламентного задания в консоли заданий есть свойство «Пользователь» (имя пользователя информационной базы). Именно это поле определяет, в чьём контексте безопасности будет выполняться обработчик задания. Если поле заполнено, платформа создаёт фоновый сеанс и выполняет аутентификацию под указанным пользователем.

Если поле «Пользователь» не заполнено, фоновое задание стартует без аутентификации. В этом случае функция ИмяПользователя() вернёт пустую строку, а обращение к текущему пользователю через механизмы БСП (например, Пользователи.ТекущийПользователь()) может вызвать исключение или вернуть неопределённое значение — в зависимости от версии библиотеки и логики прикладного кода.

Важно различать два уровня «пользователя». Первый — пользователь информационной базы 1С, от имени которого исполняется код и проверяются права на объекты метаданных. Второй — учётная запись операционной системы, под которой работает сам процесс (агент сервера 1С или клиентское приложение). Эти уровни независимы: задание может выполняться под пользователем 1С «Администратор», но процесс ОС при этом принадлежит учётной записи службы USR1CV8.

Клиент-серверный режим: кто фактически выполняет задание

В клиент-серверной архитектуре регламентные задания исполняет рабочий процесс кластера (rphost), который выбирает менеджер кластера. С точки зрения операционной системы все фоновые сеансы работают под учётной записью службы агента сервера 1С — на Windows по умолчанию это локальная учётная запись USR1CV8, на Linux — пользователь, под которым запущен агент (часто usr1cv8).

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

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

Файловый режим: особенности выполнения

В файловой информационной базе нет выделенного сервера, поэтому регламентные задания выполняются в отдельном фоновом процессе на том компьютере, где запущен клиентский сеанс с разрешённым выполнением заданий. Исторически для этого использовался запуск с параметром /ExecuteScheduledJobs или настройка через код УстановитьВыполнениеРегламентныхЗаданий(Истина).

Пользователь информационной базы в этом сценарии — тот, под которым запущен сеанс-исполнитель, либо пользователь, указанный в свойстве задания (платформа создаст фоновый сеанс с его аутентификацией). Учётная запись операционной системы — это пользователь Windows, запустивший процесс 1cv8.exe.

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

Как проверить, под каким пользователем выполнилось задание

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

Второй способ — программный. В обработчик задания временно добавьте запись в журнал с вызовом ИмяПользователя() и ТекущийРежимЗапуска(). Это даст точный ответ непосредственно из контекста выполнения и поможет отличить «пустого» пользователя от реальной учётной записи.

ЗаписьЖурналаРегистрации("ПроверкаЗадания", УровеньЖурналаРегистрации.Информация, , , "Пользователь: " + ИмяПользователя() + "; режим: " + Строка(ТекущийРежимЗапуска()));

Третий способ — консоль кластера (для клиент-серверного режима). В списке сеансов фоновые задания отображаются как отдельные сеансы с типом «Фоновое задание», и в их свойствах виден пользователь информационной базы. Это удобно для наблюдения в реальном времени, пока задание выполняется.

1. 1
   Откройте свойства регламентного задания и проверьте поле «Пользователь»
2. 2
   Запустите задание принудительно из консоли заданий
3. 3
   Откройте журнал регистрации и найдите события фонового задания
4. 4
   Сверьте имя пользователя в событиях с ожидаемым
5. 5
   При необходимости добавьте в обработчик запись ИмяПользователя() и повторите запуск

Какие права нужны пользователю регламентного задания

Пользователь, указанный в свойствах задания, должен обладать ролями, достаточными для выполнения кода обработчика: чтение и запись нужных объектов, право на выполнение общих модулей, доступ к внешним компонентам, если они используются. Минимальный принцип здесь обязателен — не следует назначать заданиям полные права «на всякий случай».

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

Отдельно проверьте права уровня ОС. Если задание пишет файлы в сетевую папку, учётной записи агента сервера 1С нужны права на эту папку. Локальная учётная запись USR1CV8 по умолчанию не имеет доступа к сетевым ресурсам других серверов — для таких сценариев службу агента запускают под доменной учётной записью с необходимыми правами.

Типичные ошибки и их последствия

Отдельный класс проблем связан с кодом, который ведёт себя по-разному в интерактивном и фоновом сеансе. Например, попытка открыть форму, вызвать Предупреждение() или обратиться к клиентскому контексту в фоновом задании вызовет ошибку. Такой код нужно оборачивать проверкой режима или выносить в серверные ветки.

Ещё одна частая ситуация: задание выполняется, но результата нет, потому что RLS-ограничения пользователя задания скрывают часть данных. Внешне это выглядит как «задание отработало, но ничего не сделало». Диагностируется сравнением результата под пользователем задания и под полными правами.

Как выбрать правильную конфигурацию для своей базы

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

Частые вопросы