1. Introduction
L'apprentissage d'un environnement de programmation est beaucoup plus aisé
quand on part d’un cas concret. Nous allons donc appliquer les notions d'entités-
relations, de définition d'interface et de programmation objet et événementielle au
développement d’une application professionnelle.
L'exemple choisi est la gestion du facturier de sortie ou du facturier d'entrée d'une
société commerciale. Cette gestion inclut le suivi des paiements et les tâches
d'administration de la TVA.
Dans un premier temps, nous réaliserons une analyse détaillée des données afin
d'établir un modèle entités-relations robuste. Nous verrons ainsi que les structures
des deux facturiers sont très similaires.
Ensuite, nous implémenterons les tables et les formulaires dans Access.
L'étape suivante sera la création d'une interface simple mais ergonomique fait de
formulaires, de sous-formulaires et de listes déroulantes. Ceci impliquera la
rédaction de nombreuses requêtes : requêtes de sélection, de mise à jour, de
regroupement, etc.
Enfin, grâce à des modules VBA, nous reprendrons le contrôle de toutes les
opérations gérées avec plus ou moins de bonheur par Access. L'objectif de cette
étape sera la réalisation d'une application complètement sécurisée destinée à un
utilisateur non averti.
Pour cette étape, nous nous analyserons en profondeur tous les aspects relatifs à la
gestion d’une table.
Il ne s’agit pas d’un simple exercice de style. En effet, nous avons montré que les
traitements à appliquer aux diverses tables d'un projet sont similaires : il s’agit
toujours d’implémenter un CRUD. Dès lors, les formulaires qui gèrent des tables
distinctes ne diffèrent guère que par la zone d'affichage des informations. Il doit
donc être possible de définir une liste type de routines événementielles applicables à
tout formulaire moyennant quelques changements de noms de variables.
Nous en profiterons pour utiliser quelques astuces telles que l'emploi de boutons
transparents, masquage et affichage d'objets en fonction du contexte, etc.
1.1 Application Access
2 - Enoncé du problème
2. Enoncé du problème
2.1. En général
Avant de se lancer dans la conception d'une base de données, il est nécessaire de
bien s'informer auprès du client.
Ce qu'il ne faut jamais faire :
- Croire qu'on connaît le métier du client.
Même si le client possède l'un de ces petits commerces "simples" qui animent
une ville de taille moyenne (tels qu'un service de location de vidéos, un atelier
d'entretien d'automobiles, un restaurant), le cas à traiter présentera toujours
des problèmes spécifiques. Pour les connaître, il n'y a pas d'autre moyen que
de passer du temps avec le futur utilisateur et regarder comment il travaille.
- Imaginer la manière dont les choses se passent.
Chacun a ses propres méthodes d'organisation du travail. La solution que le
développeur utiliserait s'il était à la place du client n'est pas nécessairement celle
que le client à choisi. Pour la connaître, il n'y a pas d'autre moyen que de passer
du temps avec le client et lui poser la question.
- Appliquer une solution livresque.
Ce point rejoint les points précédents. La solution livresque est une bonne base
de travail mais ce n'est pas l'Evangile. Il est permis de l'adapter aux besoins
réels du client. Et pour connaître les besoins réels, il n'y a pas d'autre moyen
que de passer du temps avec le client et discuter avec lui.
- Faire des hypothèses.
S'il est permis de faire des hypothèses pour avancer dans le travail, il faut
cependant toujours les valider avec le client avant de les implémenter dans le
programme. On peut imaginer qu'on paie les fournisseurs par virement; est-ce
vrai ? On peut imaginer que les livraisons se font en un seul lot; est-ce vrai ?
Ce qu'il faut toujours faire :
- discuter avec le client,
- valider toutes les hypothèses et tout le travail déjà fait,
- lui poser cent fois la question : "est-ce toujours ainsi que ça se passe ?", "N'y a-
t-il jamais d'exceptions ?". Il vous répondra sans doute : "Non, mais c'est rare".
Désolé pour vous, concepteur. Même si le cas ne se produit qu'une fois au bout
d'une lune vous devez en tenir compte dans le modèle et la réalisation.
2.2. Notre problème
N'ayant pas de problème spécifique à régler, nous sommes bien obligés d'imaginer
un cas factice. Même si l'énoncé est succinct, il ne nous sera pas interdit de nous
poser les bonnes questions au bon moment.
La société Tubimax s.a. est spécialisée dans le chauffage et l'isolation de maisons
particulières et d'installations industrielles.
Le magasin vend aussi bien des chaudières complètes que des pièces détachées
telles que robinets, vannes et tuyaux divers. L'atelier réalise des montages selon les
plans fournis par les industries clientes et les techniciens effectuent les installations
tant chez les clients privés que sur les sites industriels.
La société s'approvisionne en pièce auprès de divers grossistes. Elle dispose bien
entendu d'un secrétariat bien informatisé qui s'occupe de tous les aspects
2.1 Application Access
2 - Enoncé du problème administratifs.
Celui-ci s'approvisionne en matériel de bureau auprès d'autres
fournisseurs et détaillants.
Jusqu'à présent, le traitement des factures s'effectuait manuellement et de manière
manuscrite. Ce qui pose un gros problème de recopie lorsqu'il s'agit de rédiger les
déclarations trimestrielles à la TVA.
2.2 Application Access
3 - Analyse Entités-Relations
3. Analyse Entités-Relations
3.1. Facturier d’entrée
3.1.1. Factures et fournisseurs
L'entité Fournisseurs regroupe tout ce qui est nécessaire à l’identification du
fournisseur : le nom, l’adresse, etc. Dans Access, les entités sont représentées par
les tables.
N’oublions pas qu’il s’agit aussi de faire le traitement TVA des factures émises par
ce fournisseur (2). Ce traitement dépend du pays dans lequel réside le fournisseur.
Dès lors, pour éviter toute ambiguïté sur la manière d’encoder le nom d’un pays,
nous aurons besoin d'une liste de pays, donc d'une entité ou d'une table Pays.
Dans le même ordre d’idées nous créons une liste des Codes postaux (3).
Evidemment, la listes des codes postaux (et des villes correspondantes) dépend du
pays considéré selon la relation :
Chaque pays héberge un ou plusieurs codes postaux.
Chaque code postal est hébergé par un seul pays.
De leur côté, les codes postaux servent à localiser le fournisseur selon la relation :
Chaque code postal localise un ou plusieurs fournisseurs.
Chaque fournisseur est localisé par un seul code postal.
1 Première question à poser au client : est-ce toujours vrai ? Ou bien certains fournisseurs se regroupent-ils
auprès d'un bureau de factoring ? Si oui, comment est-ce que ça se passe ?
2 Le traitement est-il le même pour toutes les factures et pour tous les fournisseurs ?
3 Il est facile de se procurer de telles listes sur Internet. Il suffit généralement de visiter le site de "La Poste"
de chacun des pays concernés.
3.1 Application Access
3 - Analyse Entités-Relations
Ceci nous amène au schéma suivant :
Fournisseurs
localise
Codes
héberge
Pays
Postaux
émet
Factures
fig. 3.2 Etendre le modèle aux codes postaux
Outre l'en-tête, la facture reprend la liste des articles achetés et des services fournis,
avec leur prix, le taux de TVA appliqué, etc. En bas de page, la facture affiche les
montants dus : montant hors TVA, montant de la TVA, montant TVA comprise.
Lorsqu'on parle de liste d'articles achetés, on admet ipso facto l'existence d'une
table (ou entité) qui reprend l'ensemble des lignes qui figurent sur la facture (1) :
Chaque facture liste une ou plusieurs lignes de facturation.
Chaque ligne de facturation est listée sur une seule facture.
Suivant que la ligne de facturation reprend un article (p.ex.: un robinet), un service
(p.ex.: pose d'un robinet), un bien d'investissement (p.ex.: une chaudière à gaz), le
traitement TVA sera différent.
En fait, la TVA classe les échanges commerciaux dans quatre catégories : les biens,
les services, les marchandises et les investissements. Tous les items mentionnés
sur une facture n'appartiennent pas nécessairement à la même catégorie TVA; de
même tous ne se voient pas appliquer le même taux.
Nous aurons donc besoin d'une table des Catégories de TVA selon la relation :
Chaque ligne est incluse dans une seule catégorie de TVA.
Chaque catégorie de TVA inclut une ou plusieurs lignes.
Fournisseurs
localise
Codes
héberge
Pays
Postaux
émet
Factures
liste
Lignes
regroupe
Categorie
Facturation
TVA
fig. 3.3 Développer la facture
1 La comptabilisation et le taux et le traitement TVA sont-ils identiques pour toutes les lignes ?
3.2 Application Access
3 - Analyse Entités-Relations
3.1.3. Le suivi des paiements
Il est vraisemblable que nous serons amenés à payer des acomptes ou à payer une
facture en plusieurs fois :
Chaque facture est acquitée par un ou plusieurs paiements.
Chaque paiement acquitte une seule facture.
La seconde phrase n'est pas nécessairement vraie. Il se peut que, jusqu'à présent,
nous puissions utiliser un seul paiement pour acquitter plusieurs petites factures du
même fournisseur.
Si c'est le cas, nous nous trouvons devant une relation "plusieurs-plusieurs" qui
exigera la création d'une table pivot intermédiaire. Rien de bien difficile à gérer
mais, en accord avec le client, nous pouvons nous simplifier la vie : pour simplifier le
problème nous posons un choix de gestion (1) : nous décidons que désormais, un
paiement ne pourra acquitter qu'une seule facture.
Tant qu'à gérer les paiements, prenons note aussi du compte financier qui les a
effectués (banque X, banque Y, caisse, carte de crédit, etc.) et du moyen de
paiement utilisé (chèque, virement, versement, espèces, etc.).
Chaque compte financier effectue un ou plusieurs paiements.
Chaque paiement est effectué par un seul compte financier.
Chaque mode de paiement effectue un ou plusieurs paiements.
Chaque paiement est effectué par un seul mode de paiement.
Continuons dans la même voie. Toutes les factures ne sont pas exigibles en même
temps.
Certains fournisseurs offrent des conditions de paiement plus larges,
d'autres sont plus exigeants. Les factures portent des mentions du type :
- payable 30 jours fin de mois
- payable comptant
- payable 30 jours date de facture
Chaque facture affiche une seule condition de paiement.
Chaque condition est affichée une ou plusieurs factures.
Notre modèle a encore gagné quatre tables !
1 D'habitude on fait en sorte que le programme s'adapte aux habitude humaines. Le choix de gestion se
pose quand on demande à l'humain de changer ses habitudes afin de s'adapter au programme et simplifier
un traitement.
Il faut avoir de bonnes raisons pour cela même si les habitudes humaines sont
généralement anti-productives.
3.3 Application Access
3 - Analyse Entités-Relations
Fournisseurs
localise
Codes
héberge
Pays
Postaux
émet
Conditions
Factures
liste
Lignes
regroupe
Categorie
paiement
Facturation
TVA
paie
acquitte
Modes
effectue
Paiements
reçoit
Comptes
Paiement
financiers
fig. 3.4 Introduire le suivi des paiements
3.1.4. Les remises
Que se passe-t-il si le fournisseur accorde une Remise sur le total de facture comme
c'est le cas en période de soldes ?
Chaque facture accorde une ou plusieurs remises.
Chaque remise est accordée par une seule facture.
Remises
accorde
Factures
fig. 3.5 Gérer les remises
3.1.5. La TVA
Périodiquement, l'utilisateur doit renvoyer une déclaration de TVA qui reprend
l'ensemble des factures reçues et émises pendant la période considérée.
L'utilisateur y inscrit les différents montants (total hors TVA, montant de la TVA, ...)
ventilés par catégorie (Biens, services, ...).
... ... ...
3 - Analyse Entités-Relations
En menant l'analyse comme ci-dessus, on s'aperçoit que les deux structures sont
finalement très similaires.
On voit surtout apparaître une table Produits qui était
absente du modèle précédent. C'est elle qui se lie à la table Catégories de TVA.
Les tables Déclarations de TVA et Modes de Paiement ont été déplacées pour
faciliter la lecture du modèle mais les liens sont identiques à ce qu'ils sont dans le
modèle du facturier d'entrée.
Dans la suite du projet, nous développerons principalement le facturier de
sortie car il est un peu plus complexe - et donc un peu plus intéressant - que
le facturier d'entrée.
3.6 Application Access
4 - Hiérarchie des tables
4. Hiérarchie des tables
4.1. Définition
Les règles d'intégrité référentielles expriment dans quelle mesure une entité peut
exister indépendamment d'une autre ou, au contraire, si l'existence de l'une dépend
de l'autre.
Cette règle est définie dans la relation entre les deux entités. Elle est rendue
perceptible par l'emploi des mots "chaque" et "toujours".
Clients reçoit Factures
fig. 4.1 L'intégrité référentielle
Le chiffre I étant
attribué au niveau le plus élevé (le plus prioritaire).
1Même s'il ne s'agit que d'un délai de quelques secondes entre le moment où on encode le client et celui où
on encode sa facture ! Du point de vue de la BdD, pendant ce temps il existe un client sans facture.
4.1 Application Access
4 - Hiérarchie des tables
4.2. Utilité de la hiérarchie
Etablir la hiérarchie du modèle est une tâche essentielle et pourtant souvent
négligée.
La hiérarchie définit :
- un plan de réalisation de la base de données : l'interface des entités prioritaires
(formulaires) doit être réalisée avant l'interface des tables inférieures;
- l'ordre dans lequel on remplit les tables et dans lequel on procède aux tests de
validation;
- l'impact de la destruction d'un enregistrement. Une destruction se propage en
cascade dans toutes les tables liées qui sont situées plus bas dans la hiérarchie.
- quand il convient d'utiliser une liste de choix déroulante et quand il convient
d'utiliser un sous-formulaire.
4.3. Etablir la hiérarchie du modèle
Par définition, les tables les plus prioritaires, celles de niveau I, sont du côté "1" de
toutes les relations auxquelles elles participent. Dans nos deux modèles, facturier
d'entrée et facturier de sortie, il y a six tables de niveau I.
