Как реализовать уведомления в 1С: способы, код и настройка

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

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

Как выбрать механизм уведомлений под задачу

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

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

Мгновенные оповещения пользователей в сеансе

Метод ПоказатьОповещениеПользователя выводит немодальное сообщение в правом нижнем углу клиентского приложения. Он вызывается на клиенте и принимает текст, навигационную ссылку, пояснение и картинку. По клику пользователь может перейти к объекту — например, открыть документ, о котором идёт речь.

ПоказатьОповещениеПользователя(
    НСтр("ru = 'Заказ проведён'"),
    ПолучитьНавигационнуюСсылку(СсылкаНаЗаказ),
    Строка(СсылкаНаЗаказ),
    БиблиотекаКартинок.Информация,
    СтатусОповещенияПользователя.Важное);

Если оповещение нужно показать другому пользователю, а не текущему, на сервере создаётся объект ОповещениеПользователя и вызывается метод Отправить — сообщение дойдёт до активного сеанса указанного пользователя. Если сеанса нет, оповещение безвозвратно теряется, поэтому для важных событий этот способ применяют только как дополнение.

Параллельно существует СообщениеПользователю — оно выводится в панель сообщений и привязывается к форме. Такие сообщения подходят для ошибок проведения и предупреждений при записи, но не для уведомлений между пользователями.

Уведомления через систему взаимодействия

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

1. 1
   В конфигураторе или коде проверьте доступность: ИнформационнаяБазаЗарегистрирована()
2. 2
   Зарегистрируйте базу через меню Администрирование — Обсуждения или программно
3. 3
   Убедитесь, что у пользователей включено использование обсуждений в настройках
4. 4
   Создайте первое уведомление через объект УведомлениеПользователяСистемыВзаимодействия
5. 5
   Проверьте доставку: у адресата в панели обсуждений появится сообщение

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

Уведомление = Новый УведомлениеПользователяСистемыВзаимодействия;
Уведомление.Текст = "Требуется согласование заявки № " + НомерЗаявки;
Уведомление.Получатели.Добавить(ИдентификаторПолучателя);
Уведомление.Данные = СсылкаНаЗаявку;
СистемаВзаимодействия.ОтправитьУведомлениеПользователя(Уведомление);

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

Отложенные уведомления через регламентные задания

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

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

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

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

Собственная очередь уведомлений в базе

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

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

Уведомления на мобильный клиент и push

Для мобильного клиента платформа поддерживает push-уведомления через механизм доставляемых уведомлений: на сервере формируется объект ДоставляемоеУведомление, и платформа передаёт его на устройство через сервисы Apple Push или Google FCM. Настройка требует публикации мобильного приложения и регистрации сертификатов push-уведомлений.

Альтернатива без push — периодический опрос: мобильный клиент при запуске или по таймеру обращается к веб-сервису базы и забирает новые уведомления из очереди. Это проще в настройке, но сообщения приходят с задержкой и только при работающем приложении.

Частые ошибки и проверка результата

Самая распространённая ошибка — вызов клиентского метода оповещения в серверном коде. ПоказатьОповещениеПользователя недоступен на сервере: код либо не скомпилируется, либо молча не сработает. Для серверной логики используйте ОповещениеПользователя.Отправить, систему взаимодействия или запись в очередь.

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

FAQ