> Angebotsanfragen im B2B gestalten: Zustände, versionierte Angebote, Preisüberschreibungen, Gültigkeitsregeln, Umwandlung in Aufträge und Checkliste. > > Web page: https://balazscsorba.com/de/blog/b2b-rfq-quote-management · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/b2b-rfq-quote-management.md) · [Magyar](https://balazscsorba.com/hu/blog/b2b-rfq-quote-management.md) > Author: Balázs Csorba · Published: 2026-10-07 · Keywords: B2B quote management, RFQ workflow, request for quote e-commerce, quote to order conversion, quote versioning, quote expiry capture, Spryker quote request, negotiable quotes Adobe Commerce, quote approval workflow, quote data model [Blog](https://balazscsorba.com/de/blog)/Web-Engineering # Angebotsverwaltung im B2B: Workflow, Versionierung und Umwandlung in Aufträge Angebotsanfragen im B2B gestalten: Zustände, versionierte Angebote, Preisüberschreibungen, Gültigkeitsregeln, Umwandlung in Aufträge und Checkliste. [Balázs Csorba](https://balazscsorba.com/de/about)·7\. Oktober 2026·12 Min. Lesezeit - B2B quotes - RFQ workflow - Quote versioning - Order conversion - Quote expiry ![Drei Dokumentversionen in einer Reihe, über der letzten eine Uhr.](https://balazscsorba.com/images/blog/b2b-rfq-quote-management/cover.webp?v=64a6dc0c5f) ## Das Wichtigste in Kürze - Eine Angebotsanfrage ist ein Zustandsautomat auf einem Dokument; legen Sie Zustände, Versionen, Gültigkeit, Rechte und Umwandlung fest, bevor Sie Oberflächen entwerfen. - Jede Änderung an einem vereinbarten Feld erzeugt eine neue, unveränderliche Angebotsversion, und alte Versionen bleiben für den Audit-Trail lesbar. - Preisüberschreibungen gehören auf Versionspositionen mit Urheber, rollenbezogenen Schwellen und einem festgehaltenen Genehmiger; Rabatte sind Daten, kein Formularzustand. - Speichern Sie die Gültigkeit an der Version, prüfen Sie sie bei der Annahme und noch einmal bei der Umwandlung, und legen Sie ausdrücklich fest, was ein Ablauf bewirkt. - Machen Sie die Umwandlung in einen Auftrag über Angebot und angenommene Version idempotent, und halten Sie LLM-Unterstützung um das Dokument herum, nie bei der Preisbildung. Auf dieser Seite 1. [Ist eine Angebotsanfrage ein Formular oder ein Zustandsautomat?](https://balazscsorba.com/#answer-rfq-is-a-workflow-not-a-form) 2. [Wie sieht der Lebenszyklus vom Warenkorb bis zum Auftrag aus?](https://balazscsorba.com/#lifecycle-cart-to-order) 3. [Was muss eine Angebotsversion enthalten?](https://balazscsorba.com/#versioning-and-negotiation) 4. [Wer darf rabattieren, wer darf genehmigen?](https://balazscsorba.com/#permissions-and-price-overrides) 5. [Was sollte geschehen, wenn ein Angebot abläuft?](https://balazscsorba.com/#expiry-and-re-quoting) 6. [Wie wird ein angenommenes Angebot zum Auftrag?](https://balazscsorba.com/#conversion-to-order-and-erp) 7. [Was liefern die Plattformen tatsächlich aus?](https://balazscsorba.com/#platform-support) 8. [Wie sieht das Datenmodell aus?](https://balazscsorba.com/#data-model) 9. [Wo passt LLM-Unterstützung, und wo nicht?](https://balazscsorba.com/#llm-assistance-later) 10. [Bau-Checkliste: Tabellen, Zustände und Tests](https://balazscsorba.com/#build-checklist) 11. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:000:00 **Eine Angebotsanfrage im B2B ist ein Zustandsautomat auf einem Dokument.** Ein Käufer fragt für einen Warenkorb nach einem Preis, der Verkäufer antwortet mit einer Zahl, der Käufer macht ein Gegenangebot, und irgendwann nimmt jemand an. Teams beginnen meist mit einem Formular. Monate später stellen sie fest, dass das Angebot in E-Mails lebt, der Preis kein Gültigkeitsdatum hat, ein Verkäufer eine Position änderte, nachdem der Käufer sie angenommen hatte, und niemand sagen kann, auf welcher Version der Auftrag beruhte. Dieser Beitrag behandelt das Angebot als versioniertes, rechtegebundenes Objekt mit Ablaufdatum, Audit-Trail und einem Umwandlungsschritt in einen Auftrag. Er behandelt den Lebenszyklus, die Versionsregeln, wer rabattieren und genehmigen darf, was ein Ablauf bewirken sollte, sowie ein Datenmodell mit Checkliste. Preisregeln und Konfiguration sind ein eigenes Problem, beschrieben in [Headless-Produktkonfiguratoren für B2B](https://balazscsorba.com/de/blog/headless-product-configurator-b2b), und die Gesprächsführung behandelt [KI-Support für B2B-Shops](https://balazscsorba.com/de/blog/ai-assistant-b2b-shop-customer-support). Die LLM-Seite des Angebots steht in [LLM-gestützter RFQ-Automatisierung](https://balazscsorba.com/de/blog/llm-rfq-quote-automation). Hier liegt der Fokus auf Plattform und Workflow. ## Ist eine Angebotsanfrage ein Formular oder ein Zustandsautomat? **Eine Angebotsanfrage ist ein Zustandsautomat auf einem Dokument, kein Formular, das eine E-Mail verschickt.** Fünf Produktentscheidungen definieren sie: in welchen Zuständen ein Angebot sein kann, ob jede Änderung eine Version erzeugt, wer Preise wie stark ändern darf, wann ein Angebot nicht mehr gültig ist und wie ein angenommenes Angebot zum Auftrag wird. Treffen Sie diese fünf Entscheidungen zuerst, dann folgen die Oberflächen. Lassen Sie sie offen, wird die Funktion in E-Mails, Tabellen und Chatverläufen nachgebaut, mit denselben Problemen. ## Wie sieht der Lebenszyklus vom Warenkorb bis zum Auftrag aus? **Der Lebenszyklus läuft vom Warenkorb über einen Angebotsentwurf und Verhandlung und Freigabe bis zum Auftrag.** Die Namen unterscheiden sich, die Form ist auf den Plattformen aber ähnlich. Spryker lässt einen Käufer aus dem Warenkorb eine Angebotsanfrage erstellen, eine Notiz hinzufügen, Lieferadresse und Versandart festlegen und den Verhandlungsverlauf sehen. Nach dem Einreichen steht die RFQ im Status `Draft`, und ein Agent kann sie überarbeiten und zurücksenden. Käufer können eine RFQ auch wieder in den Warenkorb umwandeln. Die [RFQ-Dokumentation von Spryker](https://docs.spryker.com/docs/pbc/all/request-for-quote/latest/request-for-quote) beschreibt diese Schritte, ihr Aktualisierungsdatum ist aber alt; behandeln Sie die Feldliste daher als Ausgangspunkt und prüfen Sie den Release, den Sie einsetzen. Adobe Commerce B2B nutzt ein anderes Vokabular mit ähnlicher Form. Eine Anfrage erscheint als New, und der Käufer kann sie ändern, bis der Verkäufer sie öffnet. Der Verkäufer speichert einen Entwurf oder sendet sie, dann steht sie auf Submitted, und er kann sie erst wieder ändern, wenn der Käufer sie zurückschickt. Der Käufer sieht Pending, solange verhandelt wird. Die [Adobe-Dokumentation zu Angeboten](https://experienceleague.adobe.com/en/docs/commerce-admin/b2b/quotes/quotes), aktualisiert im Oktober 2026, sagt am deutlichsten, wer das Angebot in jedem Status anfassen darf; genau dieses Detail braucht eine Rechtematrix. Das Modul Commerce Quotes von SAP Commerce Cloud argumentiert von der anderen Seite. Das Angebot wird von beiden Parteien verhandelt, bis eine Einigung steht, und dann legt der Käufer das Angebot in den Checkout und gibt die Bestellung auf. In der Dokumentation 2205 hängt der Status von der Rolle ab: Der Käufer sieht Submitted, während der Vertriebsmitarbeiter für dasselbe Angebot Requested sieht. ![Angebotszustände vom Warenkorb bis zum Auftrag Fünf Zustände von links nach rechts: Ein Warenkorb wird zur Anfrage, der Käufer reicht sie ein, eine überarbeitete Version wandert hin und her, bis der Preis angenommen ist, und das angenommene Angebot wird zu einem Auftrag. Abgelaufene Angebote verlassen die Schleife und müssen als neue Version neu angeboten werden.](https://balazscsorba.com/images/blog/b2b-rfq-quote-management/diagram-8.webp?v=0de008f46f) Die Angebotsschleife: Ein eingereichtes Angebot wird so oft überarbeitet wie nötig, jede Überarbeitung ist eine neue Version, und die Annahme fixiert den Preis vor der Umwandlung in einen Auftrag. Zu modellieren ist die Vereinigung dieser Vokabulare: eine aus dem Warenkorb abgeleitete Anfrage, ein Entwurf, den nur der Verkäufer sieht, ein eingereichter Zustand, den der Käufer besitzt, ein überarbeiteter Zustand mit neuer Version, ein angenommener Zustand mit fixierten Preisen und Versand, ein umgewandelter Zustand, der auf einen Auftrag zeigt, und ein Endzustand abgelaufen oder storniert. Halten Sie die internen Namen stabil und bilden Sie sie in der Oberfläche auf rollenspezifische Bezeichnungen ab. Käufer und Vertriebsmitarbeiter können für denselben Sachverhalt unterschiedliche Wörter sehen, wie bei SAP, aber der Sachverhalt muss ein einziger Datensatz sein. ## Was muss eine Angebotsversion enthalten? **Eine Angebotsversion ist ein unveränderlicher Snapshot von Preisen, Mengen, Versand und Kommentaren zu einem Verhandlungsschritt.** Versionierung trennt ein Angebot von einer Diskussion. Ohne sie ändert der Verkäufer den Preis direkt, der Käufer nimmt eine Zahl an, die es nicht mehr gibt, und eine Auditfrage lässt sich nicht beantworten. Die sichere Regel: Eine Änderung an einem vereinbarten Feld erzeugt eine neue Version, und alte Versionen bleiben lesbar. SAP macht das ausdrücklich: Während ein Angebot die Verhandlung durchläuft, wird für den nächsten Schritt im Workflow eine Kopie des Angebots erstellt. Spryker behandelt Angebotsversionen als Daten; seine Importspezifikation beschreibt eine Datei, die Versionen nach Referenz, Firmenbenutzer und Status konfiguriert. Adobe führt auf der Anfrage ein Paar aus Käufer- und Verkäuferstatus und lässt beide Seiten vor der Annahme Mengen ändern, Positionen entfernen, Positionskommentare hinzufügen und Rabatte anpassen. Jede Version braucht mindestens diese Angaben: Mengen und Stückpreise; Rabatte oder Überschreibungen je Position mit Urheber; Versandart und Kosten; Positionskommentare; Anhänge wie Spezifikationen; und Akteur und Zeitstempel der Änderung. Das Entitätsmodell von Shopware ist eine brauchbare Referenz für diese Trennung. Es unterscheidet Angebot, einen Liefersatz mit Versandart und Versanddaten, Positionen, einen Transaktionssatz mit Zahlbetrag und externer Referenz, Kommentare, Mitarbeiterzuordnungen und Dokumente. Die Dokumentation sagt, derzeit werde nur der Positionstyp Produkt unterstützt; eine Service- oder Frachtposition braucht also ein eigenes Modell. Ein neues Angebot nach Ablauf darf keine Historie verlieren. Das neue Angebot ist eine neue Version, die mit der vorherigen verknüpft ist, sodass der Audit-Trail weiterhin den ursprünglichen Preis, den Ablauf und den Grund für das neue Angebot zeigt. ## Wer darf rabattieren, wer darf genehmigen? **Rechte entscheiden, wer rabattieren und wer genehmigen darf, und sie gehören in eine ausdrückliche Konfiguration je Firmenrolle, nicht in Codepfade.** Über Plattformen hinweg tauchen zwei Steuerungsdimensionen auf. Die erste ist der Wert: wie viel rabattiert werden darf und wann eine Führungskraft genehmigen muss. Die zweite ist das Budget: welche Kostenstelle und welches Budget ein Angebot belastet. Der Approval Process von Spryker verlangt vor dem Checkout die Freigabe durch eine Führungskraft. Er wird je Firmenrolle konfiguriert und startet, wenn die Warenkorbsumme einen Betrag überschreitet, der in der Berechtigung Buy up to grand total festgelegt ist. Die Funktion Purchasing Control ergänzt Budgets und Kostenstellen. Käufer ordnen sie dem Warenkorb beim Checkout oder einer Angebotsanfrage zu, und Agenten können dasselbe im Auftrag des Kunden tun. Das sind zwei getrennte Prüfungen, und ein Angebot kann beide brauchen. Adobe geht bei Rabatten anders vor. Während der Verhandlung kann der Verkäufer einen Positionsrabatt oder einen Angebotsrabatt setzen, und die Dokumentation hält fest, dass nach der Annahme eines verhandelten Angebots und seinem Übergang in den Checkout keine weiteren Rabatte hinzugefügt werden können. Diese Regel lohnt die Übernahme: Nach der Annahme ist der Preis ein Vertragsbestandteil, kein bearbeitbares Feld. Zu bauen ist eine Preisüberschreibungsregel mit Schwellen. Ein Vertriebsmitarbeiter darf eine Position innerhalb eines Bands überschreiben; darüber muss eine zweite Rolle genehmigen; unter einer Untergrenze verweigert das System. Speichern Sie die Regel als Daten je Firma oder Rolle und halten Sie den Genehmiger an der Position fest. Fest codierte Prozentsätze im Angebotsservice sind der Weg, wie eine Rabattregel zum Support-Ticket wird. **Der Preis ist ein gespeichertes Feld, kein Zustand der Oberfläche** Ein in ein Formular getippter Rabatt ist nur ein Vorschlag, bis er mit Urheber und Zeitstempel auf einer Versionsposition gespeichert ist. Jede Preisänderung nach der Annahme braucht eine neue Version und eine neue Freigabe, nie eine stille Änderung der angenommenen Version. ## Was sollte geschehen, wenn ein Angebot abläuft? **Der Ablauf ist ein gespeichertes Datum an der Version, wird durch einen Job durchgesetzt und sollte in einem sichtbaren Zustand enden, nicht in einem stillen.** Ein angebotener Preis ist ein Versprechen für einen Zeitraum, und Plattformen gehen damit unterschiedlich um. Adobe Commerce hat einen Standard-Gültigkeitszeitraum, der in Tagen, Wochen oder Monaten gesetzt werden kann. Spryker-Agenten können die Gültigkeit eines Angebots bis auf die Minute festlegen. Die Angebotsdokumentation von Odoo enthält ein Feld für das Ablaufdatum, und Angebotsvorlagen können eine Ablauffrist tragen. Die Plattformdokumentation, die ich gelesen habe, klärt nicht, was beim Ablauf geschieht; die Adobe-Seiten sagen nicht, ob ein Angebot automatisch schließt oder nur warnt. Entscheiden Sie das selbst. Drei Optionen sind üblich: das Angebot sperren, sodass der Käufer es nicht mehr annehmen kann; es mit einem neuen Preis als neue Version neu ausstellen, die der Verkäufer genehmigen muss; oder beide Seiten vor dem Ablauf warnen. Ein vernünftiger Standard ist eine Warnung vor dem Ablauf, eine Sperre beim Ablauf und eine Neuanfrage mit einem Klick, die aus der alten eine neue Version erzeugt und den alten Preis im Audit-Trail sichtbar lässt. Speichern Sie die Gültigkeit an der Version, nie in der Oberfläche. Entscheidet der Browser, ob ein Angebot noch gilt, kann ein Käufer aus einem alten Tab einen veralteten Preis annehmen, und ein Hintergrundjob kann die Wahrheit nicht erkennen. Die Prüfung bei der Annahme muss den gespeicherten Zeitstempel lesen, und dieselbe Prüfung sollte bei der Umwandlung noch einmal laufen, denn eine Annahme von letzter Woche ist keine Umwandlung von heute. ## Wie wird ein angenommenes Angebot zum Auftrag? **Die Umwandlung ist der Schritt, in dem das verhandelte Dokument zu einem kommerziellen Auftrag wird, und sie muss genau einmal geschehen.** Bei einem Shop-first-Aufbau läuft das angenommene Angebot über den normalen Checkout, die Preise werden übernommen. Adobe wendet verhandelte Preise im Checkout an und sperrt Versand und Rabatte. Spryker kann eine RFQ wieder in einen Warenkorb umwandeln, der dann den üblichen Checkout durchläuft, einschließlich einer etwaigen Freigabe. Bei einem ERP-first-Aufbau wird das angenommene Angebot im ERP zu einem Kundenauftrag, und der Shop zeigt ihn nur an. Die SAP-Dokumentation beschreibt, dass der Käufer das Angebot in den Checkout legt und eine Bestellung aufgibt. Wie Verträge und Daueraufträge aus einem angenommenen Angebot entstehen, hängt vom ERP ab; dieser Artikel prüft diesen Schritt nicht. Welchen Weg Sie auch wählen, die Umwandlung braucht einen Idempotenzschlüssel, etwa die Angebots-ID zusammen mit der Nummer der angenommenen Version. Zwei Klicks oder ein Wiederholungsversuch nach einem Timeout müssen einen Auftrag ergeben. Dieselbe Referenz sollte in den ERP-Kundenauftrag übergehen, damit eine Wiederholung das bestehende Dokument findet und nicht ein zweites anlegt. ## Was liefern die Plattformen tatsächlich aus? **Die großen Plattformen liefern Verhandlungsfunktionen, unterscheiden sich aber bei Positionsrabatten, Freigabe und Ablauf; prüfen Sie die Tabelle, bevor Sie sich entscheiden.** Daten zählen, weil sich diese Funktionen verändern. Die RFQ-Seite von Spryker ist veraltet, während die Seiten zu Purchasing Control und Approval Process neuer sind. Die hier genannten SAP-Status stammen aus der Dokumentation 2205, und neuere Releases können das Modul umstrukturieren. Die Angebotsverwaltung von Shopware gehört zu den B2B-Komponenten der Commercial-Erweiterung, verfügbar ab dem Evolve-Tarif, nicht in der Community Edition. Händler können einzelnen Angebotspositionen Kommentare und Rabatte hinzufügen, Versandkosten einbeziehen und Änderungen über den Verlauf von Angebot, Nachrichten und Dokumenten nachverfolgen. Das Open-Source-Bundle E-Commerce Framework von Pimcore ist als GPL-Version am Lebensende, das Framework ist in die Enterprise Edition gewechselt. Ein Pimcore-Shop, der Angebote braucht, baut sie deshalb am wahrscheinlichsten auf Data Objects mit der eigenen Versionierung von Pimcore oder lizenziert das Enterprise-Bundle. Einen öffentlichen Preis zum Vergleich gibt es nicht. Produktdaten und ihre ERP-Synchronisation sind ein anderes Thema, beschrieben in [Pimcore ERP Delta-Sync](https://balazscsorba.com/de/blog/pimcore-erp-delta-sync). Plattform Verhandlung und Versionen Positionsrabatt durch Verkäufer Freigabe und Budget Gültigkeit Spryker RFQ aus Warenkorb; Agent überarbeitet und sendet zurück; Versionen als Daten Vertrieb kann Preise ändern und überschreiben Approval Process je Rolle; Budgets und Kostenstellen an RFQs Gültigkeit auf die Minute genau SAP Commerce Cloud (Doku 2205) Kopie des Angebots je Schritt; Status je Rolle verschieden In den gelesenen Seiten nicht verifiziert Getrennte Schwellen für Angebot und Genehmiger In den gelesenen Seiten nicht verifiziert Adobe Commerce B2B New, Submitted, Pending; beide Seiten tauschen Änderungen aus Ja: auf Positions- oder Angebotsebene Über Admin-Rollenrechte gesteuert Standard-Gültigkeit in Tagen, Wochen oder Monaten Shopware 6 Commercial Angebotsverwaltung; Verlauf von Angebot, Nachrichten und Dokumenten Ja: Kommentare und Rabatte je Angebotsposition Order Approval und Organization Units aufgeführt In den gelesenen Seiten nicht verifiziert Pimcore (individuell) Data Objects mit Pimcore-Versionierung Eigener Code und eigene Regeln Eigener Code und eigene Regeln Eigener Code und eigene Regeln ## Wie sieht das Datenmodell aus? **Das Datenmodell hat ein stabiles Angebot, eine Version je Verhandlungsschritt, Positionen, die zu einer Version gehören, und Nachrichten- und Audit-Tabellen, die auf Angebot oder Version zeigen.** Eine flache Angebotstabelle mit einer Preisspalte kann keine Historie abbilden. Das Modell hält das Angebot als stabile Identität und legt alles Veränderliche in eine Version. ![Datenmodell des Angebots: Identität, Versionen, Positionen und Verknüpfungen zu Auftrag und Audit Der Angebotskopf hält die stabile Identität und den Status. Jeder Verhandlungsschritt ist eine quote_version-Zeile. Jede Version besitzt quote_line-Zeilen mit Preis, eventuellem Override und Rabatt. Eine Version verweist auf einen quote_message-Verlauf und quote_attachment-Zeilen. quote_event ist die Audit-Tabelle und hängt am Angebot; Der Shop-Auftrag wird über einen Fremdschlüssel vom Angebotskopf referenziert, der ERP-Kundenauftrag von den Angebotspositionen.](https://balazscsorba.com/images/blog/b2b-rfq-quote-management/diagram-36.webp?v=66a92837bb) Datenmodell des Angebots: Der Kopf ist die stabile Identität, jeder Verhandlungsschritt eine Versionszeile, Positionen und Überschreibungen gehören zu einer Version, und Nachrichten, Anhänge und Audit-Ereignisse verweisen auf Angebot oder Version. Die Überschreibungen liegen an der Versionsposition. Halten Sie den ursprünglichen Listenpreis neben dem angebotenen Preis fest, dazu Rabattart und -wert, Urheber und Verweis auf die Freigabe, damit ein Prüfer die Marge sieht, ohne sie nachzurechnen. Der Angebotskopf trägt nur den Status und Zeiger auf die aktuelle und die angenommene Version. Externe Verweise gehen auf der Commerce-Seite zum Shop-Auftrag und auf der Back-Office-Seite zum ERP-Kundenauftrag. ## Wo passt LLM-Unterstützung, und wo nicht? **LLM-Unterstützung gehört rund um das Angebotsdokument, nicht in seine Preislogik.** Nützliche Aufgaben sind der Entwurf des Begleittextes aus dem strukturierten Angebot, die Zusammenfassung eines langen Nachrichtenverlaufs für die nächste Person, die das Angebot übernimmt, die Übersetzung eines Positionskommentars und das Markieren von Positionen mit fehlenden Daten, etwa ohne Einheit, ohne Liefertermin oder mit einer Menge, die von der Anfrage abweicht. Jede Ausgabe ist ein Vorschlag, den ein Mensch prüft, bevor der Käufer ihn sieht. Die Grenze ist klar. Der Assistent setzt nie einen Preis, wendet nie einen Rabatt an und nimmt nie ein Angebot an. Die Preisbefugnis bleibt bei der Regel aus dem Abschnitt zu Rechten, und der Audit-Trail hält fest, ob ein Mensch einen Assistentenentwurf freigegeben hat. Die Dokumentation zu AI Commerce von Spryker führt einen Back Office Assistant auf, ein KI-Chatfenster im Back Office, was zeigt, dass Assistenten neben dem Angebotswesen in die Back-Office-Arbeit einziehen. Die Verhandlung selbst bleibt ein gesteuertes Dokument. Der modellseitige Entwurf für die Auswertung von Anfragen und das Formulieren von Antworten steht in [LLM-gestützte RFQ-Automatisierung](https://balazscsorba.com/de/blog/llm-rfq-quote-automation). ## Bau-Checkliste: Tabellen, Zustände und Tests **Bauen Sie Zustände, Tabellen und Tests vor den Oberflächen.** Die folgende Checkliste ist das Mindestmaß, auf das sich ein Team vor Beginn der Entwicklung einigen sollte. Jeder Punkt entspricht einer der Entscheidungen weiter oben im Artikel. 1. Definieren Sie die Zustände und erlaubten Übergänge, und weisen Sie jeden nicht aufgeführten Übergang ab. 2. Legen Sie die Tabellen quote, quote\_version, quote\_line, quote\_message, quote\_attachment und quote\_event an; aktualisieren Sie eine Versionszeile nach der Annahme nie. 3. Schreiben Sie die Preisüberschreibungsregel als Daten je Rolle mit Schwellen, und halten Sie den Genehmiger je Position fest. 4. Speichern Sie die Gültigkeit an der Version und betreiben Sie einen Ablaufjob, der Angebote sperrt und ein Ereignis auslöst. 5. Machen Sie die Umwandlung idempotent über Angebots-ID und Nummer der angenommenen Version. 6. Testen Sie den vollständigen Pfad: Der Käufer reicht ein, der Verkäufer kontert, der Käufer nimmt an, ein Auftrag entsteht, und eine zweite Annahme liefert denselben Auftrag zurück. 7. Testen Sie die Negativfälle: Eine abgelaufene Annahme wird abgewiesen, eine Überschreibung über der Schwelle wird ohne Freigabe abgewiesen, und eine wiederholte Umwandlung legt nichts Neues an. ``` // Sketch: allowed transitions are data, and anything else is rejected const allowed: Record = { draft: ['submitted', 'cancelled'], submitted: ['revised', 'accepted', 'expired', 'cancelled'], revised: ['submitted', 'accepted', 'expired', 'cancelled'], accepted: ['converted'], expired: ['revised'], // re-quoting creates a new version, never edits the old one converted: [], cancelled: [], } function transition(quote: Quote, to: QuoteState, actor: Actor) { if (!allowed[quote.state].includes(to)) throw new Error(`illegal ${quote.state} -> ${to}`) if (to === 'accepted' && quote.validUntil < new Date()) throw new Error('quote expired') return { ...quote, state: to, events: [...quote.events, { to, actor, at: new Date() }] } } ``` Ein Playwright-End-to-End-Test kann den vollständigen Pfad gegen eine Shop-Sandbox durchspielen, und die Negativfälle gehören in Unit-Tests des Zustandsautomaten. Wenn Sie einen B2B-Angebotsprozess bauen oder prüfen, sehen Sie sich meine [B2B-E-Commerce-Arbeit](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer) an. ## Quellen 1. [Spryker: request for quote feature](https://docs.spryker.com/docs/pbc/all/request-for-quote/latest/request-for-quote) 2. [Spryker: quote request import file details](https://docs.spryker.com/docs/pbc/all/request-for-quote/latest/import-and-export-data/file-details-quote-request.csv) 3. [Spryker: Approval Process feature overview](https://docs.spryker.com/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/approval-process-feature-overview) 4. [Spryker: Purchasing Control feature overview](https://docs.spryker.com/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/purchasing-control-feature-overview) 5. [Adobe Commerce B2B: negotiable quotes](https://experienceleague.adobe.com/en/docs/commerce-admin/b2b/quotes/quotes) 6. [Adobe Commerce B2B: configure quotes](https://experienceleague.adobe.com/en/docs/commerce-admin/b2b/quotes/configure-quotes) 7. [SAP Commerce: Commerce Quotes (2205 documentation)](https://help.sap.com/docs/SAP_COMMERCE/9d346683b0084da2938be8a285c0c27a/18f87a040b814781a459fe60fb28c912.html) 8. [SAP Commerce: quote statuses (2205 documentation)](https://help.sap.com/docs/SAP_COMMERCE/4c33bf189ab9409e84e589295c36d96e/5958905dbb1e4e62b117f5448bb91e63.html) 9. [Shopware: B2B Components](https://docs.shopware.com/en/shopware-6-en/commercial-features/b2b-components) 10. [Shopware: quotes management entities and schema](https://developer.shopware.com/docs/products/extensions/b2b-components/quotes-management/concepts/entities-and-schema) 11. [Odoo 20 documentation: quotation deadline](https://www.odoo.com/documentation/20.0/applications/sales/sales/sales_quotations/deadline.html) 12. [Pimcore: E-Commerce Framework bundle (GPL version end of life)](https://github.com/pimcore/ecommerce-framework-bundle) ## Häufige Fragen Worin unterscheidet sich eine Angebotsanfrage von einem Angebot im B2B-Handel? Eine Angebotsanfrage (RFQ) ist die Bitte des Käufers um Preise für einen Warenkorb oder eine Artikelliste. Das Angebot ist die Antwort des Verkäufers, über die verhandelt wird. Viele Plattformen verwenden ein Objekt für beides und benennen die Zustände unterschiedlich; modellieren Sie die gesamte Verhandlung daher als ein Dokument mit Versionen. Soll ein Angebot direkt bearbeitet oder versioniert werden? Versionieren Sie. Jede Änderung an einem vereinbarten Feld erzeugt eine neue, unveränderliche Version mit Urheber und Zeitstempel. Direkte Änderungen machen es unmöglich nachzuweisen, welchen Preis der Käufer angenommen hat und welcher Auftrag darauf beruht. Wie werden Rabatte auf Angebotspositionen freigegeben? Verwenden Sie eine Regel, die pro Firmenrolle als Daten gespeichert ist: Ein Vertriebsmitarbeiter darf innerhalb eines Bands überschreiben, darüber genehmigt eine zweite Rolle, und alles unter einer Untergrenze wird abgelehnt. Halten Sie den Genehmiger an der Position fest. Adobe Commerce dokumentiert, dass nach dem Übergang eines verhandelten Angebots in den Checkout keine zusätzlichen Rabatte mehr hinzugefügt werden können. Was sollte passieren, wenn ein Angebot abläuft? Legen Sie das ausdrücklich fest. Übliche Optionen sind das Sperren des Angebots, die Neuausstellung als Version, die eine Freigabe braucht, oder eine Warnung an beide Seiten vor dem Ablauf. Speichern Sie den Gültigkeitszeitstempel an der Version und prüfen Sie ihn bei der Annahme und erneut bei der Umwandlung. Kann ein LLM bei der Angebotsverwaltung helfen? Ja, rund um das Dokument: beim Entwurf des Begleittextes, bei der Zusammenfassung eines Nachrichtenverlaufs oder beim Markieren fehlender Positionsdaten. Ein Mensch prüft jede Ausgabe. Der Assistent setzt keine Preise, wendet keine Rabatte an und nimmt kein Angebot an. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [B2B-E-Commerce & PIM →](https://balazscsorba.com/de/expertise/b2b-ecommerce-developer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Schema.org-Strukturdaten für B2B-Shops: Preise hinter Logins, Einheiten und Varianten](https://balazscsorba.com/de/blog/schema-org-structured-data-b2b-shop) - [Ein KI-Assistent für den Support im B2B-Shop: Tools, Berechtigungen und die Übergabe an Menschen](https://balazscsorba.com/de/blog/ai-assistant-b2b-shop-customer-support) - [Streaming-Chat mit KI in Vue und Nuxt: von Anfang an barrierefrei](https://balazscsorba.com/de/blog/vue-ai-chat-ui-streaming-accessibility) - [Eine LLM-Übersetzungspipeline für i18n: Glossar, Platzhalter und Review](https://balazscsorba.com/de/blog/llm-translation-pipeline-i18n) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)