Ein Großhändler führt seine Artikel im ERP in Stück, verkauft sie aber im Karton zu zwölf, liefert auf Paletten zu vier Lagen und rechnet Kabel nach Metern ab. Im Shop steht am Ende eine einzelne Zahl im Warenkorb, und wenn niemand festgelegt hat, welche Einheit diese Zahl trägt, bestellt der Einkäufer zehn Kartons und bekommt zehn Stück. Mengeneinheiten sind deshalb kein Randthema der Stammdatenpflege, sondern der Punkt, an dem Bestellungen, Bestände und Rechnungen auseinanderlaufen. Die internationale Codeliste für Einheiten wird laufend gepflegt und umfasst rund 1.800 Schlüssel, die meisten davon dreistellig (UNECE). Dieser Beitrag zeigt, wie sich Basis-, Lager-, Verkaufs- und Bestelleinheit trennen lassen, warum Umrechnungsfaktoren in die Warenwirtschaftsanbindung gehören statt in die Shop-Oberfläche, und wie eine Middleware Bestände, Mindestmengen und Grundpreise über die Systemgrenze bringt, ohne dass unterwegs Nachkommastellen verloren gehen.
Das Wichtigste in Kürze
- Ein Artikel braucht vier getrennte Einheitenrollen: Basiseinheit für die Buchung, Lagereinheit für die Kommissionierung, Verkaufseinheit für den Shop und Bestelleinheit für den Lieferanten. Der im deutschen B2B verbreitete Katalogstandard trennt diese Ebenen als ORDER_UNIT, CONTENT_UNIT und NO_CU_PER_OU (BMEcat).
- Umrechnungsfaktoren gehören in das führende System. Wird derselbe Faktor zusätzlich im Shop gepflegt, entstehen zwei Wahrheiten, und die Abweichung fällt erfahrungsgemäß erst in der Rechnung auf.
- Für den Austausch zwischen Systemen existieren dreistellige Einheitenschlüssel aus der Empfehlung 20 (UNECE). Die europäische Norm für die elektronische Rechnung verlangt genau diese Codeliste für die Mengeneinheit einer Rechnungsposition (EN 16931).
- Bestände werden in Verkaufseinheiten abgerundet statt kaufmännisch gerundet: Aus 1.542 Stück bei einem Faktor von 12 werden 128 Kartons, die verbleibenden 6 Stück bleiben gesperrt, bis sie ein volles Gebinde ergeben.
- Mengen und Beträge mit Nachkommastellen gehören in einen Dezimaltyp. In binärer Gleitkommadarstellung lässt sich 0,1 nicht exakt abbilden (IEEE 754), und der Rundungsfehler summiert sich über tausende Positionen zu sichtbaren Differenzen.
Warum eine Basiseinheit allein nicht reicht
Jedes ERP führt einen Artikel in einer Basiseinheit. Sie ist die kleinste Einheit, in der gebucht wird, und sie ist bewusst neutral gewählt: Schrauben in Stück, Kabel in Metern, Reinigungsmittel in Litern, Schüttgut in Kilogramm. Solange nur das Lager mit diesen Werten arbeitet, ist das schlüssig. Sobald der Artikel im Shop steht, treffen jedoch mehrere Mengenwelten aufeinander. Der Einkäufer denkt in Kartons, der Kommissionierer in Lagerplätzen, der Spediteur in Paletten und Ladungsmetern, die Buchhaltung in Rechnungspositionen mit Preisbezugsmenge. Wird der Bestand einfach als Basismenge übertragen, steht im Shop die Zahl 1.542 ohne erkennbare Einheit, und der Kunde legt zehn davon in den Warenkorb. Ob daraus zehn Stück, zehn Kartons oder 120 Stück werden, entscheidet dann eine Annahme, die niemand aufgeschrieben hat. Genau diese unausgesprochene Annahme wird später zur Reklamation.
Der Schaden ist selten spektakulär, dafür beständig. Eine zu kleine Lieferung erzeugt eine Nachbestellung, eine zu große eine Retoure, und beide erzeugen Belege, Rückfragen und Korrekturbuchungen. Im Verbrauchergeschäft wird im Durchschnitt rund 70 Prozent der begonnenen Warenkörbe wieder verlassen (Baymard Institute); im B2B ist die typische Reaktion auf eine unklare Mengenangabe seltener der stille Abbruch als der Anruf im Innendienst, und dieser Anruf kostet Bearbeitungszeit an genau der Stelle, an der die Anbindung eigentlich entlasten sollte. Der eigentliche Aufwand entsteht dabei nicht im Shop, sondern in der Schnittstelle: Ist die Einheitenlogik dort nicht abgebildet, muss ein Mensch sie bei jeder Bestellung neu herstellen. Wer Artikel aus dem ERP an einen Shop übergibt, überträgt deshalb nicht nur eine Zahl, sondern ein Paar aus Menge und Einheit, und zusätzlich die Regel, wie sich dieses Paar in jede andere Einheit umrechnen lässt.
Die vier Einheitenrollen im Artikelstamm
Sauber wird die Sache erst, wenn vier Rollen getrennt geführt werden, auch wenn drei davon bei einfachen Artikeln denselben Wert tragen. Die Basiseinheit ist die Buchungseinheit im ERP und der Bezugspunkt jeder Umrechnung. Die Lagereinheit beschreibt, in welcher Form die Ware im Regal liegt und kommissioniert wird, etwa als Karton statt als Einzelstück. Die Verkaufseinheit ist die Einheit, die der Kunde im Shop sieht und in der er bestellt. Die Bestelleinheit schließlich ist die Einheit, in der beim Lieferanten nachgeordert wird, oft eine Palette oder ein Gebinde. Der im deutschen B2B verbreitete Katalogstandard bildet diese Trennung ausdrücklich ab: ORDER_UNIT für die Bestelleinheit, CONTENT_UNIT für die enthaltene Einheit und NO_CU_PER_OU für die Anzahl der Inhaltseinheiten je Bestelleinheit (BMEcat). Wer diese Felder beim Daten-Mapping zwischen ERP und Shop von Anfang an besetzt, hat den größeren Teil der Arbeit erledigt.
Basiseinheit
Die kleinste buchbare Einheit im ERP. Bestände, Reservierungen und Inventuren beziehen sich ausschließlich auf sie, alle anderen Mengen werden daraus abgeleitet.
Lagereinheit
Die Form, in der die Ware physisch liegt. Sie bestimmt Kommissionierung und Anbruchregeln, etwa ob ein Karton geöffnet werden darf.
Verkaufseinheit
Die Einheit, die im Shop sichtbar ist und in der bestellt wird. Sie kann je Kundengruppe abweichen, etwa Stück im Fachhandel und Karton im Großhandel.
Bestelleinheit
Die Einheit gegenüber dem Lieferanten. Der Katalogstandard führt sie als ORDER_UNIT, ergänzt um die enthaltene Einheit CONTENT_UNIT (BMEcat).
Umrechnungsfaktor
Das Feld NO_CU_PER_OU beschreibt, wie viele Inhaltseinheiten in einer Bestelleinheit stecken (BMEcat). Es ist der einzige Ort, an dem der Faktor gepflegt werden sollte.
Einheitenschlüssel
Dreistellige Codes wie KGM für Kilogramm oder MTR für Meter machen die Einheit maschinenlesbar und stammen aus der Empfehlung 20 (UNECE).
Umrechnungsfaktoren im ERP führen, nicht im Shop
Die häufigste Abkürzung im Projekt lautet: Der Faktor wird im Shop hinterlegt, weil eine Erweiterung im ERP länger dauert und mehr Abstimmung kostet. Ab diesem Moment existieren zwei Wahrheiten. Ändert der Lieferant die Kartongröße von zwölf auf zehn, wird der Faktor im Artikelstamm gepflegt, im Shop aber übersehen. Der Kunde bestellt weiterhin in Zwölfern, das Lager liefert Zehner, und die Differenz taucht erst in der Rechnung oder in der Inventur auf. Der Faktor gehört deshalb dorthin, wo auch der Artikel gepflegt wird, und wandert von dort in den Shop, nicht umgekehrt. Die Umrechnung selbst findet in der Middleware statt: Sie liest Menge, Einheit und Faktor aus dem ERP, rechnet in beide Richtungen und liefert dem Shop fertige Werte. Der Shop zeigt an und nimmt entgegen, er rechnet nicht.
Ein Faktor, eine Quelle
lies Position: menge_verkauf, einheit_verkauf
hole faktor aus dem Artikelstamm (Basis je Verkaufseinheit)
menge_basis = menge_verkauf * faktor # Dezimaltyp, kein Gleitkomma
wenn menge_verkauf < mindestmenge:
weise ab und melde die Mindestmenge zurück
wenn menge_verkauf modulo staffelung != 0:
runde auf das nächste Vielfache auf und zeige den Hinweis
reserviere menge_basis im ERP
gib zurück: menge_verkauf, einheit_verkauf, menge_basis, faktorBestand in Verkaufseinheiten umrechnen und runden
Der Bestand kommt in Basiseinheiten aus dem ERP, angezeigt wird er in Verkaufseinheiten. Dabei wird abgerundet und nicht kaufmännisch gerundet, denn ein halber Karton ist keine verkaufbare Menge. Aus 1.542 Stück werden bei einem Faktor von 12 genau 128 Kartons; die verbleibenden 6 Stück bleiben gesperrt, bis Zulauf sie zu einem vollen Gebinde ergänzt. Diese Restmenge sollte im Shop nicht verschwinden, sondern intern als Anbruchbestand geführt werden, damit die Inventur später aufgeht. Wer mehrere Lager führt, rechnet zuerst je Lager um und summiert danach: Zwei Lager mit je 7 Stück ergeben zusammen 14 Stück, aber weiterhin null Kartons, solange keines der Lager ein volles Gebinde hält und keine lagerübergreifende Kommissionierung vorgesehen ist. Die Reihenfolge von Summieren und Runden ist damit eine fachliche Entscheidung, wie sie auch die Bestandssynchronisation über mehrere Lager prägt.
- Rundungsrichtung festlegen: Bestände werden abgerundet, Bestellmengen auf das nächste Gebinde aufgerundet. Beide Regeln gehören dokumentiert, weil sie sich fachlich widersprechen und beide korrekt sind.
- Anbruchmenge sichtbar halten: Der Rest unterhalb eines vollen Gebindes bleibt im ERP gebucht und wird im Shop ausgeblendet, statt ihn im Abgleich zu verlieren.
- Je Lager rechnen, dann summieren: Erst die Umrechnung je Standort, danach die Aggregation. Die umgekehrte Reihenfolge erzeugt Bestände, die sich nicht kommissionieren lassen, wie es in der Anbindung von Großhandelsprozessen regelmäßig auffällt.
- Sicherheitsbestand in Basiseinheiten führen: Ein Puffer von 24 Stück ist eindeutig, ein Puffer von zwei Kartons ändert seine Bedeutung, sobald sich der Faktor ändert.
- Nachkommastellen begrenzen: Bei Gewichts- und Längenartikeln legt die Schnittstelle fest, mit wie vielen Stellen gerechnet und mit wie vielen angezeigt wird, damit die Warenwirtschaftsanbindung und der Shop denselben Wert melden.
Mindestmenge und Verpackungsstaffelung im Warenkorb
Im B2B ist die frei wählbare Menge die Ausnahme. Artikel haben eine Mindestbestellmenge, eine Staffelung in Vielfachen des Gebindes und häufig eine abweichende Einheit je Kundengruppe. Der Katalogstandard kennt dafür eigene Felder: QUANTITY_MIN für die Mindestmenge und QUANTITY_INTERVAL für die zulässige Schrittweite (BMEcat). Beide Werte gehören in die Schnittstelle und nicht in eine Textnotiz in der Artikelbeschreibung. Im Warenkorb sollte die Regel nicht als Fehlermeldung nach dem Absenden auftauchen, sondern als Korrektur währenddessen: Wer 17 Stück eingibt, sieht 24 Stück und den Hinweis, dass der Artikel in Zwölfergebinden geliefert wird. Diese Durchsetzung im Warenkorb ist ein wiederkehrender Bestandteil der Anbindung von Großhandelssystemen, weil sie Nachfragen im Innendienst spürbar reduziert.
Schwieriger wird es, wenn mehrere Regeln zusammentreffen. Ein Kunde mit Rahmenvertrag darf Einzelstücke abrufen, ein Neukunde nicht. Ein Artikel ist in der Aktion nur palettenweise zu haben, außerhalb der Aktion im Karton. Solche Fälle lassen sich nicht im Shop-Backend pflegen, ohne die zweite Wahrheit wieder einzuführen; sie gehören als Konditionsdaten an den Kunden oder die Kundengruppe und werden mit dem Artikel zusammen übertragen. Wer mehrere Gesellschaften oder Buchungskreise betreibt, achtet zusätzlich darauf, dass Einheiten und Faktoren je Mandant unterschiedlich sein dürfen, ohne dass die Zuordnung im Shop verrutscht. Wie sich das organisieren lässt, beschreibt der Beitrag zur Anbindung mehrerer ERP-Mandanten an einen Shop im Detail.
| Kriterium | Ohne Einheitenlogik | Mit Einheitenlogik |
|---|---|---|
| Mengenfeld im Shop | Zahl ohne Einheit | Zahl mit Einheit und Faktor |
| Bestandsanzeige | Basismenge, unverständlich | Verkaufseinheit, abgerundet |
| Mindestmenge | Hinweis im Beschreibungstext | Regel im Warenkorb durchgesetzt |
| Gebindestaffelung | Nachträgliche Korrektur im Innendienst | Aufrundung beim Eingeben sichtbar |
| Rechnungsposition | Einheit weicht vom Auftrag ab | Einheit und Preisbezug stimmen überein |
| Retoure | Menge muss von Hand umgerechnet werden | Rücknahme in derselben Einheit gebucht |
Variable Gewichte und Längen ohne Rundungsverlust
Bei Käse, Fleisch, Kabeln, Rohren oder Stoffen ist die bestellte Menge nicht die gelieferte Menge. Der Kunde bestellt drei Stück Rundkäse, geliefert werden drei Stücke mit 2,340 kg, 2,415 kg und 2,180 kg, und abgerechnet wird das tatsächliche Gewicht. Solche Artikel brauchen zwei Mengen je Position: die Stückzahl für Kommissionierung und Versand und das Gewicht für Preis und Rechnung. Wird nur eine der beiden übertragen, entsteht entweder eine Rechnung über ein theoretisches Gewicht oder ein Lieferschein ohne Bezug zur Auftragsposition. Für den Handel mit Fertigpackungen ungleicher Nennfüllmenge schreibt die Fertigpackungsverordnung die Angabe der tatsächlichen Füllmenge vor (FertigPackV), und die dafür genutzten Waagen unterliegen im geschäftlichen Verkehr dem Eichrecht (MessEG). Die Rückmeldung des Ist-Gewichts ist damit keine Kür, sondern Teil der Belegkette.
Technisch entscheidet der Datentyp über das Ergebnis. Mengen mit drei Nachkommastellen und Preise mit vier oder sechs Stellen gehören in einen Dezimaltyp; in binärer Gleitkommadarstellung lässt sich bereits 0,1 nicht exakt abbilden (IEEE 754), und die Standardrundung dieser Darstellung rundet zur nächsten geraden Zahl statt kaufmännisch. Über einige hundert Positionen bleibt das unauffällig, über einen Jahresumsatz summiert es sich zu Differenzen, die in der Abstimmung mühsam zu finden sind. Ebenso wichtig ist die Reihenfolge: erst multiplizieren, dann runden. Wer Einzelpreise vorher rundet und danach mit der Menge multipliziert, erhält bei 1.000 Metern Kabel einen anderen Rechnungsbetrag als das ERP. Wie sich eine Anbindung verhält, wenn das führende System zeitweise nicht antwortet, behandelt der Beitrag zum Notbetrieb bei ERP-Ausfall.
Preisbezugsmenge und Grundpreis
Ein Preis ohne Bezugsmenge ist unvollständig. Kabel wird je Meter kalkuliert, Schrauben je 100 Stück, Reinigungsmittel je Liter, und im ERP steht dafür eine eigene Preisbezugsmenge. Der Katalogstandard führt sie als PRICE_QUANTITY (BMEcat) und trennt sie damit sauber von der Bestelleinheit. Wird dieses Feld beim Import ignoriert, entsteht der klassische Faktor-100-Fehler: Der Preis für 100 Stück landet als Stückpreis im Shop. Solche Fehler fallen selten sofort auf, weil sie plausibel aussehen, und sie betreffen selten alle Artikel, sondern genau die Warengruppe mit abweichender Bezugsmenge. Wie Preisdaten und Konditionen insgesamt sauber übertragen werden, beschreibt der Beitrag zur Synchronisation kundenindividueller Preise.
Davon zu trennen ist der Grundpreis als rechtliche Anforderung. Die Preisangabenverordnung verpflichtet dazu, gegenüber Verbrauchern neben dem Gesamtpreis auch den Preis je Mengeneinheit anzugeben (PAngV); als Mengeneinheit gilt dabei jeweils 1 Kilogramm, 1 Liter, 1 Kubikmeter, 1 Meter oder 1 Quadratmeter (PAngV). Für lose angebotene Ware sind je nach Verkehrsauffassung auch 100 Gramm oder 100 Milliliter zulässig (PAngV). Grundlage dieser Vorgaben ist die europäische Richtlinie über den Schutz der Verbraucher bei der Preisangabe (Richtlinie 98/6/EG). In einem reinen B2B-Shop mit geprüfter Gewerbekundenfreischaltung greift die Verordnung nicht; sobald derselbe Shop auch Verbraucher bedient, greift sie sehr wohl, und dann muss die Berechnung aus Nettogewicht und Preisbezugsmenge automatisch erfolgen statt in einem Textfeld.
Die Einheit ist ein Datenfeld, keine Beschriftung
Einheitenschlüssel über Systemgrenzen normieren
Jedes System schreibt Einheiten anders. Im ERP steht ST, im Shop Stk., im Katalog des Lieferanten Stück, in der EDI-Nachricht H87 und in einer alten Preisliste schlicht Stk. Solange nur Menschen lesen, funktioniert das; sobald zwei Systeme abgleichen, entstehen doppelte Artikel und fehlgeschlagene Buchungen. Die Lösung ist eine Normierung auf eine Codeliste, und dafür existiert eine etablierte: die dreistelligen Schlüssel der Empfehlung 20 mit KGM für Kilogramm, MTR für Meter, LTR für Liter und H87 für Stück (UNECE). Die europäische Norm für die elektronische Rechnung verlangt für die Mengeneinheit einer Rechnungsposition genau diese Codeliste (EN 16931), sodass sich die Normierung ohnehin lohnt, wenn die Pflicht zur elektronischen Rechnung ansteht.
Praktisch führt die Middleware eine Übersetzungstabelle mit drei Spalten: Quellsystem, Rohwert, normierter Schlüssel. Jeder unbekannte Rohwert landet in einem Protokoll statt in einer stillen Ersetzung, denn eine falsch geratene Einheit ist teurer als eine abgelehnte Zeile. Ergänzend gehört zu jeder Verpackungsebene eine eigene Artikelnummer: Die Vergaberegeln für Artikelnummern sehen vor, dass jede unterscheidbare Handelseinheit einen eigenen Schlüssel erhält (GS1), also Einzelstück, Karton und Palette jeweils einen. Wer diese Ebenen zusammenlegt, verliert genau die Information, die für die Umrechnung gebraucht wird. Eine solche Übersetzungstabelle ist ein typischer Baustein der Schnittstellenentwicklung und sollte versioniert werden wie Programmcode.
Retouren und Teillieferungen in gemischten Einheiten
Bestellt wird in Kartons, geliefert wird manchmal in Stücken. Ist ein Gebinde angebrochen oder kommt der Rest aus einem zweiten Lager, entsteht eine Teillieferung mit abweichender Einheit, und die Rückmeldung an den Shop muss beide Mengen führen: die offene Restmenge in der Bestelleinheit und die gelieferte Menge in der tatsächlich versandten Einheit. Dasselbe gilt für die Rücknahme. Wer 5 Kartons bestellt und 12 Einzelstücke zurücksendet, erzeugt eine Gutschrift über einen Karton und einen Anbruch, und das nur, wenn die Umrechnung an dieser Stelle ebenfalls greift. Der Beitrag zum Retourenprozess zwischen Shop und ERP beschreibt die Belegkette dazu; im Streckengeschäft mit Lieferantenanbindung kommt hinzu, dass der Lieferant seine eigenen Gebinde führt und die Umrechnung zweimal stattfindet, einmal zum Lieferanten und einmal zum Kunden.
Testfälle für typische Fehlbestellungen
- Bestellung unterhalb der Mindestmenge wird abgewiesen und nennt die zulässige Menge, statt kommentarlos zu scheitern.
- Eingabe einer nicht staffelkonformen Menge wird auf das nächste Vielfache aufgerundet und der Kunde sieht die Korrektur vor dem Absenden.
- Bestand von 1.542 Basiseinheiten bei Faktor 12 zeigt 128 Verkaufseinheiten, nicht 128,5 und nicht 129.
- Ein Artikel mit Preisbezugsmenge 100 erzeugt im Shop denselben Positionsbetrag wie im ERP, geprüft an einer Menge mit Nachkommastellen.
- Ein Gewichtsartikel meldet nach dem Versand das Ist-Gewicht zurück und die Rechnung weicht vom Auftrag ab, ohne dass die Position ihre Zuordnung verliert.
- Eine Änderung des Umrechnungsfaktors im ERP erreicht den Shop im nächsten Abgleich und wirkt sich nicht rückwirkend auf bereits erfasste Aufträge aus.
- Eine Teillieferung in abweichender Einheit lässt die Restmenge in der ursprünglichen Bestelleinheit stehen.
- Ein unbekannter Einheitenschlüssel aus einem Lieferantenkatalog wird protokolliert und blockiert den Import der betroffenen Zeile, statt still auf Stück zu wechseln.
- Ein Wechsel der Verkaufseinheit je Kundengruppe zeigt demselben Artikel Stück oder Karton, ohne dass sich der Bestand im ERP verändert.
Eine Menge ohne Einheit ist keine Angabe, sondern eine Vermutung. Erst der Faktor daneben macht aus beiden Zahlen eine Bestellung, die durch alle Systeme trägt.
Quellen und Studien