Le mode « multi-entités »

Les entités sont organisées en niveaux hiérarchiques. Les liens hiérarchiques sont organisés du haut vers le bas, c'est-à-dire qu’une entité de niveau bas dépend d’une et une seule entité de niveau haut (lien mère/fille). Deux entités d’un même niveau ne sont pas reliées directement entre elles. Si un lien existe entre deux entités de même niveau, c’est par leur dépendance à une même entité de niveau supérieur. Dans notre exemple, les sociétés S1 et S2 sont reliées par le fait qu’elles dépendant toutes les deux du Groupe.

Cette organisation en niveau permet d’organiser les données. C’est à dire qu’il est possible de définir pour chaque groupe d’information de la base de données (articles, tiers, stocks, etc.) à quel niveau il est géré. Ainsi, cela permet de cloisonner ou partager les données.

Dans l’exemple ci-dessus :

La société S1 n’a accès qu’à sa propre base client. Elle ne voit pas les clients de S2 et S3. Toutes les entités voient les mêmes articles. Le site @1 vend les articles selon son propre tarif. Le site @2 et le service TEL ne peuvent pas voir le tarif de @1 mais disposent de leurs propres tarifs de vente.

Il faut noter que le fichier article étant partagé par toutes les entités, la fiche d’un article n’existe qu’en un seul exemplaire pour tout le groupe :

Quelle que soit l’entité sur laquelle est créé ou modifié un article, c’est dans la base article de niveau 1 qu’est effectuée la création ou la modification des informations.

• Toutes les entités disposent exactement des mêmes informations sur un même article.
• Si certaines informations doivent être distinctes pour des entités de niveau bas alors il convient de descendre le niveau de gestion de la base article. L’inconvénient de positionner une donnée de gestion au niveau bas est qu’il faut créer autant de fiches que d’entités qui vont devoir l’utiliser. Dans notre exemple : si un même client travaille avec les trois sociétés alors il convient de créer sa fiche en trois exemplaires : une dans chaque société juridique. Par ailleurs, par exemple, si cela permet de disposer de conditions de règlements distinctes par société juridique, cela contraint également à gérer l’encours par société juridique et non pas au niveau groupe.

Il faut noter qu’une entité mère n’a pas accès aux informations propres aux entités filles.

Les évènements de flux (devis, commande, livraison, réception, facture, etc.) sont systématiquement stockés sur l’entité de saisie. Cela signifie par exemple que si une commande client est saisie sur l’entité de @1 alors la livraison devra être créée sur l’entité @1.

Le modèle multi-entités permet également de définir la structure juridique du Groupe, c'est-à-dire définir comment les différentes comptabilités du Groupe sont alimentées. Pour cela, ACE se base sur les liens entre tiers (les tiers associés aux entités). Par exemple, il est possible de définir que toutes les factures clients établies sur @1 sont déversées sur la comptabilité de S1. Il serait tout autant possible de définir que le Groupe ne gère qu’une seule comptabilité au niveau Groupe ou que chaque site de vente gère sa propre comptabilité.

Dans de nombreux écrans principaux, il vous est possible d’activer le pop-up Choix de l’entité de travail pour changer facilement d’entité sans avoir à vous reconnecter au niveau du menu principal. Une liste déroulante vous propose alors l’ensemble des entités pour lesquelles vous êtes habilité à travailler.

La gestion du mode multi-entités apporte de nombreuses fonctionnalités qui couvrent l'ensemble des modules d’ACE. Elle a des incidences sur la structure physique de la base de données.

Toutes les vues associées sont plus complexes en termes de tables utilisées. Il en résulte des conséquences sur les temps des traitements qui utilisent ces vues (majorité des éditions : uniquement pour l'ordre SELECT et certaines recherches). Les mesures effectuées montrent qu'en fonction des requêtes effectuées, on obtient des temps de réponses plus ou moins longs (lors d'accès effectués directement sous SQL ou par des outils de type info-centre). Il est très souvent possible d'optimiser une requête par la création ou la modification d'index mais aucune méthode n’est offerte pour optimiser toutes les requêtes.

Afin de ne pas pénaliser les clients qui n'utilisent pas le mode multi-entités, deux jeux de vues sont livrés. Si vous voulez utiliser ce mode, il faut effectuer les opérations suivantes avant de lancer la création de la base pour une première installation ou de lancer la mise à niveau pour une nouvelle installation : copiez les fichiers ora_genegos_vue_m.sql et ora_genephi_vue_m.sql du répertoire sql_o en ora_genegos_vue.sql etora_genephi_vue.sql.

Exemple sous UNIX :

• cp sql_o/ora_genegos_vue_m.sql sql_o/ora_genegos_vue.sql
• cp sql_o/ora_genephi_vue_m.sql sql_o/ora_genephi_vue.sql

Remarque : le mode de gestion multi-sociétés doit être positionné à OUI dans le fichier Generix.ini.

Dans un contexte multi-entités, s'il est effectivement possible d'avoir un client M. DUPOND référencé 0001 dans une entité A et un autre client M. DURAND référencé également 0001 mais dans une autre entité B, il faut savoir que cette utilisation de la même référence peut être source de confusion dans toutes les fonctions de consolidation.

Pour exemple, si l'utilisateur ne précise pas tous les critères de sélection, le chiffre d’affaires cumulé du client 0001 dans plusieurs entités risque de ne pas refléter la réalité. Il est donc judicieux d'utiliser une codification unique qui permette d'identifier un client ou un produit dans toutes les entités. Le système pourra gérer l'ambiguïté ; pas forcément l'utilisateur.

Entité : élément de la structure opérationnelle (agences, guichets, dépôts, etc.) ou juridique (société, groupe, filiale).

Propriétaire du stock : entité qui possède au sens juridique un article dans un dépôt. Il est unique.

Segment : champ d'une table qui permet de partager celle ci de façon différente. Le segment est obligatoirement une partie de la clé conceptuelle.

Attention !

Quelle que soit la fonction utilisée, il est obligatoire de gérer les tables PEV (paramétrage d’événement) et PARAV (personnalisation des paramètres) sur la société de plus haut niveau. En effet, si vos paramétrages sont différents sur les entités de bas niveau, vous risqueriez de rencontrer des problèmes d’exécution des fonctions interactives et différées.

Il faut positionner dans la fonction GPEV le paramètre MULENT au niveau général :

Pour la fonction de duplication d’un événement d’une entité sur une autre, il faut positionner le paramètre DUPENT pour la fonction concernée :

Pour déterminer la position fiscale d’un événement au sein d’une même société juridique, il faut positionner l’option A2 du paramètre POSFIS :

Figure 0‑1 : Paramétrage général

Figure 0‑2 : Paramétrage de la duplication

Figure 0‑3 : Paramétrage de la duplication pour transfert

Figure 0‑4 : Paramétrage pour la position fiscale.

Pour un bon fonctionnement, il faut aussi positionner le paramètre UTIFAM, afin de gérer les familles dans la table FAM. Ce paramètre est nécessaire pour définir des familles de sociétés qui sont différentes des familles de clients et des familles de fournisseurs.

Les types de liens définis dans le paramétrage général doivent être présents dans la table des types de lien (fonction GTTLI). Les fonctionnalités du mode multi-entités se basent sur deux hiérarchies :

• La hiérarchie opérationnelle qui sera utilisée pour le partage, la propagation des données et l'ensemble des points fonctionnels d’ACE COMMERCE.
• La hiérarchie juridique qui sera utilisée pour tous les liens entre ACE COMMERCE et ACE FINANCE.

Les deux types de liens peuvent être identiques.

Figure 0‑5 : Types de liens

Ces types de liens figurent dans les données d’installation.

Les niveaux hiérarchiques doivent être définis comme familles de tiers. Il est alors souhaitable de définir des familles de société indépendantes (fonction GTTTI) afin de créer une fonction de gestion des familles de sociétés (fonction GFSO).

Figure 0‑6 : Types de tiers

L’utilisation d’une famille de type SOC permet d’isoler les familles d’entités des autres familles utilisées dans le produit.

Figure 0‑7 : Paramétrage GFSO

Ce paramétrage permet d’indiquer le type de famille à gérer dans la fonction générale de gestion des familles.

Figure 0‑8 : Familles de sociétés

Cet exemple permet de gérer une hiérarchie à cinq niveaux. On retrouve le niveau correspondant à la société juridique (2), un niveau de consolidation (1) et des niveaux purement opérationnels (3, 4 et 5).

Remarque : le niveau qui correspond à la société juridique (ici 2) doit correspondre à la valeur N1 du paramètre MULENT.

Lors d'un paramétrage en multi-entités, il vous faut partager au minimum certaines tables. De la même manière, d’autres tables ne doivent surtout pas être partagées:

Doivent être partagés impérativement :

• TIE segment SOC niveau01
• TIL segment SOC niveau01

De plus, certains segments doivent être précisés en clair. Par exemple :

• TSC segment A niveau02
• TSC segment B niveau02

Si vous indiquez uniquement TSC niveau02, le partage ne fonctionne pas.

Attention !

Toutes les tables ut_*, et autres vues utiles pour le partage des habilitations sont à partager via le fichier Generix.ini. Certaines tables (TBL-tti, TBL-tct, TBL-rzo, TBL-tbl et TBL-ttu, table cot, table p_pln) doivent être partagées sur le niveau 1 de la hiérarchie.

Les tables suivantes ne doivent jamais être partagées ni propagées :

CAL - les calendriers

CAP - les périodes des calendriers

Pourquoi cette règle de gestion sur CAP et CAL ?

Aucun problème de fond si vous utilisez uniquement ACE COMMERCE. En revanche, si vous utilisez ACE FINANCE, les tables CAL et CAP ne peuvent pas être partagées car celles-ci portent des informations comptables mises à jour à la clôture d'exercice. Or comme les clôtures s'effectuent société par société, si vous partagez CAP et CAL, la clôture d'une première société vous empêchera de clôturer les autres.

Le paramétrage est réalisé via pop-up F1-P dans la fonction GSOC (option Modifier). Pour chaque table à partager (et éventuellement son segment), il faut préciser le niveau de la hiérarchie opérationnelle où est gérée l'information. Les tables (et éventuellement son segment) non précisées dans le paramétrage du mode multi-entités ne seront pas partagées. Il est fondamental de respecter la cohérence du modèle de données dans la définition du partage.

Gérer un enregistrement DSK à un niveau et un enregistrement LSK à un autre est par exemple absolument interdit.

Même si aucun contrôle de cohérence n’est effectué, une aide vous permet de générer automatiquement des informations cohérentes. Elles seront toujours modifiables par la suite mais il faudra, dans ce cas, apporter une attention toute particulière à la cohérence.

Figure 0‑1 : Partage des tables

Pour partager les stocks, il faut définir le partage de la table DSK.

• Valider la ligne correspondant à la table DSK.
• La sélectionner de nouveau et activer le pop-up Transmission des données , pour une gestion commerciale (tables relatives aux stocks).

Le système va dupliquer la ligne pour les tables associées : LSK, ESK, PSK, FSK, ISK, NSK, SKT, SSK et OST. La table DSK déclenche la propagation des données, les autres sont les tables associées.