Shop-Bestellungen ins ERP: Wem gehört der Auftrag?

Bei den meisten Herstellern sollte SAP den Auftrag aus dem B2B-Shop führen. Der Shop legt in Salesforce Auftrag und Order Summary an und schickt die Bestellung an SAP. SAP legt den Kundenauftrag an, liefert und fakturiert. Salesforce kennzeichnet solche Summaries als unmanaged, und die Schnittstelle schreibt Status, Lieferungen und Rechnungen zurück, damit Käufer sie im Shop sehen. Salesforce Order Management, in Growth als Lite und in Advanced voll enthalten, lohnt sich, wenn Salesforce selbst zuteilen, versenden, stornieren und retournieren soll. In einem Unternehmen, das die Auftragsabwicklung schon in SAP betreibt, wären das zwei Auftragssysteme.

Was passiert mit einer Bestellung in B2B Commerce?

Sendet ein Käufer im B2B-Shop auf Salesforce eine Bestellung ab, wandelt der Shop den Warenkorb in einen Auftrag um und legt eine Order Summary an. Die Order Summary ist der Datensatz, den Käufer in ihrer Bestellhistorie sehen, und der, mit dem Schnittstellen danach arbeiten.

Jede Order Summary hat das Feld OrderLifeCycleType. Der Developer Guide zu managed und unmanaged Order Summaries1 definiert es so:

• Managed kennzeichnet eine Order Summary, die Salesforce Order Management angelegt hat. Salesforce führt den Lebenszyklus.
• Unmanaged kennzeichnet eine Order Summary, die B2B Commerce angelegt hat und deren Lebenszyklus “often managed by an external order management system” ist. Änderungen dort “must be reflected in Salesforce”.

Dieses eine Feld beantwortet die Frage im Titel, zumindest technisch. Die organisatorische Antwort muss vorher kommen.

Zum Namen: Salesforce vermarktet B2B Commerce inzwischen auch als “Agentforce Commerce for B2B”. Am Auftragsmodell ändert das nichts.

Was leistet Salesforce Order Management?

Laut Trailhead2 deckt Order Management die Zuteilung (welcher Standort liefert), die Erfüllung (Kommissionieren, Verpacken, Versenden, Fakturieren) und den Service ab (Stornos, Nachlässe, Retouren, Ersatzlieferungen und Umtausch). Es bietet “a single view of orders, actions taken on orders, and order history”. Nach der Fakturierung exportiert es die Rechnungen ins ERP.

Das ist ein vollständiges Auftragsmanagement. Es passt zu Unternehmen, die aus mehreren Standorten liefern und Retouren und Umtausch in Salesforce abwickeln wollen, wie viele Einzelhändler. Ein Maschinenbauer mit SAP SD (Vertrieb), Lagerverwaltung und Fakturierung hat all das schon in SAP.

Order Management Lite in Growth, volles Order Management in Advanced

Die B2B-Preisseite3 nennt:

	Growth Edition	Advanced Edition
Order Management	Order Management Lite	Volles Order Management
Lagerorte	20	20
Preis	Auf Anfrage, Anteil am GMV	Auf Anfrage, Anteil am GMV

Zwei Fußnoten zählen mehr als die Tabelle. Aufträge “taken on other channels or integrated from any other third-party system” brauchen ein separat gekauftes Salesforce Order Management. Und Bestandskunden mit Order Management “will need to renew on Commerce Cloud Advanced”.

Warum SAP meist Herr des Auftrags bleiben sollte

Ich sehe in der Fertigung drei Gründe.

Die meisten Aufträge kommen nicht über den Shop. Telefon, E-Mail, EDI und Außendienst landen heute in SAP und werden es noch jahrelang tun. Würde Salesforce Order Management nur die Shop-Aufträge führen, arbeitet der Innendienst in zwei Systemen. Sollen alle Aufträge hinein, braucht es die separate Lizenz und eine Umstellung der Auftragsprozesse, die sich für ein Shop-Projekt selten rechnet.

Die Abwicklung liegt in SAP. Verfügbarkeitsprüfung, Lieferung, Kommissionierung, Warenausgang und Fakturierung sind dort eingerichtet, oft mit jahrelang gewachsener kundenspezifischer Logik. Das in Salesforce nachzubauen, ist ein eigenes Programm.

Kredit, Preise und Steuern liegen in SAP. Endgültig ist der Auftrag erst, wenn SAP ihn angenommen hat. Mein Artikel zu Händlerbestand und Nachschub folgt derselben Regel: Eine Anforderung wird erst zum verbindlichen Auftrag, wenn das ERP sie angenommen und eine Auftragsnummer zurückgegeben hat.

Der Shop ist also der Ort, an dem der Auftrag beginnt und an dem der Käufer ihn verfolgt. SAP ist der Ort, an dem er abgewickelt wird.

Was kommt aus SAP zurück, und wann?

Die Bestellhistorie im Shop zeigt nur, was SAP zurückschreibt. Salesforce bietet Käufern eine Reihe von Order-Summary-APIs4: Bestellhistorie, einzelne Order Summary, Delivery Groups, Positionen, Sendungen und Sendungspositionen. Dazu kommt Add Order to Cart, das eine frühere Bestellung für eine Nachbestellung in den Warenkorb kopiert.

Bei unmanaged Summaries befüllt Ihre Schnittstelle all das. Ich würde mindestens zurückschreiben:

• die SAP-Auftragsnummer, binnen Minuten nach der Bestellung,
• bestätigte Liefertermine pro Position,
• Lieferungen mit Sendungsnummern,
• Rechnungen oder einen Link darauf,
• Stornos und Änderungen, die der Innendienst in SAP vornimmt.

Der Integrationsnutzer braucht laut Developer Guide die Berechtigung B2B Commerce Integrator User oder Edit Unmanaged Order Summaries. Nutzen Sie einen eigenen Integrationsnutzer mit Zertifikat oder Client Credentials. Passwort-Logins für Connected Apps enden am 20. Februar 2027, wie in Passwort-Integrationen enden 2027 beschrieben.

Händler, die den Status im Chat abfragen wollen, brauchen dieselben Daten. Ein Agent, der den Auftragsstatus aus SAP liest, und die Bestellhistorie im Shop sollten dieselbe API nutzen, damit beide denselben Termin zeigen.

Den Auftrag für SAP mit CreateOrder formen

Der Extension Point Commerce_Domain_Checkout_CreateOrder “creates an order from cart information during checkout”, so die Liste der verfügbaren Extensions5. Dort ergänzen Sie, was SAP braucht und der Standardauftrag nicht hat, etwa Verkaufsorganisation, Auftragsart oder Versandbedingung. Die Prüfung, bevor der Auftrag existiert, also Kredit oder Liefersperre, gehört in Commerce_Domain_Checkout_PlaceOrder, wie in B2B-Checkout mit Bestellnummer beschrieben.

Halten Sie den Auftrag schlank. Jedes zusätzliche Feld ist ein Mapping, das in jedem Salesforce-Release getestet werden muss.

Rechenbeispiel: Shop auf Growth Edition für 180 Händler

Ein Kompressorenhersteller startet einen Shop auf Growth Edition für 180 Händler. Telefon- und EDI-Aufträge bleiben in SAP. Das Design könnte so aussehen:

1. Der Shop legt unmanaged Order Summaries an. Order Management Lite bleibt zunächst ungenutzt.
2. Die CreateOrder-Extension ergänzt Verkaufsorganisation und Auftragsart.
3. Die Middleware schickt den Auftrag an SAP und schreibt die Kundenauftragsnummer binnen zwei Minuten zurück.
4. Lieferungen und Rechnungen werden bei Änderung zurückgeschrieben, Stornos des Innendiensts ebenfalls.
5. Käufer sehen eine Bestellhistorie für Shop-Aufträge. Telefonaufträge bleiben im ersten Release im Shop unsichtbar, was der Innendienst weiß und erklärt.

Punkt fünf ist eine echte Grenze. Sollen alle SAP-Aufträge im Shop erscheinen, müssen auch Telefon- und EDI-Aufträge als Order Summaries nach Salesforce. Ob das die Fußnote der Preisseite zu Aufträgen aus anderen Kanälen berührt, klären Sie schriftlich mit Salesforce, bevor Sie Händlern eine vollständige Historie versprechen.

Erster Schritt: aufschreiben, wem der Auftrag in jedem Schritt gehört

Schreiben Sie auf, wem der Auftrag in jedem Schritt gehört, vom Warenkorb bis zur Rechnung, und welchen Status der Käufer in jedem Schritt sieht. Entscheiden Sie dann, ob Order Management überhaupt eine Rolle hat. Wie der Auftrag in die übrigen Datenflüsse passt, steht in B2B Commerce und SAP: Welche Daten fließen wohin, und das Kapitel zur ERP-Anbindung der Masterclass ordnet es ein. Eine unabhängige Prüfung solcher Designs gehört zu meiner Arbeit in der Salesforce-Architektur.

Quellen5

1. 1Developer Guide zu managed und unmanaged Order Summaries (öffnet in einem neuen Tab)developer.salesforce.com
2. 2Trailhead (öffnet in einem neuen Tab)trailhead.salesforce.com
3. 3B2B-Preisseite (öffnet in einem neuen Tab)salesforce.com
4. 4Order-Summary-APIs (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Liste der verfügbaren Extensions (öffnet in einem neuen Tab)developer.salesforce.com