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

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

Выбор способа зависит от того, откуда берётся параметр. Если значение известно заранее и меняется редко — удобнее хранить его в базе и читать внутри задания. Если параметр определяется в момент запуска (например, при ручном выполнении из обработки) — подойдёт метод ВыполнитьОбработкуЗадания с передачей массива параметров. Если значение зависит от пользователя или контекста сеанса — используются параметры сеанса.

Ниже разобраны все рабочие варианты с примерами кода, ограничениями каждого подхода и типичными ошибками, из-за которых задание либо падает, либо молча работает не с теми данными.

Почему у регламентного задания нет параметров «из коробки»

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

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

Способ 1. Передача параметров через консоль заданий БСП

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

Ключевой момент: метод ФоновыеЗадания.Выполнить принимает имя процедуры, массив параметров, ключ и наименование. Параметры передаются позиционно, и их типы должны быть сериализуемыми — то есть допустимыми для передачи между клиентом и сервером (примитивные типы, структуры, массивы, ссылки). Передать, например, COM-объект или запрос нельзя.

ПараметрыПроцедуры = Новый Массив;
ПараметрыПроцедуры.Добавить(Организация);        // ссылка
ПараметрыПроцедуры.Добавить(НачалоМесяца(ТекущаяДатаСеанса()));

ФоновыеЗадания.Выполнить("ОбменДаннымиСервер.ВыгрузитьПоОрганизации",
    ПараметрыПроцедуры, "Выгрузка_" + Организация.УникальныйИдентификатор(),
    "Выгрузка по " + Организация);

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

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

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

Пример: задание «Загрузка курсов валют» должно работать с разной глубиной истории для разных компаний. Создаётся регистр сведений «НастройкиЗаданий» с измерением «ИмяЗадания» и ресурсом «Значение» (или составным ресурсом). Метод задания первым делом читает свою настройку по имени и дальше работает с полученным значением.

Процедура ЗагрузитьДанныеПоНастройке() Экспорт
    Запрос = Новый Запрос("ВЫБРАТЬ Значение ИЗ РегистрСведений.НастройкиЗаданий
        |ГДЕ ИмяЗадания = &Имя");
    Запрос.УстановитьПараметр("Имя", "ЗагрузкаДанных");
    Выборка = Запрос.Выполнить().Выбрать();
    Если Не Выборка.Следующий() Тогда
        ВызватьИсключение "Не задана настройка задания ЗагрузкаДанных";
    КонецЕсли;
    ПериодЗагрузки = Выборка.Значение;
    // далее основная логика с использованием ПериодЗагрузки
КонецПроцедуры

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

Способ 3. Параметры сеанса и предопределённые ключи

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

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

Отдельный приём — использование свойства «Ключ» регламентного задания. Создаётся несколько предопределённых заданий с одним методом, но разными ключами, а метод по ключу определяет, с каким «параметром» работать. Ключ доступен внутри через получение текущего фонового задания. Это удобно, когда вариантов немного и они фиксированы: «Выгрузка_Опт», «Выгрузка_Розница».

Организация вызова: процедура-обёртка и диспетчер

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

Пример структуры: регистр «ОчередьЗадачЗадания» с измерением «ИдентификаторЗадачи» и ресурсами «Параметр1…ПараметрN» либо одним ресурсом типа «ХранилищеЗначения», куда сериализуется структура параметров. Хранилище значения удобно, когда состав параметров заранее не фиксирован.

1. 1
   Создайте регистр сведений для настроек задания (измерение — имя или идентификатор задачи, ресурсы — значения параметров)
2. 2
   Напишите рабочую процедуру с параметрами в общем серверном модуле
3. 3
   Напишите метод-обёртку без параметров: читает настройки и вызывает рабочую процедуру
4. 4
   Привяжите обёртку к регламентному заданию, задайте расписание
5. 5
   Заполните настройки в базе и запустите задание вручную для проверки
6. 6
   Проверьте результат и журнал регистрации на наличие ошибок

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

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

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

Типичные ошибки и ограничения

Частая ошибка — объявить метод задания с параметрами и ждать, что платформа «как-нибудь» их подставит. Задание падает при первом же запуске по расписанию, хотя ручной вызов из кода работал. Вторая типичная проблема — передача несериализуемых типов (табличный документ, запрос, COM-объект) в ФоновыеЗадания.Выполнить: возникает ошибка сериализации. Передавайте ссылки и примитивы, а сложные объекты стройте уже внутри фоновой процедуры.

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

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