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

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

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

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

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

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

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

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

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

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

В конфигураторе то же свойство доступно через ветку «Общие» → «Регламентные задания» → свойства конкретного задания, поле «Имя пользователя». Там задаётся имя пользователя информационной базы, а не пользователя Windows и не пользователя СУБД. Если поле пустое — задание выполняется под пользователем по умолчанию.

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

1. 1
   Создайте в базе отдельного служебного пользователя, например «Робот» или «СервисОбмена», без права интерактивного входа, если он не нужен.
2. 2
   Назначьте ему только те роли, которые реально нужны для кода задания: чтение и запись конкретных объектов, а не полные права.
3. 3
   Откройте свойства регламентного задания и укажите этого пользователя в поле «Имя пользователя».
4. 4
   Запустите задание вручную и проверьте в журнале регистрации, что оно выполнилось под нужным пользователем и без ошибок доступа.

Пользователь по умолчанию: что это и чем он опасен

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

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

Дополнительная тонкость: в коде, который проверяет текущего пользователя (например, подстановка ответственного или отбор по владельцу), пользователь по умолчанию даст пустое значение. Документы, созданные таким заданием, могут оказаться без ответственного, что ломает отчёты и согласование.

Права и роли: минимально необходимый набор

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

Если задание обращается к внешним ресурсам — веб-сервисам, каталогам, почте — помните о двух уровнях прав. Права внутри 1С определяются пользователем ИБ, а доступ к сетевой папке или интернет-ресурсу — учётной записью ОС, под которой работает процесс кластера или клиент. Ошибка «нет доступа к файлу» часто относится именно ко второму уровню, и смена пользователя задания её не решит.

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

Варианты настройки пользователя

Отдельный служебный пользователь

Рекомендуемый вариант: понятная атрибуция в журнале, минимальные роли, легко отозвать доступ. Требует разовой настройки.

Пользователь по умолчанию (пустое имя)

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

Существующий пользователь-администратор

Быстро, но опасно: избыточные права, задания «привязаны» к конкретному человеку, при его увольнении или блокировке задания могут остановиться.

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

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

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

Ещё один практический приём — временно добавить в начало обработчика задания запись в журнал регистрации с именем текущего пользователя через ИмяПользователя(). Это даёт стопроцентное подтверждение, но требует изменения кода или расширения, поэтому применяйте на копии или через механизм расширений.

Контрольные точки

Как проверить результат

Пользователь в журнале регистрации при выполнении задания

Норма

Указан ожидаемый служебный пользователь

Тревожный признак

Пустое имя или чужой пользователь — задание настроено не так, как планировалось

Ошибки «Нарушение прав доступа» после выполнения

Норма

Ошибок нет, данные обработаны

Тревожный признак

Ошибки доступа — у пользователя задания не хватает ролей

Поля «Ответственный» в созданных документах

Норма

Заполнены ожидаемым значением

Тревожный признак

Пустые или неожиданные значения — код использует текущего пользователя, а это не тот, кого вы ожидали

Типичные ошибки и ограничения

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

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

Третья группа — различия окружения. Задание, отлаженное в файловой копии под пользователем с полными правами, в рабочей клиент-серверной базе под служебным пользователем может упасть из-за прав или из-за недоступности сетевого ресурса для учётной записи службы сервера. Всегда проверяйте задание в целевом окружении и под целевым пользователем.

Рекомендации по организации служебных пользователей

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

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

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

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

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

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

Нужен ли пароль пользователю регламентного задания?

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

Почему задание работает под одним пользователем, а файлы в сетевую папку не пишет?

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

Что будет, если удалить пользователя, указанного в регламентном задании?

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

Можно ли выполнять разные задания под разными пользователями?

Да, и это рекомендуемая практика. Каждому заданию в его свойствах задаётся свой пользователь, что позволяет выдать минимально необходимые роли и чётко разделять ответственность в журнале регистрации и в создаваемых документах.

Как заставить задание игнорировать права доступа?

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