Une commande provisoire Shopify n'est pas un devis : la machine à états derrière chacun

Une commande provisoire Shopify est l'enregistrement d'une commande qui attend d'être payée. Elle a trois états - ouverte, facture envoyée, terminée - et chacun d'eux suppose que le prix est déjà convenu. Un devis est l'enregistrement de la façon dont le prix se convient : une demande, une proposition, des révisions, des contre-offres, des approbations et une acceptation.

Shopify a un objet pour le premier et aucun pour le second, si bien qu'un projet B2B qui a besoin de négociation doit modéliser les états du devis ailleurs et créer la commande provisoire à la fin.

C'est toute la réponse ; le reste de cette page en est la preuve. Elle passe en revue, champ par champ, ce que la commande provisoire de Shopify modélise réellement, puis les états dont une négociation a besoin et qu'aucun champ de commande provisoire ne peut contenir, puis la place de la commande provisoire une fois les deux séparés. Elle s'adresse au développeur d'agence dont le premier réflexe, sur un projet de devis B2B, est « pourquoi ne pas simplement utiliser les commandes provisoires ? » - un bon réflexe, parce que la commande provisoire est la bonne fin, et un réflexe coûteux quand on lui demande d'être aussi le milieu.

Tout ce qui concerne Shopify ci-dessous a été vérifié dans la documentation de Shopify le 21 septembre 2026, en version d'API 2026-07 ; les sources sont listées à la fin. Là où la page décrit comment QuotWay modélise les états, c'est une mise en œuvre du schéma, et le schéma vaut aussi pour un développement sur mesure.

Ce qu'une commande provisoire modélise

L'énumération DraftOrderStatus de Shopify a trois valeurs, et leurs définitions sont la description la plus courte de ce à quoi sert une commande provisoire. OPEN : « la commande provisoire est ouverte. Elle n'a pas été payée et aucune facture n'a été envoyée. » INVOICE_SENT : « une facture pour la commande provisoire a été envoyée au client. » COMPLETED : « la commande provisoire a été payée. » Il n'y a pas de quatrième valeur. Rien dans l'énumération ne décrit un prix demandé, proposé, révisé ou refusé, parce que l'objet commence après que cela s'est produit.

Les champs autour du statut disent la même chose. invoiceSentAt est l'heure à laquelle la facture a été envoyée par e-mail pour la dernière fois, un seul horodatage écrasé à chaque envoi. completedAt est le moment où la commande a été créée à partir du brouillon. ready indique si le brouillon peut être finalisé. order pointe vers la commande une fois qu'elle existe. paymentTerms, deposit, amountDueNowSet et amountDueLaterSet décrivent comment le total convenu sera encaissé. anyVariantPricesOverridden indique si une ligne porte un prix différent de celui du catalogue - il enregistre qu'un prix a été modifié, pas à partir de quoi, par qui, ni si l'acheteur a accepté.

Une commande provisoire est aussi modifiable pendant toute sa vie. draftOrderUpdate prend un DraftOrderInput complet et remplace ce qui s'y trouve - les lignes sont échangées en bloc, pas corrigées une à une - et la documentation ne pose aucune restriction à la mise à jour d'un brouillon dont la facture est déjà partie. Elle avertit seulement de ce qui se passe alors : une mise à jour après le début d'un paiement dissocie ce paiement, et la commande peut ensuite être créée tandis que le brouillon reste ouvert. La chronologie du brouillon (events) enregistre chacune de ces modifications comme un BasicEvent, dont le champ message est « un texte lisible par un humain qui décrit l'événement ». C'est un journal attestant qu'une modification a eu lieu ; ce n'est pas une version numérotée que l'on peut rouvrir, et aucun champ ne renvoie les lignes telles qu'elles étaient avant la modification.

Pour le B2B, Shopify ajoute ce dont une commande professionnelle a besoin, et toujours rien de ce dont une négociation a besoin. Une commande provisoire peut naître dans l'admin, ou depuis la boutique : lorsqu'un site d'entreprise est réglé sur « Soumettre toutes les commandes comme provisoires pour vérification » (l'aperçu du paiement de Shopify nomme encore le même réglage « N'autoriser que les commandes provisoires au paiement »), ses acheteurs voient au paiement un bouton Soumettre pour approbation à la place de l'étape de règlement, et le brouillon arrive sur la page Commandes provisoires du marchand avec ses prix verrouillés. Le marchand peut modifier produits et quantités, ajouter un numéro de bon de commande, fixer des conditions de paiement et un acompte, verrouiller ou déverrouiller les prix, envoyer la facture ou créer la commande directement. Le verrouillage des prix mérite une lecture précise : il « empêche les prix d'être augmentés, mais empêche aussi leur baisse automatique » - il fige le prix que le brouillon a déjà, ce qui n'est pas la même chose qu'enregistrer un prix sur lequel deux parties se sont entendues. Quand l'acheteur paie depuis le lien de facture, le brouillon devient une commande marquée payée ; avec des conditions de paiement, la commande démarre en attente et passe par partiellement payée puis payée à mesure que Shopify encaisse selon l'échéancier. Et un brouillon que personne ne modifie pendant un an est supprimé - l'horloge repart à chaque modification, une raison de plus pour que le brouillon ne soit pas l'endroit où vit une négociation lente.

Le journal des modifications de Shopify cadre la séquence exactement. La note de juillet 2024 qui a apporté les conditions de paiement aux factures de commandes provisoires dit que la facture donne aux clients « l'occasion de vérifier leur panier négocié et leurs prix avant de passer commande ». Négocié, au passé, avant que la commande provisoire soit passée. La négociation a eu lieu ailleurs.

Ce qu'une commande provisoire ne peut pas modéliser

Le tableau liste ce qu'une négociation B2B doit enregistrer et ce que la commande provisoire offre pour chacun. La colonne du milieu est l'honnête : là où la commande provisoire a un champ, il est nommé ; là où elle n'en a pas, la ligne le dit.

Une négociation doit enregistrer	Commande provisoire	Ce qu'il faut réellement
Le prix demandé par l'acheteur	Aucun champ. La ligne a un prix ; elle ne sait pas si l'acheteur ou le vendeur l'a fixé	Un prix demandé par ligne, tenu à part des prix proposé et final
La proposition du vendeur telle qu'envoyée	Les lignes actuelles. draftOrderUpdate les remplace en bloc	Une version numérotée, verrouillée à l'instant où elle part
L'historique des révisions	Une chronologie de textes d'événements lisibles	Chaque version, réouvrable, avec un comparatif entre deux versions quelconques
Une contre-offre de l'acheteur	Rien. Les actions de l'acheteur sur un brouillon sont « payer la facture » ou « ne rien faire »	Une version rédigée par l'acheteur, avec le prix demandé par ligne
Une approbation du marchand avant l'envoi de l'offre	Rien. Les permissions du personnel délimitent quelles commandes un utilisateur voit, pas si une offre peut partir	Une règle qui retient une proposition, et la décision avec son auteur
Une chaîne d'approbation côté acheteur	Rien. « Soumettre pour approbation » demande au marchand d'approuver la commande de l'acheteur	Un état sur lequel les approbateurs de l'acheteur peuvent agir, chaque étape enregistrée
Accepter certaines lignes et laisser les autres ouvertes	Rien. Un brouillon est payé en entier ou pas du tout	Une acceptation par ligne, les lignes non retenues restant ouvertes pour un tour ultérieur
L'expiration d'une offre	La purge après un an d'inactivité, une échéance de ménage, pas une échéance commerciale	Une date de validité fixée par le vendeur, après laquelle accepter et contrer sont retirés
L'immuabilité une fois envoyée	Aucune. Un brouillon dont la facture est envoyée reste modifiable, ce qui dissocie tout paiement en cours	Une version envoyée qui ne peut être modifiée en place ; un changement est une nouvelle version
Qui peut faire chaque mouvement	Les permissions de l'utilisateur admin	Chaque transition autorisée à un acteur nommé - acheteur, marchand ou système - et refusée à tout autre
D'où vient le prix	anyVariantPricesOverridden dit qu'une ligne a été remplacée, pas à partir de quoi	Le prix catalogue d'où la négociation est partie, résolu pour le site de l'acheteur, avec l'identifiant du catalogue comme provenance
Les états terminaux	COMPLETED (payée), ou supprimée	Refusé, expiré, annulé, remboursé et clos comme fins distinctes, parce que chacune se rapporte et se relance différemment

Rien de tout cela n'est une critique de la commande provisoire. C'est un objet précis pour une tâche précise. La faute tient seulement à lui demander la tâche d'avant la sienne.

Les états de devis pour lesquels Shopify n'a pas d'objet

Une machine à états de devis n'a pas besoin d'être grande, mais elle doit être explicite, parce que chaque état répond à une question que quelqu'un posera plus tard : que pouvait faire l'acheteur à ce moment, que pouvait faire le marchand, et qui a fait quoi. Les états ci-dessous sont ceux qu'utilise QuotWay ; un développement sur mesure les nommerait autrement et aurait besoin du même ensemble.

Demandé. L'acheteur a demandé. Des lignes, des quantités, les prix qu'il espère, une note, un numéro de bon de commande, des champs personnalisés, des pièces jointes. Le marchand n'a encore rien fait. Cet état existe pour que la demande soit un enregistrement avant que quiconque l'ait chiffrée - l'article d'architecture explique pourquoi la demande elle-même est une donnée que Shopify ne détient jamais.

En examen. Un marchand l'a ouverte. Ici il chiffre les lignes à partir du prix catalogue de l'acheteur - résolu pour son site d'entreprise, pas copié d'une liste - ajoute ou retire des lignes, ajoute la livraison et rédige la proposition.

En attente d'approbation marchand. Une règle a retenu la proposition pour quelque chose qui la concerne : son total, les produits qu'elle contient, l'entreprise, la balise de l'acheteur. Le devis ne part pas chez l'acheteur tant que l'approbateur n'a pas agi, et sa décision est enregistrée avec son nom. Les permissions du personnel Shopify ne savent pas exprimer « une proposition au-dessus de ce montant passe par un responsable avant de partir » ; c'est dans cet état que vit cette règle.

Proposition envoyée. L'offre est partie. C'est une version numérotée, et cette version est désormais verrouillée : le document reçu par l'acheteur est une pièce commerciale, et la piste d'audit doit pouvoir dire ce qu'il contenait. Un changement est une nouvelle version, jamais une modification. À partir d'ici, l'acheteur peut accepter, en accepter une partie, contrer, refuser, ou router vers ses propres approbateurs.

En attente d'approbation acheteur. L'organisation de l'acheteur a son propre visa - un responsable, un contact finance. Le « soumettre pour approbation » de Shopify n'est pas cela : il demande au marchand d'approuver la commande de l'acheteur, pas au responsable de l'acheteur d'approuver l'offre du vendeur. Quand la chaîne se termine, le devis revient à proposition envoyée avec les décisions de la chaîne au dossier.

Contre-offre. L'acheteur a répondu avec d'autres chiffres. La contre-offre est elle-même une version, rédigée par l'acheteur, avec le prix demandé par ligne, et le marchand qui l'ouvre renvoie le devis en examen. La proposition suivante est la version n+1. Une commande provisoire n'a aucun moyen de représenter cet état : les seules actions de l'acheteur sur un brouillon sont payer ou attendre.

Partiellement acceptée et entièrement acceptée. L'acheteur a pris toutes les lignes, ou un sous-ensemble strict. Les lignes non retenues restent ouvertes - elles peuvent être acceptées à un tour ultérieur ou reproposées - et les prix des lignes acceptées sont désormais scellés ; rien après ce point ne modifie un prix. À partir de l'offre Professional, l'acheteur décide ligne par ligne (comment fonctionne l'acceptation partielle) ; sur toutes les offres, l'acceptation de la proposition entière existe.

Partiellement convertie, entièrement convertie, facture envoyée, commande terminée. La commande provisoire existe maintenant. Une commande provisoire fait passer le devis à partiellement converti, parce qu'un sous-ensemble accepté peut devenir une commande provisoire pendant que le reste se renégocie ; entièrement converti quand chaque ligne acceptée a sa commande provisoire ; facture envoyée quand la facture de chaque brouillon est partie ; commande terminée quand le webhook orders/create de Shopify dit que la commande existe. Ces états reflètent les trois de Shopify plus la commande, et ils sont pilotés par les événements de Shopify plutôt que par les suppositions de la couche de devis.

Refusé, expiré, commande annulée, commande remboursée, clos. Les fins. Elles sont distinctes parce qu'elles se rapportent différemment - une proposition refusée est un signal de prix, une proposition expirée un signal de relance, une commande remboursée l'affaire de la finance - et parce que « clos » est l'archivage explicite, par un opérateur, de n'importe laquelle des autres.

« Soumettre pour approbation » est l'examen du marchand, pas la négociation de l'acheteur

Le seul endroit où le B2B natif de Shopify place un état entre « l'acheteur veut ceci » et « payé » est le réglage de site d'entreprise « Soumettre toutes les commandes comme provisoires pour vérification ». Il mérite une description claire, parce qu'il est souvent pris pour un flux de devis.

Quand le réglage est actif, chaque commande de ce site arrive sous forme de brouillon : l'acheteur constitue un panier aux prix du catalogue, voit une bannière indiquant que le paiement sera dû à la confirmation de la commande, et appuie sur Soumettre pour approbation. Le brouillon apparaît avec ses prix verrouillés. Le marchand l'examine, peut modifier produits et quantités, peut fixer des conditions, et soit crée la commande, soit envoie la facture. Le réglage s'active par site, par entreprise, en masse, ou par une action Shopify Flow à la création d'un site.

Ce qu'il modélise, c'est une mise en attente : l'occasion pour le marchand de vérifier une commande avant qu'elle soit confirmée. L'acheteur ne propose rien sur le prix ; le prix est celui du catalogue. Les modifications du marchand sont faites sur le brouillon, pas renvoyées pour accord. Il n'y a ni version, ni contre-offre, ni étape d'acceptation - la prochaine action de l'acheteur est de payer. Pour un marchand dont les affaires se résument à « vérifier la commande, puis la facturer », c'est le bon outil, et une couche de devis serait une charge inutile ; quand il ne faut pas utiliser une application de devis liste ce cas parmi d'autres. Dès qu'une affaire contient un second prix, la mise en attente ne suffit plus.

Comment les transitions sont appliquées

Une liste d'états n'est pas une machine à états tant que les transitions entre eux ne sont pas énumérées et tout le reste refusé. C'est le détail d'ingénierie qui sépare une couche de devis d'une colonne de statut, et c'est là que la mise en œuvre de QuotWay vaut d'être décrite comme un schéma.

Chaque mouvement autorisé est une ligne d'un tableau : l'état qu'il quitte, l'état où il entre, quels acteurs peuvent le faire - l'acheteur, le marchand ou le système - et l'événement qu'il écrit. « Proposition envoyée → contre-offre » est autorisé à l'acheteur et écrit un événement contré. « Contre-offre → en examen » est autorisé au marchand et écrit un événement examiné. « Entièrement acceptée → partiellement convertie » est autorisé au marchand ou au système, parce qu'une conversion peut tourner depuis une file d'attente sans utilisateur connecté, et écrit un événement groupe de conversion créé. Une transition absente du tableau lève une erreur, et comme le changement d'état et son événement sont écrits dans une seule transaction de base de données, l'erreur annule les deux : le devis ne peut pas rester dans un état que son historique n'explique pas.

Deux règles du tableau sont des jokers, et ce sont celles qu'un développement sur mesure oublie le plus souvent. Tout état non terminal peut passer à expiré quand la date de validité est dépassée - c'est une règle appliquée à chaque état, exécutée par un balayage quotidien, de sorte qu'un devis ne peut pas échapper à l'expiration en se trouvant dans un état inhabituel. Et tout état terminal peut passer à clos, l'archive de l'opérateur. Cinq états sont terminaux : refusé, expiré, commande annulée, commande remboursée, clos. Commande terminée n'en fait délibérément pas partie, parce que le webhook orders/updated de Shopify peut encore signaler une annulation ou un remboursement, et le devis doit pouvoir suivre la commande jusque-là.

Les états de conversion sont l'autre endroit où le schéma compte. Le devis ne décide pas qu'il est « converti » quand il appelle draftOrderCreate ; il enregistre l'identifiant de la commande provisoire et attend. Il passe à commande terminée quand orders/create arrive - y compris dans le cas où l'acheteur paie depuis l'URL de la facture avant que le marchand ait explicitement envoyé la facture, ce que la machine autorise comme transition directe depuis entièrement convertie. Un projet qui avance son propre état au succès de l'appel d'API plutôt qu'au webhook de Shopify affichera un jour « commande terminée » pour un paiement abandonné.

Ce même tableau est ce qui permet à la piste d'audit de répondre aux questions un an plus tard. Parce que chaque transition nomme son acteur et écrit son événement, « qui a approuvé ce prix », « l'acheteur a-t-il jamais vu la version 2 » et « pourquoi ce devis est-il expiré » sont des consultations, pas des enquêtes.

Où se place la commande provisoire

Cantonnée à sa tâche, la commande provisoire est la meilleure partie de la conception, parce que Shopify se charge d'encaisser. Le schéma est : la créer une fois, à l'acceptation, avec tout ce que la négociation a réglé écrit dessus.

Le prix unitaire négocié va sur chaque ligne de variante comme priceOverride dans la devise de présentation, si bien que la commande correspond au centime à la version acceptée ; les lignes personnalisées portent leur propre prix. La purchasingEntity - entreprise, site, contact - en fait un brouillon B2B, de sorte que l'exonération fiscale et les réglages de paiement du site s'appliquent. Le modèle de conditions de paiement retenu pour l'affaire est posé sur le brouillon, et si l'affaire comportait un acompte - sur les boutiques Shopify Plus, à partir de l'offre Professional de QuotWay, de 1 à 99 % - il voyage aussi sur le brouillon, pour que le paiement encaisse l'acompte et que Shopify échelonne le solde. Le numéro de bon de commande et la note de l'acheteur vont dans les champs du brouillon. Avant de le créer, draftOrderCalculate prévisualise les totaux, de sorte que les changements de taxe, de livraison et de stock depuis la proposition sont détectés et affichés plutôt que découverts sur la facture ; l'article d'architecture détaille le passage de prix et la page de la fonctionnalité de conversion le montre côté marchand.

Une acceptation partielle devient une commande provisoire pour les seules lignes acceptées ; les lignes encore ouvertes restent sur le devis pour le tour suivant, et une acceptation ultérieure devient une seconde commande provisoire. C'est pourquoi le devis a un état partiellement converti et pourquoi une conversion est idempotente par ensemble accepté - réessayer une création échouée ne doit pas produire deux brouillons pour les mêmes lignes.

À partir de là, la machine de Shopify tourne seule. draftOrderInvoiceSend fait passer le brouillon à facture envoyée et envoie le lien de paiement ; l'acheteur paie, ou paie plus tard selon les conditions depuis son compte client ; le brouillon se termine ; la commande existe avec un statut de paiement en attente, partiellement payée ou payée. La couche de devis écoute et reflète. Elle ne modifie pas le brouillon après l'envoi - la négociation est finie, et une modification dissocierait un paiement en cours - et elle ne traite jamais le brouillon comme l'endroit où rouvrir un prix. Si le prix doit changer après l'acceptation, c'est une nouvelle proposition sur le devis, une nouvelle acceptation et une nouvelle commande provisoire ; la mécanique côté marchand est dans les commandes provisoires Shopify pour le B2B, et les pièges propres à la commande provisoire - stock non réservé par défaut, plafond de 500 lignes, purge après un an - dans l'article sur les limites.

Cinq signes qu'une commande provisoire sert de devis

Voici ce qu'une agence trouve lors d'une mission de sauvetage, listé pour le reconnaître tôt.

1. La page Commandes provisoires est le pipeline. Des dizaines de brouillons ouverts, certains vieux de plusieurs mois, avec des notes comme « v3 - en attente de l'acheteur ». La purge après un an finira par supprimer les plus anciens, et aucun rapport ne dit à quelle étape chacun se trouve, parce que l'objet n'a pas d'étape.
2. Les prix sont modifiés en place. Un brouillon modifié quatre fois pour quatre tours de marchandage, sans trace des tours un à trois hormis les entrées « modifié » de la chronologie. Quand l'acheteur conteste le chiffre final, personne ne peut montrer ce qui a été proposé avant.
3. Les factures sont envoyées comme des offres. La facture est la proposition, et « l'acheteur n'a pas payé » est le seul signal qu'il n'a pas accepté. Les conditions de paiement aggravent les choses, parce qu'une facture impayée à 30 jours est indiscernable d'une facture refusée pendant un mois.
4. La contre-offre de l'acheteur arrive par e-mail. Comme le brouillon n'a pas d'état rédigé par l'acheteur, la négociation se déroule dans une boîte de réception et le brouillon est mis à jour ensuite à la main - dès que les deux divergent, la commande est fausse.
5. L'approbation est un message Slack. Un commercial demande à un responsable si une remise convient, reçoit un pouce levé et modifie le brouillon. Rien ne relie l'approbation au prix qu'elle a approuvé.

Chacun est un état que la commande provisoire ne peut pas contenir et qui est donc tenu quelque part de manière informelle. Le remède n'est pas une commande provisoire plus grosse ; c'est un objet devis devant elle.

Questions fréquentes

Quelle est la différence entre une commande provisoire et un devis sur Shopify ?

Une commande provisoire est l'enregistrement Shopify d'une commande en attente de paiement : elle a trois statuts - ouverte, facture envoyée, terminée - et ses lignes portent un prix chacune. Un devis est l'enregistrement du chemin vers ce prix : la demande de l'acheteur, les propositions numérotées du vendeur, les contre-offres, les approbations et l'acceptation. Shopify n'a pas d'objet devis, donc une couche de devis tient ces états et crée la commande provisoire une fois le prix convenu.

Pourquoi ne pas simplement utiliser les commandes provisoires comme devis ?

Parce que la commande provisoire n'a de champ pour rien de ce qui précède l'accord. Elle ne peut contenir ni prix demandé, ni contre-offre, ni version verrouillée, ni décision d'approbation, ni acceptation par ligne ; ses lignes sont remplacées en bloc à chaque modification, et sa chronologie est du texte plutôt que des versions réouvrables. Une affaire à un seul tour - l'acheteur soumet, le marchand vérifie, l'acheteur paie - y tient ; une affaire avec un second prix, non.

Quels sont les statuts d'une commande provisoire Shopify ?

Trois, dans l'énumération DraftOrderStatus en API 2026-07 : OPEN (non payée, aucune facture envoyée), INVOICE_SENT (une facture a été envoyée au client) et COMPLETED (payée). Une fois terminée, la commande qu'elle a créée a son propre statut de paiement - en attente, partiellement payée, payée, remboursée, et ainsi de suite.

« Soumettre pour approbation » est-il un flux de devis ?

Non. C'est un réglage de site d'entreprise qui transforme chaque commande de ce site en un brouillon que le marchand examine avant confirmation. L'acheteur soumet un panier aux prix du catalogue ; le marchand peut le modifier, puis le facture ou crée la commande. Il n'y a ni proposition de prix de l'acheteur, ni version, ni étape d'acceptation. Il modélise une mise en attente de la commande, ce qui est exactement ce qu'il faut aux marchands qui n'ont besoin que de vérifier les commandes avant de facturer.

Une commande provisoire peut-elle être modifiée après l'envoi de la facture ?

Oui. draftOrderUpdate n'a aucune restriction sur les brouillons dont la facture est envoyée, et toute modification remet à zéro la purge d'un an d'inactivité. Shopify avertit toutefois qu'une mise à jour après le début d'un paiement dissocie ce paiement - la commande peut alors être créée tandis que le brouillon reste ouvert. Cette modifiabilité est ce qui fait de la commande provisoire le mauvais enregistrement d'une offre : une proposition envoyée ne doit pas être modifiable en place.

Quand faut-il créer la commande provisoire ?

À l'acceptation, une seule fois, avec les prix négociés en priceOverride sur les lignes, l'entité acheteuse, les conditions de paiement, l'éventuel acompte et le numéro de bon de commande déjà dessus. La créer plus tôt - à la proposition - place un objet modifiable et purgeable au milieu de la négociation ; la créer plus tard laisse l'acheteur sans rien à payer. Une acceptation partielle crée un brouillon pour les lignes acceptées et laisse le reste ouvert sur le devis.

Les devis expirent-ils, et les commandes provisoires ?

Différemment. L'expiration d'un devis est une date commerciale fixée par le vendeur - après elle, accepter et contrer sont retirés, et l'acheteur a besoin d'une nouvelle proposition. La seule horloge d'une commande provisoire est du ménage : les brouillons créés le 1er avril 2025 ou après sont supprimés après un an sans modification. Ni l'un ni l'autre ne doit faire le travail de l'autre.

Sources

Pages Shopify, toutes lues le 21 septembre 2026 en version d'API 2026-07 :

• Objet DraftOrder, énumération DraftOrderStatus et BasicEvent
• draftOrderUpdate et draftOrderComplete
• Commandes provisoires pour les applications B2B
• Créer des commandes B2B avec des commandes provisoires et gérer les réglages du paiement en B2B
• Configurer les conditions de paiement en B2B, objet PaymentTerms et OrderDisplayFinancialStatus
• Envoyer des factures pour des commandes provisoires et commandes provisoires et factures
• Action Flow : passer le paiement d'un site d'entreprise en brouillon
• Journal des modifications, 8 juillet 2024 : envoyer des factures de commandes provisoires avec conditions de paiement

La machine à états, les règles de transition et le comportement de conversion de QuotWay sont décrits à partir de son code source ; la version pour les marchands est dans construire et envoyer une proposition, comment fonctionne l'application des approbations et convertir un devis en commande provisoire. Les différences entre offres sont sur la page des tarifs.