Valider une date de livraison dans Business Central : deux portes avant de promettre

Dans l’industrie à la commande, la date de livraison est la seule promesse que personne ne valide formellement. Business Central sait en faire une approbation, mais pas avec sa logique par défaut : les approbations standard s’organisent autour de qui demande et du montant du document, alors qu’une date exige deux vérifications dans un ordre imposé. D’abord, sait-on fabriquer la pièce ? Ensuite, a-t-on la matière et les heures machine ? Ce n’est qu’après ces deux réponses qu’une date doit repartir chez le client.

Le besoin est sorti d’une visite de cadrage chez un industriel à la commande. Le client envoie ses plans, une quantité et une date souhaitée. Quand rien de technique n’est en jeu, la date peut être confirmée directement. Sinon, le bureau d’étude valide en premier, puis l’approvisionnement et le temps machine. Et une phrase de cette visite porte toute la conception : l’industriel voulait que la première validation soit automatique, sauf aléa.

Pourquoi une date de livraison aurait-elle besoin d’une approbation ?

Parce qu’à la commande, la date est presque toujours fixée avant que quiconque l’ait vérifiée. Le commerce saisit une date pour rassurer le client. Le bureau d’étude découvre une semaine plus tard que la pièce demande une nouvelle gamme. La planification découvre ensuite que la machine est prise. Entre-temps, le client a une date écrite noir sur blanc.

Business Central sépare déjà les deux notions dont vous avez besoin. La ligne de vente porte une date de livraison demandée, celle que le client a réclamée, et une date de livraison confirmée, celle sur laquelle vous vous engagez. Ce ne sont pas deux informations de même nature : la demande est une donnée qu’on enregistre, la promesse est une décision que quelqu’un prend. Le workflow d’approbation, c’est précisément ce qui s’intercale entre les deux.

Quand la date confirmée est saisie dans la même minute que la date demandée, la distinction s’effondre, et avec elle toute discussion ultérieure sur qui a promis quoi.

Qu’est-ce que Business Central propose déjà pour les dates de livraison ?

La promesse de livraison (order promising). Elle est utile, mais elle répond à une autre question. Depuis une commande vente, la page des lignes de promesse propose deux calculs. L’Available to Promise regarde les quantités non réservées en stock et sur les réceptions prévues. Le Capable to Promise simule un scénario pour la quantité manquante, et calcule la date au plus tôt à laquelle l’article pourrait être disponible s’il est fabriqué, acheté ou transféré.

Trois détails comptent en pratique :

• Un article n’entre dans le calcul de promesse que s’il est marqué comme critique sur sa fiche.
• Accepter une date issue du Capable to Promise crée une ligne de planification et une écriture de réservation : ce n’est pas une simulation sans effet.
• La production elle-même (nomenclatures de production, gammes, centres de charge et postes de charge) exige l’expérience Premium.

Ce que la promesse de livraison ne fait pas, c’est demander l’avis de quelqu’un. Elle calcule à partir des disponibilités et des délais ; elle ne peut pas savoir que le bureau d’étude n’a pas encore ouvert le plan. Son résultat alimente donc la seconde porte, il ne tient pas lieu de promesse.

Que fait le workflow d’approbation standard, et où s’arrête-t-il ?

Business Central fournit des workflows d’approbation pour les documents de vente, et ils en font plus que ce que la plupart des équipes imaginent.

Sur la page des groupes d’utilisateurs de workflow, chaque membre reçoit un numéro de séquence, qui fixe l’ordre d’approbation. En approbation séquentielle, une demande que le premier approbateur ne valide pas n’arrive jamais au suivant. C’est exactement le comportement qu’exige une validation de date en deux temps. Les groupes d’utilisateurs de workflow ajoutent une règle à connaître : si plusieurs membres du groupe partagent le dernier numéro de séquence, tous doivent approuver. Placez ensemble l’approvisionnement et la planification sur ce dernier numéro, après le bureau d’étude, et la seconde porte exige les deux signatures : aucun des deux ne peut confirmer une date seul.

La réponse d’approbation porte aussi une formule de date d’échéance, le nombre de jours dont dispose l’approbateur, et une option de délégation automatique qui transmet la demande à un suppléant au bout d’un, deux ou cinq jours. Sur une date de livraison, ces deux réglages n’ont rien d’administratif : une demande qui dort, c’est un client qui attend sa date.

Là où le standard s’arrête, c’est sur le déclencheur. La configuration des approbateurs raisonne en hiérarchie et en montant, avec une limite d’approbation vente par approbateur. Le montant est la mauvaise mesure pour une date. Une petite commande sur une pièce jamais fabriquée est justement celle qui a besoin du bureau d’étude, et une limite de montant la laisse passer sans un regard. La question posée est « sait-on la faire pour cette date », et le total de la commande n’en dit rien.

Pourquoi le bureau d’étude doit-il valider avant l’appro et la planification ?

Parce que la seconde réponse dépend de la première. L’approvisionnement ne peut vérifier la matière qu’une fois la matière connue, et la planification ne peut vérifier le temps machine qu’une fois la gamme connue. Les deux sortent de l’étude technique. Faire tourner le bureau d’étude en parallèle de la seconde porte, c’est demander à vos équipes les plus sollicitées de vérifier la capacité pour une pièce qui sera peut-être redessinée une heure plus tard.

L’ordre décide aussi de ce que signifie un refus. Si le bureau d’étude dit non, la demande s’arrête là et personne en aval n’y passe de temps. Si les deux portes tournent en même temps, le refus technique arrive après que la planification a déjà réservé la machine, et il faut défaire la réservation.

Ce n’est pas une règle de Business Central. C’est une décision d’ordonnancement à prendre avant de paramétrer quoi que ce soit, et c’est l’étape que la plupart des équipes sautent quand elles copient un modèle d’approbation d’achat en le renommant.

Comment rendre la première porte automatique sans la vider de son sens ?

En écrivant ce que « sauf aléa » veut dire, sous forme de données, avant que quiconque construise le workflow. Une porte automatique dont la réponse par défaut est oui est la seule que les gens ne contournent pas ; une porte qui bloque chaque commande est court-circuitée dès la deuxième semaine.

Voici le type de règles que nous proposerions pour décider qu’une commande se dispense de l’étude technique :

• L’article a déjà été fabriqué, et sa nomenclature de production comme sa gamme n’ont pas changé depuis.
• La quantité reste dans la fourchette déjà produite pour cet article.
• La date demandée laisse au moins le délai de l’article.

Chacune est un fait que le système connaît, pas une opinion. Ce qui échoue à une règle part au bureau d’étude ; tout le reste passe directement à la seconde porte.

Certaines de ces règles tiennent dans les conditions d’événement du workflow, qui filtrent sur des valeurs de champs. D’autres, comme « cet article a-t-il déjà été fabriqué », demandent une requête qu’une condition ne sait pas exprimer. Quand l’événement ou le contrôle nécessaire n’existe pas dans votre bibliothèque de workflow, il s’ajoute par extension : Microsoft documente l’abonnement à OnAddWorkflowEventsToLibrary et OnAddWorkflowResponsesToLibrary précisément pour cela. La même documentation porte un avertissement à respecter : lors d’une mise à jour, les bibliothèques d’événements, de réponses et de relations de tables du workflow sont supprimées puis recréées, et ce sont les enregistrements spécifiques ajoutés par ces points d’extension qui sont recréés.

Un piège se loge dans la configuration même des approbations. Quand un utilisateur est à la fois demandeur et approbateur dans un groupe d’utilisateurs de workflow, ses propres demandes sont toujours approuvées automatiquement. Si l’ingénieur qui crée une nouvelle pièce est aussi celui qui lance la demande de date, la porte technique s’ouvre sans que personne n’ait regardé. Tenez les demandeurs hors du groupe qui les approuve.

Paramétrage standard ou extension : que faut-il construire ?

Commencez par le standard. Un workflow d’approbation vente avec un seul groupe d’utilisateurs, le bureau d’étude en séquence 1, l’approvisionnement et la planification partageant la séquence 2, vous donne une vraie validation en deux portes sans une ligne de code. Faites-le tourner quelques mois et comptez une seule chose : combien de demandes le bureau d’étude a approuvées sans rien modifier. Ce chiffre vous dit si une règle automatique vaut la peine d’être développée. C’est le même raisonnement que pour les personnalisations Business Central qu’il vaut mieux ne jamais coder : un besoin ne justifie pas du code tant qu’on ne sait pas ce que coûte de le laisser en paramétrage.

Une extension trouve sa place dans deux situations. La première, quand la date doit être approuvée pour elle-même, indépendamment de la commande, par exemple quand la date d’une commande déjà lancée change. Business Central sait déjà retenir la nouvelle valeur d’un champ jusqu’à son approbation en conservant l’ancienne, comme il le fait pour la limite de crédit d’un client. L’appliquer à une date de livraison suppose que le bon événement existe pour cet enregistrement. La seconde, quand la règle automatique a besoin d’une donnée qu’une condition ne sait pas lire. Dans les deux cas, c’est un développement Business Central petit et bien délimité, pas une refonte du processus de vente.

L’approche Asio Services

Une date de livraison qui glisse sans cesse est rarement un problème de workflow. C’est d’ordinaire la partie visible d’un problème situé en amont : un bureau d’étude informé trop tard, des données de capacité auxquelles personne ne croit, une équipe commerciale récompensée pour dire oui. C’est dans l’analyse des causes racines d’un projet ERP qu’on sépare ce qui relève de l’outil de ce qui relève de l’organisation.

Avant de paramétrer la moindre approbation, nous écrivons trois choses sur une seule page : les portes et leur ordre, la règle qui permet à une commande d’éviter la première, et qui ne doit jamais approuver sa propre demande. Si cette page ne s’écrit pas, le workflow ne fera qu’automatiser la confusion. Pour vérifier si votre propre promesse de date tient la route, le formulaire Clarté est notre point de départ.

FAQ

Business Central peut-il approuver une date de livraison sans développement ?

Oui, avec un workflow d’approbation vente standard et un groupe d’utilisateurs dont les numéros de séquence placent le bureau d’étude en premier, l’approvisionnement et la planification en second. Ce que le standard ne fait pas seul, c’est approuver la date indépendamment de la commande, ou dispenser d’une porte selon une règle qu’une condition de champ ne sait pas exprimer.

Quelle différence entre date de livraison demandée et date confirmée ?

La date demandée est celle que le client a réclamée. La date confirmée est celle sur laquelle vous vous engagez. Les garder séparées, avec une approbation entre les deux, est ce qui permet de savoir plus tard qui a promis quoi.

Le Capable to Promise remplace-t-il l’approbation ?

Non. Le Capable to Promise calcule la date au plus tôt à partir des disponibilités et des délais, et l’accepter crée une ligne de planification et une écriture de réservation. Il ne sait pas si le bureau d’étude a validé la pièce : c’est une donnée d’entrée de l’approbation, pas un substitut.

Pourquoi la demande d’un utilisateur peut-elle passer l’étude technique automatiquement ?

Business Central approuve automatiquement les demandes d’un utilisateur qui est aussi approbateur dans le même groupe d’utilisateurs de workflow. Si la personne qui lance la demande siège dans le groupe du bureau d’étude, la porte technique s’ouvre sans revue : les demandeurs doivent rester hors du groupe qui les approuve.