Разработка модуля отслеживания доставки для 1С-Битрикс

Разработка модуля отслеживания доставки для 1С-Битрикс

Покупатель оформил заказ и ждёт посылку. Если он каждый раз вынужден идти на сайт службы доставки, копировать трек-номер и искать статус — это плохой опыт, который снижает лояльность и увеличивает нагрузку на поддержку. Автоматизация отслеживания решает эту проблему: статусы обновляются сами, пользователь видит их в личном кабинете и получает уведомления. Такое решение экономит до 80% времени на ручную проверку — это результат наших проектов для интернет-магазинов с 500+ заказами в день. Закажите разработку модуля для вашего магазина — получите консультацию в течение дня.

Автоматизация доставки: почему это необходимо

Ручное обновление статусов — источник ошибок и задержек. Менеджеры тратят часы на копирование трек-номеров, а клиенты нервничают из-за отсутствия информации. Автоматизация снимает эту нагрузку: модуль сам опрашивает API служб доставки, записывает историю и оповещает покупателя. По нашим замерам, конверсия повторных покупок растёт на 15–25% после внедрения трекинга в личном кабинете. Автоматизация лучше ручного отслеживания в 3–5 раз по скорости реакции на изменения.

Техническая реализация

Источники данных

Трек-номер появляется в заказе после его передачи в службу доставки. В Битрикс он хранится в поле TRACKING_NUMBER таблицы b_sale_order_delivery или в пользовательском свойстве заказа. Модули доставки (DPD, CDEK, Boxberry, Почта России) хранят трек-номер по-разному — это учитывается при реализации адаптеров.

Обновление статусов

Cron-задача запускается каждые 30 минут по умолчанию, интервал настраивается под нагрузку. Скрипт выбирает заказы в статусах, предполагающих активную доставку (DELIVERY, DELIVERING), получает для каждого актуальные статусы от провайдера, сравнивает с последним записанным в b_tracking_status. Если статус изменился — пишется новая запись и выставляется флаг NOTIFIED = 0. Следующий проход обходит записи с NOTIFIED = 0 и отправляет уведомления. Это гарантирует, что клиент узнаёт о движении посылки в течение часа после события.

Поддержка служб доставки

Модуль может подключать любые службы через единый интерфейс адаптеров. Адаптеры разрабатываются под REST или SOAP API конкретного провайдера. Это позволяет одновременно использовать несколько служб на одном сайте и быстро добавлять новые без изменения ядра модуля. Например, в проектах с 3+ провайдерами мы используем общий интерфейс DeliveryProviderInterface.

Архитектура модуля

local/modules/vendor.tracking/ ├── lib/ │ ├── Provider/ # Адаптеры для API служб доставки │ │ ├── CdekProvider.php │ │ ├── DpdProvider.php │ │ └── RussianPostProvider.php │ ├── TrackingService.php # Оркестратор │ └── StatusMapper.php # Нормализация статусов ├── install/ │ └── db/install.sql └── cron/ └── update_statuses.php 

Таблица b_tracking_status — история статусов по каждому заказу:

Интеграция с API

Каждый провайдер реализует интерфейс:

interface DeliveryProviderInterface { public function getStatuses(string $trackingNumber): array; public function getProviderCode(): string; } 

СДЭК использует REST API v2. Получение токена через POST /v2/oauth/token, статусы через GET /v2/orders?cdek_number={number}. Ответ содержит массив statuses с полями code, name, date_time, city. Подробнее об API СДЭК — на Wikipedia.

Почта России предоставляет SOAP-сервис https://tracking.russianpost.ru/rtm34. Метод getOperationHistory возвращает XML с операциями по отправлению. Парсинг через SoapClient или через прямой разбор XML с помощью SimpleXMLElement. Протокол SOAP описан в документации Microsoft.

DPD — REST API, трекинг через GET /api/tracing/order/{trackingNumber}.

Нормализация статусов

Каждый провайдер имеет свои коды статусов. StatusMapper приводит их к единому набору:

Это позволяет строить единый интерфейс трекинга независимо от службы доставки. Статус DELIVERED отображается зелёной иконкой, FAILED — красной с предложением связаться с поддержкой.

Типичные проблемы и их решение

Race conditions при записи статусов — когда несколько пакетов данных приходят одновременно, можно получить дубли строк. Используем INSERT ... ON DUPLICATE KEY UPDATE с уникальным индексом по ORDER_ID + EVENT_TIME. Лимиты API — у СДЭК есть ограничение 5 запросов в секунду, у Почты России — 10. В модуле встроена очередь с тайм-аутом и повторными попытками. Дублирование уведомлений — решается через флаг NOTIFIED, который проверяется перед отправкой.

Уведомления и виджет

При смене статуса покупатель получает:

• Email через почтовое событие TRACKING_STATUS_CHANGED. Шаблон содержит: текущий статус, трек-номер, ссылку на страницу заказа, кнопку «Отследить на сайте службы доставки».
• Push-уведомление (если реализован web push) — короткое сообщение о смене статуса.

Страница заказа в личном кабинете показывает timeline доставки — все события в хронологическом порядке с иконками статусов. Данные берутся из b_tracking_status по ORDER_ID без обращения к API провайдера — это быстро и не зависит от доступности внешнего сервиса.

Процесс разработки

1. Аудит текущей системы доставки и выбор провайдеров.
2. Разработка адаптеров для каждого API (REST/SOAP).
3. Нормализация статусов и единая таблица истории.
4. Настройка cron-задач и агентов Битрикс.
5. Интеграция с уведомлениями (email, push).
6. Виджет timeline в личном кабинете.
7. Документация по эксплуатации и коду.
8. Поддержка после запуска (гарантия 30 дней).

Наш опыт — более 50 проектов по автоматизации доставки на Битрикс. Мы знаем типовые проблемы: лимиты API, дублирование уведомлений, race conditions — и избегаем их на этапе проектирования. Свяжитесь с нами для точной оценки вашего проекта — рассчитаем стоимость и сроки под ключ.

Сроки разработки

Получите консультацию по интеграции модуля отслеживания доставки уже сегодня.