EDI et prise de commande dans Business Central : du programme client à la commande ferme

Aucune fonctionnalité standard documentée de Business Central ne transforme un message EDI client en commande vente. Quel que soit le transport, un portail consulté à la main, l’API ou un connecteur, la décision qui structure le projet vient avant : sur quel document atterrit chaque message. Un programme glissant va sur une commande cadre vente. Un appel de livraison ferme va sur une commande vente créée à partir d’elle. Si ce modèle est faux, la meilleure interface du monde ne fera qu’automatiser le désordre.

La question s’est posée lors du cadrage d’un industriel dont un gros client passe ses achats par un portail fournisseur. Ce client envoie une prévision, puis des commandes fermes, puis révise dates et quantités au fil de son propre plan. Le fournisseur doit confirmer chaque changement. Tout le monde pose des questions sur la connexion. C’est pourtant le modèle documentaire qui décide si l’ERP aura encore un sens dans six mois.

Que recouvre concrètement la prise de commande EDI pour un fournisseur ?

Plusieurs types de messages, pas un seul. Les portails fournisseurs utilisés dans l’automobile et d’autres chaînes d’approvisionnement industrielles transportent des commandes d’achat, des instructions de livraison (les appels), des prévisions de besoin, des confirmations de commande et des données d’expédition et de transport. SupplyOn, l’une de ces plateformes, cite tous ces échanges parmi ceux qu’elle prend en charge.

La même plateforme propose deux portes d’entrée, et elles pèsent sur le budget. Son option WebEDI, selon SupplyOn, demande « un PC, un navigateur et un accès Internet » : le fournisseur lit les messages de son client sous forme de formulaires web et peut les télécharger en CSV. L’EDI classique connecte directement le système du fournisseur, en OFTP2 ou en AS2.

« EDI » peut donc désigner une personne qui lit une page web et ressaisit la commande dans l’ERP, ou un flux de machine à machine. Les deux sont des options réelles. La première coûte du temps à chaque commande, la seconde coûte un projet, une fois.

Business Central sait-il recevoir des commandes EDI en standard ?

Pas pour les commandes clients entrantes. Microsoft documente ses fonctionnalités e-documents dans deux sens. Côté vente, elles envoient des documents, dont les factures, les commandes et les avoirs vente. Côté achat, elles reçoivent les factures et avoirs fournisseurs, qu’on peut rapprocher de commandes achat existantes. Aucun des scénarios documentés ne reçoit la commande d’un client pour en faire une commande vente.

L’automatisation de prise de commande de Microsoft, le Sales Order Agent, travaille sur une autre entrée : il surveille une boîte aux lettres Microsoft 365, lit les e-mails des clients et crée toujours un devis vente en première étape. Il consomme des crédits Copilot, facturés à l’entreprise. Il convient aux clients qui commandent par e-mail. Il n’est pas conçu pour un portail qui envoie des programmes structurés.

Reste l’API. L’API Business Central v2.0 expose salesOrders et salesOrderLines, qui acceptent toutes deux un POST pour créer des enregistrements : un middleware ou un connecteur peut donc écrire les commandes directement. L’authentification et les pièges de cette voie sont dans notre guide développeur de l’API Business Central. L’API dit comment écrire une commande vente. Elle ne dit pas si une commande vente est la bonne chose à écrire.

Sur quel document Business Central doit atterrir un programme client ?

La partie prévisionnelle d’un programme va sur une commande cadre vente. Microsoft la décrit comme le cadre d’un accord de long terme, typiquement une grande quantité livrée en petites expéditions dans le temps, chaque expédition faisant l’objet de sa propre ligne. La propriété clé est écrite noir sur blanc : les quantités d’une commande cadre n’affectent pas la disponibilité de l’article. C’est une feuille de suivi, de prévision et de planification, pas un engagement d’expédier.

La planification la voit quand même. Dans la logique de planification de Business Central, une commande cadre est une prévision propre à un client, qui s’ajoute à la prévision de la demande générale. Les commandes vente liées à une ligne de commande cadre consomment ce besoin anticipé, et cette consommation ne réduit pas la quantité de la commande cadre elle-même.

La partie ferme du programme devient une commande vente, créée depuis la commande cadre avec l’action Créer commande (Make Order). Quatre comportements documentés pèsent sur la conception :

• Avant Créer commande, on vide Qté à expédier sur chaque ligne qu’on ne veut pas encore expédier. La nouvelle commande contient malgré tout ces lignes, avec une quantité vide, et quelqu’un doit décider de les supprimer ou non.
• Une ligne de commande vente ne peut pas dépasser la quantité de sa ligne de commande cadre ; sinon, la commande ne peut pas être validée.
• Dès qu’une commande vente couvre toute la quantité d’une ligne cadre, plus aucune commande ne peut être créée depuis cette ligne. Pour ajouter de la quantité, on augmente la Quantité de la ligne cadre.
• La validation de la commande vente met à jour la Quantité expédiée et la Quantité facturée de la commande cadre, qui reste en place jusqu’à ce qu’on la supprime.

Une règle praticable en découle : tout ce qui est dans l’horizon ferme du client est une commande vente, tout ce qui est au-delà est une ligne de commande cadre. Le rôle de l’interface est de faire passer la quantité de l’une à l’autre à mesure que l’horizon avance.

Que se passe-t-il quand le client révise dates et quantités ?

C’est là que la conception se complique. Un programme reçu par portail n’est pas un document qu’on reçoit une fois. C’est un flux de révisions, et chacune peut déplacer une date, changer une quantité ou annuler une ligne.

Trois décisions doivent être écrites avant que quiconque construise le flux :

• Où atterrit une révision. Un changement au-delà de l’horizon ferme met à jour la ligne cadre. Un changement à l’intérieur touche une commande vente peut-être déjà lancée, préparée ou en fabrication. Ces deux cas demandent des règles différentes, et le second demande un humain.
• Comment on rapproche les messages. Le numéro de commande du client se garde dans le N° doc. externe, que Business Central reporte sur les documents validés et qui permet de rechercher. Les références pièces du client se relient aux vôtres par les Références article, pour que la ligne vente affiche sa référence et votre numéro d’article côte à côte.
• Ce qu’on confirme en retour. Le client attend des confirmations de dates et de quantités au fil du temps. Une date confirmée est une promesse, et elle doit passer les mêmes contrôles que n’importe quelle promesse. Nous décrivons comment la verrouiller dans un workflow d’approbation de la date de livraison en deux portes.

Quand personne ne tranche ces trois points, l’interface les tranche par défaut, en général en écrasant ce que contient l’ERP avec le dernier message reçu.

Quand un parcours devis puis commande est-il le meilleur modèle ?

Quand le client envoie une demande et non un programme. Pour des pièces chiffrées sur plan, le chemin est opportunité, devis, puis commande : Business Central crée un devis vente depuis une opportunité (pour un contact de type Société) et transforme un devis accepté en commande avec Créer commande. Les devis vente n’ont aucun effet sur la planification ni sur la disponibilité, et c’est pour cela que le Sales Order Agent s’en sert comme première étape sans risque.

Un fournisseur peut faire vivre les deux modèles en parallèle : l’un pour les pièces de série commandées sur programme, l’autre pour les pièces nouvelles commandées sur demande. L’erreur consiste à tout faire entrer dans un seul type de document parce qu’un client utilise un portail.

Faut-il construire une interface pour un seul client sur portail ?

Seulement après avoir confronté le standard au flux réel. Un ordre raisonnable pour le cadrage : vérifier d’abord que le processus tient dans le standard Business Central, puis identifier ce qui demande un développement spécifique, puis lister les interfaces, et les classer en critiques et non critiques. Une intégration de portail figure dans cette liste avec toutes les autres intégrations qui se disputent le même budget, et elle doit justifier sa place comme elles.

La première question porte sur le nombre de clients qui commandent réellement par ce canal, et sur la fréquence à laquelle un programme change. Si un client envoie quelques révisions par semaine, une session navigateur et une gestion rigoureuse des commandes cadre peuvent suffire la première année. Si plusieurs clients envoient des programmes quotidiens, la ressaisie devient une source d’erreurs de tous les jours, et un connecteur qui écrit par l’API est un chantier de développement Business Central limité et bien borné.

Dans les deux cas, le modèle documentaire décrit plus haut passe en premier. Une interface construite avant lui ne fait que figer la mauvaise réponse dans le code.

L’approche Asio Services

Commencez un projet de prise de commande sur papier, pas dans le paramétrage du portail. Écrivez une page : quels messages le client envoie, quel document Business Central devient chacun d’eux, où se situe l’horizon ferme, ce qu’une révision a le droit de modifier sans intervention humaine, et qui confirme les dates en retour. Si cette page ne peut pas s’écrire, aucun connecteur ne réglera le problème.

Si vos clients envoient déjà des programmes que vous ressaisissez à la main, ou si vous êtes sur le point de lancer un projet EDI, le formulaire Clarté est l’endroit où nous regardons le flux avant que quiconque choisisse un outil.

FAQ

Business Central peut-il importer des commandes vente EDI sans extension ?

Pas via une fonctionnalité standard documentée. Les e-documents de Business Central envoient des documents de vente et reçoivent des factures fournisseurs, et le Sales Order Agent lit des e-mails. Les commandes clients structurées arrivent par le point de terminaison salesOrders de l’API v2.0, par un connecteur ou par une extension.

À quoi sert une commande cadre vente dans Business Central ?

Elle enregistre un accord de long terme livré en plusieurs expéditions, à raison d’une ligne par expédition. Ses quantités n’affectent pas la disponibilité de l’article, mais la planification la traite comme une prévision propre au client. Les commandes fermes en sont tirées avec l’action Créer commande.

Comment conserver le numéro de commande et les références pièces du client ?

Le numéro de commande du client se saisit dans le champ N° doc. externe de l’en-tête vente ; il est reporté sur les documents validés et permet la recherche. Les références pièces du client se relient à vos articles par les Références article.

Le WebEDI suffit-il à la place d’une vraie intégration EDI ?

Il peut suffire quand peu de clients utilisent un portail et que les programmes changent rarement. Le WebEDI ne demande qu’un navigateur et les messages se téléchargent en CSV, mais chaque commande reste traitée par une personne. À mesure que le volume et la fréquence des révisions augmentent, l’intérêt d’un connecteur fondé sur l’API se renforce.