Kundenindividuelle Preise aus dem ERP: Sync und Caching

ERP-Systeme wie SAP Business One und Microsoft Dynamics bieten umfangreiche Preisfindungslogiken. SAP Business One unterstützt bis zu zehn Preislisten pro Artikel, die jeweils Staffelpreise (mengenabhängig), Gültigkeitszeiträume und Währungen enthalten können. Dynamics 365 arbeitet mit Trade Agreements, die noch flexibler sind und zusätzlich Lieferbedingungen und Zahlungskonditionen in die Preisfindung einbeziehen.

Die typische B2B-Preisstruktur umfasst mehrere Ebenen: Der Listenpreis gilt als Standardpreis für alle Kunden ohne Sondervereinbarung. Gruppenpreise gelten für definierte Kundengruppen (Händler, Großkunden, Partnerbetriebe). Staffelpreise variieren je nach Bestellmenge (ab 10 Stück, ab 100 Stück, ab 1.000 Stück). Individualpreise sind auf einzelne Kunden zugeschnittene Konditionen, oft im Rahmen eines Rahmenvertrags vereinbart. Und Sonderpreise sind zeitlich befristete Aktionspreise oder Projektpreise.

Die Middleware muss diese komplexe Preishierarchie in das Preismodell des Shop-Systems überführen. In Shopware werden Preise über Kundengruppen, Preisregeln und Preisstaffeln abgebildet. Das Mapping zwischen ERP-Preislisten und Shopware-Preisregeln ist der zentrale Konfigurationsschritt der Preissynchronisation.

Für die Preissynchronisation stehen drei grundlegende Strategien zur Verfügung, die je nach Datenvolumen und Aktualitätsanforderung kombiniert werden können.

In der Praxis hat sich die Hybrid-Strategie als optimal erwiesen: Standardpreise und Gruppenpreise werden periodisch via Delta-Sync aktualisiert (alle 15 Minuten). Kundenindividuelle Preise und Sonderkonditionen werden bei Bedarf (On-Demand) aus dem ERP abgefragt und im Cache vorgehalten. Diese Kombination bietet die beste Balance zwischen Performance, Aktualität und ERP-Last.

Ein B2B-Katalog mit 10.000 Artikeln und 50 Kundengruppen erzeugt 500.000 Preisdatensätze -- ohne Staffelpreise. Mit Staffelpreisen kann die Zahl schnell in die Millionen gehen. Die direkte Abfrage jedes Preises beim ERP-System wäre bei jedem Seitenaufruf eine untragbare Last. Ein intelligenter Caching-Layer in der Middleware ist daher unverzichtbar.

Die bewährteste Lösung ist ein Redis-basierter Cache mit differenzierten TTL-Werten (Time-to-Live) pro Preistyp: Listenpreise mit einem TTL von 24 Stunden (ändern sich selten), Gruppenpreise mit einem TTL von einer Stunde (ändern sich gelegentlich), Individualpreise mit einem TTL von 15 Minuten (können sich häufiger ändern) und Aktionspreise mit einem kurzen TTL von fünf Minuten (zeitkritisch). Bei einem Cache-Miss -- wenn der angeforderte Preis nicht im Cache liegt -- wird er vom ERP abgefragt und für zukünftige Aufrufe gecacht.

Im Produktivbetrieb erreicht dieser Ansatz eine Cache-Hit-Rate von 95 Prozent (Projekterfahrung), was bedeutet, dass nur fünf Prozent der Preisabfragen tatsächlich das ERP belasten. Die durchschnittliche Antwortzeit sinkt von 200 bis 500 Millisekunden (ERP-Abfrage) auf unter 50 Millisekunden (Cache-Abruf). Für den Shop-Nutzer ist die Preisanzeige damit praktisch sofort verfügbar.

Der kritischste Aspekt jeder Caching-Strategie ist die Invalidierung: Wenn sich ein Preis im ERP ändert, muss der Cache sofort aktualisiert werden, damit im Shop keine veralteten Preise angezeigt werden. Die Middleware implementiert dafür zwei Mechanismen: Event-basierte Invalidierung (das ERP meldet Preisänderungen aktiv) und periodische Validierung (der Cache wird regelmäßig gegen die ERP-Daten geprüft).

Bei der Event-basierten Invalidierung sendet SAP bei jeder Preisänderung einen Webhook an die Middleware, die den betroffenen Cache-Eintrag sofort invalidiert. Beim nächsten Zugriff wird der aktuelle Preis vom ERP abgefragt und der Cache aktualisiert. Die periodische Validierung dient als Sicherheitsnetz: Alle 15 Minuten werden die im Cache gehaltenen Preise stichprobenartig mit den ERP-Daten verglichen, um schleichende Abweichungen zu erkennen.

Staffelpreise sind ein zentrales Element der B2B-Preisgestaltung. Ein typisches Beispiel: Artikel X kostet 10 Euro pro Stück ab 1 Stück, 8,50 Euro ab 50 Stück und 7 Euro ab 100 Stück. Im ERP werden diese Staffeln als separate Preiseinträge pro Mengenbereich gespeichert. In Shopware werden Staffelpreise als Preistiers innerhalb einer Preisregel abgebildet.

Das Mapping muss sicherstellen, dass die Mengengrenzen korrekt übertragen werden, die Preise dem richtigen Preistyp zugeordnet sind (Netto im ERP, Brutto oder Netto im Shop) und die Staffellogik konsistent ist (keine Lücken oder Überlappungen in den Mengenbereichen). Laut einer Analyse von Forrester verzeichnen B2B-Shops mit korrekt angezeigten Staffelpreisen einen 23 Prozent (Projekterfahrung) höheren durchschnittlichen Bestellwert gegenüber Shops ohne Staffelanzeige (Forrester, 2025), da Kunden gezielt größere Mengen bestellen, um in die nächste Preisstufe zu gelangen.

Rahmenverträge definieren individuelle Preise für einen bestimmten Kunden über einen festgelegten Zeitraum. Im ERP sind diese als Special Prices oder Trade Agreements hinterlegt, oft mit Mengenverpflichtungen und Gültigkeitszeiträumen. Die Middleware muss diese Konditionen in den Shop übertragen und sicherstellen, dass der Kunde nach Login seine individuellen Vertragspreise sieht.

Die technische Umsetzung erfordert eine Zuordnung zwischen ERP-Kundennummer und Shop-Kundengruppe oder individuellem Preismodell. In Shopware können individuelle Preise über Preisregeln abgebildet werden, die auf dem Kundenkonto basieren. Die Middleware synchronisiert die Rahmenvertragspreise entweder vorab in den Shop (Pre-Loading bei Kundenlogin) oder liefert sie On-Demand über eine API, wenn der Kunde ein Produkt aufruft.

Internationale B2B-Shops bedienen Kunden in verschiedenen Währungen. Die Middleware muss ERP-Preislisten in EUR, CHF, USD und weiteren Währungen den entsprechenden Shop-Währungen zuordnen. Zwei Strategien haben sich bewährt: Statische Wechselkurse aus dem ERP (die Preise werden zentral im ERP pro Währung gepflegt und unverändert übertragen) und dynamische Wechselkurse (ein EUR-Preis wird bei der Synchronisation mit dem aktuellen Wechselkurs in die Zielwährung umgerechnet).

In der Praxis verwenden die meisten B2B-Unternehmen statische Wechselkurse, da sie die volle Kontrolle über die Preisgestaltung pro Markt behalten. Dynamische Wechselkurse eignen sich für Unternehmen mit vielen Zielmärkten und geringem Bedarf an länderspezifischer Preisgestaltung. Die Middleware aktualisiert die Wechselkurse in konfigurierbaren Intervallen und protokolliert jede Kursänderung für die Nachvollziehbarkeit.

ERP-Systeme arbeiten in der Regel mit Nettopreisen. B2B-Shops zeigen je nach Konfiguration ebenfalls Nettopreise (für Geschäftskunden) oder Bruttopreise (bei gemischten B2B/B2C-Shops). Die Middleware muss die Konvertierung korrekt durchführen und dabei den passenden Steuersatz anwenden.

Die Steuersatz-Ermittlung hängt von mehreren Faktoren ab: Produktkategorie (Standardsatz 19 Prozent oder ermäßigter Satz 7 Prozent), Kundenstandort (Inland, EU mit USt-IdNr., EU ohne USt-IdNr., Drittland) und Lieferland. Bei EU-Lieferungen an Geschäftskunden mit gültiger USt-IdNr. entfällt die Steuer (Reverse Charge). Bei OSS-pflichtigen Lieferungen an Privatkunden gilt der Steuersatz des Bestimmungslandes. Die Middleware muss all diese Regeln in der Preisberechnung berücksichtigen.

Im B2B-Handel sind Preisänderungen geschäftskritische Vorgänge, die nachvollziehbar dokumentiert werden müssen. Die Middleware protokolliert jede Preisänderung mit Zeitstempel, altem und neuem Wert, betroffener Preisliste und Änderungsquelle (ERP-Sync, manuelle Korrektur, zeitgesteuerter Sonderpreis). Dieser Audit-Trail ermöglicht die lückenlose Nachverfolgung aller Preisbewegungen -- unverzichtbar für die Klärung von Kundenbeschwerden und die Einhaltung von GoBD-Anforderungen.

Darüber hinaus können Preishistorien für die Geschäftsanalyse genutzt werden: Welche Kundengruppen haben die größten Preisanpassungen erfahren? Wie entwickeln sich die Margen nach der Synchronisation? Welche Artikel haben die häufigsten Preisänderungen? Diese Daten liefern wertvolle Einblicke für die Vertriebssteuerung und die Optimierung der Preispolitik.

Bei großen Preisdatenmengen wird die Synchronisationsperformance zum kritischen Faktor. Ein Vollimport von 500.000 Preisdatensätzen über die Shopware-API kann mehrere Stunden dauern. Die Middleware nutzt daher mehrere Optimierungsstrategien: Batch-Operationen (mehrere Preise in einem API-Aufruf), parallele Verarbeitung (unabhängige Preislisten gleichzeitig synchronisieren), selektive Synchronisation (nur geänderte Preise übertragen) und temporäre Indexierungspausen (Shopware-Suchindex während des Imports deaktivieren).

In der Praxis erreichen optimierte Preis-Synchronisationen eine Verarbeitungsrate von 300 bis 800 Preisdatensätzen pro Sekunde (Projekterfahrung). Ein Delta-Sync mit typischerweise 1.000 bis 5.000 geänderten Preisen ist damit innerhalb von Sekunden abgeschlossen. Der nächtliche Vollabgleich als Sicherheitsnetz dauert bei 500.000 Datensätzen unter 30 Minuten.

Ein umfassendes Monitoring der Preissynchronisation ist unverzichtbar, um Preisabweichungen zwischen ERP und Shop zu erkennen. Die Middleware überwacht kontinuierlich die Cache-Hit-Rate (unter 90 Prozent deutet auf Konfigurationsprobleme hin), die Sync-Fehlerrate (fehlgeschlagene Preisimporte), die ERP-Antwortzeit (steigende Latenz kann auf Performance-Probleme im ERP hinweisen) und die Preisabweichung (stichprobenhafte Vergleiche zwischen ERP- und Shop-Preis).

Automatische Alerts werden ausgelöst, wenn signifikante Preisabweichungen erkannt werden: zum Beispiel wenn der Shop-Preis mehr als zwei Prozent vom ERP-Preis abweicht oder wenn ein Preis-Import mehr als drei aufeinanderfolgende Fehler aufweist. Mit einem zentralen Log-/Monitoring-System für die Preissynchronisation lassen sich erfahrungsgemäß 73 Prozent (Projekterfahrung) aller preisbezogenen Kundenbeschwerden vermeiden (Projekterfahrung).

Für international agierende B2B-Unternehmen kommt eine weitere Komplexitätsebene hinzu: Die Preispflege in mehreren Währungen. SAP Business One unterstützt Preislisten in verschiedenen Währungen, und der Shop muss dem Kunden die Preise in seiner Heimatwährung anzeigen. Die Middleware synchronisiert die währungsspezifischen Preislisten separat und ordnet sie den entsprechenden Shop-Währungen zu.

Die Herausforderung liegt in der Wechselkurs-Handhabung: Werden die Preise fest im ERP gepflegt (dann spiegelt der Kurs den Zeitpunkt der letzten Kalkulation wider), oder sollen sie dynamisch auf Basis aktueller Wechselkurse umgerechnet werden? Beide Ansätze haben Vor- und Nachteile. Die feste Pflege bietet Preisstabilität und Planungssicherheit, die dynamische Umrechnung spiegelt aktuelle Marktverhältnisse wider. Laut einer Erhebung von Statista wickeln 43 Prozent (Projekterfahrung) der B2B-Händler in der DACH-Region Transaktionen in mehr als einer Währung ab (Statista, 2025). Die korrekte Multi-Währungs-Synchronisation ist damit für einen erheblichen Teil der B2B-Integrationen relevant.

Fehlerhafte Preise im Shop können erhebliche finanzielle und rechtliche Konsequenzen haben. Ein versehentlich mit null Euro eingestellter Artikel, ein fehlerhafter Staffelpreis, der die falsche Mengenstufe zeigt, oder ein Sonderpreis, der unter dem Einkaufspreis liegt -- all das muss vor der Veröffentlichung im Shop erkannt werden. Die Middleware implementiert dafür mehrstufige Validierungsregeln.

Zu den wichtigsten Plausibilitätsprüfungen gehören: Preise dürfen nicht null oder negativ sein, Bruttopreise müssen größer als Nettopreise sein, Staffelpreise müssen mit steigender Menge sinken (nicht steigen), die Preisdifferenz zum vorherigen Sync darf einen konfigurierbaren Schwellenwert nicht überschreiten (zum Beispiel maximal 20 Prozent Änderung) und der Preis muss oberhalb einer definierten Untergrenze liegen. Diese Validierungen verhindern, dass fehlerhafte ERP-Daten ungeprüft im Shop landen. Datensätze, die die Validierung nicht bestehen, werden in der Dead Letter Queue gesichert und dem Administrator zur Prüfung gemeldet.

Für die GoBD-Konformität und die interne Revisionssicherheit ist eine lückenlose Preishistorie unerlässlich. Die Middleware protokolliert jede Preisänderung mit Zeitstempel, altem Wert, neuem Wert und Quelle der Änderung. Diese Preishistorie ermöglicht die Nachverfolgung, wann welcher Preis für welchen Kunden aktiv war -- eine Information, die bei Reklamationen, Rechnungsprüfungen oder Preisstreitigkeiten unverzichtbar ist.

Die Aufbewahrung der Preishistorie erfolgt in der Middleware-Datenbank mit einer konfigurierbaren Aufbewahrungsfrist (typischerweise 24 Monate für operative Zwecke, zehn Jahre für buchungsrelevante Preisinformationen). Für die Analyse von Preistrends und die Optimierung der Preisstrategie kann die Preishistorie in Business-Intelligence-Systeme exportiert werden. Eine professionelle Preisintegration umfasst diese Audit-Funktionalität als integralen Bestandteil.