Je télécharge puis conçois le MCD pour revenir vers vous avec un graphe amélioré correspondant à vos remarques afin de mieux vous éclairer dans vos analyses précieuses. Bonne fin de semaine à vous
Je télécharge puis conçois le MCD pour revenir vers vous avec un graphe amélioré correspondant à vos remarques afin de mieux vous éclairer dans vos analyses précieuses. Bonne fin de semaine à vous
Il y a aussi JMerise qui est pas mal pour faire des MCD. Il a été développé par un contributeur de Developpez.com.
Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
« Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
À la maison comme au bureau, j'utilise la suite Linux Mageïa !
Voici le MCD construit avec JMerise.
Là on est bien au niveau conceptuel
Je suppose que vous avez inversé les cardinalités entre client et établissement non ? d'ailleurs il manque les règles de gestion entre client et établissement
Mais attention : avec la double relation "détenir" et "souscrire" il risque d'y avoir un cycle dans le MCD.
Je n'ai pas compris la nature de la relation "détenir" entre établissement et BP, n'est-ce pas redondant avec la relation "souscrire"
S'il y a bien les deux relations, alors il faut une CIF pour s'assurer que l'établissement en lien avec la BP est bien un établissement du client en lien avec la BP, en l'état rien ne l'interdit
Pour les lignes de facture, il faut prévoir une cardinalité mini de zéro vers la ligne de paiement, toute ligne de facture n'étant pas forcément payée
Je ne sais pas si vous avez voulu identifier les adresses relativement au client ne connaissant pas la symbolique utilisée dans ce cas par JMerise, à vérifier
Sinon votre modèle est très pauvre en attributs, il faut l'enrichir
Non je n'ai pas inversé les cardinalités entre client et établissement car un client ne peut être gérer que par un seul établissement par contre celle ci peut gérer plusieurs clients.Je suppose que vous avez inversé les cardinalités entre client et établissement non ? d'ailleurs il manque les règles de gestion entre client et établissement
Mais attention : avec la double relation "détenir" et "souscrire" il risque d'y avoir un cycle dans le MCD.
Chaque établissement à un nombre donné de N° BP et donc on ne peut pas avoir le même N° BP dans deux établissements différents.Je n'ai pas compris la nature de la relation "détenir" entre établissement et BP, n'est-ce pas redondant avec la relation "souscrire"
S'il y a bien les deux relations, alors il faut une CIF pour s'assurer que l'établissement en lien avec la BP est bien un établissement du client en lien avec la BP, en l'état rien ne l'interdit
OKPour les lignes de facture, il faut prévoir une cardinalité mini de zéro vers la ligne de paiement, toute ligne de facture n'étant pas forcément payée
C'est par rapport aux données que j'ai en ma possession. Vous pouvez toujours m'en proposer.Sinon votre modèle est très pauvre en attributs, il faut l'enrichir
D'accord ce ne sont pas les établissements du client, mais les établissement qui mettent à disposition les BP pour les clients, c'est bien ça ?
Oui c'est tout a fait cela.D'accord ce ne sont pas les établissements du client, mais les établissement qui mettent à disposition les BP pour les clients, c'est bien ça ?
Les attributs sont liés aux besoins fonctionnels et aux contraintes réglementaires.
Pour la facture et les lignes de facture, consultez la réglementation, mais comme mentionné plus haut je pense qu'il faut à minima avoir les montants HT, TVA et TTC ainsi que la référence article, la quantité, la devise de facturation et le taux de TVA. Il faut aussi le n° de facture qui peut être différent de l'identifiant technique, et la date de la facture.
J'ai tellement l'habitude de parler d'établissements d'un client, que j'ai eu du mal à voir qu'ici ce n'était pas le cas, désolé
Pour les attributs Montant HT, TVA et TTC je souscris totalement mais par contre la référence article, la quantité je ne pense pas parce-que mon produit ici est la BPLes attributs sont liés aux besoins fonctionnels et aux contraintes réglementaires.
Pour la facture et les lignes de facture, consultez la réglementation, mais comme mentionné plus haut je pense qu'il faut à minima avoir les montants HT, TVA et TTC ainsi que la référence article, la quantité, la devise de facturation et le taux de TVA. Il faut aussi le n° de facture qui peut être différent de l'identifiant technique, et la date de la facture.
Pas de soucis, je ne vous tiens pas rigueurJ'ai tellement l'habitude de parler d'établissements d'un client, que j'ai eu du mal à voir qu'ici ce n'était pas le cas, désolé
Il me semble que la quantité est obligatoire, à vérifier, même si effectivement dans votre cas, il est probable que chaque ligne ne concerne qu'une et une seule BP
Par contre la référence article effectivement n'est pas à inclure dans l'ET ligne facture : c'est le lien issu de la FK vers la BP qui permettra de connaitre l'article concerné(en l'occurrence la BP)
escartefigue, pense que GAJES n'est pas soumis à la réglementation française mais congolaise.
Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
« Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
À la maison comme au bureau, j'utilise la suite Linux Mageïa !
Donc après vos remarques très distingués et une réévaluation du MCD , es ce que vous pouvez valider ce MCD ou il y' a encore des choses à améliorer dans les relations, attributs ?????
Les attributs de ET_Facture (Montant HT, TVA, Montant TTC) migreront dans ET_Ligne_Facture de même pour ET_Paiement et ET_Ligne_Paiement
De client vers Facture, il faut prévoir une cardinalité mini zéro pour les clients n'ayant encore jamais été facturés
Idem de BP vers ligne de facture, si vous avez de nouvelles BP jamais facturées
Pour les paiements il manque le lien avec l'émetteur du paiement, de plus le solde ne devrait pas être stocké c'est une valeur calculée qui dépend de la date et de l'état des encours (montant du/montant réglé)
Toujours pas de taux de TVA dans la table facture ?
Comme vous aviez confirmé que vous gérez à la fois des clients personnes physiques et personnes morales, je vous recommande d'utiliser l'héritage pour distinguer les 2. Les attributs des uns et des autres étant très différents.
Cf. ma proposition de MCD du 11 janvier à 13h56
Concernant les identifiants, je vois que vous avez systématiquement utilisé du smallinteger.
Ce format autorise jusqu'à 65536 valeurs (2^16) ce qui est le plus souvent largement suffisant pour une identification relative, mais risque d'être trop juste pour une identification absolue. Attention donc selon les cas. A remplacer si nécessaire par de l'integer (jusqu'à 4 milliards de valeurs) voire bigint. Je pense que vous devriez d'ailleurs identifier la ligne de facture relativement à la facture (auquel cas du smallint suffit pour identifier la ligne facture)
OK pour ces modificationsDe client vers Facture, il faut prévoir une cardinalité mini zéro pour les clients n'ayant encore jamais été facturés
Idem de BP vers ligne de facture, si vous avez de nouvelles BP jamais facturées
J'ai crée une relation Client - PaiementPour les paiements il manque le lien avec l'émetteur du paiement,
Si je l'ai inséré sur MCD dans la ET_Facture ci-dessus.Toujours pas de taux de TVA dans la table facture ?
Pas comprisJe pense que vous devriez d'ailleurs identifier la ligne de facture relativement à la facture (auquel cas du smallint suffit pour identifier la ligne facture)
L'identification relative consiste en ceci :
facture(fac_id, ...)
ligne_facture (fac_id, num_ligne, ...)
La clé étrangère référençant la facture est la première colonne de la clé primaire de la ligne de facture.
La ligne de facture est identifiée relativement à la facture :
ligne_facture (fac_id, num_ligne, ...)
1, 1
1, 2
1, 3
2, 1
2, 2
3, 1
3, 2
3, 3
3, 4
...
Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
« Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
À la maison comme au bureau, j'utilise la suite Linux Mageïa !
Ah OK comprisL'identification relative consiste en ceci :
facture(fac_id, ...)
ligne_facture (fac_id, num_ligne, ...)
La clé étrangère référençant la facture est la première colonne de la clé primaire de la ligne de facture.
La ligne de facture est identifiée relativement à la facture :
ligne_facture (fac_id, num_ligne, ...)
Dans FACTURE, si votre réglementation est identique à celle applicable en France, il faut
- le montant hors taxes
- le montant de la taxe
- le montant TTC (HT + TVA)
- le taux de TVA
Or je ne vois que 3 attributs montant, je suppose donc que vous n'avez pas mis le taux
Tu avais raison sur les attributs car après quelques recherche en effet nous avons la même réglementation ainsi voici le MCD.Oui c'est pourquoi je conseille de consulter la règlementation, d'ailleurs c'est vrai dans tous les cas
Bonsoir
Je ferai peu de commentaires sur la partie paiement, car il y a bien longtemps que je n'ai pas eu à traiter ce quartier fonctionnel
toutefois vérifiez si tous vos paiements sont bien effectués dans la même devise, dans la négative, il faut ajouter la devise de paiement
La relation "illustrer" a un nom inadapté, même si cette relation ne deviendra pas une table, cardinalité 1 maxi coté paiement oblige, vous pouvez utiliser "typer", "catégoriser", "identifier", "codifier"... qui sera plus adapté
Pour la ligne facture, il manque probablement le montant HT ligne, le TTC ligne, et le montant TVA, voire le taux de TVA de la ligne. Là encore à vérifier en fonction de votre réglementation nationale.
Attention aussi aux règles d'arrondi entre le total lignes et le montant facture
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager