SAP CPQ bis S/4 Public Cloud: Vom Angebot zum Auftrag

Kurzfassung: Die Übergabe vom Angebot zum Auftrag funktioniert, wenn das angenommene Angebot ohne Neuerfassung zum beabsichtigten Auftrag in S/4HANA Public Cloud wird. Klären Sie vor dem Go-live pro Entscheidung eine verantwortliche Stelle (Produktidentität, Konfiguration, Preis, Rabatt, Auftragsannahme) und testen Sie dann, was nach der Freigabe passiert: geänderte Mengen, abgelaufene Preise, Wiederholungen und ERP-Ablehnungen. Erwartetes Ergebnis zuerst aufschreiben, mit einer Produktfamilie beginnen und Nacharbeit an der eigenen Ausgangslage messen.

Der Kunde akzeptiert das Angebot. Danach erfasst jemand alles erneut im ERP, weil Konfiguration, Rabatt oder Materialnummer nicht zusammenpassen. Das Angebot war schneller, die manuelle Arbeit ist nur in die Auftragsabwicklung gewandert.

Die entscheidende Frage lautet deshalb nicht, ob SAP CPQ ein ansprechendes Angebot erzeugt. Sondern ob das angenommene Angebot zum beabsichtigten Auftrag in S/4HANA Public Cloud wird, mit dem richtigen kommerziellen Kontext in Sales Cloud V2. Wer noch entscheidet, ob CPQ überhaupt nötig ist, beginnt besser mit unserem Entscheidungsleitfaden zu CPQ neben S/4HANA Public Cloud. Dieser Beitrag setzt voraus, dass die Entscheidung gefallen ist und die Übergabe jetzt halten muss.

Den genauen Integrationspfad prüfen

SAP dokumentiert die Integration von Sales Cloud Version 2 mit CPQ über SAP Cloud Integration, eine Kundenauftragsintegration für CPQ Quote 2.0 auf der S/4HANA-Seite und die Integration von Sales Cloud V2 mit S/4HANA Public Cloud für Preissimulation und Auftragsübergabe. Damit sind unterstützte Szenarien belegt. Jede Anforderung Ihres Auftragsprozesses ist damit noch nicht geklärt.

Bevor Sie Integrationsinhalte auswählen, halten Sie vier Dinge fest: die CPQ-Engine und Angebotsversion, das Public-Cloud-Release, die aktivierten Scope Items und die API, über die der Auftrag tatsächlich angelegt wird (zum Beispiel die Kundenauftrags-API im SAP Business Accelerator Hub). Ein älterer Sales-Cloud-Leitfaden oder ein allgemeines S/4HANA-Beispiel beweist Ihre Zielarchitektur nicht. Den gesamten Weg von der Opportunity bis zur Rechnung beschreiben wir in Quote to Cash mit Sales Cloud V2 und S/4HANA Public Cloud.

Jede Entscheidung braucht eine verantwortliche Stelle

Entscheidung	Was zu klären ist
Produktidentität	Wie entsprechen sich Angebotsposition und ERP-Material, auch bei konfigurierbaren Materialien?
Konfiguration	Welche Engine wertet die Regeln dieser Produktfamilie aus: CPQ, Advanced Variant Configuration oder beide mit klarer Aufteilung?
Preis	Welches System bestimmt den endgültigen kommerziellen Wert, pro Preiselement?
Rabatt	Wer genehmigt Ausnahmen, und wann verfällt eine Freigabe?
Auftragsannahme	Welche ERP-Antwort macht die Übergabe erfolgreich?

Die Zeile zur Konfiguration verdient einen zweiten Blick. Wenn CPQ verkauft und die Advanced Variant Configuration in S/4HANA fertigt, entscheiden Sie pro Regeltyp, wo die Wahrheit liegt. Ein doppelt gepflegtes Regelwerk läuft auseinander, und das zeigt sich als Auftrag, den die Produktion nicht bauen kann.

Die letzte Zeile ist die wichtigste. Eine erfolgreiche HTTP-Antwort ist nicht automatisch ein angenommener Geschäftsauftrag. Definieren Sie, auf welchen ERP-Status sich der Verkauf verlassen kann (angelegt, kreditgesperrt, unvollständig, abgelehnt), wo dieser Status im CRM sichtbar wird und was geschieht, wenn die ERP-Prüfung die Anfrage ablehnt.

Änderungen nach der Freigabe testen

Nehmen Sie ein beispielhaftes konfigurierbares Produkt mit zwei Optionen, einer unzulässigen Kombination und einem freigabepflichtigen Rabatt. Geben Sie ein gültiges Angebot frei und ändern Sie danach Menge, Lieferadresse oder eine Option.

Aus diesem Test ergeben sich drei Fragen. Welche Änderungen lösen eine Neuberechnung aus? Welche machen die Freigabe ungültig? Und was passiert, wenn der Kunde eine ältere Angebotsversion annimmt?

Halten Sie die angenommene Version systemübergreifend nachvollziehbar: Angebotsnummer und Version in CPQ, die Referenz an der Opportunity in Sales Cloud und die externe Referenz am ERP-Auftrag. Das ist ebenso sehr eine geschäftliche Kontrolle wie eine Schnittstellenanforderung, denn genau danach fragen Revision und Kundendienst, wenn ein Auftrag strittig ist.

Die Fälle einbeziehen, die den Normalablauf stören

Testfall	Erwartetes Ergebnis, vorab aufgeschrieben
Preis zwischen Angebot und Annahme abgelaufen	Neuberechnung oder neue Freigabe, nie stillschweigend der alte Preis
Material im ERP nicht für den Verkauf freigegeben	Ablehnung für den Verkauf sichtbar, mit Begründung
Kundenstamm im ERP unvollständig	Auftrag gesperrt oder abgelehnt, mit namentlich zuständiger Person für die Datenkorrektur
Dasselbe angenommene Angebot zweimal gesendet	Ein ERP-Auftrag, nicht zwei
Angebot nach der Übergabe überarbeitet	Klare Regel, wer den ERP-Auftrag ändern darf
Ungültige Optionskombination	In CPQ gestoppt, erreicht das ERP nie

Schreiben Sie die erwarteten Ergebnisse vor der Demo auf. Sonst kann eine überzeugende Bildschirmfolge einen ungeklärten Auftragsprozess verdecken. Gerade der Dublettenfall ist günstig zu testen und teuer in der Produktion zu entdecken, weil er genau bei einer Wiederholung nach einem Timeout auftritt.

Entscheiden, ob CPQ der richtige erste Schritt ist

Komplexe Konfiguration, häufige Freigabeausnahmen und wiederholte Nacharbeit an Angeboten sind gute Gründe, CPQ zu prüfen. Bei BDTronic standen die Kompatibilitätsregeln für über 1’400 Komponenten in einem 60-seitigen Dokument, und jedes achte Angebot enthielt einen Konfigurationsfehler. Nach der CPQ-Einführung sank die Angebotsdurchlaufzeit um 70%, und Konfigurationsfehler traten nicht mehr auf. Das ist das Profil, bei dem sich das Regelwerk seine Lizenz verdient.

Ein kleiner Katalog mit einfacher Preisbildung braucht oft zuerst sauberere Daten und einen besseren bestehenden Ablauf. Kaufen Sie keine Konfigurations-Engine, um fehlende Produktverantwortung zu ersetzen.

Beginnen Sie mit einer Produktfamilie und einem Weg vom Verkauf zum Auftrag. Messen Sie Nacharbeit, abgelehnte Übergaben und Freigabedauer an Ihrer eigenen Ausgangslage, nicht an einer Prozentzahl eines anderen Kunden.

Häufige Fragen

Gibt es eine Standardintegration zwischen SAP CPQ und S/4HANA Public Cloud?

SAP dokumentiert Integrationsinhalte dafür: Sales Cloud V2 mit CPQ über SAP Cloud Integration und auf der S/4HANA-Seite eine Kundenauftragsintegration für CPQ Quote 2.0. Welches Szenario gilt, hängt von Ihrer CPQ-Engine, dem Public-Cloud-Release und den aktivierten Scope Items ab. Prüfen Sie es deshalb an Ihren eigenen Systemen, bevor Sie darauf aufbauen.

Welcher Fehler passiert bei der Übergabe vom Angebot zum Auftrag am häufigsten?

Ein technischer Erfolg, der kein fachlicher ist: Die Schnittstelle meldet die Nachricht als verarbeitet, aber der ERP-Auftrag ist gesperrt, unvollständig oder anders bepreist als das angenommene Angebot. Legen Sie fest, welcher ERP-Status als angenommener Auftrag gilt und wer handelt, wenn das ERP die Anfrage ablehnt.

Welches System sollte den Endpreis führen?

Ein einziges, pro Preiselement entschieden und schriftlich festgehalten. CPQ kann das kommerzielle Angebot berechnen oder Konditionen aus S/4HANA lesen; beides funktioniert. Zwei parallel gepflegte Preislogiken funktionieren nicht, weil Angebot und Rechnung auseinanderlaufen.

Wie viele Testfälle braucht ein erstes CPQ-Release?

Weniger als befürchtet, wenn es die richtigen sind. Eine konfigurierbare Produktfamilie, eine gültige und eine ungültige Kombination, ein freigabepflichtiger Rabatt, eine Änderung nach der Freigabe, eine Wiederholung und eine ERP-Ablehnung decken die meisten teuren Fehler ab. Schreiben Sie das erwartete Ergebnis jedes Falls vor der ersten Demo auf.

---

CPQ, Sales Cloud V2 und die S/4HANA-Seite sind eine Kette, und wir setzen alle drei mit einem Team um. Warum das genau an dieser Nahtstelle zählt, erklären der Leitfaden zum ERP- und CRM-Partner und der Beitrag zum integrierten SAP-Stack. Bringen Sie ein echtes Angebot mit: Wir verfolgen Produktregeln, Preisentscheidungen und ERP-Übergabe, bevor wir einen Umsetzungsumfang vorschlagen.