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

Регламентное задание в 1С перестаёт выполняться чаще всего по одной из пяти причин: задание отключено или заблокировано, расписание не подходит под текущее время, нет активного исполнителя фоновых заданий, не хватает прав у пользователя, от имени которого оно выполняется, или код обработчика падает с ошибкой ещё до начала полезной работы. Проблема почти всегда диагностируется за 10–15 минут, если проверять причины в правильном порядке — от самых частых к редким.

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

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

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

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

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

Проверяем само задание: флаг использования, расписание и блокировки

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

Второй шаг — расписание. Откройте его и проверьте: не ограничено ли выполнение конкретными днями недели или интервалом дат, не истекла ли дата окончания, корректен ли интервал повтора. Частая ситуация — расписание настроено на «один раз в день в 03:00», а сервер в это время выключен или база заблокирована для обновления. Задание не «переносится» автоматически — оно просто пропускается.

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

Исполнитель заданий: сеанс в файловой базе и кластер в серверной

Файловый вариант

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

Проверьте список активных пользователей («Администрирование → Активные пользователи»): есть ли сеанс, предназначенный для фоновых заданий, и когда он был запущен. Если базу открывают только обычные пользователи и ни у кого не включено выполнение заданий — это и есть причина.

Клиент-серверный вариант

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

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

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

Регламентное задание выполняется от имени пользователя, указанного в его свойствах (поле «Имя пользователя»), или от имени пользователя с пустым именем — тогда используется служебный контекст. Если у этого пользователя нет прав на объекты, к которым обращается код обработчика (документы, регистры, внешние соединения), задание запускается, но падает с ошибкой доступа.

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

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

Читаем журнал регистрации и ошибки фоновых заданий

Журнал регистрации — главный источник информации, когда задание запускается, но завершается неудачно. Откройте «Администрирование → Журнал регистрации», установите отбор по событию «Фоновое задание» и нужному периоду. Для каждого запуска видно состояние: «Выполняется», «Завершено успешно» или «Ошибка», а также текст исключения.

Типичные ошибки в журнале и их причины:

• «Метод объекта не обнаружен» — в свойствах задания указано имя метода, которого нет в общем модуле, либо модуль переименовали при обновлении. Проверьте соответствие имени метода и модуля.
• «Нарушение прав доступа» — не хватает прав у пользователя задания (см. предыдущий раздел).
• «Конфликт блокировок» / таймауты — задание не может захватить данные, занятые пользователями или другим заданием. Обычно помогает перенос расписания на нерабочее время или сокращение объёма обрабатываемых данных за один запуск.
• «Ошибка соединения с внешним ресурсом» — недоступен сайт, FTP, почтовый сервер или другая база, к которой обращается обработчик. Проверьте сетевую доступность с сервера 1С, а не со своего рабочего компьютера.

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

Проблемы в коде обработчика и конкурентное выполнение

Если задание запускается и падает, а права в порядке, причина почти всегда в коде обработчика. Частые дефекты: метод не является экспортным, находится в модуле с неподходящими флагами (например, модуль только клиентский), обращается к модальным или интерактивным вызовам (вопросы, предупреждения), которые запрещены на сервере и в фоновом сеансе.

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

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

// Пример защиты от повторного запуска в обработчике задания
Если ЕстьАктивноеЗадание(Метаданные.РегламентныеЗадания.МоеЗадание) Тогда
    ЗаписьЖурналаРегистрации("МоеЗадание", УровеньЖурналаРегистрации.Предупреждение,,, "Предыдущий запуск ещё выполняется, выход");
    Возврат;
КонецЕсли;

Пошаговый порядок диагностики

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

1. 1
   Откройте консоль заданий и проверьте флаг «Использование» у нужного задания
2. 2
   Проверьте расписание: даты, дни недели, время, интервал повтора
3. 3
   В серверной базе проверьте свойства ИБ в консоли кластера — не включена ли блокировка регламентных заданий
4. 4
   Убедитесь, что есть исполнитель: сеанс с выполнением заданий в файловой базе или работающие рабочие процессы кластера
5. 5
   Проверьте пользователя, от имени которого работает задание: активен ли он, есть ли нужные роли
6. 6
   Откройте журнал регистрации с отбором по фоновым заданиям и прочитайте текст последней ошибки
7. 7
   Если ошибка в коде — запустите метод вручную от имени того же пользователя и локализуйте строку сбоя
8. 8
   После исправления выполните задание вручную из консоли и убедитесь, что оно завершилось успешно

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

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