Modélisation ERD et hiérarchique – Chapitre 4 :

En cette partie consacrée à la modélisation, nous devons transposer la description technique de la méthode Activity Based Costing en concepts XML, servant de base à la création du document XML reprenant les informations ABC. Nous l’avons déjà évoqué: XML a une structure hiérarchique. La modélisation des données se fera à l’aide d’un Entity Relationship Diagram (ERD), que nous transformerons ensuite en modèle hiérarchique.

1- Modèle Entity Relationship Diagram.

Nous représentons les données et les relations qui les lient au moyen d’un modèle Entity Relationship Diagram (ERD). Nous créerons des tables et attributs nécessaires; un attribut ayant un rôle index et noté « id_ … » sera créé pour chaque table. Nous prenons comme convention de ne pas utiliser, tant pour nommer les tables que les attributs , ni de majuscules, ni d’accent, qui sont sources de confusions et erreurs dans le développement informatique de ce travail. L’application ABC que nous avons proposée met en oeuvre des charges directes, des charges indirectes, des regroupements en familles de coûts, et des activités. Nous pouvons créer les tables correspondantes, soit: « charge_directe », « charge_indirecte », « famille_cout » et « activite ». Les quatre tables que nous venons de définir peuvent prendre les attributs suivants:

table « charge_directe »: « id_charge_d », « montant_dir_htva_impute », « quantite » table « charge_indirecte »: « id_chargeindirecte », « montant_htva_impute » table « famille_cout » : « id_famille », « nom_famille »
table « activite » : « id_activité », « nom_activite », « unite_oeuvre »

Nb. « htva » que nous trouvons pour les attributs « montant_dir_htva_impute » et « montant_htva_impute » signifie « hors TVA ». La relation comptable entre charge indirecte et famille de coût étant articulée autour des postes du pcmn, nous créons également une table « pcmn » dont les attributs seront le code pcmn (6 chiffres) et l’intitulé correspondant. table « pcmn » : « id_pcmn », « intitule »

Ces quatre tables, nous permettent d’inscrire et regrouper les données comptables.

D’autres tables seront dédiées à l’utilisation de ces données comptables de départ, que nous devons répartir au sein de commandes passées par des clients à l’entreprise. Pour ce, comme évoqué plus haut, nous devons effectuer des mesurages au fil du déroulement du processus de l’entreprise afin de répartir nos coûts d’activités. Il convient donc de créer une table « commande », une table « mesurage », et une table « client ».

table « commande » : « id_commande », « descriptif », « chiffre_affaire » table « client » : « id_client », « nom » et « adresse »

2- Les tables de relation.

Nous devons établir des relations entre ces tables de base du système. C’est-à-dire une relation entre « pcmn » et « charge_indirecte », entre « charge_indirecte » et « famille_cout », entre « famille_cout » et « activite », entre « activite » et « commande », entre « client » et « commande », entre « charge_directe » et « commande », entre « charge_directe » et « pcmn ».

Relation des tables « chargeindirecte » et « pcmn ».

Ces deux tables ont une relation de N à M ou plusieurs à plusieurs. Nous désignons par le terme « charge indirecte » une pièce comptable contenant une charge indirecte. Plusieurs destinations d’imputation sont possibles pour une même pièce: un même fournisseur peut reprendre au sein de la même facture des articles que nous destinons à des imputations différentes. Nous créons la table de relation « imputation » . La table « imputation » comprendra les attributs suivants:

table « imputation »: « id_imputation », « id_charge_indirecte », « id_pcmn_imputation », « montant_htva_impute ».

« id_imputation » est l’identificateur propre de la table « imputation », deux attributs sont les identificateurs des deux tables que nous mettons en relation: « id_charge_indirecte » et « id_pcmn_imputation », le dernier attribut est le montant hors TVA imputé.

Relation des tables « pcmn » et « famillecout ».

La relation entre ces deux tables est également de N à M. Une Famille de coûts est constituée de un ou plusieurs postes pcmn intervenant en proportions différentes dans le calcul de sa valeur finale. Un poste pcmn peut être intégré dans une ou plusieurs familles. La table « composition_famille » sera la relation entre les tables « pcmn » et « famille_cout ». Elle aura pour attributs: table « composition_famille »: « id_compofam », « id_famille », « id_pcmn_fam », « proportion_cf »
Nous avons utilisé des abréviations: « id_compofam » pour id_composition_famille , « id_pcmn_fam » pour id pcmn (dans famille_cout), et « proportion_cf » pour proportion cout famille. L’attribut « proportion_cf » contiendra la valeur de répartition d’un poste pcmn intervenant dans plusieurs familles. Si un poste pcmn est repris intégralement dans le calcul du coût d’une famille, l’attribut sera 1. Si il intervient pour 67%, l’attribut sera de 0.67 . Si un poste pcmn est repris intégralement dans le calcul du coût d'une famille

Relation des tables « famillecout » et « activite ».

La relation entre ces deux tables est de N à M. Une famille de coûts peut être composante de une ou plusieurs activités , qui elle peut inclure une ou plusieurs familles de coûts. Exemple: l’activité production inclus la famille7: outil et production et la famille4: formation documentation. La table « composition_activite » sera la relation entre les tables « famille_cout » et « activite ». Les attributs en seront: table « composition_activite »:« id_compoact », « id_activite ». « id_famille_kout », « proportion ». L’abréviation « id_compoact » est pour id_composition_activite. Comme précédemment, cet attribut « proportion » permet de fixer la proportion d’intervention d’une famille de coûts au sein d’une activité.

Relation des tables « activite » et « commande ».

Une commande peut mettre en oeuvre une ou plusieurs activités, une activité est utilisée par une ou plusieurs commande, ce qui implique une relation de N à M. La table de relation que nous utiliserons sera utilisée pour effectuer les mesurages d’unités d’oeuvre des différentes activités nécessaires à l’analyse ABC. Ce sera la table « mesurage », comportant les attributs:

table « mesurage »: « id_commande », « id_activite », « id_mesurage », « date », « unite_oeuvre », « quantite ».

Les champs « id_commande », « id_activite » sont des champs de relation. Relation des tables « client » et « commande ». les deux tables ont une relation de 1 à N. Un client peut passer une ou plusieurs commandes, une commande correspond à un seul client. La relation s’établira en incluant l’identificateur de client au sein de commande. La table « commande » devient: table « commande »: « id_commande », « descriptif », « id_client », « chiffre_affaire »

Relation des tables « chargedirecte » et « commande ».

Ces deux tables ont une relation de 1 à N. Une commande peut se voir imputer plusieurs charges directes, une charge directe est imputée à une seule commande. La relation est établie en incluant l’identificateur de la commande dans la table charge_directe.

Relation des tables « chargedirecte » et « pcmn ».

Ces deux tables ont une relation de 1 à N. Un poste pcmn correspond à une seule charge directe; une charge directe peut recevoir plusieurs attributions pcmn. Nous incluons l’identificateur du poste pcmn que nous appelons « id_pcmn_directe » La table « charge_directe » devient:

table « charge_directe »: « id_charge_d », « id_commande », « id_pcmn _directe », « montant_dir_htva_impute », « quantite »

Nb. Dans quelques cas, nous avons choisi de modifier le nom de l’attribut comme par exemple « id_pcmn_directe » qui est dans la table « pcmn » id_pcmn et dans la table « composition_famille »: « id_pcmn_fam. Cela ne modifie en rien la valeur de l’attribut, et nous permettra dans la suite de ce travail de pouvoir distinguer les trois attributs.

3- Modélisation hiérarchique

Comme nous l’avons évoqué plus haut, XML propose une représentation hiérarchique des données, qui forme un arbre XML. Un élément racine est le point de départ obligatoire d’une modélisation hiérarchique. Nous ne disposons pas parmi les tables du modèle ERD que nous venons de développer, d’élément racine (ou parent) de tous les autres éléments (tables). Nous créons cet élément: « ABC » (en majuscules exception faite pour l’élément racine) qui sera un élément vide. Modélisation hiérarchique Le premier élément hiérarchiquement sous la racine « ABC » est la table « client ». Au niveau hiérarchique suivant se trouvent les quatre tables principales de notre travail, « charge_indirecte », « commande », « famille_cout » et « activite ». Elles sont descendantes de « ABC », sauf la table « commande » qui est enfant de « client ». Elles se positionnent comme élément parent des tables de relation que nous avons créées dans le modèle ERD. « charge_indirecte » est parent de « imputation »: à une « chargeindirecte » correspond 1 où N instances d’ « imputation ». « commande » est parent de « mesurage »: à une « commande » correspond 1 où N instances de « mesurage ». « commande » est également parent de « charge_directe »: à une « commande » correspond 1 où N instances de « charge_directe ». « famille_cout » est parent de « composition_famille »: à une « famille_cout » correspond 1 où N instances de « composition_famille ». « activite » est parent de « composition_activite »: à une « activite » correspond 1 où N instances de « composition_activite ».

4- Eléments à parents multiples.

Notre représentation hiérarchique ne serait pas complète sans les éléments ayant des parents multiples. Eléments à parents multiples Il s’agit des trois tables descendantes de plus de une table. Nous voyons que « composition_activite » a pour parent « activite » comme nous venons de le voir, mais également « famille_cout »: à une « famille_cout » correspond 1 où N instances de « composition_activite ». La table de relation « mesurage » est descendante de « commande » et « activite ». Enfin, au dernier rang hiérarchique, la table « pcmn » est une table enfant à la fois d’« imputation » « charge_directe » et de « composition_famille ». Lire le mémoire complet ==> (Application de la méthode Activity Based Costing, technologies XML) Mémoire présenté en vue de l’obtention du grade de Licencié en Informatique et Sciences humaines Université libre de Bruxelles, Faculté des sciences sociales politiques et économiques

Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

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

Scroll to Top