Как настроить регламентное задание в 1С

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

Настройка регламентного задания зависит от режима работы базы: в файловом варианте механизм существенно ограничен, а в клиент-серверном выполнением управляет сервер 1С:Предприятия. Перед началом работы важно понять, какой у вас режим, — от этого зависят и способ настройки, и типичные причины, по которым задание «не запускается».

Ниже разобран полный цикл: от создания задания в конфигураторе до проверки его выполнения через журнал регистрации, а также типичные ошибки и способы их диагностики.

Что такое регламентное задание и как оно работает

Регламентное задание — объект метаданных конфигурации, который связывает процедуру общего модуля с расписанием. Когда наступает время выполнения, платформа создаёт фоновое задание, которое и выполняет указанный код. Само регламентное задание — это лишь «шаблон», а фоновое задание — конкретный экземпляр его выполнения в момент времени.

Процедура, вызываемая заданием, должна располагаться в общем модуле с установленным флагом «Сервер». Если модуль не серверный, задание завершится с ошибкой сразу после запуска. Процедура не должна открывать формы и выводить диалоги — фоновое задание выполняется без пользовательского интерфейса.

Создание регламентного задания в конфигураторе

Откройте конфигуратор, в дереве конфигурации перейдите в ветку «Общие» → «Регламентные задания» и добавьте новый объект. Заполните основные свойства:

• Имя и синоним — техническое имя для обращения из кода и понятное название для администратора.
• Имя метода — путь к процедуре в формате ИмяОбщегоМодуля.ИмяПроцедуры.
• Расписание — задаётся кнопкой открытия редактора расписания (подробнее в следующем разделе).
• Использование — флаг, включающий задание. Без него задание существует, но не выполняется.
• Ключ — произвольная строка, не позволяющая запускать одновременно задания с одинаковым ключом.
• Количество повторов при аварийном завершении и интервал повтора — сколько раз платформа перезапустит задание после ошибки.

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

1. 1
   Создайте или выберите общий модуль с флагом «Сервер» и разместите в нём экспортную процедуру без параметров
2. 2
   Добавьте регламентное задание и укажите имя метода в формате Модуль.Процедура
3. 3
   Задайте расписание и включите флаг «Использование»
4. 4
   Обновите конфигурацию базы данных
5. 5
   В режиме предприятия проверьте, что задание активно и расписание применено
6. 6
   Дождитесь срабатывания и проверьте результат в журнале регистрации

Настройка расписания

Редактор расписания открывается по кнопке в свойстве «Расписание» и содержит несколько вкладок: «Общие», «Дневное», «Недельное», «Месячное». На вкладке «Общие» задаются дата начала и окончания действия расписания, а также интервал повторения в течение дня — например, каждые 600 секунд с 8:00 до 20:00.

Типовые сценарии расписаний:

• Раз в день ночью — для тяжёлых операций (пересчёт итогов, архивация): время начала, например, 02:00, без повтора в течение дня.
• Каждые N минут в рабочее время — для обменов и загрузки данных: задайте интервал повторения и границы дня.
• По будням — на вкладке «Недельное» снимите галочки с субботы и воскресенья.
• Раз в месяц — на вкладке «Месячное» укажите конкретный день месяца.

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

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

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

В файловом варианте у платформы нет постоянно работающего сервера, поэтому задания выполняются только при наличии специального сеанса-исполнителя. Классический способ — запустить отдельный сеанс 1С с параметром командной строки /ExecuteScheduledJobs (в новых версиях — соответствующий параметр запуска отдельного сеанса выполнения заданий) под выделенным пользователем. Пока этот сеанс открыт, задания выполняются; при закрытии сеанса выполнение прекращается.

Сравнение вариантов

Клиент-серверный режим

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

Файловый режим с сеансом-исполнителем

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

Внешний планировщик + пакетный запуск

Запуск 1С в пакетном режиме по расписанию Windows с выполнением обработки. Гибко, но требует отдельной разработки и логирования.

Пользователь, от имени которого выполняется задание

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

Рекомендуется завести отдельного служебного пользователя (например, «Робот») с ровно теми ролями, которые нужны для выполнения заданий, и указать его в свойствах задания. Это упрощает аудит: в журнале регистрации сразу видно, какие действия выполнял механизм, а не живой пользователь. Не давайте служебному пользователю полные права без необходимости — при ошибке в коде задания ущерб будет больше.

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

Основной инструмент проверки — журнал регистрации («Администрирование» → «Обслуживание» → «Журнал регистрации»). Отфильтруйте события по имени регламентного задания: для каждого запуска фиксируются начало, успешное завершение или ошибка с текстом исключения. Если задание завершилось аварийно, текст ошибки в журнале обычно указывает строку модуля и причину.

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

Контрольные точки

Как проверить результат

Состояние задания в консоли заданий

Норма

Задание активно, есть дата последнего успешного выполнения

Тревожный признак

Задание заблокировано, отключено или давно не выполнялось

Журнал регистрации

Норма

События успешного выполнения в ожидаемое время

Тревожный признак

События ошибки с текстом исключения или полное отсутствие записей

Прикладной результат

Норма

Данные появились/обновились (курсы загружены, обмен выполнен)

Тревожный признак

Задание «успешно» отработало, но данных нет — логика процедуры отработала вхолостую

Типичные ошибки и их причины

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

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

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

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

Как запустить регламентное задание вручную, не дожидаясь расписания?

В типовых конфигурациях откройте «Администрирование» → «Обслуживание» → «Регламентные и фоновые задания», найдите задание и нажмите «Выполнить сейчас». Программно можно использовать метод РегламентныеЗадания.НайтиПоУникальномуИдентификатору и запуск через фоновое задание с тем же методом.

Почему задание не работает в файловой базе, хотя расписание настроено?

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

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

В клиент-серверном режиме откройте консоль кластера, свойства информационной базы и установите флаг «Блокировка регламентных заданий включена». В файловом режиме при открытии копии платформа обычно сама предлагает заблокировать выполнение заданий — согласитесь с этим предложением.

Чем регламентное задание отличается от фонового?

Регламентное — объект конфигурации с расписанием, «шаблон» запуска. Фоновое — конкретный экземпляр выполнения, созданный платформой по расписанию или программно. Состояние и ошибки смотрят именно у фоновых заданий.

Задание выполняется успешно, но данные не меняются. В чём дело?

Чаще всего логика процедуры отрабатывает вхолостую: отбор не находит данных, условие не выполняется или транзакция откатывается без ошибки. Добавьте в код запись в журнал регистрации о количестве обработанных объектов — это сразу покажет, делает ли процедура реальную работу.