Bestellpreismengeneinheit und Preiseinheit erklärt

Kaum ein Einkäufer denkt an die Bestellpreismengeneinheit, bis eine Rechnung wegen eines Preises gesperrt wird, der nachweislich stimmt. Sie bestellen Kabel nach Rolle, der Lieferant bepreist es pro Meter; Sie kaufen Schrauben nach Karton, der Vertrag lautet auf tausend Stück. SAP hinterlegt beide Einheiten auf der Bestellposition und dazu einen Umrechnungsfaktor, und jede Rechnung wird gegen die abgeleitete Menge geprüft, nicht gegen die erfasste. Die Preiskondition bewegt sich nie, aber die Zahl, durch die SAP sie teilt, schon — die Sperre liest sich als Preisabweichung, obwohl die Ursache ein Einheitenkonflikt ist. Dieser Eintrag erklärt, was Bestellmengeneinheit, Bestellpreismengeneinheit und Preiseinheit jeweils tun, und warum ein falscher Faktor die Abweichung erzeugt, die niemand erwartet.

Was jedes Feld macht

Vier Felder auf der Bestellposition (Tabelle MEPOITEM / EKPO) entscheiden, wie der Preis eines Lieferanten gegen eine Rechnung geprüft wird. Die Bestellmengeneinheit (MEINS, Datenelement BSTME) ist die Einheit, in der Sie bestellen und den Wareneingang buchen. Die Bestellpreismengeneinheit (BPRME, Datenelement BBPRM) ist die Einheit, auf die der Lieferant seinen Preis bezieht. Häufig sind beide identisch — Sie bestellen in Stück und werden pro Stück bepreist —, doch ein Großhandelskatalog ist voller Fälle, in denen das nicht gilt: Draht pro Meter bepreist und nach Rolle geführt, Bolzen pro tausend bepreist und nach Karton bestellt, Blech pro Kilogramm bepreist und nach Platte geliefert.

Weichen die beiden Einheiten ab, muss SAP wissen, wie sie zusammenhängen. Das ist die Aufgabe des Umrechnungsfaktors: BPUMZ ist der Zähler, BPUMN der Nenner, die die Bestellpreismengeneinheit in die Bestellmengeneinheit umrechnen. Ein eigenes Feld, die Preiseinheit (PEINH, Datenelement EPEIN), hält die Menge fest, auf die der Preis selbst lautet — ein Preis von 42,00 „pro 100” trägt die Preiseinheit 100. Die vier Felder gehören zusammen: PEINH beziffert die Menge, BPRME benennt deren Einheit, MEINS benennt die Einheit Ihrer Bestellung, und BPUMZ/BPUMN schlägt die Brücke zwischen den beiden Einheiten. In der Regel werden sie aus dem Einkaufsinfosatz auf die Bestellposition übernommen, sodass ein Fehler im Infosatz still in jede Bestellung und von dort in jede Rechnung durchschlägt. Ist eine dieser Einstellungen falsch, rechnet SAP bei der Rechnungsprüfung falsch, selbst wenn der fakturierte Betrag exakt stimmt. Hier hört ein Mengeneinheiten-Konflikt auf, eine Fußnote der Datenpflege zu sein, und fängt an, Zahlungen zu sperren.

Warum die Bestellpreismengeneinheit die Rechnungsprüfung bricht

Der Fehler ist rechnerischer, nicht handwerklicher Art. SAP vergleicht den Stückpreis des Lieferanten nicht direkt mit Ihrem Vertragspreis. Es berechnet den Rechnungspreis als Rechnungsbetrag geteilt durch die Bestellpreismenge und vergleicht diesen dann mit dem Bestellnettopreis. Die Bestellpreismenge ist selbst abgeleitet — aus dem Umrechnungsfaktor mal der Rechnungsmenge —, sodass ein falsches BPUMZ/BPUMN den Nenner verschiebt, was den berechneten Rechnungspreis verschiebt, was die Preisprüfung auslöst. SAP sagt das im Langtext der Meldung M8 090 (Please check: order price quantity set automatically) klar: Das System leitet die Bestellpreismenge aus dem Bestell-Umrechnungsfaktor mal der Rechnungsmenge ab und setzt sie im Feld „Menge BPrME”. Der Kernsatz: eine geänderte Bestellpreismenge erzeugt eine Preisabweichung, weil der Rechnungspreis der Rechnungsbetrag geteilt durch die Bestellpreismenge ist. Die Meldung zeigt auf den Preis; die Ursache sind die Einheiten.

Ein Zahlenbeispiel macht es greifbar. Der Lieferant bepreist pro 1.000 Stück, auf der Bestellposition steht BPUMZ/BPUMN aber versehentlich auf 1/1. Die Rechnung über eine fakturierte Menge, die SAP mit diesem falschen Faktor in eine Bestellpreismenge umrechnet, ergibt einen Rechnungspreis — Betrag geteilt durch Bestellpreismenge —, der um den Faktor 1.000 danebenliegt. Der Betrag auf der Rechnung ist völlig korrekt, nur der Quotient nicht. Genau diesen Quotienten prüft SAP.

Weil die Abweichung berechnet ist, läuft sie nicht über den Preis-Toleranzschlüssel. Der Prozentvergleich hinter M8 091 (Quantity more than & % below order price quantity) und M8 092 (Order price quantity exceeded by more than & %) nutzt die eigenen Schlüssel BR (Rechnung vor Wareneingang) und BW (Wareneingang vor Rechnung) — nicht den Preisschlüssel PP. Die beiden Schlüssel existieren, weil die Vergleichsbasis davon abhängt, welches Dokument zuerst eintrifft: Kommt der Wareneingang zuerst, vergleicht SAP gegen die beim Wareneingang festgehaltene Bestellpreismenge; kommt die Rechnung zuerst, gegen die Rechnungsmenge mal dem Bestell-Umrechnungsfaktor. Darum klärt ein Aufweiten von PP eine Bestellpreismengen-Sperre nie: Sie lockern das falsche Tor, während das richtige weiter feuert. M8 092 sperrt mit dem Sperrgrund Bestellpreismengenabweichung. Das Ergebnis liest sich als Preisabweichung, ist aber keine.

Unsauber vs. vertrauenswürdig: dieselbe Rechnung, zwei Wege

Bestellpreismengeneinheit-Strategie: Welche Einheit wann prüfen

1. 1
   Meldungsnummer lesen, bevor Sie irgendetwas anfassen

   M8 082 / M8 083 (Preis zu hoch: Toleranzgrenze von & & wird überschritten bzw. & %) sind echte Preis-Toleranzverletzungen auf Schlüssel PP. Der Bereich M8 090–M8 092 ist eine Bestellpreismengen-Meldung. Beide verlangen entgegengesetzte Lösungen.

2. 2
   So nachrechnen, wie SAP es tut

   Teilen Sie den Rechnungsbetrag durch die Bestellpreismenge. Stimmt der Betrag, aber der Quotient nicht, ist die Bestellpreismenge — und der Faktor dahinter — der Fehler, nicht der Preis.

3. 3
   Die Einheiten gegeneinander prüfen

   Prüfen Sie BPRME gegen MEINS und den BPUMZ/BPUMN-Faktor gegen Materialstamm und Infosatz. Ein Einheiten- und Dimensionsumrechner bestätigt den Faktor in Sekunden, und ein UNECE-Rec-20-Einheitencode-Validator bestätigt, dass die Einheitenschlüssel auf gültige Standardcodes abbilden, damit Bestell- und Preiseinheit vergleichbar bleiben.

4. 4
   Den Faktor an der Quelle korrigieren, nicht die Toleranz

   Korrigieren Sie BPUMZ/BPUMN auf Bestellposition und Infosatz, damit die Bestellpreismenge richtig abgeleitet wird. Lassen Sie PP, BR und BW streng — sie tun ihre Arbeit.

5. 5
   Vor der nächsten Datei abfangen

   Vergleichen Sie die eingehende Preisliste mit der letzten über einen Preislisten-Vergleich, damit eine geänderte Einheit oder ein geänderter Faktor auffällt, bevor er je in eine Rechnung wandert — und bilden Sie Lieferanteneinheiten mit dem Playbook zur Attributabbildung auf ein Modell ab. Zeigt die Sperre in der Praxis auf eine Einheit, führt die deutsche Schwester-Guide SAP: Mengeneinheit nicht in Basismengeneinheit umrechenbar den verwandten Fall Schritt für Schritt durch; den gesamten Mechanismus über SAP, Dynamics 365 und Business Central beschreibt das englische Flaggschiff The Error Says Price. The Cause Is Units. (auf Englisch).

Related

FAQ

REVIEW-NOTES

• Genauigkeit. Jedes Feld (MEINS/BSTME, BPRME/BBPRM, BPUMZ, BPUMN, PEINH/EPEIN, Feld „Menge BPrME”/Quantity OPUn), jede Meldung (M8 082, M8 083, M8 090, M8 091, M8 092) und jeder Toleranzschlüssel (PP, BR, BW) stammt aus dem Brief-Appendix bzw. den vom Besteller verifizierten SAP-Daten. SAP-Ampersands sind verbatim erhalten (& & Betrag+Währung in M8 082; & % Prozent in M8 083/M8 091/M8 092); Kurztexte sind als Code gesetzt. Für M8 090/M8 091/M8 092 ist nur der englische Kurztext belegt und als solcher gesetzt; kein deutscher Kurztext dieser drei wird behauptet. Meldungstyp ist nicht als zwingender Fehler dargestellt. M8 081 wird nicht zitiert, daher kein SE91-Spot-Check für diese Datei.
• Related-Zusammensetzung. 6 Karten = 3 Glossar (preisabweichung DE, order-price-unit EN, unit-of-measure EN) + 2 Tools (unit-dimension-converter, price-list-diff) + 1 Playbook (map-supplier-attributes-to-schema), gemäß Template A (3+2+1).
• Aufgeschobener/live-broken Link. Die deutsche Schwester glossary/preisabweichung existiert noch nicht — sie erscheint nur als <Card> (nicht audit-geprüft), nicht als Inline-Link; die Build-Prüfung bleibt grün, der Kartenlink ist aber live broken, bis preisabweichung in der deutschen P1-Charge ausgeliefert wird. Beim finalen Cross-Link-Commit (Brief Workflow Schritt 6) prüfen und die Inline-Paarung Glossar↔Guide (order-price-unit ↔ sap-order-price-quantity-variance) sowie translations-Einträge setzen, sobald die Geschwister existieren.
• Inline-Links nur auf existierende Ziele (per Weisung): glossary/unit-of-measure, tools/unit-dimension-converter, tools/unit-code-validator, tools/price-list-diff, playbooks/map-supplier-attributes-to-schema, die deutsche Schwester-Guide guides/sap-mengeneinheit-nicht-umrechenbar (nativ, bevorzugt) und als englischer Fallback (gekennzeichnet) guides/error-says-price-cause-is-units. Drei Tool-Inline-Links vorhanden (≥2 erfüllt). Kein Inline-Link auf fehlende Geschwister.
• relatedSlugs weggelassen (audit-geprüftes Feld; nicht alle Related-Ziele existieren schon). translations nicht gesetzt (per Weisung).
• CTA lokalisiert über Shared-Code offen (SCHEMA-NOTES §4). resolveCta() ist derzeit hartkodiert englisch; cta: "learn-more" rendert noch „See how Claro handles this in production” / „Learn more”. Die geforderte deutsche Glossar-CTA (So löst Claro das in der Praxis / Mehr erfahren) braucht die in SCHEMA-NOTES §4 beschriebene Code-Änderung und ist vor dem Live-Gang zu entscheiden — kein frontmatter-seitiger Fix in dieser Datei möglich. Ziel (useCasePage → invoice-reconciliation) ist korrekt.