Die kurze Antwort
Ein Produkt trägt keinen Preis. Der Preis liegt auf einem Verknüpfungsdatensatz zwischen dem Produkt und einer Preisliste und hält den Betrag, seine Währung und eine Zugriffseinstellung, die die Liste auf bestimmte Rollen beschränken kann. Zwei Listen, zwei Zeilen, ein Produkt, zwei Preise.
Zwei Dinge werden Sie überraschen. Das Anlegen einer Preisliste erzeugt keine Preiszeilen für bereits vorhandene Produkte – nur umgekehrt. Und die API löst nie einen Preis aus einer Liste auf: Eine Position, die ohne ausdrücklichen Preis angelegt wird, erhält null, selbst wenn das Produkt auf der Standardliste einen Preis hat.
Das Geschäftsproblem
Dasselbe Produkt kostet nicht für alle dasselbe. Ein Distributor kauft zu einem Preis, ein Direktkunde zu einem anderen. Ein Rahmenvertrag legt einen Preis für ein Jahr fest. Eine Region hat ihre eigene Liste, weil der Markt dort etwas anderes hergibt. Eine Partnerstufe erhält eine Rabattstruktur, die das Direktvertriebsteam nicht sehen können sollte, geschweige denn anbieten.
Was das in der Praxis bedeutet:
- ein Katalogeintrag pro Produkt – nicht vier Beinahe-Duplikate mit unterschiedlichen Preisen, denn genau so geht es schief;
- mehrere Preise pro Produkt, jeder zu einer benannten Liste gehörig;
- der richtige Preis wird angewendet, wenn ein Vertriebsmitarbeiter ein Angebot erstellt, ohne dass er ihn nachschlagen muss;
- manche Listen sind nur für manche Personen sichtbar;
- und hinterher ein Nachweis darüber, was angeboten wurde und auf welcher Grundlage.
Warum der naheliegende Ansatz scheitert
Das Produkt pro Preis duplizieren
„Widget (EMEA)“, „Widget (Partner)“, „Widget (Contract A)“. Das funktioniert am ersten Tag und verfällt sofort: vier Datensätze, die bei jeder Änderung der Spezifikation synchron gehalten werden müssen, vier SKUs, wo das Unternehmen eine hat, und Berichte, die die Frage „Wie viel Widget haben wir verkauft?“ nicht ohne eine Zuordnungstabelle beantworten können, die jemand von Hand pflegt.
Den Preis als benutzerdefiniertes Feld auf das Produkt legen
Ein benutzerdefiniertes Feld pro Stufe – Listenpreis, Partnerpreis, Vertragspreis – legt die gesamte Preismatrix auf ein Formular, sichtbar für alle, die das Produkt sehen können, und erfordert bei jeder neuen Stufe eine Schemaänderung. Es umgeht außerdem die Mechanik der Positionen vollständig, sodass nichts den Preis für Sie in ein Angebot überträgt.
Annehmen, der Preis sei eine Eigenschaft des Produkts
Das ist er nicht, und genau diese strukturelle Tatsache sollten Sie verinnerlichen.
Im Schema der Product-Entität erscheint price in der Liste der Schlüsselfelder
– aber die Entität hat kein Preisattribut. Legen Sie ein Produkt an, kommt der Datensatz
mit einem Namen, einer SKU, einem Einheitensymbol, einem Typ und nirgends einem Preis
zurück.
Der Preis ist ein eigener Datensatz: eine Verknüpfung zwischen dem Produkt und einer Preisliste. Jede Überraschung in §6 folgt aus dieser einen Tatsache.
Datenmodell
Drei Entitäten, von denen eine kaum jemand kennt.
| Entität | Hält |
|---|---|
| Product | Den Katalogeintrag – Name, SKU, Einheit, Typ, Kategorie. Keinen Preis. |
| Price list | Eine benannte Liste – „List Price“, „EMEA“, „Partner Tier“. Trägt einen Typ und ein Flag active. |
| Price-list price (die Verknüpfung) | Den Preis selbst, dazu seine Währung und eine Zugriffseinstellung. Eine Zeile pro Produkt × Liste. |
„Dieses Produkt kostet 100 auf der Standardliste und 85 auf der EMEA-Liste“ sind also zwei Verknüpfungsdatensätze, nicht zwei Felder und nicht zwei Produkte.
Quelle. Coevera-Hilfecenter, Price lists, für die Sicht des Administrators auf dieselbe Struktur.
Die Verknüpfung trägt die Zugriffssteuerung. Jede Preiszeile hat eine Zugriffseinstellung mit optionaler Rollenliste. Das ist der Mechanismus für eine Partner- oder rein interne Stufe: Die Beschränkung liegt auf dem Preis, nicht auf dem Produkt und nicht im Namen der Liste. Sie ist zudem leicht völlig zu übersehen, weil nichts am Namen einer Preisliste darauf hindeutet, dass eine Ebene darunter Berechtigungen hängen.
Womit ein neuer Space beginnt
- Eine Preisliste namens „List Price“, als löschgeschützt markiert – Sie können sie nicht entfernen.
- Diese Liste kommt mit dem Flag active auf false an, was alle überrascht, die annehmen, die Standardliste sei einsatzbereit.
- Eine Währung, die Basiswährung, löschgeschützt.
Positionen
Ein Produkt gelangt als Position in einen Deal – eine Verknüpfung zwischen der Opportunity und dem Produkt, die Preis, Menge und einen berechneten Betrag trägt. Preise auf Positionsebene gibt es auf Quote und Opportunity; eine Opportunity ist nicht auf eine einzige Gesamtzahl beschränkt.
Die Opportunity trägt zusätzlich eine eigene Produktwährung, getrennt von der Währung ihres Hauptwerts, und ein Flag dafür, ob dieser Hauptwert aus den Positionen abgeleitet oder von Hand eingegeben wird.
Die Einrichtung
- Zuerst die Preislisten anlegenWenn möglich vor dem Katalog. Die Reihenfolge ist entscheidend – siehe §6.
- Sie aktivierenEinschließlich der eingebauten Standardliste, die nicht aktiv ankommt.
- Die Produkte anlegenJedes erhält automatisch eine Preiszeile für jede bereits vorhandene Liste, mit dem Standardwert null.
- Die Preise setzenEine Zeile pro Produkt pro Liste. Das ist der Großteil der Arbeit und der Teil, der sich zu skripten lohnt.
- Den Zugriff auf den Zeilen setzen, die beschränkt werden müssenNicht auf der Liste – auf den Preiszeilen darin.
- Über die Befüllungsquote verifizierenZählen Sie die Preiszeilen pro Liste und vergleichen Sie sie mit der Anzahl der Produkte. Eine Liste mit weniger Zeilen als Produkten hat Lücken, und eine Lücke liest sich als Preis von null.
Schritt 6 gibt es wegen der Asymmetrie in §6, und er ist die Prüfung, die den häufigsten Fall erkennt, in dem diese Konfiguration stillschweigend unvollständig ist.
Den richtigen Preis anwenden
Die API löst keinen Preis aus einer Preisliste auf. Verifiziert: Eine ohne Preis
angelegte Position kam mit price: 0 zurück, bei einem Produkt, das auf der
Standardliste einen Preis von 100 hatte. Kein Fehler, kein Standardwert, kein Nachschlagen.
Die Auswahl der Preisliste ist eine Hilfestellung der Oberfläche. Auf dem API-Weg ist es Aufgabe des Aufrufers, zu entscheiden, welche Liste gilt, und den Preis daraus zu lesen.
Für eine Integration oder einen Import bedeutet das: Die Auflösungslogik müssen Sie selbst schreiben und selbst korrekt halten. Bestimmen Sie die anzuwendende Liste aus dem, was sie steuert – der Region des Accounts, seiner Stufe, einer Vertragsreferenz –, lesen Sie die Preiszeile für dieses Produkt und diese Liste und schreiben Sie den Wert in die Position.
Und keines der über die API gelesenen Felder der Position hält fest, aus welcher Liste der Preis stammt. Keines enthält einen Verweis auf eine Preisliste. Sobald eine Zeile existiert, sagt also nichts in den zurückgelesenen Daten, ob 85 der EMEA-Preis, ein ausgehandelter Rabatt oder ein Tippfehler war. Wenn die Grundlage eines Preises für Berichte oder Audits wichtig ist, erfassen Sie sie selbst in einem benutzerdefinierten Feld auf der Position, und zwar in dem Moment, in dem Sie den Preis setzen – hinterher ist es zu spät.
Grenzen & Kompromisse
Preiszeilen entstehen nur in eine Richtung
Das Anlegen eines Produkts erzeugt eine Preiszeile für jede vorhandene Liste. Das Anlegen einer Liste erzeugt nichts für vorhandene Produkte. In beide Richtungen verifiziert.
Die natürliche Reihenfolge – erst den Katalog aufbauen, dann eine regionale Liste hinzufügen, wenn das Unternehmen expandiert – lässt also jedes vorhandene Produkt auf der neuen Liste ohne Preis, und eine Zeile ohne Preis ist von einem Preis von null nicht zu unterscheiden. Legen Sie Listen, wo möglich, vor den Produkten an; wo das nicht geht, füllen Sie die Zeilen gezielt nach und verifizieren Sie die Anzahl.
Berechnete Werte hinken der Schreibantwort hinterher
Der amount einer Position wird aus Preis × Menge berechnet, aber der Wert in der
Antwort auf Ihren eigenen Schreibvorgang ist veraltet. Direkt nach dem Setzen des Preises 85
bei einer Menge von 2 lieferte der Schreibvorgang amount: 0; ein frischer
Lesevorgang lieferte 170. Die Berechnung stimmt – das Echo nicht.
Leiten Sie nie ein berechnetes Feld aus einer Schreibantwort ab. Dasselbe Muster zeigt sich in Blueprint 002.
Rabattfelder sind lesbar, aber nicht beschreibbar
Die Position stellt einen Rabattwert und einen Rabattprozentsatz bereit, und die API lehnt Versuche ab, eines von beiden zu schreiben – sie meldet sie als Attribute, die die Entität nicht hat. Sie scheinen abgeleitet statt setzbar zu sein, daher muss ein Rabatt über eine Anpassung des Preises ausgedrückt werden statt über das Erfassen eines Rabatts.
Nicht verifiziert: die Aggregation des Opportunity-Werts
Mit dem Auto-Berechnungs-Flag der Opportunity auf true und einer Position, deren Betrag korrekt berechnet wird, bleibt der Hauptwert der Opportunity über wiederholte Lesevorgänge und ein bewusstes erneutes Speichern des Datensatzes hinweg bei null. Das Ergebnis ist dasselbe, wenn das Flag beim Anlegen gesetzt wird, bevor es irgendeine Position gibt: Der Betrag der Position wird zu 1.000 berechnet, und der Wert der Opportunity bleibt null.
Ob es sich um einen Defekt handelt, ist nicht geklärt: Die verbleibende, hier nicht getestete Erklärung ist, dass die Aggregation von der Oberfläche und nicht vom Server berechnet wird. Fest steht, dass keine der beiden Reihenfolgen auf dem Server einen Wert ergibt, daher kann sich eine Integration nicht darauf verlassen, dass Positionen den Opportunity-Wert bestimmen – setzen Sie den Wert ausdrücklich, wenn Sie ihn brauchen, und bestätigen Sie das Verhalten der Oberfläche, bevor Sie etwas anderes annehmen.
Mehrere Währungen
Jede Preiszeile trägt ihre eigene Währung, sodass eine Liste in einer anderen Währung geführt werden kann als eine andere. Nicht nativ ist es, den Wechselkurs festzuhalten, der zu einem bestimmten Zeitpunkt galt – eine Historie der Wechselkurse zum Transaktionszeitpunkt muss über Automatisierung abgebildet werden, wenn das Unternehmen sie braucht. Wir haben das nicht in einem Space mit mehreren Währungen verifiziert; es ist aus einer früheren Analyse übernommen, nicht aus Beobachtung.
Verifizierung
- Zählen Sie die Preiszeilen pro Liste gegen die Anzahl der Produkte. Die mit Abstand wertvollste Prüfung hier, weil ein Produkt ohne Preis auf einer Liste genauso aussieht wie ein Produkt mit dem Preis null.
- Lesen Sie Preise aus den Verknüpfungsdatensätzen zurück, nicht aus dem Produkt – am Produkt gibt es nichts zu lesen.
- Legen Sie eine Position von Anfang bis Ende an und bestätigen Sie, dass der Preis, der ankommt, der beabsichtigte ist, besonders wenn eine Integration die Auflösung übernimmt.
- Lesen Sie berechnete Beträge nach einer Wartezeit erneut. Nie aus der Schreibantwort.
- Testen Sie Zugriffsbeschränkungen als eingeschränkter Benutzer, nicht als Administrator – dieselbe Disziplin wie bei der Prüfung der Datensatzsperre in Blueprint 004. Ein Administrator kann nicht sehen, dass die Beschränkung greift.
- Bestätigen Sie, dass die Standardliste aktiv ist, bevor Sie sich fragen, warum nichts einen Preis bekommt.
Was auf eine Regression hindeuten würde: Positionen, die bei null landen, was bedeutet, dass der Auflösungsschritt übersprungen wurde; eine Preisliste, deren Zeilenzahl nach einer Katalogerweiterung unter die Anzahl der Produkte fällt; oder angebotene Preise, die zu keiner Liste mehr passen, was bedeutet, dass jemand Positionen direkt bearbeitet hat.
Häufige Fragen
Wie geben Sie einem Produkt unterschiedliche Preise für verschiedene Regionen oder Kundensegmente?
Mit Preislisten. In Coevera CRM trägt ein Produkt überhaupt keinen Preis – der Preis liegt auf einem Verknüpfungsdatensatz zwischen dem Produkt und einer Preisliste, der den Betrag und seine Währung hält. Legen Sie eine zweite Preisliste und eine zweite Preiszeile für dasselbe Produkt an, hat dieses Produkt zwei Preise, einen pro Liste. Der Verknüpfungsdatensatz trägt außerdem eine Zugriffseinstellung, sodass eine Liste auf bestimmte Rollen beschränkt werden kann – so bleibt eine Partner- oder rein interne Preisstufe vor dem übrigen Vertriebsteam verborgen.
Warum zeigt mein Produkt keinen Preis, nachdem ich eine neue Preisliste angelegt habe?
Weil das automatische Anlegen von Preiszeilen nur in eine Richtung funktioniert. Das Anlegen eines Produkts erzeugt für jede bereits vorhandene Preisliste eine Preiszeile mit dem Standardwert null. Das Anlegen einer Preisliste erzeugt keine Zeilen für bereits vorhandene Produkte. Wird eine regionale oder vertragsbezogene Preisliste also erst hinzugefügt, nachdem der Katalog befüllt ist, hat jedes vorhandene Produkt auf dieser Liste keinen Preis, bis die Zeilen ausdrücklich angelegt werden, eine pro Produkt.
Wendet eine CRM-API beim Hinzufügen eines Produkts zu einem Deal automatisch den Preis aus der Preisliste an?
In Coevera nicht. Wird eine Position über die API ohne Preisangabe angelegt, entsteht eine Zeile mit dem Preis null, selbst wenn das Produkt auf der Standardliste einen Preis hat. Die Auswahl der Preisliste ist eine Hilfestellung der Oberfläche und keine serverseitige Auflösungsregel, daher muss jede Integration, die Positionen anlegt, selbst entscheiden, welche Liste gilt, und den Preis selbst mitgeben. Zudem verweist keines der über die API gelesenen Felder der Position auf die Preisliste, aus der sie stammt, sodass die Herkunft eines Preises dort nicht festgehalten wird.
Können sowohl Angebote als auch Opportunities Preise auf Positionsebene tragen?
Ja. Preise auf Positionsebene gibt es in Coevera sowohl auf Quote- als auch auf Opportunity-Datensätzen, eine Opportunity ist also nicht auf einen einzigen Gesamtwert beschränkt. Die Opportunity trägt neben der Währung ihres Hauptwerts eine eigene Produktwährung sowie ein Flag, das steuert, ob dieser Hauptwert aus den Positionen abgeleitet statt direkt eingegeben wird.