<< Click pentru afișare cuprins >> Navigare:  SmartCash eCommerce Service > Procesele de schimb de date cu un site eCommerce > Actualizarea articolelor

 

Intr-o solutie integrata SmartCash RMS – eCommerce, controlul asupra nomenclatorului de produse (articole) este efectuat totdeauna din centrala de magazine, folosind programul existent SmartCash HQ.

 

Odata adaugat un nou articol el este disponibil pentru actualizarea listei de articole si pe site-ul eCommerce. Toate articolele ce urmeza a fi comandate pe site-ul eCommerce si livrate efectiv prin solutia SmartCash RMS trebuie sa fie adaugate prima data in nomenclator din sistemul SmartCash. Din acest motiv, acest tip de actualizare este totdeauna unidirectionala dinspre SmartCash RMS catre site-ul eCommerce.

 

Orice tip de entitate de tip nomenclator SmartCash, cum este si cazul articolelor, primeste un cod unic de identificare in sistemul SmartCash (numeric de tip intreg), camp ce este denumit in cadrul metodelor cu sufixul IDSMARTCASH…. In acelasi timp, orice entitate de tip nomenclator poate primi in sistemul eCommerce si un cod specific unic in acest sistem (de tip alfanumeric). Acest cod este denumit in cadrul metodelor folosind sufixul IDEXTAPP…

 

Este datoria sistemului eCommerce sa salveze in cadrul propriei baze de date codul IDSMARTCASH si corespondenta dintre codul propriu si acesta pentru fiecare articol utilizat prin interfata.

 

Metodologia de integrare a articolelor noi sau modificate primite din SmartCash de catre site-ul eCommerce cuprinde urmatorii pasi:

1.Se apeleaza ciclic metoda GetNextModifiedArticles cu parametrul isFullCodes = 1 pentru a primi lista cu toate articolele, active sau inactive, impreuna cu preturile si caracteristicile lor, precum si cu toate codurile asociate acelui articol in sistemul SmartCash RMS. Vor fi returnate toate articolele nou adaugate sau modificate in sistemul SmartCash de la ultima apelare a aceleiasi metode. Metoda GetNextModifiedArticles se va apela recursiv pana cand intoarce un rezultat nul. Ea este o metoda paginata la maxim 5.000 inregistrari pentru a putea vehicula seturi mari de date. Dupa fiecare apelare, dupa ce datele au fost salvate in sistemul eCommerce, se vor efectua operationile descrise in continuare, apoi, dupa confirmarea cu metoda ConfirmReceivingDataByTypeOf, se va reapela aceeasi metoda pana cand ea intoarce rezultatul nul. Abia apoi se poate considera un ciclu de preluare a articolelor modificate finalizat.

2.Inregistrarea articolelor intoarse dupa fiecare apel intr-o tabela tampon din baza de date a site-ului eCommerce pe baza urmatorului protocol aproximativ:

oToate campurile articolelor primite sunt salvate in tabela tampon, indiferent daca vor fi sau nu utilizata (publicate) pe site;

oPentru articolele salvate se va pastra campul de referinta IDSMARTCASH, primit pentru fiecare articol, impreuna cu toate campurile disponibile in setul JSON pentru articole (pret vanzare, clasificari, TVA, etc). Campul IDSMARTCASH va fi folosit la transmiterea articolelor comandate prin interfata.

oDin nodul ITEM_CODES al fiecarui articol, se va salva obligatoriu codul corespunzator tipului de cod SALECODE_NAME = PLU (Price Lookup). Acest cod, furnizat in campul SALECODE, trebuie sa fie afisat pe site-ul online cu titulatura SKU (Stock Keeping Unit), fiind echivalentul acestui cod din sistemul SmartCash RMS. El este utilizat in toate operatiunile de livrare ca si cod de referinta utilizator, fiind listat si pe facturi si pe comenzi.

oLa nivelul interfetei de administrare a site-ului, vor fi afisate toate articolele primite prin interfata. Vor fi afisate toate informatiile necesare, inclusiv codurile PLU=SKU. Articolele nou adaugate trebuie sa poata fi filtrate pe baza unui flag ce trebuie sa aiba cel putin 2 stari. Acestea sunt de exemplu: New, Not-Published, Published. Cele trei stari vor fi folosite astfel:

▪Articolele care sunt in regim New, sunt articole nou sosite prin interfata, care necesita revizuirea caracteristicilor si publicarea ulterioara pe site pentru a fi disponibile pentru vanzare online;

▪Odata cu revizuirea lor, operatorul de backend le va publica pe site, ocazie cu care articolul respectiv trece in starea Published;

▪Daca exista articole ce nu se doreste a fi publicate online, se va folosi cel de-al treilea tip de flag, denumit generic Not-Published. Ca urmare articolul respectiv nu va aparea pe site pentru vanzare, dar va ramane disponibil in tabela tampon pentru eventuale noi actualizari sosite dinspre sistemul SmartCash.

oIn cazul articolelor care exista deja in sistemul eCommerce si pentru care se primesc modificari prin interfata SmartCash, aceste modificari se pot trata in doua moduri:

▪In cazul in care de exemplu preturile de vanzare se stabilesc prin conventie, tot de catre sistemul SmartCash, modificarea acestora duce automat la retrimiterea articolului modificat prin interfata. In acest caz, articolul respectiv se va actualiza automat in sistemul eCommerce doar sub aspectul pretului de vanzare, iar in tabela tampon, dupa efectuarea automata a modificarii va fi marcat direct cu flag-ul Published. Operatia e valabila si pentru alte cazuri posibile, cum ar fi delistarea sau modificarea vreunei clasificari. Totdeauna pretul de vanzare primit pentru un articol corespunde listei de preturi a magazinului cu care este mapat sit-ul online. Codul acestui magazin este trimis de catre aplicatia terta in campul aNrShop al metodei GetNextModifiedArticles.

▪Un alt caz este acela in care se doreste validarea intermediara de catre un operator uman a modificarilor sosite pentru articolele existente prin interfata (nu numai a articolelor nou adaugate). In aceasta situatie este necesara introducerea unui al 4-lea flag denumit Modified pentru articolele din tabela tampon. Pentru articolele modificate, un operator uman va decide prin metode proprii site-ului daca modificarile vor fi propagate catre articolul publicat pe site  sau nu. In fiecare caz, dupa efectuarea operatiei articolul va fi marcat cu flag-ul Published sau Not-Published dupa caz, fiind astfel pregatit pentru un nou ciclu de actualizare. Nu recomandam insa aceasta metoda, prima varianta fiind folosita in majoritatea situatiilor.

3.Dupa salvarea articolelor nou sosite sau efectuarea modificarilor in site-ul eCommerce, va fi confirmata primirea pachetului de date catre sistemul SmartCash, prin apelarea metodei ConfirmReceivingDataByTypeOf. Parametrii importanti pentru confirmare sunt: aTypeOf=101 in acest caz si aIndexValue ce trebuie sa aiba valoarea returnata in campul RECVERSION de apelul metodei GetNextModifiedArticles pentru care se face confirmarea.

4.Metoda GetNextModifiedArticles este apelata apoi din nou, repetand acelasi proces, pana cand rezultatul returnat este gol (nu mai sunt articole modificate – deci toate paginile de articole modificate, continand maximum 5.000 inregistrari au fost primite).

5.In principiu apelarea ciclica a metodei GetNextModifiedArticles se face folosind un serviciu de tip Cron, larg raspadit pe platformele web actuale, care va rula ciclic un proces la intervale de timp prestabilite (de regula de ordinul minutelor sau a zecilor de minute, in functie de latenta tolerata a actualizarii), in interiorul caruia este apelata recursiv metoda GetNextModifiedArticles. Procesul initiat de cron, trebuie sa fie unul automat, transparent utilizatorilor, al carui efect vizibil trebuie sa fie popularea listei de articole aflate in starea New sau Modified. Procesul si eventualele erori returnate trebuie sa poata fi salvate intr-un log pentru depistarea eventualelor erori de sincronizare.

6.    In situatia in care sunt necesare reinitializari ale nomenclatorului de articole la nivelul aplicatiei eCommerce sau la prima cuplare aunui nou sit cu SmartCash RMS, acest lucru se va efectua tot folosind metoda GetNextModifiedArticles. Retransmiterea tuturor articolelor este initiata din sistemul SmartCash RMS, folosind metoda standard de reinitializare folosita si pentru magazine (Retea Magazine/Reinitializare Articole). Dupa aplicarea acestei operatii toate articolele sunt marcate pentru sincronizarea in reteaua de magazine si deci si pentru locatia mapata cu magazinul online. Prin urmare apelarea recursiva a metodei GetNextModifiedArticles va produce efectul initializat de operator din centrala, acela de a trimite toate articolele inca o data, fara nevoia de a implementa alt tip de sincronizare.