--- title: "Wie handhaben Sie Mengenrabatte, die sich nach Region und Produkt unterscheiden?" blueprint: 015 slug: volume-discounts-by-region-and-product category: Preisgestaltung published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/volume-discounts-by-region-and-product/ language: de translation_of: https://blueprints.coevera.com/blueprints/volume-discounts-by-region-and-product/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie handhaben Sie Mengenrabatte, die sich nach Region und Produkt unterscheiden? **Kurze Antwort.** **Eine Preislistenzeile enthält genau einen Preis.** Ihr gesamtes Einstellungsobjekt besteht aus einer Zugriffsstufe und einer Rollenliste – darin gibt es keine Mindestmenge, keine Staffel, keinen Mengensprung. **Mengenrabatte sind also nicht nativ**, und Sie modellieren sie. **Welche Listen angeboten werden, ist dagegen weitgehend konfigurierbar.** Beliebig viele Preislisten können gleichzeitig gültig sein, und jede trägt eine Regel – bezeichnet als **price-list availability** –, die entscheidet, ob sie im Preislisten-Dropdown im Bereich Products & Services erscheint. Die Regel prüft ein beliebiges Feld am **Quote, an der Opportunity oder am Account**. **Sie regelt die Verfügbarkeit, nicht die Anwendung.** Das Dropdown steht standardmäßig auf **„Without price list“**, und ein Mensch wählt trotzdem aus. Bis jemand das tut, **wird jede Position zu einem Preis von null hinzugefügt** – was den häufigsten Preisfehler zu einem Standardfall statt zu einem Randfall macht. Und unter allen Dimensionen, nach denen eine Regel die Liste eingrenzen kann, **fehlt die Menge**: Die Menge ist eine Eigenschaft der Position, nicht eines Datensatzes, den der Filter sieht. Die funktionierende Form ist daher **ein Rabattplan am Produkt, gespeichert als Prozentsätze**, plus **Produkte, die nur auf Anfrage angeboten werden, gekennzeichnet statt mit null bepreist**. Die Prozentsätze sind wichtiger, als sie aussehen: Sie sind es, die eine Preisaktualisierung ermöglichen, ohne jede Staffel neu aufzubauen. ## 01 · Das 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. ## 02 · Warum 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: > **Nichts könnte dorthin weiterleiten.** Die Verfügbarkeitsregel einer Preisliste filtert auf > Felder von *Quote, Opportunity und Account*. Die Menge liegt an der **Position**, die keine > Regel auswertet – die Staffel könnte das Dropdown also nicht einmal eingrenzen. Und eine > Preisliste gilt für den ganzen Datensatz, also könnte auch ein Mensch nicht pro Position > auswählen. Ein Schema mit einer Liste pro Staffel hat in seinem Kern keinen Mechanismus. 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 Staffel*preis* 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. ## 03 · Datenmodell Vier Belange, vier verschiedene Orte. Das Fundament behandelt [Blueprint 007](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/) – 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](https://help.coevera.com/en/articles/2710211-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. | Belang | Wo er liegt | Nativ? | |---|---|---| | Welche Preisliste gilt | Ein `rules`-Filter an der Preisliste, der jedes Feld im Geltungsbereich prüft | **Ja** | | Der Listenpreis | Eine Preislistenzeile pro Produkt und Liste | **Ja** | | Der Staffelplan für Mengenrabatte | Rabattprozent-Felder am **Produkt**, eines pro Staffel und Region | **Nein** – modelliert | | Ausnahme „nur auf Anfrage“ | Eine Checkbox am Produkt, eine pro Region | **Nein** – 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: | Frage | Modelliert als | Was es bedeutet, wenn es fehlt | |---|---|---| | Wird es in dieser Region überhaupt verkauft? | Ein Mehrfachauswahl-Feld für die Verfügbarkeit am Produkt | Dort nicht angeboten | | Hat es hier einen Listenpreis? | Das Vorhandensein einer Preislistenzeile | **Mehrdeutig** – nur auf Anfrage, oder niemand hat ihn geladen | | Wird es hier bewusst nur auf Anfrage angeboten? | Eine Checkbox „Preis auf Anfrage“ pro Region | Es hätte einen Preis haben sollen | 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 | Kennzahl | Anzahl | |---|---| | Produkte im Katalog | **1.637** | | Preiszeilen, Region A | 788 | | Preiszeilen, Region B | 1.193 | | Listungen nur auf Anfrage, mit Kennzeichen statt Preis | **709** (370 + 339) | 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. ## 04 · Konfiguration auf Feldebene ### Wissenswerte Eigenschaften einer Preisliste | Eigenschaft | Werte | Warum es wichtig ist | |---|---|---| | `rules` | Ein Feldfilter | **Der Auswahlmechanismus.** Siehe unten | | `type` | `Standard` \| `Scheduled` | Eine geplante Liste ist der Mechanismus für eine datierte Preisänderung | | `status` | `Active` \| `Inactive` \| `Scheduled` \| `Expired` | Abgeleiteter Zustand – eine Liste kann von selbst auslaufen | | `startDate`, `endDate` | Datumswerte | Binden eine Liste an ein Preisjahr | | `isDefault`, `isActive` | Boolesche Werte | Die mitgelieferte Standardliste ist anfangs **inaktiv** | ### 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. > **Die Regel steuert die Verfügbarkeit, nicht die Anwendung.** Ihre Bezeichnung in der Oberfläche > lautet *price-list availability*, und genau das tut sie: Sie entscheidet, welche Listen im > Dropdown erscheinen. **Das Dropdown steht standardmäßig auf "Without price list", und ein Mensch > wählt aus.** Keine Regel wendet eine Liste von sich aus an, und kein Feld, das Sie setzen > können, bepreist ein Angebot für Sie. 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. > **Warum die Hauptbox leer ist.** Die entscheidende Bedingung liegt am Quote, also trägt die Box > auf Opportunity-Ebene nichts. Eine leere Hauptbox ist hier keine Fehlkonfiguration – so sieht > „keine Bedingung auf dieser Ebene“ aus. ### Der Rabattplan am Produkt Sechs ganzzahlige Felder – drei Staffeln, zwei Regionen: | Feld | Typ | Enthält | |---|---|---| | `cf_{region}_disc_10_49` | integer | % Rabatt auf den Listenpreis bei 10–49 Stück | | `cf_{region}_disc_50_99` | integer | % Rabatt auf den Listenpreis bei 50–99 Stück | | `cf_{region}_disc_100_plus` | integer | % Rabatt auf den Listenpreis ab 100 Stück | | `cf_{region}_price_on_request` | checkbox | In dieser Region nur auf Anfrage | 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. ## 05 · Automatisierung & 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. > **Klar gesagt: Diese Berechnung war im untersuchten Space nicht gebaut.** Der Katalog, die > Preislisten mit ihren Regionsregeln, die sechs Felder des Staffelplans, die Kennzeichen für > „Preis auf Anfrage“ und das Feld für den Netto-Stückpreis sind alle vorhanden und befüllt; kein > Prozess berechnet die Staffel. Das Design unten ist das, was die Bausteine hergeben, und es ist > nicht im Verhalten verifiziert. ### 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](https://blueprints.coevera.com/de/blueprints/keeping-hundreds-of-automations-maintainable/). 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](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/) 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. ## 06 · Grenzen & Kompromisse > **Es gibt keine native Mengenstaffel.** Das Einstellungsobjekt einer Preislistenzeile enthält > eine Zugriffsstufe und eine Rollenliste, sonst nichts. Keine Mindestmenge, keine > Staffelsammlung, keine Staffeltabelle. Jedes Design für Mengenpreise auf dieser Plattform ist > daher ein Eigenbau, und die Frage ist nur, welcher. - **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](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/). 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](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/) und nicht in dieses hier. ## 07 · Verifizierung 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?](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/) – 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?](https://blueprints.coevera.com/de/blueprints/keeping-hundreds-of-automations-maintainable/) – 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?](https://blueprints.coevera.com/de/blueprints/contact-migration-without-data-loss/) – 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?](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/) – der Rahmen für die Entscheidung, dass ein Staffelplan auf das Produkt gehört und nicht in eine neue Entität. ## Häufige Fragen ### Wie handhaben Sie Mengenrabatte, die sich nach Region und Produkt unterscheiden? Region und Menge werden an unterschiedlichen Stellen behandelt. Beliebig viele Preislisten können gleichzeitig gültig sein, und jede trägt eine Verfügbarkeitsregel, die ein beliebiges Feld am Quote, an der Opportunity oder am Account prüft – so lässt sich eine regionale Liste nur bei den Angeboten einblenden, für die sie gilt. Die Regel steuert aber nur, welche Listen das Dropdown anbietet; das Dropdown steht standardmäßig auf „Without price list“, und ein Mensch wählt aus. Die Menge lässt sich dort überhaupt nicht behandeln, weil eine Preislistenzeile genau einen Preis enthält und keine Regel die Menge einer Position prüfen kann. Modellieren Sie den Staffelplan daher als Rabattprozent-Felder am Produkt, und lassen Sie eine Automatisierung die Staffel anhand der Positionsmenge wählen. ### Warum nicht für jede Mengenstaffel eine eigene Preisliste anlegen? Weil nichts sie automatisch auswählen könnte und niemand sie von Hand zuverlässig auswählen könnte. Die Verfügbarkeitsregel einer Preisliste filtert auf Felder des Quotes, der Opportunity und des Accounts; die Menge liegt an der Position, die keine Regel sehen kann – die Staffel könnte das Dropdown also nie eingrenzen, und ein Mensch müsste pro Position die richtige Staffelliste wählen, was nicht einmal möglich ist, weil eine Liste für den ganzen Datensatz gilt. Die Listen würden sich außerdem mit jeder anderen Dimension mal Staffel vervielfachen, und jede bräuchte einen vollständigen Satz Preiszeilen: bei einem Katalog mit 1.637 Produkten ergeben schon zwei Regionen mal vier Staffeln über zehntausend Zeilen, die von Hand synchron gehalten werden müssen. ### Sollte eine Mengenstaffel einen Preis oder einen Rabattprozentsatz speichern? Einen Prozentsatz. Absolute Staffelpreise zu speichern bedeutet, dass jede Änderung des Listenpreises eine erneute Eingabe jeder Staffel für dieses Produkt erfordert, und die Staffeln veralten unbemerkt, wenn das nicht geschieht. Ein Prozentsatz auf den aktuellen Listenpreis übersteht eine Preisaktualisierung unverändert, sodass eine Neubepreisung ein einziger Import in die Preisliste ist statt eines Neuaufbaus des Rabattplans. ### Wie gehen Sie mit Produkten um, die keinen Listenpreis haben? Mit einem expliziten Kennzeichen pro Region und ganz ohne Preiszeile. Nie mit einem Preis von null – ein Nullpreis erzeugt ein Angebot mit Wert null, das wie eine echte Zahl aussieht. Und nie nur mit einer fehlenden Zeile, weil sich eine fehlende Preiszeile nicht von einer unterscheiden lässt, die noch niemand konfiguriert hat. In einem Live-Katalog waren 709 von 2.690 regionalen Listungen nur auf Anfrage erhältlich und trugen statt eines Preises eine Checkbox für „Preis auf Anfrage“. ### Können sich Mengenstaffeln zwischen Regionen unterscheiden? Nicht, wenn die Staffeln Felder sind. Weil jede Staffel ein eigenes Feld ist, liegen die Staffelgrenzen im Schema, sodass sich alle Regionen dieselbe Staffelstruktur teilen müssen. Ein Live-Katalog kam mit fünf Staffeln in einer Region und drei in der anderen an und wurde auf die drei gemeinsamen Staffeln normalisiert – das später zu ändern ist eine Schemaänderung plus eine Datenmigration, keine Konfigurationsänderung. --- Herausgegeben von Coevera. Auf das wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.