Индивидуальное ПО интернет-магазина с интеграцией доставки

Интеграция: это не одно соединение, а четыре отдельные задачи: создание отправления, выпуск этикетки, отслеживание статуса и уведомление покупателя. При создании отправления данные заказа переводятся в формат, которого ждёт перевозчик: адрес получателя, вес или объём и способ оплаты. Выпуск этикетки следует из ответа, поскольку перевозчик возвращает штрихкод и трек-номер.

Отслеживание статуса требует больше всего усилий. Перевозчик сообщает, что посылка в пути, передана курьеру, доставлена или возвращена, либо когда его об этом спрашивают, либо обращаясь к собственному адресу уведомлений. Программа использует один из этих двух способов или применяет оба сразу. Само уведомление: это электронное письмо, SMS или строка статуса на странице личного кабинета, и его источником всегда служит запись отслеживания.

• Создание отправления: перевод данных заказа в формат перевозчика
• Этикетка и штрихкод: печать одним щелчком на складе
• Отслеживание статуса: периодический опрос или обновления, которые присылает перевозчик
• Уведомление покупателя: автоматическое сообщение при смене статуса
• Учёт исключений: неудачная доставка, возврат, повреждение

Перевозчики и курьеры работают с разной скоростью, и данные у них тоже разные. Служба доставки посылок везёт отправление несколько дней и сообщает о нём по этапам. Городской курьер доставляет в тот же день и нередко показывает положение в реальном времени и ожидаемое время прибытия. Чтобы свести обоих в один процесс, программе нужен собственный общий словарь статусов доставки.

Работает это так: каждая компания присылает свой код статуса, а программа сопоставляет его с одним из собственных состояний, например «готовится», «в пути», «передано курьеру», «доставлено» или «проблема». Покупателю не нужно знать, какая именно компания везёт его посылку, а команде не нужно запоминать код каждой компании. Когда в систему добавляется новая компания, растёт только таблица соответствий, а сами экраны остаются прежними и не меняются.

Статус заказа и статус доставки не одно и то же, и хранить их нужно раздельно. Заказ описывает собственные этапы магазина: оплата получена, подтверждён, готовится. Доставка начинается, когда отправление передано перевозчику. Если оба статуса хранятся в одном и том же поле, то при частичных отправках, возвратах и обменах запись теряет всякий смысл.

Если в заказе три товара, два уходят сегодня, а один позже, то записей о доставке две, а записей о заказе одна. Именно здесь индивидуальное решение оправдывает себя по сравнению с готовым пакетом: вы можете описать частичную отправку, разделение по складам или время отсечки для доставки в тот же день по собственным правилам.

Сохраняйте вид для покупателя простым. Для каждого отдельного отправления странице личного кабинета нужны всего один статус, ожидаемая дата доставки и ссылка для отслеживания посылки. Показ необработанного текста статуса перевозчика обычно больше запутывает, чем информирует.

Сервис перевозчика иногда не отвечает, формат адреса отклоняется системой перевозчика или уведомление приходит с опозданием. Качество интеграции видно не тогда, когда всё работает как надо, а тогда, когда что-то ломается. Если создание отправления не удалось, сам заказ не должен пропасть. Он должен попасть в очередь повторных попыток, а команда должна видеть на одном экране, какие заказы удерживаются.

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

• Автоматическая повторная попытка для неудавшихся отправлений и список ожидания, который видит команда
• Уникальный ключ отправления, предотвращающий дублирующие запросы
• Ошибки проверки адреса сначала сообщаются команде, а не покупателю
• Возврат к опросу, если уведомление об отслеживании не приходит

Большинство готовых платформ электронной коммерции предлагают готовые подключения к распространённым перевозчикам. Для магазина, который отправляет заказы с одного склада через несколько стандартных компаний, этого обычно хватает, и индивидуальная разработка ему не нужна. Критерий: не число перевозчиков, а то, укладываются ли ваши бизнес-правила в стандартный процесс.

Индивидуальное решение оправданно, когда один заказ собирается из нескольких складов или остатков магазинов, когда срок доставки рассчитывается по товару или региону, когда правило выбирает между курьером и перевозчиком, когда в B2B-отгрузке накладные встроены в процесс или когда нужен двусторонний обмен данными с ERP. В таких случаях готовые плагины либо не справляются с задачей, либо превращаются в заплатки, наложенные друг на друга.

Бизнесу, который отправляет несколько заказов в день, пользуется одним перевозчиком и без труда передаёт трек-номера вручную, индивидуальная интеграция пока рано. Готового модуля доставки платформы или собственного кабинета перевозчика достаточно. Настоящая потребность обычно состоит в том, чтобы упорядочить сам процесс, а не в том, чтобы писать программу.

Если процесс ещё не устоялся, то и программа не сможет его закрепить. Сначала в течение целого месяца записывайте, как ручной процесс идёт на самом деле: какой заказ идёт с какой компанией, какие ошибки повторяются, о чём покупатели спрашивают чаще всего. Эта запись станет списком требований для любой последующей интеграции и с самого начала уберёт из неё лишний объём работ.

Самая частая ошибка: строить только счастливый путь: отправление создано, доставлено. Если возвраты, неудачные доставки, повреждённые посылки и частичные отправки не проработаны как отдельные случаи, команда по-прежнему ведёт их вручную в таблицах, и польза от интеграции теряется наполовину, ведь основная часть работы остаётся прежней.

Вторая ошибка: переносить коды статусов перевозчика прямо в интерфейс, так что смена перевозчика означает смену каждого экрана. Третья: не проверять уведомления: тестовая среда перевозчика может вести себя иначе, чем рабочая, и первый настоящий заказ приносит сюрприз. Четвёртая: не учитывать сопровождение. Интерфейсы перевозчиков со временем меняются, поэтому за интеграцией нужно следить как за живой частью всей системы.