Synchronisation von Umsätzen, Beständen und Preisen vom POS zum ERP
POS zum ERP: Umsätze, Bestände und Preise im Gleichschritt
Umsätze und Retouren aus jeder Filiale gebucht, Bestands- und Preisänderungen zurückgesendet und Tagesabschlusssummen abgestimmt.
Blueprint
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
POS zum ERP: jeder Verkauf genau einmal verbucht
Umsätze fließen als Ereignisse von den Kassen ins ERP, Preise und Bestand fließen zurück. Eine Filiale, die offline geht, verkauft weiter und holt auf. Eine fehlgeschlagene Buchung wird wiederholt und dann an einen Menschen übergeben.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 8 Schritten
Der Ablauf Schritt für Schritt
- Von POS-Terminals nach Filial- oder POS-Cloud-Server: Umsätze, Retouren und Stornos (primärer Ablauf).
- Von Filial- oder POS-Cloud-Server nach Integrationsschicht: Umsatzereignisse und Tagesabschlüsse über eine Ereigniswarteschlange, über REST/JSON (asynchron).
- Von Integrationsschicht nach ERP: Umsätze und Bestandsbewegungen verbucht, über OData · REST/JSON (primärer Ablauf).
- Von ERP nach Integrationsschicht: Preise, Aktionen und Artikeldaten per API oder Dateiexport, über REST/JSON (primärer Ablauf).
- Von Integrationsschicht nach Filial- oder POS-Cloud-Server: Preis- und Bestandsaktualisierungen, über REST/JSON (primärer Ablauf).
- Von Integrationsschicht nach Wiederholungswarteschlange: Buchung fehlgeschlagen (Fehlerpfad).
- Von Wiederholungswarteschlange nach Integrationsschicht: Erneut versucht (Fehlerpfad).
- Von Wiederholungswarteschlange nach Filialbetriebsteam: Weiterhin fehlgeschlagen: Warnung mit den Details (Fehlerpfad).
Überblick
Das ist der Fluss zwischen den Kassen in Ihren Filialen und dem ERP dahinter. Umsätze, Retouren und Stornos wandern zum ERP hinauf. Preise, Aktionen, Artikelstammdaten und Bestände wandern hinunter. Driften beide auseinander, verkaufen Filialen zu falschen Preisen, Bestandszahlen werden nicht mehr geglaubt, und Finanzen verbringt den Monatsabschluss mit Abstimmung.
Das Referenzdesign sendet jede Filialtransaktion als Ereignis über eine Integrationsschicht mit einer Queue. Die Schicht bildet jedes Ereignis auf die Umsatz- und Bestandsbelege des ERPs ab und bucht es genau einmal. In die andere Richtung werden Änderungen im ERP an die Filialen gesendet, die sie brauchen, sodass jede Kasse mit denselben Daten arbeitet.
Filialen verlieren ihre Verbindung, und das Design rechnet damit. Der Server in der Filiale oder die POS-Cloud verkauft weiter und holt auf, wenn die Leitung zurückkehrt. Eine Buchung, die fehlschlägt, wird wiederholt, und eine, die weiter fehlschlägt, wird mit den Details an einen Menschen übergeben, statt zu verschwinden.
So funktioniert der Ablauf
An der Kasse verkaufen
Jeder Umsatz, jede Retoure und jedes Storno wird am POS-Terminal mit einer eindeutigen Kennung, der Filiale, der Kasse und der Uhrzeit erfasst.
In der Filiale puffern
Der Server in der Filiale oder die POS-Cloud sammelt die Transaktionen und sendet sie als Ereignisse weiter, sicher verwahrt, solange die Filiale offline ist.
Ins ERP buchen
Die Integrationsschicht bildet jedes Ereignis auf Umsatz- und Bestandsbewegungen ab und bucht es ins ERP, wobei sie die Kennung prüft, damit nichts doppelt gebucht wird.
Preise und Artikel senden
Artikelstammdaten, Preise und Aktionen werden bei Änderung aus dem ERP veröffentlicht, mit dem Datum und den Filialen, für die die Änderung gilt.
Jede Filiale aktualisieren
Die Schicht liefert jede Änderung an die Filialen, für die sie gilt, und zeichnet auf, welche Filialen sie bestätigt haben.
Wenn etwas fehlschlägt
Eine Buchung schlägt fehl
Vorübergehende Fehler werden mit wachsenden Abständen wiederholt. Eine Buchung, die weiter fehlschlägt, geht in eine Dead-Letter-Queue, und das Team für den Filialbetrieb wird mit Transaktion und Fehler benachrichtigt.
Eine Filiale geht offline
Die Filiale verkauft mit ihren lokalen Daten weiter. Transaktionen werden zurückgehalten und in Reihenfolge gesendet, wenn die Verbindung zurückkehrt, und eine Filiale, die zu lange schweigt, löst eine Warnung aus.
Eine Transaktion kommt doppelt an
Jede Transaktion trägt eine eindeutige Kennung. Die Schicht erkennt eine Wiederholung und ignoriert sie, sodass ein erneutes Senden nach einem Ausfall nie einen Umsatz verdoppelt.
Summen von Filiale und ERP weichen ab
Tagesabschlusssummen jeder Filiale werden mit dem verglichen, was das ERP erhalten hat. Eine Abweichung eröffnet eine Prüfung mit den fehlenden oder zusätzlichen Transaktionen.
Standards und Systeme
- Daten und Analytik
- Apache Kafka
- ERP-Systeme
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integration
- REST
- Webhooks
- RabbitMQ
Fragen und Antworten
Sollten Umsätze in Echtzeit oder in Batches gebucht werden?
Meist als Ereignisse nahe der Echtzeit, weil Bestands- und Umsatzzahlen dann tagsüber aktuell sind. Manche ERPs oder Lizenzen machen häufige Buchungen teuer, deshalb kann die Schicht Ereignisse auch zu Zusammenfassungen je Filiale und Periode bündeln. Wir entscheiden mit Ihnen danach, welche Entscheidungen aktuelle Daten brauchen und was das ERP gut verarbeitet.
Wie werden Tagesabschlusssummen abgestimmt?
Jede Filiale sendet ihre Tagesabschlusssummen nach Zahlungsart und Abteilung. Die Schicht vergleicht sie mit den Transaktionen, die das ERP für dieselbe Filiale und denselben Tag erhalten hat. Stimmen sie überein, ist der Tag geschlossen. Wenn nicht, listet die Prüfung die fehlenden oder zusätzlichen Transaktionen, sodass Ihr Team die Ursache beheben kann, statt eine Korrekturbuchung zu erstellen.
Können Aktionen und Preisänderungen im Voraus geplant werden?
Ja. Jede Preis- oder Aktionsänderung wird im Voraus mit Datum und den Filialen, für die sie gilt, gesendet, sodass die Kassen im richtigen Moment umschalten, ohne dass jemand in der Filiale eingreift. Die Schicht zeichnet auf, welche Filialen die Änderung bestätigt haben, und markiert alle anderen.
Wie rollen Sie das über viele Filialen aus?
Wir beginnen mit einem Pilot in wenigen Filialen und vergleichen ihre Summen täglich mit dem heutigen Verfahren. Stimmen die Summen überein, rollen wir in Gruppen aus, in einem Tempo, das Ihr Team für den Filialbetrieb tragen kann. Das alte Verfahren bleibt für jede Filiale verfügbar, bis ihr neuer Fluss bewiesen ist.
Mit welchen POS- und ERP-Systemen funktioniert das?
Das Design funktioniert mit jedem POS, das Transaktionen über eine API, Ereignisse oder Dateien exportieren kann, und mit ERPs wie SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central und Odoo. Wir bestätigen die Schnittstellen Ihres konkreten POS und ERP zu Beginn. Die Nennung eines Produkts bedeutet keine Partnerschaft mit seinem Anbieter.
Wer kümmert sich nach dem Go-live um fehlgeschlagene Buchungen?
Das wird vor dem Go-live vereinbart. Meist bearbeitet Ihr Team für den Filialbetrieb oder Finanzen fachliche Fehler wie einen unbekannten Artikel aus einer Prüfliste, und das technische Team bearbeitet Fehler im Fluss selbst. Wir können diesen technischen Support im Rahmen einer laufenden Vereinbarung übernehmen, mit einem Runbook, das Ihr Team erhält.
Beginnen Sie mit einem Gespräch, nicht mit einem Vertrag.
Sagen Sie uns, was Sie bauen, verbinden oder absichern möchten. Ein Architekt geht es mit Ihnen durch und empfiehlt dann, wo Sie beginnen sollten.
Wie es weitergeht
Terminabstimmung
Unser Team schreibt Ihnen, um einen Termin für das Gespräch zu vereinbaren.
Beratungsvorgespräch
Ein kostenlose 30-minütige Online-Vorberatung: Wir gehen Ihre Ziele, Systeme und Rahmenbedingungen durch.
Readiness-Review
In einer kostenlose 48-stündige Readiness-Review prüft ein Principal Architect Ihr Projekt gegen die 6-Punkte-Definition of Ready und empfiehlt den passenden Track.
Wahl des Tracks
Projekte mit klarem Leistungsumfang erhalten innerhalb von 3–5 Werktagen ein verbindliches Angebot. Projekte in der Konzeptphase starten im Blueprint Studio. Ein laufendes System, das ausfällt, nicht dokumentiert ist oder integriert werden muss, beginnt mit einer Diagnose von 1–2 Wochen. Blueprint Studio und Diagnose haben jeweils ein festes Honorar, das im Angebot genannt wird.