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

Регламентные задания 1С хранятся в самой информационной базе, а не в отдельном файле. Описание задания (имя, метод, расписание по умолчанию) лежит в конфигурации. Рабочее расписание, флаг «Использование», пользователь и параметры — в данных базы: в файловом варианте внутри 1Cv8.1CD, в клиент-серверном — в служебных таблицах SQL Server или PostgreSQL. Отдельно, в реестре кластера, хранится только один флаг — «Блокировка регламентных заданий включена».

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

Три уровня хранения регламентных заданий

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

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

💡 Предопределённые задания платформа создаёт в данных сама, при первом обращении после обновления конфигурации. Непредопределённые (например, задания загрузки курсов по отдельным валютам или обмены по узлам) создаются программно и существуют только в данных.

Файловая база: регламентные задания внутри 1Cv8.1CD

В файловом варианте всё лежит в одном файле 1Cv8.1CD в каталоге базы. Отдельного файла с расписанием там нет. Рядом находятся:

• 📁 1Cv8Log\ — журнал регистрации, где видно запуски и ошибки заданий;
• 📄 1Cv8tmp.1CD — временный файл, создаётся во время работы;
• 🔐 1Cv8.cfl — файл блокировки, появляется при открытых сеансах.

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

Управлять этим можно параметрами командной строки:

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /F"D:\Bases\Buh" /AllowExecuteScheduledJobs -Force

• -Force — этот клиент обязательно выполняет задания;
• -Off — этот клиент задания не выполняет.

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

Клиент-серверная база: таблицы SQL и регламентные задания

В клиент-серверном варианте экземпляры заданий хранятся в служебной таблице базы данных на SQL Server или PostgreSQL. Это не таблицы объектов конфигурации (_Document…, _Reference…), а системные таблицы платформы, без префикса подчёркивания или с ним — в зависимости от назначения.

Найти таблицу проще всего запросом к каталогу СУБД.

SQL Server:

USE [buh];
SELECT name, create_date
FROM sys.tables
WHERE name LIKE '%Sched%';

PostgreSQL:

SELECT tablename
FROM pg_tables
WHERE schemaname = 'public'
  AND tablename ILIKE '%sched%';

Содержимое таблицы посмотреть можно, но толку мало. Расписание и параметры лежат в двоичном сериализованном виде, человекочитаемых колонок «время запуска» там нет.

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

1. В конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11): Администрирование → Обслуживание → Регламентные операции → Регламентные и фоновые задания.
2. Из встроенного языка — менеджер РегламентныеЗадания.
3. Через внешнюю обработку -консоль заданий, если в конфигурации нет БСП.

Таблица Config хранит конфигурацию базы данных, в том числе описание регламентных заданий из метаданных. Её данные сжаты, и разбирать их SQL-запросом бессмысленно.

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

Кто запускает задание на сервере

Расписание в таблице само ничего не делает. Его читает менеджер кластера: он следит за временем и в нужный момент создаёт фоновое задание. Выполняется оно в одном из рабочих процессов rphost как отдельный сеанс без интерфейса.

Что это даёт на практике:

• 🖥️ клиенты для запуска не нужны — задание пойдёт, даже если в базе нет ни одного пользователя;
• 👤 код работает от имени пользователя, указанного в задании, — задайте его явно, чтобы права задания были предсказуемы;
• 📋 во время выполнения задание видно в списке сеансов базы в консоли кластера как фоновое;
• ⏱️ если предыдущий запуск ещё идёт, новый по тому же заданию не стартует, пока старый не закончится.

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

Блокировка заданий в кластере и утилита rac

Флаг «Блокировка регламентных заданий включена» хранится не в базе, а в свойствах информационной базы на кластере. Физически это файл реестра 1CV8Clst.lst:

• Windows: C:\Program Files\1cv8\srvinfo\reg_1541\ (если служба установлена с каталогом по умолчанию);
• Linux: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/.

Поэтому флаг не переезжает с .dt: новая база на другом кластере получит его значение по умолчанию — выключен.

Управлять флагом удобно из командной строки через rac. Утилита работает через сервер администрирования ras, его нужно запустить заранее (порт по умолчанию 1545):

ras cluster --daemon

Дальше порядок такой:

1. Узнать идентификатор кластера:

   rac cluster list
   

2. Найти базу по имени:

   rac infobase summary list --cluster=<uuid-кластера>
   

3. Посмотреть свойства базы, в том числе scheduled-jobs-deny:

   rac infobase info --cluster=<uuid-кластера> --infobase=<uuid-базы> --infobase-user=Админ --infobase-pwd=***
   

4. Включить или снять блокировку:

   rac infobase update --cluster=<uuid-кластера> --infobase=<uuid-базы> --infobase-user=Админ --infobase-pwd=*** --scheduled-jobs-deny=on
   

Если на кластере заданы администраторы, к каждой команде добавьте --cluster-user и --cluster-pwd.

Откуда взялся schedule.dat

В описаниях темы иногда встречается файл schedule.dat, где якобы лежит расписание. В каталогах платформы, информационной базы и кластера такого файла нет. Если вы нашли его на сервере, его создала сторонняя программа — планировщик резервного копирования, скрипт администратора, агент мониторинга.

Удалять его вслепую не нужно. Сначала выясните, какой процесс его пишет: в Windows поможет Process Monitor с фильтром по имени файла, в Linux — lsof по пути. Расписание регламентных заданий 1С от этого файла не зависит.

Не путайте с похожими объектами:

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

Причины удобно проверять от внешнего уровня к внутреннему — так же, как устроено хранение.

Где смотреть историю. В журнале регистрации (Администрирование → Обслуживание → Журнал регистрации в конфигурациях на БСП) поставьте отбор по событиям группы «Фоновое задание». Для каждого запуска видно начало, успешное завершение или ошибку с текстом исключения.

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

Скрипты для мониторинга регламентных заданий

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

Проверка флага блокировки по cron

Скрипт для Linux-сервера 1С. Он находит кластер и базу по имени и сигналит, если задания заблокированы.

#!/bin/bash
IB_NAME="buh"
RAC="/opt/1cv8/x86_64/<версия>/rac"

CL=$($RAC cluster list | awk '$1=="cluster"{print $3; exit}')
IB=$($RAC infobase summary list --cluster="$CL" \
     | awk -v n="$IB_NAME" '$1=="infobase"{id=$3} $1=="name" && $3==n {print id}')

STATE=$($RAC infobase info --cluster="$CL" --infobase="$IB" \
        --infobase-user="Монитор" --infobase-pwd="$IB_PWD" \
        | awk '$1=="scheduled-jobs-deny"{print $3}')

if [ "$STATE" = "on" ]; then
  echo "В базе $IB_NAME заблокированы регламентные задания"
  exit 1
fi

Ставьте в cron раз в 15–30 минут и отправляйте сообщение в мессенджер или почту при ненулевом коде выхода. Пароль держите в переменной окружения IB_PWD, а не в тексте скрипта.

Проверка последнего запуска изнутри базы

Внутри базы состояние задания доступно через менеджер РегламентныеЗадания. Пример для общего модуля с признаком «Сервер» — собирает задания, у которых последний запуск завершился ошибкой:

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

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

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