Upload
nguyennhan
View
215
Download
1
Embed Size (px)
Citation preview
7/20/2004 1
Remerciements Je remercie tout particulièrement Monsieur Michel Pestiaux de m’avoir donné
l’opportunité de développer ce projet complet au sein de l’entreprise où il officie et la
possibilité de le présenter en tant que travail de fin d’études. Par l’aide apportée tout au
long de la réalisation de ce projet, Monsieur Pestiaux a réussi à obtenir le matériel ainsi
que le temps qui étaient nécessaires à sa mise en place.
Mes remerciements vont également à tous les collègues de l’entreprise ERGA pour leur
patience et leur soutien.
Je remercie également mes collègues qui m’ont poussé quotidiennement depuis 1 an et
demi à terminer ce travail.
Merci aussi à mon promoteur, Frédéric de Thysebaert, pour avoir accepté de suivre ce
projet avec enthousiasme et tout le dévouement qui le caractérise.
Je remercie l’Ecole Supérieure des Affaires pour m’avoir donné la possibilité de suivre
cette formation.
Merci enfin à mon frère David par son soutien et surtout ses innombrables tests ainsi
que tous mes amis pour leurs encouragements.
7/20/2004 2
1 Introduction Tout a commencé le jour où je me rendis sur le site d’exploitation de la société ERGA
(vente d’appareils électroménagers et matériels hi-fi) afin de demander quelques
renseignements concernant un appareil à réparer. J’ai été très bien accueilli mais on ne
pu malheureusement m’accorder que très peu de temps en raison de certains problèmes
techniques au niveau du service après-vente. En effet, certains appareils rentrés en
réparation ne comportaient plus aucun papier pouvant identifier la panne et le
propriétaire. De plus, même le préposé aux commandes n’arrivait plus à remettre la
main sur certaines pièces détachées…
Quelques jours plus tard, le responsable du service après-vente (Mr Pestiaux) me
demandait s’il était possible de créer un petit programme permettant le suivi des
différentes tâches de son service.
Voilà, le défi était lancé mais le projet s’annonçait titanesque.
Très vite, je me suis rendu compte que de nombreux besoins existaient dans différentes
catégories et que cela dépassait largement le cadre du « petit programme ».
J’ai ainsi déterminé qu’un développement en architecture deux tiers (applications
clientes accédant à une base de données partagée) était une réponse possible à ces
besoins.
Quels sont ces besoins et comment y ai-je répondu, c’est ce que nous allons voir dans
ces pages.
7/20/2004 3
2 Identification du projet
2.1 Présentation de la société et fonctionnement
La société anonyme ERGA vend et répare du matériel électroménager et hi-fi depuis
1946.
Cette société possède deux sites d’exploitation :
- Un magasin situé Rempart de la Vierge à Namur où l’on vend tout comme l’on
répare du matériel.
- Le second site situé Chaussée de Marche à Wierde abrite les bureaux et
l’entrepôt.
Sur le site de Namur, trois services distincts sont présents, à savoir le service
commercial, la comptabilité et le service après-vente.
Ce travail sera centralisé sur le service après-vente qui utilise le support papier pour la
gestion des interventions, commandes et autres, contrairement aux autres services qui
sont eux informatisés.
2.2 Objectifs
L’installation d’une application permettant la gestion du service après-vente était plus
que nécessaire pour les raisons suivantes :
- Mise en place d’un outil fiable apportant le support informatique, le suivi des
différentes tâches ainsi que l’automatisation des différents processus du
service après-vente
- Exploitation de l’outil depuis plusieurs « machines » facilitant la consultation
- Centralisation des données en un seul endroit unique et accessible à tout le
personnel.
Comme il n’existait aucune solution informatique propre excepté quelques fichiers
Excel ou Access, tout était à faire.
Ce travail ne traitera pas seulement du développement de l’application mais il
envisagera l’installation de l’application dans sa globalité, à savoir :
- La base de données
- Le déploiement de l’application
- L’application en elle-même
7/20/2004 4
Les besoins, tels que formulés par le service après-vente ont tout de suite écarté la
possibilité d’utiliser un produit commercial. En effet, ces besoins sont très spécifiques et
couvrent plusieurs domaines différents (gestion utilisateurs, suivi de bons, gestion de
stock, …). De plus, même si certaines applications commerciales proposent un package
se rapprochant des besoins demandés, le coût engendré est bien trop important.
Il a donc été décidé dans un souci d’uniformité de procéder au développement d’une
application unique au lieu d’une ou plusieurs solutions commerciales différentes qui
n’auraient pas permis une centralisation efficace et auraient engendré des coûts
ingérables.
7/20/2004 5
2.3 Principales fonctionnalités demandées
Les souhaits de la société sont les suivants :
- Gestion intervention : encodage et suivi des différentes interventions (devis,
réparation, intervention sur site)
- Gestion commande : encodage et suivi des commandes clients (pièces
détachées)
- Gestion livraison : encodage et suivi des livraisons d’appareils neufs aux
clients.
- Gestion stock : encodage et suivi des pièces détachées sont pris en charge
uniquement par le service après-vente.
2.4 Quels sont les besoins ?
2.4.1 Centralisation
Comme mentionné dans l’identification du projet, la centralisation des données était un
des besoins les plus importants. En effet, au sein du même site, si on considère par
exemple, la gestion du stock, celle-ci est tenue de deux manières différentes. L’une à
l’aide d’un fichier Excel, l’autre sur papier. La société ayant deux sites d’exploitation, la
majorité des documents se retrouvent en double des deux côtés. Rassembler toutes ses
données en un seul endroit permet de définir une méthode de travail pour assurer la
validité des données. Cet endroit constitue LA référence.
2.4.2 Utilisation
Le public ciblé n’étant pas nécessairement constitué d’informaticiens chevronnés,
l’application devra être facile d’utilisation, conviviale et rapide d’accès.
De plus, la vulgarisation de certaines applications actuelles et leur accès grand public
(Internet explorer, Outlook express, …) offrent comme avantage à tous les utilisateurs
de retrouver facilement ses habitudes pour autant que vous suiviez plus ou moins la
même ergonomie.
7/20/2004 6
2.4.3 Base de données
Dans notre cas, toutes les données centralisées en un seul endroit seront bien
évidemment stockées dans une base de données.
Il s’agit d’une méthode facile, efficace et éprouvée.
2.4.4 Performance & Maintenance
Outre l’aspect ergonomique très important, il est indispensable que l’application soit
performante, fiable et dynamique.
- Performante : réduire au maximum les temps d’accès à la base de données
(recherche, …) par une optimisation du langage SQL.
- Fiable : cohérence des données lorsque plusieurs utilisateurs
encodent/modifient ces données.
- Dynamique : assurer qu’un utilisateur ne bloque pas certaines données
comme cela a déjà été vu dans d’autres applications commerciales.
Ex : Sage – Gestion commerciale (http://www.sage.be)
L’aspect Backup sera géré par un programme externe.
2.5 Historique des fonctionnalités et évolutions de l’application
La version présentée dans ce travail est le résultat de toute une évolution. De nombreux
modules sont ainsi venus s’ajouter au fil du temps.
Cette application ainsi que la base de données ont été maintes et maintes fois corrigées,
optimisées et parfois totalement refaites.
Voici les dates clés dans l’évolution des modules qui sont présentés :
- Avril 2003 : Démarrage du projet, description et analyse
- Juin 2003 : Essai de plusieurs bases de données et langages différents
- Août 2003 : Démarrage du développement en Delphi/Interbase
- Septembre 2003 : Module Login, Personnel, Client & Appareil faits
- Décembre 2003 : Ajout des modules Menu Principal, Livraison &
Commande
- Janvier 2004 : Ajout des modules Intervention & Devis
- Février 2004 : Ajout des modules Réparation, Stock et Main d’oeuvre
7/20/2004 7
- Mars 2004 : Migration d’InterBase vers Firebird 1.5 + début création des
rapports d’impression + ajout module Ordre des interventions
- Avril 2004 : Test de l’application par les utilisateurs + ajout
- Mai 2004 : Début de mise en production + continuation du développement +
test
7/20/2004 8
3 Plate-forme utilisée & architecture réseau
3.1 Serveur
3.1.1 Configuration matérielle
A l’heure où ce mémoire est rédigé, il n’y a pas encore de serveur dédicacé pour
supporter la base de données Pour ce faire, j’ai choisi la machine la plus puissante tant
au niveau processeur, mémoire et espace disque parmi celles qui sont présentes sur le
parc informatique, cette machine étant client / serveur en même temps.
Il s’agit d’un Pentium 4 à 2.4 Mhz. Il est épaulé par 256 MB de mémoire ainsi qu’un
disque dur IDE de 60 GB.
L’installation d’un serveur dédicacé est planifiée dans le futur.
3.1.2 Système d’exploitation
Le client / serveur fonctionne sur Windows XP. Aucun autre choix n’a été possible vu
que la société ne dispose que de cette seule et unique licence reposant sur le noyau NT.
3.1.3 Sauvegardes et backups
Les seules solutions de sauvegarde et backup actuelles sont la copie de la base de
données tous les jours sur CD-Rom ainsi que sur deux emplacements réseaux différents.
Un système RAID (mirroring) est planifié sur le futur serveur dédicacé.
3.1.4 Sécurité des accès
La machine faisant actuellement office de client / serveur est à la disposition de tout le
monde. Néanmoins, un compte utilisateur avec mot de passe restreint l’utilisation de la
machine.
De plus, la base de données est protégée par login / mot de passe, ceci afin d’éviter
qu’une personne mal intentionnée ne tente d’y accéder avec divers programmes de
management.
Le futur serveur sera lui placé dans une pièce fermée à clé.
7/20/2004 9
3.2 Client
3.2.1 Configuration matérielle
Le parc informatique de la société est assez hétéroclite et est composé de plusieurs types
de machines, de tout âge et venant de divers endroits. Cela va du PI au PIV. Néanmoins,
l’application n’est pas trop gourmande et tourne très bien même sur le PI.
3.2.2 Système d’exploitation
Comme pour la configuration matérielle, il y a un peu de tout. Cela va du Windows 95
en passant par Windows 98 jusqu'à Windows ME.
Fort heureusement le langage de développement choisi s’accommode très bien de tous
ces différents systèmes et encore aucune incompatibilité n’a été trouvée.
7/20/2004 10
3.3 Architecture réseau
3.3.1 Schéma
7/20/2004 11
3.3.2 Description rapide du réseau
Ce réseau est très basique et est constitué pour le moment de machines et d’une
imprimante laser réseau, le tout connecté sur un switch. Dans un futur proche, une
machine dédicacée au stockage de données sera implémentée dans le réseau.
Actuellement, seul le site de Namur est relié à l’Internet. Mais il est prévu de connecter
les deux sites entre eux au moyen de lignes ADSL.
Il faudra cependant modifier le type de ligne ADSL côté Namur pour avoir une adresse
IP fixe et non dynamique comme c’est le cas pour l’instant.
3.3.3 Sécurité
Bien évidemment, la première chose qui saute aux yeux est l’absence de Firewall. En
effet, il n’est pas prévu dans le budget de la société, l’achat de Firewall hardware pour le
moment. Fort heureusement, le modem/router qui permet la connexion du lan vers la
wan intègre un mini firewall et utilise le protocole NAT. Les deux mis ensemble
assurent néanmoins une assez bonne sécurité.
L’installation d’un Firewall personnel gratuit sur chaque machine est actuellement à
l’étude.
3.3.4 Quelques définitions
LAN (Local Area Network) : Ensemble d’ordinateurs connectés les uns aux autres dans
un même endroit.
WAN (Wide Area Network) : Un réseau d’ordinateurs étendu sur de très grandes
distances connectant plusieurs LAN ensemble.
Switch : Un Switch est un élément permettant de concentrer le traffic provenant de
plusieurs hôtes, et de regénérer le signal tout en évitant les collisions.
Firewall : Un firewall est un système permettant de protéger un ordinateur des
intrusions provenant du réseau (ou bien protégeant un réseau local des attaques
provenant d'Internet).
NAT (Network Address Translation) : Permet de faire une translation d’une adresse
vers une autre. Très utilisé dans le cas des réseaux privés où on a généralement qu’une
seule adresse ip publique.
7/20/2004 12
4 Solution proposée La solution proposée dans ces pages a pour but de couvrir l’ensemble des demandes
formulées par le service après-vente.
L’application doit rester la plus ouverte possible pour l’ajout de nouveaux modules.
4.1 SGDB
4.1.1 Pourquoi choisir d’abord la base de données ?
Pourquoi commencer d’abord par le choix de la base de données et non pas par le
langage de développement ?
Comme je partais d’un système d’information vide, je n’avais aucun choix imposé tant
au niveau base de données que du langage. A partir de cela, j’en ai déduit que la base de
données devrait être choisie avec minutie, cela même avant le langage en nous basant
sur les contraintes.
4.1.2 Contraintes
1) Suivant l’analyse du projet, j’ai mis par écrit les différentes fonctionnalités que la
base de données devait supporter (intégrité référentielle, procédure stockée,
compteur, …).
2) Une base de données qui puisse si possible être « programmée » en natif ou du
moins s’en rapprocher le plus. Ceci afin d’éviter les drivers ODBC (par exemple)
qui sont source de ralentissements.
3) Une base de données qui a fait ses preuves et qui peut fonctionner parfaitement sur
un environnement Windows ou Linux.
4) Finalement et non des moindres, la base de données doit être gratuite
7/20/2004 13
4.1.3 Choix de la base de données
Suite aux contraintes évoquées ci-dessus, une base de données s’est rapidement
imposée. En effet, InterBase 6.01 (version open-source) répondait à tous les critères
cités précédemment. Au milieu du projet, nous avons migré vers Firebird 1.5 qui est en
fait une évolution open-source d’InterBase, plus optimisée et ajoutant quelques
fonctions intéressantes et surtout en évolution constante alors que la version open-
source d’InterBase n’évoluera plus jamais.
4.1.3.1 Historique de Firebird
En Août 2000, Borland sort la version 6.0 d’InterBase en open-source. La communauté
open-source préféra établir une équipe de développement totalement indépendante
plutôt que d’être soumis aux risques, aux conditions et restrictions que la compagnie
(Borland) proposait pour la participation commune dans le projet open-source. De là
naquit le projet Firebird. Quoique la communauté open source essaya plusieurs fois de
réunifier leurs efforts avec Borland afin de renforcer la position d’InterBase et ses
développements futurs, il est apparu évident (spécialement après la sortie de la version
commerciale d’InterBase 6.5) que le divorce était inéductable.
Depuis lors, on peut voir Firebird comme un produit totalement indépendant qui est
(presque) compatible à 100% avec InterBase de Borland.
4.1.4 Avantages
Les avantages de Firebird 1.5 sont multiples.
4.1.4.1 Control transactionnel total
Tout d’abord, Firebird est une base de données totalement transactionnelle. Une simple
application client peut avoir des transactions multiples et concurrentes. Les niveaux
d’isolation peuvent être entièrement contrôlés par le client.
4.1.4.2 Backup online
Il n’est pas nécessaire d’arrêter la base de données pour faire un backup. En effet, le
processus du backup prend une « image » de la base de données au moment où il est
démarré, ce qui permet aux utilisateurs de pouvoir continuer de travailler pendant qu’un
backup est en cours.
7/20/2004 14
4.1.4.3 Générateur
La présence de « Générateur » permet l’implémentation facile d’un champ auto
incrémenté.
4.1.4.4 Procédures stockées, triggers et intégrité référentielle
La contrainte d’intégrité référentielle permet de faire référence à des valeurs
préexistantes dans une colonne d’une autre table et cela au moyen des « foreign key ».
Le trigger permet l’exécution de code en fonction d’un événement survenant dans une
table.
La procédure stockée permet de déclencher du code lorsqu’on le souhaite.
4.1.4.5 Administration
L’administration de Firebird requiert très peu de temps et est très facile. De plus, de
nombreux outils sont disponibles.
4.1.4.6 Fonctions externes
Ouverte aux évolutions futures personnelles ou non par le biais de l’UDF (User Defined
Function). Vous pouvez écrire des librairies UDF en C, C++ ou Delphi et les ajouter
facilement dans le moteur afin d’en améliorer les fonctionnalités.
4.1.4.7 Accès
L’accès à Firebird se fait en natif depuis Delphi (par exemple). Pas de drivers ODBC ou
quoique ce soit d’autres. Une dll doit cependant être installée sur chaque poste client.
4.1.4.8 Gestion des verrous
Nouveauté introduite dans la version 1.5, cette gestion des verrous permet d’empêcher
toute modification sur un champ, mais celui-ci reste néanmoins accessible en lecture.
Voir annexe pour plus de détails
4.1.5 Inconvénients
Il y a assez peu d’inconvénients, mais nous pouvons noter néanmoins ceux-ci :
- Difficulté d’accès à la base de données en dehors des langages suivants : C, C++ et
Delphi
- Ne respectant pas tout à fait la norme SQL concernant le type de données, la migration
de cette base vers un autre format risque d’être plus compliquée.
4.1.6 Installation et configuration de Firebird
Voir annexe
7/20/2004 15
4.2 Langage utilisé
4.2.1 Motivation et choix du langage
Une fois la base de données choisie et n’ayant aucune contrainte imposée au niveau du
langage, je pouvais choisir celui qui me convenait le mieux. Ayant touché un peu à tout
(C++, VB, Pascal & Delphi, Java, …) et n’ayant pas vraiment de préférence, j’ai choisi
le langage s’accordant le mieux avec Firebird.
Pour faire mon choix, j’ai fait un petit sondage auprès de mes amis ayant déjà
programmé avec Firebird, mais j’ai également fait des recherches sur les sites de
développements spécialisés, sur des forums et tout le monde fut unanime, Delphi et rien
d’autres.
4.2.2 Avantages du langage
4.2.2.1 Principaux avantages de DELPHI
- IDE puissant avec accès aux principaux composants très facilement
- Syntaxe claire et compréhensible
- Très bien structuré.
- Robuste et puissant
- Compilateur très rapide
- Débogueur puissant
- Composant que l’on peut faire et trouver un peu partout sur Internet
- Grande communauté mondiale (tutoriaux, forums,…)
- Possibilité d’interfaçage avec un grand nombre de base de données
- Prix : la version de Delphi 6 Personnel est gratuite
- Version Linux (Kylix)
4.2.2.2 Facilité de développement
Après 6 mois de développement plus ou moins intensif, la facilité avec laquelle l’on
peut créer certaines choses est ahurissante. Jusqu'à présent, rien n’a été impossible à
faire en delphi.
7/20/2004 16
4.2.2.3 Puissance et compatibilité
Concernant la puissance, il est assez difficile de se prononcer étant donné que j’ai n’ai
pas réécrit l’application dans d’autres langages. Néanmoins, les résultats obtenus sont
plus que satisfaisants sur de vieilles machines comme des PI ou PII.
Concernant la compatibilité, j’ai été plus que séduit par cet aspect. Pourtant, j’avais un a
priori quant à la portabilité et compatibilité vers les différentes configurations
hétéroclites du réseau suivant mon expérience avec d’autres langages.
Mais au final, l’application tourne sur toutes configurations confondues et cela sans
aucune modification quelconque du code.
4.2.2.4 Aide
On ne peut parler de Delphi sans parler de l’aide que l’on peut trouver un peu partout.
On ne présentera plus les dizaines de livres existants sur le sujet, mais le plus incroyable
est sûrement ce qu’Internet peut apporter par le biais des sites dédicacés, des forums,
des tutoriaux en ligne, …
Il en devient par conséquent presque inconcevable de « sécher » sur un problème
Delphi.
4.2.3 Inconvénient
L’un des plus gros problèmes pour les débutants, voire même pour les assidus est sans
conteste l’aide interne.
Pourquoi donc plébiscité l’aide dans les « Avantages » et la mettre en même temps dans
la rubrique « Inconvénient » ?
Celle-ci demande une approche plus fine pour trouver ce que l’on cherche. Il m’est
souvent arrivé à plusieurs reprises de ne pas trouver ne fut-ce qu’une idée afin d’avancer
dans la résolution du problème sans faire référence à une autre source d’information
(sites dédicacés, forums).
Pour cela, les produits de développement de la famille Microsoft offrent une aide plus
que richissime surtout si vous y ajoutez les librairies MSDN.
7/20/2004 17
4.3 Fonctionnalités offertes
4.3.1 Gestion de la sécurité
4.3.1.1 Authentification
Les utilisateurs doivent rentrer un login et un mot de passe au démarrage de
l’application.
Premièrement, cela limite l’accès de l’application aux personnes concernées.
Deuxièmement, cela permet de définir les droits de l’utilisateur.
4.3.1.2 Catégories de droits
Il y a 3 catégories de droits :
- USER
- POWERUSER
- ADMIN
La catégorie « ADMIN » donne accès à toutes les fonctionnalités. C’est la seule qui
puisse ajouter, modifier ou supprimer un utilisateur ou un main d’œuvre.
La catégorie « POWERUSER » a aussi accès à toutes les fonctionnalités exceptée la
gestion des utilisateurs et la main d’œuvre.
La catégorie « USER » hérite des restrictions du poweruser en ajoutant l’impossibilité
de supprimer un bon (intervention, commande, livraison, …).
4.3.1.3 Méthodologie pour la création de comptes utilisateur
Il existe d’innombrables manières de définir des comptes utilisateur.
On peut en citer quelques-unes :
- nom + prénom OU prénom + nom
- numéro
- diminutif du nom ou du prénom, ou concaténation des deux.
J’ai choisi le dernier modèle, mais réduit à sa plus simple expression.
En effet, le login est composé de 3 lettres, ce qui donne 17576 possibilités différentes.
Le responsable technique et moi-même sommes tombés d’accord sur le format suivant :
� première lettre du prénom + 2 premières lettres du nom
Ex : Didier Pestiaux donnerait « DPE »
7/20/2004 18
4.4.2 Schéma général
Ce schéma reprend toutes les fonctionnalités existantes
Accessible uniquement à l’admin
Module principal (accessible à tous avec restriction)
Module secondaire (accessible à tous)
4.4.3 Aperçu des modules principaux
4.4.3.1 Menu Principal
Ce module est le point central de l’application par où toutes les actions passent.
Il permet :
- L’affichage de tous les bons qui n’ont pas le statut « clôturé »
- L’affichage par type de bons (intervention, devis, commande, etc…)
- L’affichage de tous les bons confondus par client
- Accès à la création et/ou modification d’un bon.
- Recherche avancée
De plus, il donne accès à tous les modules suivant les droits de l’utilisateur.
Serveur Firebird (DB)
Intervention
Commande
Livraison
Devis
Réparation
Client
Stock
Appareil
Utilisateur MO
Calendrier
Ordre INT Menu Principal Recherche
7/20/2004 19
4.4.3.1 Bon d’intervention
Le but principal de ce module est la traçabilité de tout appareil rentré au service après-
vente du magasin ou de toute intervention sur site demandée.
Ce bon comportera les données principales :
- du client
- de l’appareil défectueux
- du problème rencontré
- d’un rendez-vous (date et période) s’il s’agit d’une intervention sur site
Une fois le bon d’intervention créé, on pourra y attacher un ou plusieurs devis ou bon de
réparation.
Tout le monde peut encoder un bon d’intervention ou y accéder.
L’impression est également gérée afin de donner une trace au client.
4.4.3.2 Devis
Le devis permet de détailler et de donner une estimation du coût engendré par la
réparation de l’appareil.
En plus de reprendre les informations du bon d’intervention, il ajoutera lui-même les
informations suivantes :
- le détail de(s) pièce(s)
- le détail de la réparation à faire
- la main-d’œuvre
- les totaux (htva et tvac)
Un devis ne pourra être encodé que par une personne faisant partie de la catégorie
« poweruser ».
4.4.3.3 Bon de réparation
Le bon de réparation reprend exactement la même structure que le devis à l’exception
prêt qu’il actualise le stock en fonction des pièces utilisées lors de la réparation.
7/20/2004 20
4.4.3.4 Bon de commande
Ce module permet la gestion des commandes concernant les pièces détachées.
Il permet :
- Encodage et modification des commandes
- Permet trois types de commandes différentes : client, réparation et stock.
o Dans le cas du client, le stock sera majoré (lorsque les pièces sont
reçues) puis diminué quand le client sera venu les chercher.
o Dans le cas d’une commande de stock ou de réparation, le stock sera
automatiquement majoré.
Il comporte les données suivantes :
- Coordonnées du client
- Type de commande
- Type d’appareil pour lequel on commande des pièces
- Les pièces et leurs détails sous forme de tableau
4.4.3.5 Bon de livraison
Ce module est différent car il ne fait pas vraiment partie du service après-vente. En
effet, le service après-vente a la tâche de livrer les appareils neufs chez les clients qui
l’ont demandé.
C’est donc par ce module que le personnel encodera et gèrera les différentes livraisons à
faire.
7/20/2004 21
4.4.4 Aperçu des modules secondaires
4.4.4.1 Gestion client
Ce module permet l’encodage des coordonnées d’un client. On peut accéder à ce
module aussi bien depuis le menu principal que depuis un bon. Parmi les fonctionnalités
principales de ce module, nous pouvons noter :
- L’encodage et la modification des informations clients
- La recherche rapide d’un client suivant son nom, son prénom ou sa ville.
- La visualisation globale ou partielle suite à une recherche en forme de
tableau
- L’impression globale ou suivant des critères prédéfinis (nom, ville, code
postal)
4.4.4.2 Gestion stock
Ce module gère le stock des pièces détachées. Il permet :
- L’encodage et la modification de pièces
- La recherche rapide d’une pièce ou d’une famille de pièces
- La visualisation globale complète ou par catégorie
- L’impression globale ou par catégorie
4.4.4.3 Gestion appareil
Petit module qui répertorie les différents types d’appareils utilisés au service après-
vente. Ce module servira de référence dans les bons d’intervention, devis, réparation et
commande.
4.4.4.4 Calendrier
Module affichant un calendrier pouvant être appelé par deux modules principaux
(intervention et livraison). En effet, ce module est un outil de visualisation qui affiche
toutes les interventions ou livraisons planifiées rendant la tâche de déterminer une date
d’intervention ou de livraison beaucoup plus facile.
7/20/2004 22
4.4.4.5 Gestion ordre des interventions
Ce module permet la gestion simple de l’ordre dans lequel les différentes interventions
devront être effectuées. Il offre en quelque sorte la possibilité à chaque technicien
d’optimiser manuellement le trajet de sa tournée.
Les principales fonctionnalités de ce module sont :
- Répartitions des interventions entre les différents techniciens.
- L’affichage dans deux catégories différentes (matin et après-midi) des
interventions pour une date et un technicien donnés.
- La possibilité de modifier l’ordre des interventions pour une date et un
technicien donnés.
4.4.4.6 Recherche
Ce module permet de faire une recherche sur
- un bon en se basant sur le numéro unique
- un client en affichant tous les documents liés à ce client
4.4.4.6 Gestion utilisateur
Ce module est uniquement accessible par l’admin. Ce module permet
l’ajout/modification/suppression d’un utilisateur. Les principales informations sont :
- Les coordonnées de l’utilisateur (nom+prénom)
- La catégorie (user, poweruser, admin)
- Définition ou remise à zéro de son mot de passe
4.4.4.7 Gestion main d’œuvre
Ce module est accessible à tous en mode visualisation. Mais si l’on veut ajouter,
modifier ou supprimer, il faut les droits d’admin. Les principales informations sont :
- Le nom (ou type) de la main d’œuvre (tv, radio, gros blanc, …)
- Le prix au 1/4h (htva)
7/20/2004 23
5 Description de l’analyse
5.1 Méthodologie d’analyse utilisée
La méthode utilisée pour la description de l’analyse de ce projet est la méthode Merise.
Cette méthode permet la réalisation de schémas théoriques de raisonnement sur des
applications utilisant des bases de données relationnelles.
5.2 Aperçu
5.2.1 Le modèle conceptuel de données (MCD)
Le MCD ou modèle entités-associations est l’élément le plus connu de MERISE et
certainement le plus utile. Il permet d’établir une représentation claire des données du
système d’information et définit les dépendances fonctionnelles de ces données entre
elles.
Bien connaître les règles simples des schémas entités-associations (aussi appelés
entités-relations) permet d'affiner petit à petit une application apparemment simple, sans
avoir besoin de la programmer, et par conséquent d'économiser du temps de conception
tout en obtenant une plus grande souplesse au niveau de l'analyse.
Le modèle entités-associations ou MCD est constitué des éléments de base suivants :
5.2.1.1 Classe Entité
Ensemble composé d’entités du même type.
5.2.1.2 Entité
Représentation d’un objet matériel ou immatériel ayant un rôle dans le système décrit.
Chaque entité est composée de propriétés, données élémentaires permettant de la
décrire. Au premier abord, on peut définir l’entité comme étant un regroupement bien
pensé, donc sensé, de plusieurs propriétés.
7/20/2004 24
5.2.1.3 Propriété
Les propriétés sont les caractéristiques décrivant les entités et doivent être représentées
comme une liste de mots, la plus simple possible, dans le cadre de l'entité
correspondante.
5.2.1.4 Identifiant
Un identifiant est un ensemble de propriétés (une ou plusieurs) permettant de désigner
une et une seule entité.
5.2.1.5 Relation
Il s’agit des liaisons entre les entités. Elles peuvent aussi contenir des propriétés.
5.2.1.6 Cardinalité
Les cardinalités permettent de caractériser le lien qui existe entre une unité et la relation
à laquelle elle est reliée. La cardinalité d’une relation est composée d’un couple
comportant une borne maximale et une borne minimale.
5.2.2 Modèle logique des données (MLD)
Il ajoute au MCD la notion d’organisation. Les entités types du MCD sont converties en
table. Selon les cardinalités, les associations types du MLD sont converties en table ou
supprimées.
5.2.3 Modèle conceptuel des traitements (MCT)
Le modèle conceptuel des traitements permet de traiter la dynamique du système
d’information, c’est-à-dire les opérations qui sont réalisées en fonction d’événements.
Il permet donc de représenter de façon schématique l’activité d’un système
d’information sans faire référence à des choix organisationnels ou des moyens
d’exécution, c’est-à-dire qu’il permet de définir simplement ce qui doit être fait.
7/20/2004 25
5.3 Découpes en phases et MCT
Nous allons passer en revue les étapes de trois traitements particuliers de l’application :
- Bon d’intervention
- Bon de commande
- Bon de livraison
Tous ces bons seront gérés depuis leur création jusqu'à leur fermeture.
5.3.1 Bon d’intervention
Scénario 1 : Appareil défectueux ramené au magasin.
1) Un client apporte un appareil à réparer au magasin
2) Création d’un bon d’intervention
3) Encodage des informations client, appareil et défaut
4) Impression d’un document attestant le dépôt de l’appareil
5) Mise de l’appareil dans le local technique en attente de réparation
6) Prise en charge de l’appareil par un technicien pour réparation
7) Création d’un devis si celui-ci a été demandé
8) Création d’un bon de réparation
9) Commande de pièce(s) si cela est nécessaire
10) Réparation de l’appareil et fermeture de bon de réparation
11) Un membre du personnel contacte le client
12) Reprise de l’appareil et fermeture du bon d’intervention
Scénario 2 : Intervention sur site demandée
1) Un client téléphone pour demander une intervention sur site
2) Création d’un bon d’intervention
3) Encodage des informations client, appareil et défaut
4) Choix d’une date de passage
5) Attribution de l’intervention sur site à un technicien
6) Envoi du technicien à la date convenue
7) Réparation de l’appareil sur place
8) Si réparation impossible, reprise de l’appareil au magasin => scénario 1
9) En cas de succès, création d’un bon de réparation par le technicien
10) Fermeture du bon de réparation et du bon d’intervention.
7/20/2004 26
5.3.2 Bon de commande (niveau client)
1) Un client passe une commande de pièces détachées pour un appareil précis
2) Création d’un bon de commande
3) Encodage des informations client, appareil et pièce(s)
4) Traitement des différentes commandes par le responsable des commandes
5) Attente réception des commandes
6) Un membre du personnel contacte le client
7) Le client vient chercher sa marchandise
8) Fermeture du bon de commande
5.3.3 Bon de livraison
1) Un client passe et demande une livraison d’un appareil neuf sur site
2) Création d’un bon de livraison
3) Encodage des informations client et appareil
4) Choix d’une date de passage
5) Attribution de la livraison à un membre du personnel
6) Livraison du matériel
7) En fin de journée, le membre du personnel met à jour le bon de livraison
8) Clôture du bon de livraison en cas de succès.
7/20/2004 27
5.3.1 Symbolique utilisée
Action effectuée
Point d’attente
Décision
Message
Cheminement
7/20/2004 28
5.3.2 Bon d’intervention : Scénario 1
7/20/2004 29
5.3.2 Bon d’intervention : Scénario 2
7/20/2004 30
5.3.3 Bon de commande
7/20/2004 31
5.3.4 Bon de livraison
7/20/2004 32
5.5 MCD
7/20/2004 33
5.6 MLD
7/20/2004 34
5.7 Architecture de la base de données
5.7.1 Dictionnaire des données
Voir annexe
5.7.2 Script de création des tables en SQL
Voir annexe
5.7.3 Modules fonctionnels
Il s’agit des fonctions de base de l’application. Celle-ci ayant dès le début été créée sous
forme de modules, nous pouvons partir de cette organisation pour dégager les aspects
suivants :
Modules principaux
- Login & Menu principal
- Bon d’intervention
- Devis
- Bon de réparation
- Bon de commande
- Bon de livraison
Modules secondaires
- Client
- Appareil
- Stock
- Utilisateur
- Main d’œuvre
- Ordre des interventions
- Calendrier
- Recherche
7/20/2004 35
5.7.4 Noyaux fonctionnels
Cette seconde couche regroupe les fonctions principales de l’application
- Connexion DB : Les fonctions relatives à la connexion à la base de données
- Manipulation : Toutes les fonctions de manipulation des données ;
recherche, ajout, modification, suppression, tri
- Contrôle : Les fonctions de contrôle des données
- Affichage : Les fonctions qui déterminent l’apparence et les menus d’un
module
5.7.5 Interface
On y retrouve 3 modules
- Base de données : Fonctions d’accès à la base de données
- Ecran : Fonctions d’affichage des différents formulaires à l’écran
- Impression : Fonctions d’impression des différents états
o Voir annexe (Utilisation EKRTF)
36
5.7.6 Hiérarchisation
Bon d’intervention Devis Bon de réparation Bon de commande Bon de livraison Client Appareil Stock Ordre des interventions Calendrier
Modules principaux et secondaires
Connect DB Manipulation Contrôle
SGDB
Affichage
OS
Impression
Login et Menu principal Utilisateur, Main d’œuvre
Noyau fonctionnel
Interfaces
Module fonctionnel
Ecran
37
6 Description de l’application
6.1 Présentation générale
L’application est développée en français. Tous les écrans respectent le même design
notamment au niveau du fond, des couleurs ou encore au niveau des sections et des
boutons.
Une solution composée de bouton sans texte avec icône a été choisie par souci de clarté,
et de facilité.
Afin de définir facilement l’emplacement de la base de données, et que cela soit
modifiable sans devoir faire un changement dans le programme, j’ai décidé de créer un
fichier de configuration. Ce fichier appelé « config.ini » reprend ainsi les informations
de l’emplacement de la base de données, ainsi que de nombreux autres paramètres
(tailles des fenêtres et colonnes, …).
A chaque ouverture d’écran, les valeurs du fichier ini sont lues et traitées. De même à
chaque fermeture d’écran, les valeurs sont réécrites dans le fichier ini. Cela permet de
garder les tailles des fenêtres et colonnes que l’on a définies.
Exemple d’une partie du fichier :
[Preference] ip=127.0.0.1 path=E:\Mes Developpements\ERGA - Gestion SAV\Base de donnée\ name=GESTION SAV V5.0.FDB [MenuPR] heigth=567 width=821 Col1=160 Col2=30 Col3=67 Col4=91 Col5=71 Col6=248
38
6.1.1 Dynamique des écrans
Cette application est constituée de plusieurs écrans permettant des cheminements
différents.
39
6.2 Saisies d’écrans et explications
6.2.1 Identification
6.2.1.1 Ecran
40
6.2.1.2 Explication
Le premier écran permet de s’authentifier dans l’application et avoir ainsi accès au
menu principal. En plus de donner le titre et la version du programme, il permet de
changer les paramètres de connexion qui se trouvent dans le fichier ini.
De plus, l’utilisateur peut décider de changer son mot de passe en cliquant sur l’icône
du « cadenas + clé ».
Le second écran permet à l’utilisateur de changer son mot de passe. Cet écran reprend le
même principe que le changement de mot de passe que l’on peut voir dans des
applications comme Windows, Novell, …
Dans le cas présenté, l’utilisateur doit absolument rentrer son nom d’utilisateur et son
mot de passe actuel, ainsi qu’un nouveau mot de passe et une confirmation de ce
dernier.
Si le nom d’utilisateur et le mot de passe actuel sont vérifiés et que le nouveau mot de
passe ainsi que la confirmation sont identiques, alors le mot de passe sera changé.
41
6.2.2 Menu Principal
6.2.2.1.1 Ecran principal
6.2.2.1.2 Ecran nouveau bon
42
6.2.2.2 Explication
Le menu principal est composé d’une barre de boutons située en haut de la fenêtre. Ces
boutons donnent accès aux principaux modules de l’application
Permet de créer un nouveau bon. Appelle la fenêtre 6.2.2.1.2
Permet de modifier un bon existant
Permet de supprimer un bon
Recherche avancée
Gestion de l’ordre des interventions
Gestion client
Gestion stock/article
Gestion appareil
Gestion utilisateurs
Gestion main d’œuvre
Aide
Quitte l’application
En plus de la barre des boutons, le menu est pourvu d’une grille regroupant tous les
bons dont le statut n’est pas « clôturé ». Cette grille permet d’avoir un aperçu rapide de
ce qui est à faire.
43
6.2.3 Gestion client
6.2.3.1 Ecran
6.2.3.2 Explication
Cet écran permet la gestion des clients (encodage, modification ou suppression). Deux
nouvelles icônes sont apparues :
Impression
Exporter : Exporte des données de cet écran vers un autre écran.
Les champs marqués de jaune sont obligatoires. Vous ne pourrez en aucun cas ajouter
ou modifier un enregistrement si ces champs ne sont pas remplis.
Une recherche basée sur trois critères est disponible ainsi qu’un tri.
Le cadre « Affichage client(s) » en haut à gauche permet d’appliquer un filtre. En effet,
on peut mettre un client en mode « inactif », ce qui l’exclu de toutes les recherches.
44
6.2.4 Gestion appareil
6.2.4.1 Ecran
6.2.4.2 Explication
Cet écran est similaire en tout point au fonctionnement de l’écran « Client ».
45
6.2.5 Gestion stock (article)
6.2.5.1 Ecran
6.2.5.2 Explication
Cet écran permet la gestion des différentes pièces utilisées au service après-vente.
Le fonctionnement est assez similaire au module client excepté qu’il n’y a qu’un critère
de recherche basé sur le code article. Un petit module additionnel permettant une
recherche avancée sur plusieurs critères est en cours de réalisation.
Il est aussi possible de choisir une catégorie bien précise qui aura pour effet de
n’afficher que les articles de cette catégorie.
La recherche, le tri et le choix d’une catégorie sont cumulables.
Les quatre champs libellés respectivement « Remplacement 1 à 4 » permettent l’ajout
d’une référence pointant vers une autre pièce. En effet, très souvent une nouvelle pièce
reprenant les caractéristiques de base mais améliorant le comportement ou supprimant
un ou plusieurs défauts vient remplacer la pièce existante.
46
6.2.6 Gestion utilisateur
6.2.6.1 Ecran
6.2.6.2 Explication
Cet écran uniquement accessible par le compte administrateur permet la gestion des
utilisateurs.
Lorsque l’administrateur encode un nouvel utilisateur, il doit lui choisir un code
représentant suivant la méthode décrite précédemment, ainsi que rentrer son nom et son
prénom.
Enfin, il choisira une catégorie en fonction des droits que l’utilisateur peut avoir.
Si l’utilisateur a oublié son mot de passe, c’est également ici que l’administrateur pourra
faire un reset du mot de passe.
47
6.2.7 Main d’oeuvre
6.2.7.1 Ecran
6.2.7.2 Explication
Cet écran permet la gestion des différentes mains-d’œuvre.
Ce module sera accessible à tout le monde en mode exportation de données. Si l’on veut
ajouter ou modifier un type de main-d’œuvre, il faut se logger en tant qu’administrateur.
48
6.2.8 Ordre des interventions
6.2.8.1 Ecran
6.2.8.2 Explication
Cet écran permet la gestion des interventions suivant un jour et un membre du personnel
bien défini. Une fois ces informations choisies, les différentes interventions réparties
entre la matinée et l’après-midi sont affichées.
On peut à ce moment-là sélectionner une intervention et la faire monter ou descendre.
Cela permet de définir l’ordre dans lequel le technicien compte exécuter les
interventions qui lui sont attribuées.
Il ne reste plus qu’à cliquer sur le bouton d’impression afin d’avoir sa feuille de route.
49
6.2.9 Calendrier
6.2.9.1 Ecran
6.2.9.2 Explication
Cet écran permet d’avoir un aperçu du nombre d’interventions déjà planifié sur une
semaine.
Ce module fait exactement la même chose pour les bons de livraison.
50
6.2.10 Bon d’intervention
6.2.10.1 Ecran
6.2.10.2 Explication
Cet écran permet l’encodage et le suivi de toutes les interventions du service après-
vente.
Sauvegarde le document.
Appel du calendrier
Création d’un nouveau devis
Création d’un nouveau bon de réparation
Appel des modules externes (client & appareil dans ce cas-ci).
Les deux zones en bas de l’écran sont des zones d’accès rapide aux devis ou bon de
réparation déjà créés et qui sont liés au bon d’intervention.
51
6.2.11 Devis
6.2.11.1 Ecran
6.2.11.2 Explication
Cet écran permet l’encodage ou la modification d’un devis. Outre les informations
propres au devis en lui-même, il permet d’ajouter/modifier/supprimer une ou plusieurs
pièces provenant du stock
Le tout est calculé dans différents champs
- total de la main d’œuvre
- total des pièces
- total HTVA
- total TVA
- total TVAC
52
6.2.12 Bon de réparation
6.2.12.1 Ecran
6.2.12.2 Explication
Cet écran est en tout point similaire à l’écran « Devis »
53
6.2.13 Bon de commande
6.2.13.1 Ecran
6.2.13.2 Explication
Cet écran permet la gestion des commandes, quelque soit le type. Tout comme l’écran
« Devis » ou « Bon de réparation », il permet d’ajouter/modifier/supprimer une ou
plusieurs pièces provenant du stock
54
6.2.14 Bon de livraison
6.2.14.1 Ecran
6.2.14.2 Explication
Cet écran permet l’encodage/modification des bons de livraisons. Outre les informations
habituelles, on doit sélectionner un client dans la base de données ainsi que définir une
date de passage. Pour ce faire, on pourra s’aider en utilisant le calendrier afin de voir les
livraisons déjà planifiées.
55
7 Le futur
7.1 Ajout de fonctionnalités
7.1.1 Impression
A l’heure actuelle, seuls trois états sont disponibles (intervention, devis et réparation).
La conception des autres états est en cours.
Ces états sont générés par un module externe appelé EKRTF.
Voir annexe pour plus de détails
7.1.2 Gestion ordre livraison
A la base, seule la gestion des interventions avait été demandée. Vu la facilité de
fonctionnement de celle-ci, il m’a été demandé s’il était possible d’inclure dans le
programme une gestion similaire pour les livraisons.
Ce sera donc un nouveau module venant se greffer au module de gestion des
interventions déjà existant.
7.1.3 Système de backup automatisé
Le backup comme dit précédemment est fait tous les jours et ce manuellement. Une
meilleure méthode que celle utilisée actuellement est à l’étude afin de développer un
module ou de trouver un programme tiers pouvant s’occuper de la tâche
automatiquement.
7.1.4 Importation données (Excel => Firebird)
Ce module (interne ou externe) permettra de convertir facilement un fichier au format
Excel vers la base de données Firebird.
Ceci permettra une migration des données actuelles plus facile et rapide.
7.1.5 Aide et documentation
Rédaction d’une aide interne au niveau du programme ainsi que d’une documentation
expliquant l’installation et le fonctionnement de l’application.
56
8 Conclusion La réalisation de ce travail tente de réunir tous les acquis des cours théoriques et
pratiques étudiés tout au long du cycle d’études à l’E.S.A. et d’appliquer ces principes à
un projet réel.
Ce travail aura eu le mérite de m’avoir fait découvrir un monde que je connaissais assez
peu, le développement professionnel. En effet, cette relation client <-> développeur
ainsi que les enjeux (contraintes de temps, de budget, …) en ont fait un challenge de
tous les instants.
Parti de rien, je pense être arrivé à développer une application au fonctionnement simple
et efficace tout en améliorant ostensiblement la gestion du service après-vente.
Néanmoins, et on peut le voir dans la liste des améliorations futures, le chemin est
encore long et cette application subira encore de nombreuses évolutions.
57
9 Bibliographie
9.1 Sites généraux
www.google.com : Site permettant de faire une recherche sur tout et n’importe quoi
www.developpez.com : LE site portail de développement de langue française.
Enormément de tutoriaux ainsi que des forums très riches.
www.docsdunet.com/ : Site portail proposant des articles et des liens très intéressants.
www.borland.com : Site portail de la société Borland (Inprise)
9.2 SQL & Base de données
http://sqlpro.developpez.com/indexSQL.html : LE site de référence en SQL
http://www.aoindustries.com/docs/interbase/SqlRef/SqlRef.html : Site proposant une
explication de chaque commande SQL
http://firebird.sourceforge.net/ : Site Portail de Firebird
www.ibphoenix.com/ : Site portail proposant de nombreux articles concernant Interbase
et Firebird
9.3 Delphi
www.marcocantu.com : Excellent site proposant de nombreux exemples de codes
http://www.techtricks.com/delphi/index.php : Trucs & astuces sur certaines catégories
de composants
9.4 Autres
http://ekrtf.code.net.ru/ : Composant gratuit permettant l’impression sous Delphi
58
10 Annexes
10.1 Installation et configuration de Firebird
10.1.1 Installation
L’installation de Firebird suit le même schéma que toute application standard, à savoir
la lecture d’une licence ainsi que le choix d’un emplacement. Je vais donc m’attarder
sur certains écrans.
10.1.1.1 Composants
Il est recommandé par les développeurs de Firebird de choisir la version « Super Server
binary » pour des raisons de stabilité. En effet la version « Classic Server binary » a été
introduite récemment dans la version 1.5 et doit être regardée comme expérimentale.
59
10.1.1.2 Options
La première option « Use the Guardian » installe un programme résident vous indiquant
l’état de la base de données. Ce programme se loge dans la barre des tâches et est
facilement accessible par simple clic sur le bouton droit.
La seconde option définit Firebird comme étant une application ou un service. Dans le
premier cas, vous devrez démarrer le serveur à la main excepté si vous cochez l’option
« Start Firebird automatically everytime you boot up ».
Dans le second cas, Firebird démarrera en tant que service, très utile dans le cas où on
se trouve sur système NT, car loggé ou pas, le service démarrera toujours.
60
10.1.2 Configuration
Pour configurer une base de données Firebird, je vous conseille d’utiliser le programme
IBExpert (www.ibexpert.com). Une fois IBExpert installé et démarré, il faut aller dans
le menu « Database » puis cliquer sur « Create Database ».
Si l’on travaille au même endroit que la base de données, on peut choisir « Local » dans
l’option « Server ». Si au contraire on décide de créer la base de données sur un serveur
distant, on doit à ce moment là spécifier l’adresse IP pour ce serveur.
Ne pas oublier de :
- choisir le « Dialect SQL » (1 ou 3)
- choisir le « Character set »
- remplir le « Username » et le « Password » qui sont SYSDBA et
MASTERKEY par défaut.
61
10.2 Gestion des verrous
10.2.1 Mais qu’est-ce donc la gestion des verrous ?
Dans une application de ce type, il est très important que deux personnes ne modifient
pas les mêmes données en même temps. Pour ce faire, Firebird depuis la version 1.5 a
introduit une gestion des verrous assez efficace.
10.2.2 Comment ça marche ?
Petit rappel avant de commencer l’explication :
� tout traitement SQL dans Firebird se fait au moyen de transactions.
En ajoutant la commande « WITH LOCK » dans une requête SQL, vous verrouillez
l’enregistrement ou le groupe d’enregistrements sur lequel porte la requête SQL pour
vous seul uniquement et ceci tout au long de la transaction.
10.2.3 Démonstration
IBTransaction1.Active := true; // on ouvre une transaction
IBSQL1.Close;
IBSQL1.SQL.Clear; // on prepare la requête SQL
IBSQL1.SQL.Text := ‘select num_art from article where num_art =1 WITH LOCK';
TRY
DM.IBSQL_STO2.ExecQuery; // on exécute la requête SQL
// Si l’enregistrement n’est pas verrouillé, on peut continuer le traitement
EXCEPT
on E: EDatabaseError do // l’enregistrement est verrouillé, pas de chance
Begin
Showmessage('ATTENTION, quelqu''un est en train de modifier
l''enregistrement. Veuillez réessayer plus tard');
DM.IBSQL_STO2.Close;
DM.IBTR_STO2.Active := False;
End;
END;
62
10.3 Module EKRTF
10.3.1 Explication
La méthode d’impression fut assez dure à trouver. Finalement j’ai jeté mon dévolu sur
un module externe développé par Eugene Kuchugurov (http://ekrtf.code.net.ru/).
Ce module fonctionne de la façon suivante :
- Vous créez un modèle de rapport (avec word par exemple)
- Vous le sauvez en .RTF
- Vous préparez vos données dans votre application (au moyen d’un dataset)
- Vous générez le rapport en utilisant le composant TEKRTF
10.3.2 Exemple
Garantie N° Facture \IBDS_BI: NUMFAC_INT\ Date \IBDS_BI: DATEFAC_INT\
Tout ce qui se trouve entre \ \ sera remplacé par les données venant de votre application.
10.3.3 Code à inclure dans son application
EkRTF1.InFile := 'ModeleIntervention.rtf';
// preparer ses données au moyen d’une requête SQL au moyen d’un dataset
EkRTF1.ExecuteOpen([IBDataset1],SW_SHOW);
BON D’INTERVENTION N° : \IBDS_BI:NUM_INT\
Date : \IBDS_BI:DATECR\
63
10.4 Dictionnaire des données
Nom Alias type I O Descriptif Table
Code Client CODE_CLI
Varchar 32
� � Identifiant client CLIENT
Nom NOM_CLI
Varchar 32
� Nom du client CLIENT
Prénom PRENOM_CLI
Varchar 32
Prénom du client CLIENT
Adresse ADRESSE_CLI
Varchar 64
� Adresse du client CLIENT
Code Postal CP_CLI
Varchar 5
� Code Postal CLIENT
Ville VILLE_CLI
Varchar 32
� Ville où le client habite CLIENT
Téléphone Privé TELPRIV_CLI
Varchar 12
Numéro de téléphone (privé) CLIENT
Téléphone Bureau TELBUR_CLI
Varchar 12
Numéro de téléphone (bureau) CLIENT
Gsm GSM_CLI
Varchar 12
Numéro de gsm CLIENT
Fax FAX_CLI
Varchar 12
Numéro de fax CLIENT
E-mail EMAIL_CLI
Varchar 64
Email CLIENT
TVA TVA_CLI
Varchar 20
� Numéro de TVA du client CLIENT
RaisonSociale RAISON_CLI
Varchar 15
� Raison sociale (Monsieur, Madame, S.A., etc…)
CLIENT
Actif ACTIF_CLI
Char 1
Client actif ? CLIENT
Commentaire COMM_CLI
Varchar 300
Commentaire éventuel CLIENT
Marque MARQUE_APP
Varchar 32
� � Identifient et marque de l’appareil
APPAREIL
Type TYPE_APP
Varchar 20
� � Identifiant et type de l’appareil APPAREIL
Modèle MODELE_APP
Varchar 32
� Modèle de l’appareil APPAREIL
Catégorie CAT_APP
Varchar 13
� Catégorie de l’appareil APPAREIL
Actif ACTIF_APP
Char 1
Appareil actif ? APPAREIL
64
Nom Alias type I O Descriptif Table
NumLiv NUM_LIV
Entier 2
� � Identifiant livraison LIVRAISON
IDType IDTYP
Char 2
� Type de bon LIVRAISON
Date DATECR
Date 8
� Date de création du bon de livraison
LIVRAISON
DateLiv DLIV_LIV
Date 8
� Date de livraison LIVRAISON
HeureLiv HLIV_LIV
Heure 4
� Heure de livraison LIVRAISON
Référence REF_LIV
Varchar 10
� Référence du matériel (facture) LIVRAISON
Description DESCRIP_LIV
Varchar 128
Description du matériel à livrer LIVRAISON
Raison RAISON_LIV
Varchar 128
Commentaire éventuel LIVRAISON
Statut STATUT
Varchar 32
� Statut du bon de livraison LIVRAISON
NumInt NUM_INT
Entier 2
� � Identifiant intervention INTERVENTION
IDType IDTYP
Char 2
� Type du bon INTERVENTION
Date DATECR
Date 8
� Date de création du bon d’intervention
INTERVENTION
NumSérieApp NS_INT
Varchar 32
Numéro de série de l’appareil INTERVENTION
Accessoire ACCES_INT
Varchar 500
Accessoire(s) éventuel(s) INTERVENTION
Emballage ETATEMB_INT
Varchar 64
Emballage (présent, endommagé, etc…)
INTERVENTION
EtatAppareil ETATAPP_INT
Varchar 64
Etat de l’appareil INTERVENTION
Défaut DEFAUT_INT
Varchar 500
� Défaut de l’appareil INTERVENTION
NumFac NUMFAC_INT
Varchar 20
Si garantie => numéro facture INTERVENTION
DateFac DATEFAC_INT
Date 8
Si garantie => date facture INTERVENTION
Devis DEVIS_INT
Char 1
Devis demandé ? INTERVENTION
DateDep DATEDEP_INT
Date 8
Date de l’intervention sur site INTERVENTION
PériodeDep PERIODE_INT
Varchar 10
Période (matin ou après-midi) INTERVENTION
OrdreDep ORDRE_INT
Entier court 1
Ordre intervention sur site INTERVENTION
65
Nom Alias type I O Descriptif Table
TechDep TECH_INT
Char 3
Nom du technicien pour intervention sur site
INTERVENTION
Commentaire COMM_INT
Varchar 300
Commentaire éventuel INTERVENTION
Statut STATUT
Varchar 32
� Statut du bon d’intervention INTERVENTION
CodeRep CODEREP_PER
Char 3
� � Identifiant utilisateur PERSONNEL
Nom NOM_PER
Varchar 32
� Nom de l’utilisateur PERSONNEL
Prenom PRENOM_PER
Varchar 32
� Prénom de l’utilisateur PERSONNEL
Categorie CAT_PER
Varchar 10
� Catégorie à laquelle l’utilisateur appartient
PERSONNEL
Password PASS_PER
Varchar 10
� Mot de passe PERSONNEL
Actif ACTIF_PER
Char 1
Utilisateur actif ? PERSONNEL
PassChange CHANGEPASS_PER
Char 1
Spécifie si l’utilisateur doit changer son mot de passe
PERSONNEL
NumMO NUM_MO
Char 2
� Identifiant main-d’œuvre MO
Désignation DESIGNATION_MO
Varchar 32
� Description de la main-d’œuvre MO
TarifHT TARIFHT_MO
Réel 5,2
Prix hors tva MO
Remarque REMARQUE_MO
Varchar 64
Remarque éventuelle MO
NumCDE NUM_CDE
Entier 2
� � Identifiant commande COMMANDE
IDType IDTYP
Char 2
� Type de bon COMMANDE
Date DATECR
Date 8
� Date de création du bon de commande
COMMANDE
Type TYPE_CDE
Varchar 12
� Type de commande (particulier- réparation – stock)
COMMANDE
Acompte ACC_CDE
Entier 2
Acompte COMMANDE
TVA TVA_CDE
Réel 5,2
Tva du bon de commande COMMANDE
DatePrevenu DPREV_CDE
Date 8
Date à laquelle le client a été prévenu
COMMANDE
Statut STATUT
Varchar 32
� Statut du bon de commande COMMANDE
NumDev NUM_DEV
Entier 2
� � Identifiant devis DEVIS
66
Nom Alias type I O Descriptif Table
IDType IDTYP
Char 2
� Type de bon DEVIS
Date DATECR
Date 8
� Date de création du devis DEVIS
Codeclient CODE_CLI
Varchar 32
� Référence client DEVIS
HeureArrivée HARR_DEV
Heure 4
Heure d’arrivée (en cas de réparation sur site)
DEVIS
HeureDépart HDEP_DEV
Heure 4
Heure de départ (en cas de réparation sur site)
DEVIS
Déplacement DEPLA_DEV
Varchar 4
Déplacement (en cas de réparation sur site)
DEVIS
TVA TVA_DEV
Réel 5,2
TVA du devis DEVIS
Détail DETAIL_DEV
Varchar 500
Détail de la « réparation » DEVIS
Remarque REMARQUE_DEV
Varchar 300
Remarque éventuelle DEVIS
QTMO QTMO
Entier court 1
Quantité de la main-d’œuvre DEVIS
TVAMO TVAMO_DEV
Réel 5,2
Tva de la main-d’œuvre DEVIS
PrixMO PRIXMO_DEV
Réel 5,2
Prix de la main-d’œuvre DEVIS
Etat ETAT_DEV
Varchar 10
Etat du devis (accepté – refusé) DEVIS
Statut STATUT
Varchar 32
� Statut du devis DEVIS
NumRep NUM_REP
Entier 2
� � Identifiant réparation REPARATION
IDType IDTYP
Char 2
� Type de bon REPARATION
Date DATECR
Date 8
� Date de création du bon REPARATION
CodeClient CODE_CLI
Varchar 32
� Référence client REPARATION
HeureArrivée HARR_REP
Heure 4
Heure d’arrivée (en cas de réparation sur site)
REPARATION
HeureDépart HDEP_REP
Heure 4
Heure de départ (en cas de réparation sur site)
REPARATION
Déplacement DEPLA_REP
Char 4
Déplacement (en cas de réparation sur site)
REPARATION
TVA TVA_REP
Réel 5,2
Tva du bon de réparation REPARATION
Détail DETAIL_REP
Varchar 500
Détail de la réparation REPARATION
67
Nom Alias type I O Descriptif Table
Remarque REMARQUE_REP
Varchar 300
Remarque éventuelle REPARATION
QTMO QTMO_REP
Entier Court 1
Quantité de la main-d’œuvre REPARATION
TVAMO TVAMO_REP
Réel 5,2
Tva de la main-d’œuvre REPARATION
PrixMO PRIXMO_REP
Réel 5,2
Prix de la main-d’œuvre REPARATION
Statut STATUT
Varchar 32
� Statut du bon de réparation REPARATION
NumART NUM_ART
Varchar 32
� � Identifiant article ARTICLE
Dénomination DENOM_ART
Varchar 64
Dénomination de l’article ARTICLE
NumCode1 CODE1_ART
Varchar 32
Numéro de code 1 ARTICLE
NumCode2 CODE2_ART
Varchar 32
Numéro de code 2 ARTICLE
NumUsine USINE_ART
Varchar 32
Numéro d’usine ARTICLE
Remplacement1 REMPL1_ART
Varchar 32
Article de substitution 1 ARTICLE
Remplacement2 REMPL2_ART
Varchar 32
Article de substitution 2 ARTICLE
Remplacement3 REMPL3_ART
Varchar 32
Article de substitution 3 ARTICLE
Remplacement4 REMPL4_ART
Varchar 32
Article de substitution 4 ARTICLE
Fournisseur FOURN_ART
Varchar 32
Référence fournisseur ARTICLE
QT QT_ART
Entier 2
� Quantité ARTICLE
PUHTA PUHTA_ART
Réel 5,2
� Prix unitaire hors tva ARTICLE
Utilisation UTIL_ART
Varchar 128
Utilisation possible ARTICLE
Catégorie CAT_ART
Varchar 32
� Catégorie à laquelle appartient l’article
ARTICLE
Commentaire CMT_ART
Varchar 128
Commentaire divers ARTICLE
Localisation LOCAL_ART
Varchar 128
Endroit où se trouve l’article ARTICLE
Actif ACTIF_ART
Char 1
Définir l’état de l’article, actif ou non-actif
ARTICLE
NumPIE NUM_PIE
Entier 2
� � Numéro unique PIECE
68
Nom Alias type I O Descriptif Table
QT QT_PIE
Entier court 1
� Nombre de pièces PIECE
PrixUnitHT PUHT_PIE
Réel 5,2
Prix unitaire hors tva PIECE
DateCD DATECD_PIE
Date 8
Date à laquelle la ou les pièces ont été commandées
PIECE
DateRecue DATEREC_PIE
Date 8
Date à laquelle la ou les pièces ont été reçues
PIECE
Commentaire COMM_PIE
Varchar 128
Commentaire divers PIECE
69
10.5 Script SQL de génération /* ----------------------------------------------------------------------------- Génération d'une base de données pour Borland Interbase - Firebird (4/5/2004 17:15:06) ----------------------------------------------------------------------------- Nom de la base : MLR V5.0 Projet : Gestion SAV Auteur : Pestiaux Didier Date de dernière modification : 4/5/2004 17:06:14 ----------------------------------------------------------------------------- */ /* ----------------------------------------------------------------------------- TABLE : DEVIS -----------------------------------------------------------------------------*/ create table DEVIS ( NUM_DEV INTEGER not null, NUM_INT INTEGER not null, NUM_MO CHAR(2) , CODEREP_PER CHAR(3) , IDTYP CHAR(2) not null, DATECR DATE not null, CODE_CLI VARCHAR(32) not null, HARR_DEV CHAR(4) , HDEP_DEV CHAR(4) , DEPLA_DEV VARCHAR(4) , TVA_DEV FLOAT(5) , DETAIL_DEV VARCHAR(500) , REMARQUE_DEV VARCHAR(300) , QTMO SMALLINT , TVAMO_DEV FLOAT(5) , PRIXMO_DEV CHAR(5) , ETAT_DEV VARCHAR(10) , STATUT VARCHAR(32) not null , constraint PK_DEVIS primary key (NUM_DEV) ); /* ----------------------------------------------------------------------------- INDEX DE LA TABLE DEVIS -----------------------------------------------------------------------------*/ create index I_FK_DEVIS_INTERVENTION on DEVIS (NUM_INT); create index I_FK_DEVIS_MO on DEVIS (NUM_MO); create index I_FK_DEVIS_PERSONNEL on DEVIS (CODEREP_PER);
70
/* ----------------------------------------------------------------------------- TABLE : MO -----------------------------------------------------------------------------*/ create table MO ( NUM_MO CHAR(2) not null, DESIGNATION_MO VARCHAR(32) not null, TARIFHT_MO FLOAT(5) not null, REMARQUE_MO VARCHAR(64) , constraint PK_MO primary key (NUM_MO) ); /* ----------------------------------------------------------------------------- TABLE : COMMANDE -----------------------------------------------------------------------------*/ create table COMMANDE ( NUM_CDE INTEGER not null, MARQUE_APP VARCHAR(32) not null, TYPE_APP VARCHAR(20) not null, CODE_CLI VARCHAR(32) not null, CODEREP_PER CHAR(3) not null, IDTYP CHAR(2) not null, DATECR DATE not null, TYPE_CDE VARCHAR(12) not null, ACC_CDE INTEGER , TVA_CDE FLOAT(5) , DPREV_CDE DATE , STATUT VARCHAR(32) not null , constraint PK_COMMANDE primary key (NUM_CDE) ); /* ----------------------------------------------------------------------------- INDEX DE LA TABLE COMMANDE -----------------------------------------------------------------------------*/ create index I_FK_COMMANDE_APPAREIL on COMMANDE (MARQUE_APP, TYPE_APP); create index I_FK_COMMANDE_CLIENT on COMMANDE (CODE_CLI); create index I_FK_COMMANDE_PERSONNEL on COMMANDE (CODEREP_PER);
71
/* ----------------------------------------------------------------------------- TABLE : INTERVENTION -----------------------------------------------------------------------------*/ create table INTERVENTION ( NUM_INT INTEGER not null, CODEREP_PER CHAR(3) not null, CODE_CLI VARCHAR(32) not null, MARQUE_APP VARCHAR(32) not null, TYPE_APP VARCHAR(20) not null, IDTYP CHAR(2) not null, DATECR DATE not null, NS_INT VARCHAR(32) , ACCES_INT VARCHAR(500) , ETATEMB_INT VARCHAR(64) , ETATAPP_INT VARCHAR(64) , DEFAUT_INT VARCHAR(500) not null, NUMFAC_INT VARCHAR(20) , DATEFAC_INT DATE , DEVIS_INT CHAR(1) , DATEDEP_INT DATE , PERIODE_INT VARCHAR(10) , ORDRE_INT SMALLINT , TECH_INT CHAR(3) , COMM_INT VARCHAR(300) , STATUT VARCHAR(32) not null , constraint PK_INTERVENTION primary key (NUM_INT) ); /* ----------------------------------------------------------------------------- INDEX DE LA TABLE INTERVENTION -----------------------------------------------------------------------------*/ create index I_FK_INTERVENTION_PERSONNEL on INTERVENTION (CODEREP_PER); create index I_FK_INTERVENTION_CLIENT on INTERVENTION (CODE_CLI); create index I_FK_INTERVENTION_APPAREIL on INTERVENTION (MARQUE_APP, TYPE_APP);
72
/* ----------------------------------------------------------------------------- TABLE : APPAREIL -----------------------------------------------------------------------------*/ create table APPAREIL ( MARQUE_APP VARCHAR(32) not null, TYPE_APP VARCHAR(20) not null, MODELE_APP VARCHAR(32) not null, CAT_APP VARCHAR(13) not null, ACTIF_APP CHAR(1) , constraint PK_APPAREIL primary key (MARQUE_APP, TYPE_APP) ); /* ----------------------------------------------------------------------------- TABLE : REPARATION -----------------------------------------------------------------------------*/ create table REPARATION ( NUM_REP INTEGER not null, CODEREP_PER CHAR(3) , NUM_INT INTEGER not null, NUM_MO CHAR(2) , IDTYP CHAR(2) not null, DATECR DATE not null, CODE_CLI VARCHAR(32) not null, HARR_REP DATE , HDEP_REP DATE , DEPLA_REP VARCHAR(4) , TVA_REP FLOAT(5) , DETAIL_REP VARCHAR(500) , REMARQUE_REP VARCHAR(300) , QTMO_REP SMALLINT , TVAMO_REP FLOAT(5) , PRIXMO_REP FLOAT(5) , STATUT VARCHAR(32) not null , constraint PK_REPARATION primary key (NUM_REP) ); /* ----------------------------------------------------------------------------- INDEX DE LA TABLE REPARATION -----------------------------------------------------------------------------*/ create index I_FK_REPARATION_PERSONNEL on REPARATION (CODEREP_PER); create index I_FK_REPARATION_INTERVENTION on REPARATION (NUM_INT); create index I_FK_REPARATION_MO on REPARATION (NUM_MO);
73
/* ----------------------------------------------------------------------------- TABLE : LIVRAISON -----------------------------------------------------------------------------*/ create table LIVRAISON ( NUM_LIV INTEGER not null, CODE_CLI VARCHAR(32) not null, CODEREP_PER CHAR(3) not null, IDTYP CHAR(2) not null, DATECR DATE not null, DLIV_LIV DATE not null, HLIV_LIV DATE not null, REF_LIV VARCHAR(10) not null, DESCRIP_LIV VARCHAR(128) , RAISON_LIV VARCHAR(128) , STATUT VARCHAR(32) not null , constraint PK_LIVRAISON primary key (NUM_LIV) ); /* ----------------------------------------------------------------------------- INDEX DE LA TABLE LIVRAISON -----------------------------------------------------------------------------*/ create index I_FK_LIVRAISON_CLIENT on LIVRAISON (CODE_CLI); create index I_FK_LIVRAISON_PERSONNEL on LIVRAISON (CODEREP_PER); /* ----------------------------------------------------------------------------- TABLE : PERSONNEL -----------------------------------------------------------------------------*/ create table PERSONNEL ( CODEREP_PER CHAR(3) not null, NOM_PER VARCHAR(32) not null, PRENOM_PER VARCHAR(32) not null, CAT_PER VARCHAR(10) not null, PASS_PER VARCHAR(10) not null, ACTIF_PER CHAR(1) , CHANGEPASS_PER CHAR(1) , constraint PK_PERSONNEL primary key (CODEREP_PER) );
74
/* ----------------------------------------------------------------------------- TABLE : CLIENT -----------------------------------------------------------------------------*/ create table CLIENT ( CODE_CLI VARCHAR(32) not null, NOM_CLI VARCHAR(32) not null, PRENOM_CLI VARCHAR(32) , ADRESSE_CLI VARCHAR(64) not null, CP_CLI VARCHAR(5) not null, VILLE_CLI VARCHAR(32) not null, TELPRIV_CLI VARCHAR(12) , TELBUR_CLI VARCHAR(12) , GSM_CLI VARCHAR(12) , FAX_CLI VARCHAR(12) , EMAIL_CLI VARCHAR(64) , TVA_CLI VARCHAR(20) not null, RAISON_CLI VARCHAR(15) not null, ACTIF_CLI CHAR(1) , COMM_CLI VARCHAR(300) , constraint PK_CLIENT primary key (CODE_CLI) ); /* ----------------------------------------------------------------------------- TABLE : PIECE -----------------------------------------------------------------------------*/ create table PIECE ( NUM_PIE INTEGER not null, NUM_CDE INTEGER , NUM_ART VARCHAR(32) not null, NUM_REP INTEGER , NUM_DEV INTEGER , QT_PIE SMALLINT not null, PUHT_PIE FLOAT(5) , DATECD_PIE DATE , DATEREC_PIE DATE , COMM_PIE VARCHAR(128) , constraint PK_PIECE primary key (NUM_PIE) );
75
/* ----------------------------------------------------------------------------- INDEX DE LA TABLE PIECE -----------------------------------------------------------------------------*/ create index I_FK_PIECE_COMMANDE on PIECE (NUM_CDE); create index I_FK_PIECE_ARTICLE on PIECE (NUM_ART); create index I_FK_PIECE_REPARATION on PIECE (NUM_REP); create index I_FK_PIECE_DEVIS on PIECE (NUM_DEV); /* ----------------------------------------------------------------------------- TABLE : ARTICLE -----------------------------------------------------------------------------*/ create table ARTICLE ( NUM_ART VARCHAR(32) not null, DENOM_ART VARCHAR(64) , CODE1_ART VARCHAR(32) , CODE2_ART VARCHAR(32) , USINE_ART VARCHAR(32) , REMPL1_ART VARCHAR(32) , REMPL2_ART VARCHAR(32) , REMPL3_ART VARCHAR(32) , REMPL4_ART VARCHAR(32) , FOURN_ART VARCHAR(32) , QT_ART INTEGER not null, PUHTA_ART FLOAT(5) not null, UTIL_ART VARCHAR(128) , CAT_ART VARCHAR(32) not null, LOCAL_ART VARCHAR(128) , CMT_ART VARCHAR(128) , ACTIF_ART CHAR(1) , constraint PK_ARTICLE primary key (NUM_ART) );
76
/* ----------------------------------------------------------------------------- CREATION DES REFERENCES DE TABLE -----------------------------------------------------------------------------*/ alter table DEVIS add constraint FK_DEVIS_INTERVENTION foreign key (NUM_INT) references INTERVENTION (NUM_INT); alter table DEVIS add constraint FK_DEVIS_MO foreign key (NUM_MO) references MO (NUM_MO); alter table DEVIS add constraint FK_DEVIS_PERSONNEL foreign key (CODEREP_PER) references PERSONNEL (CODEREP_PER); alter table COMMANDE add constraint FK_COMMANDE_APPAREIL foreign key (MARQUE_APP, TYPE_APP) references APPAREIL (MARQUE_APP, TYPE_APP); alter table COMMANDE add constraint FK_COMMANDE_CLIENT foreign key (CODE_CLI) references CLIENT (CODE_CLI); alter table COMMANDE add constraint FK_COMMANDE_PERSONNEL foreign key (CODEREP_PER) references PERSONNEL (CODEREP_PER); alter table INTERVENTION add constraint FK_INTERVENTION_PERSONNEL foreign key (CODEREP_PER) references PERSONNEL (CODEREP_PER); alter table INTERVENTION add constraint FK_INTERVENTION_CLIENT foreign key (CODE_CLI) references CLIENT (CODE_CLI); alter table INTERVENTION add constraint FK_INTERVENTION_APPAREIL foreign key (MARQUE_APP, TYPE_APP) references APPAREIL (MARQUE_APP, TYPE_APP);
77
alter table REPARATION add constraint FK_REPARATION_PERSONNEL foreign key (CODEREP_PER) references PERSONNEL (CODEREP_PER); alter table REPARATION add constraint FK_REPARATION_INTERVENTION foreign key (NUM_INT) references INTERVENTION (NUM_INT); alter table REPARATION add constraint FK_REPARATION_MO foreign key (NUM_MO) references MO (NUM_MO); alter table LIVRAISON add constraint FK_LIVRAISON_CLIENT foreign key (CODE_CLI) references CLIENT (CODE_CLI); alter table LIVRAISON add constraint FK_LIVRAISON_PERSONNEL foreign key (CODEREP_PER) references PERSONNEL (CODEREP_PER); alter table PIECE add constraint FK_PIECE_COMMANDE foreign key (NUM_CDE) references COMMANDE (NUM_CDE); alter table PIECE add constraint FK_PIECE_ARTICLE foreign key (NUM_ART) references ARTICLE (NUM_ART); alter table PIECE add constraint FK_PIECE_REPARATION foreign key (NUM_REP) references REPARATION (NUM_REP); alter table PIECE add constraint FK_PIECE_DEVIS foreign key (NUM_DEV) references DEVIS (NUM_DEV);
78
/* =========== Procédure & générateur pour les compteurs ============= */ CREATE GENERATOR "GEN_PRINCIPAL"; CREATE GENERATOR "GEN_PIECE"; COMMIT WORK; SET AUTODDL OFF; SET TERM ^ ;
CREATE PROCEDURE "PS_PRINCIPAL_NUMID" RETURNS ( "AVALUE" INTEGER ) AS BEGIN EXIT; END ^
CREATE PROCEDURE "PS_PIECE_NUMID" RETURNS ( "AVALUE" INTEGER ) AS BEGIN EXIT; END ^
ALTER PROCEDURE "PS_PRINCIPAL_NUMID" RETURNS ( "AVALUE" INTEGER ) AS begin avalue = gen_id(GEN_PRINCIPAL,1); end ^
ALTER PROCEDURE "PS_PIECE_NUMID" RETURNS ( "AVALUE" INTEGER ) AS begin avalue = gen_id(GEN_PIECE,1); end ^ SET TERM ; ^ COMMIT WORK; SET AUTODDL ON; SET TERM ^ ;
79
/* =========== MODIFICATIONS TYPE DATA ============= */ /* *********** MO Type numeric ************ */ ALTER TABLE MO DROP TARIFHT_MO; ALTER TABLE MO ADD TARIFHT_MO NUMERIC(5,2) NOT NULL; /* *********** DEVIS Type numeric + heure ********* *** */ ALTER TABLE DEVIS DROP TVA_DEV; ALTER TABLE DEVIS ADD TVA_DEV NUMERIC(5,2) NOT NULL; ALTER TABLE DEVIS DROP TVAMO_DEV; ALTER TABLE DEVIS ADD TVAMO_DEV NUMERIC(5,2) NOT NULL; ALTER TABLE DEVIS DROP PRIXMO_DEV; ALTER TABLE DEVIS ADD PRIXMO_DEV NUMERIC(5,2) NOT NULL; ALTER TABLE DEVIS DROP HARR_DEV; ALTER TABLE DEVIS ADD HARR_DEV TIME; ALTER TABLE DEVIS DROP HDEP_DEV; ALTER TABLE DEVIS ADD HDEP_DEV TIME; /* *********** COMMANDE Type numeric ************ * / ALTER TABLE COMMANDE DROP TVA_CDE; ALTER TABLE COMMANDE ADD TVA_CDE NUMERIC(5,2) NOT NULL; /* *********** LIVRAISON Heure ************ */ ALTER TABLE LIVRAISON DROP HLIV_LIV; ALTER TABLE LIVRAISON ADD HLIV_LIV TIME NOT NULL; /* *********** REPARATION Type numeric + heure **** ******** */ ALTER TABLE REPARATION DROP TVA_REP; ALTER TABLE REPARATION ADD TVA_REP NUMERIC(5,2) NOT NULL; ALTER TABLE REPARATION DROP TVAMO_REP; ALTER TABLE REPARATION ADD TVAMO_REP NUMERIC(5,2) NOT NULL; ALTER TABLE REPARATION DROP PRIXMO_REP; ALTER TABLE REPARATION ADD PRIXMO_REP NUMERIC(5,2) NOT NULL; ALTER TABLE REPARATION DROP HARR_REP; ALTER TABLE REPARATION ADD HARR_REP TIME; ALTER TABLE REPARATION DROP HDEP_REP; ALTER TABLE REPARATION ADD HDEP_REP TIME; /* *********** PIECE Type numeric ************ */ ALTER TABLE PIECE DROP PUHT_PIE; ALTER TABLE PIECE ADD PUHT_PIE NUMERIC(5,2) NOT NULL; /* *********** ARTICLE Type numeric ************ */ ALTER TABLE ARTICLE DROP PUHTA_ART; ALTER TABLE ARTICLE ADD PUHTA_ART NUMERIC(5,2) NOT NULL; COMMIT;
80
/* ============ INSERTION DATA OBLIGATOIRE ============= */ /* =========== PERSONNEL ============= */ INSERT INTO "PERSONNEL" ("CODEREP_PER", "NOM_PER", "PRENOM_PER", "CAT_PER", "PASS_PER", "ACTIF_PER") VALUES ('ADM', 'Dieu', 'Tout Puissant', 'admin', 'xxxx', 1); COMMIT; /* =========== ARTICLE ============= */ INSERT INTO "ARTICLE" ("NUM_ART", "DENOM_ART", "CODE1_ART", "CODE2_ART", "USINE_ART", "REMPL1_ART", "REMPL2_ART", "REMPL3_ART", "REMPL4_ART", "FOURN_ART", "QT_ART", "UTIL_ART", "CAT_ART", "LOCAL_ART", "CMT_ART", "ACTIF_ART", "PUHTA_ART") VALUES ('ZZZDIVERS', 'Piece bidon', '', '', '', '', '', '', '', '', 0, '', 'DIVERS', '', '', '1', 0); COMMIT; /* ----------------------------------------------------------------------------- FIN DE GENERATION -----------------------------------------------------------------------------*/
81
11 Table des matières
Remerciements..................................................................................................................1
1 Introduction ..................................................................................................................2
2 Identification du projet ................................................................................................3
2.1 Présentation de la société et fonctionnement......................................................3
2.2 Objectifs.................................................................................................................3
2.3 Principales fonctionnalités demandées................................................................5
2.4 Quels sont les besoins ?.........................................................................................5
2.4.1 Centralisation.................................................................................................5
2.4.2 Utilisation........................................................................................................5
2.4.3 Base de données..............................................................................................6
2.4.4 Performance & Maintenance........................................................................6
2.5 Historique des fonctionnalités et évolutions de l’application ............................6
3 Plate-forme utilisée & architecture réseau................................................................8
3.1 Serveur...................................................................................................................8
3.1.1 Configuration matérielle...............................................................................8
3.1.2 Système d’exploitation...................................................................................8
3.1.3 Sauvegardes et backups.................................................................................8
3.1.4 Sécurité des accès...........................................................................................8
3.2 Client......................................................................................................................9
3.2.1 Configuration matérielle...............................................................................9
3.2.2 Système d’exploitation...................................................................................9
3.3 Architecture réseau.............................................................................................10
3.3.1 Schéma..........................................................................................................10
3.3.2 Description rapide du réseau......................................................................11
3.3.3 Sécurité..........................................................................................................11
3.3.4 Quelques définitions.....................................................................................11
4 Solution proposée.......................................................................................................12
4.1 SGDB....................................................................................................................12
4.1.1 Pourquoi choisir d’abord la base de données ?.........................................12
4.1.2 Contraintes...................................................................................................12
4.1.3 Choix de la base de données........................................................................13
82
4.1.4 Avantages......................................................................................................13
4.1.5 Inconvénients................................................................................................14
4.1.6 Installation et configuration de Firebird...................................................14
4.2 Langage utilisé.....................................................................................................15
4.2.1 Motivation et choix du langage...................................................................15
4.2.2 Avantages du langage..................................................................................15
4.2.3 Inconvénient.................................................................................................16
4.3 Fonctionnalités offertes.......................................................................................17
4.3.1 Gestion de la sécurité...................................................................................17
4.4.2 Schéma général.............................................................................................18
4.4.3 Aperçu des modules principaux..................................................................18
4.4.4 Aperçu des modules secondaires................................................................21
5 Description de l’analyse.............................................................................................23
5.1 Méthodologie d’analyse utilisée.........................................................................23
5.2 Aperçu..................................................................................................................23
5.2.2 Modèle logique des données (MLD)...........................................................24
5.2.3 Modèle conceptuel des traitements (MCT)................................................24
5.3 Découpes en phases et MCT...............................................................................25
5.3.1 Bon d’intervention.......................................................................................25
5.3.2 Bon de commande (niveau client)...............................................................26
5.3.3 Bon de livraison............................................................................................26
5.3.1 Symbolique utilisée......................................................................................27
5.3.2 Bon d’intervention : Scénario 1..................................................................28
5.3.2 Bon d’intervention : Scénario 2..................................................................29
5.3.3 Bon de commande........................................................................................30
5.3.4 Bon de livraison............................................................................................31
5.5 MCD .....................................................................................................................32
5.6 MLD .....................................................................................................................33
5.7 Architecture de la base de données...................................................................34
5.7.1 Dictionnaire des données.............................................................................34
5.7.2 Script de création des tables en SQL..........................................................34
5.7.3 Modules fonctionnels...................................................................................34
5.7.4 Noyaux fonctionnels.....................................................................................35
83
5.7.5 Interface........................................................................................................35
5.7.6 Hiérarchisation.............................................................................................36
6 Description de l’application......................................................................................37
6.1 Présentation générale..........................................................................................37
6.1.1 Dynamique des écrans.................................................................................38
6.2.1 Identification.................................................................................................39
6.2.2 Menu Principal.............................................................................................41
6.2.3 Gestion client................................................................................................43
6.2.4 Gestion appareil...........................................................................................44
6.2.5 Gestion stock (article)..................................................................................45
6.2.6 Gestion utilisateur........................................................................................46
6.2.6 Gestion utilisateur........................................................................................46
6.2.7 Main d’oeuvre..............................................................................................47
6.2.8 Ordre des interventions...............................................................................48
6.2.9 Calendrier.....................................................................................................49
6.2.10 Bon d’intervention.....................................................................................50
6.2.11 Devis............................................................................................................51
6.2.12 Bon de réparation.......................................................................................52
6.2.13 Bon de commande......................................................................................53
6.2.14 Bon de livraison..........................................................................................54
7 Le futur .......................................................................................................................55
7.1 Ajout de fonctionnalités......................................................................................55
7.1.1 Impression.....................................................................................................55
7.1.2 Gestion ordre livraison................................................................................55
7.1.3 Système de backup automatisé...................................................................55
7.1.4 Importation données (Excel => Firebird)..................................................55
7.1.5 Aide et documentation.................................................................................55
8 Conclusion...................................................................................................................56
9 Bibliographie ..............................................................................................................57
9.1 Sites généraux......................................................................................................57
9.2 SQL & Base de données......................................................................................57
9.3 Delphi...................................................................................................................57
9.4 Autres...................................................................................................................57
84
10 Annexes.....................................................................................................................58
10.1 Installation et configuration de Firebird ........................................................58
10.1.1 Installation..................................................................................................58
10.1.2 Configuration.............................................................................................60
10.2 Gestion des verrous...........................................................................................61
10.2.1 Mais qu’est-ce donc la gestion des verrous ?...........................................61
10.2.2 Comment ça marche ?...............................................................................61
10.2.3 Démonstration............................................................................................61
10.3 Module EKRTF.................................................................................................62
10.3.1 Explication..................................................................................................62
10.3.2 Exemple.......................................................................................................62
10.3.3 Code à inclure dans son application.........................................................62
10.4 Dictionnaire des données..................................................................................63
10.5 Script SQL de génération.................................................................................69
11 Table des matières....................................................................................................72