Məqalə
praktik bələdçiYenilənib: · Wapp.az
Saytı CRM və anbar proqramına bağlamaq üçün əvvəlcə hansı məlumatın harada əsas sayıldığını müəyyənləşdirin. Sayt sifarişi qəbul edə, CRM müştəri əlaqəsini izləyə, anbar isə qalıq və yığımı idarə edə bilər. Bu bölgü nümunədir; mövcud proqramların imkanlarına görə dəyişir. Aşağıdakı ssenari işlək müştəri inteqrasiyası barədə nəticə iddiası deyil, layihələndirmə bələdçisidir.
Məlumatın sahibi
Məhsul kodu, qiymət, stok və sifariş statusu üçün əsas mənbəni ayrıca yazın. Məsələn, stok anbar sistemindən gəlirsə, saytda edilən əl dəyişikliyinin növbəti yenilənmədə nə olacağını dəqiqləşdirin. İki sistemin eyni sahəni qaydasız dəyişməsi fərqli məlumat yaradır. Məhsul adından fərqli olaraq sabit kod əlaqələndirməni daha aydın edir.
Nümunə sifarişin yolu
- Sayt S-001 nömrəli nümunə sifarişi qəbul edir və məhsul kodlarını saxlayır.
- CRM-də bu sifarişlə əlaqəli müraciət yaranır, məsul əməkdaş müəyyən olunur.
- Anbar məhsulun mövcudluğunu yoxlayır və razılaşdırılmış qaydada rezerv edir.
- Ödəniş və yığım statusları öz mənbələrindən yenilənir.
- Göndəriş məlumatı sayta qaytarılır və müştəriyə uyğun bildiriş verilir.
S-001 izah üçün uydurulmuş identifikatordur. Bu ardıcıllıqda, məsələn, rezervin ödənişdən əvvəl və ya sonra edilməsi biznes qaydasına görə seçilməlidir.
Statusların mənasını uyğunlaşdırın
CRM-də “bağlandı” statusu satışın razılaşdırıldığını, anbarda isə “tamamlandı” məhsulun göndərildiyini bildirə bilər. Onları avtomatik eyniləşdirməyin. “Yeni”, “ödəniş gözləyir”, “yığılır”, “göndərilib” və “ləğv edilib” kimi vəziyyətlər üçün keçid qaydasını yazın. Ləğvdən sonra rezervin açılması və bildirişin göndərilməsi ayrıca yoxlanmalıdır.
Bağlantı kəsiləndə nə baş verir?
Qarşı sistem cavab vermirsə, sifarişin itdiyini fərz etmək olmaz. Göndərilmə cəhdi, qarşı tərəfin cavabı və son vəziyyət izlənə bilməlidir. Təkrar göndərişin yeni sifariş yaratmaması üçün sabit əlaqələndirici identifikator və razılaşdırılmış təkrar emal qaydası lazımdır. Gözləyən xətaları kim görəcək və nə vaxt müdaxilə edəcək — bunu da tapşırığa daxil edin.
Qəbul üçün yoxlama dəsti
- Bir məhsul və bir neçə məhsul olan sifariş.
- Naməlum məhsul kodu və kifayət etməyən stok.
- Eyni sifarişin təkrar ötürülməsi.
- Gecikmiş cavab və müvəqqəti bağlantı problemi.
- Ləğv edilmiş sifarişin rezervə təsiri.
- Məbləğ, məhsul sayı və statusun sistemlərdə uyğunluğu.
Real layihə ilə nümunənin fərqi
Finex-in açıq API sənədi inteqrasiya imkanlarını araşdırmaq üçün başlanğıc mənbədir; konkret hesabın funksiyası və giriş şərti ayrıca təsdiqlənməlidir. Finex API səhifəsi. Timmybaby-nin açıq kataloqu isə məhsulun alıcıya təqdimatını göstərir. Bu iki sayt arasında canlı inteqrasiya olduğu iddia edilmir. Öz layihəniz üçün sistem adları, sənədlər və ötürüləcək sahələr əsasında ayrıca sxem hazırlanmalıdır.
Mövzunu davam etdirin
- API inteqrasiyası xidməti
- Ödəniş və sifariş statusunun yoxlanması
- Finex layihəsinin açıq səhifələri
- İnteqrasiya üçün tələblər siyahısı
Qərardan əvvəl əlavə yoxlama
İnteqrasiya hesabatında son uğurlu ötürmə vaxtını və gözləyən əməliyyatları fərqləndirin. Ümumi “bağlantı var” göstəricisi konkret sifarişin çatdığını sübut etmir.
Bir səhv qeyd düzəldildikdən sonra yalnız həmin əməliyyatı yenidən yoxlayın. Təkrar emalın digər sifarişləri dəyişmədiyi təsdiqlənsin.
Nümunə ssenari
Nümunə qəbul: qarşı sistem sifarişi qəbul edir, amma cavab yolda itir. Göndərən tərəf yenidən cəhd etdikdə eyni sifarişin identifikatoru tanınmalıdır. Həm qeyd, həm əməliyyat nəticəsi təkrarlanmadan yoxlanmalıdır.
