B2B Commerce: Preise, Warenkorb und Checkout

Ein B2B-Shop auf Salesforce zeigt Kundenpreise im Standard aus Preisbüchern. Das reicht für Listenpreise und Händlerstufen. Entstehen Ihre Preise aus SAP-Konditionen oder Verträgen, brauchen Sie einen Live-Aufruf ans ERP über die Pricing Extension oder Advanced Pricing aus Revenue Cloud, das eine zweite Lizenz kostet. Große oder ungewöhnliche Mengen laufen über Request for Quote. Im Checkout zahlen Händler mit Bestellnummer, und der Shop fragt vorher das ERP nach Kreditlimit und Auftragssperre. Den größten Hebel hat das Nachbestellen. Die wichtigste Entscheidung des Kapitels ist trotzdem eine schriftliche: welches System Preis-Master ist.

Woher kommen die Preise im B2B-Store?

Salesforce B2B Commerce, das Salesforce laut Trailhead (öffnet in einem neuen Tab) inzwischen auch als “Agentforce Commerce for B2B” vermarktet, nutzt dieselben Preisbuch-Objekte wie Sales Cloud. Laut Salesforce-Hilfe zu Preisen in B2B-Stores (öffnet in einem neuen Tab) bekommt jeder neue Store automatisch ein Standard-Preisbuch und ein Streichpreis-Preisbuch, das einen durchgestrichenen Vergleichspreis zeigt. Weitere Preisbücher ordnen Sie dem Store oder Käufergruppen zu. Wie Käufergruppen und Sichtbarkeit zusammenhängen, steht in Kapitel 2.

Hat ein Käufer Zugriff auf mehrere Preisbücher, entscheidet die Preisstrategie (öffnet in einem neuen Tab):

• Best Price zeigt den niedrigsten Preis aus allen Preisbüchern des Käufers.
• Priority Price folgt der Reihenfolge, die Sie je Käufergruppe festlegen; die kleinere Zahl hat Vorrang.

Ich würde mit Priority Price anfangen, wenn Händler in mehreren Käufergruppen stecken, etwa Land und Stufe. Best Price belohnt jede Überschneidung, die beim Datenladen versehentlich entsteht.

Für Mengenstaffeln enthält das Preis-Datenmodell Price Adjustment Schedule und Price Adjustment Tier. Tiered Pricing steht zugleich auf der Liste der Revenue-Management-Funktionen. Welche Variante Ihre Staffeln abdeckt, prüfen Sie im Prototyp, bevor Sie Lizenzen kaufen.

Die Limits für Preisbücher (öffnet in einem neuen Tab) prägen das Design früh:

Limit	Wert
Preisbücher je Store	5
Einträge je Preisbuch	350.000 (weich)
Ausgewertete Preisbücher je Preisaufruf	25 (hart)
Käufergruppen je Preisbuch	100 (weich)
Preisbücher je Käufergruppe	50 in der Tabelle, 25 im Hinweis derselben Seite

Die 25 je Aufruf sind das Limit, das in Projekten wehtun kann: Preisbücher darüber fließen nicht in die Preisfindung ein, ohne Fehlermeldung. Die widersprüchliche Angabe je Käufergruppe sollten Sie sich von Salesforce schriftlich klären lassen, wenn Ihr Design daran hängt. Details und Muster stehen in Kundenpreise in B2B Commerce.

Preisbücher kopieren oder das ERP live fragen?

Ein Preisbucheintrag hält einen Preis für ein Produkt in einem Preisbuch. Die Konditionstechnik in SAP berechnet den Nettopreis dagegen zum Zeitpunkt des Auftrags aus Kundenpreisen, Rabatten je Materialgruppe, Zuschlägen und Gültigkeiten. Für den Shop gibt es zwei Wege:

• Replizieren: Ein Job berechnet die Nettopreise vorab und lädt sie in Preisbücher.
• Live fragen: Laut Liste der Extensions (öffnet in einem neuen Tab) nutzt Commerce_Domain_Pricing_Service im Standard Preisbücher, und Commerce_Domain_Pricing_CartCalculator rechnet Warenkorb und Checkout auf Basis dieses Dienstes. Ersetzen Sie den Dienst durch Apex, das SAP aufruft, sieht der Käufer den echten Nettopreis. Dafür muss SAP so schnell antworten, wie ein Käufer auf einer Produktliste wartet.

Bei vier Händlerstufen und stabiler Preisliste reichen vier Preisbücher und eine nächtliche Ladung. Bei Preisen, die je Kunde verhandelt sind, würde ich SAP live fragen oder aufteilen: Preisbücher für die breite Masse, Live-Aufruf für die Schlüsselkunden. Ein Detail aus der Extension-Liste: Nutzt der Store Faster Add-to-Cart, braucht jedes Produkt trotzdem einen Eintrag in einem Store-Preisbuch.

Egal welcher Weg, eine Frage muss vor dem Go-live beantwortet sein: Welcher Preis gilt, wenn der Shop einen anderen zeigt als den, den SAP beim Auftragseingang berechnet? Ohne Regel landet sie beim Innendienst, Auftrag für Auftrag. Dasselbe Risiko beschreibe ich für KI-Angebote in KI-Angebote für Händler mit dem Partner Sales Assistant. Welche Schnittstellen daraus folgen, behandelt Kapitel 4.

Wann braucht der Shop Advanced Pricing aus Revenue Cloud?

Die dritte Option ist eine Preis-Engine in Salesforce. Die Salesforce-Hilfe zu Agentforce Revenue Management for B2B Commerce (öffnet in einem neuen Tab) nennt als Voraussetzung eine Lizenz Commerce Growth oder Commerce Advanced zusammen mit Revenue Cloud Advanced, gekauft über den Account Executive. Dazu gehören komplexe Preisstrategien mit Pricing Procedures, Staffelpreise, konfigurierbare Bundles, Request for Quote, Qualification Rules für die Sichtbarkeit und Abonnements. Vertragspreise für B2B-Stores haben in der Hilfe einen eigenen Artikel.

Zum Budget: Die B2B-Editionen stehen auf “Contact for Pricing”, die Preisseite von Revenue Cloud (öffnet in einem neuen Tab) nennt für Revenue Cloud Advanced 200 US-Dollar pro Nutzer und Monat bei jährlicher Abrechnung. Wie viele dieser Nutzerlizenzen ein Store mit externen Käufern braucht, steht auf keiner der beiden Seiten. Diese Frage gehört schriftlich an Salesforce, bevor Sie einen Business Case rechnen.

Von der Anfrage über das Angebot zur Bestellung

Händler fragen nach einem Preis für 200 Stück statt 5 oder für ein Projekt mit Liefertermin. Heute ist das eine E-Mail mit Excel-Liste. Mit Request for Quote senden angemeldete Käufer den Warenkorb als Angebotsanfrage, und der Innendienst bearbeitet das Angebot in Sales Cloud oder Agentforce Revenue Management. Salesforce nennt RFQ im Beitrag vom Juni 2026 (öffnet in einem neuen Tab) “already generally available”. Im selben Beitrag stehen Quote to Cart und Round-Trip Quoting: Ein freigegebenes Angebot kommt als Warenkorb zum Käufer zurück, der es im Shop bestellt.

Für Entwickler

Welche Apex-Methoden gibt es für Angebote im Shop?

Für eigene Komponenten gibt es die Apex-Klasse ConnectApi.CommerceQuotes (öffnet in einem neuen Tab): getQuotes und getQuoteDetail ab API 66.0, createQuoteFromProduct und updateQuote ab API 67.0. Mit updateQuote verhandelt der Käufer ein freigegebenes Angebot nach oder lehnt es ab.

Wichtiger als die Technik ist der Innendienst. Ein Käufer, der drei Tage auf ein Angebot aus dem Shop wartet, schickt die nächste Anfrage wieder per E-Mail. Antwortzeit, Zuständigkeit je Queue und Rabattgrenzen gehören vor dem Go-live auf Papier. Den ganzen Kreislauf beschreibe ich in Request for Quote im B2B-Shop.

Checkout auf Rechnung: Bestellnummer statt Karte

Händler eines Herstellers zahlen meist auf Rechnung. Das Salesforce-Entwicklerhandbuch zu Zahlungskomponenten (öffnet in einem neuen Tab) beschreibt eine Purchase Order als Zahlungsform, die “not technically a payment” ist und keinen Zahlungsvorgang auslöst; die Nummer nutzt das ERP für die Rechnung. Ohne Zahlungsautorisierung oder Bestellnummer lässt sich keine Bestellung abschicken.

Die Optionen für B2B-Stores:

• Purchase Order: nur Bestellnummern, kein Payment Gateway.
• Dual Payment: Karte und Bestellnummer, nur für B2B, mit serverseitigem Gateway für die Karte.
• Salesforce Payments: native Stripe-Integration, die in B2B-Stores auch eine Bestellnummer anbieten kann.
• Eigene Komponente oder ein eigenes serverseitiges Gateway mit Apex-Adapter.

Zahlungen lassen sich laut Extension-Leitfaden (öffnet in einem neuen Tab) nicht mit Extensions anpassen. Sonderregeln für Zahlungen sind also eigener Code, den Ihr Team über jedes Release trägt.

Was der Standard nicht kann, ist die Prüfung, ob ein Händler überhaupt bestellen darf. Kreditlimit und Auftragssperre liegen im ERP. Der Ort dafür ist Commerce_Domain_Checkout_PlaceOrder: Er führt Warenkorbprüfungen aus, wenn der Käufer bestellt, und Sie überschreiben die Methode validate mit einem Live-Aufruf ans ERP. Entscheiden Sie dabei, was bei einer Zeitüberschreitung passiert und was der Käufer bei einer Sperre liest. Kreditlimits nachts nach Salesforce zu kopieren halte ich für falsch: Die Kopie stimmt genau dann nicht, wenn ein Händler heute Morgen drei große Bestellungen abgeschickt hat. Mehr dazu in B2B-Checkout: Bestellnummer, Karte oder Rechnung?.

Nachbestellen: Wo kommt das Volumen her?

Die meisten Ersatzteile und Verbrauchsmaterialien hat ein Händler schon einmal bestellt. Muss er jedes Teil neu suchen, geht er zurück zum Telefon. Salesforce bietet dafür mehrere Wege:

Weg	Stand Oktober 2026
Alte Bestellung in den Warenkorb (Add Order to Cart (öffnet in einem neuen Tab))	verfügbar
Bestellvorlagen für Käufer und Vertrieb	laut Innovationsseite (öffnet in einem neuen Tab) “AV Sept. 26”
Warenkorb als CSV oder JSON importieren und exportieren	Release Juli 2026 (öffnet in einem neuen Tab)
Mehrere Nutzer bearbeiten einen Warenkorb live	“AV Jan. 27”
Reorder Portal für Vertriebsteams in Sales Cloud	verfügbar, Agentforce-Commerce-Lizenz nötig

Add Order to Cart arbeitet mit Order Summaries in Salesforce. Eine Telefonbestellung, die nur in SAP existiert, kann der Händler deshalb nicht aus der Shop-Historie nachbestellen, solange Sie solche Aufträge nicht nach Salesforce holen.

Die Warenkorblimits (öffnet in einem neuen Tab): Die meisten Shops begrenzen einen Warenkorb auf 500 Positionen, mit Large-Cart-Unterstützung auf 2.000. Ein Nutzer hat bis zu 100 Warenkörbe, einen aktiven und 99 weitere. Prüfen Sie vor dem Versprechen “Laden Sie Ihre ganze Liste hoch”, wie lang die längsten Bestellungen im ERP wirklich sind.

Das Reorder Portal (öffnet in einem neuen Tab) ist die schlanke Variante: Vertriebsmitarbeiter laden Käufer ein, die dann ihre früheren Bestellungen wiederholen. Für die Anbindung an Sales Cloud braucht es eine Agentforce-Commerce-Lizenz und eine aktivierte Digital Experience. Es passt, wenn kein Katalogprojekt geplant ist. Welche Funktion zu welchem Bestellmuster passt, steht in Nachbestellen im B2B-Shop.

Rechenbeispiel: 600 Händler in 9 Ländern

Ein Hersteller von Kompressoren verkauft Ersatzteile an 600 Händler in 9 Ländern. SAP hält einen Listenpreis je Land, einen Rabatt je Händlerstufe und Kundenpreise für 40 große Händler. Alle Händler haben ein Debitorenkonto. Der Vertrieb kalkuliert Maschinen in SAP, Revenue Cloud gibt es nicht.

So würde ich entscheiden:

Thema	Entscheidung
Preise:	27 Preisbücher für 9 Länder und 3 Stufen, nachts aus SAP berechnet; jeder Händler sieht genau eines. Die 40 großen Händler bekommen ihren Preis über die Pricing Extension live aus SAP. Kein Advanced Pricing, weil die Preislogik in SAP bleibt.
Angebote:	RFQ erst in einer zweiten Stufe, wenn die Lizenzfrage geklärt ist; bis dahin geht Projektgeschäft wie heute an den Innendienst.
Checkout:	nur Purchase-Order-Komponente, Kreditprüfung in validate gegen SAP. Bei Zeitüberschreitung nimmt der Shop die Bestellung an, weil SAP den Kredit beim Anlegen des Kundenauftrags ohnehin prüft.
Nachbestellen:	Add Order to Cart und Bestellvorlagen für alle, CSV-Import für die großen Händler.

Die Zahlen sind erfunden, um die Methode zu zeigen. Ändern Sie eine Annahme, etwa einen Vertrieb, der schon in Revenue Cloud kalkuliert, kippt Punkt 1 zugunsten von Advanced Pricing.

Die Preis-Master-Entscheidung auf eine Seite schreiben

Schreiben Sie eine Seite zur Preis-Master-Entscheidung, bevor jemand den Store gestaltet:

1. Welches System berechnet den Preis je Käufergruppe: SAP, Preisbücher oder Revenue Cloud?
2. Welcher Preis erscheint wo: Produktliste, Warenkorb, Auftragsbestätigung?
3. Was zeigt der Shop, wenn der Live-Aufruf scheitert?
4. Welcher Preis gilt, wenn Shop und ERP abweichen, und wer klärt das?
5. Welche Käufergruppen zahlen mit Bestellnummer, welche mit Karte, und wer prüft den Kredit?

Diese Seite gehört neben Ihre Object Ownership Matrix und bestimmt die Schnittstellenliste für Kapitel 4. Den Entwurf der Preis- und Kreditaufrufe übernehme ich im Rahmen der Salesforce-Schnittstellen, die Lizenzfrage zu Revenue Cloud unter Make-or-Buy und Lizenzen. Alle Kapitel finden Sie auf der Übersichtsseite.