Was zwischen Angebot und Umwandlung kaputtgeht: 17 Fehlerfälle beim Umwandeln eines Shopify-B2B-Angebots

Zwischen dem Moment, in dem eine Käuferin ein Angebot annimmt, und dem Moment, in dem dafür ein Shopify-Bestellentwurf existiert, können sich siebzehn Dinge unter den vereinbarten Zahlen ändern: der Katalogpreis, der Bestand, die Variante selbst, die Steuer, der Versandtarif, die Währung, die Rabatte, die Zahlungsziele des Standorts, die Identität der Käuferin, der Ablauf des Angebots und der API-Aufruf, der das alles trägt.

Keines davon ist ein Fehler in Shopify. Jedes ist Shopify, das in dem Moment, in dem der Bestellentwurf entsteht, neu berechnet, was ihm gehört, während die Angebotsebene noch hält, was vereinbart wurde. Eine Umwandlung, die diese Lücke nicht erwartet, verschickt die falsche Bestellung, ohne dass es jemand vor der Rechnung bemerkt.

Diese Seite listet die Lücken einzeln auf – was Shopify jeweils tut, was eine Angebotsebene dagegen tun muss und was zu prüfen ist – und dann die zwei Mechaniken, die aus Überraschungen Zustände machen: eine Vorabberechnung, verglichen mit der versiegelten Version, und eine Umwandlung, die wiederholt werden kann, ohne einen zweiten Entwurf zu erzeugen. Geschrieben ist sie für die Agentur, die den Umwandlungsschritt baut oder bewertet – den Punkt, an dem die Angebotsebene Shopify am stärksten berührt und an dem was wo liegt und was ein Bestellentwurf ist aufhören, Architektur zu sein, und anfangen, ein Support-Ticket am Dienstagmorgen zu sein.

Alles über Shopify wurde am 22. September 2026 bei API-Version 2026-07 gegen Shopifys eigene Seiten geprüft; die Quellen stehen am Ende. Wo die Seite beschreibt, wie QuotWay einen Fall behandelt, ist das eine Umsetzung des Musters und als solche gekennzeichnet.

Warum die Lücke überhaupt existiert

Ein Angebot hält einen Preis fest, auf den sich zwei Seiten geeinigt haben. Ein Bestellentwurf hält fest, was Shopify berechnen wird. Das Erste ist eine Momentaufnahme; das Zweite ist eine Berechnung, und Shopify führt sie jedes Mal neu aus – draftOrderCalculate „berechnet die Eigenschaften eines DraftOrder, ohne ihn anzulegen“, und liefert Positionssummen, Versandtarife, Rabatte und Steuern für die Eingabe, die Sie jetzt übergeben, gegen Katalog, Bestand, Steuereinstellungen und Versandtarife, wie sie jetzt sind. Der Bestellentwurf wird dann aus denselben Eingaben angelegt, und der Checkout rechnet noch einmal, wenn die Käuferin bezahlt.

Es gibt also drei Zeitpunkte – Angebot, Umwandlung, Checkout –, und Shopify bestimmt den Zustand an den letzten beiden. Die Angebotsebene besitzt über alle drei hinweg genau eines: den versiegelten Datensatz dessen, was angenommen wurde, mit dem Preis jeder Position, der Menge, der Währung, den Zahlungszielen und den Summen, wie die Käuferin sie gesehen hat. Umwandlung ist der Akt, Shopify zu bitten, diesen Datensatz einzulösen – und herauszufinden, was sich seitdem bewegt hat.

Die Fehlerfälle

Die Tabelle ist die Seite. Jede Zeile ist eine Bedingung, die zur Umwandlungszeit wahr sein kann, es zur Angebotszeit aber nicht war – was Shopify damit macht, was die Angebotsebene tun muss und wie man es erkennt. „Berechnen“ meint draftOrderCalculate, das nichts kostet und nichts anlegt.

Bedingung	Was Shopify tut	Was die Angebotsebene tun muss	Wie man es erkennt
Katalogpreis seit dem Angebot geändert	Eine Position ohne Überschreibung nimmt beim Anlegen den Katalogpreis; eine Position mit priceOverride behält die Überschreibung. Ein B2B-Entwurf mit Preissperre behält den gesperrten Preis	Jede verhandelte Variantenposition mit priceOverride in der Präsentationswährung senden, aus der versiegelten Version, nie aus dem Live-Katalog. Dem Händler neben dem geschriebenen Preis die Basis zeigen, von der die Verhandlung ausging	Berechnen: originalUnitPriceSet jeder Position mit der zur Angebotszeit gespeicherten Basis vergleichen; eine Differenz ist eine Information für den Händler, keine Änderung an der Bestellung
Bestand weg	Ein Entwurf reserviert nichts, solange reserveInventoryUntil nicht gesetzt ist. Der Entwurf wird trotzdem angelegt; der Checkout der Käuferin scheitert dann mit einem Fehler „nicht vorrätig“, außer die Variante erlaubt Überverkauf. Reservierte Einheiten wechseln bis zum gesetzten Ablauf in „Zugesagt“	Je Geschäft entscheiden, ob und wie lange reserviert wird – bei der Umwandlung, nicht beim Angebot, wo nichts gehalten werden sollte. Der Käuferin sagen, was gilt	Berechnen: ein bestandsbezogener Nutzerfehler des Aufrufs ist das Signal; als Abweichung für den Händler behandeln, nicht als Scheitern der Umwandlung
Variante gelöscht oder Produkt unveröffentlicht	Die Position kann weder bepreist noch auf Bestand geprüft werden; es gibt keine Variante, an der die Überschreibung hängen könnte	Jede Varianten-ID vor dem Berechnen auflösen; eine Position, die sich nicht mehr auflöst, wird vom Händler ersetzt (freie Position oder Nachfolgevariante) oder mit Zustimmung der Käuferin entfernt – das ist eine neue Version, keine Bearbeitung	Erst auflösen; eine gescheiterte Auflösung stoppt vor dem Berechnen
Steuer neu berechnet	Steuern folgen den Steuereinstellungen des Shops und der Lieferadresse; die Befreiung eines Standorts greift über purchasingEntity; taxExempt lässt sich am Entwurf setzen; der Checkout rechnet erneut	Eine Schätzung anbieten und das sagen; die Befreiung des Standorts auf den Entwurf übertragen; die berechnete Steuer mit der Schätzung vergleichen und die Umwandlung anhalten, wenn die Differenz wesentlich ist	Berechnen: totalTaxSet gegen die Steuerschätzung der angenommenen Version, als Prozentsatz; ein Schwellenwert entscheidet, ob jemand hinsieht
Versand	Tarife kommen aus availableShippingRates, das eine gültige Lieferadresse und eine Position braucht; oder eine eigene shippingLine; ein nach der Rechnung ergänztes Produkt aktualisiert den Tarif nicht	Einen final angebotenen Tarif als eigene Versandposition übertragen; wo der Tarif offen blieb, bei der Umwandlung einen von Shopifys Tarifen wählen; die Rechnung nie mit dem Tarif des Angebots rausgehen lassen, wenn sich die Positionen geändert haben	Berechnen: totalShippingPriceSet und die Tarifliste gegen den angebotenen Betrag; die Differenz zeigen, den Händler wählen lassen
Währung	Ein presentmentCurrencyCode je Entwurf; priceOverride steht in dieser Währung; currencyCode ist die Shopwährung, in der gerechnet wurde; ein Mehrwährungsentwurf mit Zahlungszielen kann nur per Karte oder „als bezahlt markiert“ eingezogen werden	Die Währung des Angebots bei der Erstellung aus dem Markt der Käuferin festlegen und nie umrechnen; den Entwurf in derselben Währung anlegen; einen Wechselkurs nur als Momentaufnahme für Auswertungen halten	Vor dem Anlegen prüfen, dass presentmentCurrencyCode der Währung des Angebots entspricht; sonst verweigern
Rabatte stapeln sich	acceptAutomaticDiscounts wendet automatische Rabatte beim Berechnen an; allowDiscountCodesInCheckout lässt die Käuferin im Checkout einen Code eingeben; appliedDiscount fügt einen eigenen Rabatt auf Bestell- oder Positionsebene hinzu	Ein verhandelter Preis ist bereits der Rabatt. Ausdrücklich entscheiden, ob automatische Rabatte und Checkout-Codes obendrauf gelten – der Standard sollte Nein sein – und einen Rabatt auf Angebotsebene als einen appliedDiscount übertragen, je Entwurf aufgeteilt, wenn sich das Angebot teilt	Berechnen: platformDiscounts und totalDiscountsSet sollten mit der Version übereinstimmen; alles darüber hinaus ist Stapelung
Freie Positionen	Keine Variante, kein Bestand, keine Produktseite; nicht nutzbar für automatisiertes Fulfillment oder Versand-Apps; Preis aus originalUnitPriceWithCurrency; taxable und requiresShipping aus der Eingabe	Den vereinbarten Preis und die Flags senden; für diese Positionen manuelles Fulfillment einplanen; nicht versuchen, sie zu reservieren	Prüfung: ein Entwurf mit freien Positionen braucht beim Fulfillment eine Person
Zahlungsziele	Zahlungsziele werden am Entwurf als Vorlage plus Zeitplan gesetzt (issuedAt für Nettoziele, dueAt für ein festes Datum); ein Entwurf trägt seine eigenen Ziele, und der Standard des Standorts gilt, wo der Entwurf keine hat	Die Ziele schreiben, auf die sich das Geschäft geeinigt hat, nicht den aktuellen Standard des Standorts; hatte das Geschäft keine, dem Standort überlassen	Prüfen, dass die Vorlagen-GID der angenommenen Version noch existiert; eine gelöschte Vorlage ist ein harter Stopp
Anzahlung	Ein Prozentsatz am Entwurf (deposit), verfügbar auf Shopify Plus; der Checkout zieht ihn ein und terminiert den Rest	Den verhandelten Prozentsatz aus der angenommenen Version übertragen; sich weigern, auf einem Shop ohne Plus einen Anzahlungsentwurf anzulegen	Berechnen: amountDueNowSet sollte dem Anzahlungsanteil von totalPriceSet entsprechen
Unternehmensstandort fehlt oder hat sich geändert	purchasingEntity ist ein Kunde oder ein einkaufendes Unternehmen, nie beides; Katalog, Zahlungsziele, Steuerbefreiung und Checkout-Einstellungen des Standorts greifen nur, wenn der Standort am Entwurf hängt; DraftOrderInput.customerId ist in 2026-07 abgekündigt	Unternehmens-, Standort- und Kontakt-ID am Angebot speichern und vor dem Anlegen auflösen; ein Kontakt, der den Standort gewechselt hat, oder ein gelöschter Standort ist ein Stopp, kein Rückfall auf einen D2C-Entwurf	Die drei IDs auflösen; den aufgelösten Standort mit dem vergleichen, aus dem der Preis abgeleitet wurde
Mengenregeln	Regeln gelten je Variante und werden im Checkout erneut geprüft; eine Menge unter dem Minimum, über dem Maximum oder neben dem Inkrement scheitert dort	Mengen zur Angebotszeit gegen die Regeln des Standorts prüfen und bei der Umwandlung erneut, weil sich die Regeln ändern können	quantityRule über contextualPricing für den Standort lesen; ein Verstoß ist ein Stopp vor dem Anlegen
Angebot abgelaufen oder Entwurf gelöscht	Ein am oder nach dem 1. April 2025 angelegter Entwurf wird nach einem Jahr ohne Bearbeitung gelöscht; ein abgelaufenes Angebot ist der Zustand der Angebotsebene	Bei der Annahme umwandeln, einmal; keine Entwürfe vorsorglich beim Angebot anlegen, wo sie unbezahlt altern würden	Ein Entwurf ohne Bestellung nach N Tagen ist ein Fall für den Abgleich, kein Warten
Teilannahme und Aufteilungen	Jeder Bestellentwurf ist eigenständig: eigene Summen, Steuer, Versandposition und Zahlungsziele	Ein Entwurf je angenommener Teilmenge; Versand und Steuer nach Anteil an der Zwischensumme auf jeden verteilt oder je Entwurf vom Händler überschrieben; die noch offenen Positionen bleiben am Angebot	Die Zwischensummen der Entwürfe zur angenommenen Teilmenge zurückrechnen; die Differenz ist Rundung oder ein Fehler
Der Anlege-Aufruf bricht mittendrin ab	draftOrderCreate nimmt keinen Idempotenzschlüssel; ein zweiter Aufruf ist ein zweiter Entwurf	Die Umwandlung vor dem Aufruf beanspruchen, die Entwurfs-ID festhalten, sobald sie zurückkommt, und einen Aufruf mit unbekanntem Ausgang nie automatisch wiederholen – ihn sichtbar machen	Abgleich: eine Umwandlung mit Berechnung, aber ohne Entwurfs-ID und minutenlang ohne Bewegung, ist ein Fall für eine Person
Die Bestellung kommt spät, doppelt oder gar nicht zurück	Die Bestellung entsteht, wenn die Käuferin bezahlt; orders/create wird mit 1 Sekunde Verbindungs- und 5 Sekunden Gesamt-Timeout zugestellt, 8-mal über 4 Stunden wiederholt, ohne Garantie, möglicherweise doppelt	Die Bestell-ID aus dem Webhook schreiben, dem Entwurf über ein Attribut zugeordnet, das Sie ihm mitgegeben haben; den Handler idempotent machen; einen Abgleich laufen lassen, der Shopify fragt, ob ein Entwurf eine order hat	Abgleich: Rechnung gesendet, nach einer Woche keine Bestellung → den Entwurf abfragen
Der Entwurf wurde nach der Rechnung bearbeitet	draftOrderUpdate ersetzt die Eingabe vollständig und trennt einen laufenden Checkout; die Bestellung kann dann entstehen, während der Entwurf offen bleibt	Einen Entwurf nach dem Senden nie bearbeiten; eine Änderung nach der Annahme ist eine neue Version, eine neue Annahme und ein neuer Entwurf	Eine Regel der Angebotsebene selbst; nichts zu erkennen, wenn sie gilt

Drei Zeilen verdienen die längere Erklärung unten, weil ein Aufbau dort am häufigsten überhaupt kein Konzept hat: die Steuerabweichung, der Anlege-Aufruf und der Webhook.

Zwei Zahlen, ein Schwellenwert

Jede Zeile in der Tabelle, in der „Berechnen“ steht, ist dieselbe Mechanik: draftOrderCalculate mit genau der Eingabe ausführen, die Sie gleich anlegen werden, und das Ergebnis mit der versiegelten Version vergleichen. Das ergibt zwei Zahlen je Größe – was angenommen wurde und was Shopify berechnen wird –, und die Entwurfsfrage ist, was zu tun ist, wenn sie sich unterscheiden.

Die Antwort, die funktioniert, ist ein vom Händler gesetzter Schwellenwert, angewendet auf die Steuer, weil die Steuer das Eine ist, das Shopify stillschweigend neu berechnet und das die Käuferin nie verhandelt hat. Unter dem Schwellenwert wird die Differenz am Angebot protokolliert, und die Umwandlung läuft weiter. Darüber hält die Umwandlung im Zustand „berechnet“ an, und eine Person entscheidet: die neu berechnete Zahl annehmen, anpassen oder zurück zur Käuferin. Eine Versandabweichung wird gezeigt, hält die Umwandlung aber nicht an, weil der Händler den Tarif ohnehin wählt. Eine Bestandsabweichung wird gezeigt, und der Händler entscheidet, ob er reserviert, die Zahlung im Admin entgegennimmt oder wartet.

Der Schwellenwert ist keine Toleranz fürs Falschliegen. Er ist der Punkt, an dem „Shopifys Steuer-Engine hatte neuere Informationen als das Angebot“ zu „die Käuferin wird es merken“ wird. Eine B2B-Rechnung, deren Steuer zwei Prozent vom Angebot abweicht, ist ein Rundungsgespräch; eine mit zwanzig Prozent Abweichung ist eine Steuerbefreiung, die nicht gegriffen hat, oder eine Lieferadresse, die die Zuständigkeit gewechselt hat, und jemand sollte hinsehen, bevor sie rausgeht.

Zwei Details machen das ehrlich. Der Vergleich muss gegen die Schätzung der angenommenen Version laufen, versiegelt bei der Annahme, nicht gegen das, was das Angebotsobjekt gerade hält. Und wenn sich ein Angebot in mehrere Entwürfe teilt, müssen Steuer und Versand der Version auf jeden Entwurf verteilt werden – nach dessen Anteil an der angenommenen Zwischensumme –, damit jeder Vergleich Gleiches mit Gleichem vergleicht.

Warum Umwandlung idempotent sein muss

draftOrderCreate hat keinen Idempotenzschlüssel. Rufen Sie es zweimal mit derselben Eingabe auf, haben Sie zwei Bestellentwürfe, zwei Rechnungen und eine Käuferin, die eine bezahlt und die andere bestreitet. Alles, was es zweimal aufrufen kann, wird es irgendwann tun: eine Job-Warteschlange, die bei Timeout wiederholt, ein Händler, der doppelt klickt, ein Webhook-Handler, der eine Umwandlung auslöst und dann erneut zugestellt wird.

Das Muster hat drei Teile. Erstens ein Schlüssel je Umwandlung – Angebot, angenommene Teilmenge und Version –, vor dem Aufruf eindeutig gespeichert, sodass ein zweiter Versuch den ersten findet. Zweitens eine Beanspruchung: Der Umwandlungsdatensatz hält fest, dass ein Anlegen läuft, bevor die Anfrage rausgeht, und hält die Entwurfs-ID in dem Augenblick fest, in dem die Antwort eintrifft. Drittens eine Regel für die Lücke zwischen diesen beiden Schreibvorgängen: Ist der Prozess gestorben, nachdem Shopify den Entwurf angelegt hat, aber bevor die ID gespeichert wurde, darf die Umwandlung nicht automatisch wiederholt werden, denn die Wiederholung ist genau das Duplikat. Sie wird einer Bedienerin sichtbar gemacht, die den Entwurf über sein Attribut nachschlagen und verknüpfen kann.

Diese letzte Regel ist die, die Eigenentwicklungen überspringen, weil sie bedeutet, einen Zustand zuzugeben, der einen Menschen braucht. Sie ist auch die, die das schlimmste Ergebnis der Tabelle verhindert.

Die Bestellung kommt über einen Webhook zurück, nicht als Rückgabewert

draftOrderCreate liefert einen Entwurf. Es liefert keine Bestellung, und das kann es nicht, weil die Bestellung erst existiert, wenn die Käuferin bezahlt – oder wenn der Händler den Entwurf im Admin abschließt. Das Ereignis, das die Bestellung trägt, ist orders/create, und es kommt zu Shopifys Bedingungen: eine Sekunde Verbindungs-Timeout, fünf Sekunden für die ganze Anfrage, acht Wiederholungen über vier Stunden, keine Garantie und die Möglichkeit derselben Zustellung zweimal.

Eine Umwandlung, die sich beim Erfolg des Anlege-Aufrufs als „Bestellung abgeschlossen“ markiert, zeigt eines Tages eine Bestellung für einen abgebrochenen Checkout. Eine Umwandlung, die allein dem Webhook vertraut, verpasst eines Tages die Bestellung. Das Muster ist beides: Die Bestell-ID wird nur aus dem Webhook geschrieben, dem Entwurf über ein Attribut zugeordnet, das die Angebotsebene beim Anlegen auf den Entwurf geschrieben hat; der Handler behandelt eine zweite Zustellung als No-op; und ein Abgleichjob fragt Shopify direkt – draftOrder(id) { order { id } } – für jede Umwandlung, deren Rechnung rausging und deren Bestellung binnen einer Woche nicht eingetroffen ist, und spielt das verpasste Ereignis nach, wenn der Entwurf doch eine Bestellung hat. Stornierungen und Erstattungen kommen auf demselben Weg zurück, über orders/updated, und werden mit derselben Idempotenz behandelt.

Wie QuotWay jede Zeile behandelt

QuotWays Umwandlung ist das Muster oben mit Zahlen daran. Jede Umwandlungsgruppe wird vor draftOrderCreate mit draftOrderCalculate berechnet, und das Ergebnis wird mit den Zahlen der angenommenen Version verglichen, die dieser Gruppe nach Anteil an der Zwischensumme zugeteilt sind. Die Steuerabweichung wird als Prozentsatz gegen einen Schwellenwert je Shop gemessen, der standardmäßig bei zwei Prozent liegt; darüber hält eine automatische Umwandlung im Zustand „berechnet“ an, und der Händler übernimmt. Die Bestandsabweichung wird aus den bestandsbezogenen Nutzerfehlern des Berechnungsaufrufs gelesen und in der Vorschau gezeigt, statt die Umwandlung scheitern zu lassen; jeder andere Nutzerfehler lässt sie scheitern. Der angebotene Versand wird mit dem von Shopify berechneten verglichen, und wo das Angebot den Tarif offen ließ, werden Shopifys availableShippingRates angeboten, damit der Händler je Gruppe einen wählt.

Preise erreichen den Entwurf als priceOverride auf Variantenpositionen und originalUnitPriceWithCurrency auf freien Positionen, in der Währung des Angebots, die bei der Erstellung aus dem Markt der Käuferin festgelegt und nie umgerechnet wurde; presentmentCurrencyCode wird ausdrücklich darauf gesetzt. Ein Rabatt auf Angebotsebene wird als ein appliedDiscount geschrieben, je Entwurf aufgeteilt, wenn sich ein Angebot teilt. Zahlungsziele gehen als die Vorlage, auf die sich das Geschäft geeinigt hat, plus dem Zeitplan, den dieser Vorlagentyp braucht – ein Ausstellungsdatum für Nettoziele, ein Fälligkeitsdatum für ein festes Datum –, und ein verhandelter Anzahlungsprozentsatz reist auf Plus-Shops am Entwurf mit. Bei unternehmensbezogenen Angeboten wird die Steuerbefreiung des Standorts aus dessen eigenen Steuereinstellungen am Entwurf gesetzt, und Positionen, die der Standort nicht sehen kann, werden bei der Umwandlung erneut markiert.

Jede Umwandlung trägt einen Schlüssel aus Angebot, Gruppe und Version, eindeutig in der Datenbank, und beansprucht das Anlegen vor dem Aufruf; ein Anlegen, das mittendrin gestorben ist, wird vom System nie wiederholt – es wird für die Bedienerin aufgelistet. Die Bestell-ID wird nur aus orders/create geschrieben, über ein einzelnes Attribut am Entwurf zugeordnet (quotway_conversion_group_id); eine zweite Zustellung findet die Verknüpfung bereits vor und tut nichts; Stornierungen und Erstattungen kommen über orders/updated und werden einmal festgehalten. Ein Lauf schließt die drei hängenden Zustände: eine Berechnung ohne Entwurfs-ID und ohne Bewegung, eine gesendete Rechnung ohne Bestellung nach sieben Tagen – gelöst, indem Shopify gefragt wird, ob der Entwurf eine Bestellung hat, und das Ereignis nachgespielt wird – und eine berechnete Gruppe, auf die seit einem Tag niemand reagiert hat. Die Darstellung für Händler steht in Angebot in einen Bestellentwurf umwandeln und Teilannahme und geteilte Umwandlung; die Funktionsseite zur Umwandlung zeigt es aus dem Admin.

Eine Vorabprüfliste für jeden Aufbau

Führen Sie diese Tests gegen den Umwandlungsschritt jeder Angebotsebene aus – einer App in der Bewertung oder einer Eigenentwicklung – mit einem Testangebot, dessen Katalog, Bestand, Steuer und Versand Sie zwischen Annahme und Umwandlung ändern können. Der 50-Tests-Startplan hat die Testumgebung.

1. Katalogpreis nach der Annahme ändern, umwandeln: Der Entwurf trägt den angenommenen Preis, und der Händler sieht, dass sich die Basis bewegt hat.
2. Bestand nach der Annahme auf null setzen, umwandeln: Der Händler erfährt es, bevor die Rechnung rausgeht, und kann reservieren oder anhalten.
3. Eine Variante der angenommenen Version löschen, umwandeln: Die Umwandlung stoppt vor jedem Shopify-Aufruf und benennt die Position.
4. Die Lieferadresse in eine andere Steuerzuständigkeit ändern, umwandeln: Die Steuerabweichung wird gemessen, und über dem Schwellenwert wird eine Person gefragt.
5. Versand im Angebot offen lassen, umwandeln: Der Händler wählt aus Shopifys Tarifen; die Rechnung geht nicht mit dem Platzhalter des Angebots raus.
6. In einer Präsentationswährung anbieten, umwandeln: Der Entwurf steht in dieser Währung und jede Positionsüberschreibung auch.
7. Einen automatischen Rabatt aktivieren, der ein angebotenes Produkt abdeckt, umwandeln: Die Summe des Entwurfs entspricht der angenommenen Summe, nicht weniger.
8. Nach der Annahme Nettoziele am Standort setzen, umwandeln: Der Entwurf trägt die Ziele des Geschäfts.
9. Eine echte Teilmenge annehmen, umwandeln, mehr annehmen, erneut umwandeln: zwei Entwürfe, noch offene Positionen unberührt, Summen ergeben die angenommene Teilmenge.
10. Den Prozess zwischen Anlegen und Datenbankschreibung abbrechen, dann wiederholen: kein zweiter Entwurf; der Fall wird für eine Bedienerin aufgelistet.
11. orders/create zweimal zustellen: eine Bestell-ID, ein Statuswechsel.
12. orders/create ganz blockieren, die Rechnung bezahlen: Der Abgleich findet die Bestellung.

Ein Aufbau, der zwölf von zwölf besteht, hat die Lücke entworfen. Einer, der die ersten sechs besteht, hat den Glücksfall entworfen.

Häufige Fragen

Warum weicht die Steuer auf der Shopify-Bestellung von der Steuer auf dem Angebot ab?

Weil Shopify die Steuer beim Anlegen des Bestellentwurfs und erneut im Checkout berechnet, aus den Steuereinstellungen des Shops und der Lieferadresse in diesem Moment, während das Angebot eine Schätzung von der Angebotszeit trug. Eine geänderte Adresse, eine Steuerbefreiung, die nicht über die Purchasing Entity gegriffen hat, oder eine geänderte Steuereinstellung dazwischen verschieben die Zahl. Die Lösung ist nicht, die Schätzung exakt zu machen – das geht nicht –, sondern beide bei der Umwandlung zu vergleichen und die Umwandlung anzuhalten, wenn sie um mehr als einen Schwellenwert abweichen.

Warum wurde das Angebot zum falschen Preis umgewandelt?

Meist aus einem von drei Gründen. Die Position wurde ohne priceOverride gesendet, sodass Shopify sie aus dem Live-Katalog bepreist hat; die Überschreibung wurde in der falschen Währung gesendet; oder ein Rabatt hat sich auf den verhandelten Preis gestapelt, weil automatische Rabatte oder Checkout-Codes am Entwurf aktiviert blieben. Prüfen Sie im Berechnungsergebnis originalUnitPriceSet, das Flag priceOverride und platformDiscounts je Position gegen die angenommene Version.

Was passiert, wenn der Bestand zwischen Annahme und Umwandlung ausgeht?

Shopify legt den Entwurf trotzdem an – ein Entwurf hält keinen Bestand, solange reserveInventoryUntil nicht gesetzt ist –, und der Checkout der Käuferin scheitert mit einem Fehler „nicht vorrätig“, außer die Variante erlaubt Überverkauf. draftOrderCalculate meldet den Fehlbestand als Nutzerfehler, sodass eine Umwandlung, die ihn liest, den Händler vorher warnen kann; der Händler kann Bestand ergänzen und reservieren, die Zahlung im Admin entgegennehmen oder die Rechnung zurückhalten.

Kann ich ein gescheitertes draftOrderCreate wiederholen?

Nur, wenn Sie wissen, dass es gescheitert ist, bevor Shopify den Entwurf angelegt hat. Die Mutation hat keinen Idempotenzschlüssel, sodass eine Wiederholung nach unbekanntem Ausgang einen zweiten Entwurf anlegen kann. Speichern Sie vor dem Aufruf einen Idempotenzschlüssel und eine Beanspruchung, halten Sie die Entwurfs-ID sofort nach der Rückkehr fest, und leiten Sie einen unbekannten Ausgang an eine Person statt in eine Wiederholungsschleife.

Sollte die Angebotsebene den Bestellentwurf schon zur Angebotszeit anlegen, um den Preis zu sichern?

Nein. Ein Entwurf sperrt seine Preise nicht, wenn man es ihm nicht sagt, hält keinen Bestand, wenn nicht reserviert, wird nach einem Jahr Inaktivität gelöscht und trennt seinen Checkout, wenn er bearbeitet wird. Ihn zur Angebotszeit anzulegen stellt ein veränderbares, alterndes Objekt mitten in die Verhandlung. Legen Sie ihn einmal an, bei der Annahme, aus der versiegelten Version.

Woher weiß ich, dass die eingetroffene Bestellung zu diesem Angebot gehört?

Über ein Attribut, das die Angebotsebene beim Anlegen auf den Entwurf geschrieben hat und aus den Notiz-Attributen des orders/create-Payloads zurückliest – nie über den Abgleich von Summen oder Kunden. Der Webhook kann doppelt und spät eintreffen, also muss der Handler idempotent sein, und ein Abgleichjob muss Shopify fragen können, ob ein Entwurf eine Bestellung hat.

Berechnet eine geteilte Umwandlung den Versand doppelt?

Das kann sie, weil jeder Bestellentwurf eigenständig ist und seine eigene Versandposition trägt. Die Angebotsebene muss den angebotenen Versand auf die Entwürfe verteilen – nach dem Anteil jedes Entwurfs an der angenommenen Zwischensumme oder nach einem ausdrücklichen Betrag je Entwurf, den der Händler setzt – und das auf jeder Rechnung sagen.

Quellen

Shopify-Seiten, alle gelesen am 22. September 2026 bei API-Version 2026-07, sofern nicht anders datiert:

• draftOrderCalculate, CalculatedDraftOrder und DraftOrderWarning
• DraftOrderInput, DraftOrderLineItemInput und PurchasingEntityInput
• draftOrderUpdate und draftOrderComplete (gelesen am 21. September 2026)
• Bestellentwürfe anlegen und Rechnungen für Bestellentwürfe senden
• B2B-Bestellungen mit Bestellentwürfen anlegen und Zahlungsziele im B2B einrichten (gelesen am 21. September 2026)
• Mengenregeln und Mengenpreise (gelesen am 21. September 2026)
• Webhooks und Webhook-Zustellungen prüfen (gelesen am 20. September 2026)

QuotWays Umwandlungs-, Abweichungs-, Idempotenz- und Abgleichverhalten ist aus seinem Quellcode beschrieben; die Darstellung für Händler steht in den oben verlinkten Docs. Die Tarifunterschiede stehen auf der Preisseite; die Fakten zu Bestellentwürfen und Zahlungszielen werden in der Shopify-B2B-Referenz aktuell gehalten.