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

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

После этого случая мы собрали стенд на копии УТ 11.5 и завели на нём десять заданий, у каждого своя причина молчания. Замеры стенда разложены ниже по местам проверки: какой след оставляет каждая причина и каким кодом её найти.

Не запускается или работает впустую

Снаружи оба отказа выглядят одинаково: данных нет. Ищутся они в разных местах.

Что видно	Что это значит	Куда смотреть
запусков по расписанию нет, ошибок нет	задание не стартует	кластер, поле “Имя пользователя”, расписание
запуск есть и сразу обрывается с текстом	запуск отменила проверка БСП	текст ошибки фонового задания
запуски успешные, а данных нет	работа идёт вхолостую	код, права, возраст данных в приёмнике
запуски успешные, “обработано” большое, а набор не пустеет	обход порциями теряет записи	остаток после прогона
запуски есть, но тянутся часами	задание не влезает в окно	время по шагам

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

Скрипт: задания базы, их пользователи и последний запуск

Код для консоли кода или внешней обработки. Выполнять на сервере под администратором: список регламентных заданий платформа отдаёт только ему.

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

В выводе стоит разобрать три вида строк. Пользователь, которого в базе нет. Включённое задание без последнего запуска: повод поднять его историю. И пустое имя: по описанию платформы такое задание выполняется пользователем по умолчанию с административными правами, и надо понимать, устраивает ли это вас. В типовой УТ 11.5 на нашем стенде поле пустое у всех 139 предопределённых заданий, так что пустота сама по себе нормальна.

Проверки по порядку

1. История запусков. Если у механизма есть свой журнал, поднимите его целиком и разложите записи по датам и по тому, кто запускал. В журнале регистрации запуск сервером отличается от ручного одной колонкой, об этом ниже.
2. Блокировка регламентных заданий в кластере. У информационной базы в настройках кластера есть флаг, который выключает её регламентные задания целиком. Его вместе с остальными настройками базы показывает чек-ап сервера 1С, обработка лежит на Инфостарте. Прочитать флаг можно и кодом из самой базы, с одной ловушкой, она разобрана ниже.
3. Отказы БСП при старте. Об этом ниже отдельно: задание стартует и тут же прерывается, а иногда ещё и выключается.
4. Поле “Имя пользователя”. Существует ли учётная запись в этой базе. После переноса обработки или базы эта проверка идёт первой. Роли и запрет входа, по замеру, запуску не мешают.
5. Привязка к команде. Если задание запускает команду дополнительной обработки, убедитесь, что оно ссылается на действующую команду. Иначе запись задания есть, а выполнять нечего.
6. Расписание. Дата окончания и условия, которые никогда не совпадут. Глазами это проверяется плохо, у платформы есть функция для такого вопроса.
7. Изменения данных в сеансе запуска. Если запуски есть, а результата нет, журнал покажет, менял ли запуск что-нибудь в базе.

Какой след оставляет каждая причина

Главный вопрос при разборе молчащего задания: где искать улики. У разных причин они лежат в разных местах, а у одной их нет вовсе. Сводка по стенду: УТ 11.5.22.67, БСП 3.1.11.189, платформа 8.3.27.1606, MS SQL. Автозапуски набирали в окне около двух минут, пока флаг на кластере был снят.

Причина	Журнал регистрации	ПоследнееЗадание	Фоновые задания в памяти сервера	”Выполнить сейчас”
флаг блокировки на кластере	автозапусков нет	-	-	проходит: три запуска из трёх
пользователя из карточки в базе нет	ни одной строки: ни запуска, ни ошибки	Неопределено	попытки примерно каждые 10 секунд с ошибкой входа	-
у пользователя нет ролей	запуски идут: 6 за окно	-	-	-
пользователю выключены все виды входа	запуски идут: 7 за окно	-	-	-
расписание кончилось или не наступит	автозапусков нет	-	-	-
отказ проверки БСП	запуск и ошибка с текстом причины	-	-	-
работает вхолостую	пары Start и Finish без изменений данных	-	-	-

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

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

Консоль кластера есть не у всех, кто сопровождает базу. Флаг видно и изнутри, через сервер администрирования RAS и объект АдминистрированиеСервера. На 8.3.27 работает такой код, он берёт первый кластер:

Админка = Новый АдминистрированиеСервера("localhost", 1545);
Админка.ВыполнитьАутентификацию();
Кластер = Админка.ПолучитьКластеры()[0];
Кластер.ВыполнитьАутентификацию(ЛогинКластера, ПарольКластера);
Для Каждого База Из Кластер.ПолучитьИнформационныеБазы() Цикл
	Если База.Имя = "ИмяБазы" Тогда
		База.ВыполнитьАутентификацию(ЛогинАдминистратораБазы, ПарольАдминистратораБазы);
		Сообщить("Блокировка: " + База.БлокировкаРегламентныхЗаданий + ", СУБД: " + База.СУБД);
	КонецЕсли;
КонецЦикла;

Три замечания по замеру.

Что проверяли	Что получили
код без аутентификации администратора базы	”Нет” при включённом флаге, тип СУБД пустой, ошибки нет
тот же код после База.ВыполнитьАутентификацию	”Да”, тип СУБД MSSQLServer
порт, на котором RAS не запущен	исключение уже в конструкторе: подключение не установлено
неверный пароль администратора базы	после нескольких попыток вход этой учётке закрыт на 5 минут, HTTP-сервисы базы под ней отвечали отказом

Первая строка опаснее всех: вместо ошибки кластер молча подставляет значение по умолчанию. Верить ответу можно, только если рядом пришёл непустой тип СУБД, у клиент-серверной базы он пустым не бывает. Четвёртая строка стоила нам пяти минут неработающего стенда, поэтому подбирать пароль боевого администратора таким кодом нельзя. Пять минут - настройка нашей базы, у вас может быть иначе.

Тот же ответ даёт командная строка, строка scheduled-jobs-deny: on в выводе означает блокировку:

rac infobase info --cluster=<кластер> --infobase=<база> --infobase-user=<администратор> --infobase-pwd=<пароль> localhost:1545

rac ходит в тот же RAS, так что без запущенной службы он тоже промолчит. Остаётся консоль “Администрирование серверов 1С”, флаг лежит в свойствах информационной базы.

Одно предупреждение для тех, кто снимает флаг на копии, чтобы проверить задания. На нашем стенде за две минуты без флага БСП сама включила обновление доступа на уровне записей, и оно пошло тяжёлым фоновым заданием. После возврата флага его пришлось завершать через rac session terminate. Прежде чем снимать флаг, выключите задания, которые не должны стартовать, и запишите, какие были включены.

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

Когда задание отменяет сама БСП

Большинство типовых заданий на библиотеке стандартных подсистем, в том числе запуск дополнительных обработок по расписанию, начинают работу с общей проверки ОбщегоНазначения.ПриНачалеВыполненияРегламентногоЗадания. Если она решает, что запускать сейчас нельзя, задание прерывается, а причина остаётся в тексте ошибки фонового задания. По коду УТ 11.5.22.67 причин пять:

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

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

Кто снял галочку “Использование”

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

Параметры = Константы.ПараметрыБлокировкиРаботыСВнешнимиРесурсами.Получить().Получить();
Если ТипЗнч(Параметры) = Тип("Структура") Тогда // пока БСП не завела параметры, там Неопределено
	Сообщить("Работа с внешними ресурсами заблокирована: " + Параметры.РаботаСВнешнимиРесурсамиЗаблокирована);
	Для Каждого ИмяСписка Из СтрРазделить("ОтключенныеЗадания,ОтключенныеЗаданияПриОтключенииДоступаКИнтернетСервисам", ",") Цикл
		Для Каждого Ид Из Параметры[ИмяСписка] Цикл
			Сообщить("Выключено БСП: " + РегламентныеЗадания.НайтиПоУникальномуИдентификатору(Ид));
		КонецЦикла;
	КонецЦикла;
КонецЕсли;

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

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

Модуль = ОбщегоНазначения.ОбщийМодуль("РегламентныеЗаданияСлужебный");
Зависимости = Модуль.РегламентныеЗаданияЗависимыеОтФункциональныхОпций();
Доступно = Модуль.РегламентноеЗаданиеДоступноПоФункциональнымОпциям(Метаданные.РегламентныеЗадания.ИмяЗадания, Зависимости);

Выключенная опция при выключенном задании - штатное состояние. Тревожная комбинация обратная: галочка стоит, опция выключена. На копии УТ такое нашлось ровно у одного типового задания.

Случай: шестнадцать месяцев под учёткой из другой базы

Задание выгружало продажи партнёру. Использование включено, расписание каждый день с 06:00 до 10:30 раз в час, ошибок в журнале ноль. В истории механизма 580 записей, и все поставлены ручными прогонами: автоматических нет ни за один день с апреля 2025 года.

Первой версией было “задание видит недавний успех и пропускает запуск”. Её сняли замером: удалили запись об успешном прогоне, руками довезли данные за нужный день и стали ждать. Четыре дня ни одного запуска.

Дальше сравнивали с соседней базой, где тот же код срабатывает каждый день в 23:45. Запрет заданий в кластере был снят, в модели сервиса база не работала, привязка команды оказалась верной, права на внешние соединения совпали у обеих баз. Отличие нашлось в расписании: у соседа простое “раз в день”, у нас окно с повтором. Причиной оно тоже не было.

Решило поле “Имя пользователя”. Там стояла учётная запись из базы, откуда обработку когда-то скопировали вместе с настройками задания. Поле поправили, задание пошло само, а разрыв за дни разбора закрыли вручную: 271 пакет без единой ошибки. Тогда причину назвали по результату, изнутри механизм не разбирали. Стенд потом показал, почему журнал молчал: под пользователем, которого нет в базе, платформа 8.3.27 не пишет о задании ни строки. Версию сервера из этого случая мы не знаем, но картина совпала.

Пользователь задания: что мешает запуску, а что нет

Мы ждали, что задание остановит любой “плохой” пользователь. Замер это опроверг.

Пользователь в карточке	Запусков за окно	Вердикт
учётной записи в базе нет	0, в журнале пусто	не выполняется
есть, но без единой роли	6	запускается, код рискует
полные права, все виды входа выключены	7	запускается
поле пустое	6	норма для типовых

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

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

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

Расписание: спросите у платформы

У объекта расписания есть функция ТребуетсяВыполнение. Она отвечает, нужен ли запуск в заданный момент, и снимает вопрос “правильно ли я читаю эти галочки”. Что она ответила на стенде:

Расписание	Момент проверки	Ответ
каждые 20 секунд, дата окончания 26.09.2026	сейчас / 20.09	Нет / Да
31-е число, месяц февраль	любая дата	Нет
окно 10:15-10:45	10:00 / 10:20 / 11:00	Нет / Да / Нет
с 22:00 раз в день, прошлый запуск в 22:05	22:10	Нет
раз в 7 дней с 01.09, без даты прошлого запуска	02.09 / 08.09	Да / Да
типовая проверка ведения учёта, окно с 20:00 по 8:00	23:00 / 03:00 / 12:00	Да / Да / Нет

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

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

Сервер запускал или человек: читаем журнал

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

Признак	Запуск планировщиком	”Выполнить сейчас” в форме БСП
событие	_$Job$_.Start	_$Job$_.Start
”Метаданные”	РегламентноеЗадание.ИмяЗадания	пусто
”Данные”	наименование задания	”Запуск вручную: наименование”
при флаге блокировки на кластере	не стартует	стартует

У предопределённых заданий наименование пустое, поэтому и колонка “Данные” у их автозапусков пустая: опираться надо на метаданные. Конец запуска пишется событием _$Job$_.Finish, ошибка _$Job$_.Error уровня “Ошибка” с текстом в комментарии. Имён _$Job$_.Succeed и _$Job$_.Fail в журнале 8.3.27 мы не встретили.

Отбор = Новый Структура("ДатаНачала, ИмяПриложения, Событие", ТекущаяДата() - 30 * 86400, "BackgroundJob", "_$Job$_.Start");
Журнал = Новый ТаблицаЗначений;
ВыгрузитьЖурналРегистрации(Журнал, Отбор, "Дата, Метаданные, Данные");
Для Каждого Запись Из Журнал Цикл
	ИмяМетаданных = Запись.Метаданные;
	Если ТипЗнч(ИмяМетаданных) = Тип("Массив") Тогда // у части событий метаданных несколько
		ИмяМетаданных = ?(ИмяМетаданных.Количество() > 0, ИмяМетаданных[0], "");
	КонецЕсли;
	ВидЗапуска = ?(СтрНачинаетсяС(Строка(ИмяМетаданных), "РегламентноеЗадание."), "сервер", "вручную");
КонецЦикла;

Два ограничения. Запуски пишутся уровнем “Информация”, и если журнал настроен только на ошибки, этого раздела у вас нет. На старых платформах отбор журнала дорог: по нашему замеру на 8.3.20.2290 до 2,6 миллисекунды на каждую отобранную строку, месяц истории частых заданий читается минутами. Читайте сутками от сегодняшнего дня назад, а за дальними днями ходите отбором по метаданным только тех заданий, у которых запусков ещё не нашлось.

Запуски есть, работы нет

Холостой запуск видно по сеансу. Берём номер сеанса из _$Job$_.Start и ищем в нём события изменения данных до _$Job$_.Finish:

События = Новый Массив;
События.Добавить("_$Data$_.New");
События.Добавить("_$Data$_.Update");
События.Добавить("_$Data$_.Delete");
События.Добавить("_$Data$_.Post");
События.Добавить("_$Data$_.Unpost");
Изменения = Новый ТаблицаЗначений;
// Запуск - пара событий Start и Finish одного сеанса из выгрузки выше
ВыгрузитьЖурналРегистрации(Изменения, Новый Структура("ДатаНачала, ДатаОкончания, Сеанс, Событие",
	Запуск.Начало, Запуск.Конец, Запуск.Сеанс, События), "Метаданные");
Вхолостую = Изменения.Количество() = 0;

Считать транзакции вместо изменений нельзя: БСП на каждом запуске пишет служебную отметку, и _$Transaction$_.Commit находится даже у пустого запуска. На стенде 24 запуска удаления временных файлов, которым нечего было удалять, дали ноль событий _$Data$_, а один запуск заполнения параметров работы расширений дал 30 изменений регистра сведений.

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

Обработка: все проверки по всем заданиям

Проходить эти места руками по каждому заданию долго, на нашей копии УТ их 156, поэтому мы собрали их во внешнюю обработку. Описание, демо вердиктов и частые вопросы на странице инструмента Регламентное задание не выполняется: почему, сама обработка продаётся на Инфостарте за 10 SM.

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

Проверено на одной конфигурации, УТ 11.5.22.67 на 8.3.27.1606 с MS SQL. Файловую базу стенд не покрывает: там задания выполняет один из открытых сеансов, и при закрытых сеансах они не идут вовсе.

Контроль снаружи

Задание, которое не стартовало, не напишет ни ошибки, ни отметки о работе. Любая диагностика внутри его кода до этого места просто не доживает. Такой отказ видит только проверка снаружи: дата последнего изменения данных, которые задание обязано менять, рядом с сегодняшней датой. Хватит отчёта на две строки или пункта в мониторинге 1С, лишь бы проверка жила вне задания, за которым следит.