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

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

Различие между журналом регистрации и состоянием заданий

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

1. История выполнения (Журнал регистрации)

Если нам нужно узнать, когда задание запускалось в прошлом и с каким результатом завершилось, мы обращаемся к Журналу регистрации. В файловом варианте базы данных он физически находится в папке 1Cv8Log в каталоге базы и представляет собой файл с расширением *.lgd (в современных версиях платформы на основе SQLite). Здесь фиксируются события: Старт, Успешное завершение или Ошибка. Однако стоит помнить: если задание не запустилось вовсе из-за сбоя планировщика, в журнале регистрации записей за текущий период просто не будет.

2. Оперативное состояние (Системные таблицы базы данных)

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

Механика сбоя: почему задания «зависают» в будущем?

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

1. Задание завершает работу.
2. Система берет текущее время (которое было ошибочным) и, согласно расписанию, рассчитывает Дату следующего запуска.
3. Эта дата записывается в таблицу _ScheduledJobs как, например, «15 августа».
4. Когда системную дату возвращают к текущей (например, «май»), планировщик сравнивает: «Текущее время (май) >= Время запуска (август)».
5. Условие не выполняется, и система смиренно ждет наступления августа.

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

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

Самый быстрый и интерактивный способ — это перезапись задания. Посмотрим на алгоритм действий:

1. Откроем Консоль регламентных заданий (стандартная обработка с диска ИТС или встроенная в современные конфигурации БСП).
2. Найдем в списке те задания, у которых «Дата последнего запуска» или «Дата следующего запуска» отображается в будущем.
3. Откроем настройки расписания конкретного задания.
4. Ничего не меняя, нажмем ОК или Записать.

При записи объекта РегламентноеЗадание платформа принудительно инициирует пересчет времени следующего запуска, опираясь на текущую (уже исправленную) системную дату. После этого планировщик увидит, что время старта пришло, и запустит процесс.

Способ 2. Программное обновление через код

Если заданий много или вы хотите автоматизировать процесс «реанимации» планировщика, можно воспользоваться встроенным языком 1С. Рассмотрим пример кода, который обновит все регламентные задания в базе:

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

Этот метод позволяет сбросить некорректные ожидания планировщика для всех процессов сразу. Объекты РегламентноеЗадание обновят свои внутренние счетчики в соответствии с текущим временем сервера.

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

Проанализируем разницу в поведении планировщиков, так как это влияет на диагностику:

• Файловый вариант: За выполнение отвечает либо отдельный выделенный сеанс (в старых версиях), либо специальный поток внутри клиентского приложения. Если вы работаете в торговой точке на одном компьютере, критически важно, чтобы дата была верной именно на этой локальной машине. Данные хранятся внутри файла 1Cv8.1CD.
• Клиент-серверный вариант: За запуск отвечает Менеджер кластера сервера 1С. Планировщик ориентируется на время сервера приложений, а не клиентского компьютера. Однако, если даты на сервере приложений и сервере СУБД (SQL) сильно расходятся, это может привести к коллизиям при записи данных в таблицу _ScheduledJobs.

Рекомендации по профилактике

Чтобы избежать подобных проблем в будущем, рекомендуется:

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

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