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

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

Aussi, au niveau de Date d'intervention, il serait peut être plus judicieux de le lier à Ligne_Devis plutôt qu'à devis? qu'en penses tu?
et dans ce cas il pourrait y avoir plusieurs lignes avec la même date.
Concernant les contrats: je vais probablement renommer cette table (je sais pas encore par quoi) mais elle correspond plutot à toute les clauses contractuelles que j'ajoute au devis, car le devis fait office de contrat, et ça me permet de faire mon "contrat à la carte".

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

Re

Oui si l'intervention correspond à la ligne de service figurant sur le devis. Dans ce cas comme clé je verrais n° devis+N° ligne devis+date intervention ou si clé en numéro auto ces 3 champs en index unique sauf si plusieurs interventions peuvent être nécessaires pour une ligne le même jour... C'est toujours la réalité qui dicte.

Pour Factures et devis il faut lister les champs qui sont communs et ceux qui sont spécifiques. Pour les spécifiques voir si néanmoins on peut ou non assimiler des champs un peu différents.

J'ai déjà vu dans des bases commerciales une table commune et une table annexe pour les spécificités mais c'est aussi les besoins en exploitation qui doivent guider et il vaut mieux ne pas pousser Access aux limites dont si trop différents garder 2 tables.

Une table de jointure aura au moins le champ clé de chaque table avec ce couple clé primaire.
Pas sûr que d'autres infos soient nécessaires car on les a par ailleurs (dates notamment).

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

Re,

Alors au niveau de Facture / Devis: tous les champs sont les mêmes.
Les différences sont aux niveau des liaisons:
Devis était liée en plus à:
* Contrat
* Intervention

et Facture:
*Paiement

Alors j'ai supprimé Facture, liée Paiement à Devis.
PAr contre, là devis n'est pas lié à lui même..et j'immagine qu'il faut que je le fasse pour faire des Devis et des Factures liées. Donc une table de supplémentaire? mais je sais pas trop comment m'y prendre.

Concernant les Index, je vais aller me renseigner d'avantage dessus..c'est un peu fouillie dans ma tête là.

Concernant les documents, finalement je n'en mettrai pas dans Echanges, ça simplifie, et je laisserai tout dans devis(facture) et les livrables auront des natures différentes, mais seront intégrés aux devis/factures.

Voilà ou j'en suis dans mon schéma (PJ)

Sarah

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

Bonjour

Ci-joins la base en retour.

Je n'ai pas tout décortiqué mais :

J'ai renommé certains éléments, supprimé des index inutiles (tu n'avais pas compris le principe), modifié quelques clés et listes déroulantes. Je n'ai pas encore supprimé factures et lignes mais les ai renommées en attendant.

J'ai adapté les relations et saisi quelques lignes pour vérifier que la table des liens devis-factures marche aussi bien pour 1 devis n factures que 1 facture n devis.

Il faudra bien revoir ensuite le type et la taille des champs des tables puis voir l'aspect index de contrôle (les clés sont déjà indexées automatiquement, donc c'est juste pour empêcher des doublons sur d'autres champs).

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

Hello Chris,

Tout d'abord merci bcp ! pour le temps passé sur ma base.. En effet, y a pas mal de notions que j'avais pas comprises et qui sont bcp plus claires now.

J'ai donc supprimé:
* Interventions: Autant mettre des dates dans les lignes_devis.
* La table Facture


Donc si j'ai bien compris, il faut que je fasse une requette pour obtenir les pièces dont la nature est facture (ou devis) pour distinguer factures de devis, afin notamment d'affecter des paiements à des factures, ou des Contrats/Clients à des devis.

J'ai également rajoutée un champs durée (en numérique) à la table Devis-Factures afin de:
* Pour les factures: un délai max pour le paiement et ensuite pour faire des rappels autos (pour moi) afin de relancer manuellement les clients.
* Pour les devis: une durée de validité du devis, et éventuellement faire des rappels autos, pour relancer.


Donc maintenant je vais faire un petit check up de l'ensemble des champs, et puis après j'attaquerai les formulaires.

Concernant les liste de choix:
Lorsque je dois retrouver une clé primaire pour créer une ligne dans une table, exemple:

Pour créer un échange, il me faut la clé contact. Alors je fais une liste déroulante, qui reprend le nom prénom du contact. Cependant, si je veux également le nom du Client (société), je ne peux pas, je dois passer par une requette c'est bien ça?

De plus, pour la saisie via des formulaires, les sous formulaires peuvent m'éviter d'utiliser ces listes de choix?

Merci

Sarah

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

Bonjour

Sans ouvrir la base quelques réponses :

Si la liste déroulante est basée sur la table, on peut y mettre autant de colonnes que nécessaire : il est plus simple que l'ordre dans la table soit celui visé mais ce n'est pas une obligation.

Le requête n'est utile que si on veut filtrer la liste restituée par rapport à un champ rempli du formulaire : je choisis une sté, seuls les contacts de cette sté doivent être dans la liste lorsque j'y accède.

Les listes déroulantes définies dans les tables sont héritées dans les formulaires créés après cette définition.
Même en cas de sous-formulaire (très fréquent) nombre de listes sont utiles, notamment pour les tables de référence (type de...) : facilité de saisie mais aussi contrôle des valeurs possibles plus convivial que le contrôle des clés par le moteur SGBD.

Pour les durées de règlement, penser aussi à mettre dans le fiche client le délai accordé s'il est personnalisé.

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

Hello,

Merci pour ces infos !

Ne pas tenir compte de ce message, voir celui du dessous.


Merkkkiiii

Sarah

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

Hello,

J'ai un peu avancé:

J'ai créé un formulaire F_Client, basé sur la table T_Client. Des liste déroulante, pour lister les clients, ainsi qu'une liste déroulante en cascade pour lister les contacts en fonction des clients. Chose faite.
L'idée est ensuite, de rappatrier les infos de cette seconde liste en cascade, dans des zones de textes.

Donc, j'ai réussi à rapatrier ma clé primaire de contact via ma Liste déroulante (Contact), dans une zone de texte [N°Client_T_Contact] via une formule : =[Liste94].[Column](6)
Cette zone de texte, est est la source du critère d'une requête: [forms]![F_Client]![N°Client_T_Contact]
Cette requête est la source de mon sous-formulaire, qui me donne les infos de la table T_Contact.
Mission accomplie !!!

Mise à part, que j'aimerai optimisé un peu plus ce formulaire:
Plutot que d'utiliser une requête sur une zone de texte, qui elle comporte une formule =[Liste94].[Column](6), est il possible de directement utiliser le critère de requête sur la formule: =[Liste94].[Column](6)

En gros, est ce que le critère de ma requete peut être la selection de ma liste déroulante?

Merci d'avance.

Sarah

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

Bonjour

En principe on fait soit un sous-formulaire en mode tabulaire, où on voit tous les contacts, soit un formulaire lié.

Comme tu as effacé le message précédent, je ne sais pas si tu avais précisé l'objectif.

Peux-tu repréciser ce que tu veux faire concrètement (de façon opérationnelle pas de façon access).

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

Bonsoir,

Alors j'ai revu un peu ma copie:

Le formulaire principal: F_Client correspond à la Fiche client. L'objectif est de pouvoir LIRE / MODIFIER / CREER / SUPPRIMER les enregistrements des tables:
* T_Client
* T_Contact


Pour se faire, j'utilise
* une liste déroulante Liste_Client qui me liste les enregistrement de T_Client (via le champs Société)
* une liste déroulante Liste_Contact qui liste les enregistrement de T_Contact pour chaque Société (via le champs 'non visible': N°Client) associé à la requête R_Client. Cette liste est aussi la source du champs 'non visible' N°Contact (formule: =[Liste58].[Column](2) )
* un sous formulaire SF_Client_Contact qui reprend les champs de T_Contact par rapport au champs: N°Contact via la requête: R_Contact

J'ai donc plus ou moins "réussi" si ce n'est:
* J'ai vu un bug: en sélectionnant la société "Test" par exemple, les champs ne se remplissent pas. J'ai compris que les lignes T_Client ne contenant pas de contact, provoquaient ce "bug". J'aimerai le résoudre, car un client n'a pas forcément de contact lorsque je l'ajoute.
* Pour assurer une Modification/Ajout/Suppression "proprement", je souhaiterai mettre en place des boutons. Pour celà, il faudrait que l'ensemble des zones de textes soit verrouillé par défaut. Le bouton AJOUTER, dévérouille les zones de textes, et créer un nouveau enregistrement, lorsqu'on presse sur "ENTREE" la nouvelle ligne est ajoutée à la Table et tout se revérouille.Le bouton SUPPRIMER qui supprime la ligne de la zone déroulante selectionnée.
==> J'envisage ces 2 boutons pour mes 2 listes déroulantes: Liste Client / Liste Contact
==> Et un bouton"MODIFIER": qui dévérouille, pour laisser la libre saisie de toute la page, et revérouille tout en pressant "ENTREE".

Là je coince pour ces deux points...
As tu une idée?

Quelques précisions sur les relations:
Je me suis rendu compte, qu'il n'y aura qu'UN SEUL domaine d'activité par Client, j'ai donc supprimer une des tables Domaine d'activité (inutile) , et rajouter les champs N°DomaineA et Metier dans la table T_Client et (pour le moment je ne touche pas à la table "T_ECHANGE")



Merci d'avance.

En pièce jointe la table

Sarah

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

Bonjour

Comme dit dans mon dernier post, le plus simple et de créer un formulaire sur la table client et un sous formulaire en mode tabulaire sur la table contacts.
La mise à jour se fait alors naturellement, mais on peut masquer la plupart des options d'interface afin de forcer le passage par des boutons et également intercepter la création ou modification des enregistrements, pour contrôler la saisie notamment.

Si tu ne veux absolument pas de mode tabulaire, il faut un bouton pour passer au contact suivant mais avec si peu de champs, je ne vois pas l'intérêt d'autant que sans visibilité de l'ensemble, on ne sait s'il y en a d'autres à moins de placer un compteur.

Tu as tendance à vouloir mettre des requêtes un peu partout en lieu et place des tables.

Les requêtes ne permettent pas toujours la mise à jour ou l'ajout selon leur structure.

Dans ce que tu as fait les champs père et fils doivent être le N° de client (absent), pas le N° de contact.

Dans un premier temps je crois qu'il faut bien mettre à plat les formulaires dont tu as besoin : quand on crée un client, il est bien de créer les contacts en même temps mais, si on ajoute un contact a postériori, un formulaire simplifié pour la partie client en visualisation suffit à ajouter le contact.

Ensuite quand ces formulaires sont définis puis testés, tu peux ajouter le niveau au-dessus : les formulaires indépendants pour afficher tel ou tel client ou contact ou visualiser des synthèses de ventes etc...

Il faut toujours analyser, pour chaque tables/processus opérationnel, les différents modes :

• création/ajout (comme dit plus haut avec l'exemple contact : on peut créer un contact avec le client ou par la suite donc il faut bien voir s'il faut une seule interface ou plusieurs pour cette étape)
• mise à jour
• suppression (en général on limite au maximum : on peut avoir un champ indiquant qu'un enregistrement n'est plus utilisé sans le supprimer car il peut être utile pour l'historique ou la cohérence)
• consultation unitaire ou de synthèse

De façon générale si on utilise bien les tables et leurs relations, les formulaires sont assez faciles à réaliser et tester.
Une fois que leur fonctionnement logique est testé, on ajoute les contrôles de saisie, notamment pour les champs interdépendants dont le contrôle unitaire ne suffit pas.

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

Hello Chris,

J'ai donc suivi ton conseil.
Reposer tout à plat, et surtout commencé par créer des formulaires de saisie, afin de vérifier que ça marche bien.
On verra après pour les formulaires d'analyse.

J'ai donc créée:
* Un formulaire pour Contact & Client (F_Client_Contact)
* Un formulaire (sous formulaire du précédent) Contact (F_Contact)
* Un formulaire Pour créer les devis (F_Devis).. et là ça se complique forcément.

Déjà, une notion à laquelle je n'avais pensée, c'est que un devis est adressé à une société mais aussi à un Contact (humain). Donc j'ai ajouté un champs N°Contact à T_Devis_Facture afin d'y associer une liste déroulante reliée à T_Contact (mais sans intégrité ref).

J'ai également insérée un sous formulaire pour créer mes lignes_devis. C'est là que tout se complique, car j'avais décidé de reprendre les Prix calculés dans plusieurs table.


J'ai donc insérée :
Private Sub Form_BeforeUpdate(Cancel As Integer)
Me![Prix HT] = Me![Prix unitaire] * [Quantité]
End Sub

Dans mon sous formulaire (F_LigneDevis) (tabulaire) basé sur une requête qui importe les prix & services de T_ListeService. Afin que le prix calculé soit enregistré dans la table T_LigneDevisFacture

J'ai également créée un champs txt_TotalHT dans le pieds de page de ce sous formulaire. Ce champs utilise la formule:
=Somme([Prix unitaire]*[Quantité]) afin de calculer la somme HT du devis.

Et donc je cherche à rapatrier ces données, dans le champs: [F_Devis].[Total HT], afin de l'enregistrer dans la table également.

J'ai donc ce code qui pourrait faire l'affaire en l'insérant dans le sous formulaire F_LigneDevis: Forms![F_Devis].[Total HT] = Me![txt_TotalHT] , mais je ne sais pas sur quel événement le mettre pour qu'il fonctionne...

De plus, je me demande s'il ne serait pas possible d'intégrer la formule directement dans le champs [F_Devis].[Total HT] plutôt que de passer via la zone de texte: [F_LigneDevis].[txt_TotalHT] ...

J'ai éssayé un truc du type Forms![F_Devis].[Total HT] = Somme(Me![Prix unitaire]*[Quantité]) mais je n'ai pas réussie.

Aurais tu une idée?

ça me bloque pour la suite de se formulaire, car pour calculer le champs TVA par exemple Me![TVA] = Me![Total HT] * 19,6/100, je devrai placer le code sur un événement une fois que le Total HT sera effectué.

Merci

Sarah

PS: je n'arrive pas à upload ma base, trop lourde

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

Bonjour

De façon générale, certains calculs ne peuvent être faits que dans le pied du sous-formulaire.

Pour valoriser le champs correspondant du formulaire il faut utiliser l'évènement du sous-formulaire

Private Sub Form_AfterUpdate()
Forms("nom du formulaire principal").Controls("Nom du total HT") = Me.nom_du_champ_du_pied (lui donner un nom parlant)
End Sub

Cliquez pour agrandir...

tu peux mettre à jour plusieurs champs dans cette sub

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

Re,

J'ai donc réalisé le code:
Forms("F_Devis").Controls("Total HT") = Me.txt_TotalHT
en suivant ta syntaxe, et l'ai rajouté au sous formulaire :

Private Sub Form_BeforeUpdate(Cancel As Integer)
Me![Prix HT] = Me![Prix unitaire] * [Quantité]
Forms("F_Devis").Controls("Total HT") = Me.txt_TotalHT
End Sub

ça fonctionne, cependant le champs [Prix HT] hérite de la valeur de txt_TotalHT AVANT La mise à jour: donc l'ancienne valeur.
En le mettant en Après mise à jour ça ne marche pas non plus

Edit: J'ai allégé ma BD, pour l'upload.
J'ai également un doute concernant mes relations: T_Contact T_Client et T_Devis_Facture.
Puisse qu'un Devis(facture) s'adresse à un T_Client et à un T_Contact..

Merci d'avance pour tes conseils.

Sarah

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

Bonjour

Pour ma part

• je définis dans la table lignes factures_devis le lien avec la table de référence (pas une requête) :
  • ainsi en précisant, pour le champ type service, liste déroulante 6 colonnes (5 suffirait si on inverse les champs) avec toutes les colonnes de largeur 0 sauf la 2
• je crée un formulaire tabulaire sur la table lignes factures_devis (pas une requête) qui hérite de la liste déroulante ainsi définie
• je peux y ajouter les champs indépendants unité, durée, prix en me référant aux colonnes de la liste déroulante avec la syntaxe =[N°Service].[Column](2) (commence à 0 pour colonne 1), champs non activés, juste affichés.
• sur événement Après MAJ de ce champ je valorise [prix HT] selon la valeur du champ indépendant prix
• j'intègre ce sous formulaire en tant que sous-formulaire du formulaire Devis.
• Pour l'ensemble du devis il y a :
  • saisie :
    • on prévoit un bouton Valider et un bouton abandonner et on masque les boutons permettant de changer d'enregistrement (de plus on met le formulaire en mode ajout de données)
    • le bouton valider doit :
      • contrôler les lignes détail : pas de quantité à 0 notamment
      • après contrôle positif il faut déplacer le focus sur le formulaire principal et valoriser le total_HT et autres et enregistrer (encore que l'enregistrement peut se faire seul dans certains cas (selon la façon dont on quitte l'enregistrement) puisqu'un champ a changé).
        On peut éventuellement déclencher un recalc sur le sous-formulaire lors du changement du champ quantité mais cela repositionne le focus sur la quantité saisie
    • le bouton Abandonner doit détruire ce qui a été saisi tant au niveau Devis que des lignes.
  • MAJ :
    • dans la partie devis, à part le statut, le reste doit être verrouillé
    • pour les lignes voir ce qui est autorisé comme changement.
    • le bouton valider fait comme pour la saisie mais si abandonner est prévu, il faut avoir gardé en mémoire les valeurs précédentes devis et lignes pour pouvoir les rétablir.
  • Consulter : voir les besoins, c'est souvent un formulaire un peu différent.

On peut à l'ouverture d'un formulaire, rendre des champs actifs ou non, visibles ou non, etc, changer le statut du formulaire et donc utiliser un même formulaire pour tout mais c'est souvent plus simple quand il est finalisé d'en faire 2 ou 3 variantes pour limiter le VBA...