Pour créer dans Business Central les commandes reçues par email, on lit le message et ses pièces jointes, on en extrait le client, les lignes, les quantités et la date de livraison souhaitée, puis on crée une commande de vente par l'API de Business Central, en la laissant en attente de validation par l'ADV. Côté Business Central, l'écriture est bien documentée. Le point dur est ailleurs : savoir de quel client il s'agit et à quel article de votre catalogue correspond la référence que ce client a écrite.
Un mot sur le terme : une API est une porte d'entrée que le logiciel ouvre aux autres programmes pour lire ou écrire des données, sans passer par l'écran. Pour Business Central, Microsoft la documente en détail, ce qui rend le projet plus lisible que sur beaucoup d'ERP. Beaucoup de PME reçoivent pourtant leurs commandes en PDF, en Excel, en scan ou en texte libre, et les ressaisissent chaque matin.
Cet article décrit le flux que nous mettons en place, la table de correspondance des références, ce que l'API permet d'écrire, les contrôles avant création et les cas limites du quotidien. Pour situer ce type de chantier, voir notre page sur l'automatisation de processus métier.
Points clés à retenir
- Business Central expose une API v2.0 qui permet de créer une commande de vente et ses lignes ; la partie technique est documentée, le difficile est le rapprochement des clients et des références
- Le numéro de commande du client se range dans
externalDocumentNumber: c'est le meilleur repère pour détecter un doublon - Nous recommandons de créer la commande en attente de validation par l'ADV, et de ne jamais déclencher l'expédition ni la facturation depuis un traitement d'emails
- Client inconnu, référence incertaine, prix hors tarif et quantité inhabituelle sont mis en attente avec leur motif, jamais écrits à l'aveugle
- Le gain dépend du volume de commandes et de la propreté du catalogue : peu utile à deux ou trois commandes par jour, net à plusieurs dizaines
Le flux de bout en bout : de l'email à la commande dans Business Central
Le workflow reproduit ce que fait aujourd'hui la personne de l'ADV qui ouvre la boîte commandes, étape par étape. Chaque étape a une sortie claire, et la commande n'est créée qu'à la fin, une fois les contrôles passés.
Étape 1 : repérer les emails qui sont des commandes
Une boîte commerciale reçoit des commandes, des questions de délai, des relances et des réclamations. Le premier tri isole les messages qui contiennent réellement une commande, qu'elle soit en PDF, en tableur Excel, en scan ou écrite dans le corps du mail. Les messages ambigus restent dans la boîte pour un traitement humain.
Étape 2 : extraire les lignes, la date et l'adresse
Un modèle de langage lit le message et la pièce jointe, puis restitue des données structurées : numéro de commande du client, référence ou désignation de chaque ligne, quantité, unité, prix éventuel, date de livraison souhaitée, adresse de livraison si elle diffère de l'habituelle. Pour un scan, une reconnaissance de texte passe avant le modèle.
Étape 3 : identifier le client et les articles
Le workflow retrouve le client à partir de l'adresse de l'expéditeur et des noms cités, puis rapproche chaque ligne d'un article du catalogue. C'est cette étape, détaillée plus bas, qui décide de la fiabilité du reste.
À retenir
Si le client et les lignes sont rapprochés avec une confiance suffisante, la commande est prête. Elle n'est créée dans Business Central qu'après les contrôles décrits plus loin, et elle y arrive en attente de validation, pas expédiée.
Le même flux existe pour d'autres logiciels de gestion. Pour comparer les contraintes, voir nos articles sur les commandes email dans EBP, sur les commandes clients dans Sage 100 et sur l'automatisation des commandes email dans Odoo.
Références client et références internes : le point dur du projet
Un client commande rarement avec votre numéro d'article. Il utilise le code de son propre système d'achat, une désignation approximative ou « la même chose que le mois dernier ». C'est ce point, et non l'API, qui fait échouer les projets menés trop vite.
La table de correspondance par client
La base est une table qui associe, pour chaque client récurrent, ses codes et désignations à vos numéros d'article Business Central. On la remplit à partir de l'historique des commandes déjà saisies, puis à la main sur les produits les plus commandés. Elle se complète à chaque validation.
| Ce que le client écrit | Ce que nous cherchons | Cas fréquent | Traitement |
|---|---|---|---|
| Son propre code article | Votre numéro d'article Business Central | Client industriel avec un code par pièce | Table de correspondance par client, écriture directe si la ligne est connue |
| Une désignation libre | L'article dont le nom et la description sont les plus proches | « Le même carton que la dernière fois » | Rapprochement proposé avec un niveau de confiance, ligne à valider |
| Votre référence, avec une faute ou un ancien code | Le bon article, après normalisation | Référence d'un ancien catalogue | Correspondance enregistrée après la première validation |
| Une unité différente (carton, palette, pièce) | La même unité que sur l'article | Quantité en cartons alors que l'article se vend à l'unité | Conversion contrôlée, mise en attente si le conditionnement est ambigu |
Ce que l'IA apporte sur une référence jamais vue
Sur un nouveau client ou une référence inconnue, le modèle compare la désignation du client aux noms et descriptions de votre catalogue et propose un article avec un niveau de confiance. Tant qu'une personne n'a pas confirmé le rapprochement, la ligne reste marquée à vérifier. Une fois confirmé, il entre dans la table et ne sera plus à refaire.
Soyons clairs : le taux de rapprochement automatique ne sera pas bon le premier jour. Il monte avec le volume traité et avec la propreté du catalogue. Un catalogue plein de doublons ou de références quasi identiques produit beaucoup de lignes à valider, quel que soit le soin apporté au workflow. Notre article sur la correspondance des champs entre deux logiciels approfondit cette logique.
Écrire dans Business Central par l'API : ce que la documentation permet
Business Central propose une API v2.0 documentée par Microsoft. La ressource salesOrder accepte la création (POST), la lecture (GET), la modification (PATCH) et la suppression (DELETE). C'est l'un des ERP où l'écriture est la mieux décrite, ce qui permet de cadrer précisément ce que le workflow fera et ne fera pas.
La commande de vente et ses propriétés utiles
Pour ce cas d'usage, les propriétés qui comptent sont le client (customerNumber ou customerId), la date de commande (orderDate), la date de livraison souhaitée (requestedDeliveryDate), les adresses de livraison, de client et de facturation (shipTo*, sellTo*, billTo*) et partialShipping. La propriété externalDocumentNumber accueille le numéro de commande du client : c'est elle qui permet de repérer un doublon. Source : documentation Microsoft sur la ressource salesOrder.
Les lignes de commande
Les lignes se créent par un appel POST sur companies({id})/salesOrders({id})/salesOrderLines, avec notamment itemId, lineType, description, quantity et unitPrice. Une création réussie renvoie le code 201 (Created), et l'appel s'authentifie par un jeton Bearer. Source : documentation Microsoft sur la création d'une ligne de commande de vente.
Créer en attente de validation, jamais expédier
La propriété status de la commande peut valoir Draft, In Review ou Open. Le statut obtenu à la création dépend de la configuration de votre environnement et de vos circuits de validation, un point que nous vérifions avant de cadrer. Notre règle ne change pas : la commande arrive là où l'ADV peut la relire avant de la faire avancer.
La ressource expose aussi l'action shipAndInvoice, qui expédie et facture. Nous ne la déclenchons jamais depuis un traitement d'emails. Une expédition et une facture sont des engagements envers le client et le comptable, elles restent des décisions humaines.
| Élément | Ce que fait le workflow | Ce qu'il ne fait pas | Qui décide |
|---|---|---|---|
| Création de la commande | POST sur salesOrder, en attente de validation | Lancer l'expédition ou la facturation | L'ADV |
| Numéro de commande du client | Écrit dans externalDocumentNumber, sert à repérer un doublon | Écraser une commande existante | Le workflow signale, l'ADV tranche |
| Date de livraison | Reprend la date souhaitée par le client | La présenter comme une date promise | L'ADV, selon le stock et le planning |
| Fiche client | Utilise un client existant | Créer un client à la volée | Une personne habilitée |
Un point de cadrage à ne pas oublier : les API doivent être activées selon l'environnement, et la façon de s'authentifier varie selon que vous êtes sur Business Central en ligne ou sur site. Nous demandons un accès de test, un compte technique et ses droits avant de chiffrer quoi que ce soit.
Vous recevez des commandes par email et vous les ressaisissez dans Business Central ?
Nous regardons votre flux réel, vérifions l'accès API de votre environnement et cadrons le workflow adapté à vos clients et à votre catalogue.
Prendre un rendez-vousLes contrôles avant écriture : ce qui ne passe jamais sans validation
Un workflow qui crée tout sans filtre est un risque, pas un gain de temps. Quatre situations sont mises en attente avec leur motif, quelle que soit la façon dont la commande serait ensuite écrite.
- Client inconnu. Aucun client Business Central ne correspond à l'expéditeur ou au nom cité. Créer une fiche à la volée reviendrait à laisser n'importe quel expéditeur ouvrir un compte client.
- Référence non rapprochée avec certitude. L'article n'a pas de correspondance connue, ou plusieurs articles collent aussi bien à la désignation.
- Prix hors tarif. Le client mentionne un prix ou une remise qui ne correspond pas à ce que Business Central enregistre pour lui ou pour cet article.
- Quantité inhabituelle. Une quantité dix fois supérieure à l'historique du client, ou une unité confondue (cartons contre pièces).
Sur chacun de ces cas, la commande n'est pas bloquée : elle attend avec le motif exact, et la personne qui tranche corrige un point précis au lieu de tout reprendre. La question de l'endroit où placer ces points de contrôle est traitée dans notre article sur la validation humaine dans une automatisation.
Les cas limites du quotidien
Ce sont eux, plus que le flux principal, qui décident si le workflow est encore utilisé après un mois.
Commande en plusieurs mails, modification, annulation
Un client envoie parfois sa commande en deux ou trois messages, le complément arrivant quelques minutes après le premier. Le workflow regroupe les messages d'un même client sur une fenêtre de temps courte avant de créer la commande. Une modification ou une annulation reçue ensuite ne réécrit jamais une commande existante : elle est signalée à la personne responsable, qui l'applique elle-même.
Doublon : le rôle de externalDocumentNumber
Le client relance parfois son bon de commande, ou le transfère à deux adresses de votre entreprise. Avant toute création, le workflow cherche le numéro de commande du client dans externalDocumentNumber pour ce client. S'il existe, il ne crée rien et prévient l'ADV. Sans numéro de commande, le repère est plus fragile (mêmes lignes, même période), donc la commande part plus souvent en validation.
Pièce jointe illisible, ou commande dans le corps du mail
Une photo prise au téléphone, un scan de travers ou un tableur au gabarit inattendu réduisent la fiabilité de l'extraction. Mieux vaut laisser la commande à saisir à la main que d'écrire des données incertaines. À l'inverse, une commande écrite directement dans le mail est souvent plus simple à lire qu'un PDF scanné. Pour l'extraction elle-même, voir notre article sur l'extraction des bons de commande reçus par email.
Ce que ça change, selon votre volume
Les gains se mesurent sur deux axes : le temps de traitement d'une commande et le nombre d'erreurs découvertes trop tard, à la préparation ou à la facturation. Ils dépendent du volume et de la régularité des commandes.
- À deux ou trois commandes par jour, l'effort de mise en place n'est pas compensé par le temps gagné.
- À quelques dizaines par jour, avec des clients récurrents dont les références sont déjà dans la table, une commande standard passe d'une saisie de plusieurs minutes à une validation de quelques secondes.
- Les erreurs de recopie (référence confondue, quantité mal lue) diminuent, parce que le rapprochement s'appuie sur une correspondance vérifiée et non sur une lecture rapide.
- Les commandes mises en attente sont plus rapides à traiter qu'une saisie complète : la personne tranche un point précis.
Ces effets ne sont pas garantis. Ils dépendent de la propreté du catalogue, de la stabilité des clients et de la qualité des documents reçus. Nous connectons déjà des boîtes Outlook et Gmail à Odoo, Zoho ou NocoDB, et notre cas client Copro Assistance décrit des emails traités vers un CRM NocoDB ; sur Business Central, nous partons de la documentation Microsoft et de ce que nous vérifions pendant le cadrage, avec un déploiement progressif en parallèle de la saisie manuelle.
Vous voulez estimer ce que ce workflow changerait sur votre volume de commandes ?
Donnez-nous le nombre de commandes par jour, les formats reçus et votre type de déploiement Business Central : nous vous donnons une lecture concrète avant tout engagement.
Voir nos automatisations de processus métierQuestions fréquentes sur les commandes email vers Business Central
Pour aller plus loin
- Commandes email vers EBP avec l'IA : le même flux sur un logiciel de gestion où la voie d'écriture dépend de la version.
- Commandes clients dans Sage 100 avec l'IA : le même principe d'extraction, appliqué à un autre ERP.
- Automatiser les commandes email dans Odoo avec l'IA : un ERP dont l'API est ouverte sur toutes les versions.
- Commandes email vers Divalto avec l'IA : le même problème côté ERP pour l'industrie et la distribution.
- Commandes reçues dans Outlook vers un ERP : le côté boîte mail du flux, quel que soit l'ERP.
- Où placer la validation humaine dans une automatisation : la méthode pour décider quels contrôles garder avant écriture.
- Connecteur standard ou développement sur mesure : comment choisir selon la variété de vos formats de commande.
- Microsoft Learn : ressource salesOrder de l'API Business Central v2.0 : la référence officielle des propriétés et des actions.
Formation
Pour que vos équipes appliquent ces usages sur leurs propres documents, voir notre formation n8n, construite sur vos cas.
