Architektur für Shopify-B2B-Angebote: Was in Shopify bleibt und was in die Angebotsebene gehört

Lassen Sie Shopify das führende System für alles sein, wofür es bereits ein Objekt hat – Produkte, Varianten, Bestand, Kunden, Unternehmen, Standorte, Katalogpreise, Zahlungsziele, Bestellentwürfe und Bestellungen – und geben Sie der Angebotsebene nur das, wofür Shopify kein Objekt hat: die Anfrage des Käufers, die Angebote des Verkäufers mit ihren Versionen, Gegenangebote, Freigaben, das Prüfprotokoll der Verhandlung und die Preise zu dem Zeitpunkt, an dem sie vereinbart wurden.

Die Angebotsebene liest Shopify live, speichert Referenzen und datierte Momentaufnahmen statt Kopien und übergibt Shopify genau einen Bestellentwurf, sobald der Preis steht. Das ist die ganze Architektur; der Rest dieser Seite ist die Begründung und die Mechanik, geprüft gegen Shopifys eigene Dokumentation.

Geschrieben für die Agentur oder den Entwickler, der einen B2B-Aufbau plant, nicht für den Händler, der eine App auswählt. Es gilt unabhängig davon, ob die Angebotsebene eine App, eine Eigenentwicklung oder ein CPQ ist – die Wahl zwischen diesen dreien ist die Aufgabe des Entscheidungsleitfadens; wo ein Abschnitt beschreibt, wie QuotWay es macht, ist das als Beispiel für das Muster gemeint, nicht als das Muster selbst.

Die Regel: keine zweite Commerce-Datenbank

Jedes B2B-Angebotsprojekt stößt früh auf dieselbe Versuchung. Angebote brauchen Produkttitel, Preise, Kundennamen, Unternehmensdaten und Lagerbestände, also legt sich das Angebotssystem eigene Tabellen für Produkte, Preise und Kunden an – und ein Quartal später hat der Shop zwei Kataloge, zwei Preislisten und zwei Kundendatensätze, die sich widersprechen. Shopifys natives B2B-Modell besitzt jedes dieser Objekte bereits und ändert sie, ohne jemandem Bescheid zu sagen: Ein Händler bearbeitet einen Katalogpreis, ein Standort bekommt einen zweiten Katalog, eine Variante wird gelöscht, ein Kontakt wechselt den Standort.

Die Regel, die das verhindert, ist kurz. Shopify besitzt jedes Objekt, das es hat; die Angebotsebene besitzt nur die Objekte, die Shopify fehlen. Wo die Angebotsebene einen Wert aus Shopify halten muss – einen Titel auf dem Angebots-PDF, den Preis, von dem eine Verhandlung ausging –, hält sie ihn als datierte Momentaufnahme mit der Shopify-ID daneben, damit der Datensatz sagt: „Das stand am 14. März im Katalog“, und nie: „Das ist der Preis.“

Das native Modell ist enger, als es aussieht, und genau das macht die Trennung sauber. Shopifys B2B-Objekte sind Unternehmen, Unternehmensstandorte, Unternehmenskontakte, Kataloge (eine Produktauswahl plus Preisliste, Mengenregeln und Mengenpreise) und Bestellentwürfe; der Standort ist die Einheit, an die verkauft wird: Kataloge, Zahlungsziele, Steuerbefreiungen und Checkout-Einstellungen hängen alle daran. Keines dieser Objekte kann eine Preisanfrage, ein Angebot mit Versionsnummer, ein Gegenangebot, eine Freigabe oder eine Historie halten, wer was geändert hat. Ein Bestellentwurf ist der Datensatz einer Bestellung, die auf Zahlung oder Genehmigung wartet, nicht der Verhandlung, die sie hervorgebracht hat. Die Shopify-B2B-Referenz listet das Objektmodell vollständig.

Welches System was besitzt

Die Tabelle ist die Architektur. Jede Zeile nennt den Eigentümer, was die Angebotsebene behalten darf, und warum.

Daten	Führendes System	Was die Angebotsebene behält	Warum
Produkte und Varianten	Shopify	Produkt- und Varianten-IDs plus eine Titel-Momentaufnahme, die bei jeder Angebotsversion aufgefrischt wird	Ein Angebot vom März muss im September noch korrekt lesbar sein; die ID hält es am echten Produkt fest
Bestand	Shopify (gespeist vom ERP, wo es eines gibt)	Nichts. Wird bei der Umwandlung gelesen, Abweichungen werden markiert	Bestand ändert sich stündlich; eine Kopie ist falsch, sobald sie geschrieben ist
Kundenidentität und Anmeldung	Shopify-Kundenkonten	Die Kunden-ID; bei Gästen eine E-Mail-Adresse und später die Zuordnung zu einem Kundendatensatz	Shopify besitzt die Authentifizierung; B2B-Käufer melden sich mit einem Einmalcode an den aktuellen Kundenkonten an
Unternehmen, Standort, Kontakt	Shopify B2B	Die drei IDs	Kataloge, Zahlungsziele und Steuerbefreiungen hängen in Shopify am Standort; das Unternehmen zu duplizieren heißt, all das zu duplizieren
Standardpreise, Mengenregeln, Mengenpreise	Shopify-Kataloge	Den Preis, von dem die Verhandlung ausging, zum Angebotszeitpunkt für den Standort des Käufers aufgelöst, mit der Katalog-ID als Herkunft	Katalogpreise ändern sich, und von mehreren Katalogen gewinnt der niedrigste; eine gespeicherte Kopie kann das nicht wissen
Zahlungsziele	Shopify B2B	Eine Referenz auf die für das Geschäft gewählte Vorlage, angewandt beim Anlegen des Bestellentwurfs	Zahlungsziele gehören auf die Bestellung, und Shopify zieht dagegen ein
Anzahlung	Shopify (Plus)	Den für das Geschäft verhandelten Prozentsatz, versioniert mit dem Angebot	Wird vom Shopify-Checkout auf dem umgewandelten Bestellentwurf eingezogen
Steuer	Shopify	Eine Schätzung im Angebot, bei Umwandlung und Checkout von Shopify neu berechnet	Steuer hängt von den Befreiungen des Standorts und der Lieferadresse im Moment des Checkouts ab
Angebotsanfrage	Angebotsebene	Alles: Positionen, Mengen, gewünschte Preise, Nachricht des Käufers, eigene Felder, Bestellnummer	Shopify hat kein Anfrageobjekt
Angebote und Versionen	Angebotsebene	Jede Version, unveränderlich nach dem Versand	Die Positionen eines gesendeten Angebots sind gesperrt; eine Änderung ist eine neue Version oder ein Gegenangebot, nie eine Bearbeitung vor Ort
Gegenangebote	Angebotsebene	Jedes Gegenangebot als eigene Version, mit Urheber	Die Verhandlung ist das Produkt; ihre Historie ist der Beleg
Freigaben	Angebotsebene	Richtlinien, die Kette, die jedes Angebot durchlief, jede Entscheidung mit Urheber	Shopifys Mitarbeiterberechtigungen regeln, welche Konten ein Vertriebler sieht, nicht, ob ein Rabatt rausgehen darf
Prüfprotokoll	Angebotsebene	Jede Statusänderung, Akteur und Zeitstempel	Eine Agentur wird ein Jahr später gefragt: „Wer hat diesen Preis freigegeben?“
Angenommene Bestellung	Shopify-Bestellentwurf, dann Bestellung	Die IDs von Bestellentwurf und Bestellung, ins Angebot zurückgeschrieben	Die Bestellung gehört Shopify; das Angebot zeigt darauf
Fulfillment	Shopify und das ERP	Nichts	Die Aufgabe der Angebotsebene endete bei der Bestellung

Zwei Zeilen verdienen einen zweiten Blick, weil Projekte genau dort scheitern: Preise und Identität.

Warum die Angebotsebene keine Preise besitzen darf

Der häufigste Architekturfehler bei Shopify-B2B-Angeboten ist eine Angebots-App, die eine eigene Preisliste führt – importiert aus Shopify oder aus dem ERP, „damit wir davon ausgehend verhandeln können“. Drei Eigenschaften von Shopify-Katalogen machen das zu einer Kopie, die innerhalb von Tagen falsch ist.

Erstens: Ein Unternehmensstandort kann mehrere Kataloge haben, und wenn dasselbe Produkt in mehr als einem vorkommt, zeigt Shopify den niedrigsten Preis. Es gibt keine Vorrangregel, die man nachbauen könnte; die einzig richtige Antwort ist die, die Shopify für diesen Standort in diesem Moment berechnet. Zweitens: Mengenpreise fixieren den Preis eines Produkts und schalten den prozentualen Gesamtaufschlag oder -abschlag des Katalogs dafür ab – das „Liste minus 20 Prozent“, das eine Kopie berechnen würde, ist also nicht das, was der Käufer sieht. Drittens: Kataloge werden ständig bearbeitet – vom Händler, von einer ERP-Synchronisierung, von Shopify selbst, wenn sich ein Markt oder eine Währung ändert. Unterhalb von Plus ist ein Shop auf drei aktive Kataloge über alle B2B-Märkte begrenzt und kann keinen direkt einem Standort zuweisen, diese drei ändern sich also oft. Der Leitfaden zu Katalogen beschreibt die Händlerseite davon.

Die API gibt der Angebotsebene das richtige Werkzeug statt einer Kopie. ProductVariant.contextualPricing nimmt einen Kontext aus companyLocationId, country oder locationId entgegen und liefert „den endgültigen Preis nach Anwendung aller Anpassungen“, zusammen mit der Mengenregel und den Preisstaffeln, die in diesem Kontext gelten. Das richtige Muster ist:

1. Beim Schreiben eines Angebots den Preis jeder Variante über contextualPricing für den Unternehmensstandort des Käufers auflösen, in der Währung des Angebots.
2. Diese Zahl auf der Angebotsposition als Basis speichern, von der die Verhandlung ausging, mit der Katalog-ID als Herkunft daneben.
3. Von der Basis aus verhandeln. Die gewünschten, angebotenen und finalen Preise sind die eigenen Daten der Angebotsebene, weil Shopify dafür kein Objekt hat.
4. Den verhandelten Preis nie in den Katalog zurückschreiben. Der Katalog ist der Standardpreis für den Standort; das Geschäft ist eine Bestellung.

Genau das tut QuotWays unternehmensbezogenes Angebot: Der Katalogpreis des Unternehmensstandorts wird beim Senden eines Angebots serverseitig aufgelöst und als Basis in der Angebotswährung auf der Position gespeichert, und die Shopify-Katalog-ID wird an der Version festgehalten. Es importiert nie eine Preisliste. Dieselbe Regel beantwortet die Frage „Soll das ERP Preise in die Angebots-App pushen?“ – nein; das ERP pusht Preise in Shopify-Kataloge, und die Angebotsebene liest sie dort wie jeder andere Kanal auch.

Wie der verhandelte Preis in die Bestellung gelangt

Das ist der Übergang in die andere Richtung, und er hat zwei Details, über die Teams bei ihrer ersten Umwandlung stolpern.

Das erste: Der Bestellentwurf wird für das Unternehmen angelegt, nicht für die Person. draftOrderCreate nimmt eine purchasingEntity der Form { purchasingCompany: { companyId, companyLocationId, companyContactId } } entgegen, und Shopifys Dokumentation zu Bestellentwürfen sagt, dass ein Entwurf mit B2B-Kunde und zugewiesenem Unternehmensstandort „automatisch die Einstellungen dieses Unternehmens widerspiegelt“ – Preise, Zahlungsziele und Checkout-Optionen. Dieser Satz beschreibt einen im Admin angelegten Entwurf. Lesen Sie ihn nicht als „die API bepreist meine Positionen aus dem Katalog“: Eine Position, die mit einer variantId angelegt wird, wird von Shopify bepreist, und ein Thread in der Shopify Community, der seit September 2023 dieselbe Frage sammelt, zeigt das übliche Ergebnis – ein Produkt mit einem Katalogpreis von 8 $ für das Unternehmen landet zum Produktpreis von 10 $ auf dem Entwurf.

Das zweite Detail ist das Feld, das die vereinbarte Zahl trägt. DraftOrderLineItemInput.priceOverride ist „die Preisüberschreibung für die Position“, gesetzt in der Präsentationswährung, und es ist das Feld, durch das ein verhandelter Preis auf einer Variantenposition gehen muss; originalUnitPrice ist abgekündigt, und title, taxable und requiresShipping werden ignoriert, wenn eine variantId vorhanden ist. Eine freie Position (ohne Variante) ist das Gegenteil: Sie trägt eigenen Titel, Preis, Steuer- und Versandkennzeichen.

Der Umwandlungspfad ist also:

1. Die Eingabe für den Bestellentwurf aus der angenommenen Angebotsversion bauen: purchasingEntity aus den IDs von Unternehmen, Standort und Kontakt des Angebots; jede angenommene Position mit variantId, Menge und priceOverride zum finalen Stückpreis; freie Positionen mit eigenem Preis; die Bestellnummer; die für das Geschäft gewählten Zahlungsziele; auf Plus der Anzahlungsprozentsatz.
2. Zuerst draftOrderCalculate ausführen und Shopifys Zwischensumme, Steuer und Versand mit den Zahlen des Angebots vergleichen. Steuer und Versand weichen berechtigterweise ab – Shopify berechnet sie jetzt gegen die Befreiungen des Standorts und die Lieferadresse, nicht zum Zeitpunkt des Angebots –, es geht also darum, die Abweichung festzuhalten und die Fälle zu erkennen, die einen Menschen brauchen: eine Variante, die es nicht mehr gibt, eine Position, die Shopify anders bepreist, Bestand, der nicht mehr da ist.
3. Den Bestellentwurf unter einem Idempotenzschlüssel anlegen, damit eine wiederholte Anfrage oder ein zweiter Worker keine zwei Entwürfe für eine Annahme erzeugen kann.
4. Die Rechnung mit draftOrderInvoiceSend versenden oder den Käufer über die von Shopify zurückgegebene Checkout-URL bezahlen lassen. Ein Bestellentwurf wird zur Bestellung, wenn er bezahlt oder mit draftOrderComplete abgeschlossen wird; er hält weder Bestand noch sperrt er seine Preise, solange Sie es nicht anweisen.
5. Die ID des Bestellentwurfs beim Anlegen ins Angebot zurückschreiben, die Bestell-ID, sobald der Webhook orders/create eintrifft. Ab hier zeigt das Angebot auf Shopifys Datensatz und ist für nichts mehr die Quelle.

QuotWays Umwandlungsdienst ist so gebaut: eine Vorschau über draftOrderCalculate mit Abweichungen bei Steuer, Versand und Bestand gegenüber den Angebotszahlen, ein Idempotenzschlüssel und eine Sperre gegen parallele Anlage vor draftOrderCreate, priceOverride auf Variantenpositionen und originalUnitPriceWithCurrency auf freien Positionen, und die Bestell-ID aus dem Webhook orders/create. Was zwischen Angebotszeitpunkt und Umwandlungszeitpunkt schiefgehen kann, ist ein eigenes Thema; der Beitrag zu den Grenzen von Bestellentwürfen deckt heute die Shopify-Seite ab, der Testplan für den Start enthält die Tests, die es auffangen, und ein eigener Beitrag zu Fehlerbildern ist geplant.

Identität: Kunde, Kontakt, Gast

Shopify besitzt die Anmeldung des Käufers. B2B-Käufer melden sich an den aktuellen Kundenkonten mit der E-Mail-Adresse eines Unternehmensstandorts und einem Einmalcode an; klassische Kundenkonten wurden am 26. Februar 2026 abgekündigt und haben B2B nie unterstützt. Eine Angebotsebene sollte also weder einen Passwortspeicher noch einen Pfad für „klassische Konten“ noch ein eigenes Identitätsmodell führen. Ein Käufer mit mehreren Standorten wählt einen, bevor er Preise sieht, und jeder Preis im Shop ist der Preis eines Standorts.

Was die Angebotsebene behält, sind die Kunden-ID und bei unternehmensbezogenen Angeboten die drei Unternehmens-IDs. Der eine Fall, in dem sie berechtigterweise mehr hält, ist der Gast: ein Käufer, der ein Angebot anfragt, bevor er ein Konto hat, oder in einem Shop, der Kundenkonten nicht aktiviert hat. Dann braucht die Angebotsebene eine E-Mail-Adresse und einen Weg, den Käufer zu erreichen – einen signierten Link, einen eigenen Einmalcode – und einen Weg, das Angebot dem Shopify-Kunden zuzuordnen, sobald es einen gibt. QuotWay leitet angemeldete Käufer in eine Customer Account UI Extension innerhalb ihres Shopify-Kontos und Gäste in ein gehostetes Portal und ordnet die Angebote des Gastes seinem Kundendatensatz zu, sobald er sich später anmeldet; die Wahl wird je Shop aus dem getroffen, was Shopify meldet, nicht vom Händler.

Zahlungsziele, Anzahlung, Bestellnummer, Währung und Steuer

Das sind die Felder, die wie Daten der Angebotsebene aussehen und es nicht sind.

• Zahlungsziele gehören in Shopify zum Standort (Netto 7 bis Netto 90, fällig bei Fulfillment, ein fester Termin oder keine), und die Bestellung zieht dagegen ein. Die Angebotsebene speichert eine Referenz auf die für dieses Geschäft gewählte Vorlage und wendet sie beim Anlegen des Bestellentwurfs an; sie führt nie eine eigene Debitorenbuchhaltung.
• Eine Anzahlung ist eine Shopify-Plus-Funktion – ein Prozentsatz, der im Checkout fällig ist, der Rest nach Zahlungsziel –, gesetzt über DraftOrderInput.deposit seit API 2026-07. Die Aufgabe der Angebotsebene ist, den Prozentsatz zu verhandeln und ihn mit dem Angebot zu versionieren. QuotWay macht das auf Plus-Shops ab dem Tarif Professional, und nie außerhalb von Plus.
• Die Bestellnummer wird mit der Anfrage erfasst und an den Bestellentwurf übergeben, wo Shopify sie auf der Bestellung zeigt.
• Die Währung wird beim Anlegen des Angebots fixiert, in der Präsentationswährung des Käufers für den Markt, und jeder Preis jeder Version steht in dieser Währung; eine Momentaufnahme des Wechselkurses beim Anlegen wird für das Reporting behalten, nicht für die Bepreisung. Shopify rechnet für die Angebotsebene nichts um.
• Steuer auf einem Angebot ist eine Schätzung. Shopify berechnet die echte Zahl bei draftOrderCalculate und erneut im Checkout, gegen die Steuerbefreiung des Standorts und die Lieferadresse – deshalb sollte das Angebot „geschätzt“ sagen und der Umwandlungsschritt die Differenz festhalten, statt sie verhindern zu wollen. Der Leitfaden zur Steuerbefreiung beschreibt die Händlereinrichtung.

Wo das ERP sitzt

Shopifys eigene B2B-Dokumentation behandelt ERP-, Buchhaltungs- und PIM-Anbindungen als Teil der B2B-Architektur, und die meisten Agenturprojekte haben eine. Die Frage nach dem Platz ist einfacher, als sie klingt, sobald die Eigentümertabelle steht: Das ERP integriert sich mit Shopify, nicht mit der Angebotsebene.

• Bestand fließt vom ERP nach Shopify. Die Angebotsebene liest den Shopify-Bestand bei der Umwandlung und nie das ERP direkt.
• Standardpreise fließen vom ERP in Shopify-Kataloge, in dem Takt, den der Händler fährt. Die Angebotsebene löst Preise über contextualPricing aus dem Katalog auf, eine Preisänderung im ERP erreicht ein neues Angebot also, sobald sie den Katalog erreicht.
• Bestellungen fließen von Shopify ins ERP, über den Konnektor, den der Händler bereits für D2C-Bestellungen nutzt. Ein umgewandeltes Angebot ist eine gewöhnliche Shopify-Bestellung mit Bestellnummer, Unternehmen, Zahlungszielen und gegebenenfalls Anzahlung; das ERP sieht sie wie jede andere Bestellung. Shopifys Spring-’26-Edition ergänzte eine native QuickBooks-Synchronisierung von B2B-Bestellungen, Bestellnummern und Unternehmensdaten – dieselbe Form.
• Die Verhandlung selbst bleibt in der Angebotsebene. Wenn das ERP oder ein CRM wissen muss, dass ein Angebot gesendet, erwidert oder angenommen wurde, ist das ein Ereignis, kein zu duplizierender Datensatz: Shopify-Flow-Trigger sind die native Oberfläche dafür, und eine Angebotsebene, die sie auslöst, lässt den Händler den Rest ohne Individualintegration verdrahten. QuotWay stellt Flow-Trigger ab dem Tarif Professional und Flow-Aktionen auf Enterprise bereit; es hat keine direkten ERP- oder CRM-Konnektoren, und diese Architektur ist der Grund, warum es sie nicht braucht, um zu passen.

Die eine ERP-geführte Variante, die es zu nennen lohnt, ist der Händler, dessen Vertragspreise im ERP liegen und sich pro Kunde pro Woche ändern. Auch dieser Händler synchronisiert die Preise in Shopify-Kataloge – weil Shop, Checkout und Bestellentwürfe alle aus Katalogen lesen –, und die Angebotsebene liest aus derselben Quelle. Eine Angebotsebene, die Preise stattdessen aus dem ERP zöge, wäre die zweite Commerce-Datenbank, die die Regel verhindern soll.

Was die Angebotsebene trotzdem behält, und warum das keine Kopie ist

Drei Dinge in der mittleren Spalte sehen aus wie Duplikate von Shopify-Daten. Es sind Momentaufnahmen, und der Unterschied zählt.

• Titel und SKUs auf Angebotspositionen. Ein im März gesendetes Angebots-PDF ist ein kaufmännisches Dokument; wird die Variante im Juni umbenannt, muss das März-Dokument trotzdem so lesbar bleiben, wie es gesendet wurde. Der Titel wird also bei jeder neuen Version aufgefrischt und mit ihr eingefroren.
• Der Basispreis. Die Zahl, von der die Verhandlung ausging, ist Teil der Verhandlungshistorie, und der Katalog wird sich weiterbewegt haben. Sie wird mit Datum und Katalog-ID gespeichert und nach dieser Version nie wieder zur Bepreisung herangezogen.
• Die finalen Preise. Das sind überhaupt keine Shopify-Daten, bis der Bestellentwurf existiert; sie sind das Ergebnis der Verhandlung.

Der Test, ob etwas eine Momentaufnahme oder eine Kopie ist: Eine Momentaufnahme hat ein Datum und eine ID daneben und wird nie gelesen, um „Was ist der Preis jetzt?“ zu beantworten; eine Kopie wird gelesen, als wäre sie aktuell. Jeder Wert in der Angebotsebene sollte diesen Test bestehen.

Deinstallation, Löschung und Datenhaltung

Weil die Angebotsebene nichts besitzt, was Shopify hat, entfernt ihre Deinstallation nichts aus dem Shop: Produkte, Kunden, Unternehmen, Kataloge, Bestellentwürfe und Bestellungen bleiben unberührt. Was die Angebotsebene hält – Anfragen, Versionen, Freigaben, Nachrichten, Dokumente –, folgt Shopifys verpflichtenden Compliance-Webhooks, die jede App im App Store implementieren muss: shop/redact trifft 48 Stunden nach einer Deinstallation ein, und die App muss die Daten des Shops löschen; customers/redact kommt 10 Tage nach einer Löschanfrage oder sobald seit der letzten Bestellung des Kunden sechs Monate vergangen sind; customers/data_request fragt die Daten ab, die die App zu einem Kunden hält. Eine Agentur, die eine Angebotsebene bewertet, sollte fragen, wo diese Datensätze liegen, wie lang die Aufbewahrungsfrist ist und wie sich eine Neuinstallation innerhalb dieser Frist verhält – die Bewertungs-Checkliste hat diese Fragen samt Prüfweg. QuotWays Antworten stehen in den Docs zu Datenaufbewahrung und Deinstallation und DSGVO.

Häufige Fragen

Braucht diese Architektur Shopify Plus?

Nein. Seit dem 2. April 2026 sind Unternehmen, Standorte, Kataloge, Mengenregeln, Mengenpreise, Zahlungsziele und hinterlegte Karten auf Basic, Grow und Advanced ebenso verfügbar wie auf Plus. Plus ergänzt unbegrenzte Kataloge, die direkte Katalogzuweisung an ein Unternehmen oder einen Standort, Anzahlungen und Teilzahlungen. Eine Angebotsebene, die Katalogpreise über contextualPricing liest und Bestellentwürfe mit einer purchasingEntity anlegt, funktioniert in jedem Tarif; nur die Zeile zur Anzahlung ändert sich. Die Tarifmatrix hat jeden Unterschied.

Sollen wir Bestellentwürfe als unser Angebotsobjekt verwenden?

Verwenden Sie sie als das, was sie sind: der Datensatz einer vereinbarten Bestellung, die auf Zahlung oder Genehmigung wartet. Ein Bestellentwurf hat keinen Anfrage-, Angebots-, Versions- oder Gegenangebotsstatus, und seine Preise und Bestände werden nicht gehalten, solange Sie sie nicht sperren und reservieren. Wenn die Geschäfte des Händlers eine Runde haben – der Käufer reicht ein, der Händler passt an, der Käufer zahlt –, legt Shopifys Checkout-Einstellung „Zur Genehmigung einreichen“ den Bestellentwurf nativ an, und eine Angebotsebene ist unnötig (wann Sie keine Angebots-App brauchen listet die weiteren Fälle). Sobald es Verhandlung, Freigabe oder eine aufzubewahrende Historie gibt, modellieren Sie das in einer Angebotsebene und legen den Bestellentwurf am Ende an.

Was ist eine Purchasing Entity?

Der B2B-Käufer, für den ein Bestellentwurf oder eine Bestellung bestimmt ist. Bei draftOrderCreate wird sie als purchasingEntity: { purchasingCompany: { companyId, companyLocationId, companyContactId } } übergeben – das Unternehmen, der belieferte Standort und der Kontakt, der bestellt. Sie macht den Bestellentwurf zu einem B2B-Bestellentwurf: Zahlungsziele, Steuerbefreiung und Checkout-Einstellungen des Standorts gelten für ihn, und der Käufer sieht ihn in seinem Unternehmenskonto.

Kollidiert eine Angebotsebene mit Katalogen?

Nicht, wenn sie nie eine Preisliste speichert. Der Konflikt entsteht, wenn eine App eigene Preise führt und diese von dem Katalog abweichen, den der Shop zeigt. Lesen Sie den Preis des Standorts zum Angebotszeitpunkt über contextualPricing, verhandeln Sie davon ausgehend und schreiben Sie den vereinbarten Preis als priceOverride auf die Position des Bestellentwurfs. Der Katalog bleibt unberührt, und die Bestellung entspricht dem Angebot. Von welchem Preis eine Anfrage starten sollte, wenn ein Standort mehrere Kataloge hat, behandelt der Leitfaden zu Katalogen.

Kann ein Käufer ein Angebot nach dem Versand bearbeiten?

Nicht das gesendete. Ein Angebot ist eine nummerierte Version, unveränderlich, sobald es rausgeht, weil das Dokument, das der Käufer erhalten hat, ein kaufmännischer Beleg ist. Der Zug des Käufers ist ein Gegenangebot, das zu einer neuen Version wird; der Zug des Verkäufers ist ein neues Angebot. Eine gesendete Version vor Ort zu bearbeiten würde das Prüfprotokoll unfähig machen zu sagen, worauf sich die Seiten geeinigt hatten.

Laufen Angebote automatisch ab, und der Bestellentwurf?

Eine Angebotsebene kann ein Angebot zu einem Datum ablaufen lassen und den Annahme-Link stoppen; das ist der Status der Angebotsebene. Ein Bestellentwurf hat seine eigene Uhr: Er hält weder Bestand noch sperrt er Preise, solange Sie es nicht anweisen, und Shopify löscht Bestellentwürfe nach einer Phase der Inaktivität – siehe den Beitrag zu den Grenzen von Bestellentwürfen. Legen Sie den Bestellentwurf an, wenn der Preis vereinbart ist, nicht wenn das Angebot gesendet wird.

Was passiert mit unseren Angeboten, wenn wir die Angebots-App deinstallieren?

Mit Shopifys Daten passiert nichts. Die eigenen Daten der App – Anfragen, Angebote, Freigaben, Nachrichten – werden gelöscht, wenn Shopify shop/redact sendet, 48 Stunden nach der Deinstallation, vorbehaltlich der Wiederherstellungsfrist, die die App dokumentiert. Exportieren Sie vorher, was Sie brauchen.

Quellen

Shopify-Seiten, alle gelesen am 20. September 2026:

• B2B-Apps entwickeln – Objektmodell und Bestellentwürfe für B2B
• B2B-Kataloge und Mengenregeln und Mengenpreise
• B2B-Bestellungen mit Bestellentwürfen anlegen
• ProductVariant.contextualPricing, ProductVariantContextualPricing, ContextualPricingContext
• DraftOrderLineItemInput
• Anmeldung und Kundenkonten im B2B und Kundenkonten für Apps
• Zahlungsziele und der Changelog zu den Anzahlungsfeldern
• Datenschutzrechtliche Compliance – verpflichtende Webhooks
• B2B for all – Ankündigung, 2. April 2026 und B2B-Funktionen nach Tarif
• Shopify Editions Spring ’26
• Praxisbeleg, keine Faktenquelle: How to fetch prices from a catalog when creating B2B draft orders using APIs? (Shopify Community, September 2023 bis September 2026)