Metallzuschläge, Staffelpreise und Kundengruppen: Ein Preis ist kein einzelnes Feld.

Im einfachsten Shopmodell besitzt ein Produkt einen Preis. Er wird gespeichert, angezeigt und im Checkout verwendet.

Im B2B- und Industrie-Commerce entsteht der tatsächlich verbindliche Preis häufig erst aus mehreren Komponenten. Ein Kunde besitzt individuelle Konditionen, bestellt eine bestimmte Menge, der Rohstoffzuschlag gilt tagesabhängig, die Währung hängt vom Markt ab und die Verpackungseinheit beeinflusst die Berechnung.

Der sichtbare Preis ist damit kein einzelnes Produktattribut. Er ist das Ergebnis einer Pricing-Funktion mit Kontext, Regeln, Gültigkeit und Herkunft.

Welche Bestandteile einen Preis bilden können

Typische Komponenten:

• Listen- oder Grundpreis,
• kundenspezifischer Rabatt,
• Kundengruppen- oder Rahmenvertragskondition,
• Mengenstaffel,
• Aktions- oder Projektpreis,
• Metall-, Energie- oder Rohstoffzuschlag,
• Verpackungs- oder Mindermengenzuschlag,
• Markt und Währung,
• Gültigkeitszeitraum,
• Zahlungs- oder Lieferbedingung,
• Steuer,
• Rundungsregel,
• Maßeinheit oder Umrechnungsfaktor.

Ein Produkt kann dadurch nicht „den" Preis besitzen. Es besitzt Preisbestandteile und Regeln, aus denen für einen konkreten Fall ein Ergebnis berechnet wird.

Der Kontext entscheidet

Eine Preisabfrage benötigt möglicherweise:

Produkt oder Variante
+ Kunde und Organisation
+ Kundengruppe
+ Menge + Einheit
+ Lieferland + Währung
+ Zeitpunkt
+ Vertrags- oder Projektbezug
= verbindlicher Preis

Fehlt ein Kontextbestandteil, kann nur ein unverbindlicher Listenpreis oder eine Preisspanne angezeigt werden.

Das hat unmittelbare Auswirkungen auf:

• Produktlisting,
• Suchergebnisse,
• Produktdetailseite,
• Warenkorb,
• Angebotsfunktion,
• Checkout,
• Bestellbestätigung,
• ERP-Übergabe.

Wo wird der Preis berechnet?

Im ERP

Vorteile:

• zentrale Konditionslogik,
• konsistent mit Auftrag und Rechnung,
• bestehende Vertrags- und Kundenbeziehungen nutzbar.

Herausforderungen:

• Antwortzeit,
• Verfügbarkeit,
• große Zahl von Preisabfragen in Listings,
• teilweise schwer erklärbare Ergebnisse.

In Shopware

Vorteile:

• schnelle Darstellung,
• eng mit Commerce-Regeln verbunden,
• geringere Laufzeitabhängigkeit vom ERP.

Herausforderungen:

• doppelte Regelpflege,
• Gefahr abweichender Preise zwischen Shop und Auftrag,
• komplexe Synchronisation.

In einem Pricing Service

Vorteile:

• klar abgegrenzte Verantwortung,
• wiederverwendbar für Shop, Portal und Vertrieb,
• eigene Skalierung und Tests.

Herausforderungen:

• zusätzliche Komponente,
• Datenversorgung und Betrieb,
• eindeutige Integration in ERP und Shop notwendig.

Die richtige Entscheidung hängt von bestehender Systemlandschaft und Geschäftskritikalität ab. Entscheidend ist, dass es eine verbindliche Berechnungsinstanz gibt.

Preislisten reichen nicht immer

Eine Möglichkeit besteht darin, alle erwarteten Preise vorab zu berechnen und an Shopware zu übertragen. Bei wenigen Kundengruppen und stabilen Regeln kann das sinnvoll sein.

Bei vielen Kunden, Produkten, Mengenstaffeln und zeitabhängigen Zuschlägen wächst die Zahl der Kombinationen jedoch stark.

Beispiel:

50.000 Produkte × 2.000 Kunden × 4 Staffeln × 3 Währungen
= 1,2 Milliarden mögliche Preiszeilen

Nicht jede Kombination muss physisch gespeichert werden. Häufig ist ein hybrides Modell sinnvoll:

• allgemeine Preise und häufige Gruppen werden repliziert,
• individuelle Preise werden bei Bedarf berechnet,
• Ergebnisse werden für einen begrenzten Zeitraum gecacht,
• im Checkout erfolgt eine verbindliche Neuberechnung.

Metall- und Rohstoffzuschläge benötigen Zeitbezug

Ein dynamischer Zuschlag kann sich täglich oder in anderen Intervallen ändern. Zu klären ist:

• Welcher Referenzwert gilt?
• Zu welchem Zeitpunkt wird er fixiert?
• Gilt der Wert bei Warenkorbanlage, Bestellung, Auftragsannahme oder Lieferung?
• Wie lange bleibt ein Angebot verbindlich?
• Wird der Zuschlag separat ausgewiesen oder im Gesamtpreis verrechnet?
• Was passiert bei Storno oder Teilmengen?

Der Shop muss nicht nur den aktuellen Zuschlag kennen. Für jeden abgeschlossenen Vorgang muss nachvollziehbar sein, welcher Wert und welche Regel verwendet wurden.

Preis-Snapshots sichern Nachvollziehbarkeit

Wird eine Bestellung abgeschlossen, sollten die relevanten Preisbestandteile als Snapshot gespeichert werden.

Beispiel:

Grundpreis:                 100,00 EUR
Kundenrabatt:               -10,00 EUR
Mengenstaffel:               -2,00 EUR
Metallzuschlag:               4,25 EUR
Nettopreis:                  92,25 EUR
Steuer:                      17,53 EUR
Bruttopreis:                109,78 EUR
Preisquelle:           Pricing Service v3
Berechnungszeitpunkt:  2026-08-09 14:32

Dieser Snapshot schützt vor späteren Regel- oder Zuschlagsänderungen und hilft bei Support, Gutschrift, Audit und ERP-Abgleich.

Anzeige und Verbindlichkeit unterscheiden

Ein Preis im Listing kann aus Performancegründen gecacht oder vereinfacht sein. Im Warenkorb und spätestens vor Bestellung muss der verbindliche Preis feststehen.

Mögliche Stufen:

1. 1Orientierungspreis: öffentlich oder ohne vollständigen Kundenkontext.
2. 2Personalisierter Anzeigepreis: mit Kunden- und Mengeninformationen, eventuell gecacht.
3. 3Verbindlicher Warenkorbpreis: mit aktuellem Kontext berechnet.
4. 4Bestell-Snapshot: unveränderliches Ergebnis des Abschlusszeitpunkts.
5. 5ERP-Auftragspreis: muss mit der Commerce-Berechnung übereinstimmen oder kontrolliert abgeglichen werden.

Wenn sich zwischen Anzeige und Checkout ein Preis ändert, muss die Oberfläche transparent reagieren.

Fallbacks bei Ausfall

Ist der Pricing Service oder das ERP nicht erreichbar, existieren mehrere Optionen:

• Verkauf blockieren,
• letzten bestätigten Preis verwenden,
• nur Angebot statt Bestellung ermöglichen,
• Warenkorb speichern und später berechnen,
• bestimmte Kundengruppen oder Produkte ausnehmen.

Die richtige Entscheidung hängt vom wirtschaftlichen Risiko ab. Ein veralteter Preis kann bei geringen Schwankungen akzeptabel sein, bei Rohstoffzuschlägen oder sehr knappen Margen jedoch nicht.

Das zulässige Alter eines gecachten Preises sollte explizit definiert und überwacht werden.

Tests brauchen fachliche Kombinationen

Pricing kann nicht nur mit einem Standardkunden und einer Menge getestet werden.

Ein Testkatalog sollte enthalten:

• öffentlicher Listenpreis,
• verschiedene Kundengruppen,
• individueller Vertragspreis,
• Mengen knapp unter und über Staffelgrenzen,
• mehrere Einheiten,
• Währungswechsel,
• zeitabhängiger Zuschlag,
• Rabattkombinationen,
• ungültiger oder abgelaufener Preis,
• Ausfall der Preisquelle,
• Rundungsfälle,
• Storno und Teilgutschrift.

Für jeden Fall wird das erwartete Ergebnis als Golden Dataset festgelegt.