Нормализација на статусите за следење на превозниците: Како да се мапираат настаните на превозниците во единствен модел на статуси

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

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

Одделете го настанот на превозникот од состојбата на пратката

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

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

Практичната архитектура има три слоја:

1. Сурови докази: оригиналниот товар од превозникот или давателот, вклучувајќи кодови, текст, временски ознаки и идентификатори.
2. Нормализирани настани: вашата интерпретација на секој поединечен настан со користење верзионирано правило за мапирање.
3. Тековна проекција на пратката: состојбата избрана од историјата на настаните, заедно со активните услови и дејства на клиентот.

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

Дефинирајте компактен модел на статуси со одделни услови

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

Условите како CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE или DELAY_REPORTED чувајте ги надвор од примарното поле на животниот циклус. Пратката може да остане во IN_TRANSIT додека проблемот со адресата бара внимание. Рутинската царинска обработка не ја означувајте како исклучок, освен ако изворот не пријави задржување, проблем или потребно дејство.

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

Изградете го записот за настанот пред да ги напишете правилата за мапирање

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

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

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

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

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

Прво мапирајте ги кодовите на превозникот, а потоа внимателно користете го текстот

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

Користете го следниот редослед на мапирање како стандардна имплементација:

1. Усогласете документиран структуриран код на настанот и сите потребни квалификатори.
2. Користете документиран статус или подстатус од изворот кога јасно го опишува настанот што се обработува.
3. Применете тесно ограничени текстуални правила за познати пораки без доволно структурирани полиња.
4. Неразрешените настани оставете ги без мапирање и испратете ги повторливите случаи на разгледување.

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

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

Илустративни мапирања и нивните ограничувања

Примерите подолу користат измислени пораки за да го прикажат дизајнот на правилата. Тие не се проверени кодови или точни пораки од конкретен превозник.

• Shipment details submitted: мапирајте во PRE_TRANSIT кога дефиницијата на изворот укажува само на електронски информации.
• Accepted at origin facility: мапирајте во IN_TRANSIT кога настанот потврдува физичко прифаќање.
• Recipient unavailable; attempt unsuccessful: запишете DELIVERY_ATTEMPT_FAILED и проценете го животниот циклус врз основа на околните докази. Не заклучувајте дека е достапно преземање.
• Available for collection: мапирајте во READY_FOR_PICKUP кога изворот потврдува подготвеност за преземање од примачот.
• Transferred to delivery partner: запишете предавање и задржете соодветна состојба во транзит, наместо да ја означите испораката до примачот како завршена.

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

Пресметајте ја моменталната состојба со детерминистички редуктор

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

Дедуплицирајте без бришење значајни скенирања

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

Подредете ги настаните без претпоставка за совршени часовници

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

Потврдете ги премините наместо да доделувате универзален ранг

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

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

Следете ги активните услови независно

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

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

Третирајте ги предавањата меѓу превозници и враќањата како поврзани патувања

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

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

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

Користете API за следење без да се откажете од деловните правила

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

Пред поврзување на кој било API со известувања до клиенти или оперативна автоматизација, утврдете:

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

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

Тестирајте истории на настани, а не само поединечни мапирања

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

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

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

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

ЧПП

Дали секој настан за следење треба да има точно еден статус?

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

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

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

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

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

Како треба да се претстават пропуштените ажурирања за следење?

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

Кој треба да одобрува промени на мапирањето?

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

Извори

• RFC 3339: Date and Time on the Internet: Timestamps — референца за претставување временски ознаки и нумерички отстапувања.
• 17TRACK Tracking API — официјална почетна точка за интеграцијата со API за следење опишана погоре.
• 17TRACK API documentation — имплементациска референца за проверка на договорот со давателот; канонскиот модел и примерите за мапирање во овој напис се предложени дизајнерски обрасци, а не дефиниции специфични за давателот.