Как да унифицирате проследяването на пратки в Австралия и Нова Зеландия с един API

За да обедините проследяването на пратки в Австралия и Нова Зеландия чрез един API, свържете системата си за поръчки или изпълнение на поръчки към услуга за проследяване на множество превозвачи, регистрирайте всяка пратка с правилната самоличност на превозвача и преобразувайте входящите актуализации за проследяване в единен вътрешен модел на събитията. Интеграцията трябва да запазва специфичните за превозвача подробности, като същевременно осигурява на оперативния ви екип и клиентите едно и също изживяване при проследяване на вътрешни и транс-Tasman доставки.

За разработчиците, операторите на електронна търговия и логистичните екипи основното предизвикателство не е изпращането на първата API заявка. То е да поддържат идентичностите на пратките, статусите на доставката, предаването между превозвачите и известията към клиентите съгласувани, когато различните превозвачи описват едно и също пътуване по различен начин. Това ръководство обяснява как да проектирате тази интеграция, как да оцените API за проследяване и как да го тествате, преди да разчитате на него в продукционна среда.

Определете какво трябва да обедини единният API

Споделеният API предоставя на приложението ви обща точка за интеграция. Той не кара всички превозвачи да публикуват еднаква информация или да сканират пратките с една и съща честота. Архитектурата ви трябва да разграничава съгласувания интерфейс от пълната видимост.

Започнете с инвентаризация на пратките, базирана на реалната дейност по изпълнение на поръчките, а не с общ списък на превозвачите, работещи в някоя от двете държави. Включете вътрешни австралийски пратки, вътрешни новозеландски пратки и трансгранични движения и в двете посоки. Добавете и други международни направления, ако са част от бизнеса ви.

• Превозвач и услуга: Запишете превозвача, използваната услуга и всеки известен партньор за доставка.
• Маршрут: Разграничете началната и крайната точка на пратката от местоположението на последното ѝ сканиране.
• Идентификатори: Съберете референцията на поръчката, референцията за изпълнение, номера за проследяване и всеки заместващ или партньорски номер.
• Оперативна цел: Посочете дали актуализациите поддържат проследяване от клиента, управление на изключения, потвърждение на доставката или и трите.
• Необходима подробност: Решете дали общият статус на доставката е достатъчен, или агентите се нуждаят и от описания на сканиранията, местоположения и времеви отметки.

Тази инвентаризация се превръща във ваш контролен списък за приемане. Общото покритие на превозвачите от даден доставчик е полезно за предварителния подбор, но решението ви трябва да се основава на това дали реалните ви комбинации от превозвачи и услуги връщат използваема информация за проследяване.

Оценете API за проследяване спрямо комбинацията от ваши пратки

17TRACK предлага API за проследяване, което го прави подходящ вариант за оценка при интеграция с множество превозвачи. Използвайте неговата официална API документация, за да проверите текущите изисквания за интеграция. Разглеждайте поддръжката на превозвачи, полетата на събитията, поведението на актуализациите, ограниченията на акаунта и търговските условия като елементи, които трябва да проверите за вашата реализация, а не като предположения, произтичащи от категорията на продукта.

Задайте на всеки API, който разглеждате, едни и същи практически въпроси:

• Може ли да идентифицира и проследява превозвачите и услугите от инвентаризацията на вашите пратки?
• Когато откриването на превозвача е нееднозначно, можете ли да предоставите изричен идентификатор на превозвача?
• Как приложението ви получава актуализации и какъв механизъм за възстановяване е наличен, ако дадена актуализация бъде пропусната?
• Кои оригинални подробности за превозвача остават налични наред с нормализираните статуси?
• Какво се случва, когато номерът за проследяване е невалиден, все още не е разпознат или е свързан с повече от един възможен превозвач?
• Как са дефинирани използването, таксуването, продължителността на проследяването и ограниченията за достъп за вашия акаунт?

Препоръчително правило за решение: избирайте въз основа на успешни тестове с реалните ви модели на доставка, а не според най-големия обявен брой превозвачи. Интеграцията е подходяща, когато предоставя достатъчно информация за оперативните ви решения и показва достатъчно ясно грешките, за да можете да ги отстраните.

Изградете вътрешен модел, устойчив на различията между превозвачите

Разделяйте поръчките, пратките и етапите на проследяване

Не използвайте номера за проследяване като първичен ключ за поръчка. Една поръчка може да съдържа няколко пакета, а пътуването на един пакет може да включва повече от един идентификатор за проследяване. Вместо това създайте вътрешен идентификатор на пратката и свържете записите за проследяване с него.

Практическият модел има три нива: клиентската поръчка, физическите пратки в нея и етапите на проследяване, свързани с всяка пратка. За вътрешен пакет може да е необходим само един етап на проследяване. За трансграничен пакет може да са необходими свързани записи, когато друг превозвач или идентификатор стане релевантен.

Определяйте обхвата на запис за проследяване по превозвач, както и по номер за проследяване, и запазвайте връзката му с идентификатора на пратката. Ако се появи нов номер на партньор за доставка, добавете го като свързан идентификатор, вместо да заменяте оригиналния. Така се запазва историята, от която агентите по поддръжката се нуждаят при разследване на предаване.

Поддържайте необработено и нормализирано събитие

Използвайте малък вътрешен речник от статуси, по които бизнесът ви може да предприема действия. Например можете да дефинирате преди транзит, в транзит, предадено за доставка, налично за получаване, доставено, изключение и неизвестно. Това са предложени вътрешни категории, а не твърдение за схемата на статусите на конкретен доставчик.

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

Документирайте решенията за преобразуване във версионирана конфигурация. Когато се появи ново описание на събитие, поставете го в опашка за преглед, ако значението му е неясно. Явното неизвестно състояние е по-безопасно от уверено задаване на неправилен резултат от доставката.

Разграничавайте времето на събитието от времето на получаване

Съхранявайте отделно момента, в който е настъпило събитието, и момента, в който системата ви го е получила. По-старо сканиране може да пристигне след по-ново, особено когато актуализациите се забавят или исторически събития се предоставят заедно.

За Австралия и Нова Зеландия избягвайте прилагането на една фиксирана часова разлика към всяка пратка. Запазвайте изходните времеви отметки и отмествания, когато са предоставени. Използвайте подходяща именувана часова зона за визуализация, когато разполагате с надежден контекст за местоположението, и вземайте предвид разликите в лятното часово време. Ако часовата зона на източника липсва, запазете тази несигурност, вместо да измисляте прецизно преобразуване към UTC.

Реализирайте надежден работен поток за приемане

1. Създайте първо вътрешната пратка. Запишете връзката ѝ с поръчката, маршрута, избора на превозвач и идентификатора за проследяване, преди регистрацията в услугата за проследяване.
2. Изпратете регистрацията за проследяване. Използвайте документирания формат на заявката на доставчика. Съхранете отговора и разграничете успешната регистрация от последващата наличност на събития от превозвача.
3. Класифицирайте грешките. Разделяйте невалидните входни данни и проблемите с удостоверяването от временните откази на услугата. Повтаряйте заявката само когато повторението може разумно да помогне.
4. Получавайте или извличайте актуализации. Реализирайте механизма за доставка, поддържан от избрания API. Ако използвате webhooks, валидирайте входящите заявки по документирания от доставчика метод и обработвайте приетите събития чрез надеждна опашка.
5. Премахвайте дубликатите преди прилагане на промените. Използвайте идентификатор на събитието от доставчика, когато е наличен, или внимателно проектиран съставен ключ. Повторната доставка не трябва да задейства повторни известия към клиентите.
6. Преизчислявайте състоянието на пратката. Оценявайте значението и хронологията на събитията, вместо да заменяте текущия статус с която и да е актуализация, пристигнала последна.
7. Съгласувайте непълните записи. Когато API поддържа извличане, използвайте го за разследване на пропуснати актуализации или остарели записи в рамките на приложимите ограничения за използване.

Дръжте удостоверяването, имената на полетата и обработката на грешки, специфични за доставчика, в адаптер. Системата ви за управление на поръчките трябва да използва вътрешния ви модел на пратките, вместо да зависи директно от всяка подробност в отговора на доставчика. Това разделяне улеснява и тестването на бъдещи промени в API.

Обработвайте транс-Tasman пътуванията, без да измисляте сигурност

Трансграничното проследяване се нуждае от повече контекст от поредица статуси. Приложението ви трябва да разграничава събитие при износ, събитие, свързано с митницата, предаване между превозвачи и събитие при крайната доставка, когато изходните данни позволяват тези разграничения.

Не правете извод за митническо освобождаване от общо сканиране „в транзит“. По същия начин липсата на скорошно сканиране не доказва, че митницата задържа пакета. Полезното съобщение към клиента посочва последното потвърдено събитие и неговото време, след което обяснява всяко следващо действие, което екипът ви действително може да подкрепи.

Поддържайте началната и крайната точка отделно от местоположението на сканирането. Пратка, пътуваща от Австралия до Нова Зеландия, не става вътрешна новозеландска пратка само защото е получила сканиране при пристигане. Това разграничение е важно за отчетите по маршрути и отговорността при изключения.

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

Превърнете събитията за проследяване в полезни актуализации за клиентите

Страницата, видима за клиента, трябва да отговаря на четири въпроса: какъв е последният потвърден статус, кога е настъпил, къде е записан, ако е известно, и необходимо ли е клиентът да предприеме действие?

Дръжте правилата за известия отделно от приемането на събития. Не всяко сканиране заслужава имейл или текстово съобщение. Дефинирайте значими преходи, като първо потвърдено движение, опит за доставка, необходимост от получаване или събитие „доставено“, и потискайте повтарящите се сигнали за един и същ преход.

• Остаряло проследяване: Посочете кога е настъпила последната актуализация, без да приемате мълчанието за доказателство за загуба.
• Оценки за доставка: Разграничавайте оценка, предоставена от превозвача, от обещание на търговеца. Не измисляйте дата, когато нито една от двете не съществува.
• Изключения: Посочете конкретна следваща стъпка, когато е известна, вместо да показвате необясним етикет за грешка.
• Спорове за доставени пратки: Запазете изходното събитие и насочете случая към поддръжката; самият статус „доставено“ не разрешава всеки спор с клиент.

Защитете страниците за проследяване, както и API идентификационните данни. Избягвайте излагането на ненужни адресни или контактни данни, съхранявайте идентификационните данни за услугата на сървъра и прилагайте контрол на достъпа, подходящ за показваната информация.

Проведете пилотен проект по маршрути преди внедряването

Тествайте вътрешни австралийски, вътрешни новозеландски, австралийско-новозеландски и новозеландско-австралийски пратки, когато тези маршрути са релевантни за бизнеса ви. Включете обикновени доставки и оперативни крайни случаи: разделени поръчки, неразпознати номера, предавания, опити за доставка, събития при получаване, връщания и закъснели сканирания.

Използвайте реални записи на пратки с подходящо разрешение за валидиране на превозвача. Използвайте синтетични събития, за да тествате устойчивостта на собственото си приложение, но не приемайте синтетичните резултати за доказателство за реално покритие на превозвача.

• Проверка на идентичността: Всяка актуализация достига до правилната пратка и поръчка.
• Проверка на хронологията: Събитията извън ред не обръщат неправилно напредъка на доставката.
• Проверка на възстановяването: Временните грешки и дублираните актуализации не водят до загуба на данни или повторни сигнали.
• Проверка за поддръжка: Агентите могат да прегледат оригиналното събитие и да разберат статуса, видим за клиента.
• Търговска проверка: Очакваното използване съответства на проверения модел на таксуване и ограниченията на акаунта.

Определете праговете за приемане преди оценката на пилота. Измервайте резултатите от регистрациите, несъпоставените събития, забавянията при обработката, дублираните известия и неразрешените остарели пратки. Разделяйте забавянията в данните на превозвача от забавянията в собственото ви приложение, така че отстраняването да достигне до правилния отговорник.

Реализацията е готова, когато екипът ви може да обясни и да възстанови проследяване с непълни данни, а не просто да показва успешни доставки. Един API опростява свързването; вашият модел на пратките, правилата за събитията и оперативните процедури правят тази свързаност надеждна.

Често задавани въпроси

Един API за проследяване заменя ли интеграциите за доставка на превозвачите?

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

Мога ли да регистрирам номер за проследяване преди първото сканиране от превозвача?

Проверете правилата за регистрация на API. Проектирайте приложението си така, че да разграничава приета регистрация за проследяване от потвърдено физическо движение. Запис без събития не трябва автоматично да се показва като „в транзит“.

Ще предоставя ли един API актуализации в реално време за всеки превозвач?

Не приемайте това за даденост. Актуалността от край до край зависи от момента, в който превозвачът публикува данните, момента, в който услугата за проследяване ги получава, и момента, в който приложението ви ги обработва. Потвърдете поведението на актуализациите за използваните от вас комбинации от превозвачи и услуги.

Какво трябва да се случи, когато номерът за проследяване се промени?

Запазете оригиналния идентификатор и прикрепете проверения заместващ или партньорски идентификатор към същата вътрешна пратка. Запазете и двете истории и предотвратете генерирането на противоречиви известия от дублирани записи.

Релевантен ли е 17TRACK за тази интеграция?

Да. Неговият Tracking API е релевантен за описаната тук интеграция с множество превозвачи. Оценете го чрез ваши австралийски и новозеландски проби от пратки и потвърдете поддръжката на превозвачите, техническото поведение и условията на акаунта чрез официалните API ресурси преди внедряване.

Източници

• 17TRACK Tracking API — официален продуктов ресурс за разглежданата в това ръководство API опция.
• 17TRACK API документация — официален технически справочник за проверка на форматите на заявките, изискванията за интеграция и поддържаното поведение.