Discussion :

[Ys6BcinMZrSO]

Salut mes frères je veux créer une application de gestion commerciale et j'ai rencontrer quelques soucis au niveau de modélisation notamment au niveau des cardinalités entre commande et livraison car j'arrive pas à couvrir toutes les possibilités qu'on peut avoir par ex:
un client passe une commande qui contient 3 articles:
1-article1 disponible en stock
2-article2 la quantité demandé disponible partiellement
3-article3 indisponible
Cette commande donc aura 2 ou 3 bon livraison.
Est ce qu'on va créer un bon de livraison pour l'article1 et le deuxième pour les autres qui reste après l'approvisionnement ou il y a d'autre procédures.
et si je veux faire une liaison entre les différentes pièces commerciales c-à-d générer un bon de livraison ou une facture depuis un bon de commande ou bien générer la facture directement d'un bon de livraison comment traduire tout ça dans mon mcd tout en évitant les boucles.
voici le mcd et merci d'avance.

[Richard_35]

Bonjour sHaDoWhUnTeR,

Tu as créé une bonne base de travail, !



Tout d'abord, il faut supprimer la partie barrée. Ensuite, il faudrait détailler la partie (1) en créant une entité "CommandeClient_Detail" qui transformera les cardinalités n,n (arrivant sur DetailCommande) en 1,1 (partant de CommandeClient_Detail) : cela éclairera ton MCD et les réponses à tes questions viendront, sans doute, d'elles-mêmes.

[Ys6BcinMZrSO]

Merci Richard_35 pour votre réponse
j'ai effectué les changements que vous m'avais proposer,mais j'ai toujours pas saisi, j'ai mis une relation entre livraison et article parce que la quantité et le prix du bon de livraison sont changeables et peuvent être différentes à celles de commande, alors que devienne l'entité livraisonClient?
merci infiniment

[Richard_35]

Ce sont les ligne de commande qui vont être livrées et, peut-être, partiellement, si j'ai bien compris. Donc, ta règle de gestion devient :

Cette [ligne de] commande donc aura 2 ou 3 bon livraison.

Il faut donc partir de la ligne de commande (0,n) vers une livraison (1,1).

Enfin, même topo pour la facturation : c'est la livraison d'un article qui est facturée.

[Ys6BcinMZrSO]

Sert avec cette manip je peut livrer une commande par article, mais en contre partie il sera impossible de modifier ni la quantité ni le prix de vente met en accord avec le client, encore je ne serai pas en mesure de livrer une commande toute entière avec un seul bon de livraison.
Encore une chose que je veux savoir: la facture est ce qu'elle sera en relation avec commande ou bien avec livraison, normalement en facture les articles livrés.
et Merci pour vos conseils.

[Richard_35]

Vite fait, quelque chose comme cela devrait correspondre à ce que tu souhaites :

[Ys6BcinMZrSO]

Bonsoir, désolé pour l’absence
Est ce que avec DétailCmdeClient(0,n) ----- Livrer ------- (1,1)Livraison va me permettre d'affecter plusieurs lignes ou toute une commande à un seul bon de livraison? même question pour la facturation si je veux regrouper plusieurs bon de livraison dans une seule facture?
merci pour votre aide

[CinePhil]

DétailCmdeClient(0,n) ----- Livrer ------- (1,1)Livraison

Ce morceau de MCD est issu de la règle de gestion suivante :
Un détail de commande client peut être livré en plusieurs livraisons et une livraison ne livre qu'un seul détail de commande client.

Le schéma classique...
Pour les commandes :
Client -0,n----passer----1,1- Commande -1,n----comprendre----(1,1)- LigneCommande -1,1----concerner----0,n- Produit

Pour les livraisons :
Livraison -1,n----comprendre----(1,1)- LigneLivraison -1,1----référer----0,n- LigneCommande

Pour les factures :
Facture -1,n----comprendre----(1,1)- LigneFacture -1,1----référer----0,n- LigneLivraison

Ajouter de l'identification relative à partir du client vers la commande et du produit vers la ligne de commande complexifie les clés primaires des tables mais facilite certaines requêtes en évitant de multiples jointures pour remonter de la ligne de facture jusqu'au client ou au produit.

[Richard_35]

Bonjour SHaDoWhUnTeR et Philippe,

SHaDoWhUnTeR, tu as tous les éléments, avec les précisions de Philippe.

A noter, une chose importante à définir, concernant les factures :

Facture -1,n----comprendre----(1,1)- LigneFacture -1,1----référer----0,n- LigneLivraison

==> autrement dit, 1 ligne de bon de livraison peut être facturée en plusieurs fois.


Dans ton schéma modifié, il y a :

Facture -1,n----comprendre----(1,1)- LigneFacture -1,1----référer----0,1- LigneLivraison

==> autrement dit, 1 ligne de bon de livraison ne peut être facturée q'une seule fois (donc en totalité).

Les deux solutions sont possibles sachant que qui peut le + (CinePhil) peut le - : à toi de voir.

[Ys6BcinMZrSO]

Tout d'abord merci pour vos analyses
j'ai pas totalement saisis la partie concernant la facture et livraison généralement les factures et les bons de livraison référent les mêmes informations alors pourquoi ne pas faire une relation entre l'entité livraison et facture comme suite:
Livraison-0,1----comprendre----1,n- Facture
Voici le mcd avec les rectifications suggérés

[CinePhil]

j'ai pas totalement saisis la partie concernant la facture et livraison généralement les factures et les bons de livraison référent les mêmes informations alors pourquoi ne pas faire une relation entre l'entité livraison et facture comme suite:
Livraison-0,1----comprendre----1,n- Facture

Je n'ai pas (re)lu toute la discussion mais ai seulement posté la manière, à mon sens, classique de modéliser l'ensemble {commande, livraison, facture}.

Peut-être que dans ton cas les informations figurant sur un bon de livraison sont identiques à celles figurant sur la facture mais je peux te dire, par mon expérience professionnelle passée, que c'est loin d'être le cas partout.

Souvent, les bons de livraison ne comportent pas les prix parce que ça en regarde pas le magasinier qui va ouvrir le colis. Par contre, il peut y figurer le poids ou le nombre de colis, ce dont fout totalement le comptable qui va traiter la facture. Enfin, une facture peut tenir compte de ristourne pour cause de produit livré endommagé, de remise commerciale, de prise en compte d'un avoir...

Bref, ces trois notions, commande, livraison et facture sont étroitement liées mais sont bien différentes.

Vérifie bien quel est le processus en vigueur chez toi pour valider ton MCD. Une erreur constatée lors de la conception coûte beaucoup moins cher à résoudre que lorsqu'on s'en rend compte lors de la recette du logiciel !

[Ys6BcinMZrSO]

Merci CinePhil pour vos explications
je veux bien conserver le schéma que vous m'avais posté, mais j'ai quelques doutes concernant la transition de ces pièces commerciales entre elles avant de commencer à programmer tout ça, et j’espère que vous m'éclaircir la dessus
Est ce que cet mcd va me permettre de :
1- transformer un bon de commande en un bon de livraison;
2-transformer un bon de commande en plusieurs bons de livraison si par exemple le stock ne me permet pas de couvrir cette commande en attendant l'approvisionnement;
3-generer une facture à partir d'un bon de livraison;
4-regrouper plusieurs bons de livraison dans une seule facture.

[Richard_35]

1- transformer un bon de commande en un bon de livraison; ==> oui.
2-transformer un bon de commande en plusieurs bons de livraison si par exemple le stock ne me permet pas de couvrir cette commande en attendant l'approvisionnement; ==> oui.
3-generer une facture à partir d'un bon de livraison; ==> oui.
4-regrouper plusieurs bons de livraison dans une seule facture. ==> oui.

Mais tu n'as pas clarifié le point suivant :

1 ligne de bon de livraison peut-elle être facturée en plusieurs fois ?

[Ys6BcinMZrSO]

Mais tu n'as pas clarifié le point suivant :

1 ligne de bon de livraison peut-elle être facturée en plusieurs fois ?

Non un ligne livraison ne peut être facturé qu'une seule fois.
est ce que je peut ajouter une identification relative de (1,1) entre commande et ligneCommande et entre LivraisonClient et ligneLivraison?

[Richard_35]

Non un ligne livraison ne peut être facturé qu'une seule fois.

==> OK : voir schéma.

est ce que je peut ajouter une identification relative de (1,1) entre commande et ligneCommande et entre LivraisonClient et ligneLivraison?

==> oui : voir schéma.

Attention, des identifications relatives sont fausses (sous le contrôle de CinePhil) : barrées en rouge.

[CinePhil]

Attention, des identifications relatives sont fausses (sous le contrôle de CinePhil) : barrées en rouge.

Elles ne sont pas fausses mais, comme j'ai dit plus haut :

Ajouter de l'identification relative à partir du client vers la commande et du produit vers la ligne de commande complexifie les clés primaires des tables mais facilite certaines requêtes en évitant de multiples jointures pour remonter de la ligne de facture jusqu'au client ou au produit.

fsmrel est favorable à la propagation de l'identifiant du client et du produit à travers la chaîne commande -> livraison -> facture. S'il passe par là, il pourra sûrement retrouver référence de discussions dans lesquelles il défend ce principe, étayé par son expérience professionnelle.

À moins que j'aie des souvenirs faux de ce qu'il a écrit ?

[Richard_35]

Bonjour Philippe,

.../... la propagation de l'identifiant du client et du produit à travers la chaîne commande -> livraison -> facture.

==> hum... juste pour mon information : la propagation ne veut pas forcément dire identification relative de la cible par rapport à la source, non ?

[CinePhil]

Ben il me semble que si. Tu fais comment pour avoir l'identifiant du client dans la ligne de livraison si tu ne fais pas d'identifications relatives successives depuis l'association client - commande ?

[Richard_35]

Bonjour Philippe,

Ce post très intéressant de Fsmrel illustre l'importance de l'identification relative (que j'avais tendance à sous-estimer). Il est intéressant de constater (je le découvre) que certains outils de modélisation générant des scripts de création de table, traduisent les identifications relatives en "DELETE CASCADE", alors que les identification non relatives sont traduites en "DELETE simples".

Dans le cas qui nous occupe, si le client est supprimé, je ne pense pas qu'il faille supprimer toutes les commandes/livraisons/factures le concernant. En revanche :

• si un entête de commande est supprimé, il n'y aucun intérêt à conserver les lignes détails de cette commande ;
• si un entête de BL est supprimé, il n'y aucun intérêt à conserver les lignes détails de ce BL ;
• si un entête de facture est supprimé, il n'y aucun intérêt à conserver les lignes détails de cette facture.

Comme tu l'as très bien signalé sur un de tes anciens posts, une ligne détail ne vit que parce qu'elle dépend d'un entête, d'où la notion d'identification relative (que vous m'avez fait découvrir Fsmrel et toi, du moins dans sa forme).

Enfin, s'il y a propagation de l'identifiant client, elle devrait s'effectuer au niveau "entête" et non pas au niveau "détail".

[Ys6BcinMZrSO]

Pour les identification relatives je ferai comme il a indiqué Richard_35.
Une dernière chose qui me préoccupe, si je veux facturer plusieurs bon de livraison est ce que je les appelles par leurs numéros (NumLivrClient) ou par l'identifiant de leurs lignes (IdLigneLivr)?
Si la deuxième cas est ce qu'on peut trier les bons de livraison par facture?