Почему уведомления в 1С:ЗУП КОРП висят в статусе Подготовлено и как настроить их отправку?

← На главную

В конфигурации Зарплата и управление персоналом КОРП (редакция 3.1) реализован мощный механизм уведомлений сотрудников и ответственных лиц о различных кадровых событиях. Однако часто пользователи сталкиваются с тем, что система формирует уведомления, но они «замирают» в статусе Подготовлено и не уходят получателям. Разберем по шагам, как диагностировать эту проблему и какие настройки необходимо проверить для восстановления работоспособности рассылки.

Проанализируем двухэтапный процесс работы уведомлений

Для начала нам необходимо понять, что рассылка в 1С состоит из двух независимых процессов. Если один из них дает сбой, цепочка прерывается. Рассмотрим их подробнее:

Формирование записей: Система отслеживает бизнес-события (например, подачу заявления на отпуск) и создает записи в специальном регистре сведений. В этот момент сообщению присваивается статус Подготовлено.
Транспортная отправка: Специальное регламентное задание обращается к этому регистру, формирует на основе записей электронные письма (или SMS) и отправляет их через почтовый сервер. Только после успешного ответа сервера статус меняется на Отправлено.

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

Шаг 1. Проверка регламентных заданий

Разберем работу планировщика заданий. За рассылку отвечает регламентное задание ОтправитьУведомления. Нам нужно убедиться, что оно включено и выполняется без ошибок.

Перейдем в раздел Администрирование — Обслуживание — Регламентные и фоновые задания. Найдем в списке задание «Отправка уведомлений». Проанализируем колонку «Состояние». Если там указано «Задание выполнено», но статус сообщений не изменился, попробуем запустить его вручную кнопкой «Выполнить сейчас».

Важный нюанс: Если задание выполняется подозрительно быстро (0–1 секунда), это может означать, что оно не находит объектов для обработки из-за неверных фильтров или отсутствия данных в очереди.

Шаг 2. Настройка «Сведений о публикации»

Одной из самых неочевидных причин блокировки отправки является отсутствие настроек публикации базы. 1С:ЗУП КОРП часто вставляет в уведомления ссылки на личные кабинеты сотрудников. Если система не знает собственного адреса в сети, она не может корректно сформировать текст письма и «откладывает» отправку.

Выясним, заполнены ли эти данные. Перейдем в Настройки — Управление персоналом — Сведения о публикации объекта. Здесь должен быть указан корректный URL-адрес веб-сервера, на котором опубликована информационная база. Без этой настройки типовой механизм формирования ссылок внутри ОбъектыУведомлений может работать некорректно.

Шаг 3. Проверка учетной записи электронной почты

Проанализируем настройки почты. Даже если тестовое сообщение из карточки учетной записи уходит успешно, рассылка может не работать. Проверьте следующие параметры в разделе Администрирование — Настройки почты:

Убедитесь, что Системная учетная запись настроена корректно.
Проверьте, установлены ли галочки «Использовать для отправки» и «Использовать для рассылки».
Обратите внимание на поле «Имя отправителя» — некоторые почтовые серверы (особенно корпоративные) блокируют письма, если это поле пустое.
В версиях 1С:ЗУП выше 3.1.18.119 проверьте параметр Использовать электронную подпись. Если он включен ошибочно, отправка будет заблокирована.

Шаг 4. Анализ контактной информации получателей

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

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

Шаг 5. Очистка очереди и работа с журналом регистрации

Если в системе накопилось много «битых» записей (например, уведомления для уволенных сотрудников или людей без адресов), регламентное задание может тратить весь свой лимит времени на попытки их обработки. Рассмотрим, как это проверить.

Откроем Журнал регистрации и установим фильтр по событию «Рассылка уведомлений». Ищем записи с уровнем «Ошибка». Часто там можно встретить детальное описание, например:

Ошибка при вызове метода контекста (Отправить): Не указан адрес получателя

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


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ОчередьУведомлений.КоличествоПопытокОтправки,
    |	ОчередьУведомлений.СостояниеУведомления
    |ИЗ
    |	РегистрСведений.ОчередьУведомлений КАК ОчередьУведомлений
    |ГДЕ
    |	ОчередьУведомлений.СостояниеУведомления = ЗНАЧЕНИЕ(Перечисление.СостоянияУведомлений.Подготовлено)";

РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
    Сообщить("В очереди найдено " + РезультатЗапроса.Выгрузить().Количество() + " необработанных записей.");
КонецЕсли;

Шаг 6. Обновление конфигурации

Если все настройки верны, но уведомления не уходят, следует обратить внимание на версию программы. Разработчики признали наличие ошибок в механизме уведомлений в релизах 3.1.18.82. Посмотрим на рекомендации: исправления были внесены в версии 3.1.18.119 и выше. Рекомендуется обновить конфигурацию до актуального релиза (например, ветки 3.1.23 или 3.1.27), где работа с регистром ОчередьУведомлений была существенно оптимизирована.

Радикальное решение: Внешняя обработка

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

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