Discussion :

[GAJES]

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

[CinePhil]

Il y a aussi JMerise qui est pas mal pour faire des MCD. Il a été développé par un contributeur de Developpez.com.

[GAJES]

Voici le MCD construit avec JMerise.

[escartefigue]

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

[GAJES]

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.

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 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

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.

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

OK

Sinon votre modèle est très pauvre en attributs, il faut l'enrichir

C'est par rapport aux données que j'ai en ma possession. Vous pouvez toujours m'en proposer.

[escartefigue]

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 ?

[GAJES]

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.

[escartefigue]

C'est par rapport aux données que j'ai en ma possession. Vous pouvez toujours m'en proposer.

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.

Oui c'est tout a fait cela.

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é

[GAJES]

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.

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 BP

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é

Pas de soucis, je ne vous tiens pas rigueur

[escartefigue]

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 BP

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)

[CinePhil]

escartefigue, pense que GAJES n'est pas soumis à la réglementation française mais congolaise.

[escartefigue]

escartefigue, pense que GAJES n'est pas soumis à la réglementation française mais congolaise.

Oui c'est pourquoi je conseille de consulter la règlementation, d'ailleurs c'est vrai dans tous les cas

[GAJES]

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

[escartefigue]

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)

[GAJES]

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

OK pour ces modifications

Pour les paiements il manque le lien avec l'émetteur du paiement,

J'ai crée une relation Client - Paiement

Toujours pas de taux de TVA dans la table facture ?

Si je l'ai inséré sur MCD dans la ET_Facture ci-dessus.

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)

Pas compris

[CinePhil]

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
...

[GAJES]

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, ...)

Ah OK compris

[escartefigue]

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

[GAJES]

Oui c'est pourquoi je conseille de consulter la règlementation, d'ailleurs c'est vrai dans tous les cas

Tu avais raison sur les attributs car après quelques recherche en effet nous avons la même réglementation ainsi voici le MCD.

[escartefigue]

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