Preise im B2C zwischen Shopify und ERP synchronisieren

Im Überblicksartikel zu Preisen habe ich beschrieben, warum Preise ein Sonderfall sind: Das ERP kalkuliert, Shopify moduliert. Der B2B-Artikel beschreibt den Fall, in dem möglichst wenig moduliert werden soll. Im B2C ist die Modulation dagegen Alltagsgeschäft und findet täglich statt.

Preise sind hier deshalb besonders, weil sie sich ständig bewegen. Ein Artikel kostet nicht einen Preis, sondern diese Woche einen anderen als letzte, im Bundle einen anderen als einzeln, mit Newsletter-Code einen anderen als ohne, und im A/B-Test zwei gleichzeitig. Alles davon ist gewollt. Die Architektur muss diese Bewegung also zulassen und gleichzeitig sicherstellen, dass die Marge dabei kalkulierbar bleibt.

Wie im B2B-Artikel lege ich die Rahmenbedingungen fest, weil sich Preisarchitektur ohne sie nicht bewerten lässt:

Der letzte Punkt bringt dabei eine enorme Verbesserung im Alltag, weil eindeutige Regeln das Vertrauen über die verschiedenen operativen Bereiche hinweg steigern. Das Shop-Team muss eine Aktion nicht absichern lassen, und Einkauf und Controlling müssen sie nicht nachrechnen.

Der Unterschied zum B2B liegt außerdem darin, dass Kataloge hier nicht ausreichen. Ein Katalog bildet einen festen Preis für eine feste Kundengruppe ab. Er bildet nicht ab, dass ein Artikel drei Tage lang 20 Prozent günstiger ist, im Set mit zwei anderen noch einmal weniger kostet und der Newsletter-Code darauf nicht anwendbar sein soll. Solche Preise ergeben sich erst aus dem Warenkorb und lassen sich dem Artikel nicht vorher zuordnen.

Der Anforderungskatalog dreht sich gegenüber dem B2B-Fall um. Dort musste der Shop die ERP-Preisfindung nachbilden. Hier muss das ERP mit Preisen umgehen können, die es nicht selbst berechnet hat.

Das ERP muss den Shop-Preisen dabei vertrauen, weil es die Preislogik des Shops nicht vollständig abbilden kann und auch nicht sollte. Wer versucht, jede Kampagnenmechanik im ERP nachzubauen, hat am Ende zwei Systeme mit derselben Aufgabe, die sich in Details unterscheiden. Damit wären die Verantwortlichkeiten wieder vermischt.

Das ERP übernimmt den Shop-Preis also, rechnet ihn aber trotzdem nach. Das Ergebnis der eigenen Kalkulation entscheidet nicht über den Beleg, sondern dient als Vergleichswert, an dem sich Fehler erkennen lassen.

Im B2B ergeben sich die Grenzen aus dem Konditionsmodell. Wer einen Kundenpreis vereinbart hat, hat damit auch festgelegt, was gilt. Im B2C existiert diese Grenze nicht von selbst. Sie muss definiert werden, und zwar bevor das Shop-Team anfängt, sie zu nutzen.

Ohne Leitplanken passiert in der Praxis eines von zwei Dingen. Entweder das Shop-Team fragt bei jeder Aktion nach, dann ist es nicht handlungsfähig und der Vorteil der Aufteilung ist weg. Oder es fragt nicht nach, dann verkauft irgendwann eine Kampagne einen Artikel unter Einstandspreis, und niemand merkt es bis zum Monatsabschluss.

Eine Leitplanke ist eine Zahl je Artikel, die aus dem ERP kommt und im Shop verfügbar ist. Typischerweise:

Je Artikel, nicht je Warengruppe. Warengruppen bedeuten weniger Pflegeaufwand, mitteln aber über unterschiedlich kalkulierte Artikel hinweg. Eine Gruppenregel, die 30 Prozent Rabatt erlaubt, schützt den Artikel mit 8 Prozent Marge nicht.

Die Berechnungsgrundlage sind idealerweise echte Kosten aus dem ERP und keine geschätzte Aufschlagslogik. Wie sauber die Kostenrechnung dahinter ist, wie Wareneinstand, Fracht, Zölle und Retourenquote einfließen, ist eine Finance-Frage und nicht Gegenstand dieses Artikels. Für die Architektur reicht, dass die Zahl aus dem System kommt, in dem die Kosten liegen, und sich mit dem Einkaufspreis ändert.

Technisch durchsetzbar wäre die Grenze im Shopify Admin, etwa über eine Validierung, die eine Aktion gar nicht erst anlegen lässt. Das ist allerdings viel Entwicklungsarbeit für einen fragwürdigen Nutzen, weil Rabatte an mehreren Stellen entstehen: über automatische Rabatte, über Codes, über Apps. Jede dieser Stellen müsste einzeln abgedeckt werden.

Der pragmatische Weg besteht aus zwei Ebenen. Organisatorisch: Die Leitplanke ist im Shop sichtbar, zum Beispiel als Metafeld am Artikel, und das Shop-Team kennt die Regel. Das setzt voraus, dass die Zahl beim Anlegen der Aktion direkt am Artikel steht und nicht in einer Tabelle liegt, die jemand zweimal im Jahr aktualisiert.

Und im Reporting: Jede Bestellung wird gegen die Leitplanke geprüft, und Unterschreitungen erscheinen in einer Auswertung. Einzelne Fälle verhindert das nicht, aber es findet die dauerhafte Abweichung. Eine Kampagne, die drei Wochen läuft und dabei die Marge unterschreitet, kostet deutlich mehr als eine einzelne falsch rabattierte Bestellung.

Der Ort für diese Prüfung ist das ERP, nicht der Shop. Dort liegen die Kosten, und dort laufen die anderen Kanäle zusammen. Eine Auswertung, die nur den Shop-Kanal kennt, beantwortet die Frage nach der Profitabilität eines Artikels nicht.

In der Praxis fehlen sie häufig, weil sie zwischen den Zuständigkeiten liegen. Das ERP-Team hält sie für eine Marketingfrage, das Marketingteam für eine Controllingfrage, und das Controlling erfährt vom Thema, wenn der Deckungsbeitrag im Quartalsbericht nicht stimmt. Die Zuordnung gehört deshalb explizit geklärt, bevor die Schnittstelle gebaut wird, weil sich sonst später niemand für die Pflege der Zahlen zuständig fühlt.

Sobald der Shop eigenständig rechnet, ist die Abweichung zwischen angezeigtem und kalkuliertem Preis kein Fehler mehr, sondern der Normalfall. Jede Kampagne erzeugt sie. Das ERP braucht dafür deshalb einen definierten Regelfall und keine Fehlerbehandlung.

Bewährt hat sich ein dreistufiges Vorgehen. Innerhalb der Toleranz wird übernommen: Weicht der Shop-Preis in einem definierten Rahmen vom erwarteten ab, übernimmt das ERP den Shop-Preis. Er wurde dem Kunden zugesagt, und eine nachträgliche Korrektur um wenige Cent kostet mehr an Prozess, als sie einbringt.

Protokolliert wird immer. Jede Abweichung wird mitgeschrieben, auch die akzeptierte. Ein Protokoll über akzeptierte Abweichungen ist die einzige Datenquelle, mit der sich ein defekter Sync von einer laufenden Kampagne unterscheiden lässt. Ohne dieses Protokoll sehen beide Fälle identisch aus, nämlich als Auftrag mit einem zu niedrigen Preis.

Über der Grenze wird blockiert. Überschreitet die Abweichung die definierte Schwelle, entsteht eine blockierende Warnung. Der Auftrag läuft nicht automatisch weiter, sondern wartet auf eine Person, die ihn prüft und freigibt. Der zusätzliche Handgriff fängt den Fall ab, in dem ein Konfigurationsfehler tausend Artikel um 90 Prozent rabattiert.

Zwei Kriterien lohnen sich getrennt zu betrachten. Die Abweichung zum erwarteten Preis findet Sync- und Konfigurationsfehler. Die Unterschreitung der Mindestmarge findet zu aggressive Kampagnen. Beides kann unabhängig voneinander auftreten, und beides braucht eine eigene Schwelle.

Die Schwelle gehört außerdem auf den Auftrag und nicht auf die Position. Ein einzelner Artikel im Bundle kann deutlich unter Basispreis liegen, während der Auftrag insgesamt sauber kalkuliert ist. Wer positionsweise blockiert, blockiert jedes Bundle.

Jede Bestellung aus Shopify wird im ERP gegen Basispreis und Leitplanke nachgerechnet. Aus dem Ergebnis dieser Nachrechnung folgt, was mit dem Auftrag passiert. Protokolliert wird in allen Fällen, und das Protokoll speist das Reporting je Artikel über alle Kanäle hinweg.

Shopify bietet mehrere Wege, den Basispreis zu modulieren. Für die Anbindung ans ERP ist dabei weniger interessant, was die einzelne Mechanik im Frontend kann, sondern auf welcher Ebene sie wirkt. Davon hängt ab, ob sie mit dem Preis-Sync kollidiert.

Wer für eine Aktion den Preis direkt am Artikel überschreibt, greift in genau das Feld ein, das die Schnittstelle bespielt. Der nächste Sync setzt den Aktionspreis dann zurück. Baut man die Schnittstelle so, dass sie das Feld in Ruhe lässt, kommt umgekehrt eine echte Preisänderung aus dem ERP nicht mehr an.

Lösen lässt sich das nicht technisch, sondern nur durch eine Vereinbarung: Das Preisfeld gehört dem ERP. Aktionen finden auf Ebene 2 statt.

Eine Ausnahme ist der Strichpreis. Er gehört zum Preis und kommt deshalb ebenfalls aus dem ERP. Ändert sich dort der Listenpreis, muss der Vergleichspreis mitwandern, sonst steht im Shop dauerhaft ein Rabatt, den es nicht mehr gibt. Das ist derselbe Punkt wie im B2B-Fall, nur ohne Kataloge.

Alle übrigen Mechaniken lassen den Artikelpreis stehen und wirken erst bei der Berechnung des Warenkorbs. Für die Schnittstelle ist das die entscheidende Eigenschaft: Der Sync und die Aktion fassen unterschiedliche Felder an und können sich deshalb nicht gegenseitig überschreiben.

Automatische Rabatte decken den größten Teil des Tagesgeschäfts ab. Sie greifen ohne Zutun des Kunden und eignen sich für zeitlich begrenzte Kampagnen, Mengenrabatte und Buy-X-Get-Y-Mechaniken. Sie sind an Zeiträume, Sammlungen und Mindestwerte gebunden und lassen sich vollständig im Admin pflegen, also ohne Entwicklung.

Mengenrabatte brauchen dabei eine eigene Klärung. Sie existieren im B2B als Staffel im Katalog und im B2C als Rabattregel, und beide Systeme können sie führen. Wenn das ERP eigene Staffeln kennt, etwa für den POS oder für Großabnehmer, muss festgelegt sein, welche gilt und was bei Abweichung passiert. Das ist einer der Fälle, in denen die Abweichungsprüfung regelmäßig anschlägt.

Discount Codes decken Newsletter, Kooperationen und Rückgewinnung ab. Für die Anbindung sind sie in der Regel unkritisch, weil sie kanalspezifisch sind und im ERP nur als Betrag ankommen. Aufwendiger wird es in Kombination: Ein Code auf einen bereits rabattierten Artikel ist der häufigste Weg, versehentlich unter die Mindestmarge zu rutschen. Ob sich Rabatte kombinieren lassen, wird je Kampagne entschieden und ist in Shopify auch je Rabatt konfigurierbar. Die Leitplanke setzt deshalb nicht an der Kombination an, sondern an ihrem Ergebnis: Der Mindestpreis gilt für den Betrag, der am Ende im Warenkorb steht, unabhängig davon, aus wie vielen Rabatten er entstanden ist.

Discount Functions kommen zum Einsatz, wenn die Standardmechaniken nicht reichen. Damit lässt sich eigene Rabattlogik im Checkout ausführen. Das wäre zugleich die Stelle, an der sich eine Mindestpreis-Leitplanke tatsächlich technisch durchsetzen ließe. Dafür fallen Entwicklung und Betrieb an, weshalb sich der Weg erst bei wirklich unternehmensspezifischen Mechaniken rechnet.

Apps und Bundles decken ab, was Shopify nativ nicht kennt, insbesondere Sets, Upsell und Abo-Mechaniken. Hier gilt derselbe Hinweis wie im B2B-Artikel: Entscheidend ist nicht der Funktionsumfang im Frontend, sondern wo die App ihre Daten ablegt und ob das ERP sie lesen kann. Wie Bundles im ERP bestandsseitig aufgelöst werden, ob als eigener Artikel mit Stückliste oder als Einzelpositionen, ist ein Thema für sich und bekommt einen eigenen Eintrag.

Der Zuschnitt ist schmaler als im B2B, dafür läuft mehr Verantwortung in die Rückrichtung.

Vom ERP an Shopify gehen Basispreis, Strichpreis und die Leitplanken je Artikel. Mehr nicht. Kampagnenpreise, Rabatte und Bundle-Preise gehören ausdrücklich nicht dazu, weil sie im Shop entstehen. Preisänderungen brauchen dabei einen Auslöser und keinen nächtlichen Komplettlauf über das Sortiment; ein vollständiger Abgleich ist als Absicherung sinnvoll, im Regelbetrieb aber zu langsam und zu teuer.

Von Shopify ans ERP geht die Bestellung mit den tatsächlich berechneten Preisen. Wie der Rabatt dabei strukturell ankommt, ob auf die Positionen verteilt oder als eigene Belegzeile, hängt vom ERP ab. Die Struktur sollte bewusst gewählt werden, weil sie darüber entscheidet, ob sich die Marge später je Artikel auswerten lässt.

Im ERP findet die Prüfung statt: Abgleich gegen die eigene Kalkulation, Protokollierung jeder Abweichung, blockierende Warnung oberhalb der Schwelle. Dieser Teil wird bei knappen Projektbudgets oft gestrichen, weil er im Tagesgeschäft zunächst nichts sichtbar verbessert.

Zu beachten ist außerdem, dass der Shop nicht der einzige Kanal ist. POS-Verkäufe, Marktplätze und internationale Verkäufe laufen ebenfalls im ERP zusammen. Der Basispreis gilt für alle diese Kanäle, die Shop-Aktion dagegen nur für den Shop. Wer die Leitplanken-Auswertung nur auf Shopify-Bestellungen baut, misst die Marge einer Kampagne statt der Marge eines Artikels. Die Auswertung gehört deshalb dorthin, wo alle Kanäle ankommen.

Damit sind beide Deep Dives für einen Markt beschrieben. Sobald mehrere Länder, Währungen und Steuerlogiken hinzukommen, verschiebt sich das Bild erneut, besonders im B2C, wo Rundungslogik und Preisdarstellung je Markt eigene Regeln brauchen. Auch Bundles und Variantenlogiken, im Shop schnell angelegt und im ERP bestandsseitig aufwendig, bekommen einen eigenen Eintrag. Preis-A/B-Tests ebenfalls, weil dort zwei Preise gleichzeitig gültig sind und die Abweichungsprüfung damit umgehen können muss.