Gestion en lot avec des dates de péremption comme celui d'une pharmacie

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.

Citation:

---

Envoyé par escartefigue

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) :

Pièce jointe 511270

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 :

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)
)
;

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).

Pour vérifier tout ça, on code un bout de jeu d’essai :

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 ;

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 :

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  

On consulte la vue :

SELECT * FROM LIGNE_COMMANDE_V ;

Au résultat :

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

Vous nous direz si grâce à escartefigue et fsmrel vous sentez que vous progressez dans la bonne direction...


 

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é ;)

Citation:

---

Envoyé par escartefigue

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 !