Synchronisatie van omzet, voorraad en prijzen tussen POS en ERP
POS naar ERP: omzet, voorraad en prijzen gelijk gehouden
Omzet en retouren uit elke winkel geboekt, voorraad- en prijswijzigingen teruggehaald, en dagtotalen afgestemd.
Blauwdruk
Scroll zijwaarts om de hele tekening te zien.
POS naar ERP: elke verkoop één keer geboekt
Verkopen stromen als events van de kassa’s naar het ERP, en prijzen en voorraad stromen terug. Een winkel die offline gaat, verkoopt door en haalt de achterstand in. Een boeking die mislukt, wordt opnieuw geprobeerd en daarna aan een persoon overgedragen.
- Hoofdstroom
- Asynchroon
- Uitzonderingspad
De stroom in 8 stappen
De stroom, stap voor stap
- Van POS-terminals naar Winkel- of POS-cloudserver: Verkopen, retouren en annuleringen (hoofdstroom).
- Van Winkel- of POS-cloudserver naar Integratielaag: Verkoopevents en dagtotalen, via een eventwachtrij, via REST/JSON (asynchroon).
- Van Integratielaag naar ERP: Verkopen en voorraadmutaties geboekt, via OData · REST/JSON (hoofdstroom).
- Van ERP naar Integratielaag: Prijzen, acties en artikeldata, via API of bestandsexport, via REST/JSON (hoofdstroom).
- Van Integratielaag naar Winkel- of POS-cloudserver: Prijs- en voorraadupdates, via REST/JSON (hoofdstroom).
- Van Integratielaag naar Wachtrij voor nieuwe pogingen: Boeking mislukt (uitzonderingspad).
- Van Wachtrij voor nieuwe pogingen naar Integratielaag: Opnieuw geprobeerd (uitzonderingspad).
- Van Wachtrij voor nieuwe pogingen naar Winkeloperationeel team: Nog steeds mislukt: melding met de details (uitzonderingspad).
Overzicht
Dit is de stroom tussen de kassa’s in uw winkels en het ERP erachter. Omzet, retouren en annuleringen gaan omhoog naar het ERP. Prijzen, acties, artikeldata en voorraad gaan terug. Wanneer beide uit elkaar lopen, verkopen winkels tegen de verkeerde prijs, wordt de voorraad niet meer vertrouwd en besteedt finance de maandafsluiting aan afstemmen.
Het referentieontwerp stuurt elke winkeltransactie als gebeurtenis via een integratielaag met een wachtrij. De laag mapt elke gebeurtenis naar de omzet- en voorraaddocumenten van het ERP en boekt die precies één keer. In de andere richting worden wijzigingen in het ERP naar de winkels gestuurd die ze nodig hebben, zodat elke kassa met dezelfde data werkt.
Winkels verliezen hun verbinding, en het ontwerp houdt daar rekening mee. De winkel of POS-cloudserver blijft verkopen en haalt in wanneer de lijn terugkeert. Een mislukte boeking wordt opnieuw geprobeerd, en een boeking die blijft mislukken gaat met de details naar een persoon in plaats van te verdwijnen.
Hoe de flow werkt
Verkoop aan de kassa
Elke verkoop, retour en annulering wordt op de POS-terminal vastgelegd met een unieke identificatie, de winkel, de kassa en het tijdstip.
Houd vast in de winkel
De winkel of POS-cloudserver verzamelt de transacties en stuurt ze als gebeurtenissen door, terwijl ze veilig worden bewaard wanneer de winkel offline is.
Boek in het ERP
De integratielaag mapt elke gebeurtenis naar omzet- en voorraadmutaties en boekt die in het ERP, waarbij de identificatie wordt gecontroleerd zodat niets dubbel wordt geboekt.
Stuur prijzen en artikelen
Artikeldata, prijzen en acties worden bij wijziging vanuit het ERP gepubliceerd, met de datum en de winkels waarop elke wijziging van toepassing is.
Werk elke winkel bij
De laag levert elke wijziging aan de winkels waarop die van toepassing is, en registreert welke winkels die hebben bevestigd.
Wat als er iets misgaat
Een boeking mislukt
Tijdelijke fouten worden opnieuw geprobeerd met toenemende vertraging. Een boeking die blijft mislukken gaat naar een dead-letterwachtrij, en het team voor winkeloperaties krijgt een melding met de transactie en de fout.
Een winkel gaat offline
De winkel blijft handelen met zijn lokale data. Transacties worden vastgehouden en op volgorde verzonden wanneer de verbinding terugkeert, en een winkel die te lang stil blijft geeft een melding.
Een transactie komt twee keer binnen
Elke transactie draagt een unieke identificatie. De laag herkent een herhaling en negeert die, zodat een herzending na een storing nooit een verkoop verdubbelt.
Totalen van winkel en ERP verschillen
Dagtotalen van elke winkel worden vergeleken met wat het ERP ontving. Een verschil opent een beoordeling met de ontbrekende of extra transacties op een rij.
Standaarden en systemen
- Data en analytics
- Apache Kafka
- ERP-systemen
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integratie
- REST
- Webhooks
- RabbitMQ
Vragen en antwoorden
Moet omzet in realtime of in batches worden geboekt?
Meestal als gebeurtenissen bijna realtime, omdat voorraad- en omzetcijfers dan gedurende de dag actueel zijn. Sommige ERP’s of licenties maken frequente boekingen duur, dus de laag kan gebeurtenissen ook groeperen in samenvattingen per winkel en periode. We kiezen met u op basis van welke beslissingen actuele data nodig hebben en wat het ERP goed aankan.
Hoe worden dagtotalen afgestemd?
Elke winkel stuurt zijn dagtotalen per betaalwijze en afdeling. De laag vergelijkt ze met de transacties die het ERP voor dezelfde winkel en dag ontving. Komen ze overeen, dan wordt de dag gesloten. Zo niet, dan vermeldt de beoordeling de ontbrekende of extra transacties, zodat uw team de oorzaak kan oplossen in plaats van een correctie te boeken.
Kunnen acties en prijswijzigingen vooraf worden gepland?
Ja. Elke prijs- of actiewijziging wordt vooraf verzonden met de datum en de winkels waarop die van toepassing is, zodat de kassa’s op het juiste moment omschakelen zonder dat iemand in de winkel iets hoeft te doen. De laag registreert welke winkels de wijziging hebben bevestigd en markeert de winkels die dat niet deden.
Hoe rolt u dit uit over veel winkels?
We beginnen met een pilot in enkele winkels en vergelijken hun totalen dagelijks met het huidige proces. Zodra de totalen overeenkomen, rollen we uit in groepen, in een tempo dat uw team voor winkeloperaties aankan. Het oude proces blijft per winkel beschikbaar tot de nieuwe stroom is bewezen.
Met welke POS- en ERP-systemen werkt dit?
Het ontwerp werkt met elk POS dat transacties via een API, gebeurtenissen of bestanden kan exporteren, en met ERP’s zoals SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central en Odoo. We bevestigen aan het begin de interfaces van uw specifieke POS en ERP. Het noemen van een product betekent geen partnerschap met de leverancier ervan.
Wie behandelt mislukte boekingen zodra het live is?
Dat spreken we af vóór de livegang. Meestal behandelt uw team voor winkeloperaties of finance zakelijke fouten, zoals een onbekend artikel, uit een beoordelingslijst, en behandelt het technische team fouten in de stroom zelf. We kunnen die technische ondersteuning leveren als onderdeel van een doorlopende overeenkomst, met het runbook gedeeld met uw team.
Begin met een gesprek, niet met een contract.
Vertel ons wat u wilt bouwen, verbinden of beveiligen. Een architect neemt het met u door en adviseert daarna waar te beginnen.
Wat er nu gebeurt
Een tijd afspreken
Ons team mailt u om een tijd voor de sessie af te spreken.
Voorgesprek
Een gratis online voorafgaand adviesgesprek van 30 minuten: we bespreken uw doelen, systemen en beperkingen.
Gereedheidsanalyse
In een gratis gereedheidsanalyse van 48 uur toetst een Principal Architect uw project aan de 6-punts Definition of Ready en adviseert het traject dat past.
Het traject kiezen
Projecten met een heldere scope ontvangen binnen 3–5 werkdagen een bindend voorstel. Projecten in de conceptfase starten in de Blueprint Studio. Een live systeem dat uitvalt, ongedocumenteerd is of integratie nodig heeft, begint met een diagnose van 1–2 weken. De Blueprint Studio en de diagnose hebben elk een vaste prijs, vermeld in het voorstel.