Quand le devis et la commande Shopify divergent : ce qui dérive après la conversion

Une fois un devis converti sur Shopify, quatre enregistrements décrivent la même affaire : le devis accepté, la commande provisoire, la commande, et ce que détient l'ERP ou le CRM. Ils cessent de concorder d'un petit nombre de façons documentées - un brouillon modifié après la conversion, un brouillon encore ouvert alors que sa commande existe, un brouillon supprimé ou purgé au bout d'un an, une commande modifiée, annulée ou remboursée, une modification demandée par l'acheteur, une liste de tags écrasée par un connecteur. Chaque dérive se détecte en comparant deux champs précis, et chaque champ a un seul propriétaire. Réconcilier, c'est choisir ces propriétaires et vérifier les paires à intervalles réguliers.

Cette page est le catalogue de ce qui dérive après que le brouillon existe, de la façon de détecter chaque cas, de le réparer, et de qui possède quel champ à partir de la conversion. Créer exactement une commande provisoire est traité dans comment un devis accepté devient exactement une commande provisoire ; ce qui casse au moment de la conversion est dans les 17 modes de défaillance ; un prix faux dès le départ est diagnostiqué dans pourquoi un devis se convertit au mauvais prix. La « réconciliation » désigne ici les données entre devis et commande, pas le rapprochement des versements ou le rapprochement bancaire.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 9 octobre 2026, en version d'API 2026-10 ; les sources sont en fin de page.

Les quatre comparaisons

Ce qui dérive, et comment le repérer

Classé selon le moment où cela se produit. La « source de vérité » est l'enregistrement qui l'emporte à partir de la conversion.

Avant que la commande existe

#	Ce qui dérive	Cause dans Shopify	Détecter	Réparer	Source de vérité
1	Les lignes ou les totaux du brouillon par rapport à ce qui a été accepté	Le personnel modifie le brouillon après la conversion ; mettre à jour tags écrase toute la liste	Les totaux du payload draft_orders/update comparés aux totaux stockés à la conversion ; DraftOrder.tags comparé aux tags que vous avez écrits	Un changement commercial passe par une nouvelle proposition ou une contre-proposition et un nouveau brouillon, l'ancien brouillon étant supprimé ; un changement logistique est consigné	La version acceptée, jusqu'au paiement
2	Le brouillon est encore ouvert alors que sa commande existe	Une mise à jour pendant un checkout en cours a délié ce checkout : la commande est créée, et « la commande provisoire restera ouverte même après la création de la commande »	Une commande porte votre attribut de conversion, mais DraftOrder.order est null ou le statut n'est pas COMPLETED	Lier la commande par l'attribut ; une personne supprime le brouillon obsolète	La commande
3	Le devis pointe vers un brouillon qui n'existe plus	Le personnel l'a supprimé	draft_orders/delete ; en filet de sécurité, draftOrder(id) ne renvoie rien	Marquer le brouillon comme perdu ; vérifier qu'aucune commande ne porte l'attribut ; recréer ou clore	Shopify
4	La même chose, au bout d'un an	Les brouillons créés à partir du 1er avril 2025 sont supprimés après un an sans modification	draftOrder(id) ne renvoie rien - Shopify ne documente pas si la purge envoie un webhook de suppression	Décider bien avant l'échéance si l'affaire est perdue ou fait l'objet d'un nouveau devis	Shopify
5	La facture est partie et n'a jamais été payée	Une commande n'existe qu'une fois le brouillon payé ou finalisé	draftOrders(query: "tag:… status:invoice_sent") plus l'ancienneté	Relancer, prolonger, ou supprimer le brouillon et clore le devis - les deux ensemble	Le statut du brouillon
6	Le devis a expiré, le brouillon est toujours payable	Un brouillon n'a pas d'autre échéance que la purge	Le devis est expiré alors que DraftOrder.status vaut OPEN ou INVOICE_SENT	Supprimer le brouillon quand le devis expire, ou ne plus faire expirer les devis après la facture	Au choix - mais un seul
7	Une commande payée que la couche de devis ou l'ERP ne connaît pas	La livraison des webhooks n'est pas garantie	draftOrder.order est renseigné mais aucun identifiant de commande n'est stocké ; ou orders(query: "tag:… updated_at:>…") comparé aux identifiants stockés	Rejouer par le même handler de webhook (le balayage)	La commande

Après que la commande existe

#	Ce qui dérive	Cause dans Shopify	Détecter	Réparer	Source de vérité
8	Les lignes ou le total de la commande par rapport à la version acceptée	Le marchand ou une autre application modifie la commande : selon Shopify, la commande issue d'un brouillon créé par une application « peut être modifiée dans votre admin Shopify, et par d'autres applications »	orders/edited ; Order.edited ; originalTotalPriceSet comparé à currentTotalPriceSet	Consigner le motif sur la commande ; ne pas réécrire le devis ; l'ERP suit la commande	La commande pour l'expédition et la facturation ; le devis pour ce qui a été convenu
9	Une modification demandée par l'acheteur, en attente, que l'ERP ou l'entrepôt ne voit pas	Depuis 2026-10, un acheteur peut demander le retrait de lignes non expédiées	Webhooks requested_order_edit/* ; Order.requestedOrderEdits	Suspendre l'expédition tant que la demande est en attente ; l'accepter ou la refuser ; une demande acceptée arrive comme une modification de commande	La commande
10	Le devis montre une affaire en cours, la commande est annulée	L'annulation est « irréversible »	orders/cancelled ; cancelledAt	La consigner par commande ; le devis reste la trace ; un nouveau devis est une nouvelle affaire	La commande
11	Les montants après remboursements et retours	Remboursements par ligne ou sur les frais de livraison ; retours	refunds/create ; returns/* ; currentSubtotalPriceSet	L'avoir de l'ERP vient du remboursement, pas du devis	Les remboursements de la commande
12	L'état d'expédition recopié à plusieurs endroits	Un entrepôt ou un ERP écrit les expéditions dans Shopify	fulfillments/* ; displayFulfillmentStatus	Ne pas recopier l'expédition dans la couche de devis	L'entrepôt ou l'ERP, via Shopify

La forme de l'affaire et ses clés

#	Ce qui dérive	Cause	Détecter	Réparer	Source de vérité
13	« Le devis a une commande, il devrait en avoir deux »	L'acceptation partielle ou la conversion fractionnée crée un brouillon par groupe ; les lignes laissées pour plus tard sont encore ouvertes, pas refusées	Les groupes convertis comparés aux identifiants de commande stockés ; le sous-total de chaque commande comparé à ses lignes acceptées	Réconcilier par groupe ; les lignes encore ouvertes ne manquent pas	La couche de devis pour les lignes encore ouvertes ; les commandes pour ce qui a été acheté
14	Le total du devis ne correspond pas au montant de l'ERP	Le brouillon et la commande sont dans la devise de présentation ; shopMoney est converti	Comparer le devis uniquement avec presentmentMoney	Comptabiliser délibérément depuis un seul côté	Le montant en devise de présentation
15	La commande n'est plus reconnaissable comme issue du devis	Tags écrasés par une écriture de la liste complète ; attribut ou note modifiés	orders(query: "tag:…") comparé aux identifiants stockés ; déclencheurs Events sur order.tags et order.customAttributes	Restaurer depuis l'enregistrement du devis ; les intégrations ajoutent des tags avec tagsAdd, jamais en réécrivant la liste	La couche de devis, qui a écrit les clés une seule fois
16	L'identité de l'acheteur a changé après la conversion	Un contact retiré, un site supprimé ou modifié, des clients fusionnés	company_contacts/delete, company_locations/delete, customers/merge comparés aux identifiants stockés	Avant le paiement, recréer le brouillon pour le bon site ; après, corriger le fichier clients, pas la commande	Le fichier clients de l'ERP, ou Shopify - l'un des deux
17	Un connecteur réécrit des champs que possède la couche de devis	Deux écrivains sur un même champ	Déclencheurs Events par champ ; écart avec ce que la couche de devis a écrit	Limiter le connecteur à ses propres champs	Un écrivain par champ
18	Une intégration a manqué des événements de la couche de devis	Livraison au moins une fois, dans le désordre ; un endpoint en panne	Des trous dans la séquence d'événements ; des livraisons que l'émetteur a abandonnées	Rejouer depuis le flux d'événements, puis depuis l'API	Le journal d'événements de la couche de devis
19	Une tâche de réconciliation annonce « tout va bien » sur d'anciennes commandes	Les applications ne voient que les 60 derniers jours de commandes, sauf avec read_all_orders	Le périmètre de la tâche comparé à l'âge de la commande	Demander read_all_orders, ou réconcilier dans la fenêtre	-

Qui possède quel champ après la conversion

Les patterns d'intégration ERP, CRM et PIM donnent le tableau de propriété pour toute la vie d'une intégration. Celui-ci commence au moment où le brouillon existe :

Champ	Propriétaire après la conversion	Tous les autres	Pourquoi
Lignes, quantités, prix unitaires, conditions et version convenus	La couche de devis - la version scellée acceptée, jamais modifiée	Lecture pour l'audit	C'est la trace de l'accord ; une proposition envoyée est verrouillée
Les lignes encore ouvertes	La couche de devis	Le CRM la lit comme pipeline	Pas converties, et pas perdues
Le contenu du brouillon jusqu'au paiement	La couche de devis l'a écrit une fois ; les modifications du personnel sont des exceptions à consigner	L'ERP ignore les brouillons	Le brouillon est payable - le changer, c'est changer l'affaire
Les lignes, quantités et totaux de la commande	La commande Shopify	L'ERP et l'entrepôt la lisent ; la couche de devis ne la recopie pas	Modifications, remboursements et retours se font sur la commande
Paiement et remboursements	Shopify	L'ERP comptabilise depuis les remboursements ; la couche de devis ne consigne que les états finaux	L'argent circule sur la commande
Expédition	L'entrepôt ou l'ERP, qui écrit dans Shopify	La couche de devis : rien	Un seul écrivain
Facture, grand livre, avoirs	L'ERP ou le système comptable	-	Shopify n'est pas le grand livre
Clés de liaison - les tags du devis, l'attribut de conversion, la ligne de note	La couche de devis les écrit une fois	Les autres ajoutent avec tagsAdd	Mettre à jour tags écrase la liste
Entreprise, site, contact	Le fichier clients de l'ERP ou Shopify - l'un des deux	La couche de devis lit	Un seul écrivain
Statut du devis après la conversion	La couche de devis, déduit des événements de commande de Shopify	Les intégrations lisent	Déduit, jamais l'inverse

La règle qui en découle : ne jamais réécrire les changements de la commande dans le devis. Le devis est ce qui a été convenu ; la commande est ce qui est expédié et payé. Quand ils diffèrent, consignez pourquoi sur la commande.

Events ou webhooks pour ce travail

Events de Shopify est devenu disponible pour tous avec l'API 2026-10, en successeur des webhooks classiques, et les webhooks classiques continuent de fonctionner. Events a des topics pour les commandes, les remboursements, les retours, les ordres d'expédition, les entreprises et les clients, avec des déclencheurs sur des champs individuels - order.tags, order.customAttributes, order.lineItems.quantity entre autres - ce qui convient aux lignes 8, 15 et 17. Il n'a aucun topic pour les commandes provisoires, donc les lignes 1 à 6 ont toujours besoin des webhooks classiques draft_orders/*. Shopify ne documente pas les garanties de livraison d'Events : gardez la tâche de réconciliation ci-dessous, quel que soit votre choix.

Une tâche de réconciliation à reprendre telle quelle

Exécutez-la à intervalles réguliers, sur les identifiants stockés, à l'intérieur de la fenêtre d'accès aux commandes :

1. Les brouillons que vous avez créés et dont vous n'avez pas vu le paiement : draftOrders(query: "tag:<your-tag> updated_at:>…"). Pour chacun, status et order : une commande sans identifiant stocké, c'est la ligne 7 ; un brouillon manquant, la ligne 3 ou 4 ; un vieux brouillon INVOICE_SENT, la ligne 5 ou 6.
2. Les commandes qui portent votre clé : orders(query: "tag:<your-tag> updated_at:>…"). Comparez originalTotalPriceSet et currentTotalPriceSet (ligne 8), vérifiez cancelledAt et le statut financier (lignes 10 et 11), requestedOrderEdits (ligne 9), et que les tags et l'attribut de conversion sont toujours là (ligne 15).
3. Les systèmes extérieurs : pour chaque commande, le montant de l'ERP comparé à presentmentMoney (ligne 14), le nombre de commandes comparé aux groupes convertis (ligne 13).
4. Le périmètre : sans read_all_orders, seuls les 60 derniers jours de commandes sont visibles (ligne 19).

Le côté création - le balayage qui retrouve une conversion dont l'issue est inconnue - est dans l'article sur la conversion idempotente.

Comment QuotWay se comporte

Une implémentation, décrite telle qu'elle fonctionne aujourd'hui :

• Ce sur quoi il fait la correspondance. Chaque brouillon créé par QuotWay porte les tags quotway et quotway-<quote reference>, une note visible du seul marchand avec la référence et la version du devis, et un attribut de conversion qui relie la commande à son groupe de conversion. QuotWay ne modifie, ne finalise ni ne supprime jamais un brouillon après l'avoir créé, et ne modifie jamais les commandes.
• Ce qu'il consigne. Un changement des totaux d'un brouillon converti est consigné dans le journal d'activité du devis, avec les montants avant et après. Une fois un devis à l'état Commande terminée, QuotWay consigne sur le devis l'annulation ou le remboursement total de sa commande. Les remboursements partiels, les retours, les modifications de commande et l'expédition restent sur la commande Shopify - vérifiez-les sur la commande (convertir en commande provisoire).
• Conversions fractionnées et partielles. Chaque groupe accepté devient son propre brouillon et sa propre commande ; les lignes que l'acheteur a laissées pour plus tard restent encore ouvertes sur le devis et peuvent être converties plus tard (acceptation partielle et conversion fractionnée).
• Webhooks de commande manqués. Un balayage vérifie les devis facturés depuis sept jours sans commande et, si Shopify en montre une, la rejoue par le même handler.
• Pour les intégrations. Sur le forfait Enterprise - y compris pendant l'essai gratuit de 14 jours - l'objet devis de l'API liste les identifiants de commande provisoire et de commande Shopify du devis, et un flux d'événements de 30 jours est la voie de rattrapage des webhooks manqués (le flux d'événements). Les forfaits sont sur la page des tarifs ; la conversion est décrite sur convertir les devis en commandes.

Questions fréquentes

Pourquoi une commande provisoire Shopify reste-t-elle ouverte après le paiement du client ?

Le brouillon a été mis à jour pendant que son checkout était en cours, ce qui délie le checkout : la commande est créée, mais « la commande provisoire restera ouverte même après la création de la commande ». Vérifiez DraftOrder.order, liez la commande par votre propre clé, et supprimez le brouillon obsolète.

Existe-t-il un webhook pour le paiement d'une commande provisoire ?

Pas de topic « payé » pour les commandes provisoires. Le paiement crée une commande : écoutez donc orders/create et rattachez-la au brouillon par votre propre attribut ou tag ; le status du brouillon passe à COMPLETED et son champ order est renseigné. draft_orders/update couvre les changements du brouillon, et Events de Shopify n'a aucun topic pour les commandes provisoires en 2026-10.

Le devis doit-il changer quand la commande est modifiée ?

Non. Le devis est la trace de ce qui a été convenu ; la commande est ce qui est expédié et payé. Consignez le motif d'une modification sur la commande et laissez l'ERP suivre la commande.

Comment détecter les modifications de commande pour mon ERP ?

Le webhook orders/edited, le champ edited de la commande, et un écart entre originalTotalPriceSet et currentTotalPriceSet. Avec Events, un déclencheur sur order.lineItems.quantity fait la même chose pour les quantités.

Que sont les modifications de commande demandées par l'acheteur ?

Depuis l'API 2026-10, un acheteur peut demander le retrait de lignes non expédiées d'une commande. La demande arrive par les webhooks requested_order_edit/* et est visible sur Order.requestedOrderEdits ; suspendez l'expédition tant qu'elle est en attente, et une demande acceptée devient une modification de commande ordinaire.

Les commandes provisoires impayées expirent-elles ?

Les brouillons créés à partir du 1er avril 2025 sont supprimés après un an sans modification. Rien d'autre ne les fait expirer : un devis qui expire plus tôt laisse son brouillon payable, sauf si vous le supprimez.

Shopify Events remplace-t-il les webhooks pour la réconciliation ?

Events est le successeur des webhooks classiques et les webhooks classiques continuent de fonctionner, mais il n'a aucun topic pour les commandes provisoires, donc les brouillons ont toujours besoin de draft_orders/*. Shopify ne documente pas les garanties de livraison d'Events : gardez une tâche de réconciliation dans les deux cas.

Pourquoi le total de l'ERP ne correspond-il pas au devis ?

Le devis, le brouillon et la commande sont dans la devise de présentation de l'acheteur ; shopMoney est converti. Les remboursements et les modifications de commande changent le total actuel de la commande. Comparez le devis avec le montant en devise de présentation de la commande et avec son total initial.

Sources

Pages Shopify, lues le 9 octobre 2026 en version d'API 2026-10 :

• draftOrderUpdate - une mise à jour délie un checkout en cours et le brouillon reste ouvert
• DraftOrder et DraftOrderInput - statut, order, tags
• Commandes provisoires - suppression après un an sans modification pour les brouillons créés à partir du 1er avril 2025 ; le paiement crée la commande
• Order - totaux initial et actuel, edited, cancelledAt, requestedOrderEdits
• Modifier des commandes existantes - les commandes créées par une application peuvent être modifiées dans l'admin et par d'autres applications ; la fenêtre de 60 jours sur les commandes
• orderCancel - l'annulation est irréversible
• tagsAdd - ajouter des tags sans écraser la liste
• Topics de webhook et livraison des webhooks HTTPS - topics ; la livraison n'est pas garantie
• Events est désormais disponible pour tous et events et webhooks - topics, déclencheurs par champ, les webhooks classiques continuent
• Notes de version 2026-10 - modifications de commande demandées par l'acheteur

Le comportement de QuotWay est décrit d'après sa documentation publique et le code source de l'application, lus le 9 octobre 2026.