Интеграция магазина с логистикой и доставкой в Узбекистане: как это работает на практике

Почему интеграция с логистикой — это не "добавить телефон курьера"

Когда магазин делает первые десятки заказов в день, доставка обычно держится на менеджере, который вручную звонит в курьерскую службу, диктует адрес и переписывает трек-номер в Excel. Это работает ровно до момента роста. На 100+ заказах ручная обработка превращается в источник ошибок: потерянные адреса, неправильные тарифы, заказы, которые "зависли" между складом и курьером. Интеграция с логистикой — это автоматическая передача заказа в систему перевозчика, получение трек-номера и статусов обратно, расчёт стоимости в момент оформления и единая картина по всем отправлениям.

В Узбекистане эта задача имеет свою специфику: рынок служб доставки фрагментирован, у части перевозчиков нет публичного API, а покупатель в регионах часто ждёт наложенный платёж и доставку до пункта выдачи, а не курьером до двери.

Какие службы доставки доступны в Узбекистане

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

• Экспресс-доставка по городу и between-city. Yandex Delivery (Яндекс Доставка), Express24 и локальные курьерские сервисы закрывают быструю доставку внутри Ташкента и крупных городов. У них чаще всего есть API или хотя бы личный кабинет с экспортом.
• Межрегиональная и почтовая логистика. Узбекистон Почтаси (Pochta), BTS Express, Fargo, EMU и подобные службы везут заказы в областные центры и районы, имеют сеть отделений и пунктов выдачи.
• Маркетплейс-логистика. Если вы продаёте через Uzum Market или похожие площадки, доставка идёт по правилам маркетплейса, и интеграция сводится к работе с его API продавца.
• Собственная курьерская служба. Многие магазины держат 2–3 своих курьеров на город — тогда "интеграция" это внутренняя панель с маршрутами и статусами.

Расчёт стоимости доставки

Стоимость доставки должна считаться в момент оформления заказа, иначе вы либо теряете деньги на занижении, либо отпугиваете покупателя завышенной суммой. Тариф в Узбекистане обычно зависит от региона (Ташкент / область / районы), веса и габаритов, типа доставки (до двери или до ПВЗ) и наличия наложенного платежа.

Есть два подхода. Первый — динамический расчёт через API перевозчика: магазин отправляет адрес и параметры посылки, получает точную цену. Это идеально, но доступно не у всех служб. Второй — тарифная матрица на стороне магазина: вы заранее заносите зоны и цены, а система считает по таблице. Это менее точно, но работает с любым перевозчиком и не зависит от доступности его сервера в момент заказа.

Трекинг и статусы заказа

После передачи заказа перевозчику клиент хочет видеть, где его посылка. Здесь работает связка из двух механизмов: получение трек-номера при создании отправления и обновление статусов. Статусы приходят либо через вебхук (перевозчик сам шлёт уведомление, когда статус меняется), либо магазин периодически опрашивает API по расписанию (polling).

Вебхуки предпочтительнее: статус обновляется мгновенно, нет лишней нагрузки. Но не все узбекские службы их поддерживают, поэтому на практике часто делают гибрид — вебхуки там, где есть, и фоновый опрос раз в 15–30 минут для остальных. Статус полезно сразу транслировать клиенту: SMS или сообщение в Telegram "Заказ передан курьеру", "Доставлен в пункт выдачи". Это снижает количество звонков в поддержку.

Пункты выдачи (ПВЗ) и доставка в регионы

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

Технически это требует справочника пунктов выдачи. Хорошо, если перевозчик отдаёт его через API и обновляет сам. Если нет — справочник придётся вести и синхронизировать вручную, и здесь легко получить ситуацию, когда покупатель выбрал закрывшийся пункт. Поэтому ПВЗ-данные стоит обновлять регулярно и проверять перед отправкой.

Наложенный платёж — обязательная реалия

Значительная часть покупателей в Узбекистане предпочитает оплату при получении. Это меняет логику интеграции: при создании отправления нужно указать сумму наложенного платежа, а после доставки — получить от перевозчика подтверждение оплаты и факт перечисления денег магазину. Сверка инкассации (сколько перевозчик собрал и сколько перечислил) — отдельный важный блок, который нельзя вести "на глаз". Автоматическое сопоставление выплат с заказами экономит часы бухгалтерии и ловит расхождения.

Автоматизация: что именно убирает ручной труд

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

• создание отправления у перевозчика сразу после подтверждения заказа;
• печать накладной и стикера со штрих-кодом;
• обновление статуса заказа в админке магазина по данным перевозчика;
• уведомления клиента по SMS/Telegram на ключевых этапах;
• сверка наложенных платежей и выплат;
• возвраты и отмены без перебивания данных вручную.

Технические нюансы интеграции в Узбекистане

Реальность рынка: у части перевозчиков API либо отсутствует, либо нестабильно, либо документация неполная. Поэтому интеграцию нужно строить устойчиво к сбоям — с очередью повторных попыток, логированием каждого запроса и фолбэком, когда сервис перевозчика недоступен (заказ не теряется, а ставится в очередь на повторную отправку). Платёжная часть обычно завязана на местные системы Payme, Click, Uzum — и их статусы стоит увязывать с логистикой, чтобы не отправлять неоплаченный заказ там, где предполагалась предоплата.