Preise im B2B zwischen Shopify und ERP synchronisieren

Im Überblicksartikel zu Preisen habe ich beschrieben, warum Preise ein Sonderfall sind und wie sich die Verantwortung grundsätzlich aufteilen lässt: Das ERP kalkuliert, Shopify moduliert. Wie viel moduliert werden darf, hängt vom Geschäftsmodell ab. Dieser Artikel beschreibt den Fall, in dem die Antwort „möglichst wenig“ lautet, dafür aber die Preisfindung selbst am kompliziertesten ist: B2B.

Preisarchitektur lässt sich nicht allgemeingültig bewerten, deswegen lege ich die Rahmenbedingungen fest. Für den B2B-Case treffe ich folgende Annahmen:

Sobald das Marketingteam kurzfristig eigene Preise setzen soll, kippt die Architektur in Richtung geteilter Verantwortlichkeit, mit allen Konflikten, die ich im vorherigen Artikel beschrieben habe. Fällt eine dieser Annahmen weg, ändert sich der Lösungsweg.

Discount Codes bleiben damit außen vor. Sie sind kein Preis, sondern eine Abweichung vom Preis, und gehören deshalb in den B2C-Fall.

Der Anforderungskatalog bleibt überschaubar:

„Darstellen und berechnen“ ist dabei bewusst doppelt formuliert. Es reicht nicht, dem Kunden im Frontend einen Staffelpreis anzuzeigen. Der Checkout muss ihn auch anwenden. Genau hier scheitern viele Lösungen, weil die Anzeige über Metafelder gelöst wird und die Berechnung dann nicht mehr greift.

Dass angezeigter und abgerechneter Preis auseinanderlaufen können, habe ich im Überblicksartikel beschrieben. Im B2B verschärft sich das, weil der Kunde seine Konditionen kennt. Eine Abweichung von wenigen Cent fällt hier auf, während sie im B2C niemandem auffiele.

Der Shop muss die ERP-Preisfindung deshalb nicht ungefähr, sondern exakt nachbilden, inklusive Rundung und Staffelgrenzen. Das setzt allerdings voraus, dass es überhaupt etwas Eindeutiges nachzubilden gibt. Wo Konditionen im ERP nur historisch gewachsen und nicht als Regel formuliert sind, kann auch keine Schnittstelle sie zuverlässig übertragen. Die Vorarbeit liegt dann im ERP, nicht im Shop.

Bleibt die Preisfindung zu komplex, um sie im Shop nachzubilden, führt der Weg über eine Live-Abfrage beim ERP. Das hat zwei Konsequenzen: Jede Produktseite hängt an der Verfügbarkeit und Antwortzeit des ERPs, und Caching ist nur begrenzt möglich, weil der Preis kundenabhängig ist. Vermeidbar ist es nicht immer.

Unabhängig vom gewählten Weg sollte der übertragene Auftrag im ERP gegen die eigene Preisfindung geprüft und jede Abweichung protokolliert werden. Wer kommentarlos überschreibt, erfährt vom defekten Sync durch die Reklamation des Kunden. Wer protokolliert, findet ihn in der Regel am selben Tag.

Mit Shopify Plus ist das mittlerweile nativ möglich. Aber auch auf den anderen Plänen gibt es Lösungswege.

Die B2B-Funktionen von Shopify Plus decken den oben genannten Anforderungskatalog nativ ab. Kataloge werden Firmenstandorten zugeordnet, enthalten Preislisten mit festen oder prozentual angepassten Preisen und unterstützen Mengenregeln sowie Staffelpreise. Der Katalogpreis greift dabei in beiden Ebenen, im Storefront und im Checkout, ohne dass er im Theme nachgerechnet werden muss. Damit ist die Anforderung „darstellen und berechnen“ erfüllt, ohne dass eigene Preislogik entwickelt werden muss.

Zu beachten ist die eigene Aktualisierung. Eine Preisänderung im ERP betrifft nicht ein Feld, sondern jeden Katalog, in dem der Artikel enthalten ist. Wer nur den Basispreis aktualisiert, hinterlässt in den Katalogen die alten Werte, und genau die sieht der Kunde. Bei prozentualen Anpassungen greift die Änderung automatisch, bei festen Preisen nicht. Die Schnittstelle muss also wissen, welcher Artikel in welchem Katalog mit welcher Art von Preis liegt.

Dasselbe gilt für die Zuordnung. Neue Artikel landen nicht automatisch in allen Katalogen und neue Kunden nicht automatisch im richtigen. Die Katalogpflege gehört deshalb genauso in die Schnittstelle wie der Preis selbst, inklusive der Frage, was beim Anlegen eines neuen Kunden oder einer neuen Preisliste im ERP passieren soll.

Das gilt auch für die Strichpreise. Der Vergleichspreis ist Teil der Preisliste, lässt sich lesen, bearbeiten und darstellen und braucht deshalb keine Sonderlösung im Theme. Für die Schnittstelle heißt das aber, dass er wie der Preis behandelt werden muss: Ändert sich im ERP der Listenpreis, gehört die Aktualisierung in jeden betroffenen Katalog, sonst steht im Shop ein Rabatt, den es nicht mehr gibt.

Kataloge existieren auch ohne Plus, allerdings in begrenzter Anzahl und über Kundengruppen statt Firmenstandorte. Für Unternehmen mit wenigen, klar abgegrenzten Konditionsstufen reicht das aus. Der Weg kommt dann ohne zusätzliche Plattform, zusätzliche Lizenz und zusätzliche Ausfallstelle aus.

Die Grenze liegt in der Zahl der Konditionen. Sobald das ERP mehr Preislisten führt, als sich in Shopify abbilden lassen, beginnt das Mapping: Kunden werden auf die nächstpassende Gruppe gerundet. Das funktioniert eine Weile und wird in dem Moment zum Problem, in dem der erste Kunde seine Rechnung mit dem Shop vergleicht. Diese Rundung sollte deshalb eine bewusste Entscheidung sein und keine stille Notlösung der Schnittstelle.

Apps sind der naheliegende Weg, unterscheiden sich für die ERP-Anbindung aber grundlegend. Entscheidend ist nicht der Funktionsumfang im Frontend, sondern die Frage, wo die App ihre Preise ablegt.

Metafeld-basierte Apps schreiben Preise, Staffeln und Kundenzuordnungen in Metafelder. Das ist nicht bei allen Apps der Fall, aber wenn es zutrifft, wird die Anbindung einfach: Das ERP beschreibt die Metafelder über die Shopify API und muss die App selbst gar nicht kennen. Legt die App ihre Daten dagegen in einer eigenen Datenbank ohne Zugriff von außen ab, wird es schwierig. Dann bleibt nur manuelle Pflege oder ein Wechsel der App.

Die zweite Variante sind externe Portale, die den B2B-Teil komplett übernehmen. Hier ist eine eigene API nötig. Ist sie vorhanden und dokumentiert, lässt sich die Anbindung bauen, wobei das ERP dann gegen zwei Systeme spricht statt gegen eines. Ohne API ist der Weg kaum machbar. Diese Frage gehört deshalb vor die Auswahl der App und nicht in die Implementierungsphase.

Bleibt die individuelle Entwicklung. Hier wird eine eigene API definiert, darauf eine Schnittstelle gebaut und darüber das ERP angebunden. Der Vorteil liegt auf der Hand: Das Konditionsmodell des ERPs muss nicht in ein fremdes Schema gepresst werden, sondern gibt die Struktur vor.

Der Preis dafür ist ebenso eindeutig. Preislogik, Warenkorbberechnung und Betrieb liegen dann in eigener Verantwortung, inklusive Updates, wenn Shopify seine APIs weiterentwickelt. In der Praxis lohnt sich das dort, wo die Konditionen so unternehmensspezifisch sind, dass kein Standardprodukt sie abbildet. Bei allem anderen ist Plus der sauberere Weg, sofern die Lizenzkosten im Verhältnis zum Entwicklungs- und Betriebsaufwand vertretbar sind. Diese Rechnung geht nicht bei jedem Umsatz auf.

Unabhängig vom gewählten Weg bleibt der Zuschnitt der Schnittstelle gleich. Das ERP liefert aufgelöste Preise und keine Regeln, weil die Auflösung dort passieren sollte, wo das Regelwerk zu Hause ist. Übertragen werden Preis, Gültigkeit, Kunden- beziehungsweise Katalogzuordnung und Staffelgrenzen.

Zwei Punkte sind dabei entscheidend. Preisänderungen brauchen einen Auslöser und keinen Nachtlauf über das gesamte Sortiment. Ein vollständiger Abgleich ist als Absicherung sinnvoll, im Regelbetrieb aber zu langsam und zu teuer. Und neue Artikel, neue Kunden und neue Preislisten sind eigene Ereignisse mit eigener Logik. Wer sie als Sonderfall des Preis-Syncs behandelt, findet sie später als Lücke im Sortiment wieder.

Damit ist der B2B-Fall für einen Markt beschrieben. Wie die Aufteilung im B2C aussieht, steht im Überblicksartikel und im zugehörigen Deep Dive. Zu mehreren Ländern, Währungen und Steuerlogiken sowie zu Bundles und Variantenlogiken folgen eigene Einträge.