Как да проверите покритието на API за проследяване на пратки, преди да навлезете на нови пазари
За да проверите покритието на API за проследяване на пратки, преди да навлезете на нов пазар, тествайте точните комбинации от превозвач, услуга, транспортен маршрут и доставка до последната миля, които планирате да използвате. Сравнете пратките в реално време със записите на превозвача, потвърдете, че събитията достигат правилно до системите ви, и документирайте пропуските преди старта. Фактът, че даден превозвач фигурира в списъка с поддържани превозвачи на даден доставчик, е отправна точка, а не доказателство, че планираният от вас маршрут на доставка ще бъде видим.
Това ръководство е предназначено за логистични мениджъри, екипи по електронна търговия и отговорни лица по интеграциите, които подготвят стартиране на нов пазар. Целта е практическо решение за стартиране: кои маршрути за доставка са проверени, кои се нуждаят от резервен вариант и кои все още изискват доказателства.
Определяйте покритието според маршрутите за доставка, а не според броя държави
При планиране на навлизане на нов пазар разглеждайте покритието за проследяване като възможността да извличате и доставяте използваеми събития за пратки при конкретна схема на доставка. Самата държава на местоназначение е прекалено обща единица за анализ. Две пратки, влизащи в една и съща държава, може да използват различни превозвачи в страната на изпращане, митнически arrangements, партньори за доставка и нива на услугата.
Разграничете три въпроса, които често се обединяват в дискусиите за снабдяване:
- Съвместимост с превозвача: Може ли API да приема и идентифицира пратки от превозвача и услугата, които използвате?
- Видимост на маршрута: Връща ли събитията, от които екипът ви се нуждае, за съответните етапи на доставката?
- Оперативна доставка: Могат ли тези събития надеждно да достигнат до системата ви за управление на поръчки, инструментите за поддръжка и известията към клиентите?
Успешната API заявка отговаря само на част от първия въпрос. Тя не доказва, че пратката има полезни събития, че крайният резултат от доставката е видим или че приложението ви е обработило актуализацията.
1. Изградете матрица на покритието за конкретния пазар
Започнете с плана за доставка, който логистичният ви екип действително възнамерява да изпълни. Помолете склада, доставчика на услуги по изпълнение на поръчките и транспортните партньори да потвърдят участващите превозвачи и услуги. Ако консолидаторът избира динамично партньора за последната миля, запишете тази несигурност, вместо да приемате името на консолидатора като пълно описание на маршрута.
Създайте отделен ред за всяка значима комбинация. Следните полета образуват полезна работна матрица:
| Поле | Какво да запишете | Защо е важно |
|---|---|---|
| Транспортен маршрут | Пазар на изпращане и местоназначение | Резултатите за вътрешни доставки не доказват видимост при международни доставки. |
| Превозвач и услуга | Договорен превозвач, име на услугата и съответен идентификатор | Списъкът на ниво превозвач може да не отговаря на въпросите за конкретната услуга. |
| Схема на предаване | Известен партньор за доставка и евентуален заменящ номер за проследяване | Трябва да тествате непрекъснатостта при прехвърлянето. |
| Необходими етапи | Приемане, движение, опит за доставка, доставка и съответните изключения | Изискванията трябва да отразяват нуждите на поддръжката и клиентите. |
| Бизнес експозиция | Прогнозиран дял на пратките и последици от липсващи актуализации | Маршрутите с голям обем и висок риск заслужават приоритет. |
| Статус на проверката | Проверено, условно, все още непроверено или потвърдено неподдържано | Липсващите доказателства не трябва да се бъркат с липса на поддръжка. |
Определете отговорностите на ранен етап. Логистиката трябва да валидира физическия маршрут, инженерният екип трябва да валидира доставката на данни, а оперативният екип трябва да реши дали получената видимост подкрепя обещанията към клиентите. Отделът по снабдяване може да координира процеса, но единствено контролен списък с функции не трябва да определя приемането.
2. Проверете официалната документация, след което задайте въпроси за конкретния маршрут
Използвайте официалните API материали на доставчика, за да установите документирания обхват на интеграцията. Потърсете идентификатори на превозвачите, изисквания за регистрация, полета в отговора, дефиниции на събитията, удостоверяване, ограничения за използване и начина на доставяне на актуализациите. Съхранявайте запис с дата на документацията, която е от значение за реализацията ви.
За оценка на 17TRACK използвайте официалната страница на Tracking API и API документацията като отправни точки за проверка. Прилагайте същите тестове за приемане на ниво маршрут, описани по-долу; не приемайте общото описание на продукта като потвърждение за конкретна услуга или схема на предаване.
Изпратете на доставчика конкретно искане за валидиране, вместо да питате дали „покрива“ дадена държава. Включете планираните превозвач и услуга, начална точка и местоназначение, представителни упълномощени номера за проследяване, необходимите етапи и очаквания обем пратки.
- Изисква ли тази конкретна услуга изричен идентификатор на превозвача или допълнителна информация за пратката?
- Как трябва интеграцията да обработва номер, който може да съответства на повече от един превозвач?
- Може ли оригиналният идентификатор да покаже активността по последната миля или трябва да бъде регистриран втори идентификатор?
- Кои от необходимите събития се очакват от този маршрут и кои зависят от предоставянето им от превозвача?
- Какво се случва, когато проследяването временно не е достъпно или пратката все още няма събития?
- Кои ограничения за използване, правила за съхранение и условия за таксуване важат за предложения работен процес?
Разграничете документираното поведение от договорните ангажименти. Техническото описание на актуализациите не е непременно гарантиран интервал на обновяване или ангажимент за ниво на услугата. Поискайте писмено потвърждение, когато това разграничение влияе върху риска при стартиране.
3. Тествайте представителни пратки, а не само успешно доставени пратки
Създайте тестов набор от пратки, до които имате право на достъп. Включете както завършени, така и активни пратки. Историческите записи помагат да проверите последователностите от събития; активните пратки са необходими, за да наблюдавате регистрацията, получаването на актуализации и доставянето им до собствените ви системи.
Изберете извадки от маршрутите и услугите в матрицата си. Включете стандартни доставки и, когато има реални примери, забавени пратки, неуспешни опити за доставка, доставки до пунктове за получаване и връщания към подателя. Не измисляйте резултат от тест за изключение, когато няма подходяща пратка. Отбележете този сценарий като очакващ валидиране.
Няма универсален размер на извадката, който да доказва покритие. Малък набор може да разкрие грешка в интеграцията, но не може да установи надеждна работа при всяка услуга и изключение. Разширете тестването там, където разнообразието на маршрутите, неяснотата на превозвача или последиците от липсващи събития са по-големи.
Сравнете една и съща пратка на три нива на доказателства
- Запис на превозвача: Заснемете информацията за проследяване, налична директно от съответния превозвач, включително часа на проверката.
- API отговор: Запазете необработения отговор, върнатата самоличност на превозвача, времевите отметки на събитията и часа на извличане.
- Вашето приложение: Потвърдете какво е съхранила, показала и използвала системата ви за задействане на действия.
Тези нива помагат да се локализира повредата. Събитие, което липсва както в проследяването на превозвача, така и в API, е различно от събитие, видимо при превозвача, но липсващо в API. Събитие, налично в API, но липсващо в системата за поръчки, насочва към друга част от интеграцията.
Разглеждайте записа на превозвача като справка, а не като непогрешим отчет за физическото движение. Записите за проследяване описват докладвани събития; те не осигуряват непрекъснато наблюдение на пратката. Проучвайте съществените несъответствия с превозвача и доставчика на API.
4. Проверете предаванията, значението на статусите и времето за актуализация
Проверете непрекъснатостта до последната миля
За всеки международен маршрут проверете какво се случва, когато пратката смени притежателя си. Запишете дали оригиналният номер продължава да връща полезни събития, дали се появява друг номер и дали системата ви може да свърже двата идентификатора с една и съща поръчка.
Съобщението за предаване не е доказателство за видимост на доставката. Проследете пратката до крайния резултат. Ако информацията за последната миля не е налична, определете дали причината е липсващи изходни данни, проблем с идентификатора, проблем с конфигурацията или ограничение на поддръжката. Оставете маршрута условен, докато това разграничение не стане ясно.
Проверете значението зад нормализираните статуси
Ако интеграцията ви използва нормализирани статуси, сравнете ги с основния текст на събитието. Уверете се, че създаването на етикет не задейства съобщение за физическо изпращане, пристигането в съоръжение за доставка не се превръща в „доставено“ и неуспешният опит за доставка не затваря поръчката като успешно завършена.
Тествайте също наличността за получаване и резултатите при връщане към подателя, когато е приложимо. Опростеният статус може да помогне на клиентите да разберат напредъка, но екипът по поддръжката може да се нуждае от оригиналното описание, за да обясни изключение. Потвърдете кои подробности действително се връщат, преди да изграждате интерфейса около тях.
Измервайте наблюдаваното забавяне, без да преувеличавате точността
Разделяйте времето на събитието, времето на наблюдението и времето за обработка от приложението. Времевата отметка към събитие на превозвача не е непременно моментът, в който събитието е станало достъпно онлайн. Следователно сравнението между времето на събитието и времето на получаване от API може да обедини няколко източника на забавяне.
Ако проверявате превозвача периодично, знаете кога за първи път сте наблюдавали събитието, а не точния момент на публикуването му. Запишете интервала на проверка и обозначете резултата като наблюдавано забавяне. Нормализирайте часовите зони и запазете оригиналните времеви отметки, за да могат очевидните проблеми с подреждането да бъдат разследвани.
5. Валидирайте интеграцията при условията на стартиране
Видимостта на маршрута не е достатъчна, ако актуализациите се провалят в приложението ви. Тествайте механизма за актуализации, който действително ще използвате в продукция. При работни процеси, базирани на webhook, проверете документираните удостоверяване, потвърждение, повторен опит и възстановяване. При polling проверете разрешената честота на заявките и начина, по който приложението ви се възстановява след прекъсвания.
- Регистрация: Разграничете приета пратка от отхвърлена заявка и от приета пратка, за която все още няма събития.
- Дублирани актуализации: Уверете се, че повтарящата се информация не изпраща дублирани известия към клиентите.
- Подреждане на събитията: Проверете дали закъсняло пристигнало по-старо събитие не връща доставена пратка обратно в транзит.
- Повреда на крайна точка: Тествайте временно прекъсване на приемащата система и документирания процес за възстановяване.
- Капацитет: Сравнете прогнозите за стартиране и пиковите натоварвания с приложимите ограничения за регистрация и заявки.
- Обработка на данни: Потвърдете кои полета са необходими, ограничете достъпа до идентификационните данни и осигурете преглед от подходящия екип на изискванията за поверителност и договорните изисквания.
Проверете търговските допускания наред с техническите. Попитайте какво се счита за таксувано използване, как се обработват дублираните регистрации и какво се случва при достигане на ограниченията. Не приемайте, че интеграционният тест или пробният период имат същите условия като планираната продукционна схема.
6. Определете измерими критерии за стартиране
Определете критериите за приемане, преди да оценявате резултатите. В противен случай е лесно слаб тест да бъде преинтерпретиран като достатъчен с наближаването на крайния срок за стартиране. Използвайте прагове, съобразени с обещанията към клиентите и оперативната ви експозиция, вместо да заимствате необяснен отраслов показател.
Полезните измерители включват:
- Успешна регистрация: Успешно приетите валидни тестови пратки, разделени на валидните опити за регистрация.
- Наличност на проследяването: Тестваните пратки с използваеми събития за проследяване, разделени на допустимите тествани пратки.
- Улавяне на необходимите етапи: Необходимите етапи, върнати от API, разделени на съответните етапи, наблюдавани в референтните записи.
- Съответствие на крайния резултат: Допустимите завършени пратки, чийто резултат в API съответства на референтния резултат, разделени на проверените допустими завършени пратки.
- Наблюдавано забавяне на актуализациите: Разпределението на забавянията, измерени чрез посочен метод на наблюдение.
Отчитайте необработените бройки с процентите и посочвайте изключенията. Не отчитайте активна пратка като липсващ резултат от доставката. Не изключвайте без отбелязване нерешените проблеми с проследяването. Ако претегляте резултатите според прогнозния обем пратки, покажете и резултатите за отделните маршрути, за да остане видим слаб, но важен маршрут.
Използвайте четири състояния за решение: проверено, когато маршрутът отговаря на договорените тестове; условно, когато известен пропуск има прието решение; все още непроверено, когато доказателствата са непълни; и потвърдено неподдържано, когато пряко потвърждение или диагностицирано ограничение установява това заключение. Само необяснима неуспешна заявка не е достатъчна за последната категория.
7. Стартирайте с изрични резервни варианти и задействащи условия за повторна проверка
За всеки условен маршрут посочете отговорно лице и резервен вариант. Възможностите може да включват ръчни проверки при превозвача, процес за ескалация към поддръжката, различна услуга за доставка или по-общи съобщения към клиентите. Избягвайте да изпращате уверени твърдения за доставката, когато данните за проследяване не ги подкрепят.
Извършвайте повторна проверка, когато услугата на превозвача се промени, партньорът по изпълнението промени маршрутизацията, се появи нов партньор за последната миля или мониторингът разкрие липсващи резултати. Съхранявайте заедно одобрената матрица, доказателствата от тестовете, нерешените проблеми и потвържденията от доставчика. Покритието при навлизане на нов пазар трябва да остане оперативен запис, а не еднократно твърдение при снабдяване.
ЧЗВ
Доказва ли списъкът с поддържани превозвачи покритие за всяка услуга?
Не. Използвайте го, за да идентифицирате потенциална интеграция, след което проверете конкретната услуга, маршрута, изискванията за идентификатор и крайния резултат от доставката. Поискайте пряко потвърждение, когато публичната документация не изяснява тези подробности.
Можем ли да валидираме покритието само чрез доставени пратки?
Доставените пратки помагат да проверите пълнотата на историческите събития и крайните резултати. Те не показват колко бързо пристигат новите събития или как системата ви обработва актуализациите в реално време. Включете активни пратки, преди да одобрите работен процес за чувствителни към времето известия.
Какво да направим, ако API не върне събития за проследяване?
Проверете резултата от заявката, избора на превозвач, необходимите входни данни и дали самият превозвач показва събития. Разграничете очакващите данни от невалидната регистрация и потвърдената липса на поддръжка. Ескалирайте нерешените случаи с номера за проследяване, подробностите на заявката, времевите отметки и референтните доказателства.
Трябва ли всяка пратка да показва митнически събития?
Не приемайте, че всеки маршрут излага митнически етапи чрез проследяването на пратката. Ако тези събития са необходими за работния ви процес, проверете ги конкретно и определете как ще реагира оперативният екип, когато липсват. Липсващата информация за проследяване сама по себе си не доказва митнически проблем.
Можем ли да стартираме, докато някои маршрути остават непроверени?
Ограничено стартиране може да бъде разумно, ако експозицията е разбрана, засегнатите маршрути имат одобрени резервни варианти и някой отговаря за оставащото валидиране. Не представяйте тези маршрути вътрешно като проверени и не основавайте обещания към клиентите на недоказани възможности.
Източници
Използвайте тези официални ресурси, за да проверите обхвата на продукта и изискванията за реализация при оценка на 17TRACK. Процедурите за тестване и критериите за стартиране в това ръководство са оперативни препоръки, а не твърдения за гарантирано покритие на маршрутите.
