Почтовые уведомления о заказах

Каждое действие с заказом в 1С-Битрикс — оформление, оплата, смена статуса, отмена — способно породить письмо клиенту или менеджеру. За это отвечает механизм почтовых событий модуля sale. Разберём, какие события существуют, как связать их с шаблонами, кому уходят письма и почему часть уведомлений не доходит.

Как устроены почтовые события заказов

В 1С-Битрикс письмо никогда не отправляется «напрямую из кода заказа». Работает цепочка из трёх звеньев: тип почтового события (символьный код вроде SALE_NEW_ORDER), один или несколько почтовых шаблонов, привязанных к этому типу и к сайту, и сам факт возникновения события — когда модуль sale его инициирует.

Все типы событий лежат в Настройки → Настройки продукта → Настройки почты → Типы почтовых событий, а шаблоны — в соседнем разделе Почтовые шаблоны. При наступлении события Битрикс не шлёт письмо сразу, а кладёт запись в таблицу очереди b_event. Дальше её разбирает почтовый агент ядра main и физически отправляет сообщение.

Основные типы событий заказов

Модуль интернет-магазина регистрирует свой набор типов почтовых событий. Их символьные коды устойчивы между проектами, что удобно при переносе шаблонов:

Ключевая тонкость — смена статуса. При переходе заказа генерируются сразу два события: общее SALE_STATUS_CHANGED и адресное SALE_STATUS_CHANGED_<ID>, где ID — символьный код статуса. Это позволяет отправлять разные письма на разные статусы, не размножая логику: под каждый статус свой тип события со своим шаблоном.

Шаблоны и подстановочные поля

Шаблон — это заготовка письма: тема, тело (текст или HTML), отправитель и получатель. В нём используются подстановочные поля в формате #FIELD#, которые модуль заменяет реальными данными заказа при отправке. Самые ходовые:

• #ORDER_ID# и #ORDER_ACCOUNT_NUMBER# — внутренний ID и внешний номер заказа;
• #ORDER_DATE#, #ORDER_STATUS# — дата и текущий статус;
• #PRICE#, #ORDER_LIST# — сумма и состав заказа;
• #EMAIL# — e-mail покупателя;
• #SALE_EMAIL# — служебный e-mail магазина из настроек модуля.

Набор доступных полей у каждого типа события свой — их список выводится прямо на странице редактирования шаблона в блоке описания. Не все поля универсальны: например, ссылка на оплату есть в письмах об оплате, но не в письме об отмене.

Получатели: клиент и менеджер

Кому уйдёт письмо, определяет поле «Кому» (TO) в шаблоне. Здесь и кроется разделение на письмо покупателю и уведомление менеджеру:

1. Клиенту. В поле «Кому» ставят подстановку #EMAIL# — адрес из заказа. Отправитель (FROM) — служебный e-mail магазина, чтобы ответы шли на почту магазина.
2. Менеджеру. Создают второй шаблон того же типа события и в поле «Кому» прописывают фиксированный адрес отдела продаж (или #SALE_EMAIL#). Так на один SALE_NEW_ORDER уйдёт и подтверждение клиенту, и сигнал менеджеру.

Служебный e-mail магазина задаётся в Настройки → Настройки продукта → Настройки модулей → Интернет-магазин, а e-mail сайта по умолчанию — в настройках модуля main и в свойствах самого сайта (Настройки → Настройки продукта → Сайты). Если поле FROM в шаблоне пустое, подставляется e-mail сайта.

Очередь, агент и способ отправки

После наступления события письмо попадает в таблицу b_event и ждёт отправки. За разбор очереди отвечает почтовый агент модуля main — CEvent::CheckEvents(). Режим отправки настраивается в Настройки → Настройки продукта → Настройки модулей → Главный модуль → Почта, параметр «Способ отправки почтовых сообщений»:

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

Если выбран режим «по времени», а агенты работают на хитах на малопосещаемом сайте, письма могут уходить с задержкой. Решение — вынести агенты на cron, как и для остальных фоновых задач Битрикс. Тогда очередь b_event разбирается регулярно, независимо от посещаемости.

Доставляемость: чтобы письма не падали в спам

Сгенерированное письмо — половина дела; вторая половина в том, дойдёт ли оно. Типовая проблема магазинов — уведомления улетают в спам или отбиваются почтовыми сервисами. Что проверять:

• Домен отправителя. FROM должен быть на домене магазина (shop@ваш-домен.ru), а не на постороннем адресе. Письма «от имени Gmail» через ваш сервер провайдеры режут.
• SPF, DKIM, DMARC. Записи в DNS домена должны разрешать вашему серверу или SMTP-шлюзу отправку. Без них крупные сервисы понижают доверие к письму.
• Реальный SMTP. Отправка через системный mail() ненадёжна. Для боевого магазина подключают SMTP (модуль «Почта» / транспорт через настройки, либо сторонний сервис рассылок), где авторизация и подпись писем настроены корректно.

Итог

Почтовые уведомления о заказах в 1С-Битрикс строятся на связке «тип события → шаблон → очередь b_event → агент отправки». Ключевые типы — SALE_NEW_ORDER, SALE_STATUS_CHANGED и адресные SALE_STATUS_CHANGED_<ID>, SALE_ORDER_PAID, SALE_ORDER_CANCEL. Кому уйдёт письмо, решает поле «Кому» шаблона: #EMAIL# для клиента и фиксированный адрес для менеджера, причём на одно событие можно повесить оба письма. Отдельно держите под контролем режим отправки, cron и доставляемость — SPF, DKIM и адекватный SMTP.

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