UPS Tracking API və OMS inteqrasiyası: Hansını seçməlisiniz?
Əgər sizə yalnız göndəriş statusu lazımdırsa, UPS izləmə API-si seçin. Bir neçə kanal üzrə sifarişləri, inventarı, icranı, marşrutlaşdırmanı, ləğvləri və qaytarmaları koordinasiya etməlisinizsə, OMS inteqrasiyası seçin. Bir çox e-ticarət əməliyyatında praktiki cavab “ya bu, ya da o” deyil: OMS sifarişin həyat dövrünü idarə edir, daşıyıcı və ya çoxdaşıyıcılı izləmə API-si isə çatdırılma hadisələrini təmin edir.
Düzgün qərar komandanızın görməli olduğu fəaliyyətdən asılıdır. İzləmə səhifəsi yaradan proqramçının tələbi marketplace-i, anbarı, 3PL-i və müştəri xidməti sistemini birləşdirən əməliyyatlar komandasının tələbindən fərqlidir. UPS izləmə API-sini və OMS-i bir-birini əvəz edən həllər kimi qəbul etmək lüzumsuz inkişaf işləri yarada və ya mühüm əməliyyat boşluqları qoya bilər.
Fərq bir cümlə ilə
UPS izləmə API-si daşıyıcı məlumatlarına bağlantıdır. OMS inteqrasiyası isə sifariş iş axınına bağlantıdır.
İzləmə API-si adətən tətbiqə izləmə nömrəsi ilə əlaqəli göndəriş məlumatlarını əldə etməyə və ya göstərməyə kömək edir. Bu məlumat müştəri bildirişlərini, brendli izləmə səhifəsini, daxili göndəriş monitorinqini və ya istisnaların idarə edilməsini dəstəkləyə bilər. Əhatə dairəsi əsasən göndərişin görünürlüğüdür.
Sifariş idarəetmə sistemi daha geniş proses səviyyəsində fəaliyyət göstərir. O, bir neçə satış kanalından gələn sifarişləri koordinasiya edə, inventarı bölüşdürə, icra məntəqələri ilə əlaqə saxlaya, sifarişləri anbarlara və ya 3PL-lərə göndərə, statusu mağazalara və ya marketplace-lərə sinxronlaşdıra bilər. Dəqiq funksiyalar OMS-dən asılı olaraq dəyişir; buna görə imkanlar adından irəli gələn fərziyyələrə deyil, məhsul sənədlərinə əsasən yoxlanmalıdır.
UPS izləmə API-sinin daha yaxşı seçim olduğu hallar
Əsas biznes problemi UPS göndərişlərinin harada olduğunu bilmək və bu məlumatı başqa bir tətbiqdə əlçatan etməkdirsə, birbaşa UPS izləmə inteqrasiyasını seçin.
- Müştəriyə yönəlik izləmə: Veb-saytınız və ya tətbiqiniz müştərilərin mövcud təcrübəni tərk etməsinə ehtiyac yaratmadan göndərişin gedişatını göstərməlidir.
- Dəstək iş axınları: Agentlər yardım masası, CRM və ya sifariş ekranında cari izləmə hadisələrinə ehtiyac duyurlar.
- Çatdırılma bildirişləri: Sisteminiz e-poçt, SMS və ya digər müştəri kommunikasiyaları üçün göndəriş hadisələrini giriş məlumatı kimi istifadə etməlidir.
- İstisnələrin monitorinqi: Əməliyyat heyəti gecikmələri, çatdırılma cəhdlərini və ya təqib tələb edən digər hadisələri müəyyən etməlidir.
- Tək daşıyıcılı əməliyyat: UPS müvafiq göndərişlərin əksəriyyətini və ya hamısını idarə edir, buna görə daşıyıcıya xas inteqrasiya əməliyyat baxımından məntiqlidir.
Bu yanaşmanın əhatə dairəsini müəyyənləşdirmək adətən tam OMS layihəsindən daha dar və asandır. Komanda tələb olunan izləmə nömrəsi formatlarını, hadisə sahələrini, autentifikasiya üsulunu, yenilənmə davranışını, xətaların idarə edilməsini və müştəriyə göstərilən status dilini müəyyən edə bilər. Bunun üçün biznesin sifarişlərin bölüşdürülməsi və ya inventar proseslərini yenidən qurması tələb olunmur.
Lakin izləmə API-si sifariş idarəetmə sistemi kimi qəbul edilməməlidir. İzləmə məlumatları göndərişlə nə baş verdiyini göstərə bilər, lakin özü-özlüyündə sifarişi hansı anbarın icra etməli olduğuna qərar vermir, ehtiyatı rezervləmir, sifarişi bölmür, ləğvi təsdiqləmir və ya qaytarma iş axını yaratmır.
OMS inteqrasiyasının daha yaxşı seçim olduğu hallar
Problem göndəriş yaradılmasından əvvəl başlayırsa və ya daşıyıcı görünürlüğündən sonra da davam edirsə, OMS inteqrasiyasını seçin.
Biznes aşağıdakılardan bir neçəsini koordinasiya etməlidirsə, OMS daha uyğundur:
- Bir neçə mağaza, marketplace və ya satış kanalından gələn sifarişlər
- Mağazalar, anbarlar və icra tərəfdaşları üzrə inventarın mövcudluğu
- Yer, ehtiyat, xidmət səviyyəsi və ya əməliyyat qaydalarına əsaslanan sifariş marşrutlaşdırması
- Qismən göndərişlər, gözləyən sifarişlər, ləğvlər və sifariş dəyişiklikləri
- Anbarlara və ya 3PL sistemlərinə göndərilən icra təlimatları
- OMS ilə satış kanalları arasında status sinxronizasiyası
- Daşıyıcı statusundan daha çox şeyi əhatə edən qaytarmalar, geri ödənişlər və ya satınalmadan sonrakı iş axınları
Bu modeldə UPS daha böyük proses daxilində mümkün daşıyıcı bağlantılarından biridir. OMS icra qeydlərini yarada və ya qəbul edə, daşıyıcı inteqrasiyası isə daşınma məlumatlarını təmin edə bilər. Daha sonra OMS sifarişin həyat dövrünü yeniləmək üçün göndəriş mərhələlərindən istifadə edə bilər, lakin dəqiq davranış cəlb olunan sistemlərdən və uyğunlaşdırma qaydalarından asılıdır.
Bu səbəbdən OMS inteqrasiyası daha böyük tətbiq qərarıdır. Buraya məlumat sahibliyi, inventar sinxronizasiyası, sifariş vəziyyətlərinin tərifləri, anbar prosesləri, istisna növbələri və uzlaşdırma daxil ola bilər. Biznes yalnız daha yaxşı izləmə səhifəsi istədiyi üçün OMS bağlantısı satın almamalı və ya yaratmamalıdır.
UPS izləmə API-si və OMS inteqrasiyası
| Qərar sahəsi | UPS izləmə API-si | OMS inteqrasiyası |
|---|---|---|
| Əsas məqsəd | UPS göndəriş statusunu təqdim etmək və ya emal etmək | Sifarişin həyat dövrünü və icra əməliyyatlarını koordinasiya etmək |
| Əsas məlumat obyekti | İzləmə nömrəsi, bağlama, göndəriş hadisələri | Sifariş, sətir elementləri, inventar, icra, göndəriş və mümkün qaytarmalar |
| Ən uyğun sahib | Məhsul mühəndisliyi, müştəri təcrübəsi və ya dəstək sistemləri | E-ticarət əməliyyatları, icra, müəssisə arxitekturası və mühəndislik |
| Tipik əhatə dairəsi | Bir daşıyıcı və ya izləmə xidməti | Bir neçə kanal, obyekt, sistem və icra tərəfdaşı |
| Avtomatik həll etmədiyi məsələ | İnventarın bölüşdürülməsi, marşrutlaşdırma və ya sifariş orkestrasiyası | İnteqrasiya bunu təmin etmədikdə daşıyıcı hadisələrinin dəqiq normallaşdırılması |
| Tətbiq riski | Sahələrin uyğunlaşdırılması, autentifikasiya, sorğu və ya hadisələrin idarə edilməsi, statusların şərhi | Məlumat sahibliyi, vəziyyət sinxronizasiyası, inventarın dəqiqliyi və sistemlərarası uzlaşdırma |
Bu cədvəl hər bir təchizatçı üçün zəmanəti deyil, adi arxitektura fərqini təsvir edir. Bəzi platformalar sifariş idarəetməsi ilə göndəriş görünürlüğünü birləşdirir, bəzi izləmə provayderləri isə bir neçə daşıyıcını dəstəkləyir. İnteqrasiya modelini seçməzdən əvvəl konkret sənədləri təsdiqləyin.
Bir çox inkişaf edən biznesin ehtiyac duyduğu seçim: OMS və çoxdaşıyıcılı izləmə
UPS-dən başqa daşıyıcılardan da istifadə edən bizneslərə çox vaxt yalnız UPS bağlantısından daha geniş izləmə səviyyəsi lazımdır. Çoxdaşıyıcılı izləmə xidməti daşıyıcılar üzrə göndəriş hadisələrini normallaşdıra, OMS isə sifariş və icra proseslərinə cavabdeh olaraq qala bilər.
17TRACK proqramlaşdırılmış izləmə inteqrasiyasına ehtiyacı olan bizneslər üçün izləmə API-si təqdim edir və tərtibatçı sənədləri yayımlayır. Bu, tələb yalnız UPS-ə aid iş axını deyil, daşıyıcılar üzrə göndəriş görünürlüğüdürsə, əhəmiyyətlidir. Konkret layihə üçün cari API əhatə dairəsini, dəstəklənən əməliyyatları, autentifikasiya tələblərini və tətbiq detallarını təsdiqləmək üçün rəsmi sənədlərdən istifadə edilməlidir.
Bu arxitektura bir neçə icra tərəfdaşı olan pərakəndə satıcı və ya son mil daşıyıcısının təyinatdan asılı olaraq dəyişdiyi sərhədlərarası əməliyyat üçün faydalı ola bilər. OMS sifariş və icra vəziyyətini saxlaya, izləmə səviyyəsi isə müştəriyə yönəlik və ya daxili tətbiqlərə göndəriş yeniləmələrini təmin edə bilər. Bununla belə, iki sistemin aydın sahiblik qaydaları olmalıdır. Məsələn, sifariş statusu üçün hansı sistemin, daşıyıcı hadisələri üçün hansı sistemin əsas mənbə olduğunu və ziddiyyətli yeniləmələrin necə həll ediləcəyini müəyyənləşdirin.
Sadə, yalnız UPS-dən istifadə edən mağaza üçün həm OMS, həm də çoxdaşıyıcılı izləmə xidmətinin əlavə edilməsi lüzumsuz ola bilər. Bir neçə daşıyıcı və kanalı olan biznes üçün isə normallaşdırılmış izləmə səviyyəsindən imtina ayrı-ayrı inteqrasiyalara, uyğunsuz status adlarına və daha çox texniki xidmətə səbəb ola bilər.
Həddindən artıq quruculuğa yol vermədən necə seçim etmək olar
1. Biznes hadisəsindən başlayın
Fəaliyyətə başlamalı olan hadisəni yazın. “Sifariş səhifəsində ən son UPS statusunu göstər” ifadəsi izləmə API-sinə yönəldir. “Ödənilmiş hər sifarişi ən uyğun icra məntəqəsinə göndər və inventarı sinxron saxla” OMS-ə yönəldir. “Bağlama 3PL-dən çıxdıqdan sonra müştərini yenilə” isə hər ikisini tələb edə bilər.
2. Artıq məlumatın sahibi olan sistemləri xəritələndirin
Mağazanı, marketplace-i, ERP-ni, anbar idarəetmə sistemini, 3PL-i, müştəri xidməti platformasını, OMS-i və daşıyıcı bağlantılarını siyahıya alın. Hər biri üçün sifarişləri, inventarı, icra qeydlərini və izləmə hadisələrini yaradıb-yaratmadığını, dəyişdirib-dəyişdirmədiyini və ya yalnız oxuyub-oxumadığını müəyyən edin. Bu, yeni inteqrasiyanın iki rəqabət aparan həqiqət mənbəyi yaratmasının qarşısını alır.
3. Daşıyıcı müxtəlifliyini və coğrafiyanı yoxlayın
Əhatə dairəsində yalnız UPS varsa, birbaşa UPS bağlantısı kifayət edə bilər. Əməliyyat bir neçə daşıyıcıdan, poçt operatorundan və ya təyinatdan asılı son mil tərəfdaşlarından istifadə edirsə, daha geniş izləmə API-sinin ayrıca inteqrasiyaları azaldıb-azaltmayacağını qiymətləndirin. Provayderin hər daşıyıcını, ölkəni və ya hadisə növünü dəstəklədiyini fərz etməyin; göndəriş profiliniz üçün müvafiq əhatə dairəsini yoxlayın.
4. Minimum status modelini müəyyən edin
Daşıyıcı hadisələri çox vaxt müştərilərə göstərilən statuslardan daha ətraflı olur. İnkişafdan əvvəl xam hadisələri etiket yaradıldı, tranzitdə, çatdırılma üçün yoldadır, çatdırıldı, istisna və qaytarıldı kimi biznes vəziyyətlərinə uyğunlaşdırın. Hadisə gecikdikdə, təkrarlandıqda, itdikdə və ya ardıcıllıqdan kənar qəbul edildikdə nə baş verəcəyini müəyyənləşdirin. Bu iş məlumatın birbaşa UPS-dən və ya izləmə platforması vasitəsilə gəlməsindən asılı olmayaraq tələb olunur.
5. Əməliyyat istisnalarını sınaqdan keçirin
Uğurlu nümayiş adətən normal çatdırılmanı izləyir. Faydalı konsepsiya sübutu etibarsız izləmə nömrəsini, hadisəsi olmayan göndərişi, gecikmiş skanı, çatdırılma istisnasını, qismən göndərişi, əvəzedici sifarişi və qaytarmanı da sınaqdan keçirməlidir. OMS layihəsi üçün bölünmüş sifarişləri, inventar çatışmazlığını, ləğv cəhdlərini və təkrarlanan sifariş mesajlarını əlavə edin.
6. Ümumi əməliyyat səylərini müqayisə edin
Yalnız ilkin inteqrasiya səylərini müqayisə etməyin. Monitorinqi, API dəyişikliklərini, dəstək alətlərini, uzlaşdırmanı, daşıyıcıların qoşulmasını, məlumatların saxlanmasını, girişə nəzarəti və nasazlıqların bərpasını da nəzərə alın. Dar problem üçün dar API ən aşağı riskli seçim ola bilər. Biznesdə artıq bir neçə daşıyıcı və icra sistemi varsa, daha geniş platformanı idarə etmək daha asan ola bilər.
Praktiki qərar qaydası
İstənilən nəticə mövcud tətbiqdə etibarlı UPS göndəriş görünürlüğüdürsə, UPS izləmə API-sindən istifadə edin. İstənilən nəticə kanallar və ya məntəqələr üzrə koordinasiya edilmiş sifariş və icra prosesidirsə, OMS inteqrasiyasından istifadə edin. OMS sifarişləri idarə etməli, ayrıca izləmə səviyyəsi isə müştəri xidməti və ya satınalmadan sonrakı təcrübələr üçün göndəriş hadisələrini birləşdirməlidirsə, hər ikisindən istifadə edin.
Variantları qiymətləndirən biznes üçün növbəti addım geniş texniki öhdəlik deyil, kiçik və sənədləşdirilmiş inteqrasiya sınağı olmalıdır. Təmsilçi sifarişləri seçin, gözlənilən sahələri və statusları müəyyənləşdirin, normal və istisna hallarını sınaqdan keçirin və hər qərarın hansı sistemə aid olduğunu qeyd edin. Layihə sonradan əlavə daşıyıcılara genişlənərsə, müstəqil daşıyıcı bağlantılarını bir-bir əlavə etməkdənsə, çoxdaşıyıcılı izləmə API-sinin daha uyğun olub-olmadığını yenidən qiymətləndirin.
Ən güclü seçim növbəti ehtimal olunan tələbi məhdudlaşdırmadan cari əməliyyat problemini həll edən ən kiçik arxitekturadır. İzləmə API-si OMS kimi təqdim edilməməli, OMS isə yalnız izləmə səhifəsini göstərmək üçün tətbiq edilməməlidir.
FAQ
UPS izləmə API-si OMS ilə eynidirmi?
Xeyr. UPS izləmə API-si UPS-dən alınan göndəriş məlumatlarına fokuslanır. OMS inventar, marşrutlaşdırma, icra, ləğvlər və qaytarmalar daxil olmaqla daha geniş sifariş və icra proseslərini koordinasiya edir. Biznes OMS əsaslı arxitektura daxilində izləmə API-sindən istifadə edə bilər.
OMS UPS göndərişlərini izləyə bilərmi?
OMS-in UPS inteqrasiyası varsa və ya ayrıca izləmə xidmətinə qoşulursa, bu mümkün ola bilər. İmkan məhsula xasdır və OMS sənədlərində təsdiqlənməlidir. Təkcə OMS etiketi onun tələb olunan UPS hadisələrini və ya iş axınlarını dəstəklədiyini sübut etmir.
Brendli izləmə səhifəsi yaratmaq üçün OMS-ə ehtiyacım varmı?
Adətən yox. Brendli izləmə səhifəsi ümumiyyətlə göndəriş məlumatlarını qəbul edib müştəriyə təqdim edə bilən tətbiqə və ya izləmə xidmətinə ehtiyac duyur. OMS sifariş kontekstini təmin edə bilər, lakin səhifənin özü üçün avtomatik olaraq zəruri deyil.
Çoxdaşıyıcılı izləmə API-sindən nə vaxt istifadə etməliyəm?
Göndərişlər bir neçə daşıyıcıdan istifadə etdikdə və tətbiqləriniz çatdırılma hadisələrini əldə etmək və ya göstərmək üçün ardıcıl üsula ehtiyac duyduqda bunu nəzərdən keçirin. Faktiki işlədiyiniz marşrutlar üçün provayderin daşıyıcı əhatə dairəsini, hadisə modelini, sənədlərini, xidmət məhdudiyyətlərini və istisnaları idarə etmə qaydasını yoxlayın.
İnteqrasiyadan əvvəl tərtibatçılar nələri aydınlaşdırmalıdır?
Autentifikasiyanı, sorğu və cavab sahələrini, status təriflərini, yenilənmə tezliyini, xətaların idarə edilməsini, təkrarlanan hadisələri, izləmə nömrəsinin yoxlanılmasını, saxlanmanı, təhlükəsizliyi və sistem sahibliyini aydınlaşdırın. Həmçinin izləmə hadisəsinin müştəriyə göstərilən sifariş statusunu necə dəyişdirdiyini sənədləşdirin.
Mənbələr
- UPS Developer Portal — UPS API-ləri və inteqrasiya resursları üçün rəsmi tərtibatçı giriş nöqtəsi.
- 17TRACK Tracking API — proqramlaşdırılmış izləmə inteqrasiyası üçün rəsmi məhsul səhifəsi.
- 17TRACK API Documentation — tətbiqə dair istinad üçün rəsmi tərtibatçı sənədləri.
