2.

L'exercice
Cet exemple d'utilisation d'une base de donnée Access va nous permettre de créer la
facturation d'une petite entreprise. Cet exemple est donc théorique puisque des applications
(gestion commerciale, point de vente, ...) sont déjà développées, pour des sommes modiques
(Ciel Gestion commercial revient à 299 € hTVA).

Les desiderata de cette base de donnée sont:

1. Liste des clients

2. Liste des produits
3. Reprise automatique des prix, description, taux TVA de la fiche produit dans la facture
en fonction du code du produit.
4. Possibilité de modifier les prix en cours de facturation
5. Blocages des entrées de nouveaux clients, produits en cours de facturation.
6. Etats, impressions et formulaires d'entrées
7. et d'autres qui vont intervenir en cours de choix de nos contraintes et limitations

Dans la partie "Cours Access avancé", nous ajouterons

la gestion de stock
3. Les sujets abordés
L'exercice va de paire avec la formation Access et termine la première partie du cours
YBET informatique.

Nous verrons au cours des différents parties:

1. Création de tables, choix des champs, contraintes

2. Base de donnée relationnelle.

3. Listes de choix

4. Création des requêtes, champs calculés

5. Création d'un formulaire, sous-formulaire

6. Utilisation des macros de base (menu d'entrée de la facturation)

7. Utilisation de macros et procédures événementielles

. Introduction.
La première partie de cet exercice Access basé sur une facturation va être de
déterminer quelles tables sont à créer, quels champs à utiliser. Bref, c'est la partie la plus
difficile de Microsoft Access puisque les choix de cette partie de l'exercice vont conditionner
tous les développements de notre application de facturation, et même de limiter ou d'étendre
les fonctionnalités de notre base de donnée.
2. Choix des tables Access
Pour cette facturation, nous pourrions utiliser une seule table mais cette solution est
peu pratique. En effet, à chaque ligne de facture (produit vendu), nous devrons remplir tous
les champs: coordonnées du client, date, ... La solution réside dans une base de donnée
relationnelle.

Notre application va rassembler 4 tables qui seront reliées:

1. La table facture va reprendre l'en-tête de facture, soit le numéro, la

date, le client
2. La table Client va reprendre les coordonnées du client

3. La table Contenu facture va reprendre les lignes de la facture, soit les

quantités, prix, taux TVA, ...

4. La table produit reprend notre liste de produits.

Le choix des tables n'est pas du au hasard. Nous pourrions reprendre les tables facture
et client dans une même table. Néanmoins, ceci nous obligerait à retaper les coordonnées du
client à chaque nouvelle facture.

De même, dans le cas où nous tapons à chaque fois la description, prix, ..., nous
pouvons supprimer la table produits. Vous pouvez vous référer au au cours Access en ligne
pour les types de champs et pour les propriétés des champs

3. Choix des champs dans la table facture.

Cette table est la principale de notre exercice Access, c'est le point central de notre
application de facturation. Elle reprend:

1. Numéro de facture
2. Date de la facture

3. Code du client

4. données annexe tel que l'échéance, ... Ces données ne seront pas vues dans cet exercice

5. Types, contraintes et propriétés des champs.

Numéro de facture:

Taille du champ peut être entier long.

Comme le numéro de facture est obligatoire et unique, plusieurs possibilités possibles:

1. null interdit et indexé sans doublons

2. Clé primaire

Le choix portera à conséquence puisque dans le deuxième cas, le numéro sera

automatiquement incrémenté. Par contre, la remise à zéro nécessite la suppression et la
reconstruction du champ

Date facture:

Le format date peut être choisi personnellement, il ne gère que l'affichage.

Par facilitée, choisissons la valeur par défaut comme la date actuelle en sélectionnant la
fonction Access maintenant()

De nouveau, null interdit

L'indexation n'est pas obligatoire, mais conseillée dans certains cas.

Code Client:

Ce champ va reprendre les mêmes contraintes que dans la table client. Par facilité,
sélectionnons la taille à 10 caractères. Je laisse à chacun le soin de créer le masque de saisie
en fonction de sa propre entreprise.

Nous devons autoriser les doublons. Par contre, l'indexation fera gagner du temps dans les
recherches futures.

Null interdit n'est pas obligatoire mais:

. Null interdit et chaîne vide autorisée NON oblige à rentrer un code client correct

. Dans le cas contraire, vous pouvez utiliser un client vide pour une vente comptoir par
exemple.

4. Choix des champs dans la table Clients

La deuxième table va reprendre les coordonnées du client. La liaison avec la table
facture ci-dessus est le code du client. Les propriétés du champ doivent donc être strictement
identiques dans les 2 tables. Vous pouvez donner un nom différent au code client dans chaque
table, mais ce n'est pas conseillé. Ils seront distingués par le nom de la table ultérieurement.
Pour éviter d'encoder 2 codes client pour la même entreprise , le champ code client sera utilisé
comme clé primaire.

Les propriétés des autres champs sont normal, mais vous pouvez imposer que toutes les
coordonnées soient remplies (ou non). Pour éviter 2 codes différents pour le même client,
vous pouvez utiliser le code TVA comme "indexé sans doublon". Dans ce cas, il ne sera pas
possible de rentrer 2 clients différents non assujettis à la TVA. Par contre, vous pouvez
utiliser cette propriété pour le nom du client par exemple.

Vous le voyez, les possibilités de contraintes des champs de la table clients sont
nombreuses, mais chacune imposera des limitations futures.

5. Choix des champs dans la table Contenu facture

Cette table reprend toutes les lignes de la facture. Nous pourrions la relier en
relationnelle à notre table client (par le code client), mais finalement, la relation ne se fait que
vers l'en-tête de facture. Le numéro de la facture va donc servir de relation avec la facture ne
elle-même. Le contenu en lui-même doit obligatoirement reprendre:

1. le code du produit
2. la quantité.

Le choix des autres champs est plus délicat, mais les renseignements obligatoires sur le
document commercial est: le prix unitaire, le taux TVA, la description.

Ces 3 champs peuvent être repris de la table produits directement ou recopiés lors de la
création de la facture de cette table. Si nous reprenons directement les propriétés de la table
produit, un changement de prix dans notre table produit influencera directement l'impression
d'anciennes factures. De plus, il ne sera pas possible de modifier le prix ou la description en
cours de facturation. La solution consiste donc à effectivement créer les champs Prix,
description et taux de TVA. Lors de l'introduction de la ligne de facture, nous utiliserons une
procédure événementielle pour récupérer les données de la table produits par défaut (mais
nous pourrons faire des modifications éventuelles).Changer le prix dans la table produit ne
modifiera pas le prix dans les anciennes factures.

Nous utiliserons des champs calculés pour récupérer le total hors TVA de chaque ligne

D'autres champs peuvent être ajoutés, comme la réduction par ligne.

Attention, l'utilisation du format % pose quelques problèmes, mais vous pouvez

utiliser un format nombre standard avec des contraintes, ou même une liste de choix pour le
taux de TVA. C'est la solution adoptée ici avec une table reprenant les taux de TVA.

6. La table produit
Nous reprenons forcément le champ Code produit, avec des propriétés identiques à celui de la
table

"Contenu facture". Comme le contenu de ce champ doit être unique dans la table et
qu'il doit être indexé, nous allons désigner ce champ comme clé primaire.

Le reste des champs reprend la description, le prix et le taux de TVA. Ceux ci sont
normalement obligatoires.
7. Questions sur cet exercice?
1. Pourquoi avoir utilisé une structure de base de donnée relationnelle dans cet exercice?
2. Quel est l'avantage d'utiliser le champ "Code client" comme clé primaire dans la table
Clients? Pourquoi ne puis-je pas utiliser le numéro de facture comme clé primaire dans
la table "Contenu facture"?

3. Quel intérêt de créer ou non les champs descriptions, prix et taux de TVA dans la table
Access "Contenu facture"?

Dans les propriétés du champ "code produit" de la table "Contenu facture", quelle avantages
(ou défaut) de ne pas rendre le code produit obligatoire?

4. Choix des champs dans la table Clients

La deuxième table va reprendre les coordonnées du client. La liaison avec la table
facture ci-dessus est le code du client. Les propriétés du champ doivent donc être strictement
identiques dans les 2 tables. Vous pouvez donner un nom différent au code client dans chaque
table, mais ce n'est pas conseillé. Ils seront distingués par le nom de la table ultérieurement.
Pour éviter d'encoder 2 codes client pour la même entreprise , le champ code client sera utilisé
comme clé primaire.

Les propriétés des autres champs sont normal, mais vous pouvez imposer que toutes les
coordonnées soient remplies (ou non). Pour éviter 2 codes différents pour le même client,
vous pouvez utiliser le code TVA comme "indexé sans doublon". Dans ce cas, il ne sera pas
possible de rentrer 2 clients différents non assujettis à la TVA. Par contre, vous pouvez
utiliser cette propriété pour le nom du client par exemple.

Vous le voyez, les possibilités de contraintes des champs de la table clients sont
nombreuses, mais chacune imposera des limitations futures.

5. Choix des champs dans la table Contenu facture

Cette table reprend toutes les lignes de la facture. Nous pourrions la relier en
relationnelle à notre table client (par le code client), mais finalement, la relation ne se fait que
vers l'en-tête de facture. Le numéro de la facture va donc servir de relation avec la facture ne
elle-même. Le contenu en lui-même doit obligatoirement reprendre:

3. le code du produit
4. la quantité.

Le choix des autres champs est plus délicat, mais les renseignements obligatoires sur le
document commercial est: le prix unitaire, le taux TVA, la description.

Ces 3 champs peuvent être repris de la table produits directement ou recopiés lors de la
création de la facture de cette table. Si nous reprenons directement les propriétés de la table
produit, un changement de prix dans notre table produit influencera directement l'impression
d'anciennes factures. De plus, il ne sera pas possible de modifier le prix ou la description en
cours de facturation. La solution consiste donc à effectivement créer les champs Prix,
description et taux de TVA. Lors de l'introduction de la ligne de facture, nous utiliserons une
procédure événementielle pour récupérer les données de la table produits par défaut (mais
nous pourrons faire des modifications éventuelles).Changer le prix dans la table produit ne
modifiera pas le prix dans les anciennes factures.

Nous utiliserons des champs calculés pour récupérer le total hors TVA de chaque ligne

D'autres champs peuvent être ajoutés, comme la réduction par ligne.

Attention, l'utilisation du format % pose quelques problèmes, mais vous pouvez

utiliser un format nombre standard avec des contraintes, ou même une liste de choix pour le
taux de TVA. C'est la solution adoptée ici avec une table reprenant les taux de TVA.

6. La table produit
Nous reprenons forcément le champ Code produit, avec des propriétés identiques à
celui de la table"Contenu facture". Comme le contenu de ce champ doit être unique dans la
table et qu'il doit être indexé, nous allons désigner ce champ comme clé primaire.

Le reste des champs reprend la description, le prix et le taux de TVA. Ceux ci sont
normalement obligatoires.

7. Questions sur cet exercice?

4. Pourquoi avoir utilisé une structure de base de donnée relationnelle dans cet exercice?
5. Quel est l'avantage d'utiliser le champ "Code client" comme clé primaire dans la table
Clients? Pourquoi ne puis-je pas utiliser le numéro de facture comme clé primaire dans
la table "Contenu facture"?

6. Quel intérêt de créer ou non les champs descriptions, prix et taux de TVA dans la table
Access "Contenu facture"?

Dans les propriétés du champ "code produit" de la table "Contenu facture", quelle avantages
(ou défaut) de ne pas rendre le code produit obligatoire?

Nous avons créé les champs de notre facturation, avec quelques contraintes. Cette
partie de l'exercice de la formation va utiliser les requêtes Access et les champs calculs.

1. Calcul dans les champs.

Lors de la création de la table "Contenu Facture", nous n'avons pas créé de champ
reprenant le montant total de la ligne. Si ça avait été le cas, nous aurions du utiliser la
condition valeur par défaut et valide si pour garantir le résultat. Pour rappel, un calcul Access
peut se faire dans les requêtes ou dans les formulaires et états. Comme le champ total
(réduction comprise) va être utilisé dans tous les formulaires et états utilisant les données de
"Contenu facture", nous allons utiliser la solution requête.

Créons une requête Access en mode assistant en utilisant la table "Contenu Facture".
Ajoutons le champ calculé
 total: [quantite]*[prix]*(1-[Réduction]/100). Attention si vous avez utilisé des noms
de champs différents. Si le nom du champ de la table comporte des espaces, vous devez
insérer les [ ] manuellement, Access ne les rajoute pas d'office.

2. Visualisation de notre relation.

Par le chapitre du cours sur la création d'une base de donnée relationnelle, nous avons
vu qu'il y a 2 méthodes de travail.

1. Relier 2 tables par une requête. Cette solution est la plus facile, mais n'affiche les
enregistrements que si le champ de liaison existe dans les 2 tables
2. En utilisant un formulaire et un sous formulaire intégré. Cette méthode affiche
toujours quelques chose, mais la présentation des sous formulaire laisse souvent à
désirer.

Nous allons créer une requête relationnelle, non pas pour créer une véritable requête,
mais plutôt pour afficher la structure de notre base de donnée Access. Utilisons le mode
Création et sélectionnons les 4 tables crées au chapitre précédant. Si la relation entre les tables
ne se fait pas, vous pouvez sélectionner le champ dans une table et le glisser avec la souris sur
le champ correspondant de l'autre table. Cette requête que nous appellerons relation va nous
servie de référence pour les exercices futurs.

Un conseil, insérez au moins un champ pour avoir l'accès à cette requête facilement.

3. Question de l'exercice.
 1. Quel intérêt d'utiliser des champs calculés dans la requête plutôt que dans un
formulaire ou dans un état pour cette facturation.

2. Pourquoi ne pas construire notre base de donnée relationnelle à partir des requêtes
Access et préférer les formulaires et états.

Maintenant que nous avons créé la structure de notre facturation, nous allons mettre en
place les formulaires. Cette partie va débuter le formulaire facture de notre exercice Access.

Nous allons créer le formulaire en deux partie, la partie en-tête qui reprend la table
facture et la table client, l'autre qui reprend le contenu de la facture et les produits. Ceci est
conditionné par la pratique, mais aussi par le bon sens. Un utilisateur rentre d'abord le numéro
de facture, date, ... suivi des coordonnées du client avant de rentrer les produits. De plus, dans
notre exercice exemple, il nous font scinder la relation chaînée. Cette première partie du
formulaire reprend la création d'un formulaire et les bases relationnelles.

En effet, nous allons obliger à rentrer un code d'un client existant. A ce stade, nous
allons permettre de double cliquer sur la case code client pour rentrer les coordonnées d'un
client et le reprendre ensuite. Dans Access avancé (le niveau 2 de la formation Access), nous
jouerons sur la sécurité imposant un mot de passe pour encoder de nouveaux clients.

1. Création du formulaire de base.

La première partie de notre formulaire Access va nous permettre d'encoder l'entête de
la facture: numéro, date et code client. Jusqu'ici rien de bien compliqué, sauf que nous allons
modifier le champ "code client" pour en faire une zone de liste modifiable.

Créons notre formulaire en mode assistant, type justifié en sélectionnant la table Facture et
passons en mode modification. Enregistrons-le sous le nom facture

Notre but est de relier sur ce formulaire la table client. Nous allons donc créer dans ce
formulaire Facture un sous formulaire Client.

Comme contenu de notre sous formulaire, sélectionnons la table Client. Comme champ
de liaison, sélectionnons Code client pour chaque table.
La présentation en mode modification semble correcte, pourtant, en affichage, les
coordonnées du client sont en mode tableur. Pas très propre, et surtout obligation d'utiliser les
ascenseurs pour vérifier l'adresse du client, la préférence ira plutôt à un mode ligne de
informations.

La modification de cette apparence est liée au formulaire "Sous formulaire client", pas au
formulaire Facture. Fermons notre formulaire et ouvrons le formulaire client en modification.

Affichons les propriétés du formulaire. Comme affichage par défaut, sélectionnons

Formulaire unique au lieu de feuille de donnée. Le tour est joué.

Puisque nous sommes dans les propriétés du formulaire "Sous formulaire client", modifions
d'autres propriétés. Nous pouvons par exemple empêcher d'utiliser ce formulaire pour rentrer
ou modifier des données. Cette méthode empêche à l'utilisateur de créer directement de
nouveau client ou de modifier des coordonnées existantes.
 Voici déjà une présentation un peu plus agréable.

3. Exercice, créez le formulaire

Comme suite de l'exercice, créez un formulaire Access permettant de rentrer et
modifier les clients. A l'aide de ce formulaire, rentrez quelques clients de votre entreprise.

4. Modification de notre formulaire facturation.

Commençons nos premiers essais dans notre formulaire de facturation. Si nous créons
une nouvelle facture, avec un client existant, ses coordonnées sont automatiquement affichée
dans le sous-formulaire. Par contre, si le code du client n'existe pas, ou si nous ne connaissons
pas le code du client, impossible de corriger ou de rentrer un nouveau client si vous avez
interdit cette possibilité dans le sous formulaire client (comme ci-dessus).
 De nouveau, les choix préalables vont modifier notre manière de travailler. Si nous
autorisons de rentrer de nouveaux clients dans le formulaire facture, nous risquons de recréer
des clients existants, sans compter que nous pouvons interdire de créer de nouveaux clients
sans une vérification de la comptabilité par exemple.

Nous ne pouvons pas non plus rechercher un client existant..

Dans les 2 chapitres suivants, nous allons voire 2 méthodes pour corriger ces
fonctionnalités:

1. List de choix dans le code du client.

2. Double click sur le code client (dans la partie facture) qui fait apparaître le formulaire
client.

Cette dernière possibilité est utilisée en bloquant la liste.

1. Introduction
Dans l'exercice Access précédant, nous avons bloqué la création d'un client en cours de
facturation pour obliger à passer à un autre formulaire. Ceci pose différents problèmes. Le
principale est de ne pas pouvoir rechercher un client (même s'il existe déjà). Nous allons
utiliser une liste de choix liée à une requête pour afficher les codes et les noms de clients
disponibles.

Cette fonction "Zone de liste" pourrait se faire dans la table, mais nous allons l'utiliser
dans cet exercice par le formulaire. Ceci permettra lors du choix du code client d'afficher le
code et le nom du client. Ceci oblige toujours à créer le client dans un formulaire, puisque
c'est un choix de départ de la conception de cette base de donnée facturation.

2. Création de la requête
Dans le formulaire facture, utilisez la boîte à outils pour sélectionner la commande
Zone de liste déroulante (nous pouvions également sélectionner zone de liste).
Sélectionnons "Je veux que la liste déroulante recherche les valeurs dans une table ou une
requête" et sélectionnons notre table client. L'astuce va être de sélectionner le code client et le
nom du client (vos pourriez en sélectionner plus). La case à cocher va nous permettre de
masquer (ou non) la première colonne (le code du client).
Si vous cachez la première colonne, elle
sera automatiquement prise comme
valeur à sauvegarder. Par contre, dans
l'autre cas (ou si vous sélectionnez plus
de 2 champs, vous devez signaler quel
champ doit être utilisé:

Nous allons stocker la valeur dans un

champ. Le tour est joué

Cas d'un seul champ affiché Cas de 2 champs affichés.

Le choix dans la zone de liste influence le code client dans la partie facture et la partie
client. De même, taper le code de client dans la zone facture affiche le nom du client dans la
liste de choix. Par contre, vous n'avez pas d'affichage des coordonnées du client tant qu'un
code client valide n'est pas affiché dans la zone facture.

Cette solution a un léger problème. Nous avons finalement un double emploi entre le
code de la liste de choix et celle du formulaire au niveau facture. Si nous supprimons le
champ code client (de la table facture), nous supprimons également la relation entre les 2
tables.

Ceci est lié au choix de stocker dans un champ plutôt que de mémoriser:

Dans ce cas, il nous suffisait de supprimer le code client et de définir dans le formulaire
ce nouveau champ comme "code client" de la table facture dans les propriétés de la zone
modifiable.
 La prochaine étape va être de permettre via un autre formulaire de créer un client
existant. Pour cela, nous passerons par une macro et une procédure événementielle.

3. Formulaire client.
Une autre solution serait de créer un bouton avec une macro pour afficher le formulaire
client créé précédemment (ou un autre puisque client permet de rentrer de nouveaux client ou
de modifier les coordonnées des clients existants).

Reprenons notre formulaire de facturation et insérons un bouton de commande.

Comme macro associée, sélectionnons "Opération sur formulaire, ouvrir un formulaire".
Sélectionnons le formulaire client (nous ne créons donc pas un formulaire spécifique). Dans
cette méthode, il faudra néanmoins rentrer le code du client manuellement, sans compter que
le code d'un nouveau client sera refusé dans la facturation tant que le formulaire ne sera pas
rafraîchi (en gros quitter le formulaire et le rouvrir) Même si ce n'est pas la méthode la plus
adéquate, elle a le mérite d'exister. La méthode suivante va corriger cela par l'utilisation d'une
véritable macro et d'une procédure événementielle.