Synkronisering af salg, lager og priser fra POS til ERP
POS til ERP: salg, lager og priser holdes i takt
Salg og returneringer bogført fra hver butik, lager- og prisændringer sendt tilbage og dagens totaler afstemt.
Arkitekturskitse
Rul sidelæns for at se hele tegningen.
POS til ERP: hvert salg bogført én gang
Salget går fra kasserne til ERP-systemet som hændelser, og priser og lager går tilbage. En butik, der går offline, bliver ved med at sælge og indhenter bagefter. En bogføring, der fejler, forsøges igen og gives derefter til en person.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 8 trin
Forløbet, trin for trin
- Fra POS-terminaler til Butiks- eller POS-cloudserver: Salg, returneringer og annulleringer (primært flow).
- Fra Butiks- eller POS-cloudserver til Integrationslag: Salgshændelser og dagens totaler, gennem en hændelseskø, over REST/JSON (asynkron).
- Fra Integrationslag til ERP: Salg og lagerbevægelser bogført, over OData · REST/JSON (primært flow).
- Fra ERP til Integrationslag: Priser, kampagner og varedata, via API eller fileksport, over REST/JSON (primært flow).
- Fra Integrationslag til Butiks- eller POS-cloudserver: Pris- og lageropdateringer, over REST/JSON (primært flow).
- Fra Integrationslag til Kø til gentagne forsøg: Bogføring mislykkedes (undtagelsessti).
- Fra Kø til gentagne forsøg til Integrationslag: Forsøgt igen (undtagelsessti).
- Fra Kø til gentagne forsøg til Butiksdriftsteam: Fejler stadig: alarm med detaljerne (undtagelsessti).
Oversigt
Dette er flowet mellem kasserne i dine butikker og ERP-systemet bag dem. Salg, returneringer og annulleringer sendes op til ERP-systemet. Priser, kampagner, varedata og lagerstatus sendes ned igen. Når de to glider fra hinanden, sælger butikkerne til forkert pris, ingen stoler længere på lagertallene, og økonomiafdelingen bruger månedsafslutningen på afstemning.
Referencedesignet sender hver butikstransaktion som en hændelse gennem et integrationslag med en kø. Laget oversætter hver hændelse til ERP-systemets salgs- og lagerbilag og bogfører den præcis én gang. I den anden retning sendes ændringer i ERP-systemet til de butikker, der har brug for dem, så alle kasser arbejder ud fra de samme data.
Butikker mister forbindelsen, og det tager designet højde for. Butiksserveren eller POS-cloudserveren bliver ved med at sælge og indhenter, når forbindelsen er tilbage. En bogføring, der fejler, forsøges igen, og en, der bliver ved med at fejle, overdrages til en person med detaljerne i stedet for at forsvinde.
Sådan fungerer flowet
Sælg ved kassen
Hvert salg, hver returnering og hver annullering registreres på POS-terminalen med en unik identifikator, butikken, kassen og tidspunktet.
Opbevar i butikken
Butiksserveren eller POS-cloudserveren indsamler transaktionerne og sender dem videre som hændelser og opbevarer dem sikkert, mens butikken er offline.
Bogfør i ERP
Integrationslaget oversætter hver hændelse til salg og lagerbevægelser og bogfører den i ERP-systemet, og det kontrollerer identifikatoren, så intet bogføres to gange.
Send priser og varer
Varedata, priser og kampagner udgives fra ERP-systemet, når de ændres, med dato og de butikker, hver ændring gælder for.
Opdater alle butikker
Laget leverer hver ændring til de butikker, den gælder for, og registrerer, hvilke butikker der har bekræftet den.
Når noget fejler
En bogføring fejler
Midlertidige fejl forsøges igen med stigende ventetid. En bogføring, der stadig fejler, går til en dead-letter-kø, og teamet for butiksdrift får en alarm med transaktionen og fejlen.
En butik går offline
Butikken fortsætter salget på sine lokale data. Transaktionerne holdes tilbage og sendes i rækkefølge, når forbindelsen er tilbage, og en butik, der er tavs for længe, udløser en alarm.
En transaktion kommer to gange
Hver transaktion har en unik identifikator. Laget genkender en gentagelse og ignorerer den, så en genafsendelse efter et nedbrud aldrig fordobler et salg.
Butikkens og ERP-systemets totaler afviger
Dagens totaler fra hver butik sammenlignes med det, ERP-systemet har modtaget. En difference åbner en gennemgang med de manglende eller ekstra transaktioner opført.
Standarder og systemer
- Data og analyser
- Apache Kafka
- ERP-systemer
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integration
- REST
- Webhooks
- RabbitMQ
Spørgsmål og svar
Skal salget bogføres i realtid eller i batches?
Normalt som hændelser tæt på realtid, fordi lager- og salgstal så er aktuelle i løbet af dagen. Nogle ERP-systemer eller licenser gør hyppige bogføringer dyre, så laget kan også samle hændelser i opsummeringer pr. butik og periode. Vi vælger sammen med dig ud fra, hvilke beslutninger der kræver aktuelle data, og hvad ERP-systemet håndterer godt.
Hvordan afstemmes dagens totaler?
Hver butik sender sine totaler ved dagens afslutning fordelt på betalingstype og afdeling. Laget sammenligner dem med de transaktioner, ERP-systemet har modtaget for samme butik og dag. Stemmer de, lukkes dagen. Hvis ikke, viser gennemgangen de manglende eller ekstra transaktioner, så dit team kan rette årsagen i stedet for at bogføre en korrektion.
Kan kampagner og prisændringer planlægges på forhånd?
Ja. Hver pris- eller kampagneændring sendes i forvejen med datoen og de butikker, den gælder for, så kasserne skifter på det rigtige tidspunkt, uden at nogen i butikken skal gøre noget. Laget registrerer, hvilke butikker der har bekræftet ændringen, og markerer dem, der ikke har.
Hvordan ruller I det ud i mange butikker?
Vi starter med en pilot i nogle få butikker og sammenligner hver dag deres totaler med den nuværende proces. Når totalerne stemmer, ruller vi ud i grupper i et tempo, som dit team for butiksdrift kan følge med i. Den gamle proces forbliver tilgængelig for hver butik, indtil det nye flow har bevist sit værd.
Hvilke POS- og ERP-systemer fungerer det med?
Designet fungerer med ethvert POS-system, der kan eksportere transaktioner via et API, hændelser eller filer, og med ERP-systemer som SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central og Odoo. Vi bekræfter grænsefladerne i dit konkrete POS- og ERP-system fra starten. At vi nævner et produkt, betyder ikke et partnerskab med leverandøren.
Hvem håndterer fejlede bogføringer efter idriftsættelsen?
Det aftales før idriftsættelsen. Normalt håndterer dit team for butiksdrift eller økonomi forretningsfejl, f.eks. en ukendt vare, fra en gennemgangsliste, og det tekniske team håndterer fejl i selve flowet. Vi kan levere den tekniske support som en del af en løbende aftale, med driftsmanualen (runbook) delt med dit team.
Start med en samtale, ikke en kontrakt.
Fortæl os, hvad du skal bygge, forbinde eller sikre. En arkitekt gennemgår det med dig og anbefaler derefter, hvor du skal starte.
Det sker der nu
Aftale om tidspunkt
Vores team sender dig en e-mail for at aftale et tidspunkt for sessionen.
Forhåndskonsultation
En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Valg af spor
Projekter med et klart omfang modtager et bindende forslag inden for 3 til 5 hverdage. Projekter i konceptfasen starter i Blueprint Studio. Et system i drift, der fejler, er udokumenteret eller skal integreres, starter med en diagnosticering på 1 til 2 uger. Blueprint Studio og diagnosticeringen har hver et fast honorar, som er angivet i forslaget.