Discussion :

[jojo86]

Bonjour,
Dans une appli je souhaite gérer des factures et donc des produits.
Le but de ce sujet est de faire un point focal uniquement sur la gestion des tarifs.

Mon objectif est, lors de la visualisation d’une facture passée, de visualiser le prix du produit à cette date.
Du coup j’envisageais d’ajouter un champ date tarif à ma table produit, correspondant à la date de création du produit.

Mon produit aura bien sur une cle primaire ID et c’est cet ID qui sera stocké dans la facture.

Lorsque le prix d’un produit change, au travers d’un Update sur la table produit, j’envisageais de gérer avec un trigger before Update qui permettrait de faire en language littérale :
Avant Update : Si NEW.Prix <> prixActuel Alors Insérer le produit comme s’il s’agissait d’un nouveau produit, sauf que la désignation est la même, et insérer la date du jour dans date tarifs.

De cette manière pour la création de nouvelles factures, je peux sélectionner les derniers produits en date.

Qu’en pensez vous?

Merci de votre aide.

[SQLpro]

Mon objectif est, lors de la visualisation d’une facture passée, de visualiser le prix du produit à cette date.
Du coup j’envisageais d’ajouter un champ date tarif à ma table produit, correspondant à la date de création du produit.

[...]

Lorsque le prix d’un produit change, au travers d’un Update sur la table produit, j’envisageais de gérer avec un trigger before Update qui permettrait de faire en language littérale :
Avant Update : Si NEW.Prix <> prixActuel Alors Insérer le produit comme s’il s’agissait d’un nouveau produit, sauf que la désignation est la même, et insérer la date du jour dans date tarifs.

Si vous utilisez SQL Server, inutile de vous emmerdez avec tout cela, c'est automatique et performant avec la gestion des tables temporelles.
https://blog.developpez.com/sqlpro/p...r-presentation
Cela fait partie de la norme SQL 2015.
En sus, vous avez des opérateurs pour savoir quel était la valeur du produit à tel moment ou dans tel intervalle de temps.

A +

[jojo86]

Salut, désolé j’ai oublié de préciser que je dois faire ca sur SQLite.

Du coup dans la logique de ce que j’envisage, est-ce que ca semble fonctionnel?

[escartefigue]

Bonjour,

Le cas le plus général est que la facture concerne un à plusieurs produits et qu'un produit possède un à plusieurs tarifs en fonction de la date, de la quantité, voire, du client

La modélisation correspondante est dans ce cas

FACTURE 1,n --- contenir --- (1,1) LIGNE_FACTURE 1,1 --- concerner --- 0,n PRODUIT 1,n --- tarifer ---0,n CALENDRIER

Soit les tables :
FA_FACTURE (FA_id, FA_numero, FA_date, ..., CL_id #(id client))
LF_LIGNE_FAC(FA_id, LF_id, LF_qte, ..., PR_id#)
PR_PRODUIT(PR_id, PR_reference, PR_lib, ...)
TA_TARIFER(PR_id#, CA_date#, TA_prix, TA_unite_mesure, TA_code_TVA...)

Le prix de base n'est donc pas enregistré au titre du produit, mais du couple produit + date
Ensuite, il peut y avoir des remises sur quantité, sur montant ... tout dépend de vos règles de gestion

[jojo86]

Le prix de base n'est donc pas enregistré au titre du produit, mais du couple produit + date
Ensuite, il peut y avoir des remises sur quantité, sur montant ... tout dépend de vos règles de gestion

Salut, merci de ton aide,
Mais du coup je ne comprends pas comment réussir à afficher une facture passée pour laquelle les tarifs auraient changé.

Pour faire plus simple, je pourrais très bien rajouter une clé primaire auto incrémentée dans TA_TARIFER, de cette manière, j'aurai une clé unique représentative de mon couple IDProduit + Date ? Et c'est cette clé que je stockerai dans la table LF_LIGNE_FAC ?
En résumer :

FA_FACTURE (FA_id, FA_numero, FA_date, ..., CL_id #(id client))
LF_LIGNE_FAC(FA_id, LF_id, LF_qte, ..., ID_TARIF_PRODUIT#)
PR_PRODUIT(PR_id, PR_reference, PR_lib, ...)
TA_TARIFER(ID_TARIF_PRODUIT#, PR_id, CA_date#, TA_prix, TA_unite_mesure, TA_code_TVA...)

Comme ça, je peux faire un formulaire utilisateur "Modification des tarifs" :
1 : l'utilisateur recherche et sélectionne le produit (Table PR_PRODUIT),
2 : Après sélection du produit par l'utilisateur, lancement d'une requête de sélection sur la table TA_TARIFER pour récupérer le dernier tarif avec "Select Max(ID_TARIF_PRODUIT), TA_PRIX..... WHERE PR_id = id du produit selectionné"
3 : Après modification des tarifs, faire un "Insert Into TA_TARIFER........" pour ajouter une nouvelle ligne de prix pour le produit.

Ensuite, lors de l'établissement d'une facture, il faudra faire la même requete permettant de récupérer le dernier tarif en vigueur, et lors de l'enregistrement de la facture, je peux stocker le numéro "ID_TARIF_PRODUIT" dans la table LF_LIGNE_FAC ce qui permettra de manière plus simple de retrouver les tarifs des anciennes factures.
Qu'en penses-tu ?

Merci de ton aide,

[SQLpro]

Salut, désolé j’ai oublié de préciser que je dois faire ca sur SQLite.

Du coup dans la logique de ce que j’envisage, est-ce que ca semble fonctionnel?

Avez-vous conscience que SQL Lite n'est pas un SGBD destiné à être utilisé par plusieurs personnes à la fois ? C'est un SGBDR embarqué destiné à être utiliser par un seul et unique utilisateur à la fois.

Or il me semble que vous voulez faire une application multi utilisateur....

Extrait de cette page :
https://www.sqlite.org/whentouse.html
"
Situations Where A Client/Server RDBMS May Work Better
Client/Server Applications
If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. ...
"
Traduction :
Situations dans lesquelles un SGBD client/serveur fonctionnera mieux
Applications client/serveur
S'il existe de nombreux programmes clients envoyant SQL à la même base de données sur un réseau, utilisez un moteur de base de données client/serveur au lieu de SQLite. ...


A +

[jojo86]

Avez-vous conscience que SQL Lite n'est pas un SGBD destiné à être utilisé par plusieurs personnes à la fois ? C'est un SGBDR embarqué destiné à être utiliser par un seul et unique utilisateur à la fois.

Or il me semble que vous voulez faire une application multi utilisateur....

Bonjour,
Non, ce n'est pas une application multi utilisateur... C'est une application monoposte.
Pour les applications multi-utilisateurs, j'utilise principalement firebird qui offre plus de confort niveau triggers, procédures stockées.

Donc oui, tu fais bien de poser la question car j'aurais pu tomber des nus et voir mon monde s'écrouler, mais je suis bien informé sur ce point !

[escartefigue]

Si les règles de gestion que j'ai évoquées plus haut sont les bonnes, il suffit, au moment où l'on établit la facture, d'aller rechercher dans la table TA_TARIFER le prix de chaque produit applicable.
Il faudra vérifier que la date de facturation (en général la date du jour mais pas forcément) est comprise entre la date de début et la date de fin du tarif

Et effectivement, comme l'indique SQLPro, si votre application est multi-utilisateurs, un autre SGBD s'impose !

[jojo86]

Il faudra vérifier que la date de facturation (en général la date du jour mais pas forcément) est comprise entre la date de début et la date de fin du tarif

Du coup pour déterminer la date de début et de fin du tarif, je dois avoir deux champs dédiés ? Un champ DateDebutTarif et un champ DateFinTarif => Mais ce champ correspondra à DateDebutTarif de mon nouveau Tarif.
Mais si je n'ai pas ces deux champs, je n'arrive pas à imaginer la requête de selection des produits... Que faut-il mettre dans le Where ?
Si j'ai deux champs : "DateDebut" et "DateFin" je peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Where DateDebut>='Date de la facture saisie dans l'appli' AND (DateFin<='Date de la facture saisie dans l'appli

Sauf que potentiellement, le dernier tarif en vigueur n'aura pas de DateFin de renseigné puisque le tarif est actif...
Comment vois-tu la clause Where? (dans les grandes lignes)
Merci,

Et effectivement, comme l'indique SQLPro, si votre application est multi-utilisateurs, un autre SGBD s'impose !

Non c'est du mono utilisateur pas de risque !

[escartefigue]

Pour s'affranchir de la problématique de la date de fin non renseignée pour la ligne en vigueur, la solution la plus couramment utilisée est d'avoir une colonne date de fin avec une valeur par défaut à 9999-12-31 (colonne not null with default)

Ensuite il suffit de borner la date de facturation ainsi :
WHERE FA_DATE between TA_DTDEB and TA_DTFIN

[jojo86]

Pour s'affranchir de la problématique de la date de fin non renseignée pour la ligne en vigueur, la solution la plus couramment utilisée est d'avoir une colonne date de fin avec une valeur par défaut à 9999-12-31 (colonne not null with default)

Ensuite il suffit de borner la date de facturation ainsi :
WHERE FA_DATE between TA_DTDEB and TA_DTFIN

Je comprends mieux certaines choses
Dans notre ERP SAP au travail, certains champs liés à des segments temps sont initialisés à cette fameuse date !

Merci de tes lumières, je n'ai plus qu'à m'y mettre !

[escartefigue]

Dans notre ERP SAP au travail, certains champs liés à des segments temps sont initialisés à cette fameuse date !

Il arrive aussi que la date de début soit valorisée par défaut au '0001-01-01'
C'est toujours plus simple pour les requêtes de n'avoir pas à se préoccuper des marqueurs nuls

[jojo86]

La modélisation correspondante est dans ce cas

FACTURE 1,n --- contenir --- (1,1) LIGNE_FACTURE 1,1 --- concerner --- 0,n PRODUIT 1,n --- tarifer ---0,n CALENDRIER

Soit les tables :
FA_FACTURE (FA_id, FA_numero, FA_date, ..., CL_id #(id client))
LF_LIGNE_FAC(FA_id, LF_id, LF_qte, ..., PR_id#)
PR_PRODUIT(PR_id, PR_reference, PR_lib, ...)
TA_TARIFER(PR_id#, CA_date#, TA_prix, TA_unite_mesure, TA_code_TVA...)

Avec ce modèle, comment serait-il possible de gérer des stocks ?
De manière simple je pourrais ajouter un champ quantité à la table PR_PRODUIT, ainsi qu’un champ contenant le prix moyen pondéré ?

Qu'en penses-tu ?

[escartefigue]

Ca dépend du besoin

Si le stock est géré par magasin et par emplacement il faut une table magasin (ou entrepôt) et une table emplacement (qui pourra avantageusement être identifiée relativement au magasin)
Chaque produit est présent dans zéro à plusieurs emplacements et dans chaque emplacement il y a une certaine quantité, la somme de ces quantités donne le stock total tous magasins confondus

Attention : certains produits sont peut être stockés parfois à l'unité, parfois par sachet, carton, mêtre linéaire, kit... il faut donc gérer l'unité de mesure de la quantité et ne pas sommer des choses incohérentes

Si on s'intéresse au stock à date d'inventaire, il faut historiser ces quantités