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

[sarah33]

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

 

[sarah33]

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

Re,

Si j'ai bien compris, je met 3 clé primaires sur la table Doc, la troisième étant un n°dédié au doc ?

 

[chris]

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

Re

Le numéro auto suffit, d'autant que certains documents n'auront pas d'autre numéro je pense...

 

[sarah33]

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

Bonjour,

enfaite je me suis un peu embrouillée

Le champs 1 = N° auto + clé primaire
Le champs 2 = N° NAture doc + clé primaire
Je laisse quand même un champs 3 n° de doc? sans clé primaire, mais en n° auto?

merci

 

[chris]

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

Bonjour

Non un numéro auto en clé primaire seulement.
Le nuléro de facture ou devis est celui de la facture ou du devis donc pas auto.

Ja vais quand même re réfléchir à cette table car l'intégrité référentielle ne marchera pas avec plusieurs tables côté 1.

Je te dirais...

 

[sarah33]

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

Hello Chris,

Oki, je te joins mon fichier, car c'est toujours plus parlant que des photos... au cas ou.
De mon côté, je commence à dessiner mes pages pour les formulaires, en attendant de cloturer la partie schéma relationnel.

A plus tard, et encore merci !

Sarah

 

[sarah33]

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

Bonsoir,

Le précédent point sur la table document m'a amené à revoir l'attribution des valeurs de données NumAuto et donc des clées primaires. En effet, sur ma précédente base, je m'étais embrouillée.

Voici mes champs num auto:
* Table Echanges : N°Echange
* Table Contact: N°Contact
* Table Client: N°Client
* Table Liste Domaine d'activité : N°Domaine d'Activité
* Table Devis: N°Devis
* Table Date Intervention: N°Date_Inter
* Table Liste Contrats: N°Contrat
* Table Lignes_Devis: N°Ligne_Devis
* Table Liste Services: N°Service
* Table Document: N°Document
* Table Liste Document: N°Nature_Document
* Table Lignes_Facture: N°LigneFacture
* Table Facture: N°Facture
* Table Paiement Client: N°Paiement

Grossomodo, j'ai un peu changée la structure des tables Lignes Facture, Ligne Devis, et Document.

EDIT: pour la table Document, j'ai ajouté 2 champs N° DEVIS et N° FActure... je me rend compte que c'est faux, car lors de la création d'un nouvel article, il sera alors demandé obligatoirement et un n°Devis et un N°Facture...Cependant, il y aura soit l'un soit l'autre, mais pas les 2... donc, je repars au point de départ avec cette table document !

Une solution pourrait être de créer une table Document pour chaque table nécessitant un document. Et chaque table Document lié à la table Nature de document (pour retrouver facilement) ? Dans Nature de document on pourrait imaginer un champs multiple permettant de dire à quelle table Document, un document(Nature de document) est autorisé.

Pour les tables Lignes, par contre, je sais pas si c'est juste ou pas ma modification.


Qu'en penses-tu?

 

[sarah33]

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

Voici le schéma corrigé, avec 2 tables Document (pour chaque table qui a besoin de document liés)

 

[chris]

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

Bonjour

Je regarde cela ce week end, car fin de semaine chargée...

 

[sarah33]

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

Hello Chris, le forum,

Je me permet de remonter mon poste, car je n'ose pas trop bosser mes formulaires temps que je ne suis pas sur de la "justesse" de mes relations.

Pensez vous que les relations avec les tables Documents_Devis et Document_Factures sont bonnes?
à savoir que je souhaite stocker des liens hypertexts pour classer mes documents à chaque fois?

MErci d'avance.

sarah

 

[chris]

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

Bonsoir

C'est un peu la course en ce moment et en ce type d'analyse demande un peu de calme et réflexion.

J'aurais un peu plus de temps demain pour m'y replonger.

 

[sarah33]

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

Hello,

Loin de moi l'idée de presser, je pensais juste voir été oubliée hihihii
PRends ton temps pour me répondre !!

A bientôt

Sarah

 

[chris]

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

Bonjour

Concernant les lignes devis (et facture), on utilise généralement une clé combinant N° de devis+N° de ligne. Principe : devis 0001, ligne 1 puis devis 0001 ligne 2 et recommence à 1 sur chaque devis.
On n'utilise donc pas de numéro auto. En tous cas ne pas inclure type service dans le clé.
Cela peut aussi éventuellement s'appliquer au paiement.
Mais il est vrai que le numéro auto simplifie la mise en œuvre informatique...

Pour les tables de référence, types de service, type nature de documents, domaines d'activité, etc., on peut utiliser des codifications sous formes de texte (plus mnémotechnique) sur 10 caractères maxi.

Dans certains cas il te faudra définir en plus des clés, des index uniques car les clés type numéro auto ne garantissent pas l'absence de doublons. Exemple : pas le même type de contact avec la même personne à la même date, idem pour les interventions peut-être.
Pour les documents, je ne mettrais pas la nature dans la clé mais un index interdisant éventuellement plusieurs natures identiques pour un même devis.

En fait pour les documents : si on garde 2 tables séparées pour devis et factures, cela induit bien une table document pour chaque sauf à se limiter à une relation sans contrôle de l'intégrité référentielle.
On peut envisager une table unique devis/facture avec un champs nature car le contenu est assez similaire, mais reste les autres documents correspondant au livrables ou aux échanges...

Les contrats ne semblent pas raccrochés à des clients : est-ce normal ?
A quoi sert statut dans Devis et Factures ?

 

[sarah33]

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

Hello Chris,

J'ai donc mis les index en "unique" dans les tables document, pour les champs N° Nature doc (Je suis pas sur d'avoir bien config l'index)
J'ai enlevé les n° Auto des Lignes (devis / facture) donc tout en numérique, ainsi que pour la ligne paiement.

Concernant mutualiser les facture/devis, j'aimerai bien mutualiser la table, mais j'ai peur de ne plus pouvoir lier un devis à des facture ensuite ?

Concernant la table contact, j'ai pas trop compris:
Client = société; Contact = la personne; Echange = (envoi de devis; relance mail; facturation; etc.)

Statut Devis = En attente, Signé, Annulé; etc.

Sarah

 

[chris]

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

Bonjour

Bien dimensionner les champs en fonction de la nécessité, ni plus ni moins.

Des champs de 255 caractères sont à proscrire : la base ressemblera à un gruyère à gros trous...

En revanche prévoit une adresse complète avec 2 ou champs ligne adresse, un CP, une ville.

Pour les listes déroulantes des tables de référence, comme par exemple liste des services, inutile de faire une requête, indiquer simplement la table et les colonnes à afficher (on place en début de tables les 2 ou 3 champs utiles pour simplifier ce paramétrage).

Pour les index, je parlais surtout d'index multiples indépendant des clés, automatiquement indexées : exemple le trio N° client, Nom, prenom, évite de saisir plusieurs fois le même contact car on a très de chance d'avoir des homonymes parfaits dans le même sté.
Prévoir Civilité dans la table car avec Dominique ou Claude...
La question était : peut-on enregistrer plusieurs échanges de même nature le même jour avec la même personne ou bien est-ce une anomalie et l'index permet de l'éviter.

Pour devis et factures : la relation d'une table à elle-même est dans la norme (exemples pour des personnes on peut avoir un champ père et un champ mère qui pointent chacun sur la même table de personnes qui contient toutes les générations.

La question est surtout d'être sûr de la notion 1 à n : éventuellement plusieurs factures pour un devis mais, s'il peut y avoir une facture correspondant à plusieurs devis, ça coince et il faut alors une table de jointure.
Actuellement tu n'as pas de relation entre les 2.

Sinon je n'ai rien vu d'autre.

 

[sarah33]

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

Merci pour ce complément !

Concernant plusieurs échange pour un même contact, une même date, c'est possible. Donc je laisse tel quel?
Concernant une facture pour plusieurs devis, c'est également possible je pense, en tout cas si ça se présente un jour, il faut que je puisse le faire... Donc une table de jointure. Ce qui veut dire que je mutualise quand même Devis/Facture dans une même table, mais que je fais quand même une seconde table: "Table_Jointure_Facture" pour permettre le cas 1facture/plusieurs devis.
Quels champs attribuer à cette table? et clées?

Je préférai revenir poser ma question avant de faire les modifs !

Merci,

Sarah