Содержание
Если вы вовлечены в e-commerce, а конкретно — в e-trade с помощью мобильных приложений, на первый план постепенно выдвигается автоматизация покупки товаров и сбора необходимых данных для их дальнейшей отправки. Объясним на примере. Допустим, вы предоставляете услугу отправки товара по почте. В таком случае автоматизация расчета доставки и сбора необходимых для отправки данных превращается в важнейшее условие взаимодействия с клиентами. В противном случае работа сервиса электронной торговли становится чрезмерно сложной.
В чем проблема использования доставки от PayPal?
Не будем ходить вокруг да около и сразу же перейдем к рассмотрению проблемы в практической плоскости. Сервис PayPal предоставляет возможность автоматического расчета доставки и ее ручной настройки. Для этого потребуется только наличие аккаунта PayPal и указание адреса отправки. Все остальное, за исключением тонких настроек, сервис сделает за нас.
Как это выглядит? Перед пользователем появляется специальный блок для введения адреса доставки. Туда вносятся, соответствующие данные, после чего в окошке моментально отображается цена.
Казалось бы, все хорошо. Но в этом подходе есть одна проблема. PayPal не использует API почтовых адресов — данные выводятся на основании собственных настроек. В качестве примера, хотелось бы привести проект Nucleus, в котором ранее использовался предложенный метод.
Как объяснил заказчик, это позволяет ему выигрывать на внутренних доставках, но приводит к потере денег при международных заказах. Дело в том, что стоимость транспортировки товаров по Америке составляла 8 долларов, что значительно ниже средней цены. А доставка за рубеж выходила в 45 долларов (кроме Канады и Мексики), что, в свою очередь, выше среднего ценника.
Способы использования API доставки в Rails App
- for USPS — https://github.com/gaffneyc/usps (последний коммит 4 месяца назад). Project Status — Looking for a Maintainer.
- for FedEx — https://github.com/jazminschroeder/fedex (последний коммит 4 месяца назад).
- for UPS — https://github.com/transcriptic/ups-shipping (последний коммит 3 года назад).
Казалось бы, в чем проблема? Гемы, хоть и старые, но есть. Документация — тоже. Однако перед нами возникает суровая необходимость использовать сразу несколько сервисов. Как быть? Чтобы избежать путаницы, приходится изыскивать решение, способное использовать один интерфейс для работы с разными сервисами.
Существует два основных варианта:
- Gem `shipping` — https://github.com/cardmagic/shipping (последний коммит 7 лет назад).
- Gem `active_shipping` — https://github.com/Shopify/active_shipping (последний коммит 8 дней назад).
Использование гема shipping
Гем shipping предоставляет возможность получать данные от таких сервисов как:
- UPS — http://www.ups.com/
- USPS — http://www.usps.com/
- FedEx — http://www.fedex.com/
- Canada Post — http://www.canadapost.ca/
- New Zeland Post — http://www.nzpost.co.nz/
- Shipwire — http://www.shipwire.com/
- Stamps — http://www.stamps.com/
- Kunaki — http://www.kunaki.com/
Перед началом работы с гемом необходимо получить данные клиента для доступа к API необходимых нам сервисов. А именно:
- USPS — логин и пароль
- UPS — логин, пароль, секретный ключ
- FedEx — логин, пароль, секретный ключ и аккаунт
- Canada Post — логин
- New Zealand Post — секретный ключ
- Shipwire — не требует никаких данных
- Stamps — логин, пароль, ключ интеграции
- Kunaki — не требует данных.
Работа с active_shipping
Переходим ко второму гему. Основным объектами, которые нам понадобятся, являются: посылка, адрес отправки и адрес доставки. Используя класс Package, мы можем указать размеры товара:
Package.new(weight,[width,height,depth], unit system)
Стандартная система измерения — метрическая. Однако можно использовать и английскую систему мер. Для этого необходимо указать units: :imperial в качестве последнего параметра. Далее следует прописать адреса отправки и доставки. Для этого используется класс Location:
Location.new(country: ‘country’,
state: ‘state’,
city: ‘city’,
zip: ‘zip’)
Гем active_shipping имеет один существенный недостаток. Предполагается, что при работе с ним сервису передается полный массив объектов Package с данными по каждому товару. Но при использовании такого метода цена доставки получается неоправданно высокой. Это происходит потому, что сервисы распознают полученный массив, как отдельные посылки и в ответ отправляют суммарную стоимость всех заказов. Плюс предлагают все возможные способы одновременной доставки посылок.
Получается совсем нехорошо. И с этой проблемой мы столкнулись, когда разрабатывали систему расчета доставки для проекта Nucleus Gallery.
Существуют алгоритмы, позволяющие укладывать прямоугольники на поверхности. Они могут быть двухмерными и трехмерными. Реализация первого алгоритма достаточно сложна. А второго — не только сложна, но еще и невозможна с точки зрения попадания в определенный дедлайн. Она попросту не зависит от количества входных данных.
К чему мы это? К тому, что решением проблемы послужил один простой способ. Для расчета общего веса мы сложили вес всех товаров по отдельности. Система такова. Изначально выбирается товар с максимальной площадью. Его параметры нам необходимы для определения ширины посылки. Далее предполагается, что товары будут укладываться в стопку по принципу пирамиды — наибольший становится основанием, наименьший — вершиной. Исходя из этого, рассчитывается высота посылки. Наконец, собранные данные отправляются одним пакетом на сервер. Это позволило нам приблизить стоимость доставки к реальным цифрам.
И еще одна сложность. Такие сервисы как USPS и UPS проверяют валидность полученных данных только для Америки и только на уровне принадлежности почтового индекса к определенному штату. Это может создать проблемы при передаче информации о доставке на PayPal. Сервис просто не распознает адрес заказчика. В результате возникает коллапс. Для решения этой проблемы необходима сторонняя валидация адреса. Например, smartystreets или Google’s geocoding.