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

← На главную

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

Почему это происходит? Анализируем внутренний механизм планировщика

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

Когда системные часы показывают 2099 год, планировщик считает этот момент текущим временем. После выполнения очередного задания в систему записывается признак: «Задание успешно выполнено 31.07.2099». Когда администратор возвращает правильное текущее время (например, текущий год), планировщик обращается к своим таблицам и видит, что дата следующего запуска наступит еще очень нескоро. Поскольку текущее время компьютера физически меньше, чем сохраненное время последнего запуска, планировщик засыпает и не инициирует выполнение задач.

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

Способ 1: Решение для файловых баз данных (Очистка JobScheduler)

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

Завершите работу всех пользователей. Перед проведением любых манипуляций с файлами базы данных обязательно убедитесь, что в базе никто не работает, и закройте все сеансы (включая конфигуратор).
Создайте резервную копию. Скопируйте файл 1Cv8.1CD в безопасное место. Это золотое правило любого администрирования.
Удалите служебный каталог планировщика. Перейдите в каталог информационной базы на диске. Найдите там папку с именем 1Cv8JobScheduler (обратите внимание, что в старых версиях или на форумах ее часто ошибочно называют «JobSheduler» без буквы «c»). Полностью удалите эту папку. Платформа автоматически создаст её заново при следующем запуске базы, сбросив все зависшие даты выполнения на нулевые значения.
Очистите локальный кэш. Иногда удаление папки внутри базы не помогает до конца, так как операционная система кэширует данные пользователя. Рекомендуется полностью очистить каталоги временных файлов на компьютере, где запускается планировщик. Папки кэша обычно располагаются по путям:
%LocalAppData%\1C\1Cv8
%AppData%\1C\1Cv8

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

Способ 2: Решение для клиент-серверных баз (SQL)

В клиент-серверном варианте работы простое удаление папок на диске не поможет, поскольку вся информация планировщика находится непосредственно внутри таблиц системы управления базами данных (СУБД), а само расписание активно кэшируется процессами сервера приложений 1С.

Рассмотрим порядок действий для СУБД MS SQL Server (для других СУБД, таких как PostgreSQL, логика действий аналогична):

Идентификация таблицы. Информация о регламентных заданиях хранится в системной таблице с именем _ScheduledJobs (в некоторых структурах имя может содержать постфикс, например, _ScheduledJobsXXXX).
Корректировка данных. С помощью средств администрирования СУБД (например, SQL Server Management Studio) необходимо скорректировать или обнулить поля, отвечающие за последнее время запуска (колонки дат). Прежде чем вносить изменения, обязательно сделайте резервную копию базы данных средствами СУБД!
Критически важный шаг — Перезапуск службы! После прямого редактирования таблиц SQL планировщик не заработает сразу. Это связано с тем, что менеджер кластера 1С хранит расписание в своей оперативной памяти. Вам необходимо в обязательном порядке перезапустить службу «Агент сервера 1С:Предприятия». Только после перезапуска службы сервер считает обновленные «чистые» даты из таблиц СУБД и восстановит корректную работу.

Если прямое вмешательство в таблицы СУБД для вас нежелательно, существует альтернативный способ сброса очереди через консоль администрирования серверов 1С:

Откройте консоль администрирования кластера 1С.
Перейдите в свойства вашей проблемной информационной базы.
Установите флаг «Блокировка регламентных заданий включена».
Зафиксируйте изменения, нажав кнопку «Применить», и подождите около 3–5 минут. Это необходимо для того, чтобы фоновые процессы завершились, а менеджер кластера обнулил текущие потоки выполнения.
Снимите флаг блокировки регламентных заданий. В современных версиях платформы это инициирует принудительный пересчет внутренней очереди планировщика на основе текущего системного времени сервера.

Способ 3: Программный сброс расписаний через пересоздание заданий

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

Проанализируем пример кода, который решает эту задачу:


// Программный сброс и пересоздание зависших регламентных заданий
МассивЗаданий = РегламентныеЗадания.ПолучитьРегламентныеЗадания();

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

Поскольку вновь созданные объекты не имеют истории прошлых запусков в 2099 году, планировщик воспримет их как абсолютно новые задачи и начнет их выполнение в строгом соответствии с текущим временем и заданным расписанием.

Способ 4: Особенности конфигураций на базе БСП (Библиотека стандартных подсистем)

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

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

Перейдите в меню «Функции для технического специалиста» (или «Все функции»).
Найдите регистр сведений РегистрСведений.ОчередьЗаданий (или аналогичные регистры, отвечающие за состояние фонового выполнения в вашей версии БСП).
Проанализируйте записи регистра. Если вы обнаружите строки, в которых колонка «Момент времени запуска» или «Дата планируемого старта» установлена в 2099 году, просто удалите эти записи вручную или программно.

Способ 5: Метод «dt» — универсальный сброс для небольших баз

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

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

Важное предостережение: Метод с .dt отлично подходит для файловых или небольших серверных баз. Однако для крупных корпоративных систем этот способ не рекомендуется, так как процесс выгрузки и загрузки гигабайтных баз данных требует значительного времени простоя системы, а также может приводить к временной деградации индексов СУБД.

Подводя итог, можно сказать, что самым оптимальным и безболезненным путем решения проблемы является комбинация очистки локального кэша базы (для файлового варианта) или программного пересоздания регламентных заданий (для клиент-серверного варианта). Будьте внимательны к настройкам системного времени на ваших серверах и своевременно настраивайте синхронизацию времени по протоколу NTP!