Sincronizarea vânzărilor, stocului și prețurilor între POS și ERP
De la POS la ERP: vânzări, stoc și prețuri ținute în pas
Vânzări și retururi înregistrate din fiecare magazin, modificări de stoc și de preț trimise înapoi și totaluri de sfârșit de zi reconciliate.
Blueprint
Derulați lateral pentru a vedea întregul desen.
POS către ERP: fiecare vânzare postată o singură dată
Vânzările curg de la casele de marcat la ERP ca evenimente, iar prețurile și stocurile curg înapoi. Un magazin care rămâne offline continuă să vândă și se sincronizează la revenire. O înregistrare care eșuează este reîncercată, apoi predată unei persoane.
- Flux principal
- Asincron
- Cale de excepție
Fluxul în 8 pași
Fluxul, pas cu pas
- De la Terminale POS la Server de magazin sau cloud POS: Vânzări, retururi și anulări (flux principal).
- De la Server de magazin sau cloud POS la Strat de integrare: Evenimente de vânzare și totaluri de sfârșit de zi, printr-o coadă de evenimente, prin REST/JSON (asincron).
- De la Strat de integrare la ERP: Vânzări și mișcări de stoc postate, prin OData · REST/JSON (flux principal).
- De la ERP la Strat de integrare: Prețuri, promoții și date despre articole, prin API sau export de fișier, prin REST/JSON (flux principal).
- De la Strat de integrare la Server de magazin sau cloud POS: Actualizări de prețuri și stocuri, prin REST/JSON (flux principal).
- De la Strat de integrare la Coadă de reîncercări: Postare eșuată (cale de excepție).
- De la Coadă de reîncercări la Strat de integrare: Reîncercat (cale de excepție).
- De la Coadă de reîncercări la Echipa de operațiuni a magazinelor: Încă eșuează: alertă cu detalii (cale de excepție).
Prezentare generală
Acesta este fluxul dintre casele de marcat din magazinele dumneavoastră și ERP-ul din spatele lor. Vânzările, retururile și anulările urcă spre ERP. Prețurile, promoțiile, datele articolelor și stocul coboară înapoi. Când cele două se desincronizează, magazinele vând la prețul greșit, cifrele de stoc nu mai sunt de încredere, iar finanțele petrec închiderea de lună reconciliind.
Arhitectura de referință trimite fiecare tranzacție din magazin ca eveniment printr-un strat de integrare cu o coadă. Stratul transformă fiecare eveniment în documentele de vânzări și de stoc din ERP și îl înregistrează exact o dată. În sens invers, modificările din ERP sunt trimise magazinelor care au nevoie de ele, astfel încât fiecare casă de marcat să lucreze cu aceleași date.
Magazinele își pierd conexiunea, iar arhitectura se așteaptă la asta. Magazinul sau serverul cloud al POS-ului continuă să vândă și se sincronizează când linia revine. O înregistrare care eșuează este reîncercată, iar una care continuă să eșueze ajunge la o persoană, cu toate detaliile, în loc să dispară.
Cum funcționează fluxul
Vânzarea la casă
Fiecare vânzare, retur și anulare este înregistrată pe terminalul POS cu un identificator unic, magazinul, casa și momentul.
Păstrarea în magazin
Magazinul sau serverul cloud al POS-ului colectează tranzacțiile și le trimite mai departe ca evenimente, păstrându-le în siguranță cât timp magazinul este offline.
Înregistrarea în ERP
Stratul de integrare transformă fiecare eveniment în vânzări și mișcări de stoc și le înregistrează în ERP, verificând identificatorul, astfel încât nimic să nu fie înregistrat de două ori.
Trimiterea prețurilor și articolelor
Datele articolelor, prețurile și promoțiile sunt publicate din ERP când se modifică, împreună cu data și magazinele cărora li se aplică fiecare modificare.
Actualizarea fiecărui magazin
Stratul livrează fiecare modificare magazinelor cărora li se aplică și consemnează care magazine au confirmat-o.
Când ceva eșuează
O înregistrare eșuează
Defecțiunile temporare sunt reîncercate cu intervale tot mai mari. O înregistrare care continuă să eșueze ajunge într-o coadă de mesaje eșuate, iar echipa de operațiuni a magazinelor este alertată cu tranzacția și eroarea.
Un magazin trece offline
Magazinul continuă să vândă pe baza datelor locale. Tranzacțiile sunt păstrate și trimise în ordine când revine conexiunea, iar un magazin care tace prea mult timp declanșează o alertă.
O tranzacție sosește de două ori
Fiecare tranzacție are un identificator unic. Stratul recunoaște o repetare și o ignoră, astfel încât o retrimitere după o întrerupere nu dublează niciodată o vânzare.
Totalurile din magazin și din ERP diferă
Totalurile de sfârșit de zi din fiecare magazin sunt comparate cu ceea ce a primit ERP-ul. O diferență deschide o verificare în care sunt listate tranzacțiile lipsă sau în plus.
Standarde și sisteme
- Date și analize
- Apache Kafka
- Sisteme ERP
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integrare
- REST
- Webhooks
- RabbitMQ
Întrebări și răspunsuri
Vânzările ar trebui înregistrate în timp real sau în loturi?
De obicei ca evenimente apropiate de timp real, pentru că cifrele de stoc și de vânzări sunt atunci actuale pe parcursul zilei. Unele ERP-uri sau licențe fac costisitoare înregistrările frecvente, așa că stratul poate grupa evenimentele în sumar pe magazin și perioadă. Alegem împreună cu dumneavoastră, în funcție de deciziile care au nevoie de date actuale și de ce gestionează bine ERP-ul.
Cum sunt reconciliate totalurile de sfârșit de zi?
Fiecare magazin își trimite totalurile de sfârșit de zi pe tipuri de plată și raioane. Stratul le compară cu tranzacțiile pe care ERP-ul le-a primit pentru același magazin și aceeași zi. Dacă se potrivesc, ziua este închisă. Dacă nu, verificarea listează tranzacțiile lipsă sau în plus, astfel încât echipa dumneavoastră să poată elimina cauza în loc să înregistreze o ajustare.
Promoțiile și modificările de preț pot fi programate în avans?
Da. Fiecare modificare de preț sau promoție este trimisă din timp, împreună cu data și magazinele cărora li se aplică, astfel încât casele de marcat să comute la momentul potrivit fără ca cineva din magazin să intervină. Stratul consemnează care magazine au confirmat modificarea și semnalează pe cele care nu au făcut-o.
Cum extindeți acest lucru la multe magazine?
Începem cu un proiect pilot în câteva magazine și comparăm zilnic totalurile cu procesul actual. Când totalurile se potrivesc, extindem în grupuri, într-un ritm pe care echipa dumneavoastră de operațiuni a magazinelor îl poate susține. Procesul vechi rămâne disponibil pentru fiecare magazin până când noul flux este dovedit.
Cu ce sisteme POS și ERP funcționează?
Arhitectura funcționează cu orice POS care poate exporta tranzacții printr-un API, prin evenimente sau fișiere, și cu ERP-uri precum SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central și Odoo. Confirmăm la început interfețele POS-ului și ale ERP-ului dumneavoastră. Menționarea unui produs nu înseamnă un parteneriat cu furnizorul său.
Cine se ocupă de înregistrările eșuate după lansare?
Acest lucru se convine înainte de lansare. De obicei, echipa dumneavoastră de operațiuni a magazinelor sau de finanțe tratează erorile de business, cum ar fi un articol necunoscut, dintr-o listă de verificare, iar echipa tehnică tratează defecțiunile din fluxul propriu-zis. Putem asigura acel suport tehnic în cadrul unui acord continuu, cu manualul de operare partajat echipei dumneavoastră.
Începeți cu o conversație, nu cu un contract.
Spuneți-ne ce trebuie să construiți, să conectați sau să securizați. Un arhitect parcurge totul împreună cu dumneavoastră, apoi recomandă de unde să începeți.
Ce se întâmplă în continuare
Convenirea unei ore
Echipa noastră vă scrie prin e-mail pentru a conveni o oră pentru sesiune.
Sesiune de preconsultanță
O sesiune online gratuită de preconsultanță de 30 de minute: trecem în revistă obiectivele, sistemele și constrângerile dumneavoastră.
Evaluarea de pregătire
Într-o evaluare de pregătire gratuită în 48 de ore, un arhitect principal verifică proiectul dumneavoastră față de definiția „pregătit” în 6 puncte și recomandă traseul potrivit.
Alegerea traseului
Proiectele cu scop definit primesc o propunere fermă în 3–5 zile lucrătoare. Proiectele aflate în faza de concept încep în Blueprint Studio. Un sistem live care eșuează, nu este documentat sau are nevoie de integrare începe cu un diagnostic de 1–2 săptămâni. Blueprint Studio și diagnosticul au fiecare un tarif fix, cotat în propunere.