1. #1
    Candidat au Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2017
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2017
    Messages : 9
    Points : 2
    Points
    2

    Par défaut Facturation et infos clients qui changent ?

    bonjour à tous,
    je resume mon soucis.
    voila, si dans mon programme de gestion j'ai les tables

    FACTURE (id_facture, id client, montantHT, date etc...)
    lié à ma table CLIENT (par l'id client):
    CLIENT (id_client, nom, prenom, adresse etc..)

    donc les factures sont crées et enregistrées.
    Si en cours d'année je crée et donne au client une facture 1. et ensuite l'adresse du clients change.
    dans ce cas, dans mon programme de gestion les factures ne sont plus bonnes (car ma facture 1 générable sera avec le nouvelles adresse du client alors que le client aura la facture que je lui ai remis avant la modification de son adresse dans ma table client).

    ma question:
    pour avoir toujours les factures identiques à celles remises à mon client sur mon programme de gestion, est il preferable que j'ajoute dans ma table FACTURE le champ CLIENT.adresse qui sera une copie de CLIENT.adresse à l'instant ou je génére et donne la facture au client?

    donc j'aurais FACTURE (id_facture, id client, montantHT, date, client_adresse etc...) ?

    ou bien que j'ajoute un historique client en créant une table ADRESSE(id_client, date, coordonnées)
    ce qui complique bien le developpement par rapport à si j'insere juste le champs CLIENT_adresse dans la table FACTURE.

    merci pour vos reponses.

  2. #2
    Membre du Club
    Homme Profil pro
    Inscrit en
    juillet 2009
    Messages
    84
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 84
    Points : 62
    Points
    62

    Par défaut

    Bonjour . Il faut séparer l'adresse de la table client.

    avec ceci , tu dois associer une commande à la fois à la table 'adresse de facturation' et et la table 'client' .

    si le client change d'adresse , ce n'est pas grave , l'id de l'ancienne adresse est toujours présent dans la commande (car cette adresse est toujours gardée dans ta base de données)

    As tu fait comme ça ?

  3. #3
    Candidat au Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2017
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2017
    Messages : 9
    Points : 2
    Points
    2

    Par défaut

    bonjour utilisateur 38,
    non je n'ai pas fait comme ca. ce que j'ai fait:
    j'ai ajouté le champs FACTURE(adresse, cp, ville, TVA1, TVA3, TVA4, TVA5 etc...) à ma table FACTURE.

    bref j'ai mis les infos d'adresse de facturation ainsi que les taux de la facture directement dans la table facture.

    ainsi si le 5 taux de TVA changent (mon programme permet 5 taux de tva differents), les factures émises gardent les bon taux.
    je sais que ce n'est pas correct niveau merise mais ca simplifie la programmation pour moi de ne pas avoir trop de tables.
    qu'en pensez vous ?

    En tout cas ca fonctionne bien meme si ca fait des infos redondantes

  4. #4
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 531
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 531
    Points : 5 651
    Points
    5 651

    Par défaut

    Bonjour,

    La simplification de la programmation ne doit en aucun cas être un critère pour déroger aux règles de modélisation !
    La structure de la base de données, c'est un peu comme les fondations d'une maison, si elle est mal conçue, alors vous le paierez cash par l'intégrité des données non assurée, les perfs dégradées, l'espace disque inutilement encombré et les traitements complexes pour contourner les problèmes.
    Est ce qu'un cuisinier enlève la moitié des ingrédients de ses recettes sous prétexte que c'est trop compliqué ?

    Si vous avez des difficultés avec les jointures, formez vous à SQL, les jointures sont très simples à mettre en œuvre avec un peu de pratique.
    Voici un lien qui pourra vous aider si nécessaire : https://www.developpez.net/forums/d6...q-langage-sql/

  5. #5
    Candidat au Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2017
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2017
    Messages : 9
    Points : 2
    Points
    2

    Par défaut

    merci escartefigue,
    effectivement je vais modifier et ajouter une table adresse_facturation.

    mais si on s'en tient vraiment aux regles de modelisation, pour une petite appli réalisable rapidement et non soumise à modification par la suite, elle s'alourdit parfois beaucoup et complique la saisie par l'utilisateur (en gros pour chaque table je fais une fenetre d'ajout, modification et suppression à mon programme)

    par exemple pour etre rigoureux il faudrait aussi ajouter la table Adresse_Client car l'adresse du client (du siege social par exemple) peut etre difference de l'adresse de facturation et aussi changer au cours du temps.

    et dans ce cas il me semblerait plus simple d'ajouter la table EN_TETE (id_en_tete, adresse_client, adresse_Facturation). et le champs id_en_tete à ma table FACTURE
    ce ne serait pas plus mal non ?

    une facture serai lié à une EN_TETE par l' id_en_tete
    et la table EN_TETE contiendrait les infos necessaires à l'en tete de la facture au moment de la création de celle-ci.

    je parle bien pour une petite application, comme une application de facturation ou l'utilisateur ne saisirait que 200 factures au maximum par an, dans ce cas je ne pense pas que ca changerait grand chose niveau performance, espace disque etc..

  6. #6
    Expert confirmé
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 531
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 2 531
    Points : 5 651
    Points
    5 651

    Par défaut

    Citation Envoyé par whynot75 Voir le message
    mais si on s'en tient vraiment aux regles de modelisation, pour une petite appli réalisable rapidement et non soumise à modification par la suite, elle s'alourdit parfois beaucoup et complique la saisie par l'utilisateur (en gros pour chaque table je fais une fenetre d'ajout, modification et suppression à mon programme)
    Toute application évolue un jour ou l'autre, si la modélisation est bien faite, l'évolution est aisée, et inversement.
    Le nombre de tables ne pilote aucunement le nombre de fenêtres dans l'application.
    Vous pouvez par exemple avoir une fenêtre de saisie de facture avec une partie entête reprenant les éléments du client et un corps avec autant de lignes que d'articles à facturer

    Citation Envoyé par whynot75 Voir le message
    par exemple pour etre rigoureux il faudrait aussi ajouter la table Adresse_Client car l'adresse du client (du siege social par exemple) peut etre difference de l'adresse de facturation et aussi changer au cours du temps.
    Le mieux est de typer les adresses : une seule entité-type adresse chaque adresse possède un type, par exemple 0=par défaut, 1=de facturation, 2=de livraison, 3=de correspondance...
    Vous pouvez créer un lien à date entre le client et l'adresse

    Citation Envoyé par whynot75 Voir le message
    et dans ce cas il me semblerait plus simple d'ajouter la table EN_TETE (id_en_tete, adresse_client, adresse_Facturation). et le champs id_en_tete à ma table FACTURE
    ce ne serait pas plus mal non ?
    Ce n'est pas une bonne idée, il ne faut jamais répéter les données, c'est une règle de base, et elle s’explique aisément : si certains clients sont livrés et facturés à la même adresse, alors une des deux adresses est redondante, si demain vous avez besoin d'une troisième adresse alors vous êtes contraint de modifier la table.
    Utilisez ce que je vous propose plus haut.

    Citation Envoyé par whynot75 Voir le message
    je parle bien pour une petite application, comme une application de facturation ou l'utilisateur ne saisirait que 200 factures au maximum par an, dans ce cas je ne pense pas que ca changerait grand chose niveau performance, espace disque etc..
    Les performances sont effectivement plus sensibles quand le volume d'informations est important.
    Par contre quelque soit le volume dans la base de données, si les formes normales ne sont pas respectées, il y a un risque concernant l'intégrité des données, or, la première qualité d'une base de données est de garantir la fiabilité des données
    Comme il n'est pas plus compliqué de bien faire que de mal faire, je dirai même que c'est plutôt l'inverse, autant s'habituer de suite aux bonnes pratiques, les maintenances inévitables à venir en seront plus aisées.

  7. #7
    Candidat au Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2017
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : février 2017
    Messages : 9
    Points : 2
    Points
    2

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    Le mieux est de typer les adresses : une seule entité-type adresse chaque adresse possède un type, par exemple 0=par défaut, 1=de facturation, 2=de livraison, 3=de correspondance...
    Vous pouvez créer un lien à date entre le client et l'adresse
    oui effectivement, c'est ce point qui me prenait la tete (l'idée d'avoir une table adresse livraison, puis une table adresse facturation etc..)
    en ayant une seule table adresse avec un type (0, 1, 2 ou 3), ca me va tres bien, merci beaucoup

Discussions similaires

  1. Facture , nom client qui remplit les cellules automatique.
    Par djmisterjon1 dans le forum Macros et VBA Excel
    Réponses: 1
    Dernier message: 19/09/2013, 21h50
  2. [XL-2010] Infos client sur facture
    Par jack0000 dans le forum Excel
    Réponses: 4
    Dernier message: 24/09/2012, 08h16
  3. [AC-2007] Formulaire de facturation: infos client auto
    Par Alkazar2 dans le forum IHM
    Réponses: 14
    Dernier message: 10/06/2009, 18h24
  4. [Info] A qui profite java?
    Par afrikha dans le forum Général Java
    Réponses: 40
    Dernier message: 20/12/2005, 17h18
  5. la liste des clients qui n'ont pas acheter aucun article ...
    Par TéBeSsI dans le forum Langage SQL
    Réponses: 6
    Dernier message: 13/02/2004, 14h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo