Synkronisering av försäljning, lager och priser mellan POS och ERP
POS till ERP: försäljning, lager och priser i takt
Försäljning och returer bokförs från varje butik, lager- och prisändringar skickas tillbaka och dagens slutsummor stäms av.
Ritning
Rulla i sidled för att se hela ritningen.
POS till ERP: varje försäljning bokförd en gång
Försäljning flödar från kassorna till ERP som händelser, och priser och lager flödar tillbaka. En butik som går offline fortsätter sälja och kommer ikapp. En misslyckad bokföring får ett nytt försök och lämnas sedan över till en person.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 8 steg
Flödet, steg för steg
- Från POS-terminaler till Butik eller POS-molnserver: Försäljning, returer och annulleringar (primärt flöde).
- Från Butik eller POS-molnserver till Integrationslager: Försäljningshändelser och dagssummer, genom en händelsekö, över REST/JSON (asynkront).
- Från Integrationslager till ERP: Försäljning och lagerrörelser bokförda, över OData · REST/JSON (primärt flöde).
- Från ERP till Integrationslager: Priser, kampanjer och artikeldata, via API eller filexport, över REST/JSON (primärt flöde).
- Från Integrationslager till Butik eller POS-molnserver: Pris- och lageruppdateringar, över REST/JSON (primärt flöde).
- Från Integrationslager till Kö för nya försök: Bokföringen misslyckades (undantagsväg).
- Från Kö för nya försök till Integrationslager: Nytt försök (undantagsväg).
- Från Kö för nya försök till Team för butiksdrift: Misslyckas fortfarande: larm med detaljerna (undantagsväg).
Översikt
Det här är flödet mellan kassorna i dina butiker och ERP-systemet bakom dem. Försäljning, returer och annulleringar går upp till ERP-systemet. Priser, kampanjer, artikeldata och lager går tillbaka ner. När de två glider ifrån varandra säljer butikerna till fel pris, lagersiffrorna slutar att gå att lita på och finansavdelningen ägnar månadsskiftet åt avstämning.
Referensdesignen skickar varje butikstransaktion som en händelse genom ett integrationslager med en kö. Lagret mappar varje händelse till ERP-systemets försäljnings- och lagerdokument och bokför den exakt en gång. I andra riktningen skickas ändringar i ERP-systemet till de butiker som behöver dem, så att varje kassa arbetar utifrån samma data.
Butiker tappar förbindelsen, och designen räknar med det. Butiken eller molnservern för POS-systemet fortsätter att sälja och kommer i kapp när linjen är tillbaka. En bokföring som misslyckas görs om, och en som fortsätter att misslyckas lämnas till en person med uppgifterna i stället för att försvinna.
Så fungerar flödet
Sälj i kassan
Varje försäljning, retur och annullering registreras i POS-terminalen med en unik identifierare, butiken, kassan och tiden.
Håll kvar i butiken
Butiken eller molnservern för POS-systemet samlar transaktionerna och skickar dem vidare som händelser, och håller dem säkert medan butiken är offline.
Bokför i ERP-systemet
Integrationslagret mappar varje händelse till försäljnings- och lagerrörelser och bokför den i ERP-systemet, med kontroll av identifieraren så att inget bokförs två gånger.
Skicka priser och artiklar
Artikeldata, priser och kampanjer publiceras från ERP-systemet när de ändras, med datum och vilka butiker varje ändring gäller.
Uppdatera alla butiker
Lagret levererar varje ändring till de butiker den gäller och registrerar vilka butiker som bekräftat den.
När något går fel
En bokföring misslyckas
Tillfälliga fel görs om med ökande väntetider. En bokföring som fortfarande misslyckas hamnar i en dead-letter-kö, och butiksdriftens team larmas med transaktionen och felet.
En butik går offline
Butiken fortsätter att sälja på sina lokala data. Transaktionerna hålls kvar och skickas i ordning när förbindelsen är tillbaka, och en butik som är tyst för länge larmar.
En transaktion kommer in två gånger
Varje transaktion har en unik identifierare. Lagret känner igen en upprepning och ignorerar den, så att en omsändning efter ett avbrott aldrig fördubblar en försäljning.
Butikens och ERP-systemets summor skiljer sig
Dagens slutsummor från varje butik jämförs med vad ERP-systemet tog emot. En skillnad öppnar en granskning med de saknade eller överskjutande transaktionerna listade.
Standarder och system
- Data och analys
- Apache Kafka
- ERP-system
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integration
- REST
- Webhooks
- RabbitMQ
Frågor och svar
Bör försäljning bokföras i realtid eller i satser?
Vanligen som händelser nära realtid, eftersom lager- och försäljningssiffrorna då är aktuella under dagen. Vissa ERP-system eller licenser gör täta bokföringar kostsamma, så lagret kan också gruppera händelser till sammanställningar per butik och period. Vi väljer tillsammans utifrån vilka beslut som behöver aktuell data och vad ERP-systemet hanterar väl.
Hur stäms dagens slutsummor av?
Varje butik skickar sina slutsummor per betalningssätt och avdelning. Lagret jämför dem med de transaktioner ERP-systemet tog emot för samma butik och dag. Stämmer de stängs dagen. Om inte listar granskningen de saknade eller överskjutande transaktionerna, så att ditt team kan åtgärda orsaken i stället för att bokföra en justering.
Går det att schemalägga kampanjer och prisändringar i förväg?
Ja. Varje pris- eller kampanjändring skickas ut i förväg med datum och vilka butiker den gäller, så att kassorna slår om i rätt ögonblick utan att någon i butiken behöver göra något. Lagret registrerar vilka butiker som bekräftat ändringen och flaggar dem som inte gjort det.
Hur rullas det här ut i många butiker?
Vi börjar med en pilot i några butiker och jämför deras summor med nuvarande process varje dag. När summorna stämmer rullar vi ut i grupper, i en takt som butiksdriftens team kan stödja. Den gamla processen finns kvar för varje butik tills det nya flödet har visat sig fungera.
Vilka POS- och ERP-system fungerar det här med?
Designen fungerar med alla POS-system som kan exportera transaktioner via API, händelser eller filer, och med ERP-system som SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central och Odoo. Vi bekräftar gränssnitten i ditt specifika POS- och ERP-system i början. Att ett produktnamn nämns betyder inte att vi är partner med leverantören.
Vem hanterar misslyckade bokföringar när det är i drift?
Det kommer vi överens om före driftsättningen. Vanligen hanterar ditt butiksdriftsteam eller din finansfunktion affärsfel, som en okänd artikel, från en granskningslista, och det tekniska teamet hanterar fel i själva flödet. Vi kan stå för den tekniska supporten som en del av ett löpande avtal, med driftsmanualerna delade med ditt team.
Börja med ett samtal, inte ett avtal.
Berätta vad du behöver bygga, koppla samman eller skydda. En arkitekt går igenom det med dig och rekommenderar sedan var du ska börja.
Vad som händer härnäst
Vi enas om en tid
Vårt team mejlar dig för att enas om en tid för samtalet.
Förberedande samtal
En kostnadsfri förkonsultation online i 30 minuter: vi går igenom dina mål, system och begränsningar.
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Val av spår
Projekt med tydlig omfattning får ett bindande förslag inom 3 till 5 arbetsdagar. Projekt i konceptfasen börjar i Blueprint Studio. Ett system i drift som fallerar, är odokumenterat eller behöver integreras börjar med en diagnostik på 1 till 2 veckor. Blueprint Studio och diagnostiken har var sitt fasta pris som anges i förslaget.