Dynamics AX rencontre le processus qui n’existe que sur le tableau

Un diagramme montre souvent commande → livraison → facture. Dynamics AX oblige à remplir ce qui existe entre les flèches : réservation partielle, article substitué, adresse incorrecte, retour sans facture et doublon venu d’une interface. Le design du processus devient le design des états et de leurs transitions.

Une commande possède des statuts commerciaux, physiques et financiers. Un article peut être commandé sans être réservé, prélevé sans être expédié, livré sans être facturé. Garder ces états distincts permet de représenter le terrain, mais une personnalisation qui les confond peut bloquer les annulations.

Tester l’exception, pas seulement le parcours idéal

Pour un retour client, je ferais exécuter :

1. retrouver la facture et la ligne d’origine;
2. créer une autorisation de retour;
3. recevoir l’article dans un emplacement de contrôle;
4. décider remise en stock, réparation ou rebut;
5. corriger la quantité physique;
6. produire l’avoir et les écritures financières;
7. rapprocher inventaire, client et grand livre.

Si l’article revient sans numéro de lot ou dans un autre entrepôt, la règle doit dire qui tranche. Une valeur par défaut silencieuse peut rendre le stock disponible au mauvais endroit. L’écran n’est que le point d’entrée; les tables, dimensions, transactions et traitements batch portent le résultat.

Le design doit aussi couvrir les interfaces. Un site Web peut renvoyer deux fois la même commande après un timeout. Un identifiant externe unique et une table de correspondance empêchent le doublon. Si le message est rejeté, une file d’exception garde le contenu, la cause et le propriétaire; le support ne modifie pas directement les tables.

Livrer code, configuration et données ensemble

Dans AX, le modèle X++ versionné ne capture pas toutes les séquences de numéros, workflows, rôles et paramètres. Une livraison possède donc un manifeste : objets, configuration, migration de données, traitements à suspendre, tests et retour arrière.

Un script de données doit être idempotent ou vérifier son prérequis. La transaction protège les écritures locales; elle ne rappelle pas un fichier bancaire déjà envoyé. Pour les frontières externes, la marche arrière peut être une opération compensatoire plutôt qu’un rollback technique.

La séparation des tâches fait partie des cas. La personne qui reçoit un retour ne devrait pas nécessairement créer l’avoir et approuver son paiement. Chaque nouvel écran ou service doit appliquer les privilèges existants et produire un audit.

Faire signer le résultat plutôt que le dessin

Après l’atelier, chaque responsable métier devrait valider une preuve issue d’AX : document, statut, quantité et voucher pour son scénario. Une capture d’écran du workflow ne prouve pas que l’inventaire et la comptabilité suivent. Je garderais un jeu de données de référence avec client, article, lot et comptes, puis automatiserais autant que possible les contrôles. Les résultats attendus changent seulement avec une décision versionnée. Lors d’une mise à jour, l’écart indique la règle exacte touchée. Cette méthode évite l’acceptation générale « le processus semble bon » et rend la responsabilité partagée entre ceux qui configurent et ceux qui portent l’opération.

Je construirais la définition terminée autour de quatre exemples : normal, partiel, doublon et annulation. Pour chacun, on compare documents AX, quantités physiques, quantités financières et écritures. Si le résultat tient, le design représente un processus; s’il ne couvre que la flèche heureuse, il représente encore un tableau.

Mise à jour de 2026

Dynamics AX appartient maintenant à une ancienne génération. Le soutien des éditions AX 2012 a pris fin en 2022 ou en 2023, et Microsoft oriente les clients vers les applications Dynamics 365 de finance et d’opérations. Les questions de processus restent valides, mais elles ne justifient pas le maintien d’une plateforme abandonnée. Microsoft publie les échéances de soutien et conseils de migration.