Daşıyıcı izləmə statuslarının normallaşdırılması: Daşıyıcı hadisələrini vahid status modelinə necə uyğunlaşdırmaq olar

Daşıyıcının izləmə statusunun normallaşdırılması daşıyıcıya xas skan kodlarının və mesajlarının ilkin sübutları qorumaqla ardıcıl göndəriş modelinə çevrilməsi deməkdir. Bunu etibarlı şəkildə həyata keçirmək üçün hər hadisəni kanonik status və səbəblə əlaqələndirin, sonra hadisənin vaxtı, göndəriş konteksti və açıq keçid qaydalarından istifadə edərək göndərişin cari vəziyyətini hesablayın. Alınmış ən yeni mesajı avtomatik olaraq göndərişin cari statusu kimi qəbul etməyin.

Bu təlimat izləməni sifariş idarəetmə sisteminə, dəstək panelinə və ya müştəri bildirişləri iş axınına inteqrasiya edən tərtibatçılar, logistika əməliyyatları komandaları və məhsul sahibləri üçündür. Aşağıdakı model rəsmi daşıyıcı standartı və ya hər hansı izləmə provayderinin status taksonomiyasının təkrar istehsalı deyil, təklif olunan tətbiq nümunəsidir.

Daşıyıcı hadisəsini göndəriş vəziyyətindən ayırın

İzləmə hadisəsi göndəriş haqqında bildirilən bir şeyi təsvir edir: etiket yaradılıb, bağlama müəssisəyə çatıb və ya çatdırılma cəhdi uğursuz olub. Göndəriş vəziyyəti isə tətbiqinizin müəyyən vaxt nöqtəsində müvafiq sübutları şərh etməsidir. Bu anlayışlar ayrıca saxlanmalıdır.

Məsələn, bağlamada çatdırılma cəhdi hadisəsindən sonra müəssisəyə çatma hadisəsi baş verə bilər. Çatma əməliyyat tarixçəsi üçün faydalıdır, lakin bu, uğursuz cəhd vəziyyətinin aradan qalxdığı anlamına gəlmir. Əksinə, çatdırılmanın təsdiqindən sonra daxil olan gecikmiş skan bağlamanı avtomatik olaraq yenidən tranzit vəziyyətinə keçirməməlidir.

Praktik arxitektura üç təbəqədən ibarətdir:

1. Xam sübut: kodlar, mətnlər, vaxt möhürləri və identifikatorlar daxil olmaqla, daşıyıcının və ya provayderin ilkin yükü.
2. Normallaşdırılmış hadisələr: versiyalanmış xəritələndirmə qaydasından istifadə etməklə hər bir fərdi hadisənin şərhi.
3. Cari göndəriş proyeksiyası: hadisə tarixçəsindən seçilən vəziyyət, həmçinin aktiv şərtlər və müştəri tədbirləri.

Bu ayırma ilkin qeydi silmədən xəritələndirmələri düzəltməyə və göndəriş vəziyyətlərini yenidən qurmağa imkan verir.

Ayrı şərtlərlə yığcam status modeli müəyyənləşdirin

Fiziki hərəkəti, gömrük emalını, çatdırılma problemlərini və qaytarmaları eyni vaxtda ifadə etməli olduqda, tək status sahəsini saxlamaq çətinləşir. Kiçik həyat dövrü modeli istifadə edin, sonra daha konkret şərtlər və səbəblər əlavə edin.

CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE və ya DELAY_REPORTED kimi şərtləri əsas həyat dövrü sahəsindən kənarda saxlayın. Ünvan problemi diqqət tələb etdiyi halda göndəriş IN_TRANSIT olaraq qala bilər. Mənbə saxlanma, problem və ya tələb olunan tədbir barədə məlumat vermədikdə, adi gömrük emalını istisna halı kimi işarələməyin.

İstiqaməti journey_type kimi ayrıca sahə ilə göstərin. Qaytarma öz tranzit və çatdırılma vəziyyətlərinə malik ola bilər. Bu, satıcıya qaytarılan çatdırılmanı alıcıya uğurlu çatdırılma kimi şərh etməyin qarşısını alır.

Xəritələndirmə qaydalarını yazmazdan əvvəl hadisə qeydini yaradın

Normallaşdırılmış qeyd xəritələndirməni izah etmək və nəticəni yenidən yaratmaq üçün kifayət qədər kontekst daşımalıdır. Faydalı ilkin sxemə aşağıdakılar daxildir:

• İdentifikasiya: daxili göndəriş ID-si, daşıyıcı identifikatoru, izləmə nömrəsi, mənbə və göndəriş mərhələsi.
• İlkin sübut: xam hadisə kodu, xam təsvir, təqdim edildikdə mənbə hadisə ID-si və ilkin yükə istinad.
• Vaxt: hadisənin başvermə vaxtı, saat qurşağı məlumatı, qəbul vaxtı və vaxt möhürünün dəqiqliyi.
• Şərh: kanonik status, şərt, səbəb kodu, səyahət növü və tədbir tələbi.
• İzlənəbilənlik: xəritələndirmə qaydasının ID-si, xəritələndirmə versiyası və etimad kateqoriyası.

Hadisənin başvermə vaxtını sisteminizin yeniləməni qəbul etdiyi vaxtdan ayrı saxlayın. Günortadan sonra alınan webhook səhər baş vermiş skanı təsvir edə bilər. Sorğu cavabında da bir yeni hadisə əvəzinə bir neçə tarixi hadisə ola bilər.

Vaxt və ofset məlum olduqda RFC 3339 kimi sənədləşdirilmiş vaxt formatından istifadə edin. Mənbə etibarlı ofset olmadan yerli vaxt təqdim edirsə, saxta UTC göstəricisi əlavə etmək əvəzinə bu məhdudiyyəti qoruyun. Yalnız tarixlə verilən hadisələri dəqiq skan vaxtı uydurmadan yalnız tarix sübutu kimi saxlayın.

Xam yükləri müvafiq giriş nəzarətləri və saxlama qaydaları altında saxlayın. Onlarda alıcının məlumatları və ya geniş əlçatan analitika cədvəlinə aid olmayan digər məlumatlar ola bilər.

Əvvəlcə daşıyıcı kodlarını xəritələndirin, sonra mətndən ehtiyatla istifadə edin

Mənbə və konkret daşıyıcı üçün məhdudlaşdırılmış qaydalarla başlayın. 01 kimi kodun sənədləşdirilmiş kontekstdən kənarda etibarlı mənası yoxdur. Mənbə xidmətləri, regionları və ya mərhələləri fərqləndirirsə, şərhə təsir etdikdə həmin ölçüləri də daxil edin.

İcra üçün standart olaraq aşağıdakı xəritələndirmə sırasından istifadə edin:

1. Sənədləşdirilmiş strukturlaşdırılmış hadisə kodunu və tələb olunan əlavə göstəriciləri uyğunlaşdırın.
2. Emal olunan hadisəni aydın təsvir etdikdə, sənədləşdirilmiş mənbə statusundan və ya alt-statusdan istifadə edin.
3. Adekvat strukturlaşdırılmış sahələri olmayan məlum mesajlar üçün dar əhatəli mətn qaydaları tətbiq edin.
4. Həll olunmamış hadisələri xəritələndirmədən saxlayın və təkrarlanan halları nəzərdən keçirilməyə göndərin.

Əvvəlcə provayderin status sahəsinin fərdi hadisəni, yoxsa göndərişin cari xülasəsini təsvir etdiyini müəyyənləşdirin. Göndəriş səviyyəli xülasənin hər tarixi hadisəyə köçürülməsi əvvəlki skanların çatdırılma təsdiqi kimi görünməsinə səbəb ola bilər.

“delivered ehtiva edir” kimi qlobal açar söz qaydalarından qaçın. “not delivered” ifadəsi də uyğun gələ bilər, logistika tərəfdaşına çatdırılmanı təsvir edən mesaj da. Mətn qaydaları inkarın emalını, dil kontekstini və istisnaları nəzərə almalıdır. Maşın tərcüməsi rəyçiyə mesajı anlamaqda kömək edə bilər, lakin tərcümə edilmiş ifadə səssiz şəkildə mötəbər hadisə tərifinə çevrilməməlidir.

Nümunəvi xəritələndirmələr və onların məhdudiyyətləri

Aşağıdakı nümunələr qayda dizaynını göstərmək üçün uydurulmuş mesajlardan istifadə edir. Bunlar təsdiqlənmiş daşıyıcı kodları və ya konkret daşıyıcıdan götürülmüş dəqiq mesajlar deyil.

• “Shipment details submitted”: mənbənin tərifi yalnız elektron məlumatı göstərdikdə PRE_TRANSIT statusuna xəritələndirin.
• “Accepted at origin facility”: hadisə fiziki qəbulu təsdiqlədikdə IN_TRANSIT statusuna xəritələndirin.
• “Recipient unavailable; attempt unsuccessful”: DELIVERY_ATTEMPT_FAILED qeyd edin və həyat dövrünü ətrafdakı sübutlara əsasən qiymətləndirin. Götürmənin mümkün olduğunu fərz etməyin.
• “Available for collection”: mənbə alıcının götürməyə hazır olduğunu təsdiqlədikdə READY_FOR_PICKUP statusuna xəritələndirin.
• “Transferred to delivery partner”: təhvil verməni qeyd edin və alıcıya çatdırılmanı tamamlanmış kimi işarələmək əvəzinə uyğun tranzit statusunu saxlayın.

Hər qaydanın qısa əsaslandırması və sahibi olmalıdır. Əməliyyat mütəxəssisi xəritələndirmə ilə razılaşmadıqda, komanda müştəriyə göstərilən etiketi geriyə doğru təhlil etmək əvəzinə dəqiq qaydanı müəyyən edə bilməlidir.

Cari vəziyyəti deterministik reduktorla hesablayın

Reduktor normallaşdırılmış hadisələri qiymətləndirən və cari göndəriş proyeksiyasını yaradan funksiyadır. Eyni sübut və qayda versiyası üçün girişin neçə dəfə təkrar oynadılmasından asılı olmayaraq eyni nəticəni qaytarmalıdır.

Mənalı skanları silmədən təkrarları aradan qaldırın

Mümkün olduqda sabit mənbə hadisə identifikatoruna üstünlük verin. Əks halda göndəriş identikliyi, daşıyıcı, kod, başvermə vaxtı və məkan kimi mövcud atributlardan təkrarların aradan qaldırılması açarı yaradın. Vaxt möhürünün dəqiqliyini və mənbənin davranışını nəzərə alın. Eyni təsvirə malik iki skan, xüsusilə bağlama müəssisəyə yenidən baş çəkirsə, mütləq təkrar deyil.

Mükəmməl saatları fərz etmədən hadisələri sıralayın

Mövcud olduqda etibarlı başvermə vaxtlarından və sənədləşdirilmiş ardıcıllıq məlumatlarından istifadə edin. Qəbul vaxtı bərabərlikləri həll etməyə kömək edə bilər, lakin adətən daha erkən başvermə vaxtını üstələməməlidir. Vaxt möhürləri ziddiyyət təşkil edirsə və ya etibarlı şəkildə müqayisə edilə bilmirsə, süni əminlik yaratmaq əvəzinə qeyri-müəyyənliyi qoruyun.

Universal sıralama təyin etmək əvəzinə keçidləri təsdiqləyin

Statusların sadə rəqəmsal sıralaması hər göndəriş marşrutunu ifadə edə bilməz. Uğursuz cəhddən sonra bağlama çatdırılma üçün yola çıxmış vəziyyətdən yenidən tranzitə keçə bilər. Götürməyə hazır olma müddəti bitə bilər. Açıq düzəliş çatdırılma təsdiqini etibarsız edə bilər.

İcazə verilən keçidləri və hər biri üçün tələb olunan sübutları müəyyənləşdirin. Çatdırılmış statusunu adi köhnə skanlardan qorunan hesab edin, lakin sənədləşdirilmiş düzəlişə və ya səlahiyyətli əməliyyat ləğvinə icazə verin. İstənilən ləğvin səbəbini və mənbəyini qeyd edin.

Aktiv şərtləri müstəqil izləyin

Sonrakı hərəkət skanı irəliləyiş göstərə bilər, lakin ödəniş və ya ünvan probleminin həll olunduğunu sübut etmir. Şərtə xas təmizləmə qaydaları müəyyənləşdirin: açıq həll, məntiqi olaraq həll edən hadisə və ya səlahiyyətli əl ilə görülən tədbir. Başqa hadisə gəldiyi üçün hər bir şərti avtomatik silməyin.

Həmçinin daşıyıcının bildirdiyi gecikməni öz fəaliyyətsizlik xəbərdarlığınızdan ayırın. Yeni skanların olmaması məlumatın yenilənməsi barədə müşahidədir, bağlamanın itirildiyinə dair sübut deyil.

Daşıyıcı təhvilvermələrini və qaytarmaları əlaqəli səyahətlər kimi idarə edin

Ölkələrarası izləmə bir neçə daşıyıcı və identifikatoru əhatə edə bilər. Daxili göndəriş identikliyini saxlayın və daşıyıcıya xas izləmə istinadlarını müvafiq mərhələlərə əlavə edin. İstinadları yalnız oxşar təyinatlara və ya yaxın vaxt möhürlərinə əsasən deyil, mənbənin təqdim etdiyi əlaqələr və ya təsdiqlənmiş əməliyyat məlumatları ilə əlaqələndirin.

Mərhələ səviyyəsində çatdırılma hadisəsi kontekstdə şərh edilməlidir. Konsolidasiya müəssisəsinə və ya tərəfdaş şəbəkəsinə çatdırılma həmin mərhələni tamamlaya bilər, lakin alıcıya çatdırılmanı tamamlamaya bilər. Göndəriş proyeksiyanız hadisənin hansı təyinatı ifadə etdiyini bilməlidir.

Eyni şəkildə, “return requested”, “return movement started” və “returned to sender” ifadələrini ayırın. Bunlar müxtəlif mərhələləri təsvir edir. Qaytarma tələbi bağlamanın fiziki olaraq geri hərəkət etdiyini sübut etmir və əks səyahətin çatdırılma təsdiqi qaytarma təyinatını göstərməlidir.

Öz biznes qaydalarınızdan imtina etmədən izləmə API-sindən istifadə edin

Çoxdaşıyıcılı inteqrasiya ümumi məlumat qəbulu nöqtəsi təmin edə bilər, lakin ortaq cavab formatı aydın daxili müqaviləyə olan ehtiyacı aradan qaldırmır. 17TRACK Tracking API-ni qiymətləndirərkən tətbiqinizə aid sahələrin və interfeyslərin mənasını yoxlamaq üçün onun rəsmi sənədlərindən istifadə edin. Bu təlimatda təklif olunan statusların onun yerli taksonomiyası ilə uyğun olduğunu fərz etməyin.

Hər hansı API-ni müştəri bildirişlərinə və ya əməliyyat avtomatlaşdırmasına qoşmazdan əvvəl aşağıdakıları müəyyənləşdirin:

• Hansı sahələrin fərdi hadisələri, hansılarının isə cari göndəriş xülasəsini təsvir etdiyini.
• İlkin daşıyıcı məlumatlarından hansılarının açıqlandığını və saxlanıla bildiyini.
• Vaxt möhürlərinin, çatışmayan dəyərlərin, düzəlişlərin və təkrarlanan yeniləmələrin necə təqdim edildiyini.
• Qaytarma səyahətlərinin və aralıq tərəfdaşlara çatdırılmanın necə fərqləndiriləcəyini.
• İnteqrasiyanızın naməlum kodlara və gələcək sxem dəyişikliklərinə necə cavab verəcəyini.

Xarici cavab ilə kanonik model arasında nazik adapter saxlayın. Bu, tətbiqinizin qalan hissəsinə hər bir yuxarı axın sahəsinin adına bağlı olmadan vahid izləmə statusu müqaviləsindən istifadə etməyə imkan verir. Bildiriş qaydalarını başqa təbəqə kimi qəbul edin: yeni normallaşdırılmış hadisə avtomatik olaraq müştəri mesajını işə salmamalıdır.

Yalnız fərdi xəritələndirmələri deyil, hadisə tarixçələrini də yoxlayın

Xəritələndirmə ayrı-ayrılıqda düzgün ola bilər, lakin yenə də yanlış göndəriş vəziyyəti yarada bilər. Hadisələrin başvermə vaxtlarından fərqli ardıcıllıqla çatdırıldığı yeniləmələr də daxil olmaqla, tam tarixçələri yoxlayın.

• Gecikmiş tarixçə: çatdırılma təsdiqi köhnə tranzit skanından əvvəl gəlir. Göndəriş çatdırılmış olaraq qalır.
• Təkrar qəbul: eyni hadisə yenidən emal olunur. Təkrar müştəri bildirişi göndərilmir.
• Uğursuz cəhd: çatdırılma üçün yola çıxmış vəziyyətdən sonra uğursuz cəhd baş verir. Dəstəkləyici sübut olmadan proyeksiya artıq aktiv çatdırılma səfərinə söz vermir.
• Götürməyə hazır olma: bağlama hazır olduğu təsdiqlənməzdən əvvəl götürmə müəssisəsinə çatır. Vaxtından əvvəl götürmə təlimatı verilmir.
• Naməlum hadisə: yeni kod görünür. Xam qeyd saxlanılır və əvvəllər müəyyən edilmiş göndəriş vəziyyəti avtomatik olaraq naməlum ilə əvəz edilmir.
• Qaytarma hərəkəti: əks səyahət göndəricidə başa çatır. İlkin alıcıya çatdırılma uğurlu kimi işarələnmir.
• Düzəliş: açıq mənbə düzəlişi yoxlanıla bilən keçid vasitəsilə nəticəni dəyişir.

Daşıyıcı və mənbə üzrə xəritələndirilməmiş hadisələri, mətn ehtiyatından istifadəni, etibarsız keçidləri və təkrar bildiriş cəhdlərini izləyin. Xəritələndirmənin tamlığını düzgünlüyündən ayırın: hər kodu tanımaq, onun şərhi yanlışdırsa, faydalı deyil.

Xəritələndirmə dəyişikliyini tətbiq etməzdən əvvəl nümunəvi tarixçələri yenidən oynadın və köhnə ilə yeni proyeksiyaları müqayisə edin. Çatdırılma təsdiqinə, götürmə təlimatlarına, qaytarmanın tamamlanmasına və ya müştəri tədbirinə təsir edən fərqləri nəzərdən keçirin. Qaydaları versiyalayın ki, dəstək agenti sistemin konkret nəticəni nə üçün yaratdığını izah edə bilsin.

Tez-tez verilən suallar

Hər izləmə hadisəsinin dəqiq bir statusu olmalıdır?

Hər hadisənin bir əsas normallaşdırılmış şərhi ola bilər, lakin ona şərt, səbəb və səyahət konteksti də lazım ola bilər. Bütün mənanı tək düz status siyahısına məcbur etmək modeli istifadə və saxlama baxımından çətinləşdirir.

Naməlum hadisə cari göndəriş statusunu əvəz etməlidir?

Adətən yox. Son dəstəklənən göndəriş vəziyyətini saxlayarkən hadisənin xəritələndirməsini həll olunmamış saxlayın. Məlumatın yenilənmə vəziyyətini ayrıca göstərin ki, istifadəçilər köhnə təsdiqlənmiş vəziyyəti son yeniləmə ilə səhv salmasınlar.

Çatdırılmış göndəriş yenidən tranzitə keçə bilər?

Köhnə tranzit skanı bu dəyişikliyə səbəb olmamalıdır. Yoxlanılmış düzəliş bunu əsaslandıra bilər, yeni başlayan qaytarma səyahəti isə adətən ayrıca göstərilməlidir. Keçid üçün sadəcə daha gec qəbul vaxtı deyil, açıq səbəb tələb olunur.

Çatışmayan izləmə yeniləmələri necə göstərilməlidir?

Daxili yenilənmə göstəricisindən və ya fəaliyyətsizlik xəbərdarlığından istifadə edin. Bunu daşıyıcının bildirdiyi gecikmə, itki və ya istisna statuslarından ayrı saxlayın. İstənilən eskalasiya həddi universal fərziyyəyə deyil, xidmət öhdəliklərinizə və əməliyyat siyasətinizə əsaslanmalıdır.

Xəritələndirmə dəyişikliklərini kim təsdiqləməlidir?

İcra və yenidən oynatma testlərinə mühəndislik, daşınma mənasının təsdiqinə logistika əməliyyatları, mesaj nəticələrinin təsdiqinə isə müştəri təcrübəsi sahibi cavabdeh olmalıdır. Qeyri-müəyyən hadisələrin qeyri-müəyyən müddətə həllsiz qalmaması üçün adı müəyyən edilmiş qərar sahibi təyin edin.

Mənbələr

• RFC 3339: İnternetdə tarix və vaxt: Vaxt möhürləri — vaxt möhürlərinin və rəqəmsal ofsetlərin təqdimatı üçün istinad.
• 17TRACK Tracking API — yuxarıda müzakirə edilən izləmə API inteqrasiyası üçün rəsmi giriş nöqtəsi.
• 17TRACK API sənədləri — provayderin müqaviləsini yoxlamaq üçün tətbiq istinadı; bu məqalədəki kanonik model və xəritələndirmə nümunələri provayderə xas təriflər deyil, təklif olunan dizayn nümunələridir.