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

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

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

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

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

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

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

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

Где задается пользователь регламентного задания

Назначить пользователя можно двумя способами: в конфигураторе на уровне метаданных или в режиме предприятия через консоль заданий. В конфигураторе откройте ветку «Общие — Регламентные задания», выберите нужное задание и в палитре свойств найдите поле «Имя пользователя». Здесь можно указать конкретного пользователя информационной базы.

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

Программно пользователь назначается через объект метаданных задания при создании или изменении:

Задание = РегламентныеЗадания.НайтиПоУникальномуИдентификатору(ИдЗадания);
Задание.ИмяПользователя = "СлужебныйРобот";
Задание.Записать();

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

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

В клиент-серверном варианте регламентные задания исполняются фоновыми заданиями в рабочих процессах кластера. Поток выполнения стартует от имени учетной записи агента сервера 1С, поэтому все обращения к файловой системе, сетевым путям (\\server\share), COM-объектам и внешним компонентам происходят с правами этой служебной учетки, а не с правами пользователя ИБ.

Это причина классической ошибки: задание «под администратором» не может записать файл в сетевую папку, хотя у администратора туда есть доступ. Доступ к папке должен быть у учетной записи, под которой работает служба агента сервера 1С. Решение — выдать права на каталог этой учетке либо запускать службу сервера под доменной учетной записью с нужными доступами.

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

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

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

Контекст пользователя при этом определяется свойством «Имя пользователя» задания аналогично серверному режиму. Фоновое задание создает отдельный сеанс под указанным пользователем. Но права на файловую систему — это права Windows-пользователя, в чьем сеансе запущено выполнение.

Для автономной работы файловой базы часто настраивают отдельный процесс через планировщик Windows с запуском 1С в режиме Execute (параметр командной строки /Execute с обработкой или запуск с ключом выполнения регламентных заданий). В этом случае под /N указывают пользователя ИБ, под которым пройдет аутентификация.

1. 1
   Создайте в ИБ служебного пользователя с нужными ролями
2. 2
   Укажите его в свойстве «Имя пользователя» регламентного задания
3. 3
   Настройте задачу в планировщике Windows с запуском 1cv8.exe и параметрами /N и /P
4. 4
   Проверьте права Windows-пользователя планировщика на каталог базы и сетевые ресурсы
5. 5
   Запустите задачу вручную и проверьте журнал регистрации

Права и роли: что проверить, если задание падает

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

Далее проверьте роли пользователя задания: нужны права на чтение/запись объектов, которые обрабатывает код, а также право на выполнение самой процедуры (если она в общем модуле с признаком «Привилегированный режим», часть проверок прав снимается, но полагаться на это без понимания кода не стоит).

Если в конфигурации используется RLS (ограничение доступа на уровне записей), помните: под пользователем задания применяются его ограничения. Задание, которое у полноправного пользователя видит все организации, под роботом с RLS обработает только разрешенные ему записи. Это частая причина «неполной» выгрузки данных.

Типичные ошибки при настройке пользователя задания

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

Выбор стратегии: какого пользователя назначить

Универсальное правило: одна задача — один служебный пользователь с минимально достаточными правами, без привязки к реальным сотрудникам. Это упрощает аудит (в журнале сразу видно, какое задание что сделало), снижает риски и исключает сбои при кадровых изменениях.

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