29.05.2018

Система разделения заказов «dukanfood»

Задача

Сегодня к нам попал очень интересный проект. С одной стороны, мы получили обычный интернет-магазин, с другой - две независимые платформы, которые взаимодействуют только по API и собственный сервис, реализующий их взаимодействие.

dukanfood лого

Все начиналось с простого задания: клиенту было необходимо продавать комплекты товаров, но оформлять их в разные заказы, чтобы упросить работу логистики.

Например: клиент купил 1 товар (подписку) и получает 3 доставки, в системе учета итогом получается 4 заказ. Основной заказ, который оформил клиент, получает статус «Распределенный» после того, как будет разделен на другие заказы. Заказы, полученные в итоге распределения, поступают в обработку логистики.

Разделение заказов

Первым интересным моментом в работе платформы стала система разделения заказа, т.к. сайт был разработан на системе облачной CMS для интернет-магазинов insales, взаимодействие с которой происходит посредством API и Webhook.

Insales - платформа, позволяющая создать интернет магазин самостоятельно, не привлекая программистов и не разбираясь в хостинге, интеграциях и прочих технических вопросах. Можно взяв готовый шаблон, описать товары и начать продавать.

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


Общий алгоритм работы получился такой:

  1. После создания нового заказа Insales посылает Webhook к нашей системе
  2. Наша система разбирает заказ, и если видит определенные товары, которые попадают под распределение, создает разделенные заказы и выгружает назад
  3. Распределенные и готовые заказы наша система отправляет в службу доставки

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

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

Наш сервис выступает в роли посредника между интернет-магазином на CMS insales и системой курьерской доставки на базе expelex.


В качестве платформы для коммуникации была выбрана система связи Expelex. Она позволила организовать передачу курьерам заявок на доставку. Заявки передаются в виде последовательности сообщений по сформированному оптимальному маршруту. Выполнил заявку - получил следующий адрес. Выполнил маршрут - узнал сумму к возврату наличных в кассу и зарплату за день.

Мобильные приложения Expelex в данном проекте позволяют осуществлять трекинг по маршруту следования курьера и оценивать исполнение сроков доставки.

При выполнении основного процесса ведения заявки могут возникать различные проблемы, отмены и другие инциденты. О критических проблемах выполняется оповещение ответственным сотрудникам в мобильных приложениях Expelex, по Email, Viber, Telegram, Skype и другим каналам последовательно.

Бек-энд

Определившись с задачами, начнем реализовывать бек-энд нашей системы. Помимо API клиентов insales и expelex необходимо реализовать механизм разделения заказов, а именно настройку товаров, что и на что будет разделяться. Самый интересный момент реализации разделения заказов в том, что разделение зависит от даты заказа, т.е. заказы, оформленные в разные временные интервалы, разбиваются по-разному, но имеют фиксированные даты доставок.

Теперь, зная все условия формирования заказов, мы можем начинать. Первым делом мы должны реализовать обмен товарами с insales, на данном каталоге у нас и будет построено разделение товаров.

Добавление настроек для разделения товара на подзаказы состоит из двух шагов: сначала мы выбираем товары (с sku) и назначаем, в какие дни для них будет доставка.

После чего настраиваем время, по которому и будут делиться товары. Например, если мы оформим заказ в воскресенье до 17-00, то получим первую доставку во вторник, а именно «Сочная котлета из индейки с сыром» и так далее, согласно графику.

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

После чего выгружаем разделенные заказы в доставку.

Как это работает под капотом. После прихода хука оформления заказа мы кладем его обработку в очередь, очередь позволяет не только пошагово обрабатывать заказы, снижая нагрузку на сервер, но и распределять и контролировать API запросы по системам, т.к. они тоже имеют свои лимиты.

В административной панели системы insales заказы получили вот такой вид

Очень быстро мы получили первые кейсы с ошибками по заказам и доставкам. Оказалось, что операторы путались в заказах, могли внести данные в основной заказ, а не в конкретный, чем провоцировали обновление данных во всех заказах.

Работа с несколькими заказами увеличивала время обработки заявки и увеличивала шанс некорректного заполнения заказа и увеличения очереди обработки заказов, соответственно, увеличивая время обновления данных в системе доставки.

Решили больше не выгружать заказы назад в админку insales, а сразу отправлять данные в систему доставки, для этого мы ввели множество свойств к заказу. К этому момент у нас появилась задача доставлять товары не только в заданный день, но и в заданный временной интервал, что еще больше увеличило количество заполняемых данных.

Изменив логику работы, снова заглянем под капот. После создания или изменения заказа мы ставим его в очередь на обработку. Заказ, проходя обработку, так же разделяется на подзаказы, но теперь он не уходит назад на обновление данных, а получает все необходимые данные сразу, и отправляется в доставку.

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

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

Остался последний шаг, передавать информацию из доставки в insales, а именно, обновлять статусы заказов. Алгоритм был построен так же очень просто:

  • Если заказ доставлен – выставляем статус доставки
  • Если заказ не доставлен – выставляем статус не доставлен или отмены
  • Если все заказы доставлены – выставляем статус выполнения заказа

А что мы получили в доставке? Все так же просто, на входе в insales мы имеем один заказ №100, в expelex мы имеем 3 заказа №100/1, №100/2, №100/3. Каждый из заказов имеет свой статус, адрес и время доставки.