Запуск обработки как регламентное задание в 1С

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

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

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

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

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

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

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

Способ 1: запуск через «Дополнительные отчеты и обработки» БСП

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

Чтобы обработка поддерживала такой режим, в её модуле объекта должна быть экспортная функция СведенияОВнешнейОбработке(), возвращающая структуру с описанием: вид «ДополнительнаяОбработка», версия, и таблица команд. Для фонового выполнения команда должна иметь поле Использование со значением «ВызовСерверногоМетода» — тогда БСП сможет выполнить её без открытия формы.

1. 1
   В модуле объекта обработки добавьте функцию СведенияОВнешнейОбработке() с командой вида «ВызовСерверногоМетода»
2. 2
   Откройте раздел «Администрирование» → «Печатные формы, отчеты и обработки» и включите использование дополнительных отчетов и обработок
3. 3
   Добавьте файл обработки в справочник «Дополнительные отчеты и обработки»
4. 4
   В карточке обработки откройте команду и включите опцию «Выполнять по расписанию»
5. 5
   Настройте расписание и дождитесь первого запуска, затем проверьте журнал регистрации

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

Способ 2: собственное регламентное задание в конфигураторе

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

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

Процедура ВыполнитьВнешнююОбработку() Экспорт

	// Файл должен быть доступен серверу 1С
	ПутьКФайлу = "C:\1C_Обработки\ВыгрузкаДанных.epf";

	Обработка = ВнешниеОбработки.Создать(ПутьКФайлу, Ложь);
	Обработка.ВыполнитьОсновнуюПроцедуру();

КонецПроцедуры

Обратите внимание: путь к файлу интерпретируется на сервере 1С, а не на компьютере разработчика. Файл должен лежать в каталоге, доступном учетной записи, под которой работает агент сервера 1С. Надежная альтернатива — хранить двоичные данные обработки в самой базе (в справочнике или хранилище значения) и при запуске сохранять её во временный файл через ПолучитьИмяВременногоФайла().

Если обработка небольшая и меняется редко, разумнее перенести её код прямо в общий модуль и отказаться от внешнего файла — это убирает зависимость от диска и упрощает обновление.

Требования к коду обработки для фонового выполнения

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

Обработка должна корректно работать в транзакционной логике сервера. Рекомендуется оборачивать критичные операции в попытку/исключение с записью ошибки в журнал регистрации через ЗаписьЖурналаРегистрации() — иначе при сбое вы просто увидите «задание завершено с ошибкой» без деталей. Для длительных операций полезно писать в журнал промежуточные этапы: «начата загрузка», «обработано N записей», «завершено успешно».

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

Настройка расписания и параметров задания

Расписание настраивается в стандартном диалоге: периодичность (ежедневно, еженедельно, ежемесячно), время начала, интервал повторения в течение дня, дни недели. Для задания «каждые 15 минут в рабочее время» задается повтор с паузой и ограничение по времени начала и окончания дня.

У регламентного задания есть параметры, влияющие на надежность. «Количество повторов при аварийном завершении» и «Интервал повтора при аварийном завершении» определяют, будет ли платформа перезапускать упавшее задание. Для обменов с внешними системами разумно задать 2–3 повтора с паузой в несколько минут: временная недоступность веб-сервиса не должна отменять обмен до следующего дня. «Имя пользователя» задает, от чьего имени выполняется задание — от этого зависят права на данные.

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

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

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

Отдельно стоит проверить прикладной результат, а не только технический статус. Задание может завершаться «успешно», но ничего не делать: например, отбор вернул пустую выборку, или условие в коде не сработало. Полезно, чтобы обработка сама фиксировала в журнале количество обработанных объектов — тогда «выполнено, обработано 0 записей» сразу выглядит подозрительно.

Безопасность и ограничения самостоятельной настройки

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

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

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