Schéma relationnel : Gestion client: suivi/devis/facture

sarah33

XLDnaute Junior
Bonjour,

Je me décide de créer une application pour Photographe.

Tout d'abord quelques explications sur mes tables:
Client: est une société
Contact: est une personne qui appartient à une société
Échanges: est une table qui permet de tracer les échanges avec des Contacts, et donc des sociétés.
Devis: Des devis sont adressé à des clients.
Si l'état du devis est accepté, on déclenche un Ordre de travail.
Dans lequel, on trouve: les livrables et la facture.
Les livrables, sont les photos rendues aux clients.
La facturation est la dernière étape.

Tout d'abord que pensez vous de ces relations?
Ensuite, stocker beaucoup de photos très gourmandes en espace (Go) sur le disque dur via Access est une bonne idée?

Merci pour vos retours.

Sarah
 

Pièces jointes

  • schéma.jpg
    schéma.jpg
    19.7 KB · Affichages: 1 372
  • schéma.jpg
    schéma.jpg
    19.7 KB · Affichages: 809
  • schéma.jpg
    schéma.jpg
    19.7 KB · Affichages: 798

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonjour

Globalement l'approche parait OK mais :

  • Il semble y avoir des champs multivalués. Même si les nouvelles versions le permettent, ce n'est pas conseillé car difficilement exploitable
  • Les documents ne doivent pas être stockés dans la base : même en GED On ne ne le fait pas.
    Cela bouffe les performances.
    Prévoir une arborescence de stockage et gérer les chemins d'accès.
  • les relations doivent être déclarées avec intégrité référentielles sinon c'est peu exploitable et il devient facile de polluer la base.
 

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Hello Chris !

Merci pour ton retour.

Peux-tu m'en dire un peu plus sur les champs qui semblent multivalués?
Au niveau des document, ok je ne les stockerai pas dans Access, mais avec une arborescence bien définie sur mon Disque dur. Cependant, au niveau des champs, j'enlève donc le type de données de ces champs "Pièce jointe" pour "lien hypertexte"?

Merci d'avance!

Sarah
 
Dernière édition:

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Re

Multivalué : partout où il y a des + c'est qu'il y a N éléments.

Si ce sont juste des liens vers des documents et que tu ne requêtes jamais dessus, tu peux les laisser mais sinon il est difficile d'utiliser ces éléments : un table annexe avec des dates et autre infos liées au document permet un accès plus simple.

Je vois que tu as mis domaines d'activités au pluriel : si tu comptes en mettre plusieurs dans un même champ, tu auras la même difficulté pour exploiter cette info.

Pour les documents : lien hypertexte est OK a priori.

Sinon en regardant de plus près je vois que tu as inversé l'aspect clé étrangère :
  • dans échanges on doit retrouver le code contact et non l'inverse
  • dans contact on doit retrouver le code client et non l'inverse
  • etc
 

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonsoir Chris,

Merci pour ton aide.

Concernant les champs multivalués. Il s'agissait enfaite des champs avec en valeur de données "pièce jointe".
Je les ai donc remplacé par des valeurs de données "hypertexte".

Mais si j'ai bien compris, l'idéal serait de créer une table "Document", avec un champs Document avec comme valeur de données le lien hypertexte, un autre champs Date, et un autre champs Type de document. Et mettre en relation cette table, avec toutes celles qui nécessitent un lien hypertexte vers un document?

Concernant les domaines d'activité, en effet, il peut y en avoir plusieurs.
Du coup, je me suis rendue compte également que dans la table "Devis" il y avait "ServiceS" qui lui aussi nécessite une nouvelle table.
Il y aura un nombre limité de domaines d'activités et de services... que je réutiliserai pour chaque devis et chaque client...
Un client peut avoir plusieurs Domaines d'activités, un Devis peut contenir plusieurs services....
J'ai donc créée ces deux tables, sans intégrité référentielle...
Est-ce la bonne méthode?



J'ai également coché: "intégrité référentielle"; "mise à jour en cascade"; "effacement en cascade"... pour l'ensemble des autres relations.

En pièce jointe, le nouveau schéma relationnel.

Si tout paraît ok, je passe à la phase Formulaires / Requêtes... d'ailleurs, à ce sujet, il vaut mieux commencer par les Requêtes ou les Formulaires?
 

Pièces jointes

  • schéma.jpg
    schéma.jpg
    27.2 KB · Affichages: 688
  • schéma.jpg
    schéma.jpg
    27.2 KB · Affichages: 607
  • schéma.jpg
    schéma.jpg
    27.2 KB · Affichages: 1 200
Dernière édition:

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonjour

Il faut distinguer 2 choses :
  • la liste des domaines d'activité qui est une table de référence
  • la tables des domaines des clients qui est une table de jointure entre clients et domaines et qui a comme clé primaire la combinatoire N° client+ID domaine.
  • La tables des domaines des clients (N) est en relation avec
    • la table de référence(1) avec intégrité référentielle
    • la table des clients (1) avec intégrité référentielle
  • il faut remplir le table de référence avant de saisir les clients.
  • dans la structure de la table des domaines des clients on peut indiquer que le champ domaine est contrôle par le table de référence et qu'il y a une liste déroulante.
    Ainsi quand tu crées les formulaires, les listes déroulantes et le contrôle est en place

Il y a la même logique pour les services. De façon générale, on distingue pour les devis et/ou factures la table des devis (ou factures) où figurent les infos n'existant qu'une fois, de la table des lignes de devis ((ou factures) ou figurent les infos de la ou des lignes. (Prix U, qté notamment).

Toutes les relations doivent être de 1 à N avec intégrité et sans mise à jour en cascade. Sauf Access permet cela, pas les gros SGBD et dans une appli "officielle" (facturation), tu risques d'être hors la loi puisque cette option autorise de modifier des identifiants.

Pour l'ordre requêtes ou formulaire, globalement c'est formulaires d'abord amis il faut d'abord : lister toutes les interfaces nécessaires, celles qui servent à la saisie, celles qui servent à la consultation simple ou basée sur une analyse plus poussée, puis les documents d'exploitation (états).

Les formulaires de saisie ne nécessitent pas de requêtes, ou éventuellement intégrées à certains champs.
Les requêtes alimentent surtout les états et, selon les besoins, certaines interfaces de consultations.

L'idée d'une table documents est effectivement une piste : bien approfondir les besoins, les documents concernés avant de trancher.
 

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonjour,

Merci pour cette réponse très complète.

Donc j'ai mis à jour le schéma relationnel de la BD, selon tes conseils: voir pièce jointe. (sauf pour la table document, car je n'ai pas encore tranché).

J'ai utilisé des listes déroulantes pour services & domaines dans les tables de jointure avec pour source la table ou ils sont listées.

J'ai supprimé "mise à jour en cascade" et "effacement en cascade" de toutes les relations, comme ça pas de prob (meme si ce n'est pas une appli officielle.)

Concernant la table Facture... selon moi elle n'a pas besoin d'être liée à Services, étant donnée qu'une facture est créé à partir d'un devis. Mais je me trompe peut être?

Je vais donc lister l'ensemble des interfaces nécessaires pour la création des formulaires, et reviendrai très probablement en cas de doute.

A plus tard !! ;)

Sarah
 

Pièces jointes

  • schéma.jpg
    schéma.jpg
    49.4 KB · Affichages: 2 200
  • schéma.jpg
    schéma.jpg
    49.4 KB · Affichages: 1 232
  • schéma.jpg
    schéma.jpg
    49.4 KB · Affichages: 1 491

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonjour

Si la facture est toujours le reflet du devis c'est OK mais si on est amené à facturer en plusieurs fois ou si un service n'est pas dispo...
A vérifier d'auant que tu lies Factures à OT et non devis et qu'il semble y avoir plusieurs OT par devis.

Des commentaires un peu partout : est-ce utile ?

Concernant l'OT c'est un peu ambigu : concrètement on a un devis avec n services. L'OT est-il lié au devis ou à chaque service commandé ? Tout est-il livré à chaque fois ?

Souvent dans les sytèmes de gestion commerciale professionnels on a une table des devis avec sa table lignes de devis et une table des factures et sa table lignes de factures et il y a des possibilités de pré-remplir la facture en reflet d'un devis mais d'y enlever ou ajouter des lignes.
Ici l'OT ajoute une notion de production à la gestion commerciale.

Il faut donc bien mettre à plat les façons dont à partir d'une ou n demandes client on passe par devis, fabrication, facturation...
 

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Hello Chris,

Merci pour l'intérêt que tu portes à mon projet.

En effet, il est possible de facturer une prestation en plusieurs fois... ce qui peut entrainer le cas où se présente 1devis pour plusieurs factures. Donc je vais insérer la notion de services tel que je l'ai fait pour la table Devis.

Concernant les OT. C'est vrai que c'est un peu ambigu.
Je vais essayé d'expliquer le fond de mon raisonnement:

Les services sont: prise de photo, tournage de film, montage vidéo, retouche photo, impression photo. etc.. (en gros)

J'édite des devis à mes clients (nous sommes dans de la prestation de SERVICE: photographie / Vidéo). Lorsqu'un client accepte, je transforme mon Devis en OT.
Il y a deux phases dans l'OT: la phase avant la prestation qui me permet de planifier la mission.
Et la phase lorsque la prestation est terminée: les livrables, le bon de livraison (peut être mal exprimé: un document que je fais signé par mes clients en fin de prestation, attestent mon passage et la réalisation de la prestation.)

Lorsque les deux phases de l'OT sont exécutées, je passe alors à la Facturation.
En me relisant, je me dis que un OT = un jour de prestation, et que si un Devis contient plusieurs jours de prestations, alors il y aura plusieurs OT... hummm comment faire? l'idéal aurait été de pouvoir créer plusieurs jours de prestations a l'intérieur d'un seul OT.

Que penses tu de ma démarche? (probablement maladroite) Peut être que je vais renommer OT en Prestation plutot.

Je vais rectifier déjà la partie Facturation en attendant de voir les éventuelles rectifications de l'OT.

Encore merci,

A plus tard.

Sarah
 
Dernière édition:

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Coucou,

Alors, j'ai un peu édité ma base de données =)

Tout d'abord, j'ai enlevé les champs Document de mes tables (dont les valeurs de données étaient Hypertexte), et j'ai créée la table Documents dont le champs Document renvoi vers un lien Hypertexte.
Je trouve que c'est plus clair, car ça me fait moins de champs par table, et je pense que ça me permettra en effet de mieux trier et retrouver mes documents.

Ensuite, par rapport à la table facturation, je l'ai reliée à la table Services (qui et déjà reliée à la table devis pour un usage identique): est-ce correct? ou faut-il en créer une nouvelle (identique)? ça sent la source d'erreur... mais j'attends l'avis d'experts.

J'ai une question d'ordre général, faut-il créer des champs pour: Montant total TTC ; Montant total HT bien que ces données soient calculées à partir d'autres champs (Services/Prix) ?

J'ai également rajouter la table Paiement Client, pour suivre le paiement des factures par les clients.

Ma problématique reste cette fameuse et douloureuse table Ordre de travail... (en relisant mon précédent message, je me rend compte à quel point ce n'est pas clair) je tente à nouveau:

Cette étape correspond à l'étape entre La création du devis et la création de la facture: elle sert à planifier la mission à réaliser (qui peut se réaliser sur plusieurs jours), y a ajouter des documents nécessaires à la mission (un zoom sur le besoin client par exemple, etc...). Puis, à la finalisation de la mission: le livrable (montage photo), le bon de livraison, qui attestent que la mission s'est bien déroulée.

En l'état, j'ai l'impression que cette table ne marchera pas comme je le souhaite, ne serait-ce simplement que par le fait qu'une mission peut s'étaler sur plusieurs jours, et qu'il n'y a qu'un champs Date dans cette table.
J'imagine donc qu'il faille diviser cette étape, en plusieurs étape, et chaque étape en plusieurs tables..... mais avant de partir dans l'usine à gaz, j'attends vos avis !!

Merci à vous, et a plus tard!!

Sarah
 

Pièces jointes

  • schéma.jpg
    schéma.jpg
    25.5 KB · Affichages: 499
  • schéma.jpg
    schéma.jpg
    25.5 KB · Affichages: 451
  • schéma.jpg
    schéma.jpg
    25.5 KB · Affichages: 521

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonjour

Pour moi les lignes de devis et les lignes de factures (que tu appelles services) sont disjointes dans la mesure où la facture n'est pas le reflet exact du devis dans 100% des cas.

Tu peux par contre imaginer une transformation de devis en facture en partant d'un formulaire affichant un devis où tu cocherais les lignes à facturer avec un code qui générerait le formulaire de facturation pré-rempli de ces données.

Concernant les prix unitaires, il y a 2 écoles :
  • soit on stocke le prix dans la table de liste de services et dans ce cas il évolue au fil du temps et il faut garder dans les lignes de devis et factures le prix en vigueur au moment de la prestation car sinon on ne sait le retrouver
  • soit on a une table des prix avec code service prix et date début de validité +, éventuellement, fin de validité. Cela permet de préparer les prix à l'avance et de ne pas stocker le prix dans les lignes de factures puisqu'on sait le retrouver.
Pour les Totaux HT et TVA, remise, on sait en général les reconstituer mais les conserver facilite l'exploitation statistique basée sur le CA ou le suivi des paiement en évitant de tout recalculer.

Pour les OT : c'est l'organisation interne qui doit permettre l'analyse. De quoi a-t-on besoin pour réaliser la mission ?
Quelle traçabilité est nécessaire.
Si on doit suivre précisément chaque étape alors il y a bien un OT et sa "sous-table" des étapes de fabrication.

Si un OT se référant à un devis suffit à travailler on peut simplifier...

L'analyse et la modélisation dans Access est une bonne démarche mais avant de réaliser, selon le volume à traiter, le nombre de personnes utilisant la base, peut-être faut-il voir en parallèle si une logiciel du marché ne répondrait pas à tes besoins. Il en existe à des prix abordables, paramétrables...
 

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Hello Chris,

J'ai donc ajouter un table Contrat et sa sous table liste contrat, dans le but de joindre à mes devis des contrats à la carte.
Ensuite, j'ai créée les tables lignes_facture et ligne_devis, dans lesquelles sont stockées les Prix HT et TVA. Ils sont reliés à liste services.

Petite question concernant les tables Devis et Facture, dois-je stocké dans un nouveau champs le montant Total TVA et HT ? ou avec les lignes, ça suffit?

Ducoup j'ai fait sauter la Table OT. En contrepartie, j'ai créée une table Date intervention, pour pouvoir planifier les prestations. En attendant, s'il y a des documents à joindre à l'intervention, je les regrouperai dans Devis, et je ferai peut être évoluer la table Date prestation si le besoin se fait pour pouvoir y joindre des documents.

Qu'en penses tu?

Merci!!

Sarah
 

Pièces jointes

  • schéma.jpg
    schéma.jpg
    31.6 KB · Affichages: 308
  • schéma.jpg
    schéma.jpg
    31.6 KB · Affichages: 330
  • schéma.jpg
    schéma.jpg
    31.6 KB · Affichages: 337

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonjour

Pour le prix total dans devis et factures, cela dépend de l'exploitation comme indiqué dans mon précédent post : souvent on établit des statistiques de CA où on fait un suivi de trésorerie et les requêtes sont plus rapides si on n'a pas à reconstituer à partir des lignes.

Selon les volumes le temps peut être très différent et les requêtes étant très gourmandes en ressources cela peut également gêner les utilisateurs : donc la volumétrie guide le choix.

Tu n'a pas prévu de quantité pour les lignes : on ne vend toujours qu'un produit/service par ligne ?

Ta clé document = ta clé facture ou devis : peux-tu préciser ce que tu mettras dans documents au fil du processus.
 

sarah33

XLDnaute Junior
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Bonsoir,

Dans la table Documents, j'envisageais de mettre plusieurs type de document:
* Documents PDF (dans les tables Facture et Devis): devis format PDF et Facture format PDF
* Les livrables: photos, vidéo etc.
* Les document de la prestation: bon de passage, etc.
Le tout en lien hypertexte.
La nature du document est défini par la table Nature de Document.

Niveau utilisateurs, il y en aura très peu: maximum 3 personnes (rarement simultanés), cette application est destinée à une TPE, j'essaie de me faire une appli évolutive pour mon activité, et je serai la principale utilisatrice.

Si le dernier champs des tables Facture et Devis est bien "Quantité".
J'ai utilisé la même table "Services" pour y stocker le descriptif des services / prix qui seront réutiliser dans les tables Devis / Facture.

J'ai donc ajouté Total HT et Total TVA à Devis et Facture.

Pour suivre le paiement de mes factures, et ce que me doivent les clients, me conseilles-tu de rajouter un champs: Restant du dans la table Facture ou alors ce sera une requête?
 

Pièces jointes

  • schéma.jpg
    schéma.jpg
    29.9 KB · Affichages: 283
  • schéma.jpg
    schéma.jpg
    29.9 KB · Affichages: 358
  • schéma.jpg
    schéma.jpg
    29.9 KB · Affichages: 391
Dernière édition:

chris

XLDnaute Barbatruc
Re : Schéma relationnel : Gestion client: suivi/devis/facture

Re

Non "restant du" se calcule à la volée par requête.

Sorry je n'avais pas vu quantité. C'est OK.

Pour les documents je mettrais un ID propre à cette table et un champ supplémentaire pour le numéro de facture ou devis ou autre, car si il y a un PDF par facture et 1 par devis, tu auras plusieurs livrables par devis ou facture et ils ne sont sans doute pas eux-même numérotés, idem pour les autres documents...
 

Discussions similaires

Statistiques des forums

Discussions
312 211
Messages
2 086 292
Membres
103 171
dernier inscrit
clemm