UPS API за следење на пратки наспроти интеграција со OMS: Што треба да изберете?

Ако ви е потребен само статусот на пратката, изберете UPS API за следење. Ако треба да координирате нарачки, залихи, исполнување, рутирање, откажувања и враќања преку повеќе канали, изберете интеграција со OMS. Во многу операции за е-трговија, практичниот одговор не е едното или другото: OMS го управува животниот циклус на нарачката, додека API за следење на еден или повеќе превозници обезбедува настани поврзани со испораката.

Правилната одлука зависи од дејството што вашиот тим треба да го преземе. Развивач кој создава страница за следење има поинакво барање од оперативен тим што поврзува маркетплејс, магацин, 3PL и систем за корисничка поддршка. Ако UPS API за следење и OMS ги третирате како заменливи, тоа може да создаде непотребна развојна работа или да остави важни оперативни празнини.

Разликата во една реченица

UPS API за следење е врска со податоци од превозник. Интеграцијата со OMS е врска со работниот тек на нарачките.

API за следење обично ѝ помага на апликацијата да преземе или прикаже информации за пратката поврзани со број за следење. Овие информации може да поддржат известувања за корисниците, брендирана страница за следење, внатрешно следење на пратките или постапување со исклучоци. Опсегот првенствено е видливост на пратката.

Системот за управување со нарачки се наоѓа на поширок процесен слој. Тој може да координира нарачки од неколку продажни канали, да распределува залихи, да комуницира со локации за исполнување, да испраќа нарачки до магацини или 3PL-системи и да го синхронизира статусот назад кон веб-продавниците или маркетплејсите. Точниот сет на функции се разликува кај секој OMS, па неговите можности треба да се проверат во документацијата за производот, наместо да се претпоставуваат само врз основа на називот.

Кога UPS API за следење е подобар избор

Изберете директна UPS интеграција за следење кога главниот деловен проблем е да знаете каде се наоѓаат UPS пратките и тие информации да ги направите достапни во друга апликација.

• Следење насочено кон корисниците: Вашата веб-страница или апликација треба да го прикажува напредокот на пратката без корисниците да мора да го напуштат корисничкото искуство.
• Работни текови за поддршка: Агентите имаат потреба од тековни настани за следење во системот за корисничка поддршка, CRM или екранот за нарачки.
• Известувања за испорака: На вашиот систем му се потребни настани од пратките како влез за е-пошта, SMS или други комуникации со корисниците.
• Следење на исклучоци: Оперативниот персонал треба да идентификува доцнења, обиди за испорака или други настани што бараат дополнително постапување.
• Операција со еден превозник: UPS управува со повеќето или со сите релевантни пратки, па интеграцијата специфична за превозникот е оперативно разумна.

Овој пристап обично е потесен и полесен за дефинирање од целосен OMS-проект. Тимот може да ги дефинира потребните формати на броевите за следење, полињата за настани, методот за автентикација, однесувањето при освежување, постапувањето со грешки и јазикот на статусите прикажани на корисниците. Тој не бара бизнисот да ги редизајнира процесите за распределба на нарачки или управување со залихи.

Сепак, API за следење не треба да се третира како систем за управување со нарачки. Податоците за следење можат да покажат што се случило со пратката, но сами по себе не одлучуваат кој магацин треба да ја исполни нарачката, да резервира залиха, да подели нарачка, да одобри откажување или да создаде работен тек за враќање.

Кога интеграцијата со OMS е подобар избор

Изберете интеграција со OMS кога проблемот започнува пред создавањето на пратката или продолжува надвор од видливоста на превозникот.

OMS е порелевантен кога бизнисот треба да координира неколку од следните елементи:

• Нарачки од повеќе веб-продавници, маркетплејси или продажни канали
• Достапност на залихи низ продавници, магацини и партнери за исполнување
• Рутирање на нарачки врз основа на локација, залиха, ниво на услуга или оперативни правила
• Делумни пратки, заостанати нарачки, откажувања и измени на нарачки
• Инструкции за исполнување испратени до магацини или 3PL-системи
• Синхронизација на статусот помеѓу OMS и каналите за продажба
• Враќања, рефундирања или постпродажни работни текови што вклучуваат повеќе од статусот на превозникот

Во овој модел, UPS е една можна врска со превозник во рамките на поголем процес. OMS може да создава или прима записи за исполнување, додека интеграцијата со превозникот обезбедува транспортни детали. OMS потоа може да ги користи клучните моменти на испораката за ажурирање на животниот циклус на нарачката, но точното однесување зависи од вклучените системи и правила за мапирање.

Затоа, интеграцијата со OMS е поголема имплементациска одлука. Таа може да опфаќа сопственост над податоците, синхронизација на залихите, дефиниции на состојбите на нарачката, магацински процеси, редици за исклучоци и усогласување. Бизнисот не треба да купи или изгради OMS-врска само затоа што сака подобра страница за следење.

UPS API за следење наспроти интеграција со OMS

Област на одлучување	UPS API за следење	Интеграција со 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 може да биде избор со најмал ризик за тесен проблем. Поширока платформа може полесно да се одржува кога бизнисот веќе има повеќе превозници и системи за исполнување.

Практично правило за одлучување

Користете UPS API за следење кога посакуваниот резултат е сигурна видливост на UPS пратките во постоечка апликација. Користете интеграција со OMS кога посакуваниот резултат е координирано извршување на нарачки и исполнување низ повеќе канали или локации. Користете ги и двете кога OMS треба да управува со нарачките, а посебен слој за следење треба да ги обедини настаните на пратките за корисничката поддршка или постпродажните искуства.

За бизнис што ги проценува опциите, следниот чекор треба да биде мал, документиран интеграциски тест, наместо широка техничка обврска. Изберете репрезентативни нарачки, дефинирајте ги очекуваните полиња и статуси, тестирајте нормални случаи и случаи со исклучоци и забележете кој систем ја поседува секоја одлука. Ако проектот подоцна се прошири со дополнителни превозници, повторно проценете дали API за следење на повеќе превозници е посоодветен од додавање независни врски со превозниците една по една.

Најдобар избор е најмалата архитектура што го решава тековниот оперативен проблем без да го блокира следното веројатно барање. API за следење не треба да се претставува како OMS, а OMS не треба да се воведува само за прикажување страница за следење.

Често поставувани прашања

Дали UPS API за следење е исто што и OMS?

Не. UPS API за следење се фокусира на информациите за пратките од UPS. OMS ги координира пошироките процеси на нарачки и исполнување, кои може да вклучуваат залихи, рутирање, исполнување, откажувања и враќања. Бизнисот може да користи API за следење во архитектура предводена од OMS.

Дали OMS може да ги следи UPS пратките?

Може, ако OMS има UPS интеграција или се поврзува со одделна услуга за следење. Способноста зависи од конкретниот производ и треба да се потврди во документацијата за OMS. Самата ознака OMS не докажува дека системот ги поддржува потребните UPS настани или работни текови.

Дали ми е потребен OMS за создавање брендирана страница за следење?

Обично не. На брендираната страница за следење генерално ѝ е потребна апликација или услуга за следење што може да прима податоци за пратките и да ги прикажува на корисникот. OMS може да обезбеди контекст за нарачката, но не е автоматски неопходен за самата страница.

Кога треба да користам API за следење на повеќе превозници?

Размислете за таков API кога пратките користат повеќе превозници, а на вашите апликации им е потребен конзистентен начин за преземање или прикажување на настаните за испорака. Проверете ја покриеноста на превозниците, моделот на настани, документацијата, ограничувањата на услугата и начинот на постапување со исклучоци за рутите што навистина ги користите.

Што треба да разјаснат развивачите пред интеграцијата?

Разјаснете ги автентикацијата, полињата во барањата и одговорите, дефинициите на статусите, зачестеноста на ажурирањата, постапувањето со грешки, дуплираните настани, валидацијата на броевите за следење, задржувањето, безбедноста и сопственоста на системите. Исто така, документирајте како настанот за следење го менува статусот на нарачката прикажан на корисникот.

Извори

• UPS Developer Portal — официјална почетна точка за развивачи за UPS API и ресурси за интеграција.
• 17TRACK Tracking API — официјална страница на производот за програмска интеграција за следење.
• 17TRACK API Documentation — официјална документација за развивачи како референца за имплементација.