Posted by La mise en place de projets ERP implique souvent des contextes multi-sociétés. La question de la maintenance des référentiels articles, clients, fournisseurs ou même comptables revient souvent dans ces situations.
Si les référentiels sont totalement différents pour chacune des sociétés, il n’y a aucune question à se poser et chaque référentiel est à maintenir séparément.
Si quelques références sont partagées, on pourra les dupliquer manuellement le cas échéant pour gérer les exceptions.
Dans les cas où certains de ces référentiels sont communs à l’ensemble ou une partie des sociétés, deux possibilités s’offrent à nous : dupliquer les références dans chaque société ou … partager certaines tables.
Rappel sur la structure du modèle de données article, client et fournisseur
Une petite parenthèse est nécessaire pour décrire les données communes et spécifiques par société dans AX 2012 avant d’étudier les deux possibilités principales de maintenance des référentiels.
Clients et fournisseurs
Les clients et fournisseurs sont gérés de la même façon. Lorsqu’on crée une fiche client ou fournisseur dans une société AX, elle n’est visible que dans cette société. Néanmoins, la création d’une référence client/fournisseur va créer automatiquement une référence dans le carnet d’adresse global qu’on appelle IDParty. Le carnet d’adresse global portant bien son nom et étant commun à toutes les sociétés, on retrouve ces informations depuis celui-ci.
Dans le schéma ci-dessous, nous sommes connectés dans la société FRSI. On constate que l’ID 000005600 a été créé en tant que client dans la société USMF pour l’identifiant client CLIENT-USMF.
Dès lors, il est possible de « lancer » le client pour cette société, de façon manuelle.
A noter : toutes les informations saisies dans la société initiale ne sont pas dupliquées, car certaines sont propres à chaque société comme par exemple l’identifiant du client/fournisseur dans la société sœur qui sera conforme sa souche de numéro, tout comme le groupe de client/fournisseur.
Pour une fiche client/fournisseur, seules les données des volets Général, Adresses et Contacts sont dupliquées : toutes les autres données sont à reprendre pour la société dupliquée.
Articles
Concernant les articles, le modèle de données est complexe dans AX 2012. Ce qui suit suppose que la notion de produit / produits générique / produits lancés est maitrisée, sinon consulter Technet ici .
Les produits et produits génériques sont communs à toutes les sociétés, le référentiel est partagé. Seule une dizaine de champ de la fiche article sont disponibles pour les produits et produits génériques.
Les produits lancés sont propres à chaque société. L’essentiel du paramétrage se fait dans une table principale qui correspond (à peu près) à toutes les informations des onglets principaux.
Les informations situées sur le bandeau sont des tables liées à la table principale des articles. Ces tables sont propres à chaque société.
Partager les données
Dupliquer les références
Lorsqu’on souhaite avoir un référentiel commun, la solution la plus sécurisante qui ne touche pas au modèle de données est de dupliquer les données à l’identique dans chacune des sociétés.
Dupliquer manuellement
La duplication peut évidemment se faire manuellement. Pour un client/fournisseur, il faudra passer dans chacune des sociétés concernées et récupérer l’IDParty, puis venir recréer une occurrence de ce client/fournisseur et, bien sûr, compléter les informations qui n’ont pas été dupliquées.
Pour un article, il conviendra de le créer dans les produits ou produits génériques, puis de le lancer en choisissant les sociétés concernées. Enfin, il faudra finaliser le paramétrage de chaque article dans chaque société c’est-à-dire passer dans chacune d’entre elle et reproduire le paramétrage pour tous les champs, soit une bonne centaine, dépendant bien sûr du contexte. Bien lourd tout ça…
Dupliquer en masse
La duplication peut se faire en masse via l’outil d’import/export des données (DIXF) si votre version d’AX est en R3 ou R2 équipée de l’Add-on. DIXF, s’il est en premier lieu un outil de reprise de données, sert également d’outil d’interface ou de maintenance de référentiel. On peut lancer des traitements par lot sur chaque traitement DIXF pour une sélection de sociétés. Les entités articles, clients et fournisseurs existent en standard dans DIXF (il faut souvent les personnaliser en ajoutant quelques champs qui n’existent pas dans l’entité, mais on reste dans les fonctionnalités standard de l’outil).
L’avantage principal de la duplication est qu’on reste dans le standard AX. On a donc l’assurance de ne pas avoir de mauvaise surprise (on le verra plus tard pour l’autre solution) quant à l’utilisation de tous les champs du référentiel partagé. On peut également personnaliser au besoin par société et pour chaque champ de la fiche article/client ou fournisseur des valeurs potentiellement différentes.
Les inconvénients de la duplication sont les suivants :
- Duplication des références dans la base de données (mais avant de réussir à planter AX pour la volumétrie il faut y aller)
- Maintenance difficile qui se fait manuellement pour chacune des sociétés, soit via un template DIXF mais cette solution, si elle a le mérite de fonctionner, n’est pas ergonomique et surtout pas en temps réel.
D’autres solutions non standards et plus ou moins couteuses existent également lorsqu’on souhaite partager le référentiel :
- Développer un outil de réplication automatique dans toutes ou une sélection des sociétés en temps réel dès qu’une fiche d’un référentiel est mise à jour (on parle d’un développement, donc on peut imaginer des choses merveilleuses pourvu qu’on ait un budget illimité)
- Pour les articles, remonter les informations communes du produit lancé vers le produit/produit générique. Ainsi on conserve la logique AX de lancement des produits dans une sélection de société.
Utiliser une société virtuelle
L’autre solution consiste à partager le référentiel à toutes les sociétés (ou une sélection) via une ou des société(s) virtuelle(s).
Principe
Ce n’est pas une solution standard (d’ailleurs Microsoft ne la conseille pas) puisque des modifications doivent être effectuées depuis l’AOT pour partager les tables concernées à toutes les sociétés, mais l’impact technique est mineur et relativement simple.
Sans entrer dans trop de détails techniques, une société virtuelle va être créée et les sociétés concernées par le partage vont lui être rattachées. Ainsi, la création d’une occurrence du référentiel partagé sera visible dans les sociétés appartenant à la même société virtuelle. L’ajout d’une nouvelle société à la société virtuelle se fait facilement via du paramétrage dans le menu Administration système.
Facile non ?
Impacts fonctionnels
Ce choix est vraiment structurant pour la suite de votre projet et certains points doivent attirer votre attention avant de se lancer dans ce partage, car c’est fonctionnellement que ça peut devenir rapidement un calvaire.
Tout d’abord, le partage se fait par table, et aucunement par champ. Ainsi, le partage de la table principale des articles par exemple se fera pour tous les champs de cette table (vous avez reconnu InventTable ?). On ne peut pas gérer des exceptions sur certains champs.
Quelques exemples :
- Il est possible de paramétrer le fournisseur par défaut pour les articles : il sera commun à toutes les sociétés.
- Si on lance un calcul de classification ABC pour les articles vendus, le système viendra calculer une valeur pour la société courante, et l’affecter à l’article : cette valeur sera commune à toutes les sociétés, alors que la valeur est potentiellement différente.
Il faut donc s’assurer que tous les champs qui, au niveau métier, sont forcément différents par société, n’ont pas d’importance dans le contexte de votre secteur d’activité. Surtout, il faut bien intégrer que le partage va être réalisé pour une table et non pour un champ.
Inutile de préciser qu’une marche arrière est difficilement envisageable lorsque des transactions existent pour ces clients / fournisseurs ou articles.
Ensuite, il convient de délimiter précisément la frontière de partage et de boucler sur toutes les tables liées à la table partagée :
- La table principale des articles est rattachée à 56 tables différentes. Il faut donc étudier chacune d’entre elles et mesurer l’incidence d’avoir un tronc commun.
- On peut envisager de partager des tables liées, mais la problématique de frontière se retrouvera au niveau N+1. On pourra toujours gérer des exceptions de partage ou de réplication via des points de développement, mais la charge de travail peut être rapidement couteuse d’où l’intérêt de faire une analyse détaillée poussée.
- Attention également dans le cas de contextes multi-sociétés avec des flux inter-sociétés, il conviendra de jouer des scénarii de tests en amont sur des données partagées pour valider la solution définitivement.
En résumé, il faut être certain que tous les champs impactés sont bien destinés à être partagés et donc définir une frontière précise dans les données.
En particulier, dans un contexte multi-pays, il y a des différences de localisation (groupes de taxes, libellés, etc). La solution de partage de tables est déconseillée dans ces cas.
Conclusion
En conclusion, comme souvent avec AX, il est possible d’arriver à répondre à un besoin de plusieurs façons. Chacune ayant ses avantages et ses inconvénients, il convient d’étudier scrupuleusement ses impacts avant de retenir une solution.
Yohann ROLLAND