GUILLARD Thomas DUT Informatique 2è année

Rapport de stage

Période du 26 mars au 1er juin 2007

AJOUT DE FONCTIONNALITES DANS UNE APPLICATION

(ACCESS, ORACLE)

Etablissement LEGRAND Tuteur de stage IUT : M. Pascal DOLHEN Maître de stage LEGRAND : M. Thierry SAUVEGRAIN

Année scolaire 2006-2007

1

REMERCIEMENTS

Je remercie l’entreprise LEGRAND qui m’a accueilli pour réaliser mon stage de fin d’étude.

Je remercie également mon maître de stage, Monsieur Thierry

SAUVEGRAIN, administrateur de base de données de la direction Achats Groupe, pour son aide tout au long de mon stage dans le développement du projet.

Je remercie enfin toute l’équipe de la division Achat et les autres stagiaires

pour leur accueil et leur gentillesse qui ont facilité mon intégration.

2

RÉSUMÉ

Lors de mon stage, j’ai été convié à modifier une application déjà existante.

L’objectif qui m’était donné consistait à ajouter des fonctionnalités définies au début de mon stage. Ainsi, j’ai donc géré des utilisateurs, affecté des sous-familles aux acheteurs leaders, géré des variations de prix et mis en place une sécurisation.

J’ai toujours essayé de coder de la manière la plus compréhensible et j’ai toujours analysé ce qu’il fallait faire avant de me lancer directement dans la réalisation de ma tâche.

A la fin de chaque tâche, je demandais une confirmation concernant la justesse de celle-ci.

J’ai essayé d’analyser et d’expliquer tous les choix qui ont été faits.

3

TABLE DES MATIÈRES

INTRODUCTION PAGE 4 PARTIE 1 : CONTEXTE DU STAGE PAGE 5 I ] Présentation de l’entreprise PAGE 6 II ] Présentation du projet PAGE 9

1. Sujet du stage PAGE 9 2. Situation existante PAGE 9 3. Analyse du besoin PAGE 11

III ] Moyens matériels et logiciels utilisés PAGE 14 IV ] Organisation du projet PAGE 15 PARTIE 2 : ANALYSE ET RÉALISATION DU PROJET PAGE 18 I ] Analyse du sujet PAGE 19 II ] Réalisation des différentes fonctionnalités PAGE 23

1. Gestion des utilisateurs de l’application PAGE 23 2. Gestion des pourcentages affectés aux prix des articles PAGE 25 3. Mise en place d’un système de sécurisation PAGE 29 4. Gestion des acheteurs leaders PAGE 31 5. Mise en base de production PAGE 35

CONCLUSION PAGE 36 GLOSSAIRE SOURCES DOCUMENTAIRES

4

INTRODUCTION

L’entreprise Legrand m’a accueilli pour réaliser mon stage de fin de DUT Informatique. C’est une entreprise dynamique ouverte au monde. En effet, l’entreprise est toujours

désireuse d’innover, elle a toujours le désir d’attirer les clients vers elle. Elle essaie d’élargir de plus en plus son marché et de s’installer dans de plus en plus de pays. Elle souhaite conquérir de nombreux marchés : c’est une entreprise d’avenir en constante évolution.

La direction dans laquelle j’effectue mon stage, la direction Achats Groupe, veut mettre à disposition des utilisateurs concernés, une application qui est en développement depuis 3 ans.

Cette application a pour but de gérer des données concernant le budget, le chiffre d’affaires de l’entreprise, etc.

L’entreprise m’a demandé d’ajouter des fonctionnalités importantes à cette application.

Lors de mon stage, j’ai donc dû comprendre et utiliser cette application. Dans ce rapport, je vais tout d’abord vous expliquer le fonctionnement de cette

application, puis je vous ferai part de mon analyse concernant la base de données associée à cette application. Ensuite j’évoquerai succinctement les tâches à réaliser durant le stage ainsi que les instructions qui m’ont été données concernant la mise en place et la présentation de l’application. Puis, je présenterai les moyens matériels et logiciels qui m’ont été accordés durant mon stage. Enfin, je relaterai la façon dont j’ai géré les tâches que j’avais à réaliser avec les problèmes de temps et la durée de chaque tâche.

Dans une seconde partie, j’effectuerai une analyse complète de la base de données et donc de l’application et j’expliquerai en détail les différentes fonctionnalités que j’ai ajoutées ainsi que mes choix concernant le développement.

5

6

I ] PRÉSENTATION DE L’ENTREPRISE

Le groupe Legrand a été créé en 1860. A l’origine, l’entreprise était un petit atelier de

porcelaine de table limougeaud. En 1904, M. Legrand, associé à M. Betoule, devient propriétaire de la société et lui donne son nom. L’appareillage électrique est introduit en 1919 et cohabite alors avec la porcelaine.

En 1944, M. Jean Verspieren et M. Edouard Decoster prennent la direction de Legrand et 5 ans plus tard la production de porcelaine est abandonnée au profit de l’appareillage électrique, plus prometteur.

Voici quelques dates clés :

� 1966 : Rachat d’une société belge, extension en Europe. � 1974 : L'expansion se poursuit hors d'Europe avec l’ouverture d'une filiale au Brésil. � 1984 : 1ère implantation aux Etats-Unis. Le groupe réalise plus de 500 millions d'euros de

chiffre d’affaires. � 1989 : Entrée dans le groupe de Bticino, n°1 italien et une des premières marques

mondiales. � 2000 : Le groupe devient leader mondial en cheminement de câbles avec l'acquisition de

Wiremold. � 2005 : Legrand a acquis deux sociétés majeures en Chine : TCL International et TCL

Building Technology

L’entreprise Legrand se compose de plusieurs directions : la direction technique et la direction des systèmes d’information.

J’effectue mon stage à la direction Achats Groupe dont voici l’organigramme :

7

Aujourd’hui, Legrand est le N°1 mondial de l’appareillage électrique et du cheminement de câbles. Le groupe est implanté dans plus de 60 pays et distribué dans plus de 160 pays : en Amérique (Brésil, États-Unis), en Europe (Grèce), en Afrique (Egypte) et enfin en Asie (Arabie-Saoudite, Hong-Kong, Taïwan, Iran …).

Il dispose d’un maillage territorial dense qui lui permet de s’adapter aux besoins locaux et d’accompagner ses clients dans leurs projets internationaux à travers une trentaine de marques dont trois de renommée planétaire : Legrand, Bticino et Ortronics. En 2006, la société employait 31000 personnes dont 73% à l’étranger.

Legrand possède 20 marques mondiales ou locales leaders sur le marché. Son marché est compris entre 50 et 60 milliards d’euros pour les installations électriques

et réseaux d’information. Legrand a une croissance régulière sur des marchés historiques et un potentiel énorme

dans les pays émergents. L’optimisation régulière de son offre de produits et de fonctions, de son dispositif

industriel et commercial ainsi que de sa couverture géographique permet à Legrand de renforcer dans la durée sa position concurrentielle et donc de dégager les ressources financières additionnelles nécessaires à son développement futur.

Voici les données annuelles de l’entreprise Legrand :

Pour 2007, Legrand est confiant dans sa capacité à faire progresser son chiffre d’affaires total. L’entreprise repose sur 4 valeurs principales qui sont :

� L’éthique du comportement (respect), � La valorisation des ressources (optimiser l’utilisation des ressources), � L’écoute des clients, � L’innovation permanente.

D’une façon générale, la vocation de Legrand est d’offrir aux installateurs électriciens du

monde entier, via la distribution grossiste, tous les produits nécessaires à la réalisation d’une installation électrique basse tension (< 500 V) et courants faibles (<50 A) dans le logement, le tertiaire et l’industrie. Ceci dans les meilleures conditions de coût, de qualité et de délai.

8

Voici les 6 domaines d’activités stratégiques (DAS) de l’entreprise Legrand :

���� DAS 1 : Tableaux de distribution basse tension (mécanismes modulaires, têtes d’armoire,…) qui représentent environ 20% de l’activité Legrand.

���� DAS 2 : Circulation et mise à disposition des courants (appareillage, goulottes, boîtes d’encastrement…) représentant 50% de l’activité du groupe.

���� DAS 3 : Immotique, domotique, courants faibles (commande à distance, alarme incendie) qui représentent 7% de l’activité.

���� DAS 4 : Equipement électrique pour le marché grand public (englobant presque tous les produits entrée et moyenne gamme) soit 10% de l’activité.

���� DAS 5 : Constituants d’automatismes pour l’outil de production (commandes électriques basse tension pour les machines de production) représentant 10% de l’activité.

���� DAS 6 : Matériel électrique pour atmosphère explosive (tous les produits anti-déflagrants spéciaux) représentant 3% de l’activité.

Pour son avenir, Legrand a une double ambition, d’une part devenir sur tous les marchés

le leader des produits et systèmes pour installations électriques et réseaux d’informations, sachant qu’aujourd’hui Legrand représente 6% de part de marché dans le monde, et d’autre part devenir l’acteur de référence de l’intelligence électrique avec des solutions et des services innovants.

Afin d’atteindre ces objectifs, le groupe compte s’appuyer sur un choix de la spécialisation, caractérisé par une démarche de leadership technologique ; une offre unique de produits et systèmes et une dimension mondiale.

9

II ] PRÉSENTATION DU PROJET 1. Sujet du stage

L’objectif de mon stage est d’ajouter des fonctionnalités dans une application déjà

existante. L’entreprise travaille sur cette application depuis 3 ans et veut que les modifications soit

opérationnelles cette année. Certaines fonctionnalités manquent à cette application pour : � faciliter son utilisation par les futurs usagers. � la rendre plus sûre.

2. Situation existante Voici la page d’accueil de l’application au début de mon stage :

Cette application est composée de quatre onglets :

Le premier onglet « Critères » permet à l’utilisateur de faire ses choix concernant la sélection des acheteurs, des divisions et des unités qu’il veut visualiser.

L’utilisateur peut également choisir l’année dans laquelle il se place pour visualiser les données. Une fois que l’utilisateur a sélectionné une année, la zone de texte « Budget » située en dessous calcule automatiquement l’année du budget : c'est-à-dire l’année sélectionnée +1.

Enfin l’utilisateur a le choix d’utiliser les fournisseurs groupe (à l’intérieur du groupe LEGRAND), hors groupe (en dehors du groupe LEGRAND), ou groupe et hors groupe. Les sélections d’un utilisateur seront conservées pour sa prochaine connexion grâce à diverses tables et requêtes que j’évoquerai plus tard dans mon rapport.

Le deuxième onglet « Réalisé » regroupe les calculs de prix et donc les suivis au niveau de la sous-famille-locale, de l’année, de la catégorie, de l’unité…

Ces suivis sont représentés par des graphiques : ce sont les prix de l’année en cours. Dans cet onglet nous pouvons également observer les indices de prix sous différents

niveaux : article, société… Ces indices représentent le rapport du prix au mois de décembre de l’année N-1 sur le

prix du mois de janvier de l’année N. Ainsi nous pouvons remarquer les variations de prix avec le mois de décembre de l’année N-1.

10

Le troisième onglet « Budget » permet comme son nom l’indique de gérer des données budgétées, c'est-à-dire des données prévues et non réalisées. Ce sont des données qui sont prévues pour l’année N+1.

Dans cet onglet nous pourrons visualiser des analyses sur l’évolution future des prix. Ces analyses se font sur un niveau au choix : le fournisseur, l’article…

Le dernier onglet « Paramètres » contient une multitude de données sensibles auxquelles il faut faire très attention. En effet dans cet onglet nous pouvons créer un nouveau budget, verrouiller un budget ou affecter une sous-famille-locale à un acheteur. Ces données peuvent, si elles sont modifiées, changer tous les calculs. Il y a donc un risque de fausser les données et donc de les rendre inutilisables.

11

Dans les onglets « Réalisé » et « Budget », trois diagrammes représentent le Chiffre d’Affaires extrapolé, réalisé et budgété de l’année N.

Dans l’onglet « Budget » il y a un quatrième diagramme présentant le Chiffre d’Affaires budgété de l’année N+1.

3. Analyse du besoin

L’entreprise désire des nouvelles fonctionnalités pour son application afin de rendre encore plus complète la version déjà existante. C’est à moi que revient cette tâche.

Cette application sera utilisée dans toute la France par la plupart des Entreprises Legrand et par de nombreuses personnes (acheteurs locaux, acheteurs leaders, administrateurs ou des contrôleurs de gestion).

Mon stage ne se déroulait pas dans un service informatique donc il n’y avait pas de cahier des charges à proprement parlé : les demandes sont faîtes de manière non conventionnelle.

Il faut savoir que l’entreprise a le désir de ne pas décevoir le client et donc l’utilisateur final. C’est pourquoi les applications sont réalisées avec la ferme intention d’apporter une valeur ajoutée au travail de l’utilisateur. Il faut donc qu’elles soient le plus compréhensible et le plus intuitive possible.

Ainsi nous retrouvons des noms ou des images simples et efficaces sur les boutons. Il fallait que je respecte la présentation de l’application du départ afin de rester

compréhensible et pour garder la cohérence de l’application pour les utilisateurs finaux. Je me suis imposé des contraintes de temps afin d’éviter de rester trop longtemps sur une

tâche. Il y avait des obligations au niveau de l’interface utilisateur de l’application. En effet il

fallait que l’application soit la plus simple possible à comprendre pour l’utilisateur futur. Ainsi, il fallait créer des boutons clairs avec, soit une illustration intuitive, soit un mot

simple qui évoque parfaitement l’action que l’utilisateur va effectuer. Voici deux exemples de boutons :

Bouton permettant d’ajouter un prix Bouton permettant de fermer un formulaire

Il fallait également utiliser des zones de liste et non des listes déroulantes car avec les zones de liste, les données sont plus lisibles car il est possible de visualiser plusieurs données de la liste directement.

Il devait y avoir un titre simple et efficace en haut de la liste afin de bien comprendre ce qu’il y avait à l’intérieur.

12

Voici un exemple de liste :

Liste représentant les sites et les divisions que l’utilisateur a sélectionnés Pour éviter toute confusion, il fallait ajouter une bulle d’information concernant les icônes qui avaient un risque de ne pas être comprises parfaitement. Voici un exemple :

Bouton accompagné d’une bulle d’information qui explique qu’il sert à Modifier des critères de sélection.

Il était également préférable de ne pas surcharger les formulaires afin d’assurer la bonne compréhension de ceux-ci. Ainsi, les formulaires ne comportent pas beaucoup de données à compléter.

Il était important que les formulaires soient cohérents entre eux. C'est-à-dire qu’il ne fallait pas avoir des formulaires liés entre eux qui ne soient pas construits de la même façon. Tout ceci rend plus agréable et plus compréhensible l’application.

Dans la conception de l’application et donc des fonctionnalités que je devais ajouter il fallait impérativement utiliser des triggers :

Un trigger (déclencheur en français) est un élément de code qui se déclenche sur un événement précis, se rapportant à un objet de la base de données.

Un trigger se définit uniquement sur les objets de type TABLE et déclenche les événements suivants : INSERT, UPDATE, DELETE. Il peut être déclenché BEFORE (c'est à dire avant survenance de l'événement) ou AFTER (c'est à dire après survenance de l'événement). Il est attaché à une table.

Il est préférable d’utiliser un trigger lorsque l’on veut effectuer un formatage des données

ou que l’on veut supprimer en cascade. Ces triggers vont me permettre de modifier les données des tables que je veux modifier.

Pour afficher les données dans le formulaire, il fallait créer des vues qui permettent de

réaliser certains calculs et tests concernant ces données. Il était préférable également d’utiliser des noms cohérents concernant toutes les données

de la base. Par exemple, la table qui comprend les utilisateurs se nomme UTILISATEUR. Il fallait faire ceci dans un souci de maintenance pour les années futures.

Comme mon travail consistait à apporter de nouvelles fonctionnalités à une application déjà créée, je me suis organisé en fonction de ce qui avait déjà été réalisé. Tout ceci pour éviter toute complication dans la compréhension du code. Ainsi, tout ce que j’avais à ajouter dans les

13

vues ou les triggers était codé de la même manière que le code réalisé. J’ai donc construit mes formulaires en fonction de ceux déjà créés.

J’ai également créé les vues avec la même idée que pour les premières. J’ai donc réalisé tout un travail d’analyse et de compréhension de ce qui avait déjà été

fait.

14

III ] MOYENS MATÉRIELS ET LOGICIELS UTILISÉS

Lors de mon arrivée dans l’entreprise, on m’a installé un ordinateur et des logiciels comme Microsoft Office ou Power AMC. Cela m’a permis de travailler dans de bonnes conditions dès le début de mon stage.

L’entreprise utilise le logiciel Lotus Notes. C’est un logiciel de messagerie électronique. Grâce à ce logiciel tous les employés peuvent bénéficier d’une boîte mail. Mais ce logiciel ne permet pas seulement de recevoir ou envoyer des e-mails mais il permet également de planifier des réunions, consulter les coordonnées d’un employé etc.

Ainsi j’ai reçu des demandes de réunion comme dans l’exemple ci-dessous.

J’ai débuté ce stage par une familiarisation avec la base de données et tous les calculs de prix.

J’ai réalisé une analyse MERISE que j’évoquerai plus précisément plus loin dans ce rapport. J’ai travaillé avec le logiciel « POWER AMC » que nous avons utilisé en Première année de DUT Informatique.

Puis j’ai commencé la réalisation des nouvelles fonctionnalités, en utilisant « SCRIPT EDIT » pour le code, MICROSOFT ACCESS pour l’application en elle-même avec de la programmation en VB ACCESS et enfin avec « Oracle Tool » et SQL Plus pour le code SQL et enfin j’ai utilisé « MS PROJECT » pour la gestion de projet afin de m’organiser au mieux dans les différents tâches à réaliser.

15

IV ] ORGANISATION DU PROJET Durant mon stage j’ai eu l’occasion de participer à quelques réunions.

Ma première réunion a été effectuée le mercredi 4 avril. Mon maître de stage en était

l’organisateur et M.ROSTAN était également invité. Lors de cette réunion nous avons discuté sur le contenu de mon stage. Ainsi nous avons pu définir les différentes fonctionnalités que j’avais à réaliser lors de mon stage.

J’ai participé à une autre réunion le 17 avril organisée par M.ROSTAN. Lors de cette

réunion il a expliqué aux futurs utilisateurs de l’application son fonctionnement et comment sont réalisés les différents calculs de l’application.

Enfin, pour le mardi 22 mai, j’ai moi-même organisé une réunion avec mon maître de

stage afin de réaliser la mise en production de la base de test comme le montre la copie d’écran ci dessous.

Ainsi, j’ai invité mon maître de stage à une réunion le mardi 22 mai de 9h00 à 12h00. Le planificateur permet de connaître les disponibilités de la personne que l’on invite.

Mon maître de stage et moi nous retrouvions à peu près tous les deux jours pour des problèmes à résoudre ou pour faire un point sur ce qui a été réalisé. Cette fréquence de relation m’a permis de ne pas aller dans une direction différente de celle qui m’était donnée.

16

Lorsque j’avais terminé la réalisation une tâche, nous nous rencontrions afin qu’il me donne un nouveau travail à réaliser.

Afin de bien m’organiser dans mon travail, j’ai décidé de réaliser un diagramme de Gant

à l’aide du logiciel de gestion de projet « MS Project ». Ainsi ce logiciel m’a permis de planifier les tâches à effectuer durant le stage et par

conséquent cela m’a évité de me « perdre » et de me disperser. Voici la liste des tâches constituant mon projet :

Date de début du projet : Lundi 26/03/07 Date de fin du projet : Vendredi 01/06/07

Tâches

Nº Nom de la tâche Durée Début Fin % achevé

1 Analyse MERISE 14 jours Mar 27/03/07 Jeu 12/04/07 100%

2 Fonctionnalité 1 : Gérer les utilisateurs 8 jours Ven 13/04/07 Lun 23/04/07 100%

3 Fonctionnalité 2 : Gérer les variations globales du prix

10 jours Mar 24/04/07 Mer 09/05/07 100%

4 Fonctionnalité 3 : Ajouter une sécurité à l'application

2 jours Jeu 10/05/07 Ven 11/05/07 100%

5 Fonctionnalité 4 : Ajouter la notion d'acheteur leader

8 jours Lun 14/05/07 Jeu 24/05/07 100%

6 Mise en base de production de l'application 5 jours Ven 25/05/07 Ven 01/06/07 0%

7 Réalisation du rapport final 43 jours Lun 26/03/07 Mer 23/05/07 100%

J’ai nommé mes tâches en fonction des fonctionnalités que j’avais à réaliser. Ainsi, une

tâche correspond à une fonctionnalité à ajouter. Bien sûr j’ai ajouté l’analyse qui ne faisait pas partie du cœur du projet. Enfin j’ai inclus la réalisation du rapport final que j’effectuai chez moi.

La tâche « Mise en base de production de l'application » est présente car lors de mon stage j’ai travaillé sur une base de test qui était une copie de la base qui sera utilisée. Ainsi, pour effectuer cette tâche il fallait faire appel au secteur informatique (DSI) qui effectuera lui-même la mise en production de la base.

17

Voici le diagramme de Gant de mon projet correspondant au tableau précédent :

…

Grâce à ce diagramme nous observons que la tâche la plus longue à développer sans tenir

compte de la réalisation du rapport de stage a été l’analyse. C’est une partie complexe et très importante dans la compréhension de la base de données.

J’ai pris un peu de retard (1 jour) sur la réalisation de la deuxième fonctionnalité car il fallait modifier beaucoup de vues. Pour distinguer cette tâche je l’ai coloré en rouge. Ce fut une tâche très fastidieuse.

Pour les autres tâches, les quelques problèmes n’ont pas retardé le projet. La mise en place d’une sécurisation à même été plus rapide que prévu : 2 jours au lieu de 5.

Au moment de la clôture de mon rapport de stage, je n’avais pas encore réalisé la tâche de mise en production de la base de test. J’ai évalué la durée de cette tâche à 5 jours.

18

19

I ] ANALYSE DU SUJET Concernant la partie Analyse de mon sujet et donc de cette base de données, qui est très

importante puisqu’elle conditionne la bonne compréhension de la base, j’ai réalisé un modèle Merise (Modèle Conceptuel de Données et Modèle Physique de Données), à l’aide du logiciel « Power AMC », comme je l’ai évoqué auparavant. Le modèle Conceptuel de Données que j’ai réalisé à partir de la base de données déjà existante est présent sur la page suivante.

Dans ce modèle, il y a 4 grandes entités (tables) qui sont : � TABLEAU_IND, � TABLEAU_REALISE, � TABLEAU BUDGET � TABLEAU_ARTICLE.

Elles vont permettre de calculer les Chiffres d’Affaires, les indices, à partir des

informations présentes dans ces entités. Comme beaucoup de données, dans cette base, sont réalisées en fonction d’une année

donnée, la présence d’une table « Année » s’imposait. Cette table est reliée à presque toutes les autres tables de la base de données.

La table TABLEAU_ARTICLE permet de définir un article et de visualiser les années où il est présent, elle permet de définir également une sous-famille-locale qui est le « niveau » au dessus de l’article.

La table UTILISATEUR permet de connaitre les utilisateurs de l’application. Un utilisateur possède un identifiant. De plus il va pouvoir sélectionner un site qui sera spécialisé dans une division (Protection, Appareillage,…).

Il existe différentes sous-familles-locales (vues auparavant) qui, elles-mêmes, appartiennent à une famille d’une catégorie. C’est donc la principale hiérarchie du modèle.

Il y a également la présence de hausses représentées par les tables HAUSSES FOURNISSEURS et HAUSSES SOUS-FAMILLES. Ces deux tables présentent les hausses de prix d’un fournisseur ou des prix d’une sous-famille : c’est pour cela que l’une est reliée avec la table FOURNISSEURS et l’autre avec la table SOUS-FAMILLE

Il existe différents types de fournisseurs dans la base de données :

� 0 : externe, � 1 : interne,

Les associations qui relient des entités permettent de comprendre le fonctionnement de la

base et ainsi, de visualiser les liens entre les différentes tables de la base de données de l’application.

Ainsi, grâce à ce modèle, on peut remarquer qu’un utilisateur peut visualiser des acheteurs qui affectés à des sous-familles-locales et peut visualiser des données par rapport aux unités. Il sélectionne une année N et a le choix de visualiser les données par rapport aux fournisseurs du groupe Legrand ou externes au groupe Legrand ou par rapport à la totalité des fournisseurs.

Une sous-famille-locale appartient à une unité et est associée à une année. Enfin un utilisateur appartient à une unité. Les tables qui contiennent les données de calcul possèdent également une année et la référence de l’article. En effet chaque article, pour une année donnée, possède ses prix, ses variations, sa quantité.

20

21

Après avoir réalisé le modèle de la base existante, je me suis attelé à la réalisation du modèle comprenant les modifications que je devais apporter à l’application durant ce stage (MCD page suivante).

Pour la gestion des utilisateurs, j’ai supprimé le lien de la table PUTILISATEURS avec une autre base afin de rendre la table UTILISATEUR. J’ai supprimé les informations qui ne serviraient plus à l’application comme le téléphone, la fonction, l’e-mail de l’utilisateur. J’ai donc crée la table UTILISATEUR qui ne contient que l’IDUTILISATEUR, le NOM et le PRENOM de l’utilisateur.

Ensuite, afin de mettre en place un mécanisme de sécurisation, il fallait avoir une information qui renseignerait le profil de l’utilisateur différent de l’information FONCTION de la table PUTILISATEURS. J’ai donc ajouté l’information PROFIL dans la table UTILISATEUR. J’ai choisi de ne pas créer de table contenant seulement le profil car je n’en voyais pas l’utilité.

Ensuite, concernant la variation de pourcentage à affecter à tous les prix des articles, j’ai créé une table VARIATION_POURC qui comprendra la valeur du pourcentage, un commentaire et l’année de la variation (il ne peut y avoir qu’une seule variation par article et par année).

Cette table est donc reliée à la table ANNEE mais aussi à la table TABLEAU_REALISE qui contient les prix de l’article.

J’ai crée cette table car il était impératif d’avoir une table permettant de connaître le pourcentage de variation affecté à un article pour une année donnée afin de pouvoir effectuer les calculs de prix et de budget. La dernière modification que j’ai effectuée sur ce modèle, a été de créer une table LEADER et une association SELECT_LEADER qui deviendra une table dans l’application. En effet, je devais ajouter la notion de Leader dans l’application. J’ai donc choisi de créer une table qui répertorie les acheteurs leaders de la base. Un acheteur leader s’occupe d’une sous-famille-groupe qui appartient à une famille, qui appartient à une catégorie. De plus un utilisateur sélectionne les acheteurs leaders auxquels il veut voir les données.

La table SELECT_LEADER comprend tous les acheteurs leaders que l’utilisateur a sélectionnés.

Il était impératif de réaliser ces modèles de données car je pense que c’est un moyen de bien comprendre comment la base fonctionne. J’ai utilisé Merise car, selon moi, cette méthode est plus facile à comprendre par rapport à une analyse UML concernant une base de données.

22

23

II ] RÉALISATION DES DIFFÉRENTES FONCTIONNALITÉS

1. Gestion des utilisateurs de l’application

Cette première fonctionnalité a pour but d’ajouter, de modifier ou de supprimer un utilisateur de l’application. Tous les utilisateurs de l’application sont répertoriés dans la table UTILISATEUR. J’utilise cette table pour pouvoir accéder à tous les utilisateurs. A l’aide d’Access j’ai ajouté une liste sur laquelle apparaîtra la liste de tous les acheteurs. Pour récupérer la liste des utilisateurs j’exécute la requête SQL suivante : SELECT BUDACHU_UTILISATEUR.IDUTILISATEUR, BUDACHU_UTILISATEUR.NOM, BUDACHU_UTILISATEUR.PRENOM FROM BUDACHU_UTILISATEUR UNION SELECT " New", "<Nouveau> ","" FROM BUDACHU_UTILISATEUR ORDER BY BUDACHU_UTILISATEUR.NOM;

Je sélectionne l’IDUTILISATEUR, le nom et le prénom de l’utilisateur et j’ajoute une

ligne qui affiche « Nouveau » comme nom d’utilisateur. Cette ligne va permettre à la personne d’ajouter un nouvel utilisateur : En effet, il clique sur la ligne « Nouveau » puis il remplit les champs correspondants.

J’affiche dans la liste le nom et le prénom de l’utilisateur mais pas l’IDUTILISATEUR dont nous n’avons pas besoin : Il permet juste de pallier au problème que poserait la présence de deux personnes homonymes.

Puis j’ai ajouté deux zones qui permettront de modifier le nom, le prénom et une liste qui permet de modifier le profil de l’utilisateur.

Cette dernière liste contient trois profils possibles :

� ADMIN pour administrateur, � ACHET pour acheteur � AUTRE pour les autres types de personne.

La liste est verrouillée pour que l’utilisateur ne puisse pas affecter un profil différent de

ceux qui sont dans la base de données. La zone qui concerne le login de l’utilisateur permet d’ajouter le login de l’utilisateur que l’on ajoute.

Cette dernière zone sera cachée si l’on veut modifier ou supprimer l’utilisateur car on ne doit pas changer le login d’un utilisateur déjà présent dans la base.

J’ai ajouté 3 boutons : � Le premier permettant de sauvegarder l’ajout, la modification ou la suppression

dans la base. � Le deuxième qui permet de supprimer un utilisateur. � Le troisième pour quitter le formulaire actuel.

Sur le formulaire de l’accueil, j’ai ajouté un bouton « Gérer utilisateur » qui permet d’ouvrir le formulaire évoqué au dessus.

24

Voici le code VB correspondant : Private Sub Liste21_AfterUpdate() Dim rs As Object Set rs = Me.Recordset.Clone rs.FindFirst "[IDUTILISATEUR] = '" & Me![Liste2 1] & "'" If Not rs.EOF Then If Me.Liste21 = " New" Then Texte11.Visible = True DoCmd.GoToRecord , , acNewRec Else Texte11.Visible = False Me.Bookmark = rs.Bookmark End If End If On recherche si l’utilisateur est présent dans la base. Ensuite, si la personne veut insérer un nouvel utilisateur, la zone « login » devient visible sinon elle reste cachée.

Formulaire de gestion d’utilisateur

Le problème auquel j’ai été confronté reposait sur la zone de texte du nom et la zone de

texte du prénom. En effet je ne savais pas comment faire apparaître les données au clic de l’utilisateur dans la liste.

25

De plus, je découvrais les liens entre Access et les requêtes SQL pour utiliser les différentes tables de la base de données ACCESS

2. Gestion des pourcentages affectés aux prix des articles

La deuxième fonctionnalité que j’ai ajoutée a été de modifier l’application afin de

pouvoir affecter un pourcentage au prix de chaque article pour une année donnée. Pour cela j’ai réalisé un nouveau formulaire permettant de visualiser tous les pourcentage déjà affectés par année, mais aussi d’en affecter ou d’en modifier un.

Le formulaire se compose d’une liste avec l’année correspondante à l’année de la variation du pourcentage, d’une zone de texte qui permet de renseigner la valeur du pourcentage à affecter, d’une autre zone de texte qui permettra d’ajouter un commentaire afin d’expliquer pourquoi nous avons affecté ce pourcentage pour l’année sélectionnée. Enfin, j’ai ajouté une liste qui permet de répertorier tous les pourcentages déjà affectés, avec l’année de la variation du pourcentage et sa valeur. Voici la maquette de ce formulaire :

Formulaire de gestion de variation de prix

26

Voici le code du bouton de sauvegarde de la modification. Private Sub CmdOk_Click() On Error GoTo Err_CmdOk_Click vRep = MsgBox("Vous allez modifier les prix des réf érences de tout les articles." & Chr(10) & "Continuer ?", vbQu estion + vbYesNo, "Attention") If vRep = vbYes Then Set db = CurrentDb db.Execute ("UPDATE BUDACHU_VARIATION_POURC SET (VA L_POURC = '" & Me.ValPourc & "', ANNEE_POURC = '" & Me.AnneePour c & "', COMMENTAIRE = '" & Me.COMMENTAIRE & "')") End If Liste13.Requery Exit_CmdOk_Click: Exit Sub Err_CmdOk_Click: MsgBox Err.Description Resume Exit_CmdOk_Click End Sub

J’ai inséré une boîte de message demandant à l’utilisateur une confirmation concernant

l’ajout d’une variation. Cette confirmation est très importante car la variation modifiera beaucoup de graphiques présents dans l’application. Si la réponse au message est oui alors on peut exécuter la requête de mise à jour de la table. On met à jour la table VARIATION_POURC à l’aide de la commande UPDATE et on insère dans cette table la valeur du pourcentage, l’année et le commentaire concernant cette variation. Enfin on met à jour la liste de gauche à l’aide de Requery.

Dans le formulaire d’accueil j’ai ajouté, dans l’onglet « Paramètre », un bouton « Affecter Pourcentage » qui permettra d’afficher le formulaire décrit précédemment.

Ce deuxième travail a été plus difficile que les autres car il fallait modifier certains tableaux et graphes. En effet, les prix standards changent avec la variation de pourcentage. Il fallait donc modifier les prix standard de l’année du budget. J’ai donc transformé la vue V_CAL_IND_FG qui permet de calculer les indices de prix des familles groupe de la base.

27

Voici une partie intéressante de cette vue : CASE WHEN SUM(VUE.DENUM_IAN1B * (NVL(((VAL_POURC/10 0)+1),0))) = 0 THEN 0 ELSE (SUM(VUE.NUM_IAN1B)/SUM(VUE.DENUM_IAN1B * (NVL(((VAL_POURC/100)+1),0))))*100 END "IAN1B", CASE WHEN SUM(VUE.DENUM_IAN2B * (NVL(((VAL_POURC/10 0)+1),0))) = 0 THEN 0 ELSE (SUM(VUE.NUM_IAN2B)/SUM(VUE.DENUM_IAN2B * (NVL(((VAL_POURC/100)+1),0))))*100 END "IAN2B", CASE WHEN SUM(VUE.DENUM_IAN3B * (NVL(((VAL_POURC/10 0)+1),0))) = 0 THEN 0 ELSE (SUM(VUE.NUM_IAN3B)/SUM(VUE.DENUM_IAN3B * (NVL(((VAL_POURC/100)+1),0))))*100 END "IAN3B", CASE WHEN SUM(VUE.DENUM_IAN4B * (NVL(((VAL_POURC/10 0)+1),0))) = 0 THEN 0 ELSE (SUM(VUE.NUM_IAN4B)/SUM(VUE.DENUM_IAN4B * (NVL(((VAL_POURC/100)+1),0))))*100 END "IAN4B",

L’indice à la référence de l’article est composé de 3 données :

� Le prix de l’année N-1, � le prix de l’année N, � la quantité d’article lors de l’année N-1.

Le calcul d’un indice se réalise comme ceci : Art 1 Qy-1 Py-1 Py N1 = Py * Qy-1 D1 = Py-1 * Qy-1 Indice = (N1 / D1) * 100 Art 2 Null Null Py N2=0 D2=0 N/A Art 3 Qy-1 Py-1 Null N3=0 D3=0 N/A Art …

Art N ….. ….. ….. ….. ….. Total Sous Famille, Unité,… Numérateur N

Somme Ni Dénominateur D Somme Di

Indice (N / D) * 100

Avec : Qy-1 = Quantité Année N-1 Py-1 = Dernier PMPM connu à décembre N-1 Py = PMPM du mois analysé

28

Il faut savoir que les numérateurs et dénominateurs sont calculés dans un trigger nommé TABLEAU_BUDGET_AFTER : en voici un exemple de calcul : DENUM_IAN3 = NVL(ROUND(DECODE(ART.INDICE,0,0,VNM1DE C_QTE_CUM * NVL(VNM1DEC_R,0)) * (DECODE(VNMAR,NULL,0,0,0,1)), 2),0)

Ainsi, on calcule le produit du nombre d’article A, présents durant l’année NM1 par le prix réel de l’article A. La ligne de code : * (DECODE(VNMAR,NULL,0,0,0,1)),2),0) permet de vérifier si le numérateur est NULL, égal à 0 ou égal à une valeur quelconque. Si le numérateur est NULL alors on multiplie par 0 le dénominateur, sinon on le multiplie par 1. Cela permet donc de conserver un même périmètre. Dès que le numérateur n’est pas une valeur quelconque on ne prend pas en compte le dénominateur. On fait de même pour le dénominateur par rapport au numérateur.

La vue V_CAL_IND_FG fait la somme des numérateurs des articles de la famille groupe concerné et la divise par la somme des dénominateurs des articles de la famille groupe concernée.

Pour pouvoir mettre en place la gestion de pourcentage, il a fallu que je multiplie le dénominateur par la valeur du pourcentage.

Pour cette fonctionnalité, j’ai également dû modifier un formulaire présent dans l’application au départ. Ainsi, j’ai dû modifier le formulaire «Calendrier» qui permet de consulter, ou modifier les différents prix et leurs différentes variations. Voici le formulaire :

Formulaire de détail d’un article

J’ai ajouté une zone de texte qui correspond à la variation du prix dû au pourcentage de

variation. Cette donnée n’est pas exprimée en pourcentage.

29

J’ai également ajouté une zone qui représente le nouveau prix standard calculé en multipliant l’ancien prix standard par la variation de prix en valeur.

Ensuite, j’ai dû ajouter une colonne dans le tableau présentant le PMPM ; je l’ai nommée PMPM Final. Ce PMPM prend en compte le nouveau prix standard.

Enfin, il fallait modifier les sources de chaque donnée du graphique en bas du formulaire. Le problème que j’ai rencontré lors de la réalisation de cette tâche a été la modification

des triggers. En effet il fallait que je comprenne d’abord pourquoi utiliser un trigger et sa signification. J’ai également rencontré un problème de temps de réponse. En effet, le temps de réponse de l’application était beaucoup trop long. Nous avons donc décidé, avec mon maître de stage, de découper la vue en deux vues distinctes. La première réalise les sommes et nomme le résultat. La seconde permet de vérifier les résultats des calculs. Cette nouvelle manière de faire a permis de gagner un temps d’exécution considérable. Il fallait également assimiler tous les calculs afin de pouvoir modifier ceux-ci en ajoutant la notion de pourcentage de variation.

3. Mise en place d’un système de sécurisation

La troisième fonctionnalité à ajouter permettait d’instaurer un mécanisme de sécurisation. Pour cela j’ai utilisé la table utilisateur qui comportait la donnée Profil. Comme expliqué auparavant il existe trois types de profil : administrateur, acheteur et autre.

Nous avons décidé, avec mon maître de stage, que l’administrateur aurait tous les droits (lecture, ajout, modification), que l’acheteur aurait le droit de lecture et de modification et que les autres auraient le droit de lecture seulement. Pour réaliser ce système il a fallu récupérer le profil de l’utilisateur connecté Pour pouvoir faire cela il fallait utiliser la fonction username() qui permet de récupérer l’IDUTILISATEUR de l’utilisateur qui s’est connecté à son ordinateur. Après avoir récupérer le username de l’utilisateur, on l’associe à son profil ainsi on aura le profil de l’utilisateur connecté. Private Sub Form_Load() If vCalc Then Me.CmdCalc.Caption = "Activer Calcul Manuel" Else Me.CmdCalc.Caption = "Activer Calcul Auto" End If If (PROFIL2.Value = "ADMIN") Then Paramètres.Enabled = True Else Paramètres.Enabled = False End If TxtDate.Value = Format(Date, "dddd d mmmm yyy y") End Sub

Ce code permet de réaliser ce que j’ai affirmé auparavant. J’ai ajouté une zone de texte nommée PROFIL2 qui permet de récupérer le profil de

l’utilisateur : =RechDom("[PROFIL]";"[TESTSecurisation]").

30

Puis si le profil est ADMIN alors on ne verrouille pas l’onglet paramètre, sinon on le verrouille ainsi les acheteurs et autres utilisateurs ne pourront pas appuyer sur les boutons de l’onglet paramètre. Comme dans l’exemple ci-dessous :

Onglet « Paramètres » du formulaire d’accueil.

De plus, le système de sécurisation est présent lors de la consultation du détail d’un

article : une personne qui est administrateur ou acheteur pourra modifier le prix d’un article mais si cette personne possède le profil AUTRE alors elle ne pourra pas modifier les prix. Cette sécurité a été instaurée car il y avait des risques de données erronées au niveau des prix. Il fallait donc restreindre l’accès à ces données aux seuls administrateurs ou acheteurs. Enfin, j’ai ajouté sur le formulaire « Accueil » trois champs :

- La date du jour - Le login de l’utilisateur - Le profil de l’utilisateur

Voici le formulaire correspondant :

Formulaire d’accueil de l’application

31

4. Gestion des acheteurs leaders

La dernière fonctionnalité que j’ai ajoutée consistait en l’ajout de la notion d’acheteur leader. Les acheteurs leaders sont des acheteurs leader sont des acheteurs qui sont en relation directe avec les fournisseurs. Ce sont eux qui prennent les décisions concernant les prix à pratiquer les négociations de ceux-ci.

Pour ajouter cette notion il fallait ajouter une liste qui permettrait de récupérer les derniers paramètres que l’utilisateur a sélectionnés lors de sa dernière connexion.

Ainsi cela permettra à l’utilisateur de ne pas sélectionner une nouvelle fois ces paramètres habituels à chaque connexion. Cette liste va se trouver juste à coté de la liste correspondant aux acheteurs. La liste ajoutée va représenter les acheteurs leaders dont l’utilisateur veut visualiser les données correspondantes. Ainsi nous aurons des graphiques en fonction des acheteurs leaders en plus de tous les autres paramètres déjà présents auparavant. Voici le formulaire d’accueil avec la liste des acheteurs leader :

Formulaire d’accueil comprenant la liste des acheteurs leaders sélectionnés par l’utilisateur.

Lorsque l’utilisateur double-clique sur la liste un nouveau formulaire apparaît qui permet

de sélectionner ou désélectionner un acheteur leader. Il y a 5 boutons différents :

� un permettant d’ajouter un acheteur dans la sélection, � un autre permettant ajouter tous les acheteurs dans la sélection, � un troisième pour enlever un acheteur de la sélection, � un quatrième pour enlever tous les acheteurs de la sélection, � un dernier pour quitter le formulaire et revenir donc au formulaire d’accueil.

SELECT BUDACHU_UTILISATEUR.IDUTILISATEUR, BUDACHU_UTILISATEUR.NOM, BUDACHU_UTILISATEUR.PRENOM, [SELECT_LEADER Connecté].IDUTILISATEUR FROM [SELECT _LEADER Connecté], BUDACHU_UTILISATEUR WHERE [SELECT_LEADER Connecté].SELLEADER=BUDACHU_UTILISATEUR.IDUTILISATE UR ORDER BY BUDACHU_UTILISATEUR.NOM, BUDACHU_UTILISATEUR.PRENOM, BUDACHU_UTILISATEUR.IDUTILISATEUR;

La requête « SELECT_LEADER Connecté » permet de connaître tous les acheteurs leader que l’utilisateur a sélectionné lors de sa dernière connexion.

32

La requête ci-dessus permet d’afficher la liste des acheteurs leader sélectionnés, ainsi on différencie les différents acheteurs leaders sélectionnés par leur IDUTILISATEUR. Voici le formulaire correspondant à la sélection des acheteurs leaders :

Formulaire de sélection des acheteurs leaders

Voici un exemple de code de ce formulaire : Private Sub CmdAjout_Click() Dim vLstLeader As Control Dim vValLstLeader As Variant Dim db As DAO.Database Dim rq As DAO.Recordset Set db = CurrentDb Set rq = db.OpenRecordset("BUDACHU_SELECT_LEA DER") Set vLstLeader = Me.LstLeader For Each vValLstLeader In vLstLeader.ItemsSel ected rq.AddNew rq![SELLEADER] = vLstLeader.ItemData(vValLstLeader) rq![IDUTILISATEUR] = UserName() rq.Update Next Me.LstSelLeader.Requery Me.LstLeader.Requery End Sub

33

Ce code correspond au bouton qui permet d’ajouter un acheteur leader dans la sélection de l’utilisateur connecté. On utilise la table SELECT_LEADER qui contient tous les acheteurs leaders sélectionnés par l’utilisateur, puis, dans cette table nous utilisons les informations SELLEADER et IDUTILISATEUR qui vont permettre de faire le lien entre les données de la table et celles de la liste. Ainsi, lorsque l’on clique sur le bouton d’ajout, on ajoute le leader sélectionné par l’utilisateur dans la table SELECT_LEADER. La ligne de code : rq.Update va mettre à jour la table SELECT_LEADER. Ainsi l’opération d’ajout effectuée par l’utilisateur va être prise en compte à l’intérieur même de la table SELECT_LEADER. La ligne de code Me.LstSelLeader.Requery va permettre de mettre à jour la liste des leaders sélectionnés et la ligne en dessous permettra de mettre à jour la liste des leaders (la liste de gauche sur l’image ci-dessus).

Les autres boutons sont codés de la même manière à la différence que les requêtes sont différentes de celle de l’ajout simple. En effet pour la suppression nous allons utiliser le code rq.Delete qui va permettre de supprimer de la sélection l’acheteur leader que l’utilisateur avait déjà sélectionné.

Comme je l’ai évoqué auparavant un grand nombre de vues sont utilisées afin de pouvoir visualiser les calculs dans des graphes ou des tableaux. Or cette fonctionnalité en utilise beaucoup. Il a du falloir introduire la notion d’acheteur leader dans les vues déjà existante car sinon tout ce que l’on avait fait auparavant n’aurait servi à rien. Voici donc un exemple de vue que j’ai réalisé : WHERE CHOIX_GRP.UTILISATEUR = UNITES.UTILISATEUR AND CHOIX_GRP.CHOIX <> VUE.FOURNISSEUR_GROUPE AND CHOIX_GRP.UTILISATEUR = ANBUD.UTILISATEUR AND VUE.SOCIETE = ACHT.SOCIETE AND VUE.SOUS_FAMILLE_LOCALE = ACHT.SOUS_FAMILLE_LOCALE AND VUE.SOCIETE = UNITES.CODE AND SSD.UTILISATEUR = UNITES.UTILISATEUR AND SSD.NUMSEL = VUE.SIT_DIVISION AND SSD.UTILISATEUR = ANBUD.UTILISATEUR AND SU.UTILISATEUR = UNITES.UTILISATEUR AND SU.SELUSER = ACHT.ACHETEUR AND SU.UTILISATEUR = ANBUD.UTILISATEUR AND VUE.SOCIETE = UNITES.CODE AND UNITES.VISU = -1 AND UNITES.UTILISATEUR = ANBUD.UTILISATEUR AND ANBUD.ANNEE_N = VUE.ANNEE AND VUE.ANNEE = TO_CHAR(TO_NUMBER(VP.ANNEE_POURC) +1) AND SL.IDUTILISATEUR = UNITES.UTILISATEUR AND SL.SELLEADER = L.IDUTILISATEUR AND SL.IDUTILISATEUR = ANBUD.UTILISATEUR GROUP BY VUE.CATEGORIE, VUE.ANNEE, VUE.BUDGET, UNITES.UTILISATEUR

34

J’ai choisi de vous présenter cette partie de vue car c’est ici que sont exposées les conditions du calcul. En effet, c’est dans la clause WHERE que l’on va faire les liens entre les tables. Ainsi, nous pouvons dire qu’un calcul correspond à une année, une société, un acheteur, un acheteur leader, un utilisateur et une unité. Nous pouvons alors garantir qu’il n’y aura pas de doublons au niveau des utilisateurs.

Pour éviter à l’utilisateur de fermer son formulaire s’il veut changer ses critères de sélection au niveau des acheteurs leaders, il fallait ajouter la sélection évoqué précédemment dans le formulaire « Sélection Critères » qui est accessible lors de l’aperçu des tableaux de données ou des graphiques. Voici le formulaire créé :

Formulaire « Sélection Critères »

La liste des acheteurs leaders sélectionnés est construite exactement de la même manière

que la liste construite précédemment. Pour terminer cette fonctionnalité, il fallait pouvoir affecter un acheteur leader à sa sous-

famille-groupe. J’ai donc réalisé un nouveau formulaire qui permettra de visualiser les sous-familles-groupe et leur acheteur leader. J’ai créé une liste qui permettra de visualiser la liste de toutes les sous-familles-groupe et leur acheteur affectés. Si la sous-famille-groupe n’a pas d’acheteur leader, je laisse la case correspondant au nom de l’acheteur vide. Sinon, j’indique dans la colonne correspondante au nom de l’acheteur leader qui s’occupe de la sous-famille-groupe. En dessous de la liste, j’indique la sous-famille-groupe sélectionnée ainsi que son acheteur dans la liste déroulante située à coté. J’utilise trois boutons :

� Le premier permet de sauvegarder le nouvel acheteur-leader affecté à la sous-famille-groupe correspondante,

� le deuxième permet d’annuler le changement que l’utilisateur vient d’effectuer � le troisième permet de quitter le formulaire.

J’ai ajouté une zone de texte qui permet de faire une recherche par sous-famille-groupe. Enfin, j’ai ajouté une case à cocher qui permettra de ne visualiser que les sous-familles-

groupe qui ne sont pas affectées à un acheteur leader.

35

Voici le formulaire correspondant :

Formulaire permettant d’affecter des sous famillegroupe aux acheteurs leaders

Le problème auquel j’ai été confronté reposait sur la façon de modifier les vues car il

fallait examiner et comprendre les vues qui étaient déjà présentes dans la base. Ainsi il fallait modifier la plupart des vues car elles avaient un lien avec la notion d’acheteur leader que je devais instaurer.

5. Mise en base de production

A l’heure de la clôture de mon rapport, je n’ai pas encore réalisé cette tâche. Comme je l’ai évoqué auparavant, j’ai effectué mes modifications de l’application et de

la base de données dans une base de test, je travaillais donc sur une copie de la base de données qui sera utilisée.

Cette tâche consistait en l’organisation de la mise en production de la base de test. La mise en production, en elle-même’, sera effectuée par le service informatique de l’entreprise Legrand Limoges (DSI). Il faut donc faire une demande auprès de ce secteur afin qu’ils étudient la base de donnée. Tout ceci est fait par mesure de sécurité. Nous ne pouvons pas installer n’importe quoi sur le réseau de l’entreprise car il pourrait y avoir des problèmes de virus ou une diffusion de données qui porte atteinte à l’entreprise.

Il fallait donc organiser et évaluer tout ce dont DSI avait besoin pour réaliser cette mise en production.

J’ai donc rassemblé tous les fichiers que j’avais crées ou modifiés durant mon stage : les triggers, les vues, les index, les synonymes et bien sûr les tables.

36

CONCLUSION

Ce stage aura donc consisté en l’ajout de nouvelles fonctionnalités dans l’application « Budget » déjà existante.

Il a donc fallu effectuer une analyse complète de la base de données afin de comprendre son fonctionnement.

Ces fonctionnalités étaient différentes les unes des autres avec par exemple, la mise en place de sécurisation ou la gestion de pourcentages avec le calcul de divers prix.

C’est pourquoi, j’ai pu approfondir mes connaissances dans le domaine des bases de données et donc du langage SQL. J’ai également approfondi mes connaissances dans le domaine de la gestion de projet. De plus, ce stage m’a permis de découvrir plus en détails le langage VB que nous n’étudions pas à l’IUT dans le cadre de cours magistraux. Enfin, je me suis familiarisé avec l’aspect commercial. En effet, dans cette application, j’ai pu rencontrer tous les différents calculs de prix, les budgets ainsi que les notions d’acheteurs leaders.

L’application que j’ai complétée sera utilisée après mon stage, dans la plupart des entreprises Legrand de France (Antibes, Strasbourg, Isère, Pantin, Sillé, Limoges, Guise, Fontaine, Montville, Malaunay, Senlis, Pau…). Les fonctionnalités que j’ai ajoutées seront donc utiles à la bonne utilisation de l’application. Bien sûr, cette application évoluera puisque la demande évolue continuellement mais ces fonctionnalités devraient se pérenniser.

Pendant toute la durée de mon stage, j’ai pu participer à des réunions, ce qui m’a fait découvrir le travail en équipe dans l’entreprise.

J’ai trouvé ce stage très intéressant car il m’a permis de me familiariser avec le monde de l’entreprise. Cela m’a permis de découvrir l’obligation de résultats dans l’entreprise et les contraintes de temps.

Pour conclure, ce stage m’a vraiment apporté, au niveau technique comme au niveau

relationnel. Ce fut une expérience très enrichissante, un apport personnel dans le cadre de mes études. J’ai trouvé ce stage complètement différent des périodes de cours et je l’ai vécu pleinement.

37

GLOSSAIRE Méthode de codification des champs : xx_N = données de l’années xx_NM1 = données de l’année A-1 xx_NM2 = données de l’année A-2 xx_NP1 = données de l’année A+1 YTD = Year to Date = Cumul progressif de Janvier au mois sélectionné MMM = prix mensuel réel (de Janvier à Aout), prix mensuel extrapolé (de Septembre à décembre) MMM _NP1 = Prix standard mensuel calculé pour le budget MMM _R = prix réel de septembre à décembre MMM _BIS = top de forçage du prix mensuel (1 = forcé, 0 = calculé) VARIATION_ MMM = pourcentage de variation du prix à la référence VARIA_FAM_ MMM = pourcentage de variation du prix à la Sous Famille Locale VARIA_FOU_ MMM = pourcentage de variation du prix au fournisseur Formule de calcul du prix standard mensuel (ou prix standard extrapolé) Prix du mois = prix du mois M-1 * Variation à la référence * Variation à la Sous Famille Locale * Variation au fournisseur Nota : le calcul se porte sur tous les prix de la période future sauf si un prix a été forcé Exemple : Mois Ancien

Prix Variation Prix

Forcé Nouveau Prix

Commentaires

Septembre 10 10 Octobre 10 10 Novembre 10 5% 10.5 Le pourcentage s’applique à

partir de Novembre jusqu'à Juin Budget

Décembre 11 10.5 Janvier Budget 11 10.5 Février Budget 11 10.5 Mars Budget 11 10% 11.55 Le pourcentage s’applique à

38

partir de Mrs Budget jusqu'à Juin Budget

Avril Budget 11 11.55 Mai Budget 11 11.55 Juin Budget 11 Oui 10 Le prix est forcé, on ne prend en

compte que les % futurs Juillet Budget 11 10 Aout Budget 11 10 Septembre Budget 11 10% 11 Octobre Budget 11 11 Novembre Budget 11 11 Décembre Budget 11 11 Données mensuelles Extrapolée : Les données de Prix, CA et Qte sont initialisées avec les valeurs du dernier mois chargé afin d’avoir les dernières données valide sur le mois sélectionné PFA = Prévision Annuel de vente PMPM = Prix moyen pondéré mensuel (calculé à la référence) � PMPM = Chiffre d’affaire du mois / Quantité acheté du mois PMPA = Prix moyen pondéré Annuel YTD (calculé à la référence= � Chiffre d’affaire YTD / Quantité Cumulé YTD PMPA_N (PMPA_M) = Prix Moyen Pondéré Annuel moyen � moyenne arithmétique des PMPM de Janvier à Aout + PMPM Extrapolé de Septembre à Décembre STD_N = Prix Standard de l’année (calculé l’année précédente). Ce prix est rechargé à partir des bases de production afin de prendre en compte les nouvelles références non prévues au budget ou encore les modifications de dernière minute STD_NP1 = Prix standard du budget (Année N+1) � Moyennes des prix NP1 du budget QTE = Quantité achetée sur une référence QTE_CUM = Quantité YTD de la référence au mois QTE_EXT = Quantité extrapolée à la référence en fonction de la PFA, soit : Janvier = QTE_CUM + (PFA / 12) * 11 Février = QTE_CUM + (PFA / 12) * 10 Mars = QTE_CUM + (PFA / 12) * 9 Avril = … Nota : la Quantité Extrapolé n’est calculé que jusqu’au mois d’Aout.

39

CA = Chiffre d’affaire mensuel à la référence CA_CUM = Chiffre d’affaire YTD à la référence SOCIETE = Code Unité Legrand ANNEE = Année des données de l’enregistrement BUDGET = Année du budget de l’enregistrement (ANNEE + 1) CODE_FOURN_PRINCIPALE = Code du fournisseur de la référence ayant la plus grosse part de marché CODE_FOURN_GROUPE = Code de regroupement des fournisseurs locaux permettant d’identifier un seul et même fournisseur dans chaque unité. FOURNISSEUR_GROUPE = Identification si le fournisseur est une filiale Legrand ou non (0 = externe, 1 = interne) SOUS_FAMILLE_LOCALE = Code sous famille achat géré localement dans les unités SOUS_FAMILLE_GROUPE = Code sous famille achat commun à toutes les unités SIT_DIVISION = Déclinaison de l’unité en plusieurs partie distinct INDICE = top prise en compte de l’article dans les indices (0 ou Null = Prix en compte, 1 = exclu) FAMILLE_GROUPE = Niveau supérieur de la sous famille groupe CATEGORIE = Niveau Supérieur de la famille Groupe Effet Volume = Valeur de l’augmentation des quantités entre deux Chiffres d’affaire (type de CA : Réel / Budget, Période Janvier / Février) L’effet volume est calculé à la référence Art 1 Qte N-1 PMPA N-1 Qté N PMPA N PMPA N-1 * (Qté N – Qté N-1) Art 2 Null Null Qté N PMPA N PMPA * Qté N Art 3 Qté N-1 PMPA N-1 Null Null - (PMPA N-1 * Qté N-1) Art … Art N ….. ….. ….. ….. Total Sous Famille, Unité,… Somme des résultats

40

Effet Prix = Valeur de l’augmentation des prix entre deux Chiffres d’affaires (type de CA : Réel / Budget, Période Janvier / Février) L’effet volume est calculé au niveau de regroupement demandé C’est la différence entre les deux CA analysé diminué de l’effet volume Indice Intra Annuel = Indice de suivi des prix mensuels Art 1 Qy-1 Py-1 Py N1 = Py * Qy-1 D1 = Py-1 * Qy-1 Indice = (N1 / D1) * 100 Art 2 Null Null Py N2=0 D2=0 N/A Art 3 Qy-1 Py-1 Null N3=0 D3=0 N/A Art …

Art N ….. ….. ….. ….. ….. Total Sous Famille, Unité,… Numérateur N

Somme Ni Dénominateur D Somme Di

Indice (N / D) * 100

Qy-1 = Quantité Année N-1 Py-1 = Dernier PMPM connu à décembre N-1 Py = PMPM du mois analysé Indice Inter Annuel = Indice de suivi des prix annuel Art 1 Qy-1 Py-1 Py N1 = Py * Qy-1 D1 = Py-1 * Qy-1 Indice = (N1 / D1) * 100 Art 2 Null Null Py N2=0 D2=0 N/A Art 3 Qy-1 Py-1 Null N3=0 D3=0 N/A Art …

Art N ….. ….. ….. ….. ….. Total Sous Famille, Unité,… Numérateur N

Somme Ni Dénominateur D Somme Di

Indice (N / D) * 100

Qy-1 = Quantité Année N-1 Py-1 = PMPA N-1 Py = PMPA N PMPA N-1 et PMPA N sur période identique (ex : Janvier à Juin) Indice Standard Annuel = évolution de prix entre PMPA et STD Art 1 Qy-1 Py-1 Py N1 = Py * Qy-1 D1 = Py-1 * Qy-1 Indice = (N1 / D1) * 100 Art 2 Null Null Py N2=0 D2=0 N/A Art 3 Qy-1 Py-1 Null N3=0 D3=0 N/A Art …

Art N ….. ….. ….. ….. ….. Total Sous Famille, Unité,… Numérateur N

Somme Ni Dénominateur D Somme Di

Indice (N / D) * 100

Qy-1 = Quantité Année N-1

41

Py-1 = PMPA N-1 Py = STD_N Indice Standard Mensuel = évolution de prix entre PMPM et PMPM Budget Art 1 Qy-1 Py-1 Py N1 = Py * Qy-1 D1 = Py-1 * Qy-1 Indice = (N1 / D1) * 100 Art 2 Null Null Py N2=0 D2=0 N/A Art 3 Qy-1 Py-1 Null N3=0 D3=0 N/A Art …

Art N ….. ….. ….. ….. ….. Total Sous Famille, Unité,… Numérateur N

Somme Ni Dénominateur D Somme Di

Indice (N / D) * 100

Qy-1 = Quantité Année N-1 Py-1 = PMPM Py = PMPM Budget PMPM et PMPM Budget sur période identique (ex : Janvier / Janvier, Juin / Juin, …) NUM_IANx = Numérateur du calcul de l’indice Intra Annuel DENUM_IANx = Dénominateur du calcul de l’indice Intra Annuel La gestion des données sous la forme numérateur et dénominateur permet de calculer les indices a des regroupement de niveau supérieur ( Sous Famille, Famille, Unité,…) NUM_IRNx = Numérateur du calcul de l’indice Inter Annuel DENUM_IRNx = Dénominateur du calcul de l’indice Inter Annuel NUM_SANx = Numérateur du calcul de l’indice Standard Mensuel DENUM_SANx = Dénominateur du calcul de l’indice Standard Mensuel NUM_STNx= Numérateur du calcul de l’indice Standard Annuel DENUM_STNx= Dénominateur du calcul de l’indice Standard Annuel

42

SOURCES DOCUMENTAIRES

http://support.microsoft.com/ http://www.developpez.net/ http://www.vbfrance.com http://forum.hardware.fr http://sqlpro.developpez.com/ http://oracle.developpez.com/ http://dev.mysql.com/ http://labo-oracle.com/ Site intranet de Legrand : http://www.fr.dialeg.com/portail/ Les cours de base de données de DUT