Ihre Automatisierung übergeht die Preisfindung im ERP
Der Workflow legt den Auftrag an und nimmt den Preis aus dem Artikelstamm. Bei Kunden mit Rahmenvertrag oder Staffel ist er damit falsch, und weil sich über zu niedrige Rechnungen niemand beschwert, fällt es erst nach Monaten auf.
Dieser Beitrag wurde mit KI erstellt. Kennzeichnung gemäß Art. 50 EU AI Act. Verantwortlich für die Veröffentlichung: Sophera Consulting.
4,80 Euro statt 3,95, vierzehn Monate lang
Ein Händler für medizinischen Sachbedarf beliefert vier Kliniken über ein Bestellportal. Die Bestellungen laufen seit gut einem Jahr automatisch ins ERP: Das Portal schickt einen Webhook, der Workflow legt den Auftrag an, dann die Positionen. Die Preisfindung des ERP kommt dabei nicht zum Einsatz, der Preis pro Position stammt aus dem Artikelstamm.
Im März hat die Einkaufsleitung einer Klinik eine Sammelrechnung geprüft und bei einer Position nachgefragt. Untersuchungshandschuhe, 4,80 Euro pro Karton. Im Rahmenvertrag stehen 3,95.
Wir haben uns anschließend vierzehn Monate Rechnungen angesehen. Betroffen war nicht das ganze Sortiment, sondern die 62 Artikel, für die dieser Kunde eigene Konditionen hat. Bei den übrigen rund 900 Artikeln greift ohnehin der Listenpreis, und genau deshalb ist die Sache so lange gelaufen: In der Stichprobe, die man beim Testen zieht, stimmt der Preis meistens.
Der Preis steht nicht am Artikel
Im Artikelstamm steht ein Listenpreis. Das ist eine Ausgangsgröße, kein Verkaufspreis.
Was der Kunde zahlt, entsteht aus einer Kette: Kundennummer, zugeordnete Preisliste, Rahmenvertrag mit Laufzeit, Mengenstaffel, Aktionspreis, Rabattgruppe des Artikels, bei manchen Häusern noch ein Zuschlag für Kleinmengen. Diese Kette heißt im ERP Preisfindung, sie ist dort eine eigene Funktion, und sie hat oft mehr Logik als der komplette Workflow, der den Auftrag anlegt.
Der Workflow ruft sie nicht auf. Er liest den Artikel, findet ein Feld namens Preis und schreibt den Wert in die Position.
Warum die Schnittstelle das anbietet
Der Endpunkt für Artikel liefert einen Preis, weil er einen Standardpreis liefern muss. Er kennt den Kunden nicht, der gerade bestellt, also kann er nichts anderes liefern.
Die Preisfindung passiert im ERP an einer anderen Stelle: beim Anlegen der Auftragsposition. Übergibt man dort Artikelnummer, Kunde und Menge und lässt das Preisfeld leer, rechnet das System. Übergibt man einen Preis, akzeptiert es ihn und rechnet nicht.
Das ist kein Fehler in der Schnittstelle. Ein manuell erfasster Sonderpreis muss übergeben werden können, sonst könnte der Vertrieb nie von der Kondition abweichen. Der Workflow benutzt diese Möglichkeit nur bei jeder einzelnen Position, ohne dass jemand das entschieden hätte.
Bei zwei anderen Kunden haben wir denselben Aufbau gefunden, beide Male mit derselben Begründung: Beim Bau war unklar, ob das Preisfeld ein Pflichtfeld ist, also wurde es sicherheitshalber gefüllt.
Die Staffel gilt für die Bestellung, die Schleife sieht die Position
Staffelpreise hängen an der Menge: 1 bis 9 Kartons zum einen Preis, 10 bis 49 zum nächsten, ab 50 zum dritten. Ein Workflow, der die Positionen in einer Schleife nacheinander anlegt, übergibt bei jedem Durchlauf eine Menge. Bestellt der Kunde dreimal denselben Artikel in verschiedenen Zeilen, weil das Portal so aufgebaut ist, sieht das ERP dreimal eine kleine Menge statt einmal eine große.
Das gleiche passiert beim Auftragssplitting. Wird eine Bestellung nach Lieferwerk oder nach Verfügbarkeit auf zwei Aufträge verteilt, fällt der Kunde in beiden Aufträgen unter die Staffelgrenze, die er zusammen überschritten hätte.
Bei dem Händler waren das im Jahr 41 Bestellungen. Der Betrag pro Fall ist klein, das ist der Grund, warum sich nie jemand gemeldet hat.
Preise haben ein Datum, Workflows selten
Rahmenverträge laufen aus, Preislisten gelten ab einem Stichtag, und eine Aktion, die im Juni galt, gilt im Juli nicht mehr.
Wir sehen regelmäßig Automatisierungen, die eine Preisliste einmal als Tabelle ausgelesen und in Airtable oder eine Google Tabelle geschrieben haben, um API Aufrufe zu sparen. Danach lief der Abgleich nie wieder. Beim Händler oben war eine solche Tabelle im Spiel, Stand des Vorjahres, für die Artikel, die das Portal vorab anzeigt.
Dazu kommt die Frage, welches Datum überhaupt zählt. Bestelldatum, Auftragsdatum oder Lieferdatum können auseinanderfallen, gerade bei Rückständen über den Jahreswechsel. Das ERP nimmt dafür ein bestimmtes Feld. Wenn der Workflow den Preis selbst setzt, nimmt er implizit den Tag, an dem er gelaufen ist.
Zu teuer fällt auf, zu billig nie
Berechnen Sie zu viel, meldet sich der Kunde. Nicht sofort, aber irgendwann, und dann kostet es Vertrauen und eine Gutschrift.
Berechnen Sie zu wenig, meldet sich niemand. Die Position ist fakturiert, der Deckungsbeitrag fehlt, und in der Auswertung sieht das aus wie eine schwache Marge im Sortiment, nicht wie ein Fehler in der Schnittstelle.
Bei dem Händler ging der Fehler in beide Richtungen. Aufgefallen ist nur die eine.
Der falsche Preis bleibt nicht im Auftrag
Ein Auftragspreis ist keine Sackgasse. Er landet in der Rechnung, in der Umsatzstatistik, in der Deckungsbeitragsrechnung pro Kunde und in den Zahlen, mit denen im Herbst die Konditionen für das nächste Jahr verhandelt werden. Ein Kunde, bei dem systematisch zu wenig berechnet wurde, sieht in der Auswertung unattraktiv aus, und im Zweifel bekommt er dann schlechtere Konditionen wegen eines Fehlers, den der Lieferant gemacht hat.
Bei Retouren geht es weiter. Eine Gutschrift muss den Preis erstatten, der auf der ursprünglichen Rechnung stand. Automatisierungen, die eine Gutschrift aus dem Rücksendeschein erzeugen, holen den Preis oft frisch aus dem Artikelstamm, weil das der Weg ist, den sie schon kennen. War die Rechnung zu hoch, erstattet die Gutschrift zu wenig, und der Fehler bleibt beim Kunden hängen. Bei einem Aktionsartikel, dessen Aktion inzwischen abgelaufen ist, kann die Erstattung deutlich unter dem liegen, was der Kunde gezahlt hat.
Die Korrektur selbst ist der unangenehmste Teil. Vierzehn Monate falsche Preise heißt bei diesem Händler 340 betroffene Positionen, verteilt auf Rechnungen, die längst bezahlt sind. Rechnungskorrekturen über einen abgeschlossenen Zeitraum sind eine steuerliche und eine vertriebliche Angelegenheit, keine technische. Der Workflow war an einem Nachmittag repariert, die Aufarbeitung hat sechs Wochen gedauert.
Was wir in Auftragsprozessen festlegen
Der Preis kommt aus dem System, das die Preisfindung besitzt. Der Workflow übergibt Artikelnummer, Kundennummer, Menge und Datum und lässt das Preisfeld leer. Alles andere heißt, die Konditionslogik des ERP im Workflow nachzubauen, und dieser Nachbau altert ab dem Tag der Inbetriebnahme.
Muss das Portal einen Preis vorab anzeigen, sind es zwei Aufrufe. Erst eine Preisanfrage an das ERP, mit Kunde und Menge, dann die Bestellung. Der angezeigte Preis bekommt eine Gültigkeit von wenigen Minuten. Weicht der Preis beim Anlegen ab, geht der Auftrag in eine Freigabe statt durch.
Positionen gehen in einem Aufruf ins System, nicht einzeln in einer Schleife. Gleiche Artikel werden vorher zusammengefasst. Was aus kaufmännischen Gründen auf zwei Aufträge geteilt wird, wird für die Preisfindung trotzdem als eine Menge betrachtet, sonst zahlt der Kunde für die Logistik des Lieferanten.
Jede Position bekommt eine Plausibilitätsprüfung gegen den Listenpreis. Rabatte über einer festgelegten Grenze und alles unterhalb des Einstandspreises laufen in eine Freigabe. Der Schritt bremst den Normalfall nicht aus, er fängt Konfigurationsfehler ab, bevor die Rechnung das Haus verlässt.
Im Protokoll steht, woher der Preis kam. Preisliste, Rahmenvertrag, Staffel, Aktion oder Sonderpreis, mit Kennung. Ohne diese Angabe braucht die Fehlersuche in einem Jahr denselben Aufwand wie oben: vierzehn Monate Rechnungen und ein Nachmittag mit dem Einkauf.
Eine Stunde, dann wissen Sie es
Suchen Sie Ihre fünf Kunden mit den umfangreichsten Sonderkonditionen. Ziehen Sie aus jedem der letzten drei Monate zehn automatisch angelegte Auftragspositionen und vergleichen Sie den fakturierten Preis mit dem, was die Preisfindung im ERP für diesen Kunden, diese Menge und dieses Datum ausgibt.
Stimmen die Werte, prüfen Sie noch die Staffelfälle: Bestellungen mit mehreren Zeilen desselben Artikels und Aufträge, die gesplittet wurden.
Findet sich in fünfzig Positionen keine Abweichung, ist die Preisfindung sauber angebunden. Findet sich eine, betrifft sie alle Bestellungen dieses Kunden seit der Inbetriebnahme, und Sie müssen entscheiden, wie weit zurück Sie korrigieren.