Démarrage D365FO : Problèmes rencontrés après intégration des données et retour d’expérience

Posted by
English version available here

Je suis fier de faire partie d’une équipe qui a réalisé un démarrage de l’ERP en mode « fast and furious » – 4 mois environ – en janvier 2018 sur la dernière version de D365FO.

Les facteurs de la réussite d’un tel projet sont les suivants :

  • Une équipe de consultants soudée
  • Une équipe client impliquée
  • Pas développement ou très peu
  • Moins de 30 utilisateurs
  • Périmètre défini à l’avance et bridé

Ce fût mon premier démarrage en D365FO, dans sa version cloud, avec certains avantages par rapport aux anciennes versions (si l’on oublie son chargeur de portable chez le client, on peut quand même travailler pour lui sur son PC personnel), et des inconvénients également (les techniciens vous diront qu’ils se sentent orphelin de ne plus pouvoir ouvrir le moindre AOT en production, ce qui nous aurait été utile pour corriger certaines coquilles à l’intégration). Pour rappel, toute la plateforme de production est gérée et contrôlée par Microsoft.

Même si l’histoire se termine bien (comme toujours et pour chaque démarrage, en toute modestie bien sûr), nous avons rencontrés de sérieux problèmes d’intégration de données. Quel dommage qu’il eut fallut les découvrir en production, après avoir importé les articles et validé le premier inventaire. Dès qu’on a des transactions, il est difficile de revenir sur le setup.

Voici néanmoins quelques astuces utiles.

Articles avec le mauvais paramétrage de dimension stockage ou suivi

Lorsqu’on importe des articles dans D365FO, on utilise généralement le framework Data Management qui, faut-il le souligner, a été largement amélioré depuis Ax 2012 R2.

Lorsqu’un produit est créé et lancé

Pour les articles, on peut avoir jusqu’à 10 fichiers voir même plus pour les importer (les produits, les variantes, les produits lancés, les nomenclatures, les gammes, les paramètres de commande par défaut, etc). Prenons le cas d’un produit importé, sur lequel on a paramétré via l’import les dimensions stockage et suivi.

Puis le produit est lancé, avec la bonne entity de Data Management. Le paramétrage obligatoire est complété alors : groupe de modèle d’article, unités, groupe d’article, etc, ainsi que le paramétrage requis dans le contexte du client.

Puis, l’inventaire est validé, la table Inventrans est alors impactée.

C’est alors que la lumière s’allume, et que quelqu’un remarque que l’article aurait dû être suivi avec des numéros de lot, au lieu de « None ».

La première chose à faire est d’inverser le comptage. Puis, c’est là que ça se corse. Changer le paramétrage n’est pas chose aisé dès que des transactions sont entrées. Depuis le produit lancé, ce n’est pas possible, la zone est grisée.

Ce qu’il faut faire alors c’est retourner au niveau du produit, et supprimer la valeur affectée pour la dimension suivi.

Puis, de retour sur le produit lancé, il faut également supprimer la valeur de la dimension suivi.

Ensuite, retourner sur le produit et choisir la bonne valeur pour la dimension de suivi : batch dans ce cas. La valeur sera alors ajoutée automatiquement sur le produit.

Pas la peine d’essayer d’affecter la valeur de dimension suivi depuis le produit lancé directement, ça ne fonctionnera pas.

Puis, il est possible de créer le numéro de lot pour l’article.

Vous devriez être en mesure de valider l’inventaire sur le numéro de lot.

Dans certaines situations, ce n’est pas si facile, et le message suivant peut apparaitre : closing of non-financial transfers’ is set to yes. (mince, je n’ai pas gardé la traduction en français, Molière pardonne-moi).

Ceci est la faute d’une case à cocher dans le groupe de dimension suivi (ou stockage) : la case suivi financier est cochée.

Ce que vous pouvez faire pour contourner cet écueil est de créer un groupe de dimension suivi (ou stockage) avec la fameuse coche financière de décochée. Puis, répéter la précédente procédure en affectant ce nouveau groupe de dimension. Recommencer une nouvelle fois en choisissant cette fois la bonne valeur de dimension (celle avec la coche financière de cochée). Et là, ça passe. Magique.

Dans un contexte different dans lequel vous être en production depuis longtemps, vous pouvez rencontrer ce genre de message. Il faut alors bien penser à lancer une clôture des stocks avant.

Lorsqu’on créé directement des produits lancés

A présent, intéressons-nous au cas ou l’article a été créé directement en tant que produit lancé. Créer un produit lancé va automatiquement créer un produit. La seule différence reside dans le fait que les dimensions de stockage et suivi sont initialisées à blanc dans le produit.

Dans ce cas, la procédure à suivre est la suivante pour changer de dimension :

  • Supprimer la valeur depuis le produit lancé
  • Renseigner la bonne valeur depuis le produit : cela va propager la valeur au produit lancé.

Articles paramétrés avec le mauvais sous-type

Alors là, bonjour la galère. Si le produit a été créé en tant que Produit au lieu de Service, après un premier comptage il est – pour ce que j’en sais – impossible de modifier ce paramètre. Même s’il n’y a pas de transaction, ce n’est pas pas possible non plus de le modifier (mais alors on peut supprimer l’article et le recréer facilement).

Si la codification article est importante, entendre par là qu’il n’est pas envisageable d’avoir un code différent pour le « bon » article, il faut aller renommer l’article mal paramétré pour pouvoir l’importer à nouveau avec le bon nom et les bonnes valeurs.

Comment faire ? Pour le produit lancé, c’est assez simple, aller dans les Options, et choisir les informations sur l’enregistrement. On peut alors le renommer facilement.

Comme on peut le voir, le produit lancé est correctement renommé.

Ce n’est pas la même limonade pour le produit…. S’il l’on tente le même processus, on va être coincé pour une histoire de RecId qui nous empêche le renommage.

Mais par contre, voici une chose à savoir. Vous connaissez peut-être, puisque c’est juste sous nos yeux… Sur le produit, une fois ouvert en mode édition, le bandeau est modifié (va savoir pourquoi c’est caché là) et alors là on peut changer l’identifiant du produit.

Et voilà c’est fait.

Maintenant, l’identifiant du produit et du produit lancé ont été renommé, il est possible d’importer l’article à nouveau, bien comme il faut cette fois.

Et à l’avenir, penser à faire des tests sur l’environnement de test avant de découvrir des soucis en production après le démarrage. Mais c’est un autre débat.

Yohann ROLLAND

Merci à Anthony VACHON qui était en charge des reprises de données d’avoir découvert et résolu ce problème lors du démarrage.

One comment

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.