SAP Preisfindung: warum im Auftrag ein anderer Preis steht
Das System rät nicht. Es arbeitet ein Kalkulationsschema ab, geht je Konditionsart eine Zugriffsfolge durch und nimmt den ersten gültigen Konditionssatz. Wer diese Kette lesen kann, findet die Abweichung in Minuten statt in Tagen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Preis wird gesucht und nicht nachgeschlagen
Im Alltag klingt die Frage einfach: In der Preisliste steht ein Wert, im Auftrag steht ein anderer, also stimmt etwas nicht. Tatsächlich hat das System keine Preisliste gelesen, sondern eine Suche durchgeführt. SAP beschreibt das als Konditionstechnik, also als das Verfahren, mit dem Preise aus den Informationen in Konditionssätzen ermittelt werden. Die Beteiligten an dieser Suche sind das Kalkulationsschema, die einzelnen Konditionsarten, die daran hängenden Zugriffsfolgen, die Konditionstabellen und zuletzt die Konditionssätze selbst. Wer nur auf den Konditionssatz schaut, sieht das Ergebnis und nicht den Weg dorthin.
Deshalb gehen Klärungen so oft im Kreis. Der Vertrieb prüft den Konditionssatz, findet ihn korrekt gepflegt und gibt zurück, dass alles stimmt. Die Buchhaltung sieht in der Faktura trotzdem den anderen Wert. In Wahrheit war der geprüfte Satz nie im Spiel, weil ein früherer Zugriff der Zugriffsfolge bereits einen kundenspezifischen Satz gefunden hatte und die Suche an dieser Stelle beendet war. Das System nimmt nicht den besten oder den zuletzt gepflegten Satz, sondern den ersten, der zu einem Zugriff passt.
Der zweite große Block sind Änderungen von Hand. Eine Konditionsart, die im Kalkulationsschema als manuell änderbar geführt wird, lässt sich im Beleg überschreiben. Danach steht dort ein Wert, den keine Stammdatenpflege der Welt erklärt, und eine erneute Preisfindung setzt ihn je nach gewähltem Verfahren zurück oder eben nicht. Kommen Rabatte über Ausschlussgruppen dazu, wird es endgültig unübersichtlich, denn ausgeschlossene Konditionssätze verschwinden nicht aus dem Beleg, sie sind nur inaktiv gesetzt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Abweichungen, die im Vertrieb tatsächlich auflaufen
Sortiert nach dem, was du am Beleg siehst, nicht nach dem Customizing dahinter. Zu jedem Fall steht, an welcher Station der Kette er entsteht und was ihn dauerhaft erledigt.
Symptom
Im Auftrag steht ein niedrigerer Preis als in der gepflegten Preisliste, und der geprüfte Konditionssatz sieht korrekt aus.
Ursache
Die Zugriffsfolge hat einen spezifischeren Satz früher gefunden. Typisch ist ein kundenspezifischer Materialpreis, der vor dem allgemeinen Materialpreis abgefragt wird. Sobald ein Zugriff erfolgreich ist, endet die Suche für diese Konditionsart, alle weiteren Zugriffe werden nicht mehr ausgeführt.
Lösung
Ruf die Analyse an der Position auf und lies, welcher Zugriff getroffen hat und mit welchem Schlüssel. Wenn der frühere Satz nicht mehr gelten soll, gehört er befristet oder gelöscht, nicht der allgemeine Satz angepasst. Wer stattdessen die Reihenfolge im Customizing ändert, verschiebt das Problem auf alle anderen Kunden.
Symptom
Ein Konditionssatz ist gepflegt, taucht in der Analyse aber überhaupt nicht auf, auch nicht als erfolgloser Zugriff.
Ursache
Die zugehörige Konditionstabelle ist in der Zugriffsfolge dieser Konditionsart nicht enthalten, oder die Konditionsart selbst steht nicht im ermittelten Kalkulationsschema. Beides führt dazu, dass das System an dieser Stelle nie gesucht hat.
Lösung
Prüf zuerst, welches Kalkulationsschema der Beleg gezogen hat, und vergleich es mit der erwarteten Konditionsart. Fehlt sie dort, liegt die Ursache in der Schemaermittlung über Belegart und Kundenstamm. Fehlt nur der Zugriff, gehört die Konditionstabelle in die Zugriffsfolge aufgenommen, und zwar an der richtigen Stelle in der Reihenfolge.
Symptom
Der Zugriff erscheint in der Analyse als geprüft, aber ohne Treffer, obwohl der Satz sichtbar in der Konditionspflege steht.
Ursache
Mindestens ein Schlüsselfeld der Konditionstabelle stimmt nicht. Eine Konditionstabelle definiert die Feldkombination, die einen einzelnen Konditionssatz identifiziert, und diese Kombination muss vollständig passen. Zweiter häufiger Grund ist der Gültigkeitszeitraum, denn maßgeblich ist das Preisdatum des Belegs.
Lösung
Vergleich Feld für Feld den Suchschlüssel aus der Analyse mit den Werten im Konditionssatz. In der Praxis stolpert man über Vertriebsweg, Sparte oder die Preisliste im Kundenstamm. Wenn alles passt, schau auf das Preisdatum der Position und nicht auf das Tagesdatum.
Symptom
Der Preis war einmal richtig, hat sich nach einer Änderung am Beleg aber nicht mitgeändert oder plötzlich doch.
Ursache
Bei einer Änderung an einer Position wird die Preisfindung neu ausgeführt, und wie das geschieht, hängt vom gewählten Verfahren ab. Manche Verfahren behalten manuell eingegebene Konditionen bei, andere verwerfen sie und bauen die Kalkulation vollständig neu auf.
Lösung
Klär im Team eine feste Regel, welches Verfahren bei nachträglichen Preisänderungen verwendet wird, und halte sie schriftlich fest. Solange jeder ein anderes nimmt, sind zwei Belege mit derselben Historie nicht vergleichbar, und die Suche nach der Ursache beginnt jedes Mal von vorn.
Symptom
Der Kunde bekommt einen von zwei zustehenden Rabatten nicht, obwohl beide Konditionssätze im Beleg zu sehen sind.
Ursache
Es ist eine Konditionsausschlussgruppe im Spiel. Das System vergleicht konkurrierende Konditionssätze, wählt nach der eingestellten Methode aus, etwa den besten Preis für den Kunden, und schaltet die übrigen ab. Ausgeschlossene Sätze werden nicht aus dem Auftrag gelöscht, sondern nur deaktiviert.
Lösung
Erklär den Fachbereichen einmal, dass ein durchgestrichener oder inaktiver Satz kein Fehler ist, sondern eine bewusste Entscheidung des Schemas. Wenn beide Rabatte gemeinsam gelten sollen, ist nicht der Konditionssatz das Thema, sondern die Zuordnung der Ausschlussgruppe im Kalkulationsschema.
Symptom
Nach dem Umstieg auf SAP S/4HANA liefert ein eigener Report zur Konditionsauswertung keine Daten mehr.
Ursache
Das Ergebnis der Preisfindung lag in der Tabelle KONV. In SAP S/4HANA ist KONV in seiner Rolle als Datenablage durch die neue Tabelle PRCD_ELEMENTS ersetzt worden. KONV bleibt für die Datendeklaration bestehen und definiert weiterhin die Struktur des Preisfindungsergebnisses im Anwendungscode, der Inhalt wird bei der Umstellung nach PRCD_ELEMENTS übertragen.
Lösung
Stell lesende Zugriffe auf die neue Tabelle um. Der Nebeneffekt ist erfreulich: Weil das Ergebnis keine Cluster-Tabelle mehr ist, lässt es sich direkt auswerten. Prüf im selben Zug eigene Zugriffe auf die Felder VAKEY und VADAT, denn diese konkatenierten Felder wurden aus den Konditionskopftabellen einschließlich KONH entfernt.
Vom Beleg zum Preis, fünf Stationen in fester Reihenfolge
- 01 Verkaufsbelegart und Kundenstamm bestimmen das Kalkulationsschema.
- 02 Das Schema legt die Konditionsarten und ihre Rechenreihenfolge fest.
- 03 Jede Konditionsart hat eine Zugriffsfolge, die die Suchreihenfolge steuert.
- 04 Jeder Zugriff zeigt auf eine Konditionstabelle mit ihren Schlüsselfeldern.
- 05 Der erste gültige Konditionssatz liefert den Wert, danach hört die Suche auf.
Was du danach ohne Rückfrage an der Belegposition klärst
Die Analyse läuft immer in derselben Reihenfolge, und sie beginnt nicht bei den Stammdaten, sondern am Beleg. Sechs Schritte reichen, um von der Abweichung bis zur Ursache zu kommen, und sie funktionieren für Preise, Rabatte, Zuschläge und Frachten gleichermaßen.
Erst das Kalkulationsschema bestimmen
Das Schema legt fest, welche Konditionsarten überhaupt in Frage kommen und in welcher Reihenfolge sie gerechnet werden. Es wird aus Angaben der Verkaufsbelegart und des Kundenstamms ermittelt. Steht eine erwartete Konditionsart gar nicht im Schema, ist die Suche nach dem Konditionssatz vergebliche Mühe, denn das System hat nie danach gesucht.
Die Analyse im Beleg aufrufen statt zu raten
Zu jeder Position lässt sich die Preisfindung nachvollziehen. Dort steht je Konditionsart, welche Zugriffe geprüft wurden, welcher davon erfolgreich war und mit welchem Schlüssel gesucht wurde. Diese Anzeige beantwortet in einem Bild, wofür Rückfragen sonst zwei Tage brauchen.
Die Zugriffsfolge von oben nach unten lesen
Eine Zugriffsfolge steuert die Suchreihenfolge je Konditionsart und legt fest, wann das System aufhört zu suchen. Jeder Zugriff zeigt auf eine Konditionstabelle, und die Tabelle bestimmt über ihre Schlüsselfelder, wonach gesucht wird. Der erste Treffer gewinnt, spätere Zugriffe kommen nicht mehr zum Zug.
Den Schlüssel der Konditionstabelle mit dem Beleg abgleichen
Eine Konditionstabelle definiert die Feldkombination, die einen einzelnen Konditionssatz identifiziert, etwa Verkaufsorganisation, Vertriebsweg, Kunde und Material. Weicht auch nur eines dieser Felder im Beleg vom gepflegten Satz ab, greift der Zugriff nicht. Das ist die häufigste Ursache für einen Satz, den es gibt und der trotzdem nicht wirkt.
Gültigkeit und Staffel prüfen, bevor du Customizing anfasst
Ein Konditionssatz gilt in einem Zeitraum, und maßgeblich ist das Preisdatum des Belegs, nicht das heutige Datum. Existiert eine Staffel, rechnet das System den passenden Wert zur Belegmenge aus. Eine Position, die knapp über einer Staffelgrenze liegt, bekommt damit einen anderen Preis als eine knapp darunter, und genau dieser Sprung erklärt viele scheinbar willkürliche Abweichungen.
Manuelle Eingriffe und Ausschlüsse sichtbar machen
Manuell gesetzte oder überschriebene Konditionen sind im Beleg gekennzeichnet. Kommen Konditionsausschlussgruppen zum Einsatz, vergleicht das System konkurrierende Sätze und deaktiviert die unterlegenen. Diese Sätze werden nicht aus dem Beleg gelöscht, sondern nur inaktiv gesetzt, sie sind also weiterhin sichtbar und stiften ohne diese Kenntnis Verwirrung.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was die Konditionstechnik eigentlich ist
SAP nennt Konditionstechnik das Verfahren, mit dem das System Preise aus den Informationen in Konditionssätzen ermittelt. Die Stammdaten sind dabei die Konditionssätze, gespeichert werden sie in Konditionstabellen, und für die Ermittlung sorgen drei Elemente: das Kalkulationsschema, die Konditionsart und die Zugriffsfolge. Diese Aufteilung wirkt zunächst umständlich, sie ist aber der Grund, warum sich in SAP fast jede Preislogik abbilden lässt, ohne eine Zeile Code zu schreiben.
Der Ablauf im Verkaufsbeleg ist immer derselbe. Das System bestimmt das Kalkulationsschema aus Angaben der Verkaufsbelegart und des Kundenstamms. Das Schema definiert die gültigen Konditionsarten und die Reihenfolge, in der sie im Auftrag erscheinen. Für die erste Konditionsart beginnt die Suche nach einem gültigen Konditionssatz, gesteuert über die Zugriffsfolge, die dieser Konditionsart zugeordnet ist. Das System prüft die Zugriffe, bis es einen gültigen Satz findet, und die Zugriffsfolge legt außerdem fest, wann die Suche abgebrochen wird.
Danach wiederholt sich das für jede weitere Konditionsart im Schema, bis am Ende der Nettowert steht. Zuschläge, Rabatte, Frachten, Skonti und Bonusvereinbarungen sind alle nichts anderes als weitere Konditionsarten in derselben Kette. Das ist die eigentliche gute Nachricht: Wer den Mechanismus einmal für den Grundpreis verstanden hat, versteht ihn für alle Bestandteile der Kalkulation.
Konditionstabellen, Feldkatalog und der Schlüssel, auf den es ankommt
Eine Konditionstabelle definiert die Feldkombination, also den Schlüssel, der einen einzelnen Konditionssatz identifiziert. Das Standardsystem bringt vordefinierte Tabellen mit, und jeder Zugriff in einer Zugriffsfolge zeigt auf genau eine davon. Ein klassisches Beispiel ist die Tabelle für kundenspezifische Materialpreise mit den Feldern Verkaufsorganisation, Vertriebsweg, Kunde und Material. Die ersten beiden Felder bilden die organisatorische Zuordnung ab, die letzten beiden die Beziehung zwischen Kunde und Material.
Die Felder, die für einen Schlüssel zur Verfügung stehen, kommen aus dem Feldkatalog. Ausgewählte Felder bilden den Schlüssel, erlaubte Felder sind die Menge, aus der ausgewählt werden darf. Wer eine eigene Konditionstabelle anlegt, entscheidet damit über zwei Dinge zugleich: über die Genauigkeit, mit der Preise gepflegt werden können, und über die Menge an Sätzen, die später gepflegt werden muss. Beides zieht Folgekosten nach sich, die man am besten vor der Anlage bespricht.
In SAP S/4HANA hat SAP an dieser Stelle die Grenzen erweitert. Die Zahl der möglichen kundeneigenen Konditionstabellen für die Preisfindung wurde nach SAP-Angaben ungefähr verdoppelt, die Zahl der möglichen Zugriffe in einer Zugriffsfolge stieg von 99 auf 999, und der Schlüssel der Konditionstabellen kann jetzt 255 Zeichen lang sein statt bisher 100. Für bestehende Systeme ändert das nichts am Verständnis, es nimmt aber der Diskussion über zu enge Grenzen den Anlass.
Was sich mit SAP S/4HANA am Datenmodell geändert hat
Die wichtigste Änderung betrifft die Ablage des Preisfindungsergebnisses. Im klassischen SAP ERP lag es in der Tabelle KONV. In SAP S/4HANA ist KONV in seiner Rolle als Datenablage durch die neue Tabelle PRCD_ELEMENTS ersetzt. KONV existiert weiter und definiert nach wie vor die Struktur des Preisfindungsergebnisses im Anwendungscode, der Inhalt wird bei der Umstellung automatisch übertragen. Für Fachbereiche ändert sich dadurch nichts, für jeden eigenen Report und jede eigene Schnittstelle sehr wohl.
Der zweite Punkt betrifft die Konditionskopftabellen. Das konkatenierte Feld VAKEY wurde aus allen Konditionskopftabellen entfernt, einschließlich KONH für die Preisfindung, ebenso das konkatenierte Datenfeld VADAT. Für die interne Verarbeitung gibt es lange Datenelemente, und der Inhalt lässt sich zur Laufzeit über Methoden einer Serviceklasse ermitteln. Wer eigene Programme betreibt, die diese Felder direkt gelesen haben, findet sie in der Prüfung des kundeneigenen Codes wieder.
Der Nutzen dieser Umstellung ist eine Nebenwirkung, die im Alltag mehr wert ist als die technische Änderung selbst. Weil das Preisfindungsergebnis keine Cluster-Tabelle mehr ist, lässt es sich direkt für Auswertungen lesen. Fragen wie die nach dem durchschnittlich gewährten Rabatt je Kundengruppe waren vorher ein Projekt und sind jetzt eine Abfrage. Wenn im Haus ohnehin über die Umstellung diskutiert wird, gehört dieser Punkt auf die Habenseite.
Wie ihr das Thema dauerhaft aus der Klärungsschleife holt
Der wirksamste Hebel ist nicht technisch. Klärt einmal verbindlich, wer Konditionssätze anlegen darf und auf welcher Ebene. Wenn Vertrieb, Innendienst und Key User alle kundenspezifische Sätze pflegen dürfen, entsteht innerhalb weniger Monate ein Bestand, den niemand mehr überblickt, und jede Abweichung wird zur Einzelfallrecherche. Eine kurze Vereinbarung darüber, welche Ebenen bewusst genutzt werden und welche nicht, spart mehr Zeit als jedes Werkzeug.
Zweitens gehört die Analysefunktion im Beleg in die Einarbeitung jedes neuen Kollegen im Innendienst. Sie ist kein Werkzeug für die IT, sondern die Standardantwort auf die Frage, warum ein Preis so ist, wie er ist. Ein Fachbereich, der sie kennt, stellt an die IT deutlich präzisere Fragen, und die Fälle, die dann noch übrig bleiben, sind meistens echte Customizing-Themen.
Drittens lohnt eine regelmäßige Sichtung der Konditionssätze mit abgelaufener oder sehr weit in der Zukunft liegender Gültigkeit. Konditionsindizes helfen dabei, denn mit ihnen lassen sich Konditionssätze über mehrere Konditionsarten und Tabellen hinweg anzeigen, ändern und mit Bezug anlegen. Ein Index muss dafür angelegt, generiert und aktiviert sein, das ist eine einmalige Einrichtung mit dauerhaftem Nutzen.
Dazu passende Kurse
Wenn im Innendienst regelmäßig geraten wird, warum ein Preis so zustande kommt, sind SAP-Kurse für Vertrieb und Preisfindung der kürzere Weg als die nächste Klärungsrunde.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Warum nimmt das System nicht einfach den günstigsten Preis für den Kunden?
Der Konditionssatz ist gepflegt, wirkt aber nicht. Woran liegt das meistens?
Was ist der Unterschied zwischen Konditionsart und Konditionssatz?
Gilt dieselbe Mechanik auch im Einkauf?
Brauchen wir für jede Rabattvariante eine eigene Konditionstabelle?
Quellen
- SAP Help Portal, Konditionstechnik und Preisfindung in SAP S/4HANA
- SAP Help Portal, Pricing and Conditions, Ablauf der Konditionstechnik im Verkaufsbeleg
- SAP Help Portal, Condition Tables, Aufbau des Konditionsschlüssels
- SAP Simplification List für SAP S/4HANA 2025 FPS01, Abschnitt Data Model Changes in SD Pricing
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Konditionstechnik einmal am eigenen System durchgehen
Bei cmt baust du im SD-Kurs zur Preisfindung Konditionstabellen, Zugriffsfolgen und Konditionsarten selbst auf und liest die Analyse an echten Belegen, statt sie im Ernstfall zum ersten Mal zu sehen.