Доставка — это момент, где интернет-магазин чаще всего теряет деньги дважды: сначала на неточном тарифе, потом на брошенной корзине, когда покупатель не смог выбрать удобный пункт выдачи или не понял стоимость. DPD — одна из популярных служб, и её грамотная интеграция снимает обе проблемы: точный тариф по API, пункты выдачи на карте и понятный трекинг.
Это практический how-to по интеграции DPD с магазином на 1С-Битрикс: как выбрать между готовым модулем и своей интеграцией, рассчитывать тарифы, показывать пункты выдачи, создавать отправления, вести трекинг и синхронизировать всё с 1С. Если у вас нестандартная логистика или B2B-сценарии, интеграцию удобно проектировать вместе с автоматизацией продаж и склада на 1С.
Коротко
- Тариф DPD считают запросом к API в момент оформления — по направлению, весу, габаритам и типу услуги.
- Пункты выдачи выводят на карте: это дешевле курьера и повышает конверсию оформления.
- После создания отправления магазин ведёт трекинг по трек-номеру через агент и обновляет статусы.
- Ключевые поля доставки синхронизируют с 1С и делают интеграцию устойчивой к сбоям API.
Зачем интегрировать DPD глубоко
Можно ограничиться фиксированной стоимостью доставки «по городу столько, по России столько» — но это грубо и невыгодно. Для одних заказов вы переплатите из своего кармана, на других отпугнёте покупателя завышенной ценой. Глубокая интеграция с DPD решает это: тариф считается точно под конкретный заказ, а клиент видит реальную стоимость и срок.
Кроме точного тарифа глубокая интеграция даёт выбор пункта выдачи прямо на сайте, автоматическое создание отправлений без ручного ввода и трекинг в личном кабинете. Это и выше конверсия оформления, и меньше нагрузка на менеджеров, которые иначе вручную считают доставку и заводят посылки.
Модуль из Маркетплейса или своя интеграция
Первое решение — как подключать. Есть два пути с разным балансом скорости и гибкости.
| Критерий | Готовый модуль | Своя интеграция через API |
|---|---|---|
| Скорость запуска | Быстро | Дольше, нужна разработка |
| Гибкость логики | Ограничена автором | Полная, под ваши сценарии |
| Зависимость | От обновлений модуля | От вашей команды |
| B2B и нестандарт | Часто не покрывает | Покрывает |
| Стоимость | Ниже на старте | Выше, но управляемо |
Для типового розничного магазина готовый модуль часто закрывает задачу. Для сложной логистики, оптовых сценариев и особых правил расчёта делают собственную интеграцию через обработчик службы доставки. Иногда выбирают гибрид: модуль как основа плюс доработки.
Службы доставки и обработчики в Битрикс
В 1С-Битрикс доставка реализована через систему служб доставки и их обработчиков. Обработчик — это код, который отвечает за конкретную службу: он умеет рассчитывать стоимость, отдавать сроки, а в расширенном варианте — создавать отправления и получать статусы. DPD подключается именно как такой обработчик.
Штатная архитектура удобна тем, что доставка встраивается в стандартный процесс оформления заказа: обработчик получает состав корзины, адрес и параметры, возвращает варианты и стоимость. Собственная интеграция пишется по этому же контракту, поэтому корректно работает с корзиной, скидками на доставку и оформлением. Как устроена разработка таких расширений на платформе, мы разбираем в статье про разработку собственного модуля Битрикс.
Расчёт тарифа по API
Сердце интеграции — расчёт стоимости. В момент оформления магазин формирует запрос к API DPD с параметрами заказа и получает актуальную цену и срок:
- Собрать параметры. Город отправки и получения, суммарный вес и габариты, тип услуги, объявленная ценность.
- Отправить запрос. Обработчик обращается к API DPD за тарифом для этих параметров.
- Показать варианты. Покупателю выводятся способы (курьер, пункт выдачи) со стоимостью и сроком.
- Сохранить выбор. Выбранный вариант и его параметры фиксируются в заказе.
Ключевое требование — актуальность и точность. Тариф берётся из API в реальном времени, а не из устаревшей таблицы, поэтому клиент видит настоящую стоимость. Чтобы не дёргать API на каждый чих, ответы кэшируют на короткое время.
Вес, габариты и упаковка
Точность тарифа DPD упирается в вес и габариты — служба считает и по фактическому, и по объёмному весу. Если у товаров не заполнены эти свойства или корзина неправильно их суммирует, расчёт «плывёт»: занижение съедает вашу маржу, завышение отпугивает покупателя.
- Свойства товара. Вес и габариты должны быть заполнены у каждой позиции инфоблока.
- Суммирование в корзине. Общий вес и объём заказа считаются корректно, с учётом количества.
- Упаковка. Учитывается вес и объём тары, если он существенен.
- Источник данных. Вес и габариты обычно ведут в 1С и передают на сайт обменом.
Это самая частая причина неточных тарифов, поэтому проверку заполненности весогабаритных характеристик закладывают в подготовку каталога до запуска доставки.
Пункты выдачи на карте
Доставка до пункта выдачи дешевле курьерской и удобна части покупателей, поэтому её почти всегда стоит подключать. DPD отдаёт список пунктов через API, и его показывают на карте прямо на шаге оформления.
Покупатель выбирает удобный пункт — по адресу, режиму работы, близости к дому или работе, — а идентификатор пункта сохраняется в заказе и передаётся в DPD при создании отправления. Хорошая реализация подгружает пункты для выбранного города, показывает их на карте и в списке и запоминает выбор. Это снижает стоимость доставки для магазина и повышает конверсию: клиент находит вариант под себя.
Создание отправления и трек-номер
После оформления и подтверждения заказа отправление в DPD создаётся автоматически — без ручного заведения посылки менеджером. Магазин передаёт в API DPD данные заказа: получатель, адрес или пункт выдачи, состав, вес, тип услуги. В ответ DPD присваивает отправлению трек-номер.
Автоматизация этого шага экономит время и убирает ошибки ручного ввода. Трек-номер сохраняется в заказе и становится основой для дальнейшего трекинга. Часто на этом же этапе печатают транспортную этикетку. Автоматическое создание отправлений особенно ценно на потоке — оно снимает с менеджеров рутину и ускоряет отгрузку.
Трекинг и обновление статусов
Клиент хочет видеть, где его посылка, а поддержка не должна проверять это вручную. Трекинг решает обе задачи: магазин периодически запрашивает у API DPD статус по трек-номеру и обновляет статус заказа на сайте.
Технически это удобно делать агентом Битрикса — фоновой задачей по расписанию, которая проходит по активным отправлениям и подтягивает их статусы. При смене статуса магазин может уведомить покупателя письмом или пушем и обновить информацию в личном кабинете. Так клиент видит движение посылки, а менеджеры освобождаются от ручной сверки. Общие принципы безопасной работы с внешними API и обработки их ответов мы разбираем в статье про REST, вебхуки и безопасность в Битрикс.
Синхронизация с 1С
Если учёт и отгрузка ведутся в 1С, данные о доставке не должны жить только на сайте. Служба, тариф, трек-номер и статус доставки передаются в учётную систему обменом — иначе менеджеры работают в двух местах, а данные расходятся.
Правильная схема: сайт рассчитывает и оформляет доставку, а ключевые поля синхронизируются с 1С через обмен CommerceML или API. Тогда менеджер в 1С видит выбранную службу и трек-номер, а статус доставки согласован между системами. Настройку такого двустороннего обмена мы закрываем услугой автоматизации на 1С — доставка становится частью единого процесса, а не изолированным блоком на сайте.
Устойчивость к сбоям API
Внешний сервис не может быть доступен на 100%, и интеграцию проектируют с учётом сбоев. Главное правило — недоступность API DPD не должна блокировать оформление заказа.
- Запасной сценарий. Если API не ответил — ориентировочный тариф из кэша или расчёт позже с менеджером.
- Кэширование. Ответы API держат в кэше короткое время, чтобы не дёргать сервис и пережить кратковременные сбои.
- Логирование ошибок. Сбои фиксируются, чтобы видеть проблемы и реагировать.
- Таймауты. Запрос к API ограничен по времени, чтобы не подвешивать оформление.
Клиент не должен упираться в «доставка недоступна» из-за временного сбоя внешнего сервиса и бросать корзину. Устойчивость интеграции — это напрямую сохранённые заказы.
Частые ошибки
- Пустые вес и габариты. Тариф считается неверно, магазин теряет на марже или конверсии.
- Фиксированная стоимость вместо API. Грубый расчёт «по зонам» проигрывает точному тарифу DPD.
- Нет пунктов выдачи. Только курьер — упущенная конверсия и лишние расходы клиента.
- Ручное создание отправлений. Менеджеры заводят посылки вручную, теряя время и допуская ошибки.
- Нет трекинга. Клиент не видит статус, поддержка проверяет посылки вручную.
- Доставка не синхронизирована с 1С. Данные расходятся, менеджеры работают в двух системах.
- Сбой API блокирует заказ. Временная недоступность DPD роняет оформление и теряет корзину.
Чек-лист внедрения
- Способ подключения выбран. Готовый модуль или своя интеграция под сложность ваших сценариев.
- Весогабариты заполнены. У товаров есть вес и габариты, корзина суммирует их корректно.
- Тариф считается по API. Стоимость и срок берутся из DPD в реальном времени, ответы кэшируются.
- Пункты выдачи на карте. Клиент выбирает пункт, идентификатор сохраняется в заказе.
- Отправления создаются автоматически. Трек-номер присваивается без ручного ввода.
- Трекинг работает. Агент обновляет статусы, клиент видит движение, уведомления настроены.
- Синхронизация с 1С. Служба, трек-номер и статус попадают в учётную систему обменом.
- Устойчивость к сбоям. Запасной сценарий, таймауты и логирование не дают сбою API ронять заказ.
Вывод
Глубокая интеграция DPD превращает доставку из источника потерь в конкурентное преимущество: точный тариф по API убирает переплаты и отказы, пункты выдачи на карте повышают конверсию, автоматическое создание отправлений и трекинг снимают рутину с менеджеров и держат клиента в курсе.
Начните с корректных весогабаритов и расчёта по API, добавьте пункты выдачи и автоматические отправления, настройте трекинг агентом и синхронизацию с 1С — и не забудьте про устойчивость к сбоям внешнего сервиса. Тогда доставка перестанет терять заказы и станет частью единого, надёжного процесса продаж.
