Penny Perfect Pricing: ERP-Preise in Salesforce?

Für die meisten Hersteller mit SAP sollte das ERP Preis-Master bleiben, und Penny Perfect Pricing lohnt einen Blick nur dort, wo Aufträge in Salesforce erfasst werden. Penny Perfect Pricing kam mit Winter ’27 als Preisfindung für Positionen von Advanced Orders, dem Telesales-Bestellablauf in der Manufacturing Cloud. Ihre Objekte bilden die SAP-Konditionstechnik nach, sie kann also kundenspezifische Preise berechnen, ohne das ERP zu fragen. Die Entwicklerdokumentation nennt keine Lizenz und keinen Standardweg, SAP-Konditionssätze zu laden. Zwei Preisfindungen laufen auseinander, wenn keine führt. Legen Sie das zuerst fest und lassen Sie sich die Lizenzfrage schriftlich beantworten.

Was ist Penny Perfect Pricing?

Salesforce stellt sie in den Winter ’27 Release Highlights auf Trailhead1 mit einem Satz vor: “Apply SAP-grade pricing precision across every manufacturing order, with multimarket, multi-unit of measure (UoM), calculation schema, and ERP integration built into Manufacturing Cloud.” Also Preisgenauigkeit auf SAP-Niveau, mit mehreren Märkten, mehreren Mengeneinheiten, Kalkulationsschema und ERP-Anbindung. Winter ’27 ist seit 12. Oktober 2026 allgemein verfügbar2.

Konkreter wird der Developer Guide3. Penny Perfect Pricing liefert danach genaue Preise in Echtzeit für Positionen von Advanced Orders. Die REST-APIs können:

• Sofortpreise für Positionen liefern, während ein Auftrag erfasst wird,
• die endgültigen Preise eines Auftrags berechnen,
• Preisdaten anlegen,
• einen vollständigen Auftrag mit einem einzigen Aufruf platzieren,
• Account-Hierarchien für Reporting und Analysen flach darstellen.

Der Guide beschreibt 19 Objekte, alle ab API-Version 68.0 verfügbar, und nennt Manufacturing Cloud, Automotive Cloud und Consumer Goods Cloud als die Clouds, die sie nutzen. Im Developer Guide der Manufacturing Cloud4 hat sie einen eigenen Eintrag, direkt neben Advanced Orders for Telesales.

In der Struktur ist sie nah an der SAP-Preisfindung

SAP berechnet Preise mit der Konditionstechnik: Laut SAP Learning5 enthält ein Kalkulationsschema die Konditionsarten, jede Konditionsart hat eine Zugriffsfolge, und die Zugriffsfolge sucht in Konditionstabellen nach einem gültigen Konditionssatz, einschließlich Staffeln nach Menge.

Die Objektreferenz6 von Penny Perfect Pricing liest sich wie eine Übersetzung dieses Modells. Salesforce veröffentlicht die Zuordnung nicht; die rechte Spalte ist meine Lesart der Objektbeschreibungen:

Objekt in Penny Perfect Pricing	Beschreibung in der Referenz	Nächstes SAP-Gegenstück
Pricing Calculation Schema	geordnete Folge von Rechenschritten	Kalkulationsschema
Pricing Specification	“Pricing Condition Template”, eine Art von Preiskondition	Konditionsart
Pricing Search Strategy	geordnete Schritte, wie die Engine Konditionen sucht	Zugriffsfolge
Pricing Key Type	Kombination aus bis zu 10 Schlüsselattributen	Schlüssel der Konditionstabelle
External Pricing Key Value	“a resolved pricing condition record”	Konditionssatz
External Pricing Key Value Tier	Mengen- oder Volumenstaffel	Staffel

Dazu kommen gemeinsame Objekte wie Account, Product2, Account-Beziehungen und interne Organisationseinheiten, die geschäftsbereichsspezifische Einstellungen pro Account tragen.

Die Ähnlichkeit hat zwei Seiten. Wer die SAP-Preisfindung kennt, erkennt die Logik wieder. Sie bedeutet aber auch denselben Konfigurationsaufwand: Jede Konditionsart, jeder Zugriff und jeder Konditionssatz aus SAP bräuchte ein Gegenstück in Salesforce.

Wo passt Penny Perfect Pricing, und wo nicht?

Sie passt zum Telesales, also zum Auftragseingang am Telefon. Die APIs von Advanced Orders for Telesales7 durchsuchen Sortimente und Produkte, zeigen früher bestellte Produkte, liefern gültige Liefertermine, holen Sofortpreise und platzieren einen Auftrag mit einem Aufruf. Die Produktseite der Manufacturing Cloud8 nennt unter Winter ’27 eine “unified telesales order view”. Penny Perfect Pricing ist der Preisschritt in diesem Ablauf.

Zwei andere Preisfindungen ersetzt sie nicht:

• Angebote mit Konfiguration, Freigabe und Vertragsbedingungen gehören zu Revenue Cloud. Penny Perfect Pricing bepreist Auftragspositionen, keine Angebote.
• Shoppreise für Händler, die online bestellen, kommen aus Preisbüchern in B2B Commerce oder per Live-Aufruf aus dem ERP, wie in Kundenpreise in B2B Commerce und im Masterclass-Kapitel Preise, Warenkorb, Checkout beschrieben.

Agenten, die Händlerangebote erstellen, etwa der AI Partner Sales Assistant, haben dasselbe Problem von der anderen Seite: Hält Salesforce nur Listenpreise, nennt der Agent Listenpreise. Das beschreibe ich in KI-Angebote für Händler mit dem Partner Sales Assistant.

Was ist nicht dokumentiert?

Drei Dinge habe ich am 28. Oktober 2026 in keiner offiziellen Quelle gefunden:

1. Lizenz. Die Preisseite der Manufacturing Cloud9 erwähnt Penny Perfect Pricing nicht, und die Entwicklerseiten enthalten keine Angaben zu Lizenz oder Permission Sets.
2. Konditionssätze aus SAP laden. Die Highlights versprechen ERP-Anbindung, der Developer Guide beschreibt aber keinen Import und keinen Abgleich von SAP-Konditionssätzen. Das Trailhead-Modul für Consumer Goods10 sagt, dass Preiskonditionen aus dem ERP genutzt werden können, und erwähnt einen Import von Konditionssätzen, ohne ihn zu beschreiben.
3. Mehrere Märkte und Mengeneinheiten. Die Highlights nennen beides. Die Objektreferenz, die ich gelesen habe, erklärt nicht, wie Währungen oder Umrechnung von Mengeneinheiten eingerichtet werden.

Zwei Preisfindungen laufen auseinander, weil Konditionen sich ändern

Konditionssätze ändern sich ständig. Die Preisabteilung legt in SAP jede Woche Kundenrabatte an, beendet Aktionen und passt Staffeln an. Rechnet Salesforce mit Kopien, muss jede Änderung ankommen, bevor der nächste Auftrag bepreist wird. Typische Lücken:

• Zeitpunkt. Eine Kondition ändert sich in SAP um zehn Uhr, die Kopie kommt über Nacht, und der Telesales-Mitarbeiter nennt den ganzen Tag den Preis von gestern.
• Neue Konditionsarten. Die Finanzabteilung führt in SAP einen Zuschlag ein. Niemand ergänzt die passende Preisspezifikation im Kalkulationsschema in Salesforce.
• Rundung. “Penny perfect” setzt identische Rundung in jedem Schritt voraus. Eine Abweichung in der Rechenreihenfolge, und Auftrag und Rechnung unterscheiden sich um ein paar Cent pro Position, was Kunden bei großen Aufträgen bemerken.
• Welcher Preis gilt. Übernimmt SAP den Salesforce-Preis, wenn der Auftrag ankommt, oder ermittelt es einen eigenen? Rechnen beide, bekommt der Kunde womöglich eine Auftragsbestätigung mit einem Preis und eine Rechnung mit einem anderen.

Diese Lücken lassen sich beherrschen, wenn ein Preis-Master und eine Regel für Abweichungen feststehen, bevor sich ein Mitarbeiter auf einen Salesforce-Preis verlässt.

Rechenbeispiel: Telesales für Ersatzteile

Angenommen, ein Maschinenbauer nimmt mit einem Telesales-Team von zehn Personen Ersatzteilaufträge am Telefon an. 30.000 Ersatzteile, 2.500 Kunden, Preise aus SAP mit vier Konditionsarten: Listenpreis, Kundenrabatt, Mindermengenzuschlag und Mengenstaffeln. Die Aufträge sollen in Salesforce erfasst werden, wo der Mitarbeiter auch die installierte Basis und offene Fälle des Kunden sieht.

Variante A: SAP bleibt Preis-Master. Salesforce fragt SAP pro Position nach dem Preis, während der Auftrag erfasst wird, über eine API wie in Agentforce und SAP: Auftragsstatus über MuleSoft. Die Preise sind immer identisch. Der Preis dafür ist eine Abhängigkeit: Ist SAP im Wartungsfenster, kann das Team keine Aufträge bepreisen.

Variante B: Penny Perfect Pricing rechnet. Die vier Konditionsarten werden als Preisspezifikationen nachgebaut, und die Konditionssätze für 2.500 Kunden werden als External Pricing Key Values kopiert, mit einem Delta-Lauf mehrmals am Tag. Preise kommen sofort, ohne SAP. Der Aufwand liegt im Abgleich und in einer zweiten Preiskonfiguration, die jemand verantwortet.

Ich würde A wählen, wenn SAP schnell antwortet und zuverlässig erreichbar ist, und das ist der häufigere Fall. B würde ich prüfen, wenn die Preislogik stabil ist, sich Konditionen selten ändern und das Team weiterarbeiten muss, wenn SAP nicht antwortet. In beiden Fällen sollte SAP den endgültigen Rechnungspreis bestimmen, und die Schnittstelle sollte jeden Auftrag markieren, bei dem die beiden Preise abweichen.

Konditionsarten zählen und Preis-Master festlegen

1. Zählen Sie Ihre Konditionsarten und wie oft sich Konditionssätze pro Woche ändern.
2. Halten Sie den Preis-Master fest und welcher Preis gilt, wenn Salesforce und SAP abweichen.
3. Fragen Sie Salesforce schriftlich: Welche Lizenz enthält Penny Perfect Pricing, und gibt es einen unterstützten Weg, SAP-Konditionssätze zu laden?
4. Planen Sie die Datenflüsse zusammen mit der übrigen SAP-Schnittstelle, wie in Manufacturing Cloud und SAP: welche Daten wohin.
5. Testen Sie mit echten Aufträgen: 200 historische Aufträge in beiden Systemen bepreist und Position für Position verglichen.

Das ganze Kapitel zu ERP-Anbindung, Agenten und Rollout ist ERP, KI und Rollout in der Masterclass Manufacturing Cloud. Die Grenze zwischen ERP und Salesforce zu ziehen, gehört zu meiner Arbeit als Salesforce-Architekt.

Quellen10

1. 1Winter ’27 Release Highlights auf Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com
2. 2seit 12. Oktober 2026 allgemein verfügbar (öffnet in einem neuen Tab)salesforce.com
3. 3Developer Guide (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Developer Guide der Manufacturing Cloud (öffnet in einem neuen Tab)developer.salesforce.com
5. 5SAP Learning (öffnet in einem neuen Tab)learning.sap.com
6. 6Objektreferenz (öffnet in einem neuen Tab)developer.salesforce.com
7. 7Advanced Orders for Telesales (öffnet in einem neuen Tab)developer.salesforce.com
8. 8Produktseite der Manufacturing Cloud (öffnet in einem neuen Tab)salesforce.com
9. 9Preisseite der Manufacturing Cloud (öffnet in einem neuen Tab)salesforce.com
10. 10Trailhead-Modul für Consumer Goods (öffnet in einem neuen Tab)trailhead.salesforce.com