Angebotsfunktion in Shopware 6: Quote Management für B2B richtig einsetzen
Im B2B ist der Preis selten ein fester Wert auf dem Etikett. Er wird verhandelt: Der Einkäufer legt seinen Bedarf zusammen, fragt einen Sonderpreis an, der Vertrieb rechnet nach, es geht ein-, zweimal hin und her — und erst dann wird bestellt. Genau diesen Ablauf zwängen viele Shops in E-Mails und PDF-Anhänge, weil sie ihn technisch nicht abbilden. Shopware 6 bringt dafür mit dem Quote Management der B2B Components einen fertigen Prozess mit. Wann er trägt, wo seine Grenzen liegen und wie ein Angebot im entkoppelten Frontend funktioniert.
1. Warum das Angebot ein eigener Prozess ist — nicht nur ein Rabatt
Es ist verlockend, die Angebotsfunktion mit der Preislogik zu verwechseln. Kundenspezifische Preise, Staffeln und Vertragskonditionen lassen sich in Shopware sauber über Preisgruppen und Rule Builder abbilden — das ist gesetzter Katalogpreis. Ein Angebot ist etwas anderes: eine einmalige, verhandelte Vereinbarung über einen konkreten Warenkorb, oft zeitlich befristet und mit einer Rückkopplung zwischen Käufer und Verkäufer. Der Unterschied ist nicht kosmetisch. Beim Katalogpreis kennt das System den Preis vorab; beim Angebot entsteht er erst im Dialog. Wer beides in dieselbe Preistabelle presst, baut entweder eine unwartbare Sonderregel-Wüste oder verlagert die eigentliche Verhandlung doch wieder in die Mailbox. Das Quote Management trennt diese Fälle sauber und macht aus dem Warenkorb ein eigenes, nachvollziehbares Objekt mit Status und Historie.
2. Der Workflow von der Anfrage bis zur Bestellung
Der Ablauf im Quote Management folgt der realen Verhandlung. Der B2B-Kunde füllt seinen Warenkorb wie gewohnt und löst daraus statt einer Bestellung eine Angebotsanfrage aus — optional mit einem Kommentar, in dem er sein Anliegen beschreibt. Im Backend landet die Anfrage bei den Händlern, die das Angebot prüfen und gezielt einzelne Positionen rabattieren können, um es an den Bedarf des Kunden anzupassen. Der Kunde kann das zurückgespielte Angebot dann annehmen, ablehnen oder eine Änderung anfragen. Nimmt er an, wird er durch den Checkout geführt und das System erzeugt automatisch eine Bestellung auf Basis des akzeptierten Angebots. Wichtig für die Praxis: Der Warenkorb darf bei der Anfrage nicht leer sein — das Angebot hängt immer an konkreten Positionen, nicht an einer abstrakten Preisverhandlung.
3. Was ein Angebot technisch ist: State Machine und Gültigkeit
Hinter der Angebotsfunktion steckt kein Sonderfeld am Warenkorb, sondern ein eigenständiges Objekt mit einer Nummer (quoteNumber), einem Erstelldatum, einem Ablaufdatum (expirationDate), einer eigenen Preissumme und — entscheidend — einem Status aus einer State Machine (stateMachineState). Dass der Zustand über die State Machine läuft — dasselbe Muster wie bei Bestell- und Zahlungsstatus — ist mehr als ein Implementierungsdetail. Es bedeutet, dass jeder Übergang (angefragt, überarbeitet, angeboten, angenommen, abgelehnt) ein sauber definierter, protokollierbarer Schritt ist. Für das Projekt heißt das: An diese Übergänge lassen sich Flows hängen, etwa eine Benachrichtigung an den Vertrieb bei einer neuen Anfrage oder eine Erinnerung an den Kunden, bevor ein Angebot abläuft. Das Ablaufdatum ist dabei kein Deko-Feld — ein verhandelter Preis, der ewig gilt, ist im Einkauf ein kalkulatorisches Risiko.
4. Verfügbarkeit und Lizenz: Evolve, Beyond — nicht Community oder Rise
Der wichtigste Punkt vor jeder Planung: Das Quote Management ist Teil der modularen B2B Components und damit an die kommerzielle Shopware-Commercial-Erweiterung gebunden. Verfügbar ist es laut Doku ab dem Evolve-Plan (Evolve, Beyond). Die Community Edition und der Rise-Plan bringen keine native Angebotsfunktion mit. Diese Lizenzfrage vorab zu klären erspart die unangenehmste Sorte Überraschung im Projekt — nämlich die, bei der ein zentrales Feature bereits im Konzept steht, bevor jemand geprüft hat, ob es im gebuchten Plan überhaupt enthalten ist. Historisch existiert daneben noch die ältere B2B Suite; für Neuprojekte sind die B2B Components der Weg, an dem sich die Entwicklung orientiert.
5. Angebote im Headless-Frontend: die Store API und useB2bQuoteManagement
Wer sein Frontend entkoppelt betreibt, verliert das Quote Management nicht — die Funktionen liegen über die Store API bereit. Im Shopware-Frontends-Stack bündelt der Composable useB2bQuoteManagement den gesamten Ablauf: requestQuote() für die Anfrage aus dem Warenkorb, getQuoteList() für die Übersicht im Kundenkonto, declineQuote() und requestChangeQuote() für Ablehnung und Änderungswunsch, dazu Methoden für Zahl- und Versandart sowie createOrderFromQuote() für die abschließende Bestellung. Das Muster ist dasselbe wie beim restlichen Headless-Setup: Die Bestell- und Verhandlungslogik bleibt vollständig im Shopware-Backend, das Frontend ruft die entsprechenden Routen mit dem Context-Token auf und rendert nur die Oberfläche. Wer kein Vue-basiertes Frontend nutzt, spricht dieselben Store-API-Endpunkte direkt an — die Composables sind bequem, aber keine Voraussetzung.
6. Wann sich der Blick auf eine Custom-Lösung lohnt
Das native Quote Management deckt den klassischen Verhandlungsfall sauber ab. Es gibt aber Konstellationen, in denen der Standard-Workflow nicht ganz passt. Typisch: Ein Angebot muss vor der Bestätigung durch eine interne Freigabekette laufen, die von Auftragswert und Abteilung abhängt. Oder die Rabattierung soll nicht frei per Hand erfolgen, sondern gegen hinterlegte Konditionen aus dem ERP validiert werden, damit kein Vertriebler unter die Marge geht. Oder das Angebot muss zusätzliche Dokumente tragen — technische Zeichnungen, Freigabeprotokolle, ein kundenspezifisches Datenblatt. In solchen Fällen ist eine Erweiterung oder eine eigene Lösung auf Basis der Store API legitim, oft sogar der ehrlichere Weg, als den Standard mit Workarounds zu verbiegen. Die Faustregel bleibt dieselbe wie bei anderen B2B-Bausteinen: native Komponente, wenn der Standardprozess trägt und die Lizenz vorhanden ist; Custom-Lösung, sobald der Prozess Sonderlogik verlangt, die sich nicht sauber konfigurieren lässt. Die Frage ist nie „geht das native?", sondern „passt der native Ablauf zu dem, wie hier tatsächlich verhandelt wird?".
7. Fazit: Die Verhandlung gehört in den Shop, nicht in die Mailbox
Solange Angebote per E-Mail und PDF hin- und hergehen, ist der digitale Bestellprozess an genau der Stelle unterbrochen, an der im B2B das Geld verdient wird. Das Quote Management schließt diese Lücke mit einem klaren Objektmodell, einer nachvollziehbaren State Machine und einem Ablauf, der die reale Verhandlung abbildet — im Standard-Storefront wie im Headless-Frontend. Vor der Umsetzung stehen zwei Fragen: Ist die Lizenz vorhanden (Evolve oder Beyond)? Und deckt sich der Standardablauf mit dem, was zwischen Einkauf und Vertrieb tatsächlich passiert? Wenn beides passt, ist die native Funktion der schnellste Weg. Wenn nicht, ist die Store API die Grundlage für eine Lösung, die den echten Prozess abbildet — statt einen Idealfall, an dem beide Seiten vorbei arbeiten.
Du planst eine Angebotsfunktion in Shopware 6?
Lass uns in 30 Minuten klären, ob das native Quote Management deinen Verhandlungsprozess abbildet oder ob du eine Custom-Lösung über die Store API brauchst. Kein Sales-Call.