B2B-Portal am ERP: Kundenpreise, Rahmenverträge, Kreditlimit
Kurz gesagt
Für ein B2B-Portal mit kundenindividuellen Rahmenvertragspreisen und Kreditprüfung ist das redaktionelle Zielmodell, vier ERP-Daten aktuell zu beziehen: die Preisliste, den Rahmenvertragspreis, das Kreditlimit und den Bestand. Rahmenvertragspreis und Kreditlimit lesen Sie live zum Bestellzeitpunkt; Preisliste und Bestand dürfen kurz gecacht werden, wenn der Cache bei jeder Änderung neu geladen wird. Die Caching-Regeln sind redaktionelle Empfehlungen.
Das Wichtigste
- Redaktionelles Zielmodell: Das Portal bezieht vier ERP-Daten aktuell – Preisliste, Rahmenvertragspreis, Kreditlimit, Bestand.
- Die Caching-Regel richtet sich nach der Änderungsrate der Daten; die hier angenommenen Änderungsraten sind Projektbedingungen, keine Vorgabe eines Standards.
- GS1 definiert die GTIN für Artikel und die GLN für Standorte in seinem Standard, verlangt deren Einsatz aber nicht für jedes Portal; eindeutige Zuordnung geht auch über interne Schlüssel und Mapping.
- Im EDI können bei Verwendung der PRICAT-Nachricht (EANCOM Subset 009) Preise und Gültigkeitszeiträume übertragen werden; die DTM-Segmente sind conditional.
- GS1-Standards sind freiwillig; verbindlich werden sie, wenn die Handelspartner ihre Verwendung vereinbaren.
Ein B2B-Portal zeigt dem Kunden Preise und Mengen, die aus Ihrem ERP kommen. Ob der Kunde den richtigen Preis sieht, hängt nicht davon ab, ob das Portal angebunden ist, sondern davon, welche Daten es aus dem ERP bezieht und wie aktuell sie sind. Dieser Artikel listet die Daten auf, die aus dem ERP kommen sollten, und nennt für jede eine Caching-Regel.
Worauf es ankommt
Ein Portalpreis ist korrekt, wenn er zum Bestellzeitpunkt mit dem ERP übereinstimmt. Das gilt für den Preis, die verfügbare Menge und das Kreditlimit. Drei Dinge entscheiden, ob das Portal diese Werte aktuell hat.
Erstens die Identifikation. Portal und ERP müssen denselben Artikel und denselben Lagerort meinen. GS1 definiert in seinem Standard die Global Trade Item Number (GTIN) als Identifikationsschlüssel für Handelsartikel (Abschnitt 1.3.1) und die Global Location Number (GLN) für Parteien und Standorte (Abschnitt 2.4). GS1 verlangt den Einsatz dieser Schlüssel nicht für jedes Portal; eine eindeutige Zuordnung geht auch über interne Schlüssel und Mapping. Entscheidend ist, dass beide Systeme denselben Artikel und denselben Lagerort meinen.
Zweitens die Änderungsrate. Die Caching-Regel richtet sich nach der Änderungsrate der Daten. Die hier angenommenen Änderungsraten (Bestände ändern sich mit jeder Lagerbewegung, Rahmenvertragspreise nur bei Vertragsänderung) sind Projektbedingungen, keine Vorgabe eines Standards.
Drittens der Ausleseweg. Im redaktionellen Zielmodell liest das Portal die Werte live aus dem ERP. Im EDI kann der Verkäufer bei Verwendung der PRICAT-Nachricht (EANCOM Subset 009) Preise und Gültigkeitszeiträume übertragen; das System des Käufers wendet den Preis innerhalb dieses Zeitraums an. GS1-Standards sind freiwillig; verbindlich werden sie, wenn die Handelspartner ihre Verwendung vereinbaren.
Die vier Daten und ihre Caching-Regeln
Die Tabelle listet die vier Daten auf, die das redaktionelle Zielmodell für ein B2B-Portal mit Preisvereinbarungen und Kreditprüfung vorsieht, und nennt für jede die Konsequenz eines veralteten Werts und eine Caching-Regel. Die Caching-Regeln sind redaktionelle Empfehlungen; sie sind keine Vorgabe eines Standards.
| Datenpunkt | Was ein veralteter Wert bewirkt | Caching-Regel (redaktionelle Empfehlung) |
|---|---|---|
| Preisliste (Basispreise) | Der Kunde sieht einen Preis, der nicht mehr gilt; die Bestellung wird zu falschen Konditionen gebucht. | Kurz cachen (Minuten); bei jeder Preislistenänderung neu laden. |
| Rahmenvertragspreis (kundenindividuell) | Der Kunde sieht den Listenpreis statt seines Vertragspreises oder umgekehrt. | Live zum Bestellzeitpunkt lesen; nicht cachen. |
| Kreditlimit | Das Portal lässt eine Bestellung zu, die das Limit überschreitet, oder blockiert eine zulässige. | Live zum Bestellzeitpunkt lesen; nicht cachen. |
| Bestand (verfügbar) | Der Kunde sieht verfügbare Mengen, die nicht mehr da sind; die Bestellung wird nicht vollständig geliefert. | Kurz cachen (Sekunden bis Minuten); bei jeder Lagerbewegung neu laden. |
Die Caching-Regel hängt von der Änderungsrate der Daten ab. Die hier angenommenen Änderungsraten sind Projektbedingungen, keine Vorgabe eines Standards: Bestände ändern sich mit jeder Lagerbewegung, daher nur kurz cachen. Rahmenvertragspreise und Kreditlimits ändern sich selten, aber ein veralteter Wert hat einen hohen Fehlerwert; hier ist das Live-Lesen zum Bestellzeitpunkt der sicherere Weg. Die Preisliste liegt dazwischen: Sie ändert sich seltener als Bestände, häufiger als Rahmenverträge.
Ein Rechenbeispiel (erfunden)
Die folgenden Beispiele verwenden erfundene Zahlen, um die Konsequenz eines veralteten Caches zu illustrieren.
Preis. Ein Kunde hat für den Artikel mit der GTIN 04012345678901 einen Rahmenvertragspreis von 10,00 Euro; die Preisliste zeigt 12,00 Euro. Das Portal cacht den Preis 24 Stunden; der Cache wurde um 09:00 Uhr geladen (Preis: 10,00 Euro). Um 10:00 Uhr wird der Rahmenvertragspreis auf 9,50 Euro geändert. Um 14:00 Uhr bestellt der Kunde und sieht 10,00 Euro, weil der Cache noch nicht abgelaufen ist (er läuft am nächsten Tag um 09:00 Uhr ab). Die Bestellung wird zu 10,00 Euro gebucht, das ERP führt aber 9,50 Euro. Die Differenz von 0,50 Euro je Stück muss nachträglich korrigiert werden.
Bestand. Ein Artikel hat 5 Stück Bestand. Das Portal cacht den Bestand 1 Stunde; der Cache wurde um 11:00 Uhr geladen (Bestand: 5 Stück). Um 11:30 Uhr werden 5 Stück verkauft. Um 11:45 Uhr bestellt der Kunde und sieht „5 verfügbar”, weil der Cache noch nicht abgelaufen ist (er läuft um 12:00 Uhr ab). Die Bestellung wird angenommen, der Bestand ist aber 0. Es entsteht ein Nachschub oder eine Stornierung.
Typische Fehler
- Preise über Stunden cachen: Der Rahmenvertragspreis ändert sich, das Portal zeigt den alten Wert. Prüfen Sie, ob der Cache bei jeder Preisänderung neu geladen wird.
- Bestände ohne Zeitfenster cachen: Ein veralteter Bestand zeigt verfügbare Mengen, die nicht mehr da sind. Setzen Sie eine kurze TTL und laden Sie bei jeder Lagerbewegung neu.
- Kreditlimit im Kundenstamm cachen: Das Limit wird angepasst, das Portal blockiert oder lässt Bestellungen falsch zu. Lesen Sie das Limit live zum Bestellzeitpunkt.
- Artikel- und Lagerortschlüssel nicht abgleichen: Portal und ERP meinen unterschiedliche Artikel oder Lagerorte. Prüfen Sie, dass beide Systeme dieselben Schlüssel verwenden – GS1-Schlüssel (GTIN, GLN) oder interne Schlüssel mit Mapping.
- PRICAT und Portal parallel ohne Abstimmung: Der EDI-Preis und der Portalpreis weichen ab, weil sie aus unterschiedlichen Quellen kommen. Führen Sie beide aus derselben Preisquelle.
So gehen Sie vor
- Listen Sie die vier Daten auf, die das Portal aus dem ERP beziehen sollte: Preisliste, Rahmenvertragspreis, Kreditlimit, Bestand.
- Prüfen Sie, ob Portal und ERP denselben Artikel und denselben Lagerort meinen: Verwenden Sie dieselben Schlüssel (GS1-Schlüssel GTIN/GLN oder interne Schlüssel mit Mapping).
- Legen Sie je Datenpunkt die Caching-Regel fest: live, kurz cachen oder mit TTL. Halten Sie die TTL und den Auslöser für ein Neu laden schriftlich fest.
- Testen Sie den Fall einer Preisänderung: Ändern Sie den Rahmenvertragspreis und prüfen Sie, ob das Portal den neuen Wert zeigt.
- Testen Sie den Fall eines Bestandswechsels: Verkaufen Sie den letzten Bestand und prüfen Sie, ob das Portal die Verfügbarkeit anpasst.
- Prüfen Sie, ob die Verarbeitung personenbezogener Daten im Portal (Login, Ansprechpartner, Bestellhistorie) datenschutzrechtlich aufgesetzt ist.