Отправить одно письмо из 1С относительно просто. Сложнее обеспечить надежную работу, когда сообщения клиентам формируются автоматически: почтовый сервер может быть временно недоступен, соединение может оборваться, в данных получателя может оказаться ошибка, а повторный запуск обработки не должен приводить к двум одинаковым письмам.
Поэтому очередь сообщений в 1С нужна не только для последовательной отправки email. Ее основная задача — отделить возникновение бизнес-события и подготовку сообщения от фактической передачи письма почтовому серверу. Тогда неудачная попытка отправки не приводит к потере сообщения, а результат каждой операции можно проконтролировать.
Практическая схема выглядит так:
бизнес-событие → данные 1С → подготовка сообщения → очередь → попытка отправки → результат → повторная попытка при необходимости → журнал
Такой подход особенно важен для автоматических клиентских коммуникаций: подтверждений заказов, уведомлений об оплате, напоминаний о сроках, сообщений о готовности заказа и отправки документов.
Зачем нужна очередь сообщений в 1С
Если письмо формируется и отправляется непосредственно в момент проведения документа или выполнения другой пользовательской операции, бизнес-процесс начинает зависеть от внешней системы.
Например, в 1С зарегистрирована оплата клиента. По правилу после этого необходимо отправить подтверждение. Если в этот момент почтовый сервер недоступен, возможны два нежелательных сценария: пользователь получает техническую ошибку во время своей обычной работы либо письмо просто не уходит и о проблеме никто не узнает.
Очередь устраняет эту связь.
В момент возникновения события система фиксирует, что сообщение необходимо подготовить или отправить. Само обращение к почтовому серверу может выполняться отдельно. Если отправка завершилась ошибкой, запись остается в очереди и может быть обработана повторно.
Важно не считать наличие очереди обязательной штатной функцией любой конфигурации 1С. Реализация зависит от конкретного прикладного решения, его версии и используемых расширений. Здесь очередь рассматривается как архитектурный механизм надежной автоматической коммуникации.
Из каких частей состоит отправка email из 1С
Для надежной отправки полезно разделять четыре разных элемента: учетную запись электронной почты, содержание сообщения, очередь и транспорт отправки.
| Элемент | За что отвечает |
|---|---|
| Учетная запись электронной почты | Определяет параметры подключения, необходимые для отправки почты |
| Шаблон сообщения | Определяет структуру и оформление письма |
| Данные 1С | Заполняют персональные значения: клиента, номер документа, сумму, дату, состояние заказа и другие реквизиты |
| Очередь сообщений | Хранит задания на отправку и результаты их обработки |
| Почтовый транспорт | Выполняет фактическую передачу сформированного письма почтовому серверу |
| Журнал | Позволяет установить, что, кому и с каким результатом отправлялось |
Наличие почтового адреса отправителя само по себе недостаточно. Например, официальная справка фирмы «1С» «Как в „1С:Бухгалтерии 8“ настроить учетную запись электронной почты» подтверждает, что для отправки писем непосредственно из программы должна быть настроена учетная запись электронной почты.
Конкретные поля и способы настройки зависят от конфигурации. Поэтому при проектировании автоматизации лучше не переносить инструкции одной типовой конфигурации на другую без проверки.
Подготовка сообщения и отправка — разные операции
Это принципиальное разделение.
Подготовка сообщения отвечает на вопросы: почему нужно написать клиенту, кому нужно написать и что должно быть в письме.
Отправка отвечает на другой вопрос: удалось ли передать уже подготовленное сообщение через используемый канал.
Рассмотрим пример.
В 1С зарегистрировано поступление оплаты по счету №1548. На основании этого состояния срабатывает правило коммуникации. Из учетной системы определяются клиент, контактный email, номер счета, сумма поступившей оплаты и менеджер. По шаблону формируется письмо:
Здравствуйте, Иван.
Оплата по счету №1548 получена.
Сумма поступившей оплаты: 125 000 руб.
Спасибо.
На этом этапе сообщение уже можно считать подготовленным, но еще нельзя считать отправленным.
Следующий этап — помещение его в очередь и попытка передачи через настроенную почтовую учетную запись.
Такое разделение позволяет сохранить сформированное сообщение даже тогда, когда SMTP-сервер временно недоступен.
Что должна хранить запись очереди
Чтобы контроль отправки сообщений в 1С был действительно полезным, одной отметки «отправлено / не отправлено» недостаточно.
В записи очереди обычно имеет смысл связывать сообщение с исходным бизнес-событием и сохранять техническую информацию, необходимую для обработки.
Практическая модель может содержать следующие данные:
| Данные | Назначение |
|---|---|
| Идентификатор сообщения | Позволяет однозначно определить запись |
| Источник | Документ, заказ, платеж или другое событие 1С |
| Получатель | Адрес, определенный на момент формирования |
| Шаблон | Правило или шаблон, по которому создано сообщение |
| Тема и содержание | Подготовленное сообщение или данные для его формирования |
| Дата создания | Когда возникла необходимость отправки |
| Текущий статус | На каком этапе находится сообщение |
| Количество попыток | Сколько раз выполнялась отправка |
| Время последней попытки | Нужно для диагностики |
| Следующая попытка | Используется механизмом повторной обработки |
| Последняя ошибка | Помогает понять причину сбоя |
| Время успешной отправки | Фиксирует завершение операции |
Это не перечень обязательных реквизитов типовой 1С, а рекомендуемая структура собственной очереди сообщений.
Особенно важна связь сообщения с исходным объектом. Без нее сотрудник видит техническую ошибку отправки, но не понимает, к какому заказу, счету или клиенту она относится.
Какие статусы нужны очереди сообщений
Статусы отправки сообщений в 1С должны описывать реальное состояние обработки, а не смешивать несколько разных признаков в одном поле.
Для собственной очереди можно использовать модель, подобную следующей:
| Статус | Что означает |
|---|---|
| Подготовлено | Сообщение сформировано и ожидает обработки |
| В обработке | Система начала попытку отправки |
| Ожидает повторной попытки | Предыдущая попытка не удалась, но отправку можно повторить |
| Отправлено | Почтовый транспорт успешно обработал операцию отправки |
| Ошибка | Автоматическое продолжение невозможно без устранения причины |
| Требует проверки | Сообщение должно быть проверено сотрудником |
Названия могут быть другими. Важнее однозначно определить смысл каждого состояния.
Например, статус «Ошибка» не должен одновременно означать временную недоступность сервера, отсутствие адреса клиента и необходимость согласовать содержание письма. Это разные ситуации и требуют разных действий.
Следует также аккуратно трактовать слово «Отправлено». Оно фиксирует успешный результат операции, контролируемой вашей системой. Сам по себе такой статус не означает, что адресат прочитал письмо. Если необходим контроль последующей доставки или других событий почтовой инфраструктуры, это уже отдельная задача и она должна поддерживаться используемым почтовым сервисом и интеграцией.
Повторная отправка сообщений в 1С
Автоматическая повторная отправка полезна только для ошибок, которые действительно могут исчезнуть без вмешательства человека.
Например, соединение с почтовым сервером временно недоступно. Повторить попытку позднее разумно.
Совсем другая ситуация — у клиента отсутствует email. Сколько бы раз система ни запускала отправку, корректный адрес сам не появится.
Поэтому механизм повторной отправки должен сначала классифицировать результат.
| Ситуация | Что делать |
|---|---|
| Временная ошибка соединения | Оставить сообщение в очереди и повторить позднее |
| Временная недоступность почтового сервера | Повторить после паузы |
| Не заполнен адрес получателя | Остановить автоматические попытки и показать ошибку данных |
| Некорректны настройки учетной записи | Остановить поток и привлечь администратора |
| Сообщение требует решения сотрудника | Перевести на ручную проверку |
| Сообщение потеряло актуальность | Не отправлять автоматически после устранения задержки |
Последний случай часто упускают.
Предположим, клиенту необходимо сообщить: «Ваш заказ будет доставлен завтра». Из-за технической ошибки письмо несколько дней остается в очереди. Автоматически отправлять его после восстановления связи уже нельзя — содержание потеряло смысл.
Поэтому для части сообщений кроме повторных попыток нужен срок актуальности.
Почему нельзя повторять отправку бесконечно
Бесконечный цикл повторных попыток маскирует проблему вместо ее решения.
Если причина связана с временным транспортным сбоем, система может выполнить новую попытку позднее. При повторении одной и той же ошибки интервалы между попытками разумно увеличивать, а после установленного условия переводить сообщение в состояние, требующее внимания.
При этом предельное количество попыток и интервалы не следует задавать универсально для всех компаний. Они зависят от критичности сообщения и бизнес-процесса.
Подтверждение получения заказа может оставаться актуальным достаточно долго. Сообщение о скором времени доставки имеет гораздо более короткий жизненный цикл.
Поэтому надежность означает не «отправить любой ценой», а получить управляемый результат: отправить актуальное сообщение либо вовремя показать человеку, почему это невозможно.
Как избежать повторной отправки одного письма
Повторная обработка создает еще один риск — дубли.
Например, система передала письмо почтовому серверу, но не успела записать успешный результат из-за сбоя. При следующем запуске сообщение снова выглядит неотправленным.
Поэтому одной проверки статуса недостаточно. Архитектура очереди должна предусматривать защиту от одновременной обработки одной записи и максимально однозначную идентификацию каждой коммуникации.
Бизнес-правило тоже должно отвечать на вопрос: создавалось ли сообщение по этому событию ранее.
Например, если основанием является поступление конкретной оплаты, повторный запуск фоновой обработки не должен каждый раз создавать новое подтверждение одной и той же операции.
Именно поэтому источник сообщения — документ, операция или другое событие — желательно сохранять вместе с идентификатором сформированной коммуникации.
Контроль ошибок отправки в 1С
Фраза «письмо не отправилось» слишком мало говорит для диагностики.
Контроль ошибок отправки в 1С должен позволять ответить хотя бы на четыре вопроса:
Что отправлялось? Нужно видеть клиента, источник сообщения и его содержание.
Когда возникла проблема? Необходимы дата создания и время последней попытки.
На каком этапе произошел сбой? Ошибка могла возникнуть еще при подготовке сообщения, при определении адресата либо непосредственно при соединении с почтовым сервером.
Требуется ли вмешательство человека? Система должна отличать ситуацию для автоматического повтора от ситуации, которую должен исправить пользователь или администратор.
Практически это означает, что техническое сообщение об ошибке нужно сохранять рядом с понятным бизнес-контекстом.
Запись «ошибка соединения» полезна администратору. Для менеджера гораздо важнее видеть: «Не отправлено подтверждение оплаты клиенту ООО „Альфа“ по счету №1548».
Что проверять, если письма перестали отправляться
Диагностику лучше проводить последовательно от бизнес-данных к инфраструктуре.
Сначала следует установить, было ли вообще создано сообщение. Если запись в очереди отсутствует, проблема находится до этапа отправки: не сработало правило, не выполнено условие или не удалось сформировать данные.
Если сообщение создано, следует проверить получателя и содержимое. Затем — состояние очереди и текст последней ошибки. Только после этого имеет смысл переходить к параметрам почтовой учетной записи, доступности почтового сервера и сетевому соединению.
Такой порядок принципиален. Проверка SMTP не поможет, если сообщение никогда не попало в очередь.
Журнал отправленных сообщений в 1С
Очередь отвечает на вопрос «что требуется обработать сейчас». Журнал — «что происходило раньше».
Эти задачи лучше не смешивать.
Журнал отправленных сообщений в 1С полезен для работы менеджеров, поддержки и администраторов. По нему можно установить, какое письмо было сформировано, кому оно предназначалось, какое событие стало основанием, когда выполнялась отправка и какой результат был получен.
История отправленных писем в 1С особенно важна для событийной коммуникации. Если клиент сообщает, что не получал подтверждение оплаты, сотруднику не следует начинать расследование с почтового сервера. Сначала он должен открыть историю коммуникаций по этому клиенту или документу и увидеть фактическую цепочку обработки.
При этом журнал желательно рассматривать как историю операций, а не как еще одну папку электронной почты. Его ценность именно в связи письма с бизнес-объектами 1С.
Очередь email в 1С и фоновые задания
Очередь сама по себе ничего не отправляет. Нужен процесс, который регулярно находит сообщения, готовые к обработке, и выполняет попытки отправки.
В конкретной реализации это может быть регламентная или иная серверная обработка, предусмотренная архитектурой решения.
Важно, чтобы обработчик корректно работал при повторном запуске. Если предыдущий запуск завершился аварийно, система должна понимать, какие записи уже были обработаны, какие можно повторить и какие требуют проверки.
Для больших очередей имеет значение и последовательность. Обычно сначала должны обрабатываться сообщения, срок отправки которых уже наступил. При этом критичные коммуникации могут иметь собственный приоритет.
Однако приоритеты, количество параллельных обработчиков и частота запуска — это уже параметры конкретной системы. Их нельзя универсально переносить между разными информационными базами.
Когда сообщение можно отправлять полностью автоматически
Автоматическая отправка безопаснее всего для предсказуемых сценариев, где событие и содержание однозначны.
Например:
Поступила оплата → определить плательщика → сформировать подтверждение → отправить.
Данные для сообщения берутся непосредственно из 1С: клиент, сумма, документ расчетов, дата платежа и другие необходимые реквизиты.
Если такое сообщение формируется по стабильному шаблону и не содержит решения сотрудника, его можно помещать в очередь автоматической отправки.
Иная ситуация — перенос срока по важному заказу. Данные в 1С могут быть корректными, но менеджер должен сначала проверить формулировку и контекст сообщения. Тогда событие создает готовое письмо со статусом «Требует проверки», а отправка выполняется после подтверждения.
Таким образом, очередь полезна и для автоматических, и для контролируемых человеком сценариев.
Шаблон сообщения не должен управлять надежностью отправки
Шаблон отвечает за содержание и оформление. Очередь — за доставку сформированного сообщения до почтовой инфраструктуры.
Смешивать эти уровни неудобно.
Изменение фирменного оформления письма не должно менять механизм повторных попыток. И наоборот, недоступность SMTP-сервера не должна заставлять систему заново определять бизнес-событие или изменять текст уже подготовленного сообщения без явной причины.
Для надежной архитектуры полезна последовательность:
событие → данные → правило → шаблон → готовое сообщение → очередь → отправка → журнал
Так легче диагностировать каждый этап отдельно.
Как очередь сообщений используется в событийной коммуникации
После организации надежного механизма отправки можно перейти от отдельных писем к полноценной событийной модели.
В Алертариуме исходной точкой становится событие в 1С. Система определяет подходящее правило коммуникации, получает необходимые данные, формирует персонализированное сообщение и в зависимости от сценария направляет его на автоматическую отправку либо на предварительную проверку сотрудником.
Очередь при этом отвечает за техническую надежность последующего процесса.
Например:
Событие: заказ получил состояние, при котором клиента необходимо уведомить о готовности.
Получатель: контактное лицо клиента, определенное по данным 1С.
Содержание: номер заказа, дата, информация о готовности и контакты ответственного сотрудника.
Режим: автоматическая отправка для стандартных заказов либо предварительная проверка для выбранных сценариев.
Результат: успешная отправка или зафиксированная ошибка с возможностью дальнейшего контроля.
После обработки коммуникация сохраняется в журнале.
Где фактически должна отправляться почта
При использовании Алертариума важно разделять управление коммуникацией и почтовую инфраструктуру клиента.
Правила, шаблоны и другие настройки могут централизованно управляться с использованием облачной части решения. Но фактическая отправка email и учетные данные почтового сервера остаются в локальной 1С клиента.
То есть пароль от корпоративной почты не требуется переносить в сторонний облачный сервис только ради того, чтобы бизнес-события автоматически создавали сообщения.
С точки зрения процесса цепочка выглядит так:
событие 1С → правило Алертариума → персонализированное сообщение → очередь → локальная почтовая учетная запись 1С → результат отправки → журнал
Так бизнес-логика коммуникации остается связанной с учетными данными и событиями 1С, а технический результат каждой отправки можно контролировать.
Что должно получиться после настройки
Надежная очередь сообщений — это не просто список неотправленных писем.
В рабочей системе можно однозначно определить, почему было создано каждое сообщение, кому оно предназначено, отправлялось ли оно, сколько попыток выполнялось, какая ошибка возникла и требуется ли действие сотрудника.
При этом временный технический сбой не приводит к потере коммуникации, повторный запуск обработки не должен бесконтрольно создавать дубли, а устаревшее сообщение не отправляется клиенту только потому, что когда-то оказалось в очереди.
Именно такая архитектура превращает автоматическую отправку email из вспомогательной функции в управляемый бизнес-процесс.
Для этого следует разделить бизнес-событие, формирование сообщения и техническую отправку; хранить состояние обработки; классифицировать ошибки; выполнять повторную отправку только там, где она оправдана; сохранять связь сообщения с исходным объектом 1С; фиксировать результат в журнале и выводить исключительные ситуации на контроль сотруднику.
Автоматизация надежных клиентских сообщений
Очередь, повторные попытки и журнал решают техническую часть задачи. Следующий уровень — автоматически определять сам момент коммуникации: поступила оплата, изменился заказ, наступил срок или сформирован документ.
Тогда сотруднику не приходится каждый раз помнить, что клиенту необходимо написать. Бизнес-событие в 1С запускает заранее определенное правило, данные автоматически попадают в шаблон, после чего готовое сообщение проходит через контролируемую очередь отправки.
Автоматизируйте клиентские коммуникации в 1С с Алертариумом. Система сама создаст и отправит нужное сообщение по событию, сократит ручную работу менеджеров и ускорит информирование клиентов. Начните с нескольких ключевых сценариев сейчас.