Подключение Достависты

Достависта (в международном контуре — Borzo) — это агрегатор курьеров для доставки внутри города «день в день»: пеший или автокурьер забирает заказ с вашего склада и везёт клиенту за пару часов. Готового типового обработчика в 1С-Битрикс для неё нет, поэтому подключение всегда идёт через API — либо модулем из Маркетплейса, либо собственным обработчиком доставки. Разберём, как это устроено технически и на что смотреть при внедрении.

Когда Достависта уместна в магазине

Достависта закрывает узкую, но важную нишу — срочная внутригородская доставка. Это не межгород и не сеть ПВЗ: курьер берёт посылку в одной точке города и отвозит в другую в тот же день. Поэтому в Битрикс её обычно заводят как отдельную службу доставки рядом со СДЭК или Почтой России, а не вместо них.

Типовые сценарии, где она выигрывает:

• магазины с локальным складом или пунктом самовывоза, откуда можно быстро отгрузить;
• товары, которые нужны клиенту «сегодня» — цветы, продукты, электроника, запчасти;
• пиковые дни, когда своих курьеров не хватает и нужен подхват сторонними.

API и доступ

Интеграция строится поверх business-API Достависты. Боевой контур — https://robot.dostavista.ru/api/business/1.4/, тестовый — https://robotapi.dostavistatest.ru/api/business/1.4/. Каждый запрос авторизуется токеном, который передаётся в заголовке X-DV-Auth-Token. Токен вы берёте в личном кабинете клиента Достависты в разделе для разработчиков.

Основные методы, которые нужны магазину:

Запрос — это JSON с массивом точек points (забор и доставка с адресами и телефонами), общим весом total_weight_kg и типом транспорта vehicle_type_id. Ответ по calculate-order содержит итоговую стоимость, которую и показывают покупателю.

Два пути подключения

Есть два способа встроить Достависту в Битрикс, и выбор зависит от того, насколько нестандартна ваша корзина.

1. Модуль из Маркетплейса. Быстрее: ставите решение, вводите токен, город и адрес склада — служба появляется в списке доставок. Подходит для типовой корзины на компонентах sale.order.ajax или sale.basket.basket. Минус — вы ограничены логикой автора модуля и зависите от его обновлений под новые версии API.
2. Собственный обработчик доставки. Гибче: вы пишете класс-наследник \Bitrix\Sale\Delivery\Services\Base, который сам дёргает calculate-order, и вешаете создание заявки на события заказа. Это правильный путь для магазинов с кастомным оформлением, мультискладом или своей логикой выбора курьера.

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

Обработчик расчёта стоимости

Ядро интеграции — расчёт цены в корзине. Собственный обработчик доставки в Битрикс реализуется классом с конфигурацией и методом расчёта, который возвращает объект \Bitrix\Sale\Delivery\CalculationResult. Внутри метода вы формируете запрос к calculate-order: адрес забора берёте из настроек службы (склад магазина), адрес доставки — из свойств заказа (город, улица, дом покупателя), вес — суммируете по корзине.

Чтобы каждое обращение к корзине не било по API Достависты, расчёт стоит кэшировать на короткое время по ключу «адрес + вес + тип транспорта». Это снимает нагрузку и ускоряет пересчёт корзины при смене количества товара.

Если API недоступен или вернул ошибку, обработчик должен корректно вернуть результат с ошибкой, а не «ронять» весь расчёт доставки. Иначе покупатель вообще не сможет выбрать другую службу и оформить заказ.

Автосоздание заявки на курьера

Расчёт цены и вызов курьера — разные вещи. Показать стоимость можно на этапе корзины, а вот create-order имеет смысл дёргать позже, когда заказ реально готов к отгрузке. Для этого используют события модуля sale:

• OnSaleOrderSaved — заказ сохранён;
• OnSaleStatusOrderChange / OnSaleDeliveryOrderStatusChange — смена статуса, например «Оплачен» или «Собран».

В обработчике события вы проверяете, что заказ использует службу Достависты и достиг нужного статуса, собираете точки маршрута и вызываете create-order. Полученный order_id Достависты нужно сохранить в свойство заказа — по нему потом запрашивают статус и, при необходимости, отменяют доставку через cancel-order.

Лимиты, транспорт и адрес забора

У Достависты стоимость и сама возможность доставки зависят от типа транспорта. Пеший курьер везёт небольшие лёгкие посылки, легковой автомобиль — крупнее и тяжелее, для габаритного груза нужен более вместительный транспорт. Тип задаётся полем vehicle_type_id, и его выбор влияет на цену расчёта.

Что обязательно учесть в настройках службы:

• Адрес забора — точный адрес склада/магазина с контактным телефоном; он один для всех заявок или свой для каждого склада при мультискладе;
• Ограничения по весу и габаритам — заведите их в Битрикс как условия доставки, чтобы служба не предлагалась для заведомо неподъёмного заказа;
• Зону действия — Достависта работает в конкретных городах; ограничьте службу по группам местоположений, чтобы она не появлялась там, где курьеров нет.

Ограничения удобно продублировать штатными условиями служб доставки Битрикс — тогда некорректный заказ отсекается ещё до обращения к API.

Диагностика и типовые ошибки

Когда доставка «не считается» или заявка не уходит, проверяйте по порядку:

1. Токен и контур. Боевой токен на тестовом URL (и наоборот) даёт ошибку авторизации. Убедитесь, что X-DV-Auth-Token соответствует окружению.
2. Исходящий HTTPS. С консоли сервера: curl -I https://robot.dostavista.ru/api/business/1.4/. Закрытый фаервол или отсутствие доступа наружу — частая причина «тишины».
3. Адрес не геокодируется. Если API отвечает ошибкой по точке — проверьте, что город и улица собраны в корректную строку.
4. Вес и транспорт. Нулевой вес корзины или неподходящий vehicle_type_id дают отказ в расчёте.

Итог

Подключение Достависты к Битрикс — это интеграция по API из трёх частей: авторизованный доступ с токеном X-DV-Auth-Token, обработчик расчёта стоимости через calculate-order для корзины и автосоздание заявки на курьера через create-order по событию заказа. Отдельно продумывают лимиты по весу и транспорту, точный адрес забора, зону работы и защиту от повторного вызова курьера.

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