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

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

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

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

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

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

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

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

Как проверить расписание и предопределённые настройки

Откройте задание в консоли и посмотрите расписание. Частые проблемы: расписание задано на ночные часы, а сервер в это время выключен или база недоступна; расписание срабатывает раз в сутки, а пользователи ждут обновления данных каждый час; задание настроено на запуск «по дням недели», и в выходные оно законно не работает.

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

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

Как проверить выполнение через журнал регистрации

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

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

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

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

Особенности файлового и клиент-серверного режимов

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

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

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

Программная проверка и автоматический контроль

Состояние заданий можно получить из встроенного языка. Метод РегламентныеЗадания.ПолучитьРегламентныеЗадания() возвращает список с отборами, а у каждого объекта доступны свойства: Использование, Расписание, ПоследнееЗадание. Через свойство ПоследнееЗадание.Состояние определяется результат последнего запуска.

Отбор = Новый Структура("Метаданные", "ОбменДанными");
Задания = РегламентныеЗадания.ПолучитьРегламентныеЗадания(Отбор);
Для Каждого Задание Из Задания Цикл
    Последнее = Задание.ПоследнееЗадание;
    Если Последнее <> Неопределено Тогда
        Сообщить("" + Задание.Наименование + ": " + Последнее.Состояние);
    КонецЕсли;
КонецЦикла;

На базе такого кода строят автоматический мониторинг: отдельное задание раз в час проверяет критичные задания и отправляет письмо администратору, если последнее выполнение старше допустимого интервала или завершилось ошибкой. Это надёжнее, чем периодический ручной просмотр консоли.

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

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

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

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

Как убедиться, что задание работает правильно

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

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

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