После отправки SMS через SMPP-шлюз протокол возвращает статусы доставки (DLR). Если выгружать их в систему учёта 1С, можно автоматически отмечать оплаченные заказы, фиксировать неверные номера и не звонить клиенту с вопросом «пришло ли сообщение?». Статья объясняет, как построить такую схему для небольшого магазина без программиста в штате.
Почему статусы доставки важны для учёта заказов?
Когда интернет-магазин отправляет клиенту уведомление о статусе заказа, важно знать, дошло ли оно. SMPP-шлюз возвращает коды: DELIVRD (доставлено), EXPIRED (просрочено), UNDELIV (не доставлено), REJECTD (отклонено оператором). Если эти данные попадают в 1С, менеджер видит, что SMS получена, и не тратит время на ручную проверку. Для магазина с 20–50 заказами в день это экономит 2–3 часа в неделю.
Протокол SMPP версий 3.4 и 5.0 поддерживает подробные коды ошибок (источник dev.sms-assistent.by). В SMPP 5.0, если команда SUBMIT_SM_RESP возвращает ошибку, длина PDU составляет 16 октетов (источник BSG). Это значит, что парсер должен уметь обрабатывать разную длину пакетов. Но для малого бизнеса чаще используют SMPP 3.4 — с ним совместимы почти все белорусские операторы.
Что нужно для интеграции SMPP и 1С?
Минимальный набор:
- SMPP-шлюз с возможностью отправки и получения DLR (обычно провайдер SMS даёт доступ к шлюзу);
- скрипт-посредник (например, на PHP или Python), который забирает статусы из шлюза и передаёт их в 1С через HTTP-запросы;
- обработка в 1С, принимающая POST-запросы и обновляющая документы (заказы, счета).
Если у вас нет возможности писать скрипт, можно использовать готовые модули обмена, которые некоторые SMS-провайдеры предлагают для 1С. Но чаще нужен простой посредник. Вот как он работает.
Схема работы: от отправки до отметки в 1С
- Отправка. Вы создаёте документ «Отправка SMS» в 1С. Обработка вызывает скрипт, который через SMPP отправляет сообщение и запоминает message_id.
- Получение DLR. SMPP-шлюз асинхронно отправляет скрипту уведомление о доставке (или ошибке) с тем же message_id.
- Передача в 1С. Скрипт передаёт в 1С POST-запрос с JSON:
{"message_id":"...","status":"DELIVRD","timestamp":"..."}. - Обновление статуса. В 1С обработчик находит заказ по message_id (или по номеру телефона+времени) и проставляет флаг «SMS доставлена» или «Ошибка доставки».
Всё это происходит за 1–3 секунды после фактической доставки. Для интернет-магазина такой подход позволяет сразу видеть, что клиент получил уведомление об оплате или отгрузке.
Какие статусы стоит обрабатывать?
Не все коды нужны в учёте. Вот таблица статусов, которые имеют практический смысл для магазина.
| Код статуса | Значение | Что делать в 1С |
|---|---|---|
| DELIVRD | Сообщение доставлено | Отметить заказ как «Уведомление отправлено» |
| UNDELIV | Не доставлено (номер неверный, абонент недоступен) | Пометить контакт для проверки; предложить другой способ связи |
| EXPIRED | Истекло время жизни SMS | Похоже на UNDELIV — обновить телефон клиента |
| REJECTD | Отклонено оператором (спам, блокировка) | Проверить текст сообщения или имя отправителя |
| ACCEPTD | Принято шлюзом, но ещё не доставлено | Ничего не делать; ждать финального статуса |
Для автоматизации достаточно обрабатывать только DELIVRD, UNDELIV и REJECTD. Остальные можно логировать, но не влиять на учёт.
Типичные ошибки при настройке выгрузки
- Не сопоставлен message_id. Если скрипт не сохраняет связь между отправленным сообщением и заказом, пришедший DLR не к чему привязать. Решение — передавать в SMPP дополнительный параметр (TLV), например номер заказа.
- Дубликаты при повторной отправке. Если скрипт не проверяет, был ли уже обработан статус, 1С получит два одинаковых запроса. В обработчике 1С стоит проверять по уникальному message_id.
- Игнорирование кодов ошибок SMPP. Протокол возвращает не только финальный статус, но и промежуточные ошибки (см. источник dev.sms-assistent.by). Не учитывая их, можно потерять сообщения.
- Слишком высокая частота запросов к 1С. Если отправка идёт потоком, скрипт может завалить 1С HTTP-запросами. Лучше буферизовать статусы по 10–20 штук и передавать пачкой раз в минуту.
- Нет обработки таймаутов. Если скрипт не получил DLR в течение 24 часов, стоит считать сообщение недоставленным и повторять попытку.
3 шага, которые можно сделать сегодня
- Проверьте, возвращает ли ваш SMS-провайдер DLR и какие коды он использует. Большинство поддерживают стандарт SMPP 3.4 с кодами, описанными выше.
- Настройте простой скрипт-посредник, который забирает DLR из шлюза и складывает их в файл или базу данных. Это можно сделать за 2–3 часа на любом доступном языке.
- Добавьте в 1С обработчик HTTP-запроса, который принимает статусы и обновляет нужные документы. Пример кода для 1С:Предприятие 8.3 есть в типовых конфигурациях.
