Contraintes FOREIGN KEY SQL vs code client

Je n'ai pas dit que la facture pouvait rester (à tout jamais) sans ligne de facture, mais il est parfois intéressant de pouvoir créer une facture qui n'a pas temporairement de ligne de facture.

Cas:
Nous sommes le 2 du mois, et je termine d'établir les factures au dernier jour du mois précédent. Mais, aussi, je dois facturer les factures du jour... Et je sais que je vais devoir facturer une prestation/livraison au dernier jour du mois précédent pour un client, mais sans savoir quoi (pour une raison x).

Or, je suis dans l'obligation de respecter une chronologie dans mes factures, et ne peut donc avoir une facture au dernier jour d'un mois dont le numéro serait supérieur à celui de la première facture du mois suivant... Je dois donc réserver un numéro pour une facture qui viendra "s'intercaler" dans le journal de facturation lorsque j'aurai des infos complémentaires.

Deux solutions:
- Le logiciel impose la création d'une ligne et je vais donc mettre n'importe quoi en attendant les précisions. Je sais d'expérience que cela générera des erreurs et des oublis...
- Le logiciel me permet la création d'une facture sans ligne de détails et je ne dois rien inventer

Désavantage de la solution 1: J'ai encodé une mauvaise ligne qu'aucun algorithme ne peut mettre en évidence, sauf à inventer un article bidon "Attente de précisions" et de mettre en évidence les factures utilisant cet article.

Avantage de la solution 2: Une requête très simple pour extraire les factures sans lignes de détails et pas de faux encodages avec les erreurs que cela risque d'entraîner (stats faussées, oublis de corrections, mauvaises imputations, ...)

Je ne dis pas qu'il n'y a pas d'autres solutions que la mienne, et on pourra en développer à l'infini, mais étant passé pendant plusieurs années par la case comptable (l'expertise comptable est ma formation première), j'ai apprécié le logiciel qui me permettait cela et j'ai beaucoup moins apprécié les logiciels qui me contraignaient à encoder de fausses données simplement pour pouvoir avancer...

Ton exemple est acceptable en effet. Je n'avais pas pensé à ce cas de figure.

C'est au cahier des charges, issu des besoins exprimés par les utilisateurs et leur hiérarchie, de déterminer si la contrainte "ligne de facture obligatoire pour toute facture" est requise ou non.

Pour aller dans ton sens, je me souviens d'une nouvelle version de logiciel qui gérait les contrats d'intérim. Lorsque ça a été présenté aux utilisateurs, ça a été un tollé de leur part parce que les verrouillages (les intérimaires ne pouvaient être enregistrés qu'avec le numéro du contrat les concernant) les empêcheraient de travailler car la réalité du quotidien était que le contrat d'intérim était reçu avec retard par rapport au moment où l'intérimaire commençait à travailler et pour lequel il fallait imputer des heures.

Je ne sais pas si la contrainte était logicielle ou en base de données mais comme c'était un programme en GAP sur AS400 dans les années 90, et une mise à jour d'un programme créé sur IBM36, j'ai des doutes sur la base de données qu'il y avait derrière.
Quoiqu'il en soit, le problème était que les spécifications n'avaient assez tenu compte du terrain.

Quant à moi, j'étais simple correspondant informatique dans une filiale qui n'utilisait pas encore ce logiciel et je n'ai pas été concerné.

Citation:

---

Envoyé par CinePhil

J...
Imaginons que je te facture quelque chose de la façon suivante :
Tu l'accepterais cette facture ?

---

Citation:

---

Ma Société
Son Adresse
Son Téléphone
FACTURE
Client : Pierre Fouconnier
Ton adresse
N° de client : 123
N° de facture : 12345
Date d'émission : 09/01/2010
Montant HT : 10 000 €
TVA : 1 960 €
Montant TTC : 11 960 €

---

C'est même pire que cela, car s'il n'y a pas de ligne de facture mais qu'il y a une facture alors la facture devrait apparaître comme ceci :


Ma Société
Son Adresse
Son Téléphone
FACTURE
Client : Pierre Fouconnier
Ton adresse
N° de client : 123
N° de facture : 12345
Date d'émission : 09/01/2010
Montant HT : NULL
TVA : NULL
Montant TTC : NULL

En effet les motant totaux sont calculées par rapport à la somme des lignes de facture !

C'est pourquoi effectivement une facture sans ligne de facture ne doit pas exister. Mais c'est souvent plus simple à dire qu'a faire, car il faut gérer des contraintes circulaires, ce qui suppose que le SGBDR ait la capacité à déférer la vérification des contraintes à la transaction ou bien simuler cela à l'aide d'une gestion fine des privilèges et de transaction comme je l'ai démontré ici :
http://www.developpez.net/forums/d82...t/#post4901806

A +

SQLPro,

Faire ce que tu proposes, c'est ne pas tenir compte de mon souhait fonctionnel, tel que je l'ai expliqué plus haut dans la discussion.

Ou alors, tu me trouves une solution pour que je puisse agir selon cette obligation fonctionnelle (à savoir, réserver un numéro de facture pour pouvoir intercaler une facture dont les détails seront connus plus tard entre deux factures que je peux établir).

Pour rappel: Ce n'est pas aux informaticiens à définir les obligations fonctionnelles d'un logiciel.

Bonjour à tous,
Je vais apporter ma maigre contribution à ce débat (même si je développe en Windev :aie:).
Si on considère qu'un ticket de vente et une facture sont (peu ou prou) la même chose, j'ai deux cas concerts de facture sans ligne:
1. Le client qui achète un bon d'achat, un avoir... En effet, ce dernier n'étant pas un produit, une prestation... le ticket de vente correspondant n'aura que des opération de trésorerie (des modes de règlements), donc pas de ligne.
2. Le client qui veut échanger une CB contre de l'espèce (pourquoi pas, après tout). Pour que le fond de caisse soit correcte, un ticket de vente est généré sans aucune ligne (un encaissement de CB et un décaissement d'espèce).

Si le deuxième cas est théorique, je rencontre le premier tout les jours avec le logiciel d'encaissement que nous utilisons (mais que nous n'avons pas développé).

Tatayo.
<Humour=on>
P.S. Plemaire, je développe en Windev, j'ai plusieurs applications qui attaquent la même base qui contient plus ou moins 300 tables, utilise des triggers, des procédures stockées, des règles d'intégrité, des clé étrangères... Suis-je un VRAI développeur, ou bien ?
</humour>

Salut Tatayo.

Premier cas: Ce n'est pas une vente. Acheter un bon d'achat, sur le plan comptable, c'est payer un acompte sur une vente qui se fera plus tard = > pas de facture ou de ticket de caisse (= vente, au sens commun du terme), mais un mouvement financier.

Deuxième cas: Echange CB contre monnaie. Ce n'est pas une vente, donc pas de ticket de caisse (= vente) ou de facture de vente, mais un ticket de mouvement de caisse...

C'est effectivement ainsi que le voit le logiciel d'encaissement, mais pas notre ERP (d'un autre éditeur) pour lequel un mouvement sur la caisse implique un ticket de vente. Et je me retrouve entre les deux, à traduire des opérations de tréso en ticket de vente... sans ligne.

Tatayo.

Citation:

---

Envoyé par Pierre Fauconnier

Cas:
Nous sommes le 2 du mois, et je termine d'établir les factures au dernier jour du mois précédent. Mais, aussi, je dois facturer les factures du jour... Et je sais que je vais devoir facturer une prestation/livraison au dernier jour du mois précédent pour un client, mais sans savoir quoi (pour une raison x).

Or, je suis dans l'obligation de respecter une chronologie dans mes factures, et ne peut donc avoir une facture au dernier jour d'un mois dont le numéro serait supérieur à celui de la première facture du mois suivant... Je dois donc réserver un numéro pour une facture qui viendra "s'intercaler" dans le journal de facturation lorsque j'aurai des infos complémentaires.

Deux solutions:
- Le logiciel impose la création d'une ligne et je vais donc mettre n'importe quoi en attendant les précisions. Je sais d'expérience que cela générera des erreurs et des oublis...
- Le logiciel me permet la création d'une facture sans ligne de détails et je ne dois rien inventer

Désavantage de la solution 1: J'ai encodé une mauvaise ligne qu'aucun algorithme ne peut mettre en évidence, sauf à inventer un article bidon "Attente de précisions" et de mettre en évidence les factures utilisant cet article.

Avantage de la solution 2: Une requête très simple pour extraire les factures sans lignes de détails et pas de faux encodages avec les erreurs que cela risque d'entraîner (stats faussées, oublis de corrections, mauvaises imputations, ...)

---

Certes. Néanmoins, dans l’activité de conception d’une base de données, on commence par modéliser le QUOI, d’où la production d’un modèle conceptuel de données (ou d’un diagramme de classes). On y représente la finalité et il est d’usage que dans le cas d’une facture, cette finalité soit, entre autres, l’existence d’au moins une ligne de facture, ce qui est représenté par une cardinalité 1,N :

http://www.fsmwarden.com/developpez/...D_Facture).jpg

Si au cours des échanges entre l’équipe projet et les utilisateurs, sont mises à jour des règles particulières du genre de celle que vous évoquez, à savoir que l’on peut être amené à avoir des factures provisoirement sans lignes, il est évident qu’il faut en tenir compte au plus tôt et aménager le modèle du moins mal que l’on peut, et la solution ne peut être qu’ad-hoc. On peut par exemple doter l’entité-type Facture d’un attribut de type statut (état) de la facture, qui ne correspond donc pas à une donnée, mais à une métadonnée, pour signifier qu’une facture est provisoirement incomplète.

Dans ce genre d’histoire, qu’il s’agisse de factures où d’objets totalement différents, l’essentiel est de poser le problème dès le départ et la solution ne sera pas imposée par l’informaticien seul, mais sera le fruit de sa collaboration avec l’utilisateur.

Exemple, avec l’adjonction d’un attribut FactureStatut :

http://www.fsmwarden.com/developpez/...ure)Statut.jpg

Cela a évidemment un impact sur les requêtes, car on doit systématiquement tester la valeur de l’attribut FactureStatut avant d’envoyer les factures dans la nature, de calculer des statistiques, etc. Une précaution peut consister à définir une vue, par exemple :

Code:

---

1 2 3 4

Create VIEW FactureOK (FactureId, FactureNumero, FactureDate, ...) AS SELECT FactureId, FactureNumero, FactureDate FROM Facture WHERE FactureStatut = "ok"

---

L’en-tête de cette vue (la liste de ses attributs) est identique à celui de la table Facture, à ceci près que l’attribut FactureStatut n’y figure pas. Les programmes ont tous accès à la vue, mais un seul d'entre eux est autorisé à accéder à la table Facture et changer le statut des factures.

C’est peut-être un peu contraignant du point de vue de l’organisation, aussi chacun peut réfléchir à sa solution ad-hoc, toujours en collaboration avec l’utilisateur. Le tout est de chercher à anticiper les problèmes qui ne manquent jamais de faire surface. « Prevention is better than cure ».

Maintenant, si on utilise un progiciel...

N.B. Dans le MCD ci-dessus, figurent un attribut FactureId et un attribut FactureNumero faisant a priori double emploi : le concepteur de bases de données a pour habitude d’avoir la maîtrise absolue de ses clés primaires, que l’utilisateur ne voit pas (FactureId), et de laisser à celui-ci le soin de s’occuper de ses propres clés naturelles (FactureNumero). Cette contrainte n’est pas fonctionnelle, mais les chefs de projets ayant quelque expérience acceptent volontiers de la prendre en compte dès le niveau conceptuel.

Oulala fsmrel, tu m'as fait une horreur dans le SQL de ta vue en utilisant des guillemets au lieu des apostrophes !!!!

Il faut donc lire :

Code:

---

WHERE FactureStatut = 'ok'

---

et non

Code:

---

WHERE FactureStatut = "ok"

---

va falloir que je te fasse un cours sur SQL !!! ;)

A +

Citation:

---

Envoyé par SQLpro

Oulala fsmrel, tu m'as fait une horreur dans le SQL de ta vue en utilisant des guillemets au lieu des apostrophes !!!!

---

Tel est mon bon plaisir...

(Et puis SQL Server offre gracieusement l'option SET QUOTED_IDENTIFIER OFF...)

Citation:

---

Envoyé par fsmrel

N.B. Dans le MCD ci-dessus, figurent un attribut FactureId et un attribut FactureNumero faisant a priori double emploi : le concepteur de bases de données a pour habitude d’avoir la maîtrise absolue de ses clés primaires, que l’utilisateur ne voit pas (FactureId), et de laisser à celui-ci le soin de s’occuper de ses propres clés naturelles (FactureNumero). Cette contrainte n’est pas fonctionnelle, mais les chefs de projets ayant quelque expérience acceptent volontiers de la prendre en compte dès le niveau conceptuel.

---

J'aimerais que tout le monde prenne ce genre de précautions dès que possible, je me suis déjà retrouvé à gérer des tables de plusieurs dizaines de millions de lignes ayant pour clé primaire un champ de type varchar(60).
Inutile de préciser que les jointures étaient particulièrement inefficaces et les gros traitements batch douloureusement longs avant que l'on ne prenne la décision de modifier le MCD.

Désolé pour le H.S. et bonne discussion.

Bonjour

Le cas de la facture sans ligne de facture, c’est quand même tenter de modéliser une contrainte qui n’existe pas ou qui est mal définie.
Que la vérification soit coté client ou coté SGBD, aucune machine ne saura différencier un oubli de ligne de facture d’une volonté du comptable de réserver un numéro … A moins de le spécifier. Et dans ce cas, rajouter un champ booléen FactureTemporaire permettra d’une part :

• De modéliser que la facture est temporaire
• De placer une contrainte Check efficace : une facture non temporaire doit avoir au moins une ligne de facturation
• De lister facilement les factures temporaires à corriger (voire même pourquoi pas un délai maximum autorisé pour la mise à jour)

« Je veux que l’application soit fiable mais je veux être libre de créer des factures vierges » n’a aucun sens.
En revanche :
« Je veux que l’application soit fiable mais je veux être libre de créer des factures vierges si je le stipule » est le fruit d’un cahier des charges réfléchi conduisant à "comment je le stipule", "qui peut le stipuler". Quant à confier cela au code client, cela signifierait :

Je crée une facture vierge n° 3010 sans ligne de facture. Message de confirmation : « Voulez-vous créer une facture sans produit ? » Je réponds Oui. Sans faire attention, je ré-ouvre la facture : le programme a oublié qu’il s’agissait d’une facture sans ligne => Message de confirmation : « Voulez-vous créer une facture sans produit ? »
Un simple champ booléen dans la table permet de mémoriser la réponse de l’utilisateur et de préserver la cohérence des données. Maintenant, comme l’indique SQL Pro, il faut que le SGBD soit capable de vérifier les contraintes en fin de transaction et non à la création de la ligne facture.

Il n'est pas nécessaire de rajouter un booléen pour ce faire. En effet, par une vue dotée d'une jointure INNER entre facture et ligne de facture, vous rendez visible uniquement les factures ayant des lignes de facture.

Le problème est que 99% des développeurs oublient que normalement toute application BD devrait être exclusivement attaquée par des vues et non directement sur les tables de la base. C'est la notion de modèle externe. Si tout le monde la respectait, les développements seraient triviaux, simple et sans redondance aucune !

A +

Citation:

---

Il n'est pas nécessaire de rajouter un booléen pour ce faire. En effet, par une vue dotée d'une jointure INNER entre facture et ligne de facture, vous rendez visible uniquement les factures ayant des lignes de facture.

---

Oui mais dans ce cas, comment tu fais pour autoriser l'absence volontaire de ligne pour une facture ? Sans les différencier explicitement, toutes les factures auront les mêmes contraintes de validation.

Il faut bien à la validation par le SGBD avoir une règle du style :
Une facture doit au moins avoir une ligne sauf pour les factures dont le numéro est réservé.

Non ?

Citation:

---

Envoyé par Tofalu

Oui mais dans ce cas, comment tu fais pour autoriser l'absence volontaire de ligne pour une facture ? Sans les différencier explicitement, toutes les factures auront les mêmes contraintes de validation....

---

C'est pour cela qu'à mon avis, cette contrainte n'a rien à faire au niveau de la création de la facture dans le SGBD

Je suis navré qu'une discussion BDD se limite à de la facturation et de la compta. La pratique d'une techno ultra-généraliste comme SQL te livre aux foudres d'un contrôleur de gestion, son regard en coin, ses blagues grinçantes, ses petites piques sadiques, sa serviette en cuir patinée, son haleine fétide.

Je reconnais que vous avez vraiment étudié les questions relatives à la sécurité des transactions dans un cadre où on garde les informations pour des raisons légales. Un problème français est d'avoir balayé les autre utilisations d'une BDD, le mode connecté avec traitement puis destruction des flux.

En face, on a des équipes complètement décalées qui utilisent des tableaux indicés pour tout ce qui n'est pas sonnant et trébuchant. Vous savez que Firefox utilise sql pour gérer ses favoris et que les developpeurs qui ont commis ce crime ne savent peut être pas réduire une tva, mais sont les rois des url's...

Il faudrait créer un fork de chaque topic BDD : 1. utilisation par des comptables - 2. toutes les autres utilisations (innombrables)

Et à part cet état de "navritude" et la caricature du contrôleur de gestion (je n'en suis pas un et je n'en connais pas), tout ça ne nous dit pas ce que tu penses du sujet de cette discussion.
J'ai beau relire ton message, je n'en comprends toujours pas le fond !

Citation:

---

Envoyé par Tofalu

Oui mais dans ce cas, comment tu fais pour autoriser l'absence volontaire de ligne pour une facture ?

---

Tout dépend si on fait une jointure interne(factures avec lignes) ou externes ( factures avec et sans lignes).

A +

Citation:

---

Envoyé par CinePhil

Et à part cet état de "navritude" et la caricature du contrôleur de gestion (je n'en suis pas un et je n'en connais pas), tout ça ne nous dit pas ce que tu penses du sujet de cette discussion.
J'ai beau relire ton message, je n'en comprends toujours pas le fond !

---

sans vouloir polluer votre thread interressant au demeurant. Je regrette que sql francais soit réservé à la gestion et soumis à des règles METIER issus de la gestion. Je suis intervenu plus haut dans ce sens. Vous prétendez à tord que les contraintes d'intégrité ref coté serveur font partie de l'état de l'art et que quelqu'un qui préfère les implémenter coté client est un amateur ou un bidouilleur. Là dessus vous nous plongez dans l'univers passionnant des factures et autres récursions de 1 à n indispensables à l'enregistrement de documents comptables.
Je récuse cette approche ôô combien dictée par l'enseignement français et invite les développeurs C(#/++/..) à utiliser systématiquement SQL dans leurs création comme un gestionnaire de données persistantes et utiliser les jointures tardives plutôt que d'utiliser les tableaux indicés et autres horreurs de caractères pour toute la cinématique de leurs programmes et non seulement pour compter les gros sous.

Autrement dit : votre discussion est instructive mais votre conclusion en réponse à la question posée dans ce topic est fausse car vous ne parlez que de gestion.

Je ne veux pas détailler les innombrables cas où les contraintes serveur sont un boulet à éviter car la liste est impressionnante , j'avais cité plus haut le cas des contrôleurs aériens qui est un métier aussi important que ceux d'argent et - pour autant que je sache - pas forcément interdit aux français. Pourtant les très nombreuses personnes interressées par ce type de développement préfèrent passer leur chemin plutôt que d'affronter vos certitudes, malheureusement pour l'industrie notamment. Cela m'ouvre un marché de niche et je collectionne les missions qui me mettent systématiquement en conflit avec des français parce que l'enseignement y est trop ... je sais pas comment dire, ... dogmatique, franchouillard... sur des sites anglophones , on ne souffre pas de cette discrimination .

En fait SQL ne vous appartient pas et vous n'avez pas à imposer les règles métier de gestion à l'ensemble des développeurs SQL.

Je ne cherche pas à diminuer votre travail mais à vous suggérer de ne pas coloniser l'industrie avec une approche gestion.

Toutes les lignes de sql ne sont pas si importantes à situer dans un SI , certaines sont momentanément poubélisées mais pas deletées pour optimiser les perfs. Certaines lignes insérées ne seront jamais lues dans un select car l'évenement ne sera jamais appelé entrainant des lignes orphelines.

Pour info , j'ai écrit des compilateurs, serveurs , géolocalisateurs, gestionnaires de signal très hautes fréquences..... grâce à SQL qui m'a fait gagner des mois de travail et permis des fonctions quasi impossibles autrement (mémoire virtuelle notamment)