UPS Tracking Api или интеграция с OMS: что выбрать?

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

Правильное решение зависит от того, какое действие должна выполнять ваша команда. У разработчика, создающего страницу отслеживания, требования отличаются от требований операционной команды, подключающей маркетплейс, склад, 3PL и систему обслуживания клиентов. Рассматривать API отслеживания UPS и OMS как взаимозаменяемые решения может привести к ненужным затратам на разработку или оставить важные операционные пробелы.

Разница в одном предложении

API отслеживания UPS — это подключение к данным перевозчика. Интеграция с OMS — это подключение к рабочему процессу обработки заказов.

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

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

Когда API отслеживания UPS — лучший выбор

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

• Отслеживание для клиентов: Вашему сайту или приложению нужно показывать ход доставки, не заставляя клиентов покидать текущий интерфейс.
• Рабочие процессы поддержки: Операторам нужны актуальные события отслеживания внутри системы поддержки, CRM или интерфейса заказа.
• Уведомления о доставке: Вашей системе нужны события отправления в качестве входных данных для электронной почты, SMS или других коммуникаций с клиентами.
• Мониторинг исключений: Операционным сотрудникам нужно выявлять задержки, попытки доставки и другие события, требующие дальнейших действий.
• Работа с одним перевозчиком: UPS обрабатывает большинство или все соответствующие отправления, поэтому интеграция с конкретным перевозчиком является операционно разумной.

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

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

Когда интеграция с OMS — лучший выбор

Выберите интеграцию с OMS, если проблема начинается до создания отправления или продолжается после получения информации о перевозчике.

OMS более актуальна, когда бизнесу необходимо координировать несколько из следующих процессов:

• Заказы из нескольких интернет-магазинов, маркетплейсов или каналов продаж
• Доступность запасов в магазинах, на складах и у партнеров по выполнению заказов
• Маршрутизация заказов на основе местоположения, запасов, уровня обслуживания или операционных правил
• Частичные отправления, отложенные заказы, отмены и изменения заказов
• Инструкции по выполнению заказов, отправляемые на склады или в системы 3PL
• Синхронизация статусов между OMS и каналами продаж
• Возвраты, возмещения или процессы после покупки, которые включают больше, чем статус перевозчика

В этой модели UPS является одним из возможных подключений к перевозчику внутри более крупного процесса. OMS может создавать или получать записи о выполнении заказов, а интеграция с перевозчиком предоставляет сведения о транспортировке. Затем OMS может использовать этапы доставки для обновления жизненного цикла заказа, но точное поведение зависит от задействованных систем и правил сопоставления.

Таким образом, интеграция с OMS — это более масштабное решение по внедрению. Она может включать владение данными, синхронизацию запасов, определения состояний заказа, складские процессы, очереди исключений и сверку данных. Бизнесу не следует приобретать или создавать подключение к OMS только потому, что ему нужна более качественная страница отслеживания.

API отслеживания UPS и интеграция с OMS

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

Вариант, который нужен многим растущим компаниям: OMS плюс отслеживание нескольких перевозчиков

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

17TRACK предоставляет API отслеживания и публикует документацию для разработчиков для компаний, которым нужна программная интеграция отслеживания. Это актуально, когда требуется видимость отправлений разных перевозчиков, а не рабочий процесс, связанный только с UPS. Для подтверждения текущего охвата API, поддерживаемых операций, требований к аутентификации и деталей внедрения конкретного проекта следует использовать официальную документацию.

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

Для простого магазина, работающего только с UPS, добавление одновременно OMS и сервиса отслеживания нескольких перевозчиков может быть излишним. Для бизнеса с несколькими перевозчиками и каналами отсутствие нормализованного уровня отслеживания, напротив, может привести к отдельным интеграциям, несогласованным названиям статусов и увеличению объема обслуживания.

Как выбрать решение, не создавая лишнюю сложность

1. Начните с бизнес-события

Опишите событие, которое должно запускать действие. «Показать последний статус UPS на странице заказа» указывает на API отслеживания. «Отправлять каждый оплаченный заказ в лучшее место выполнения и поддерживать синхронизацию запасов» указывает на OMS. «Обновлять информацию для клиента после того, как посылка покинула 3PL» может потребовать и того и другого.

2. Определите системы, которые уже владеют данными

Составьте список интернет-магазина, маркетплейса, ERP, системы управления складом, 3PL, платформы обслуживания клиентов, OMS и подключений к перевозчикам. Для каждой системы определите, создает ли она, изменяет или только читает заказы, запасы, записи о выполнении и события отслеживания. Это поможет избежать появления двух конкурирующих источников истины из-за новой интеграции.

3. Проверьте разнообразие перевозчиков и географию

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

4. Определите минимальную модель статусов

События перевозчика часто более подробны, чем статусы, отображаемые клиентам. До начала разработки сопоставьте исходные события с бизнес-состояниями, такими как этикетка создана, в пути, передано курьеру для доставки, доставлено, исключение и возвращено. Определите, что происходит, если событие задержано, продублировано, отсутствует или получено не по порядку. Эта работа необходима независимо от того, поступают ли данные напрямую от UPS или через платформу отслеживания.

5. Протестируйте операционные исключения

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

6. Сравните общие операционные затраты

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

Практическое правило выбора

Используйте API отслеживания UPS, когда нужен надежный просмотр информации об отправлениях UPS в существующем приложении. Используйте интеграцию с OMS, когда требуется согласованное выполнение заказов и операций по их обработке через разные каналы или в разных местах. Используйте оба решения, когда OMS должна управлять заказами, а отдельный уровень отслеживания — объединять события отправлений для обслуживания клиентов или процессов после покупки.

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

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

Часто задаваемые вопросы

Является ли API отслеживания UPS тем же самым, что и OMS?

Нет. API отслеживания UPS сосредоточен на информации об отправлениях UPS. OMS координирует более широкие процессы обработки заказов и их выполнения, включая запасы, маршрутизацию, выполнение, отмены и возвраты. Бизнес может использовать API отслеживания в архитектуре, управляемой OMS.

Может ли OMS отслеживать отправления UPS?

Да, если OMS имеет интеграцию с UPS или подключается к отдельному сервису отслеживания. Возможности зависят от конкретного продукта и должны быть подтверждены в документации OMS. Одно только наличие обозначения OMS не доказывает поддержку необходимых событий или рабочих процессов UPS.

Нужна ли мне OMS для создания брендированной страницы отслеживания?

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

Когда следует использовать API отслеживания нескольких перевозчиков?

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

Что разработчики должны уточнить до интеграции?

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

Источники

• Портал разработчиков UPS — официальная точка входа к API UPS и ресурсам для интеграции.
• API отслеживания 17TRACK — официальная страница продукта для программной интеграции отслеживания.
• Документация API 17TRACK — официальная документация для разработчиков и справочная информация по внедрению.