Discussion :

[BRODU]

Bonjour,

Je termine un logiciel de facturation avec bons de livraison et factures. Ce travail est fait avec DELPHI 7 et Firebird.

Or, je me pose une question concernant les clés étrangères.

J’ai trois tables TB_LIG, TB_BON et TB_FACT, TB_BON et relié à TB_FACT par une clé étrangère, c'est-à-dire :

TB_LIG(PK_LIG, FK_BON, Autres)
TB_BON(PK_BON, FK_FACT, Autres)
TB_FACT(PK_FACT, DATE_FACT, NO_FACT, Autres)

Aucun souci avec la liaison TB_LIG et TB_BON

Par contre, lorsque le bon est émis, je ne connais pas le n° de la facture. Je suis obligé de mettre la clé étrangère FK_FACT à 0 ou NULL. C’est seulement au moment de la facturation que la clé étrangère sera reliée à la facture émise.

Or, la mise à zéro d’une clé étrangère fait que j’aurai des lignes orphelines dans la table TB_BON jusqu’à l’émission de la facture.

Je voudrais savoir :

- Cette approche est-elle la bonne ? Sinon, comment la modifier.
- La traduction en SQL pour éviter que des bons de livraison ne soient jamais facturés.
- Le contrôle des bons en attente de facturation doit-il se faire dans le programme et non dans la base de données ?

Mon MCD et MPL font bien état d’une situation de clé étrangère à zéro ou NULL lorsque le bon est attente de facturation.

J’espère qu’une âme charitable pourra m’enlever mes doutes et me donner des conseils judicieux.

[Aka Guymelef]

Bonjour,

le fait que tu es des bons en attente de facturation sont une réalité fonctionnelle de ton application je pense. Il y a bien un moment où l'utilisateur doit sélectionner un bon et déclencher l'opération de facturation de ce bon.

Si c'est le cas alors ton approche est la bonne, la seule chose à se souvenir c'est que la table TB_BON peut contenir soit des bons non-facturés (FK_FACT IS NULL) et des bons facturés (FK_FACT IS NOT NULL). Ces deux conditions te permettront de distinguer l'une de l'autre pour tes écrans d'affichage par exemple.

Le truc après c'est que lors de la création d'une facture, tu dois avoir conservé quelque part dans le programme une variable indiquant de quel bon elle est issue et faire la liaison entre bon et facture une fois cette dernière insérée en base (et dont tu connais l'id maintenant).

[valer]

Moi aussi j'ai un programme ainsi et voici comment je resouds mon problème:
Dans la table facturation tu crées un champ appelé par exemple Etat.
Kan on crée un bon tu insères aussi dans facturation avec la valeur Etat à Non par exemple. Puis au moment de facturer tu modifies juste la valeur de Etat à oui et le tour est joué.

[BRODU]

Bonjour,

Je vous remercie pour vos réponses, elles m'ont confirmé dans mon approche de simplification. Dans le cas présent, j'avais créé une table de liaison entre les bons de livraison et les factures. Cette mise en oeuvre fonctionne parfaitement avec les inconvénients suivants :

• Création d'une table supplémentaire ;
• Requête SQL plus complexes ;

Une question complémentaire pour @valer. La démarche employée me semble convenir que dans le cas où un bon de livraison = une facture. Mais, lorsqu'une facture regroupe plusieurs bons de livraison, tu pourrais m'expliquer comment tu fais.
D'avance merci

[didier.cabale]

- Cette approche est-elle la bonne ? Sinon, comment la modifier.

par principe, rien n'impose un lien 1 <-> 1 entre un BL et une facture. En effet, plusieurs BL peuvent être facturé en une seule fois.
De ce fait, et pour la raison que vous ne connaissez pas encore le # de facture, je ne ferais pas de lien entre BL et facture dans le fichier BL, mais dans un autre fichier, qui pourrait être le fichier des "BL facturés" (par exemple) ou le fichier des factures.

- La traduction en SQL pour éviter que des bons de livraison ne soient jamais facturés.

Si vous êtes Ok avec le 1er point, Il suffirait d'analyser le fichier des "BL facturés"

- Le contrôle des bons en attente de facturation doit-il se faire dans le programme et non dans la base de données ?

Cà serait le programme qui analyserait la base de donnée: je compare le fichier des "BL facturés" et celui des BL, et j'extrais les BL non facturés.

Cordialement

[chaplin]

+1

J'opterais pour cette solution.

[BuzzLeclaire]

Je m'y colle aussi.

J'informatise les entreprises depuis 15 ans alors je peux te donner ce que font les logiciels que je vends (je les aie pas fait lol) car chacun à sa sauce...

Celle que je prefere est cette solution :

1) Tu créer un BL (avec un champs etat (meme idée que Valer) à 0)
2) quand tu l'envoi en facture tu mets ce champs Etat a 1
3) dans une autre table (Tracabilite par exemple) tu enregistre
Le numero de Doc Origine, le numero Doc Destination (voir un champs type en plus car les factures peuvent etre des avoir) donc tu rajoute TypeDocOrigine, TypeDocDestination. Ce qui te permet de regler ton problème de x BL pour 1 Facture.

Mais cela c'est que pour les entetes !!
As-tu pensé aux lignes du bL car par exemple tu pourrais donner la possibilité de facturer tel ou tel ligne du BL.

Dans ce cas, il te faut :
- en entete une donnée supplémentaire un champ nommée solder (pour savoir si ton bl est totalement terminé d'être facturé. Champs que tu mettras à 1 que lorsque toutes tes lignes sont envoyée en facture
- Puis pour chaque ligne tu fais la même chose avec en plus un champs quantité facturé (cas ou tu facture que la moitié de la ligne). Donc tu aurais pour les lignes un champs solder et qté facturé. Lorsque qté facturé est = à qté de la ligne tu place ton solder de la ligne à 1, ensuite quand toutes tes lignes sont à 1, tu peux placé dans ton entete ton champs solder à 1.

[BRODU]

Bonjour,

Je vous remercie pour toutes vos réponses, lesquelles répondent à la partie pratique. La méthode que j'ai retenu était une table qui fait la liaison entre les bons de livraisons et les factures.

En fait, ma demande avait pour objectif de savoir si l'utilisation de la clé étrangère pour lier le bon à la facture pouvait être à Null lors de la création du bon et comporter le n° de la facture au moment de sa création.

Cette approche avait l'avantage d'éviter une table supplémentaire est de simplifier les requêtes.

Je pense que je me suis mal exprimé, la question qui fait chauffer mon petit cerveau est :

• Une clé étrangère peut-elle être mise à NULL ?
• Si oui, quid de l'intégrité référentielle ?

Dans mon MCD ma relation est : Facture <1,n> LIER <0,1> Bon Livraison.

Merci à ceux qui pourront me préciser ce dernier point.

[Andry]

Bonjour,

• Une clé étrangère peut-elle être mise à NULL ?
• Si oui, quid de l'intégrité référentielle ?

J'ai souvent ce genre de sitiation dans mes tables. Je ne sais pas si c'est correcte point de vue analyse.

A+

[Aka Guymelef]

Une clé étrangère peut-elle être mise à NULL ?

Oui à partir du moment où le champ n'est pas définit NOT NULL ou que le champ ne fait pas partie de la clé primaire de la table.

Si oui, quid de l'intégrité référentielle ?

Déjà pour qu'il y ait contrainte d'intégrité référentielle il faut que la contrainte de clé existe au niveau des tables.
Ensuite s'il y a suppression d'un élément d'une table qui est référencé comme clé étrangère dans d'autres tables alors le SGBD refusera de supprimer l'élément.
De même l'insertion ou modification d'une valeur dans le champ d'une clé étrangère doit correspondre à une clé dans la table principale, sinon il y aura rejet. A l'exception du NULL qui n'est pas considéré comme une valeur.

Normalement en terme de génération le fait d'avoir une table d'association entre deux tables implique qu'il y peut y avoir plusieurs combinaisons de des deux éléments. Ainsi avec une table d'association tu autorise à ce qu'une facture possède plusieurs bons (OK) mais tu autorise également à ce qu'un bon ait plusieurs factures (NOK ?).
Avec clé étrangère dans une table, cela implique qu'un enregistrement dans cette table n'est associé qu'à un seul élément de la table principale. Mais ça n'empêche pas un élément de la table principale d'être associé à plusieurs éléments de la table détail.