Preise und Stammdaten zwischen ERP und Shop pflegen

Ein Feld wie der Verkaufspreis kann in zwei Systemen stehen, aber nur eines darf es schreiben. Schreibt auch das andere, hängt die Anzeige davon ab, welcher Lauf zuletzt lief, und die Rechnung kann einen anderen Betrag tragen als der Warenkorb. Die Frage lautet deshalb nicht, welche Software die bessere ist, sondern welches System eine Angabe setzen darf; diesen Zuschnitt nennen wir hier Systemführerschaft.

Was Sie vorab brauchen

• ein Feldinventar: jedes Feld, das in beiden Systemen vorkommt, mit dem Namen je System
• Zugriff auf die Import- und Exportprofile, nicht nur auf die Anzeige
• die Preislisten sowie Staffel- und Kundengruppenpreise, soweit vorhanden
• die Liste Ihrer Kanäle (Shop, Marktplatz, Preisvergleich, Geschäftskundenliste)
• fünf Artikel als Stichprobe, darunter ein Staffelpreis, ein Bündel und ein Länderpreis

Schritt für Schritt: Felder verteilen und abgleichen

Schritt 1: Feldinventar anlegen

Schreiben Sie beide Feldlisten nebeneinander und suchen Sie die Angaben, die dasselbe meinen. Achten Sie auf Paare, die gleich heißen und Verschiedenes bedeuten: „Lieferzeit“ ist im ERP die Beschaffungszeit beim Lieferanten, im Shop der Text für die Kundschaft. Markieren Sie abgeleitete Werte, die kein eigenes Feld sind, sondern eine Rechnung: der Bruttopreis aus Nettopreis und Steuerschlüssel, der Grundpreis aus Preis und Bezugsmenge.

Ergebnis: eine Liste mit dem Feldnamen je System und dem Vermerk „abgeleitet“ oder „übertragen“.

Schritt 2: Je Feld ein führendes System festlegen

Für jedes Feld notieren Sie ein System als Quelle und das andere als Empfänger. Hilft die Zuordnung nicht weiter, trennen Sie das Feld in zwei Felder, statt sich auf eine Absprache zu verlassen: eine Handelsbezeichnung für den Beleg und einen Verkaufstext für die Produktseite. Die Tabelle ist eine Arbeitsvorlage.

Feld	Führendes System	Warum dort	Im zweiten System
Artikelnummer (SKU)	ERP	Sie verbindet Bestellung, Rechnung und Lager	übernehmen, nicht neu vergeben
GTIN	Herstellerangabe in ERP oder PIM	Sie identifiziert den Handelsartikel im offenen Handel	übernehmen
Verkaufstext und Bilder	Shop oder PIM	Sie richten sich nach dem Kanal	hier pflegen
Shop-Kategorie	Shop	Sie folgt der Navigation, nicht dem Lager	nicht zurückschreiben
Warengruppe und Erlöskonto	ERP	Sie steuern Auswertung und Buchhaltung	übernehmen
Merkmale und Varianten	ERP oder PIM	Sie bestimmen Nummer, Bestand und Preis je Ausprägung	übernehmen
Preise der Preisliste (Liste, Staffel, Kundengruppe)	ERP	Sie gelten kanalübergreifend und tragen die Rechnung	nur lesen
Aktionspreis mit Gültigkeit	das System, in dem die Aktion gilt	Sie gilt für einen Kanal oder für alle	zum Enddatum beenden
Bestand und Verfügbarkeit	ERP oder Lagerverwaltung	Dort entstehen die Lagerbewegungen	nur anzeigen
Gewicht und Maße für den Versand	ERP oder PIM	Sie gehen in Versandkosten und Frachtpapiere ein	dieselben Werte nutzen
Steuerschlüssel (Feld)	ERP oder Fakturierung	Er gehört zur Buchhaltung	übernehmen
Einkaufspreis und Kalkulation	ERP	Vertrags- und Buchhaltungsdaten	nie in den Shop übertragen
Bezugsmenge für den Grundpreis	PIM oder ERP	Sie ist eine Produkteigenschaft	Anzeige daraus ableiten
Preisliste und Währung je Land	ERP	Je Land gilt eine eigene Liste	Land bestimmt die Liste

Was der Shop davon anzeigt, folgt dem Preisangabenrecht je Land: Preisangaben in Deutschland, Preisangaben in Österreich, Preisangaben in der Schweiz. Liegen Produkttexte in mehreren Kanälen, hilft ein eigenes Produktinformationssystem, siehe Wann sich ein PIM-System lohnt.

Schritt 3: Schreibrechte im zweiten System sperren

Ein Feld ist erst ruhig, wenn das zweite System es nicht schreiben kann. Nehmen Sie es aus dem Importprofil der Rückrichtung und entfernen Sie im Shop die Möglichkeit, den übernommenen Wert zu überschreiben; eine solche Option ist eine zweite Pflegestelle. Muss im Ausnahmefall doch jemand im Shop ändern, notieren Sie Wer, Was und Wann und tragen Sie den Wert in das führende System nach.

Schritt 4: Änderungen feldweise und wiederholbar übertragen

Schicken Sie statt des ganzen Artikelsatzes die geänderte Angabe mit Artikelnummer, Feldname, neuem Wert und Version. Dafür ist die HTTP-Methode PATCH gedacht: Sie überträgt Anweisungen zu einem bestehenden Datensatz, während PUT die ganze Darstellung ersetzt (RFC 9110, Abschnitte 9.3.4 und 14.5). PATCH ist nach RFC 5789 weder sicher noch idempotent und wird serverseitig vollständig oder gar nicht angewendet.

JSON Patch (application/json-patch+json) überträgt Anweisungen wie add und replace; schlägt eine fehl, gilt das ganze Dokument als nicht angewendet (RFC 6902, Abschnitte 1 und 5), und test prüft vorab den erwarteten Wert (Abschnitt 4.6). JSON Merge Patch beschreibt den gewünschten Zustand, wobei ein null ein Feld entfernt (RFC 7396, Abschnitt 1); es passt nicht zu Dokumenten, die null als eigenen Wert verwenden.

Gegen parallele Änderungen brauchen Sie eine Vorbedingung, die die Schnittstelle je Änderung prüft; If-Match ist einer von mehreren Wegen (RFC 5789, Abschnitt 2, nennt eine bedingte Anfrage mit starkem ETag als Beispiel). Wählen Sie diesen Weg, vergleicht der Server keinen freien Wert im Datensatz, sondern den Entity-Tag (ETag): Nach RFC 9110 muss er dabei stark vergleichen und die Methode unterlassen, wenn kein gelisteter ETag mehr passt (Abschnitt 13.1.1, zum starken ETag Abschnitt 8.8.1). Die gescheiterte Vorbedingung darf er mit 412 anzeigen (Abschnitt 15.5.13); hat ein anderer Aufruf die Änderung bereits angewandt, darf er stattdessen auch mit 2xx antworten und ändert dann nichts mehr (Abschnitt 13.1.1). Das setzt voraus, dass die Schnittstelle für jeden Datensatz einen starken ETag liefert und die Vorbedingung auswertet; führen Sie die Version nur als Feld im Datensatz, weist sie konkurrierende Änderungen ab, sobald die Schnittstelle sie prüft, etwa als test-Anweisung in einem JSON Patch, das der Server vollständig oder gar nicht anwendet (RFC 6902, Abschnitte 4.6 und 5) (redaktionelle Arbeitsregel). Wiederholen darf ein Client nur, was wiederholbar ist: PUT, DELETE und lesende Methoden ja, POST ohne weitere Kenntnis nicht (Abschnitt 9.2.2).

Beträge gehen als Dezimalzahl fester Stellenzahl oder als ganze Zahl in der kleinsten Währungseinheit über: RFC 8259, Abschnitt 6, weist darauf hin, dass Implementierungen Zahlen nach IEEE 754 binary64 annähern dürfen; Euro und Franken haben je zwei Nachkommastellen (ISO 4217, Stand 17. September 2026). Zu einer Preisänderung gehört das Datum, ab dem sie gilt, sonst entscheidet der Zeitpunkt des Laufs (redaktionelle Empfehlung).

Schritt 5: Preis rundet genau ein System

Führt das ERP den Nettopreis und der Shop den Bruttopreis, wird zweimal gerechnet und zweimal gerundet. Beispielrechnung mit erfundenen Zahlen und einem angenommenen Satz von 20 Prozent, der keine Aussage über einen Steuersatz in den drei Ländern ist: 8,30 Euro netto ergeben brutto 8,30 × 1,20 = 9,96 Euro. Rundet der Shop die Anzeige auf 9,95 Euro und schreibt zurück, ergibt 9,95 ÷ 1,20 = 8,2916…, gerundet 8,29 Euro netto: eine unbeabsichtigte Senkung um einen Cent. Den Wert, der angezeigt und abgerechnet wird, setzt deshalb ein System; das zweite übernimmt ihn.

Eine reine Preisänderung lässt die Kennungen unangetastet: Nach dem GTIN Management Standard löst nur der direkt auf die Packung gedruckte Preis eine neue GTIN aus (Abschnitt 2.10). Wer bei jeder Preisanpassung neu vergibt, verliert die Zuordnung zu Bestellungen, Feeds und Lagerbestand.

Schritt 6: Abgleich, Stichprobe und Nachweis einrichten

Prüfen Sie jeden Lauf und zusätzlich im Shop. Je Lauf: Zahl der geänderten Felder, Summe der Preise vorher und nachher und die Artikelnummern mit altem und neuem Wert. Im Shop: die fünf Stichproben aufrufen und Anzeige, Warenkorb, Bestellbestätigung und Rechnungsposition vergleichen, mit den Randfällen, in denen zwei Felder zusammenwirken (Staffelpreis, Länderpreis, Aktionspreis mit Enddatum, Grundpreis).

Ergebnis: ein Bericht je Lauf mit Laufzeit, Zahl der Änderungen, Differenzen und Stichproben; damit lässt sich eine Preisdifferenz einem Lauf zuordnen. Wie Sie Fehler einer Übergabe erkennen und alarmieren, beschreibt Datensynchronisation zwischen Systemen.

So prüfen Sie das Ergebnis

• Jedes Feld im Feldinventar hat ein führendes System; keines ist in beiden Systemen änderbar.
• Die Rückrichtung überträgt kein Preisfeld, keinen Bestand und keine Kennung.
• Eine Preisänderung trägt Artikelnummer, Feldname, Wert und die Vorbedingung mit, gegen die sie geprüft wird; passt sie nicht mehr (etwa der starke ETag), wendet der Server die Änderung nicht an.
• Beträge kommen als Dezimalzahl fester Stellenzahl oder als ganze Zahl in der kleinsten Einheit an.
• Die fünf Stichproben stimmen in Anzeige, Warenkorb, Bestellbestätigung und Rechnung überein.

Wenn etwas nicht klappt

Symptom	Ursache	Behebung
Der Preis im Shop ist am Morgen wieder der alte	Im Shop wurde geändert, der Lauf hat überschrieben	Änderung im ERP nachtragen, Feld im Shop sperren
Anzeige und Rechnung weichen um einen Cent ab	Zwei Systeme runden den Bruttopreis	Rundung in ein System legen
Shop und Marktplatz zeigen verschiedene Preise	Der Kanal liest eine eigene Liste	Quelle je Kanal dokumentieren
Nach einem Lauf ist der Preis leer	Ein Merge Patch hat null gesendet und damit das Feld entfernt (RFC 7396)	Den gültigen Preis erneut senden; ein Feld bewusst leeren nur im mit der Schnittstelle vereinbarten Format (RFC 7396, Abschnitt 2)
Eine Preisänderung wurde doppelt gebucht	Ein Aufruf ohne eigenen Schlüssel lief zweimal	Je Änderung einen eigenen Schlüssel mitgeben und im Ziel speichern, damit die Gegenseite denselben Schlüssel erkennt und den zweiten Aufruf verwirft; das setzt eine Deduplizierung voraus, die die Schnittstelle tatsächlich anbietet (redaktionelle Arbeitsregel)
Der Bestand im Shop passt nicht zum Lager	Die Verfügbarkeit wird im Shop berechnet	Verfügbarkeit aus dem führenden Bestand ableiten

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn beide Systeme dasselbe Feld in beide Richtungen schreiben und niemand den Vorrang entscheidet, wenn ein Marktplatz eine eigene Preisquelle verlangt, oder wenn Preise in mehreren Ländern und Währungen geführt werden. Für die Systemwahl hilft Warenwirtschaft für Onlinehändler, für die Übertragungswege Schnittstellen im Shop-Umfeld und für die Frage, ab wann ein ERP nötig wird, ERP im Onlinehandel.