Wie handhaben Sie Mengenrabatte, die sich nach Region und Produkt unterscheiden?

01Das Geschäftsproblem

Ein Hersteller verkauft einen großen Katalog über regionale Distributoren. Drei Dinge variieren gleichzeitig, und sie greifen ineinander:

• Region. Derselbe Artikel kostet in zwei Gebieten unterschiedlich viel, und die beiden Regionen führen keinen identischen Katalog.
• Menge. Wer zehn kauft, zahlt einen Preis; wer hundert kauft, zahlt einen anderen. Der Staffelplan ist nicht einheitlich – er unterscheidet sich pro Produkt.
• Ausnahmen. Manche Artikel haben überhaupt keinen Listenpreis. Sie werden nur auf Anfrage angeboten, und welche das sind, variiert je nach Region.

Ein Distributor, der ein Angebot erstellt, sollte die richtige Zahl erhalten, ohne irgendetwas davon zu wissen. Und wenn die jährliche Preisaktualisierung ansteht, muss sie ein Datenimport sein – kein Projekt.

Dieser letzte Satz ist die Anforderung, die stillschweigend das gesamte Design bestimmt, und meist ist es genau die, die niemand ausspricht.

02Warum der naheliegende Ansatz scheitert

Eine Preisliste pro Region und Mengenstaffel

Sobald man weiß, dass eine Preisliste regionale Preise liefert, liegt es nahe, mehr davon anzulegen: Europa 10–49, Europa 50–99, Europa 100+, und dasselbe noch einmal für jede andere Region. Das scheitert aus einem strukturellen, nicht kosmetischen Grund:

Die Wartungsrechnung ist das zweite Problem, und es verschärft sich. Weil eine Liste unter fast jeder Bedingung verfügbar gemacht werden kann, sammeln sich in einem echten Katalog meist einige an – Gebiet, Vertriebskanal, ein paar ausgehandelte Vereinbarungen. Multiplizieren Sie diese Zahl, wie hoch sie auch sein mag, mit den Staffeln: Bei einem Katalog mit 1.637 Produkten ergeben zwei Regionen mal vier Staffeln bereits acht Listen und über zehntausend Preiszeilen, die bei jeder Neubepreisung untereinander konsistent gehalten werden müssen. Außerdem wird das Dropdown so zu einer Liste nahezu identischer Namen, aus der ein Distributor jedes Mal richtig wählen muss.

Absolute Staffelpreise speichern

Wo auch immer die Staffeln am Ende liegen, der Reflex ist, den Staffelpreis zu speichern – weil die Quelltabelle genau das enthält. Das macht jede künftige Preisänderung zu einem Neuaufbau: Der Listenpreis bewegt sich, und jede Staffel dieses Produkts muss neu berechnet und neu eingegeben werden. In der Praxis geschieht das nicht, und die Staffeln beschreiben unbemerkt die Preise des Vorjahres.

Speichern Sie stattdessen den Prozentsatz. Der Listenpreis bewegt sich, die Staffel folgt automatisch, und die jährliche Aktualisierung ist ein Import in eine Preisliste.

Das Unbepreisbare mit null bepreisen

Artikel, die nur auf Anfrage angeboten werden, haben keinen Preis, und die verlockende Abkürzung ist eine Preiszeile mit 0. Eine Null ist eine Zahl: Sie fließt in die Positionssumme, in den Angebotswert, in die Prognose, und sie sieht auf dem ganzen Weg völlig legitim aus. Die Zeile stattdessen wegzulassen ist besser, reicht aber immer noch nicht, weil sich eine fehlende Preiszeile nicht von einer unterscheiden lässt, die noch niemand konfiguriert hat – und bei einem Katalog dieser Größe fehlen viele schlicht.

Ein Rabatt auf das gesamte Angebot

Es gibt einen nativen Rabatt auf Angebotsebene, sowohl als Prozentsatz als auch als Betrag. Er ist das richtige Werkzeug für ein ausgehandeltes Zugeständnis bei einem Deal und das falsche hier, weil er nicht ausdrücken kann, dass diese Position sich für eine Mengenstaffel qualifiziert und jene nicht. Mengenpreise sind eine Eigenschaft jeder einzelnen Position.

03Datenmodell

Vier Belange, vier verschiedene Orte. Das Fundament behandelt Blueprint 007 – ein Produkt trägt keinen Preis; der Preis liegt auf einer Verknüpfungszeile zwischen dem Produkt und einer Preisliste –, und alles hier baut darauf auf. Dieses Beispiel bepreist nach Region, aber am Mechanismus ist nichts regional: Lesen Sie „Region“ im Folgenden als „die Dimension, die Ihre Preislisten trennt“. Der Artikel Price lists des Coevera-Hilfecenters gibt nur einen Überblick über die Listen und ist nicht die Quelle für ihre Verfügbarkeitsregeln; die Rabattschicht unten ist dort nicht dokumentiert, und deshalb wird sie modelliert.

Die Preislistenzeile ist die ganze Einschränkung

Eine Preislistenzeile besteht aus einem Produkt, einer Preisliste, einer Währung, einem Preis – und einem Einstellungsobjekt, dessen vollständiger Inhalt eine Zugriffsstufe und eine optionale Rollenliste ist. Es gibt keine Mindestmenge, kein Maximum, keine Staffelsammlung, keine Staffeltabelle. Eine Zeile, ein Preis. Jede Designentscheidung unten folgt aus dieser einen Tatsache.

Drei regionale Tatsachen, die nicht dieselbe Tatsache sind

Die Ausnahmebehandlung funktioniert erst, wenn Sie bemerken, dass diese drei verschieden sind, denn wer zwei davon vermischt, erzeugt unbemerkt falsche Zahlen:

Die dritte existiert genau dafür, die zweite eindeutig zu machen. Mit ihr ist eine fehlende Zeile plus ein nicht angehaktes Kästchen ein Datenqualitätsalarm; ohne sie ist derselbe Zustand unsichtbar.

Die Form, die sich in einem echten Katalog ergab

Rund ein Viertel aller regionalen Listungen hat bewusst keinen Preis. Dieser Anteil ist der Grund, warum der Ausnahmemechanismus hier kein Randfall ist – er ist ein vollwertiger Bestandteil des Modells.

04Konfiguration auf Feldebene

Wissenswerte Eigenschaften einer Preisliste

Wie eine Preisliste verfügbar wird

Der rules-Filter ist genauso aufgebaut wie Filter an anderen Stellen der Plattform: ein Aktivierungskennzeichen, ein Gruppenoperator, eine Haupt-Filterbox, die eine Entität nennt, und Geschwister-Boxen für verknüpfte Entitäten. In einer funktionierenden Konfiguration mit zwei Regionen trägt jede Liste:

• isEnabled: true, Operator And;
• eine Hauptbox auf Opportunity ohne Bedingungen;
• eine Geschwister-Box auf Quote mit genau einer Bedingung – ein Region-Dropdown, Operator Is, passend zur eigenen Regionsoption dieser Liste.

Beide Listen filtern dasselbe Feld und beanspruchen jeweils eine andere Option davon, sodass das Setzen der Region am Quote das Dropdown auf eine sinnvolle Auswahl eingrenzt. Die Liste, die der Benutzer dann wählt, wird am Quote in einer nativen Preislisten-Relation festgehalten, sodass das Angebot dauerhaft dokumentiert, aus welchen Preisen es erstellt wurde.

Regional ist daran übrigens auch nichts – ein Regions-Dropdown ist schlicht das, worauf dieser Katalog zufällig filterte. Die Feldauswahl für Bedingungen bietet Quote, Opportunity und Account an, sodass die Verfügbarkeit an einer Account-Stufe, einer Vertragsart, einem Partner-Kennzeichen oder einem Opportunity-Attribut hängen kann. Diese drei Entitäten sind der gesamte Geltungsbereich: Die Regel reicht nicht darüber hinaus.

Und von allem, was sie prüfen kann, fehlt die Menge – die Menge gehört zur Position, und kein Datensatz, den der Filter auswertet, trägt sie. Das ist der ganze Grund, warum Mengenpreise nicht in einer Preisliste leben können, und es ist der Angelpunkt, um den sich der Rest dieses Blueprints dreht.

Was passiert, wenn eine Liste gewählt wird

• Vor der Auswahl: Der Bereich zeigt „Without price list“, und jedes hinzugefügte Produkt landet bei einem Preis von null.
• Nach der Auswahl: Neu hinzugefügte Produkte übernehmen ihren Preis aus dieser Liste.
• Bei der Auswahl: Die Oberfläche fragt, ob die bereits am Datensatz vorhandenen Positionen aus der neu gewählten Liste neu bepreist werden sollen – ein Listenwechsel mitten im Angebot ist also eine abgefragte Aktion, keine stillschweigende Neuberechnung.

Der Bereich hat außerdem eine eigene Währungsauswahl und einen Schalter für die Produktsynchronisierung, und es gibt ihn nur an Opportunity und Quote. Jeder Workflow, der bepreiste Positionen an einer anderen Entität braucht, muss über eine dieser beiden laufen.

Der Rabattplan am Produkt

Sechs ganzzahlige Felder – drei Staffeln, zwei Regionen:

Zwei Eigenschaften dieses Aufbaus sind bewusst gewählt, und eine ist ein Preis, den Sie in Kauf nehmen:

• Pro Produkt, nicht global. Der Plan ist ein Produktattribut, sodass ein Produkt ohne Mengenstaffel einfach leere Felder hat – keine Ausnahmeliste nötig.
• Prozentsätze, keine Preise. Eine Neubepreisung ist ein Import in die Preisliste und sonst nichts. Der Plan muss nie angefasst werden.
• Die Staffelgrenzen stecken in den Feldnamen – was bedeutet, dass sie Schema sind, keine Daten. 50–99 in 50–149 zu ändern ist eine Feldumbenennung plus eine Migration, dazu jeder Bericht, jedes Formular und jeder Prozess, der darauf verweist. §6 kommt darauf zurück.

An der Position

Die Position trägt nativ quantity, price, amount, discount_percentage und discount_value. Eine funktionierende Konfiguration ergänzt ein benutzerdefiniertes Feld, einen Netto-Stückpreis, damit der rabattierte Betrag explizit gespeichert und nicht später aus den anderen Werten erschlossen wird.

Ein praktischer Hinweis, der an diesem Feld beobachtet wurde: Seine Bezeichnung und sein api_name waren auseinandergelaufen – der API-Name trug noch ein Regionssuffix aus einem früheren Design, das die Bezeichnung nicht mehr erwähnt. Bezeichnungen lassen sich bearbeiten, und an API-Namen binden sich Integrationen, Importe und Prozessvorlagen – der API-Name, mit dem Sie ein Feld anlegen, ist also der, mit dem Sie leben. Benennen Sie es nach dem, was es ist, nicht nach dem Ort, an dem es zuerst verwendet wurde.

05Automatisierung & Logik

Was berechnet werden muss

Alles oben ist Datenmodell. Das eine Stück Logik lautet: Aus der Menge einer Position und der Region des Quotes die richtige Staffel finden und anwenden. Der Reihe nach – die Menge aus der Position lesen; das Staffelfeld wählen, das zur Region des Quotes passt; wenn es einen Prozentsatz enthält, diesen in den Rabattprozentsatz der Position schreiben oder den Netto-Stückpreis berechnen und schreiben.

Warum dies ein einziger Prozess ist

Die meisten Automatisierungen auf dieser Plattform zerfallen in mehrere Prozesse, weil ein Prozess einen einzigen Filter trägt, dessen Zweige nach dem Prinzip „der erste Treffer gewinnt“ ausgewertet werden, und unabhängige Bedingungen ihn daher nicht teilen können – die Einschränkung hinter Blueprint 011.

Mengenstaffeln sind der umgekehrte Fall. Sie schließen sich gegenseitig aus: Eine Position mit 60 Stück liegt in genau einer Staffel. „Der erste Treffer gewinnt“ ist hier also kein Hindernis, sondern genau die gewünschte Semantik, und ein Filter, dessen Zweige von der größten Staffel abwärts geordnet sind, ist die richtige und vollständige Form. Ordnen Sie sie absteigend, und der erste Treffer ist immer der richtige.

Der Ausnahmezweig, den man leicht vergisst

Ein Produkt mit „Preis auf Anfrage“ darf nicht unbemerkt eine Staffel erhalten – es hat keinen Listenpreis, auf den sich ein Rabatt beziehen könnte. Der Staffelfilter braucht einen vorgelagerten Zweig auf das Kennzeichen „Preis auf Anfrage“, der die Position stattdessen an einen Menschen weiterleitet. Ohne ihn zieht ein Artikel, der nur auf Anfrage angeboten wird, bei einer großen Position unbemerkt einen Prozentsatz von einem Preis ab, der nicht existiert.

Vorrang, der entschieden und nicht entdeckt werden muss

Das Quote hat außerdem einen nativen Rabatt auf das gesamte Angebot. Sobald eine Position eine Mengenstaffel trägt, sind zwei Rabatte im Spiel, und nichts in der Plattform entscheidet, ob sie sich addieren, ob der größere gewinnt oder ob ein ausgehandelter Angebotsrabatt den Staffelplan ersetzt. Entscheiden Sie es, schreiben Sie es in den Prozess, und nehmen Sie es in die Angebotsvorlage auf – sonst beantwortet es jeder Distributor anders, und das Margen-Reporting ist bedeutungslos.

Was die Preisliste für Sie tut und was nicht

Die Verfügbarkeitsregel entscheidet, welche Listen angeboten werden – sie bepreist nichts. Erst dass ein Mensch eine Liste auswählt, bepreist neue Positionen in der Oberfläche, und Blueprint 007 dokumentiert das Gegenstück auf dem API-Weg: Eine ohne expliziten Preis angelegte Position landet bei null, unabhängig davon, was das Produkt auf irgendeiner Liste kostet. Beide Wege laufen auf denselben Fehler hinaus, also muss jeder Import, jede Integration und jede Automatisierung, die Positionen erstellt, den Preis selbst setzen.

06Grenzen & Kompromisse

• Staffelgrenzen sind Schema. Weil jede Staffel ein Feld ist, sind die Grenzen in Feldnamen und Formulare eingebaut. Eine Staffel hinzuzufügen oder eine Grenze zu verschieben ist eine Feldänderung, eine Datenmigration und eine Anpassung von allem, was darauf verweist – keine Konfigurationsänderung. Wählen Sie die Staffeln in der Erwartung, dass sie mehrere Preislisten überdauern.
• Alle Preislisten müssen sich eine Staffelstruktur teilen. Ein Katalog, der mit fünf Staffeln unter einer Liste und drei unter einer anderen ankommt, lässt sich nicht getreu abbilden: Entweder Sie normalisieren auf die gemeinsamen Staffeln und verlieren die feinere Granularität, oder Sie vervielfachen die Felder pro Liste, und das Produktformular wird unbrauchbar. Das Live-Modell wählte die erste Option und verwarf zwei Staffeln für kleine Mengen, die nur in einer Region existierten. Beachten Sie die Asymmetrie – die Auswahl skaliert frei mit neuen Listen, der Rabattplan nicht.
• Die Menge kann nie eine Preisliste erreichen. Die Verfügbarkeitsregel wertet Felder am Quote, an der Opportunity und am Account aus; die Menge ist eine Eigenschaft der Position. Fast jede andere Dimension steht Ihnen offen – diese nicht, und das ist der strukturelle Grund, warum der ganze Ansatz am Produkt lebt und nicht in der Preisliste.
• Null ist der Standardfall, nicht die Ausnahme. Der Bereich öffnet mit „Without price list“, sodass ein Datensatz, dessen Ersteller das Dropdown nie angefasst hat, jede Position mit null bepreist und fertig aussieht. Keine Regel verhindert das, weil Regeln nur entscheiden, was das Dropdown anbietet. Wo Angebote wichtig sind, behandeln Sie „Positionen ohne Preisliste gespeichert“ als Validierungsfehler und fangen Sie ihn bewusst ab.
• Überlappende Verfügbarkeitsregeln erzeugen eine Wahl, keine Auflösung. Mehrere Listen können gleichzeitig gültig sein, sodass Regeln, die beide zutreffen, den Benutzer ohne Orientierung vor zwei plausible Optionen stellen – und eine erneute Auswahl fragt, ob alles bereits am Datensatz Vorhandene neu bepreist werden soll. Schreiben Sie die Regeln so, dass sie sich gegenseitig ausschließen.
• Eine fehlende Preiszeile ist mehrdeutig, solange Sie das nicht ändern. Ihr Fehlen bedeutet „nur auf Anfrage“ oder „nicht konfiguriert“, und die Plattform kann Ihnen nicht sagen, was davon zutrifft. Das Kennzeichen trennt beides – und es muss von dem gepflegt werden, was auch immer den Katalog lädt, sonst verfällt es in dieselbe Mehrdeutigkeit.
• Zwei Rabatte können für eine Position gelten, und nichts schlichtet. Die Staffel auf Positionsebene und der Rabatt auf Angebotsebene bestehen ohne definierten Vorrang nebeneinander.
• Geplante Preislisten wurden nicht erprobt. Typ, Status und Datumsgrenzen sind im Schema verifiziert, aber nicht im Verhalten – wie eine Scheduled-Liste zu Active wird und was mit Angeboten geschieht, die auf eine Expired-Liste verweisen, wurde nicht beobachtet.
• Die Position hält keine Preisherkunft fest, siehe Blueprint 007. Das Quote hält fest, welche Liste es verwendet hat; die einzelne Position hält nicht fest, aus welcher Preiszeile sie stammt, sodass sich eine spätere Preisänderung nicht zu den Angeboten zurückverfolgen lässt, die sie verändert hätte.
• Ein API-Name ist in der Praxis dauerhaft, eine Bezeichnung nicht. Sie laufen auseinander, und an den API-Namen bindet sich jede Integration.

Der Kompromiss, den man klar benennen sollte

Den Plan als Prozentsätze am Produkt abzulegen bringt das, was über eine mehrjährige Lebensdauer am meisten zählt: Die jährliche Neubepreisung bleibt ein Datenimport. Neue Preise werden in die Preisliste importiert, und Rabattplan, Ausnahmekennzeichen und Automatisierung bleiben alle unberührt. Der Preis dafür ist, dass Staffelgrenzen zu Schema werden, eine Struktur jeder Region dienen muss und die Berechnung ein Eigenbau statt einer Einstellung ist. Für einen Katalog im Tausenderbereich, der jährlich neu bepreist wird, ist das ein guter Tausch. Für eine Handvoll Produkte mit individuellen Staffeln pro Kunde ist es völlig die falsche Form – das sind Vertragspreise, und die gehören in eine Preisliste pro Kunde, also in das Gebiet von Blueprint 007 und nicht in dieses hier.

07Verifizierung

Am 2026-09-16 aus einem Live-Space ausgelesen, der einen vollständig importierten Distributorenkatalog für zwei Regionen enthält.

• Die Einschränkung wurde auf Schemaebene bestätigt: Das Einstellungsobjekt einer Preislistenzeile stellt genau zwei Eigenschaften bereit, ein Zugriffs-Enum und eine Rollenliste. Nirgendwo an der Preisliste oder ihren Zeilen existiert eine Eigenschaft für Menge, Staffel oder Mengensprung.
• Katalog und Preiszeilen stimmen exakt überein. 1.637 Produkte; 788 Preiszeilen in einer Region, 1.193 in der anderen. Gegen die Quelldateien – 1.158 und 1.532 regionale Listungen, von denen 370 und 339 als „nur auf Anfrage“ markiert waren – lassen sich beide Zahlen genau nachvollziehen: 1.158 − 370 = 788 und 1.532 − 339 = 1.193. Die Listungen, die nur auf Anfrage angeboten werden, tragen ein Kennzeichen „Preis auf Anfrage“ und keine Preiszeile, und genau das bestätigen diese beiden Subtraktionen.
• Die Verfügbarkeitsregeln wurden vollständig gelesen, an beiden aktiven Listen, die gleichzeitig gültig waren: aktiviert, Operator And, eine leere Hauptbox auf Opportunity und eine Geschwister-Box auf Quote mit einer einzigen Is-Bedingung gegen ein Dropdown – dasselbe Feld auf beiden Listen, jede mit einer anderen Option. Die Regel ist ein gewöhnlicher Feldfilter; dass das Dropdown eine Region enthält, ist also eine Eigenschaft dieses Katalogs und nicht des Mechanismus.
• Die Eigenschaften der Preislisten – Typ Standard/Scheduled, der Status mit vier Werten, Start- und Enddatum, die einen Preiszeitraum begrenzen, und eine inaktive mitgelieferte Standardliste, die noch Zeilen aus der Produktanlage enthält – wurden aus den Live-Datensätzen gelesen.
• Der Rabattplan wurde aus dem Produktschema gelesen: sechs ganzzahlige Prozentfelder, drei Staffeln über zwei Regionen, dazu zwei regionale Checkboxen für „Preis auf Anfrage“ und ein Mehrfachauswahl-Feld für die Verfügbarkeit.
• Die Felder der Position wurden gelesen, darunter die nativen Felder für Menge, Preis, Betrag, Rabattprozentsatz und Rabattwert sowie ein benutzerdefiniertes Feld für den Netto-Stückpreis, dessen Bezeichnung und API-Name auseinandergelaufen sind.

Nicht beobachtet, und ausdrücklich so benannt:

• Die Staffelberechnung. Kein Prozess im Space berechnet einen Mengenrabatt. Das Modell ist befüllt; die Logik ist nicht gebaut. Das Design in §5 ist das, was die Bausteine hergeben, nicht etwas, das beim Funktionieren beobachtet wurde.
• Das Verhalten geplanter Preislisten – Aktivierung, Ablauf und die Auswirkung auf Datensätze, die bereits auf eine Liste verweisen.
• Ob sich ein Rabatt auf Positionsebene und ein Rabatt auf Angebotsebene verrechnen, und in welcher Reihenfolge.
• Ob das Preislisten-Dropdown und die Abfrage zur Neubepreisung ein Gegenstück auf dem API-Weg haben, wo eine ohne Preis angelegte Position einfach bei null landet.

Woran Sie eine Regression erkennen

• Positionen, die bei einem Preis von null landen. Der mit Abstand wahrscheinlichste Fehler, und er sieht bis in die Prognose hinein wie eine echte Zahl aus. Prüfen Sie jeden Import und jede Automatisierung, die Positionen anlegt, ohne explizit einen Preis zu setzen.
• Nach einer Neubepreisung mehr Preiszeilen als regionale Listungen. Das bedeutet, dass der Import Zeilen für Produkte angelegt hat, die nur auf Anfrage angeboten werden, und diese Produkte erhalten nun unbemerkt Mengenstaffeln auf einen Preis, den es nicht geben sollte.
• Datensätze mit Positionen, aber ohne festgehaltene Preisliste. Niemand hat das Dropdown von „Without price list“ weggestellt, also steht jede Position bei null. Das ist der Standardzustand, kein seltener Fehler, und gehört deshalb in die Validierung statt in eine monatliche Überprüfung.
• Ein befülltes Staffelfeld an einem Produkt, dessen Kennzeichen „Preis auf Anfrage“ angehakt ist. Ein Widerspruch in den Daten, den der Ausnahmezweig in §5 abfangen soll.

Verwandte Blueprints

• Blueprint 007 — Wie bepreisen Sie ein Produkt je nach Region, Segment oder Vertrag unterschiedlich? – das Preislistenmodell, auf dem alles hier aufbaut, und die Weigerung der API, einen Preis aufzulösen.
• Blueprint 011 — Wie halten Sie Hunderte von CRM-Automatisierungen wartbar? – Filter nach dem Prinzip „der erste Treffer gewinnt“, und warum Mengenstaffeln der Fall sind, in dem genau das gewünscht ist.
• Blueprint 005 — Wie migrieren Sie Kontakte aus einem anderen System, ohne unbemerkt Daten zu verlieren? – warum ein Katalogimport eine Prüfung der Befüllungsquote braucht, und wie unbemerkt ein Wert sein Ziel verfehlen kann.
• Blueprint 003 — Wie modellieren Sie etwas, für das Ihr CRM kein Objekt hat? – der Rahmen für die Entscheidung, dass ein Staffelplan auf das Produkt gehört und nicht in eine neue Entität.