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

← На главную

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

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

Решение №1. Проверка блокировки регламентных заданий в настройках базы на сервере

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

В современных версиях платформы 1С:Предприятие 8.3 существует защитный механизм. Когда вы копируете базу данных, разворачиваете ее из резервной копии (файла .dt или бэкапа СУБД) на тестовом сервере, платформа при первом запуске выдает диалоговое окно с вопросом: «Информационная база перемещена или восстановлена из резервной копии». Если администратор или программист нажимает кнопку «Это копия информационной базы», платформа автоматически устанавливает флаг блокировки регламентных заданий. Это сделано для безопасности: чтобы тестовая копия случайно не начала отправлять реальные письма клиентам или перезаписывать данные на рабочем сайте.

Для того чтобы снять эту блокировку вручную, выполним следующие действия:

Откроем консоль «Администрирование серверов 1С Предприятия» на сервере приложений.
Развернем дерево до списка информационных баз: Console root — Центральные серверы 1С:Предприятия — [Имя Вашего Сервера] — Кластеры — Локальный кластер — Информационные базы.
Найдем нашу базу в списке, нажмем на нее правой кнопкой мыши и выберем пункт «Свойства».
Сервер запросит имя пользователя и пароль администратора этой конкретной информационной базы. Введем их.
В открывшемся окне найдем флажок «Блокировка регламентных заданий включена» (или аналогичный в зависимости от версии платформы). Он должен быть снят. Если галочка установлена — снимаем ее и нажимаем «ОК» или «Применить».

После снятия этой блокировки сервер 1С начнет автоматически инициализировать фоновые процессы по расписанию.

Решение №2. Исправление критической ошибки несовпадения сигнатуры метода

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


Задание = РегламентныеЗадания.СоздатьРегламентноеЗадание(Метаданные.РегламентныеЗадания.аВыгрузитьДанныеДляОбмена);
Задание.ИмяПользователя = ПользователиИнформационнойБазы.НайтиПоИмени("Администратор");
Задание.Ключ = "ВыгрузкаДанных_123";
Задание.Использование = Истина;

мсПараметров = Новый Массив;
мсПараметров.Добавить("ПараметрВыгрузки");
Задание.Параметры = мсПараметров; // Передаем один параметр

Задание.Записать();

При этом в общем модуле процедура может быть объявлена следующим образом:


Процедура аВыгрузитьДанные() Экспорт
    // Логика выгрузки
КонецПроцедуры

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

Чтобы решить эту проблему, нам необходимо либо полностью очистить массив параметров перед записью задания:

Задание.Параметры = Новый Массив; // Если параметры методу не требуются

Либо изменить объявление самой процедуры в общем модуле, добавив в нее соответствующий параметр (можно с дефолтным значением для совместимости):


Процедура аВыгрузитьДанные(ИдентификаторВыгрузки = Неопределено) Экспорт
    // Логика выгрузки с использованием параметра
КонецПроцедуры

Решение №3. Правильная настройка свойств общего модуля

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

Сервер (Server): Этот флаг должен быть обязательно установлен. Регламентные задания выполняются исключительно на сервере в контексте специального фонового сеанса.
Вызов сервера (Call Server): Этот флаг часто устанавливают по ошибке. Для регламентных заданий он абсолютно бесполезен и даже вреден с точки зрения архитектурной чистоты и безопасности. Он предназначен только для того, чтобы тонкий или толстый клиент мог вызвать процедуру модуля напрямую. Поскольку регламентное задание выполняется в фоновом сеансе на сервере, клиентского контекста у него нет, и "вызывать" сервер клиенту не требуется. Снимите эту галочку.
Привилегированный (Privileged): Это крайне важный флаг, о котором часто забывают в самописных конфигурациях. Если регламентное задание выполняется под системной учетной записью или у назначенного пользователя ограничены права доступа (RLS), выполнение кода может прерваться из-за недостатка прав на чтение таблиц или запись файлов. Установка флага Привилегированный позволяет выполнять код регламентного задания в обход ограничений прав доступа, что гарантирует стабильность работы системных алгоритмов.

Решение №4. Устранение сбоев на этапе инициализации параметров сеанса

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

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

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


Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    
    // Проверим, выполняется ли код в фоновом задании
    Если ИмяПользователя() = "" Тогда 
        // Если имя пустое, возможно, это системный сеанс фонового задания
        // Инициализируем только базовые параметры сеанса без привязки к интерфейсу
        ПараметрыСеанса.ТекущийПользователь = Справочники.Пользователи.ПустаяСсылка();
        Возврат;
    КонецЕсли;
    
    // Обычная инициализация для интерактивных пользователей
    // ...
    
КонецПроцедуры

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

Решение №5. Синхронизация расписания и часовых поясов

Разберем ситуацию, когда расписание настроено, база активна, но задание все равно не стартует. Обратите внимание на настройки времени начала работы задания.

Если сервер 1С физически находится в другом часовом поясе (например, в Москве, а вы работаете в Волгограде или Екатеринбурге), время на сервере будет отличаться от времени вашего локального компьютера. Если вы указываете время начала выполнения, например, 11:38:00 по своему локальному времени, а на сервере в этот момент только 10:38:00, задание не запустится до тех пор, пока на часах сервера не наступит указанное время.

Рекомендации по настройке времени в расписании:

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


Расписание = Новый РасписаниеРегламентногоЗадания;
Расписание.ПериодПовтораВТечениеДня = 60; // каждые 60 секунд
Расписание.ВремяНачала = ТекущаяДатаСеанса(); // привязка к серверному времени
Расписание.ПериодПовтораДней = 1;
Задание.Расписание = Расписание;

Решение №6. Особенности тестирования и запуска в файловом режиме

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

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

Либо запустить хотя бы один активный клиентский сеанс (тонкий или толстый клиент), в котором периодически (например, в обработчике ожидания) будет выполняться метод ВыполнитьОбработкуЗаданий().
Либо настроить запуск отдельного служебного сеанса 1С через планировщик задач операционной системы Windows со специальным ключом запуска: "C:\Program Files\1cv8\...\1cv8.exe" ENTERPRISE /F "ПутьКБазе" /N "Робот" /P "Пароль" /C "ВыполнятьРегламентныеЗадания".

Без выполнения этих условий в файловой базе регламентные задания запускаться сами по себе не будут.

Решение №7. Как правильно отладить регламентное задание

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

Убедитесь, что служба сервера 1С запущена в режиме отладки. В параметрах запуска службы должен присутствовать ключ -debug.
Откройте базу данных в режиме Конфигуратора.
Перейдите в меню: Отладка — Подключение...
В открывшемся окне нажмите кнопку «Настройка автоматического подключения».
Установите флажок напротив пункта «Фоновые задания» и нажмите «ОК».
Установите точку останова в первой строке вашей экспортной процедуры общего модуля (например, внутри процедуры аВыгрузитьДанные).

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

Решение №8. Использование Технологического журнала для глубокого анализа

В особо сложных случаях, когда регламентное задание аварийно завершается на уровне самой платформы (например, из-за нехватки памяти, критических ошибок СУБД или внезапного падения рабочего процесса rphost), Журнал регистрации 1С останется абсолютно пустым. Единственный способ докопаться до истины — настроить Технологический журнал 1С.

Создайте в каталоге настроек платформы (обычно C:\Program Files\1cv8\conf) файл с именем logcfg.xml следующего содержания:


<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\1C_Logs\BackgroundJobs" history="24">
        <event>
            <eq property="Name" value="EXCP"/>
        </event>
        <event>
            <eq property="Name" value="backgroundJob"/>
        </event>
        <property name="all"/>
    </log>
</config>

Этот конфигурационный файл заставит платформу записывать все исключительные ситуации (события EXCP) и события фоновых заданий в каталог C:\1C_Logs\BackgroundJobs. Проанализировав сформированные текстовые файлы логов, вы гарантированно увидите истинную причину падения фонового процесса, даже если база была заблокирована или произошел сбой ядра СУБД.