Automatiser l'entrée des commandes email dans Divalto consiste à extraire le client et les lignes de commande depuis le mail ou sa pièce jointe, à les rapprocher des fiches clients et des articles Divalto, puis à créer la pièce de vente par la voie que votre installation autorise. La création elle-même n'est pas un simple appel standard : sur Divalto Infinity, elle passe par un web service paramétré avec votre intégrateur ou l'éditeur.
Dans une PME de négoce, de distribution ou d'industrie, les commandes arrivent encore en PDF, en Excel, en scan ou en texte libre, et le service ADV les ressaisit une à une. Ce n'est pas un défaut de Divalto, c'est un flux d'entrée que l'ERP n'a jamais été conçu pour lire. Les deux points durs sont la table de correspondance entre références client et références internes, et la voie d'écriture réellement disponible chez vous.
Cet article décrit le flux que nous mettons en place, ce que la documentation publique de Divalto permet et ne permet pas d'affirmer, et les contrôles à garder avant toute écriture. Pour situer ce type de chantier, notre page sur l'automatisation de processus métier présente les cas que nous traitons.
Points clés à retenir
- Divalto Infinity expose des services web REST, une API RecordSQL et des webhooks, mais la documentation publique ne décrit pas de web service standard de création de pièce de vente : la création d'une commande passe par un web service paramétré avec l'intégrateur ou l'éditeur
- Un accès en lecture ne prouve pas qu'une création est possible : il faut tester l'écriture sur un environnement de recette avant de cadrer
- Le point dur numéro un reste le rapprochement entre la référence du client et le code article Divalto ; sans table de correspondance fiable, le taux d'erreur reste élevé
- Un client inconnu, une référence incertaine, un prix hors tarif ou une quantité inhabituelle ne s'écrivent jamais dans Divalto sans validation humaine
- Le gain est conditionné au volume : peu de commandes par jour ne justifient pas le chantier, plusieurs dizaines par jour avec des clients récurrents oui
Le flux de bout en bout : de l'email de commande à la pièce dans Divalto
Le workflow doit reproduire ce que fait aujourd'hui la personne qui traite la boîte commandes, étape par étape. Rien n'est écrit dans Divalto avant la dernière étape, et seulement si les contrôles sont passés.
Étape 1 : trier les emails qui sont vraiment des commandes
Une boîte ADV reçoit des commandes, mais aussi des relances, des demandes de prix, des réclamations et des accusés de réception. Le workflow qualifie chaque mail entrant et ne garde dans le flux automatique que ceux qui contiennent une commande, dans le corps du message, en PDF ou en tableau Excel. Les cas ambigus restent dans la boîte pour un traitement classique.
Étape 2 : extraire les lignes de commande
Un modèle de langage lit le mail et ses pièces jointes, avec une reconnaissance de texte quand le document est un scan. Il en tire des données structurées : référence ou désignation du client, quantité, unité, prix ou remise annoncés, date de livraison souhaitée, adresse de livraison si elle diffère de l'adresse habituelle, numéro de commande du client. Le résultat est un objet structuré que les étapes suivantes savent exploiter, pas un texte à relire.
Étape 3 : rapprocher le client, les articles et les conditions
Le workflow identifie le client à partir de l'adresse d'expédition du mail et du nom indiqué, puis cherche sa fiche dans Divalto. Chaque ligne est ensuite rapprochée d'un article. C'est l'étape qui détermine la fiabilité de tout le reste, détaillée dans la section suivante.
À retenir
Un client identifié et des lignes rapprochées ne suffisent pas à écrire. Les quatre contrôles décrits plus bas passent d'abord, et c'est seulement après qu'on choisit la voie d'écriture.
Le même flux existe pour d'autres logiciels : nos articles sur les commandes email vers EBP, sur les commandes clients dans Sage 100 et sur l'automatisation des commandes email vers Odoo montrent la même mécanique avec d'autres contraintes techniques.
Le point dur numéro un : les références du client ne sont pas vos codes Divalto
Un client commande rarement avec votre code article Divalto. Il utilise la référence de son propre système d'achat, la vôtre telle qu'elle figurait sur un ancien catalogue, ou une désignation libre du type « même modèle que le mois dernier ». C'est la première cause d'échec des projets menés trop vite.
La table de correspondance
La solution durable est une table qui associe, pour chaque client récurrent, ses références ou ses désignations aux codes articles Divalto. Elle se construit en partie depuis l'historique des commandes déjà saisies, en partie à la main au démarrage, client par client, sur les produits qu'il commande le plus.
| Ce que le client écrit | Ce que Divalto attend | Comment on rapproche |
|---|---|---|
| Sa propre référence d'achat | Le code article interne | Table de correspondance par client, alimentée par l'historique |
| Votre ancienne référence | Le code article actuel | Table des anciens codes ou des articles remplacés |
| Une désignation libre | Un article et son conditionnement | Proposition de l'IA avec niveau de confiance, validation humaine la première fois |
| Une unité différente (carton, palette, pièce) | L'unité de vente de l'article | Règle de conversion par article, signalée si le calcul est ambigu |
Quand la correspondance n'existe pas encore
Sur un nouveau client ou une référence jamais vue, l'IA compare la désignation du client aux libellés et descriptions des articles Divalto, et propose un rapprochement avec un niveau de confiance. Un rapprochement de confiance élevée peut être accepté sans relecture une fois la fiabilité démontrée sur plusieurs semaines. Un rapprochement incertain reste à vérifier, jamais écrit à l'aveugle.
Chaque validation manuelle enrichit la table. Le taux de rapprochement automatique progresse avec le volume traité, pas dès le premier jour.
Les voies d'écriture dans Divalto : ce que la documentation permet d'affirmer
Divalto présente Infinity comme un ERP ouvert, interopérable via des connecteurs et des web services. Sur la plateforme cloud, la documentation officielle décrit des services web en architecture REST, avec une authentification par jeton, une API RecordSQL et des webhooks. Le protocole SOAP n'est plus supporté par la plateforme depuis septembre 2024.
Ce que la documentation publique décrit, et ce qu'elle ne décrit pas
L'appel d'un web service DIVA se fait par un POST JSON sur l'adresse WebService/Execute, avec un paramètre « action » qui correspond à un code d'action défini dans l'administration cloud. Autrement dit, ce que l'on peut appeler est ce que votre installation a paramétré. La documentation publique ne décrit pas de web service standard de création de pièce de vente : la création d'une commande passe donc par un web service paramétré côté Divalto, avec votre intégrateur ou l'éditeur.
Lecture n'est pas écriture
Réussir à lire des fiches clients, des articles ou des tarifs ne prouve pas qu'une création de commande est possible. Ce sont des actions et des droits distincts. Avant de cadrer, nous testons une écriture réelle sur un environnement de recette, pas seulement une connexion.
Une installation sur serveur local (on premise) ne relève pas de cette documentation cloud. Ce qui est possible chez vous se vérifie avec votre intégrateur, version et paramétrage en main.
Trois voies selon ce que votre installation autorise
- Web service paramétré. L'intégrateur ou l'éditeur définit une action de création de commande, et le workflow l'appelle après authentification. C'est la voie la plus directe, avec un travail de paramétrage côté Divalto à prévoir.
- Import de fichier. Quand votre installation sait importer un fichier de commandes, selon son paramétrage, le workflow dépose un fichier au format attendu. Le format exact et la fréquence de relecture se définissent avec l'intégrateur.
- Fichier déposé pour validation. Le workflow prépare la commande et un opérateur la reprend dans Divalto après relecture. Aucune ouverture technique n'est requise, c'est la voie la plus prudente pour démarrer.
| Voie d'écriture | Condition | Délai | Contrôle humain |
|---|---|---|---|
| Web service paramétré | Action de création définie dans l'administration cloud avec l'intégrateur ou l'éditeur | Quasi immédiat | Avant écriture, sur les lignes à confiance faible |
| Import de fichier | Import autorisé et paramétré sur votre installation | Selon la fréquence de relecture | Avant dépôt du fichier |
| Fichier déposé pour validation | Aucune, hors accès à la boîte mail | Selon le rythme de l'opérateur | Systématique, à chaque commande |
Si aucune de ces voies n'est ouverte et que l'ERP n'offre aucune interface exploitable, la question change de nature : notre article sur l'automatisation d'un logiciel métier sans API détaille les solutions de contournement.
Côté méthode, nous connectons déjà des boîtes Outlook et Gmail à Odoo, Zoho ou NocoDB. Le cas client copro-assistance et l'automatisation des emails vers un CRM NocoDB montre ce que donne le flux quand les emails de commande alimentent un outil de gestion. Divalto demande en plus de passer par le paramétrage de votre installation.
Vous recevez des commandes par email et vous les ressaisissez dans Divalto ?
Nous auditons votre flux de commandes, testons ce que votre installation Divalto autorise en écriture avec votre intégrateur, puis cadrons le workflow adapté à votre catalogue et à vos clients.
Prendre un rendez-vousLes contrôles avant écriture : ce qui ne passe jamais sans validation
Un workflow qui écrit tout dans Divalto sans filtre est un risque, pas un gain de temps. Quatre situations vont systématiquement en attente de validation humaine, quelle que soit la voie d'écriture.
- Client inconnu. Aucune fiche ne correspond à l'adresse email ou au nom détecté. Créer une fiche à la volée reviendrait à laisser n'importe quel expéditeur ouvrir un compte client.
- Référence incertaine. Le produit demandé n'a pas de correspondance fiable, ou plusieurs articles correspondent aussi bien à la désignation.
- Prix hors tarif. Le client annonce une remise ou un prix négocié qui ne correspond pas à ce que Divalto contient pour ce client ou cet article.
- Quantité inhabituelle. Une commande dix fois supérieure à l'historique du client, un zéro de trop, une unité confondue entre pièce et carton.
Dans chacun de ces cas, la commande n'est pas bloquée : elle attend avec le motif précis du signalement, et la personne de l'ADV tranche en quelques secondes plutôt que de tout ressaisir. La méthode complète pour placer ces points de contrôle est détaillée dans notre article sur où placer la validation humaine dans une automatisation.
Les cas limites du quotidien ADV
Ce sont ces cas, plus que le flux nominal, qui décident si l'automatisation tient dans la durée.
Commande en plusieurs emails, modification, annulation
Un client envoie parfois sa commande en deux ou trois mails à quelques minutes d'intervalle. Le workflow les regroupe sur une fenêtre courte avant de créer la pièce. Une modification ou une annulation reçue après création n'écrase jamais une pièce existante : elle est signalée au responsable du dossier, qui l'applique lui-même dans Divalto.
Document illisible ou commande dans le corps du mail
Un scan de mauvaise qualité, une photo prise au téléphone ou un Excel à la mise en page inattendue baissent la fiabilité de l'extraction. Dans ce cas, mieux vaut laisser le document en saisie manuelle que d'écrire des données incertaines dans l'ERP. À l'inverse, une commande écrite dans le corps du mail est un cas simple à traiter, souvent plus que le PDF scanné.
Commandes cadres, livraisons multiples, remises par client
Dans le négoce et l'industrie, une commande peut renvoyer à un contrat cadre, être livrée en plusieurs fois à plusieurs adresses ou porter des remises spécifiques au client. Ces règles se listent au cadrage, client par client. Tant qu'une règle n'est pas formalisée, la commande concernée part en validation humaine au lieu d'être traitée par approximation.
Ce que ça change concrètement, à condition d'être honnête sur les volumes
Le gain se mesure sur le délai de traitement d'une commande et sur les erreurs de saisie corrigées après coup, parfois découvertes seulement à la livraison ou à la facturation.
Il dépend directement du volume et de la régularité des commandes. Sur deux ou trois commandes par jour, l'effort de mise en place, qui inclut ici le paramétrage d'une écriture côté Divalto, n'est pas compensé. À partir de plusieurs dizaines de commandes par jour avec des clients récurrents, le gain est net :
- Une commande standard, déjà couverte par la table de correspondance, passe d'une saisie de plusieurs minutes à une validation de quelques secondes.
- Les erreurs de recopie (référence confondue, quantité mal lue, unité inversée) diminuent, parce que le rapprochement repose sur une correspondance vérifiée et non sur une lecture rapide.
- Les commandes signalées se traitent plus vite qu'une saisie complète, car l'ADV n'a plus qu'un point précis à trancher.
Ces effets ne sont pas garantis. Ils dépendent de la propreté du fichier articles Divalto, de la stabilité des clients récurrents et de la qualité des documents reçus. Un fichier articles avec des doublons ou des codes incohérents produira beaucoup de signalements, ce qui vaut la peine d'être audité avant de chiffrer.
Vous voulez savoir ce que ce flux changerait sur votre volume de commandes ?
Indiquez-nous le nombre de commandes par jour, les formats reçus et votre mode d'hébergement Divalto (cloud ou serveur local). Nous vous donnons une lecture concrète avant tout engagement.
Voir nos automatisations de processus métierQuestions fréquentes sur les commandes email vers Divalto
Pour aller plus loin
- Faire entrer les commandes reçues par email dans EBP : le même flux sur un ERP dont la voie d'import est un fichier paramétrable.
- Commandes clients dans Sage 100 avec l'IA : le même principe appliqué à un autre ERP de PME et d'ETI.
- Commandes email vers Business Central : la variante pour un ERP dont l'API est documentée.
- Commandes reçues dans Outlook vers l'ERP : le détail de la partie messagerie, indépendamment de l'ERP de destination.
- Automatiser les commandes email dans Odoo avec l'IA : le même flux sur un ERP à l'API ouverte.
- Automatiser l'extraction des bons de commande reçus par email : l'étape d'extraction en détail.
- Faire correspondre les champs entre deux logiciels avec l'IA : la logique de rapprochement des références.
- Connecteur standard ou développement sur mesure : comment choisir selon votre installation Divalto.
- Où placer la validation humaine dans une automatisation : la méthode pour calibrer les contrôles avant écriture.
- Documentation Divalto : services web de la plateforme cloud : la source officielle pour l'authentification et l'appel des web services.
- Divalto : technologies et ouverture de la plateforme : la présentation officielle de l'interopérabilité d'Infinity.
Formation
Pour que vos équipes appliquent ces usages sur leurs propres documents, voir notre formation n8n, construite sur vos cas.
