Fünf Kartons bestellt, 500 Stück berechnet: die Verpackungseinheit fehlt in der Schnittstelle
Zwischen Bestellportal, ERP und Lager wechselt dieselbe Zahl die Bedeutung. Die Menge kommt an, die Verpackungseinheit bleibt zurück. Der Fehler trifft nur die Artikel, die in Gebinden verkauft werden, und deshalb überlebt er jede Testphase.
Fünf bestellt, 4.700 Euro berechnet
Ein Großhändler für Praxisbedarf hat im März fünf Kartons Nitrilhandschuhe an eine Zahnarztpraxis geliefert, 100 Stück je Karton, 9,40 Euro der Karton. Das Lager hat richtig gepackt, der Lieferschein war richtig. Auf der Rechnung standen 500 Stück zu 9,40 Euro, Summe 4.700 Euro, für Ware im Wert von 47 Euro.
Die Praxis hat reklamiert, das war der einfache Teil. Der schwierige Teil kam danach, denn diese Schnittstelle lief zu dem Zeitpunkt seit sieben Monaten.
Die Menge wurde umgerechnet, der Preis nicht
Im Bestellportal ist der Artikel in Verpackungseinheiten geführt. Kunden bestellen Kartons, keine einzelnen Handschuhe. Das ERP führt denselben Artikel in Stück, weil der Bestand in Stück gezählt wird und die Kommissionierung auch einzelne Packungen aus dem Karton nimmt.
Beim Bau der Anbindung hat jemand an diesen Unterschied gedacht, an einer Stelle. Die Menge wird mit 100 multipliziert, aus 5 werden 500. Der Preis geht unverändert durch, weil er im Portal in einem Feld namens price steht, im ERP in einem Feld namens Einzelpreis, und beide im Mapping gleich aussehen.
Der Lauf war grün. Das ERP hat beide Zahlen angenommen, für diesen Artikel ist jede davon korrekt. Falsch ist nur die Kombination, und Kombinationen prüft kein Pflichtfeld.
Warum die Einheit unterwegs verloren geht
Die meisten Schnittstellen übertragen Zahlen, keine Größen. Das Feld heißt quantity und enthält 5. Was gezählt wird, steht woanders, in den Artikelstammdaten des Quellsystems, in einer Spalte, die beim Mapping nicht gebraucht wurde.
Manche APIs liefern die Einheit mit, in einem Feld unit oder uom. Sie fällt trotzdem raus, weil das Zielsystem ein Pflichtfeld für die Menge hat und keins für die Einheit. Was optional ist, verschwindet im ersten Mapping und kommt nicht zurück.
Dazu kommt die Richtung. In dem einen System ist die Basiseinheit Stück und die Verpackungseinheit die Ableitung, im anderen umgekehrt. Ob der Faktor 100 multipliziert oder dividiert werden muss, entscheidet nicht die API, sondern die Stammdatenpflege auf beiden Seiten. Verwechselt man die Richtung, liegt das Ergebnis um den Faktor 10.000 daneben, und das fällt wenigstens auf.
Der Fehler trifft nur einen Teil des Sortiments
Bei diesem Großhändler hatten rund 80 Prozent der Artikel die Verpackungseinheit 1. Für die ist der Umrechnungsfaktor 1, und damit stimmt jedes Mapping, egal wie es gebaut wurde. Karton und Stück sind dasselbe, Preis pro Karton und Preis pro Stück auch.
Der Rest sind Gebinde: Handschuhe, Tupfer, Kanülen, Desinfektionsmittel im Sechserpack. Artikel mit einem Faktor größer als 1 also, und dazu solche, die über das Portal seltener bestellt werden als die Standardware.
Deshalb überlebt so ein Fehler den Test. Wer eine Anbindung mit drei Beispielbestellungen prüft, trifft mit hoher Wahrscheinlichkeit dreimal einen Artikel mit Verpackungseinheit 1 und sieht dreimal ein korrektes Ergebnis.
Wo dieselbe Verwechslung sonst auftaucht
Der nächtliche Bestandsabgleich schreibt den Lagerbestand in den Shop. 40 Kartons werden zu 40 verfügbaren Einheiten, der Artikel steht als knapp im Portal, obwohl 4.000 Stück im Regal liegen. Bei einem Getränkelogistiker lief es andersherum: Der Shop hat 3.600 Flaschen angezeigt und verkauft, im Lager standen 300 Kästen. Der erste Engpass kam vier Tage später.
Im Versandmodul geht es um Kilogramm gegen Gramm, in der Gefahrgutprüfung um Liter gegen Milliliter. Der Faktor ist 1.000. Ein Paket mit 12.000 Kilogramm lehnt jeder Versanddienstleister ab, was den Fehler wenigstens sichtbar macht. Für 0,012 Kilogramm druckt er ein Label.
Am wenigsten auffällig ist der Fall bei Staffelpreisen. Die Staffel gilt ab 500 Stück, das Portal übergibt 5 Kartons, und der Kunde bekommt den Staffelpreis nicht, obwohl er die Menge bestellt hat. Darüber beschwert sich niemand, das kostet nur Marge auf der falschen Seite.
Was wir bei solchen Anbindungen festlegen
Die Einheit reist mit. Jedes Mengenfeld in einem Workflow bekommt ein zweites Feld daneben, auch wenn das Zielsystem es nicht verlangt. Das kostet nichts und macht in jedem Ausführungsprotokoll sichtbar, worüber gerade gerechnet wurde.
Umgerechnet wird an einer Stelle, direkt beim Eingang, und danach nie wieder. Menge und Preis sind bei diesem Großhändler auseinandergelaufen, weil die Umrechnung an zwei Stellen im Szenario stand und nur eine davon gepflegt wurde.
Der Faktor kommt aus den Stammdaten, nicht aus dem Workflow. Steht er im Workflow, ändert ihn niemand, wenn der Lieferant das Gebinde von 100 auf 90 umstellt. Die Lieferung kommt dann mit der neuen Größe und die Rechnung mit der alten.
Und es gibt eine Obergrenze je Position. Ein Positionswert über 2.000 Euro oder eine Menge über 1.000 Stück geht in die Freigabe statt in die Fakturierung. Diese Grenze fängt Einheitenfehler ab und Tippfehler im Portal gleich mit.
Die Prüfung dauert zehn Minuten
Suchen Sie drei Artikel mit einer Verpackungseinheit größer als 1 und bestellen Sie je eine Einheit über Ihren eigenen Kanal. Dann vergleichen Sie vier Zahlen: die Menge im Auftrag, die Menge auf dem Lieferschein, den Einzelpreis auf der Rechnung und die Bestandsveränderung im Lager.
Wenn eine davon nicht passt, passt sie seit dem Tag nicht, an dem die Schnittstelle in Betrieb gegangen ist.