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

Сфера прийняття рішення	API відстеження UPS	Інтеграція з OMS
Основне призначення	Надання або обробка статусу відправлення UPS	Координація життєвого циклу замовлення та операцій із виконання
Основний об’єкт даних	Номер відстеження, посилка, події відправлення	Замовлення, позиції, запаси, виконання, відправлення та, можливо, повернення
Найкращий власник	Продуктова розробка, клієнтський досвід або системи підтримки	Операції електронної комерції, виконання замовлень, корпоративна архітектура та розробка
Типовий обсяг	Один перевізник або сервіс відстеження	Кілька каналів, об’єктів, систем і партнерів із виконання замовлень
Що не вирішується автоматично	Розподіл запасів, маршрутизація або оркестрація замовлень	Точна нормалізація подій перевізника, якщо інтеграція її не забезпечує
Ризик впровадження	Зіставлення полів, автентифікація, опитування або обробка подій і тлумачення статусів	Володіння даними, синхронізація станів, точність запасів і узгодження між системами

Ця таблиця описує типовий архітектурний поділ, а не гарантію для кожного постачальника. Деякі платформи поєднують управління замовленнями та видимість відправлень, а деякі постачальники відстеження підтримують кількох перевізників. Перед вибором моделі інтеграції ознайомтеся з конкретною документацією.

Варіант, який потрібен багатьом компаніям, що розвиваються: 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 — офіційна документація для розробників і довідки щодо впровадження.