Einzelhandel und Omnichannel-Commerce
Filialen, Webshops und ERP stimmen bei jedem Verkauf und jeder SKU in Echtzeit überein.
Warum Filialen, Onlinekanäle und ERP auseinanderlaufen
Einzelhändler arbeiten mit vielen Systemen, die übereinstimmen müssen: Kassen, Webshops, Lager, Zahlungsdienstleister und ERP. Laufen sie auseinander, ist der Bestand falsch, Preise unterscheiden sich zwischen Kanälen, und die Finanzabteilung verbringt Tage mit Abstimmung.
Nächtliche Batch-Synchronisierung
Kassen, Webshops und ERP tauschen Daten mit Stunden Verzögerung aus, sodass der Bestand zu Spitzenzeiten überverkauft wird.
Langsame Abwicklung
Kartenabrechnungen über mehrere Acquirer werden spät abgestimmt, und Abweichungen kosten Geld.
Spitzen, die den Checkout brechen
Aktionen und Festivals sorgen für Andrang, den langsame Systeme nicht bewältigen.
Was sich ändert
Eine Version jedes Verkaufs
Filialterminals, Online-Checkout und ERP-Hauptbuch stimmen in Echtzeit überein.
Bestand, dem Sie trauen können
SKU-Bestände zwischen Filialen und Webshops synchronisiert, sobald sie sich ändern.
Abrechnungen abgestimmt
Abrechnungsdateien werden eingelesen, und Gebühren werden automatisch geprüft.
Wo wir arbeiten
Was wir bauen
- POS-Erweiterungen, Backoffice-Apps und Filial-Dashboards
- Offline-sichere Synchronisierung zwischen Filialservern und Zentrale
Was wir bauen
- E-Commerce-Frontends und Auftragsdienste
- Click & Collect, Retouren und Sendungsverfolgung
Typische Integrationen
- E-Commerce-Plattformen, Marktplätze, Frachtführer und das ERP
Was wir bauen, verbinden und absichern
POS- und ERP-Integration
Verkäufe, Retouren und Tagesabschlüsse ins ERP gebucht, mit Preisen, Aktionen und Artikeln, die an jede Filiale zurückgehen.
Bestandstransparenz
Eine Sicht auf den Bestand über Filialen, Lager und Online, aktualisiert, sobald Verkäufe und Lieferungen stattfinden.
Online- und Mobile-Commerce
Webshops und Apps, die Produkte, Preise und Bestand mit den Filialen teilen.
Loyalty und Aktionen
Loyalty-Programme, Gutscheine und Aktionsregeln, die in jedem Kanal gleich funktionieren.
Werkzeuge für den Filialbetrieb
Apps für Bestandsaufnahmen, Umlagerungen, Lieferungen und Mitarbeiteraufgaben, gebaut für die Verkaufsfläche.
Super-Apps und Unified Commerce
Eine hochlastfähige App für Einkauf, Zahlungen und Loyalty über Marken hinweg.
POS-Plattformen
Kassen und POS-Cloud-Dienste, über ihre APIs, Exportdateien oder Filialserver.
Kartenzahlungen
Terminals, Gateways und Acquirer, mit Abrechnungsdateien, die den Verkäufen zugeordnet werden.
ERP
SAP S/4HANA, Microsoft Dynamics 365, Oracle NetSuite, Odoo und andere, für Artikel, Bestand und Finanzen.
Lager und Frachtführer
Lagersysteme und Frachtführer-APIs für Kommissionierung, Lieferungen und Retouren.
Kartendaten außerhalb des Geltungsbereichs
Wir halten Kartendaten beim Zahlungsdienstleister, über Tokenisierung und punkt-zu-punkt-verschlüsselte Terminals, wo verfügbar, was den PCI-DSS-Umfang klein hält.
Kundendaten
Loyalty- und Auftragsdaten werden mit Einwilligung erhoben, nur so lange wie nötig aufbewahrt und nach DSGVO und den geltenden lokalen Gesetzen behandelt.
Fiskal- und Steuerregeln
Wo ein Land fiskalische Belege oder E-Invoicing verlangt, binden wir die vorgeschriebenen zertifizierten Geräte oder Plattformen an und bewahren die geforderten Aufzeichnungen auf.
So arbeiten wir
Wir verbinden diese Systeme, damit Verkäufe, Bestand, Preise und Zahlungen zuverlässig zwischen ihnen fließen, und bauen die Kunden-Apps und Backoffice-Werkzeuge darum herum. Filialen verkaufen weiter, wenn das Netz ausfällt, und holen auf, wenn es zurückkehrt.
Abläufe erfassen
Verkäufe, Retouren, Preise, Bestand und Zahlungen zwischen allen Systemen.
Batches ersetzen
Ereignisse streamen zwischen POS, Webshops und ERP, mit einer Dead-Letter-Queue für Fehler.
Unter Spitzenlast beweisen
Lasttests mit Andrang wie bei Festivals vor der Inbetriebnahme.
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).
Seitwärts scrollen, um die ganze Zeichnung zu sehen.
Kartenzahlungen: an der Kasse autorisiert, später abgewickelt, im ERP abgestimmt
Das Terminal oder der Checkout fragt das Gateway, das Gateway fragt den Acquirer, und der Acquirer leitet an Kartennetzwerk und Kartenausgeber weiter. Abwicklungsdateien kommen später und werden im ERP Umsätzen und Gebühren zugeordnet. Eine Zeitüberschreitung löst ein Storno aus, damit der Kunde nie doppelt belastet wird.
- Primärer Ablauf
- Asynchron
- Fehlerpfad
Der Ablauf in 8 Schritten
Der Ablauf Schritt für Schritt
- Von EMV-Terminal oder Online-Checkout nach Zahlungsgateway: Autorisierungsanfrage, über EMV · REST/JSON (primärer Ablauf).
- Von Zahlungsgateway nach Acquirer: Autorisierung, über ISO 8583 (primärer Ablauf).
- Von Acquirer nach Kartennetzwerk und Kartenausgeber: An den Kartenausgeber weitergeleitet, über ISO 8583 (primärer Ablauf).
- Von Acquirer nach Zahlungsgateway: Genehmigt oder abgelehnt, über ISO 8583 (asynchron).
- Von Acquirer nach Integrationsschicht: Abwicklungs- und Gebührendateien, über SFTP (asynchron).
- Von Integrationsschicht nach ERP: Abgewickelte Umsätze, Gebühren und Auszahlungen, über REST/JSON (primärer Ablauf).
- Von Zahlungsgateway nach EMV-Terminal oder Online-Checkout: Keine rechtzeitige Antwort: automatisches Storno, über ISO 8583 0400 (Fehlerpfad).
- Von Integrationsschicht nach Zahlungsbetriebsteam: Abweichung in der Abwicklung oder Chargeback (Fehlerpfad).
Erfolgsbilanz
Ausgewählte Unternehmensmarken stehen für historische und laufende Systeme, Plattformen und digitale Produkte, die XSIS, KONG GROUP, unser CEO und unsere leitenden Ingenieure im Laufe ihrer Karrieren entworfen oder geliefert haben. Alle Marken Dritter sind Eigentum ihrer jeweiligen Inhaber und werden ausschließlich zur sachlichen Identifikation des Portfolios genannt.
So beginnen
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.
KI-native Produktteams
Geführte, funktionsübergreifende Pods aus Senior-Ingenieuren, ausgestattet mit agentischen Coding- und QA-Harnesses.
Projekte mit festem Ergebnis und Managed Services rund um die Uhr
Lieferung mit festem Umfang und Meilensteinen unter benannten Delivery-Leads sowie Application Managed Services rund um die Uhr unter SLA-Governance.
Der schnellste Einstieg ist das Paket Sprint für E-Invoicing-Vorgaben und ERP-Bereitschaft, eines unserer schnellen Zusammenarbeitspakete.
Wo Sie startenFragen und Antworten
Was geschieht, wenn eine Filiale die Verbindung verliert?
Die Filiale verkauft weiter. Verkäufe werden lokal gespeichert und gesendet, wenn die Verbindung zurückkehrt, jeweils mit einer eindeutigen Kennung, damit nichts doppelt gebucht wird. Preis- und Bestandsaktualisierungen warten auf dieselbe Weise. Der Betrieb sieht, welche Filialen zurückliegen und um wie viel, sodass ein längerer Ausfall sofort auffällt und nicht erst zum Monatsende entdeckt wird.
Welche POS-Systeme können Sie integrieren?
Wir integrieren POS-Plattformen über das, was sie bieten: Cloud-APIs, Filialserver, Datenbankexporte oder Dateien. Bevor wir schätzen, prüfen wir die POS-Dokumentation und eine Stichprobe ihrer Daten, denn das entscheidet über den Ansatz. Die Nennung einer POS-Plattform oder eines ERPs auf dieser Seite bedeutet keine Partnerschaft mit seinem Anbieter.
Warum stimmt der Bestand zwischen ERP und Filialen nie überein?
Meistens, weil die Systeme sich bei Timing, Einheiten oder der Frage unterscheiden, was als Bewegung gilt. Retouren, Umlagerungen, beschädigte Ware und Verkäufe während einer Bestandsaufnahme sind häufige Ursachen. Wir verfolgen die Unterschiede, vereinbaren eine Regel je Bewegungsart und bauen die Synchronisierung so, dass sie jede Änderung mit ihrer Quelle erfasst. Verbleibende Abweichungen landen auf einer Prüfliste, statt sich anzustauen.
Was bestimmt die Kosten einer Einzelhandelsintegration?
Die Zahl der Systeme, Filialen und Kanäle, wie gut POS und ERP ihre Daten bereitstellen und wie viele Sonderfälle Regeln brauchen, etwa kanalübergreifende Retouren oder Teilzahlungen. Die Einführung Filiale für Filiale erhöht den Testaufwand ebenfalls. Wir schätzen, nachdem wir die Systeme und eine Stichprobe echter Transaktionen geprüft haben.
Können Sie einführen, ohne Filialen zu schließen?
Ja. Wir gehen in Stufen live, beginnend mit einer Pilotfiliale, und betreiben die neue Integration neben dem laufenden Prozess, bis die Summen übereinstimmen. Änderungen in den Filialen werden nach Möglichkeit außerhalb der Öffnungszeiten geplant, und jede Stufe hat einen Rückweg, falls etwas nicht wie geplant funktioniert.
Wer betreut die Integration nach der Inbetriebnahme?
Wir können sie im Rahmen einer Supportvereinbarung überwachen und betreuen oder mit Dokumentation, Warnungen und einem Runbook an Ihr Team übergeben. In beiden Fällen landet eine fehlgeschlagene Nachricht mit ihrem Grund in einer Warteschlange, sodass sie behoben und erneut eingespielt statt verloren geht.
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.