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.

[helmis]

Les valeurs de clé étrangère dans la ligne de référencement sont mises à NULL lorsque la ligne de référence est mise à jour ou supprimé. Cela n'est possible que si les colonnes de la table de références sont Nullable. En raison de la sémantique des NULL, un référencement ligne avec NULL dans les colonnes de clé étrangère ne nécessite pas de référence à une ligne.

[Aka Guymelef]

Les valeurs de clé étrangère dans la ligne de référencement sont mises à NULL lorsque la ligne de référence est mise à jour ou supprimé.

Non c'est faux, ou alors ce n'est pas standards à tout les SGBD. Lorsqu'une contrainte existe le fait de supprimer la ligne de référence entraine un contrôle pour savoir si elle n'est pas utilisée dans une autre table, si c'est le cas, la suppression échoue.

La seule autre option dont je n'avais pas parlé c'est le ON DELETE CASCADE qui, lorsqu'on supprime un enregistrement de la table de référence, supprime toutes les lignes dans les tables utilisant cette référence. A utiliser avec précautions néanmoins.

[valer]

Déjà le fait que Léclaire pense qu'un BL peut être facturer plusieurs fois est absurde. Je crois qu'on doit partir de ce kon a pour faire quelque chose.
Dans la mesure ou le BL est fait avant la facture l'idéal serait de ne pas joindre directement la table facture à la table BL. Cela permet que les deux ne soient pas intimement liés.
Cette pratique donne l'avantage qu'en supprimant une facture ou qu'en annulant un BL les autres lignes dans les autres tables restent intactes.
Dans ce cas l'approche que je te donne est simple. Dans ta table BL tu crées un champ Etat que tu mets à 0 par exemple chaque fois kon livre. Bien entendu dans la table BL il doit avoir le champ Facture qui peut prendre la valeur NULL. Ainsi chaque fois kon livre tu mets laisses intact.
Au moment de facturer donc tu auras plusieurs choses à faire. Créer la facture, insérer ce numéro de facture dans les BL sélectionnés et mettre le champ Etat à 1 par exemple.
Ainsi donc ta facture peut contenir plusieurs BL.

[BRODU]

Bonjour,

Je vous remercie tous pour vos conseils et commentaires. Tous ces éléments m'ont permis de répondre à mes questions théoriques et pratiques.

Je considère cette question comme résolue.

A bientôt.