Devis HubSpot vers ERP : retrouver les lignes acceptées

L'administration des ventes reçoit une commande ERP à 192 euros, alors que le client a accepté un devis HubSpot à 180 euros. Le commercial a modifié le prix dans l'opportunité après publication du devis. L'intégration a relu les lignes actuelles de cette opportunité au moment du transfert, sans retrouver celles du document accepté.

Le montant diffère ici de douze euros, avec un risque de correction manuelle avant facturation. L'incident peut aussi porter sur une référence, une quantité ou deux prestations regroupées à tort. Il touche les entreprises qui préparent leurs offres dans HubSpot et exécutent la commande dans un ERP, avec une équipe commerciale et une équipe ADV responsables de moments différents du dossier.

En pratique, le transfert doit partir du devis sélectionné et de ses propres lignes, avec une preuve d'acceptation qualifiée pour ce document. Le passage de l'opportunité en « gagné » peut déclencher une recherche ; il ne suffit pas à choisir entre plusieurs devis. Nous allons distinguer produit et ligne commerciale, reconstruire un exemple chiffré et éprouver les décisions de transmission avec huit situations fictives.

Ce cadrage appartient à notre activité d'intégration API entre les logiciels de l'entreprise. Pour une intégration HubSpot avec votre ERP, Dawap définit les contrats d'échange et l'application de suivi, en coordination avec l'intégrateur ERP lorsque son intervention est nécessaire.

Anatomie du dossier : une opportunité, plusieurs devis, plusieurs jeux de lignes

Une opportunité sert à suivre une vente en préparation. Un devis présente une proposition déterminée au client. La commande ERP engage ensuite l'exécution selon les règles de gestion de l'entreprise. Même lorsqu'ils concernent le même acheteur, ces trois objets ne représentent pas nécessairement la même photographie commerciale.

Retrouver les lignes du document publié

La documentation HubSpot sur l'éditeur de lignes explique que la création d'un devis depuis une opportunité clone les lignes avec de nouveaux identifiants. Les lignes d'un devis publié sont figées ; les changements ultérieurs dans l'opportunité ne les modifient pas. Le devis et l'opportunité peuvent donc présenter des prix différents sans qu'une anomalie technique ait eu lieu.

La question de contrôle devient : à quel parent appartient chaque ligne extraite ? Un identifiant retrouvé dans l'opportunité ne constitue pas, à lui seul, la preuve qu'il est aussi celui du devis accepté. Le relevé destiné à l'ADV doit montrer le document retenu et les associations lues pour ce document.

Garder la filiation sans mélanger les versions

Conservons, dans notre modèle de suivi, le portail HubSpot, l'opportunité, le devis et sa révision commerciale qualifiée. Cette révision est une référence de notre application ; elle n'est pas présentée comme un champ natif universel de HubSpot. Si le processus remplace une offre par une autre, il faut retrouver quel document est retenu et lequel devient obsolète.

Deux devis présents dans la même opportunité demandent une décision explicite, même si leurs totaux sont identiques. L'un peut correspondre à une livraison fractionnée, l'autre à une livraison unique. Choisir le plus récent sur sa seule date de modification risque de transmettre un brouillon au lieu de l'offre effectivement retenue.

Pour qui : l'ADV doit savoir quelle acceptation autorise la commande

Le besoin devient critique lorsque l'ERP crée une commande ferme, réserve des ressources ou alimente un processus de préparation. Avant ce passage, l'ADV doit pouvoir retrouver la proposition retenue par le client. Une pièce jointe reçue par courriel et un changement d'étape commerciale ne donnent pas automatiquement la même autorisation.

Qualifier le mécanisme réellement utilisé dans le portail

Le projet commence par un inventaire du type de devis utilisé, des fonctionnalités accessibles, des droits de lecture et de la manière dont l'entreprise reconnaît l'engagement du client. Le responsable commercial précise si le dossier repose sur une signature, un bon de commande ou une validation ADV documentée. Le spécialiste juridique intervient si la portée de cet engagement doit être déterminée.

Le connecteur lit ensuite les données effectivement exposées par les interfaces disponibles. Il ne fabrique pas une acceptation depuis un libellé ressemblant à un état final. Dans les exemples suivants, « acceptation qualifiée » désigne une preuve fournie à notre modèle de décision ; aucun nom de propriété ou statut natif HubSpot n'est supposé.

Distinguer commande ferme et préparation commerciale

Si l'entreprise souhaite préparer un dossier ERP avant l'accord, elle peut définir un objet provisoire et ses restrictions, à condition que son ERP le permette réellement. Le contrat doit indiquer ce que cette préparation autorise : consultation, étude de disponibilité ou brouillon interne. Elle ne doit pas déclencher les effets réservés à une commande validée.

La priorité consiste à sécuriser un seul parcours d'engagement connu. Les autres modes d'acceptation restent différés tant que leur preuve, leur source et leur responsabilité ne sont pas définies. Refuser une transmission ambiguë laisse le commercial poursuivre le dossier sans transformer son étape de pipeline en autorisation d'exécution.

Produit, ligne de devis et article ERP : trois identités à conserver

La référence du produit répond à la question « que vend-on ? ». L'identité de la ligne répond à « quelle occurrence de cette vente figure sur ce document ? ». L'article ERP apporte encore une autre référence, dans une société et un catalogue déterminés. Une table de correspondance doit conserver ces niveaux séparément.

Deux lignes du même produit peuvent être légitimes

Un devis peut contenir deux lignes d'une même référence pour des dates de livraison distinctes. Dans notre exemple fictif, deux unités à 40 euros figurent sur la première ligne, puis une unité à 40 euros sur la seconde. Le total atteint 120 euros et les deux lignes restent nécessaires pour préserver la séparation commerciale prévue.

Paradoxalement, un total correct peut masquer une commande mal construite. Regrouper ces lignes donne toujours trois unités et 120 euros, mais efface la distinction qui permet à l'ADV de suivre les deux engagements. Une déduplication par produit peut même supprimer une occurrence au lieu de regrouper ses quantités.

Traiter les lignes libres sans inventer une référence ERP

La documentation historique de l'objet line item distingue les lignes issues d'un produit et les lignes propres à un devis. Elle recommande aussi des jeux de lignes propres à chaque parent. Cette distinction éclaire le modèle métier ; les chemins d'API historiques du guide ne constituent pas une recommandation de version pour une nouvelle intégration.

Une prestation saisie librement peut manquer de correspondance ERP. L'équipe choisit alors une règle vérifiable : revue manuelle, article de service autorisé ou création encadrée par le gestionnaire du catalogue. Le connecteur ne remplace pas cette absence par une référence passe-partout sans accord, et il n'utilise pas le nom commercial comme identifiant stable.

Exemple concret : retrouver les 180 euros réellement proposés

Nous travaillons ici avec des montants nets fictifs en euros, des quantités entières et des prix déjà normalisés. Taxes, remises, frais, périodicité et conversion de devises sont exclus du calcul. Dans un vrai dossier, chacun de ces éléments demande son propre mapping, ses règles de calcul et une validation avec l'équipe ERP.

Comparer les ensembles de lignes avant les montants

Le devis Q-501 porte les lignes L-701 et L-702 : trois unités à 40 euros, puis deux unités à 30 euros. Son montant calculé vaut 3 × 40 + 2 × 30 = 180 euros. L'opportunité D-101 porte d'autres lignes, L-201 et L-202, dont la première est désormais à 44 euros : son montant vaut 192 euros.

Par exemple, le contrôle d'une commande créée depuis D-101 doit retrouver un écart de 12 euros et surtout expliquer sa cause : le mauvais ensemble de lignes a été choisi. Ramener seulement le total à 180 euros ne répare pas la commande. Il faut repartir de Q-501 et reconstruire les postes à partir de ses occurrences.

Revoir les règles de prix avec l'ERP

L'ERP peut appliquer une politique tarifaire différente de celle du document transmis. Le projet doit donc vérifier s'il reprend un prix convenu, recalcule le tarif ou impose une revue. Cette capacité dépend de l'interface et du paramétrage accessibles ; elle ne peut pas être déduite de la présence d'un champ prix dans HubSpot.

Si l'ERP renvoie un montant différent, la commande conserve un état « écart à examiner » jusqu'à résolution. L'équipe recherche alors le tarif, l'unité, les remises et les arrondis appliqués. Le responsable ADV tranche selon les règles de l'entreprise, sans modifier silencieusement le document commercial pour le faire ressembler au résultat aval.

Exercice de décision : huit transferts proposés à l'ADV

Les huit situations suivantes ont été exécutées hors connexion sur un modèle de données normalisées. Elles testent notre politique de sélection et un registre de réception fictif, sans appel HubSpot, sans commande ERP réelle et sans certification d'une acceptation juridique. Les identifiants permettent de suivre les différences ; ils ne proviennent pas d'un compte client.

Les scénarios B et C retiennent le transfert avant tout effet

Dans B, l'état commercial de D-101 n'apporte pas la preuve exigée pour Q-501. Dans C, deux candidats sans sélection explicite empêchent la préparation. Le registre garde le motif et la personne attendue pour décider, plutôt qu'un message « erreur de synchronisation » qui renverrait toutes les situations au développeur.

L'ADV peut lever ces blocages en qualifiant l'engagement ou en désignant le document. Elle ne les lève pas en désactivant globalement le contrôle pour faire passer le lot. Le dossier ainsi corrigé reçoit une nouvelle décision identifiable et reste comparable à ce qui était disponible lors du premier refus.

• Document ambigu : le commercial désigne la proposition retenue et apporte la preuve attendue par l'ADV.
• Référence ERP manquante : le gestionnaire du catalogue qualifie la correspondance avant la préparation des postes.
• Résultat de création inconnu : l'ADV rapproche les effets disponibles avec le partenaire ERP avant toute nouvelle tentative.

Les scénarios F, G et H distinguent reprise et changement de vente

Dans F, notre simulation retrouve un reçu déjà enregistré et rattache la commande fictive sans nouvel effet de création. Dans G, les lignes ont changé sous une identité déjà traitée : la reprise doit s'arrêter pour revue. Dans H, un autre devis arrive après création ; il faut choisir entre modification de commande, remplacement ou nouveau dossier autorisé.

Cette décision dépend du processus ERP et de l'état d'exécution. Une commande déjà préparée ne se remplace pas comme un brouillon. Le modèle interdit de conclure qu'un nouveau devis annule automatiquement la commande précédente ; l'entreprise doit définir le traitement et les personnes habilitées à l'approuver.

Réponse ERP perdue : retrouver une création avant de la rejouer

Une coupure peut survenir après l'enregistrement de la commande dans l'ERP et avant la réception de sa réponse. Le middleware ne sait alors pas si l'écriture a produit un effet. Rejouer immédiatement transforme une incertitude de transport en risque de doublon commercial.

Conserver le contrat de sortie et son empreinte

Le contrat de sortie proposé conserve société cible, portail source, devis retenu, révision interne, lignes ordonnées et références de correspondance. Son empreinte permet de comparer le contenu préparé à celui associé à une tentative précédente. Les montants sensibles restent dans un stockage autorisé ; les journaux de diagnostic n'ont pas besoin de recopier toutes les données commerciales.

Le registre de transfert garde la tentative, le résultat connu et la référence ERP quand elle est disponible. Une clé identique avec un contenu différent appelle une revue, au lieu d'autoriser une seconde création sous le même nom. Le modèle couvre aussi deux sociétés ERP qui pourraient utiliser les mêmes numéros locaux. L'idempotence recherchée concerne l'effet de création ; le contrat de sortie et la journalisation des tentatives doivent permettre d'en vérifier le périmètre réel.

Vérifier la possibilité réelle d'une recherche aval

Notre cas F suppose un reçu local déjà retrouvé. Il ne démontre pas qu'un ERP sait rechercher une commande par référence externe ni qu'il empêche deux créations concurrentes. Ces capacités doivent être vérifiées avec son éditeur ou son intégrateur, sur l'interface retenue et avec les restrictions de droits applicables.

Si aucune preuve fiable ne permet de retrouver l'effet, la tentative passe en état « résultat inconnu » et l'ADV examine le dossier. Une recherche de rapprochement, une interface adaptée ou une procédure manuelle peut résoudre l'incertitude. Le délai de réponse souhaité ne justifie pas une garantie de création unique que les systèmes accessibles ne permettent pas d'établir.

Un timeout est donc enregistré comme une incertitude tant que la preuve aval manque. L'observabilité du transfert expose séparément tentative envoyée, reçu connu et décision de reprise. Le seuil de repli prévu dans le contrat suspend les nouvelles créations du dossier ; il ne supprime ni son historique ni la responsabilité de résolution attribuée à l'ADV.

Erreurs fréquentes : un total juste peut cacher des lignes fausses

Comparer seulement le montant et l'étape commerciale

Un premier signal faible apparaît lorsque plusieurs commandes ont le bon total mais moins de lignes que les devis. Il peut indiquer un regroupement par produit qui a effacé des occurrences. Le contrôle doit rapprocher les identités et les quantités, puis les montants ; le total seul n'établit pas la fidélité du transfert.

Un second signal apparaît lorsque l'ADV corrige systématiquement les prix des commandes quelques heures après leur création. La lecture tardive de l'opportunité mérite alors d'être examinée. Avant d'accuser un calcul d'arrondi, il faut reconstruire le devis retenu, ses associations et le moment où l'intégration a relevé les données.

Utiliser la dernière modification comme sélection du client

Un devis récemment modifié peut être une proposition préparatoire, une copie ou un remplacement encore non qualifié. La sélection commerciale nécessite une preuve liée au dossier, et non un tri technique par date. Une opportunité contenant plusieurs documents ne doit pas être rendue transmissible en supprimant simplement les candidats gênants.

L'autre erreur consiste à corriger une identité manquante avec une valeur par défaut partagée. Deux lignes distinctes deviennent alors indiscernables lors d'une reprise. Les contrôles du modèle refusent notamment les identifiants absents ou répétés, les quantités invalides, les prix non admissibles et une correspondance de catalogue inconnue.

Plan d'action : qualifier un parcours de devis avant l'automatisation

Le pilote commence sur une famille d'offres et une société ERP déterminées. Le commercial apporte les documents et leurs étapes ; l'ADV décrit les effets autorisés ; le responsable catalogue précise les correspondances. Dawap cadre l'échange, tandis que le partenaire ERP vérifie les écritures, les possibilités de recherche et les conséquences sur l'exécution.

Observer les décisions avant d'autoriser les créations

La première passe prépare des dossiers sans créer de commandes. Elle compare, sur des cas autorisés, les lignes que le connecteur aurait retenues à celles contrôlées par l'ADV. Les divergences sont classées : document ambigu, acceptation non qualifiée, produit inconnu, unité différente ou transformation de prix aval.

La bascule vers l'écriture exige que les cas acceptés et refusés correspondent à la politique convenue. Le pilote inclut les limites : document absent, contenu modifié pendant la lecture, dossier déjà transmis et résultat ERP inconnu. Si une ligne ne peut pas être qualifiée, le dossier entier reste retenu lorsque le contrat exige une commande complète.

Préparer la maintenance de l'interface utilisée

Le calendrier officiel de migration HubSpot annonce la fin du support des API v1 à v3 en septembre 2027 et un calendrier séparé pour v4. Une intégration neuve doit vérifier la documentation et la version appropriées à ses objets, plutôt que reprendre sans examen les chemins d'un ancien tutoriel.

Le contrat conserve donc l'interface choisie, la date de vérification, les droits nécessaires et les essais à refaire lors d'une migration. En exploitation, une suspension doit arrêter les nouvelles créations tout en laissant accessibles les reçus et les dossiers retenus. La reprise suit les effets connus ; elle ne relance pas indistinctement tous les devis du pilote.

Mesurer le coût caché des corrections de commande

Dans une estimation fictive, 24 dossiers demandent chacun onze minutes de vérification entre le devis, le CRM et la commande. La charge atteint 264 minutes, soit quatre heures et vingt-quatre minutes. Elle décrit un temps de contrôle supposé, sans prétendre mesurer une économie chez un client.

Une correction peut mobiliser plusieurs équipes lorsque la préparation a commencé. Pour estimer le coût complet, il faut distinguer recherche du document, correction tarifaire, intervention catalogue et remise en cohérence de l'exécution. Le nombre de messages techniques réussis ne permet pas de chiffrer ces reprises.

Le suivi du pilote mesure les dossiers transmis sans correction, ceux retenus pour décision et ceux dont le résultat aval reste inconnu. Le seuil d'arrêt est lié aux conséquences acceptées : une commande créée depuis le mauvais devis exige une investigation immédiate. Les objectifs de rapidité viennent ensuite, quand la sélection commerciale est suffisamment maîtrisée.

Guides complémentaires : client ERP, lecture HubSpot et rapprochement des montants

Le transfert des lignes dépend d'autres contrats qui méritent un examen séparé. Les ressources suivantes prolongent la qualification du client, la lecture du CRM et la vérification des montants, sans substituer une présentation générale à la sélection du devis accepté.

Qualifier le contact et le compte client avant la commande

Le devis correctement sélectionné ne résout pas l'identité du client ERP. La ressource sur les leads HubSpot et les clients ERP examine ce passage du prospect au compte connu dans le système de gestion. Cette correspondance reste un prérequis du dossier, distinct de l'identité des lignes commerciales.

Le responsable du compte client vérifie notamment la société de gestion et la référence cible autorisée. Une modification de la fiche prospect pendant la préparation du devis ne doit pas changer silencieusement le destinataire commercial d'une commande déjà qualifiée par l'ADV.

Préparer les lectures et les notifications du CRM

La présentation de l'intégration de l'API HubSpot couvre les objets et les échanges CRM dans un périmètre plus large. Une notification, par exemple un webhook lorsque cette interface est disponible pour le parcours retenu, peut signaler qu'un dossier mérite une nouvelle lecture ; elle doit encore conduire à la qualification du document attendu avant de déclencher une commande.

Le contrat de lecture précise également la pagination des associations : arrêter la collecte après une première réponse peut laisser des postes hors du dossier. Le connecteur prépare son payload normalisé seulement après avoir rapproché la liste complète attendue avec les lignes disponibles pour le document retenu.

Expliquer un écart avant de modifier les prix

La lecture des montants, devises et arrondis dans les échanges API apporte les contrôles de représentation et de rapprochement utiles au diagnostic financier. Elle complète la sélection des occurrences, particulièrement lorsque l'ERP recalcule certains postes à partir de son propre contrat tarifaire.

Le contrôle financier compare les composants accessibles du prix et conserve le motif de la différence. Une simple tolérance sur le total risquerait d'accepter une référence erronée compensée par un autre poste, alors que les opérations attendues restent différentes.

Qualifier aussi la relation qui apporte le compte candidat

Le document accepté et ses lignes ne suffisent pas si le lecteur CRM sélectionne une société d’après l’ordre de ses associations. Le compte candidat doit porter une origine vérifiable, avec le rôle reconnu et la correspondance de gestion utilisée. Le rôle primaire d’un contact reste distinct du destinataire qualifié pour une vente donnée.

La lecture des associations HubSpot avant le rattachement ERP sépare douze cas de sélection et de refus. Un changement de société observé après une première préparation y ouvre une revue, plutôt qu’une réattribution silencieuse de la commande déjà engagée.

Conclusion : transmettre la proposition retenue, puis suivre ses effets

Le devis choisi donne une origine aux lignes de la commande. Ses occurrences restent identifiables même si l'opportunité change ou si un même produit apparaît plusieurs fois. Cette filiation permet à l'ADV d'expliquer une différence sans reconstituer la vente à partir de captures dispersées.

L'acceptation qualifiée autorise le passage prévu par l'entreprise ; la réponse ERP confirme ensuite un effet différent. Entre les deux, une coupure exige une recherche ou une décision, plutôt qu'une création répétée. La politique de reprise doit rester compatible avec les capacités réellement accessibles du système de gestion.

Avant de généraliser le flux, un pilote doit montrer quel document est choisi, quelles lignes sont conservées et pourquoi certains dossiers attendent. Pour examiner votre parcours de vente, notre accompagnement d'intégration HubSpot reliée à l'ERP part des interfaces disponibles et des décisions que vos équipes doivent prendre.

Dawap construit les échanges et les applications qui rendent ces décisions consultables jusqu'à l'exécution. Notre expertise en intégration API sur mesure permet de cadrer le transfert des devis avec votre équipe ADV et votre partenaire ERP, puis de suivre les reçus, les écarts et les reprises en exploitation.