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
 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.

1
 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.

2
 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

3
 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.

4
5
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 :

6
 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.

7
 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.

8
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.

9
 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.

10
 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.

11
 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

12
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.

13
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.

14
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.

15
 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%
Fonctionnalité 2 : Gérer les variations
3 10 jours Mar 24/04/07 Mer 09/05/07 100%
globales du prix
Fonctionnalité 3 : Ajouter une sécurité à
4 2 jours Jeu 10/05/07 Ven 11/05/07 100%
l'application
Fonctionnalité 4 : Ajouter la notion
5 8 jours Lun 14/05/07 Jeu 24/05/07 100%
d'acheteur leader
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.

16
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.

17
18
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é.

19
20
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.

21
22
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.

23
Voici le code VB correspondant :

Private Sub Liste21_AfterUpdate()

Dim rs As Object

Set rs = Me.Recordset.Clone
rs.FindFirst "[IDUTILISATEUR] = '" & Me![Liste21] & "'"
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.

24
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

25
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 ?", vbQuestion +
vbYesNo, "Attention")

If vRep = vbYes Then

Set db = CurrentDb

db.Execute ("UPDATE BUDACHU_VARIATION_POURC SET (VAL_POURC = '"

& Me.ValPourc & "', ANNEE_POURC = '" & Me.AnneePourc & "',
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.

26
Voici une partie intéressante de cette vue :

CASE WHEN SUM(VUE.DENUM_IAN1B * (NVL(((VAL_POURC/100)+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/100)+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/100)+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/100)+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 Dénominateur D Indice (N / D) * 100
Somme Ni Somme Di

Avec :

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

Py-1 = Dernier PMPM connu à décembre N-1

Py = PMPM du mois analysé

27
 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,VNM1DEC_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.

28
 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 yyyy")
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]").

29
 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

30
 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.IDUTILISATEUR 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.

31
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_LEADER")

Set vLstLeader = Me.LstLeader

For Each vValLstLeader In vLstLeader.ItemsSelected

rq.AddNew
rq![SELLEADER] =
vLstLeader.ItemData(vValLstLeader)
rq![IDUTILISATEUR] = UserName()
rq.Update

Next
Me.LstSelLeader.Requery
Me.LstLeader.Requery
End Sub

32
 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

33
 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.

34
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.

35
 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.

36
 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 Variation Prix Nouveau Commentaires

Prix Forcé Prix
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 à

37
 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.

38
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

39
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 Dénominateur D Indice (N / D) * 100
Somme Ni Somme Di

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 Dénominateur D Indice (N / D) * 100
Somme Ni Somme Di

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 Dénominateur D Indice (N / D) * 100
Somme Ni Somme Di

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

40
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 Dénominateur D Indice (N / D) * 100
Somme Ni Somme Di

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

41
 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

42