Bonjour,
Je voudrais avoir des orientations sur la gestion en lot avec des dates de péremptions comme les articles de la pharmacie. Si je peux avoir des exemples.
Bonjour,
Je voudrais avoir des orientations sur la gestion en lot avec des dates de péremptions comme les articles de la pharmacie. Si je peux avoir des exemples.
Bonjour,
voici un exemple de discussion similaire ici :
https://www.developpez.net/forums/d1...ite-piluliers/
Je regarde et je vous reviens
Suivant le sujet si je transpose dans mon cas j'estime que j'aurai:
Produit(IdProduit, Libelle, ...)
ProduitLot(NumeroLot, #IdProduit, DatePeremption, ...)
Facture(numFact, dateFact.....)
vente(#numFact,#numerolot,DateFa, ...)
Cela suppose que pour facturer c'est chaque lot qui sera pris en compte.
Si ce n'est pas le cas éclairé moi pour que je comprenne mieux.
Merci
Bonsoir,
On ne peut pas vous aider si vous ne communiquez pas
- des explications sur le contexte : décrivez le besoin, donnez des exemples, définissez le vocabulaire
- vos règles de gestion.
Vous devez rédiger les règles et les faire valider par les gens du métier, sans quoi votre modèle, non conforme à la réalité, ne satisfera pas au besoin.
Les règles se rédigent sous la forme (exemple) :
R001 --- produits et lots
R001a : un produit peut être concerné par plusieurs lots de fabrication
R001b : un lot de fabrication concerne un et un seul produit
R002 --- commandes et produits
R002a : un produit peut être commandé plusieurs fois
R002b : une commande peut concerner plusieurs produits
etc.
Bonjour
Toutes mes excuses. Les règles sont:
R001 --- produits et lots
R001a : un produit peut être concerné par plusieurs lots de fabrication
R001b : un lot de fabrication concerne un et un seul produit
R002 --- commandes et produits
R002a : un produit peut être commandé plusieurs fois
R002b : une commande peut concerner plusieurs produits
R003 : Sur une commande doit figurer la date de péremption de chaque produit(First in Fisrt Out)
Encore une fois, ce que j'avais écrit n'était qu'un exemple, il faut rédiger les règles pour couvrir l'ensemble.
Dans votre premier message, il était également question de factures et de ventes, il manque probablement d'autres acteurs : des clients sans doute, des règlements probablement, etc.
À compléter donc.
C'est vrai que c'est un exemple. Cet exemple répondait bien à ma préoccupation. Pour moi une commande est une facturation directement. Je sais qu'il y a d'autre gestion où la commande est dissocié de la facture. Je me suis calqué que sur l'aspect que je comprend pas bien. les autres aspects tel que client, facture et règlement me pose pas de problème.
R001 --- produits et lots
R001a : un produit peut être concerné par plusieurs lots de fabrication
R001b : un lot de fabrication concerne un et un seul produit
R002 --- commandes et produits (Commande est égale à la facturation)
R002a : un produit peut être commandé plusieurs fois
R002b : une commande peut concerner plusieurs produits
R003c : Sur une commande doit figurer la date de péremption de chaque produit(First in Fisrt Out)
R003d : Une commande peut être réglé plus tard
R004 ---- Client
R004a : un client peut passer plusieurs commandes
R004b : une commande ne peut être passé que par un seul client
Bonsoir,
Escartefigue a pratiqué l’art de la maïeutique, c’est-à-dire vous a demandé expressément d’accoucher de la liste des règles de gestion : cette énumération est indispensable pour qu’on puisse examiner votre problème. Ainsi on y voit un peu plus clair, et pour encore y voir mieux, il n’est pas inutile de représenter les choses graphiquement, à l’aide d’un MCD (modèle conceptuel des données). A cette occasion, on met vite en évidence le chaînon manifestement manquant, à savoir la ligne de commande.
Exemple avec Looping (gratuit, merci à Patrick Bergougnoux) :
Ainsi on voit qu’une ligne de commande détermine un lot (donc la date de péremption), et via le lot détermine le produit.
Vous noterez que les cardinalités 1,1 sont parfois accompagnées de la lettre « R », cas par exemple de la patte connectant l’entité-type LIGNE_COMMANDE et l’association LC_COM : cela veut dire qu’on utilise l’identification relative, qui est un moyen de signifier qu’une entité-type est faible, c’est-à-dire qu’elle n’est qu’une propriété d’une entité-type plus forte. Ainsi, LIGNE_COMMANDE n’est qu’une propriété de COMMANDE, et si d’aventure une commande disparaissait du système, ses lignes de commande en feraient nécessairement autant.
Je ne suis pas amateur du mode représentation du MLD (modèle logique des données) défini par les merisiens dans les années quatre-vingts et dont vous vous êtes servi (cf. votre post #4) car, si c’est mieux que rien, entre autres choses, il ne permet pas de toujours savoir explicitement à quelle table fait référence telle ou telle clé étrangère ou encore de représenter d’autres contraintes.
Appelons donc un chat un chat, la structure pertinente est celle que l’on utilise en SQL, c’est moins joli que les beaux dessins, mais autrement efficace :
Vous noterez que la table LIGNE_COMMANDE est dotée d’une clé alternative {commandeId, produitId} signifiant que deux lignes d’une même commande ne peuvent pas faire référence à un même produit, mais si cette contrainte ne vous convient pas, vous la supprimez (contrainte LIGNE_COMMANDE_AK).CREATE TABLE PRODUIT ( produitId INT NOT NULL , produitNom VARCHAR(48) NOT NULL , CONSTRAINT PRODUIT_PK PRIMARY KEY (produitId) ) ; CREATE TABLE LOT ( produitId INT NOT NULL , lotId INT NOT NULL , datePeremption DATE NOT NULL , CONSTRAINT LOT_PK PRIMARY KEY (produitId, lotId) , CONSTRAINT LOT_PRODUIT_FK FOREIGN KEY (produitId) REFERENCES PRODUIT (produitId) ) ; CREATE TABLE COMMANDE ( commandeId INT NOT NULL , commandeNumero VARCHAR(9) NOT NULL , commandeDate DATE NOT NULL , CONSTRAINT COMMANDE_PK PRIMARY KEY (commandeId) , CONSTRAINT COMMANDE_AK UNIQUE (commandeNumero) ) ; CREATE TABLE LIGNE_COMMANDE ( commandeId INT NOT NULL , ligneCommandeId INT NOT NULL , produitId INT NOT NULL , lotId INT NOT NULL , quantiteCommandee INT NOT NULL , CONSTRAINT LIGNE_COMMANDE_PK PRIMARY KEY (commandeId, ligneCommandeId) , CONSTRAINT LIGNE_COMMANDE_AK UNIQUE (commandeId, produitId) , CONSTRAINT LIGNE_COMMANDE_COMMANDE_FK FOREIGN KEY (commandeId) REFERENCES COMMANDE (commandeId) , CONSTRAINT LIGNE_COMMANDE_LOT_FK FOREIGN KEY (produitId, lotId) REFERENCES LOT (produitId, lotId) ) ;
Pour vérifier tout ça, on code un bout de jeu d’essai :
Et pour bien voir le résultat et pouvoir le présenter au maître d’oeuvre, on crée la vue qui va bien :INSERT INTO PRODUIT (produitId, produitNom) VALUES (1, 'aubergine'), (2, 'betterave'), (3, 'courgette') ; SELECT '' as 'PRODUIT => ', * FROM PRODUIT ; INSERT INTO LOT (produitId, lotId, datePeremption) VALUES (1, 1, '2019-04-01'), (1, 2, '2019-07-14'), (1, 3, '2020-02-29') , (2, 1, '2019-02-02'), (2, 2, '2019-06-06'), (2, 3, '2020-01-10') , (3, 1, '2020-02-16'), (3, 2, '2020-06-21'), (3, 3, '2020-07-22') ; SELECT '' as 'LOT => ', * FROM LOT ; INSERT INTO COMMANDE (commandeId, commandeNumero, commandeDate) VALUES (1, 'AB-123-XY', '2019-01-01'), (2, 'AB-234-JH', '2019-02-02'), (3, 'AC-345-GG', '2019-03-03') ; SELECT '' as 'COMMANDE => ', * FROM COMMANDE ; INSERT INTO LIGNE_COMMANDE (commandeId, ligneCommandeId , produitId, lotId , quantiteCommandee) VALUES (1, 1, 2, 1, 150), (1, 2, 3, 2, 220), (1, 3, 1, 3, 330) , (2, 2, 3, 2, 260) , (2, 1, 2, 1, 250) ; SELECT '' as 'LIGNE_COMMANDE => ', * FROM LIGNE_COMMANDE ;
On consulte la vue :CREATE VIEW LIGNE_COMMANDE_V (commandeNumero , produitNom , datePeremption , quantiteCommandee) AS SELECT commandeNumero, produitNom, datePeremption, quantiteCommandee FROM LIGNE_COMMANDE AS x JOIN COMMANDE AS y ON x.commandeId = y.commandeId JOIN LOT AS z ON x.produitId = z.produitId AND x.lotId = z.lotId JOIN PRODUIT AS t ON z.produitId = t.produitId
Au résultat :SELECT * FROM LIGNE_COMMANDE_V ;
Vous nous direz si grâce à escartefigue et fsmrel vous sentez que vous progressez dans la bonne direction...commandeNumero produitNom datePeremption quantiteCommandee -------------- ---------- -------------- ----------------- AB-123-XY betterave 2019-02-02 150 AB-123-XY courgette 2020-06-21 220 AB-123-XY aubergine 2020-02-29 330 AB-234-JH betterave 2019-02-02 250 AB-234-JH courgette 2020-06-21 260
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Je suis émerveillé. Cela répond à ma problématique et suis en plein dans les codes et les requêtes. J'allais droit dans le mur. Je vous reviens si toute fois y a des zones d'ombres.
Merci à tout un chacun
Vous saurez à l'avenir que commencer à coder les requêtes alors que le modèle de données n'est pas validé est très prématuré
Cette fois-ci, babey doit en être convaincu, avant de mettre les mains dans le cambouis du code, rien de tel qu’un bon dessin accompagné de règles de gestion pertinentes...
@babey,
N’hésitez pas à revenir si vous avez des questions. Sinon, marquez la discussion comme résolue.
N’oubliez pas de liker les messages qui vous ont apporté quelque aide.
Bonne suite !
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager