Како да ги следите пратките од Кина до Европа и САД со еден API

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

За развивачите и тимовите за е-трговски операции, целта не е само прикажување статус. Целта е секоја физичка пратка да се поврзе со точната нарачка, клиентите да бидат информирани без да им се испраќаат погрешни ажурирања и да се идентификуваат пратките на кои им е потребна интервенција. Овој водич објаснува како да го изградите тој работен тек и како да оцените услуга како 17TRACK Tracking API според вашите реални транспортни рути.

Започнете со транспортната рута, а не само со земјата на одредиште

Пратка што патува од Кина до европска или американска адреса може да помине низ услуга за собирање, меѓународна транспортна мрежа, царинска обработка и превозник за достава во земјата на одредиште. Некои транспортни услуги ги прикажуваат овие движења под еден број за следење. Други обезбедуваат одделна референца за достава подоцна во текот на патувањето.

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

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

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

Што треба да прави еден API за следење — и што не може да прави

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

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

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

Изградете ја интеграцијата околу запис на ниво на пратка

1. Одделете ги нарачките, пратките и идентификаторите за следење

Една нарачка од е-трговија може да содржи повеќе пакети, а тие пакети може да пристигнат во различни периоди. Користете внатрешен ID на пакетот или пратката како стабилен идентификатор. Поврзете ја нарачката на клиентот со тој запис, а потоа прикачете ги идентификаторите за следење на превозникот.

Практичниот внатрешен модел треба да ги содржи следните елементи:

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

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

2. Регистрирајте ги пратките од сигурен деловен настан

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

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

Прочитајте го одговорот од регистрацијата на ниво на поединечна пратка. Успешното HTTP-барање не мора да значи дека секоја ставка во серијата е прифатена. Чувајте ги неуспесите во редица за повторно обидување и овозможете им на оперативните тимови начин за решавање на невалидни или нејасни поднесоци.

3. Дизајнирајте ја испораката на ажурирања пред да ги поврзете известувањата за клиентите

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

Вашиот приемник треба трајно да го прифати ажурирањето пред да го потврди приемот, а потоа да го обработи асинхроно. Дизајнирајте за дупли испораки и настани што пристигнуваат по погрешен редослед. Користете ID на настанот од давателот кога е достапен; во спротивно, дефинирајте документирано правило за отстранување дупликати со користење стабилни атрибути на настанот.

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

4. Нормализирајте ги статусите без да го отфрлите значењето

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

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

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

Експлицитно постапувајте со меѓународните предавања

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

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

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

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

Каде се вклопува 17TRACK во овој работен тек

Понудата на Tracking API од 17TRACK е релевантна кога на вашата апликација ѝ е потребна интеграција за следење со повеќе превозници. Нејзината официјална API документација треба да ја насочува имплементацијата на автентикацијата, регистрацијата, обработката на одговорите и поддржаните работни текови за ажурирања. Користете го документираниот API-договор наместо потрошувачката страница за следење да ја третирате како интеграциски интерфејс.

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

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

Спроведете пилотирање засновано на рути пред пуштањето

Користете тест-сет што вклучува нормални доставки и сложени случаи. Историските пратки помагаат при тестирањето на мапирањето на статусите, додека пратките во живо ја откриваат испораката на ажурирања и оперативниот тајминг. Ниту еден тест самостојно не одговара на сите прашања.

• Достава од Кина до САД: проверете ги настаните на потеклото, евентуалното меѓународно предавање и конечниот настан на доставата.
• Достави од Кина до Европа: тестирајте ги земјите на одредиште и транспортните услуги што навистина ги користите.
• Нова етикета: потврдете дека пакетот без физичко скенирање не се прикажува како да се движи.
• Променета референца за достава: потврдете дека односот останува поврзан со точниот пакет.
• Исклучок при достава: проверете дали деталната причина стигнува до соодветната оперативна редица.
• Поделена нарачка: потврдете дека доставата на еден пакет не ја затвора целата нарачка.
• Дуплирано или задоцнето ажурирање: потврдете дека не создава повторени пораки или неправилно не презапишува понов статус.
• Привремен неуспех на интеграцијата: проверете го повторниот обид, усогласувањето и видливоста за поддршката.

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

Следете ја свежината на податоците одделно од достапноста на API

API Monitoring треба да одговори на две различни прашања: дали интеграцијата функционира и дали информациите за пратката се корисни? Успешните барања одговараат само на првото прашање. Исто така, треба да знаете дали регистрациите акумулираат грешки, дали повратните повици не успеваат или дали некоја рута престанала да создава очекувани пресвртници.

• Здравје на интеграцијата: неуспеси при автентикација, грешки на барањата, одговори за ограничување на стапката, неуспеси на повратните повици и заостанати задачи во редиците.
• Квалитет на податоците: непознати статуси, неправилни временски ознаки, нерешени идентитети на превозници и неочекувани промени на идентификаторите.
• Свежина на пратката: времето од последниот настан од превозникот, сегментирано според рута и транспортна услуга.
• Деловно влијание: обем на работа со исклучоци, неуспешни известувања и нарачки неправилно означени како завршени.

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

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

ЧПП

Може ли еден API да ги следи и кинескиот превозник на потекло и превозникот за достава на одредиштето?

Услуга со повеќе превозници може да ги обедини настаните од двата дела на патувањето кога се поддржани релевантните услуги и односите меѓу идентификаторите. Потврдете ја целата рута со реални пакети. Самото препознавање на бројот за следење на потеклото не докажува дека информациите за доставата на одредиштето ќе бидат достапни.

Зошто следењето престанува да се ажурира откако пакетот ќе ја напушти Кина?

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

Дали апликацијата треба да користи веб-куки или периодично испитување?

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

Може ли API за следење да гарантира датум на достава или царинско ослободување?

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

Што треба да се провери пред изборот на API-план?

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

Извори

• 17TRACK Tracking API — официјална референца за производот и понудата на tracking API.
• 17TRACK API documentation — официјална техничка референца за имплементација на интеграцијата. Потврдете ги точните формати на барањата, поддржаните работни текови и ограничувањата овде пред развојот.