Discussion :

[intikman]

Bonjour,

Pour commencer je tiens a vous remercier d'avances pour l'aide que vous allez m'apporter, par contre je vous demanderai d'être indulgent avec moi car je suis débutant et j'apprends.

Je sais que la conception est une partie très important pour la réalisations de projet, mais lors de ma formation de développeur web on a survolé ce volet que j'estime important, bref pour les besoins de réalisation d'une application et afin d'apprendre aussi, j'ai décidé de réaliser une application e-commerce avec livraison.

La partie qui me cause d'énormes problème et le panier, la commande, la livraison et la facture.

Je m'explique le panier sera réalisé a l'aide de la session, donc ma question est est ce que le panier doit figurer dans le MCD ?

je pense que oui et qu'au moment ou le client appuis sur la touche commander la table commande prendra le relais ( c'est mon avis ).

je veux utiliser stripe qui est un moyen de paiement la question est dois-je rajouter une table mode de paiement ou en forme d'attribue sur la ligne de commande ?

j'ai ajouter une table adresse pour différencier une adresse de livraison de celle de facturation dois-je rajouter un type sous forme d'attribue ou créer une table ?

je vous mets en pièce jointe mon MCD et je vous donne ma vision de mon projet concernant les partie ou j'ai besoin d'aide :

un client puisse gérer son panier afin de rajouter un ou des produits

le panier peut posséder aucun produit à plusieurs produits

un client peut passer une commande ou plusieurs

une commande peut avoir zéro ou plusieurs produits

un produit peut avoir une promo

une commande peut avoir de zéro a plusieurs livraisons

une livraison à une seul adresse

une livraison peut avoir de zéro à plusieurs factures

Je vous remercie

[escartefigue]

Bonjour,

Le règles de gestion sont données, c'est très bien, mais un identifiant pour chaque règle aurait facilité les échanges
Par exemple : R001 le panier peut posséder aucun produit à plusieurs produits

Également, les règles de gestion sont exprimées en français, mais le modèle de données utilise des noms en anglais. Il est préférable que les règles et le modèle soient dans la même langue, ça évite les erreurs.
Si votre projet est francophone, conservez le français, sinon, utilisez l'anglais ou la langue du client (sous réserve qu'elle soit maîtrisée bien sur )

De plus, les règles de gestion doivent décrire chaque sens de chaque "patte" d'association, par exemple la règle "Rxxx une livraison à une et une seul adresse " doit être complétée de "Ryyy : une seul adresse fait l'objet de zéro à plusieurs livraisons"

Cette règle "Rzzz une commande peut avoir zéro ou plusieurs produits" implique que vous enregistrez une commande même si aucun produit n'est sélectionné à confirmer.
Si avéré, les cardinalités sont erronées sur le modèle (zéroà n lignes de commande pour une commande)

Supprimez les synonymes : si panier et commande ne font qu'un, choisissez l'un des deux termes et bannissez l'autre du discours, sinon, précisez ce qu'est l'un et l'autre.

Le formalisme de votre modèle est inhabituel. Quel logiciel utilisez vous ?
Il existe de très bon logiciels dont certains sont gratuits qui permettent de réaliser le MCD, d'en dériver le MLD et/ou le MPD et de générer le script.
Parmi ces logiciels, je vous recommande l'excellent Looping (qui ne génère pas encore le MPD sous forme graphique) facile d'utilisation et dont le concepteur Paprick contribue régulièrement dans ce forum

Quelques remarques sur le modèle :

Vous avez modélisé des lignes de commandes et des lignes de factures et vous avez bien fait, mais, aucune de ces deux entités-type n'apparait dans vos règles de gestion.
C'est à corriger. En effet, par exemple, la règle "Rnnn une commande peut avoir zéro ou plusieurs produits" doit être scindée en "Rppp : une commande peut avoir une à plusieurs lignes" et "Rqqq : une ligne de commande concerne un et un seul produit"

Les lignes de commandes comme les lignes de factures sont des entités-type dites "faibles" : elle n'existent pas en l'absence respectivement de la commande et de la facture. De ce fait, il est pertinent d'utiliser l'identification relative, qui, selon les logiciels de modélisation peut se matérialiser par un "R" en suffixe des cardinalités ou de parenthèses pour encadrer celles-ci. La conséquence est qu'au niveau tabulaire, l'identifiant primaire de l'entité-type faible sera composé de la PK de l'entité-type forte augmenté de l'identifiant de l'identité type faible. Par exemple, pour la ligne de facture, la PK sera PK facture + identifiant de ligne.

La ligne de commande possède un attribut "devise" (plutôt que currency), c'est surprenant. Si avéré, il faut rédiger une règle de gestion et externaliser la devise dans une entité-type qui sera en lien avec la ligne de commande.

Il manque beaucoup d'attributs. Dans la facture, le montant HT, TTC et TVA par exemple.

D'après votre modèles, les prix des produits et les promotions sont liées au produit seulement, indépendamment du client, de la date, du montant commandé etc. À confirmer au travers de règles de gestion

[intikman]

Bonjour,

Merci @escartefigue d'avoir pris le temps de me lire.

Le règles de gestion sont données, c'est très bien, mais un identifiant pour chaque règle aurait facilité les échanges
Par exemple : R001 le panier peut posséder aucun produit à plusieurs produits

Comme je l'ai dit dans mon post on a survolé le volet conception lors de la formation, on a appris les MCD MLD MPD userstories ...etc , mais les réglés de gestions on a pas vu ça , c'est en me documentant sur ce forum que j'ai pu écrire quelques lignes.

Par la même occasion je vais revoir mes cardinalités entre commande et produit.

Supprimez les synonymes : si panier et commande ne font qu'un, choisissez l'un des deux termes et bannissez l'autre du discours, sinon, précisez ce qu'est l'un et l'autre.

en faite comme je l'ai dit dans mon premier post je veux un panier en session que gérera le client par la suite une fois confirmé ce panier se transforme en commande, donc panier en session et je ne sais pas s'il doit figurer dans le MCD ou pas, je vais refaire cette partie ou je vais lier le panier et la commande genre Client 1,n ----- gère ----------1,1-panier -1,n---------correspond--------1,1 -ligne de commande -1,1---------correspond ou enregistre---------1,1 -commande et lier la ligne de commande et laissé le reste a l'état actuel.
Sauf si j’enlève le panier du MCD ?!!

lool j'utilise draw.io pour la conception des MCD, mais je vais prendre ton conseil en utilisant looping.

Les lignes de commandes comme les lignes de factures sont des entités-type dites "faibles" : elle n'existent pas en l'absence respectivement de la commande et de la facture. De ce fait, il est pertinent d'utiliser l'identification relative, qui, selon les logiciels de modélisation peut se matérialiser par un "R" en suffixe des cardinalités ou de parenthèses pour encadrer celles-ci. La conséquence est qu'au niveau tabulaire, l'identifiant primaire de l'entité-type faible sera composé de la PK de l'entité-type forte augmenté de l'identifiant de l'identité type faible. Par exemple, pour la ligne de facture, la PK sera PK facture + identifiant de ligne.

Merci pour l'explication.

La ligne de commande possède un attribut "devise" (plutôt que currency), c'est surprenant. Si avéré, il faut rédiger une règle de gestion et externaliser la devise dans une entité-type qui sera en lien avec la ligne de commande.

J'avais mis devise juste la, mais vu que ca sera que des euros je pense l'enlever, mais bonne remarque par rapport une entité type.

Il manque beaucoup d'attributs. Dans la facture, le montant HT, TTC et TVA par exemple.

sur ce plan j'ai beaucoup hésité, car c'est un projet qui concerne la nourriture rapide livrable à domicile et ils ne mettent jamais de TVA même sur des site comme uber deliveroo ou autre, donc du coup faudra que je fouine sur internet pour voir si c'est o=obligatoire de mettre ou pas.

D'après votre modèles, les prix des produits et les promotions sont liées au produit seulement, indépendamment du client, de la date, du montant commandé etc. À confirmer au travers de règles de gestion

J'avoues que ce point m'a fait sué, et je me suis dit que la promotion s'applique sur le produit, donc le prix a l'unité et les réductions sont applicable aux produits seulement pour le reste commande c'est le total qui va apparaître.

En ce qui concerne l'utilisation de l’anglais dans mon MCD, c'est le faite d'avoir pris l'habitude pendant la formation de nommer en anglais les entités, le noms des fonctions ect..

Voila un grand merci et si des personnes veulent me donner leurs avis, je suis preneur.

Je vais refaire mon MCD et le reposer ici avec des règles de gestions

[intikman]

Re !

Je reviens avec un nouveau MCD que j'ai modifié en prenant en compte les conseilles de escartefigue.

Voici les règles de gestions :

un client gére un panier

un panier est géré par un et un seul client

un panier possède une ou plusieurs lignes de commandes

une ligne de commande a un et un seul panier

une ligne de commande contient un et un seul produit

un produit est contenu dans une ou plusieurs lignes de commandes

un produit peut avoir une promotion

une promotion peut être appliqué a plusieurs produits

un produit peut contenir plusieurs photos

une photo est contenu dans a un et un seul produit

une ligne de commande a une et une seule commande

une commande peut avoir une a plusieurs lignes de commandes

une ligne de commande peut comporter plusieurs lignes de livraisons

une ligne de livraison comporte une et une ligne de commande

une ligne de livraison comporte une à plusieurs lignes de factures

une ligne de facture comporte une et une ligne de livraison

une ligne de facture a une et une facture

une facture a une a plusieurs lignes de factures

une ligne de livraison a une et une livraison

une ligne de livraison a une ou plusieurs lignes de livraisons

une livraison a une et une adresse

une adresse peut avoir plusieurs livraisons

Je vous remercie d'avance

[escartefigue]

Je confirme : la TVA est obligatoire !

Pour la devise, si vous ne facturez qu'en euro, inutile d'ajouter cet attribut

N'oubliez pas d'ajouter un identifiant à chaque règle de gestion, c'est bien plus facile de dire
"est ce que la règle R012 a été validée par vos experts métiers"
que de demander
"est ce que la règle qui mentionne << une ligne de livraison comporte une et une ligne de commande >>est validée par la maîtrise d'ouvrage"

Attention aussi à la façon de formuler les règles
"une commande peut avoir une a plusieurs lignes de commandes"
quand on dit "peut avoir", ça sous-entend que la ligne est factultative (mini zéro donc)
il est préférable d'écrire soit
"R027 : une commande peut avoir plusieurs lignes de commandes" => cardinalités 0,n
soit
"R027 : une commande a au moins une ligne de commande" => cardinalités 1,n

[intikman]

Bonjour,

@escartefigue merci pour la réponse apportée, sincèrement c'est un plaisir de vous lire.

J'ai rajouté la TVA sur l'entité produit.

J'ai mis un identifiant sur les règles de gestions :

R0001 un client peut géré un panier

R0002 un panier es géré par un et un seul client

R003 un panier possède au moins une ligne de commande

R004 une ligne de commande est possède par un seul panier

R005 une ligne de commande contient un seul produit

R006 un produit est contenu au moins dans une ligne de commande

R007 un produit peut avoir une promotion

R008 une promotion peut être appliqué à plusieurs produits

R009 un produit peut contenir plusieurs photos

R010 une photo est contenu dans un et un seul produit

R011 une ligne de commande a une et une seule commande

R012 une commande peut avoir plusieurs lignes de commandes

R013 une ligne de commande peut comporter plusieurs lignes de livraisons

R014 une ligne de livraison comporte une et une ligne de commande

R015 une ligne de livraison comporte au moins une ligne de facture

R016 une ligne de facture comporte une et une ligne de livraison

R017 une ligne de facture a une et une facture

R018 une facture a au moins une ligne de facture

R019 une ligne de livraison a une et une livraison

R020 une livraison a au moins une ligne de livraison

R021 une livraison a une et une adresse

R022 une adresse peut avoir plusieurs livraisons

et modifié mon MCD .

j'ai quelque questions :

1- le panier sera géré avec la session, la question est-ce que le panier doit figurer sur le MCD ?

2- le faite de mettre la quantité et le total sur ligne de commande , ligne livraison et ligne de facture n'est pas rébarbatif ?

3- dois-je rajouter une entité type concernant l'entité adresse pour faire la différence entre l'adresse de facturation avec l'adresse de livraison ?

4- enfin est-ce que mon MCD est correcte maintenant ?

Un grand merci

[escartefigue]

Bonsoir intikman

Quelques réponses rapides et peu structurées, toutes mes excuses mais le temps me manque

J'ai rajouté la TVA sur l'entité produit.

Oui mais non la TVA doit être externalisée dans une entité-type et le produit sera en relation avec cette entité-type, faute de quoi, la redondance et tous les maux qui lui sont associés vous menacent !

J'ai mis un identifiant sur les règles de gestions :

Bravo, c'est bien plus pratique

R003 un panier possède au moins une ligne de commande
R004 une ligne de commande est possède par un seul panier
R005 une ligne de commande contient un seul produit

De ces 3 règles, j'en déduis que panier et commande ne font qu'un, exact ?
Et, dans le MCD il semble que "order" soit un autre pseudonyme pour le même acteur, toujours exact ?
Si tel est bien le cas, plutôt que de vous fatiguer (comme les hommes politiques) à user et abuser de synonymes, simplifiez, ne retenez définitivement qu'un seul nom, ce sera bien plus simple pour tout le monde

R006 un produit est contenu au moins dans une ligne de commande

Ce qui implique que vous ne saurez jamais créer un produit dans votre BDD avant qu'il ait été commandé au moins une fois, pas très pratique et bien peu réaliste... à confirmer

R007 un produit peut avoir une promotion
R008 une promotion peut être appliqué à plusieurs produits

Comme mentionné dans une de mes réponses précédentes, je suis surpris que la notion de promotion ne tienne compte ni du volume commandé, ni du montant, ni de la saison
Ça ne ressemble guère à ce qui se pratique habituellement dans le commerce, à vérifier aussi.

R011 une ligne de commande a une et une seule commande
R012 une commande peut avoir plusieurs lignes de commandes

Si commande et panier ne font qu'un (voir plus haut) alors R011=R004 et R012=R005

R013 une ligne de commande peut comporter plusieurs lignes de livraisons
R014 une ligne de livraison comporte une seule et une ligne de commande

N'oubliez pas une et une seule sinon ça n'est pas très clair
OK pour ces règles, ça signifie donc que si je commande 10 brosses à dents et 10 tournevis, je peux très bien recevoir une première livraison de 5 brosses à dents et 2 tournevis, puis, quelques jours plus tard, le reste de ma livraison. Vous confirmez ?



Je m'arrête là pour ce soir, vérifiez bien l'ensemble des points soulevés ici et dans mes réponses précédentes.
Avez vous téléchargé looping ou un logiciel équivalent pour réaliser votre MCD ? C'est tellement plus facile avec. N'hésitez pas !

À bientôt et bon courage

[Paprick]

Bonsoir,

Avez vous téléchargé looping ou un logiciel équivalent pour réaliser votre MCD ? C'est tellement plus facile avec. N'hésitez pas !

Au niveau logiciel, draw.io est intéressant sur un plan purement graphique, même s'il ne respecte pas le formalisme E/A normalement utilisé pour les MCD.
Cependant, je rejoins l'avis de escartefigue et, sans rentrer pour le moment dans le détail de votre projet, je pense que vous devriez, avant tout, définir un MCD qui respecte le formalisme Entité-Association (cf. Merise), ou alors UML avec le diagramme de classes, ce qui rendrait votre modèle beaucoup facile à lire, et nous permettrait de mieux vous aider sur la phase de conception.
Il existe pas mal d'outils pour réaliser ces MCD qui, en plus, permettront ensuite de générer automatiquement le MLD et le schéma relationnel correspondant pour le SGBD de votre choix ; voici quelques exemples : Win'Design, Power-AMC, JMerise, Looping, ...

Bon courage pour votre projet.

[intikman]

Bonsoir,

Sur conseil de @escartefigue et @Paprick , j'ai refait mon MCD avec le logiciel Looping et par la même occasion, j'ai refait les règles de gestion.

J'ai aussi mis un petit bout de mon cahier des charges, et je commence par ce dernier.

- un client peut commande un ou plusieurs produits

- la commande peut être livré en un ou plusieurs livraisons

- une facture de livraison peut être générée à la demande pour chaque livraison

- un client peut avoir une adresse différente pour la livraison par rapport a l'adresse de la facturation.

Règles de gestions :

R001 un client peut passer plusieurs commandes

R002 une commande a un et un seul client

R003 une commande concerne au moins une ligne de commande

R004 une ligne de commande concerne une et une seule commande

R005 une ligne de commande est composée d'un et un seul produit

R006 un produit peut composer une ligne de commande

R007 une ligne de commande peut associer plusieurs lignes de livraisons

R008 une ligne de livraison est associée a une et une seule ligne de commande

R009 une ligne de livraison peut se référer à des lignes de factures

R010 une ligne de facture se réfère a une et une seule ligne de commande

R011 une ligne de facture contient une et une seule facture

R012 une facture contient au moins une ligne de commande

R013 une ligne de livraison se réfère a une et une seule livraison

R014 une livraison se réfère au moins a une ligne de livraison

R015 une livraison a une et une seule adresse

R016 une adresse peut avoir des livraisons

R017 une adresse possède un et un seul utilisateur

R018 un utilisateur possède au moins une adresse

R019 une promotion peut déduire des lignes de commandes

R020 une ligne de commande déduit une et une promotion

R021 une promotion peut déduire des lignes de factures

R022 une ligne de facture déduit une et une seule promotion

R023 une TVA peut être appliquée a des lignes de commandes

R024 une ligne de commande s'applique sur une et une seule TVA

R025 une TVA peut s'appliquer sur des lignes de factures

R026 une ligne de facture s'applique sur une et une seule TVA

Au passage merci à vous deux d'avoir répondu.

[escartefigue]

en faite comme je l'ai dit dans mon premier post je veux un panier en session que gérera le client par la suite une fois confirmé ce panier se transforme en commande, donc panier en session et je ne sais pas s'il doit figurer dans le MCD ou pas, je vais refaire cette partie ou je vais lier le panier et la commande genre Client 1,n ----- gère ----------1,1-panier -1,n---------correspond--------1,1 -ligne de commande -1,1---------correspond ou enregistre---------1,1 -commande et lier la ligne de commande et laissé le reste a l'état actuel.
Sauf si j’enlève le panier du MCD

Oups, désolé, j'avais loupé cette réponse.
Si la commande est un panier validé, alors ce n'est qu'un statut particulier du panier, on peut ne conserver qu'un seul terme.


À ce sujet :

En ce qui concerne l'utilisation de l’anglais dans mon MCD, c'est le faite d'avoir pris l'habitude pendant la formation de nommer en anglais les entités, le noms des fonctions ect...

L'anglais est parfait s'il s'agit d'un projet international, sous condition que les intervenants maîtrisent la langue et de faire attention aux pièges des mots réservés SQL plus fréquents si on nomme les objets en anglais qu'en français.
(on peut éviter ces pièges en utilisant des astuces de nommage telles que l'utilisation de préfixes ou de suffixes)
Si le projet est francophone, simplifiez vous la vie et nommez tous les objets en français (entités-type, associations, attributs, rôles)
Dans les deux cas, il est préférable d'utiliser les mêmes noms dans les règles et dans le MCD

Attention : le MCD n'est pas toujours conforme aux règles, par exemple, de produit (plutôt que product) vers ligne de commande (plutôt qu'order line) le MCD mentionne 0,n alors que R006 indique " R006 un produit peut composer une ligne de commande" soit 0,1. C'est le MCD qui a raison, sans quoi vous ne pouvez pas connaître un produit tant qu'il n'est pas commandé .

[intikman]

Re !

Merci @escartefigue pour la réponse , j'ai effectivement décidé de créer un panier avec une session au moment ou le client clique sur commander (donc validé) c'est une commande.

pour la règle de gestion R006 une petite erreur s'est glissée il fallait effectivement lire " R006 un produit peut être compose de plusieurs lignes de commandes ".

J'aimerai avoir un retour (complet) sur le dernier MCD a part le faite que les entités et attribues soit en anglais car j'ai d'autres questions par la suite.

encore une fois un grand merci, sincèrement j'apprends beaucoup par vos réponses et le faite d'aller aussi parcourir le forum, spécialement la section Modélisation.

[escartefigue]

J'aimerai avoir un retour (complet) sur le dernier MCD a part le faite que les entités et attribues soit en anglais car j'ai d'autres questions par la suite.

encore une fois un grand merci, sincèrement j'apprends beaucoup par vos réponses et le faite d'aller aussi parcourir le forum, spécialement la section Modélisation.

Content d'avoir pu rendre service , n'hésitez pas à voter en faveur des réponses qui ont pu être utiles, voire à désapprouver celles qui font fausse route (auquel cas il est indispensable d'expliquer pourquoi, sinon on ne peut pas s'améliorer ). Les pouces verts et rouges sont là pour ça

Je n'aurai pas le temps de répondre exhaustivement, c'est qu'il est conséquent le modèle , mais voici un début :

CLIENT (user) passer COMMANDE (order)
RàS : c'est conforme aux règles R001 et R002
Tout au plus, par cohérence, je reformulerai R002 pour utiliser le même verbe que dans R001 (et donc nommer l'association) ainsi : R002 commande a est passée par un et un seul client
Coté client, si phone_number est enregistré ici, c'est que tout client a un et un seul numéro de téléphone utile pour votre gestion.
Si vous avez besoin dans certains cas de connaître plusieurs n° (n° bureau, n° portable perso, n° d'astreinte...) alors il faut créer une entité-type distincte en relation 0,n ou 1,n avec le client.


COMMANDE (order) concerne LIGNE DE COMMANDE (order line)
le modèle est conforme à R003 et R004
L'attribut CREATED_AT, s'il s'agit de la date de création, est un attribut technique que vous pouvez ajouter dans tous les types d'entité, ainsi que la date (et heure si besoin) de MàJ, le user de création et le user de MàJ.
Toujours utile pour la traçabilité.
Qu'est ce que le statut d'une commande ? à préciser dans les règles de gestion


LIGNE DE COMMANDE composer PRODUIT (product)
le modèle est conforme à R005 et R006
Je ne suis pas fan de l'identification de la ligne de commande relativement au produit : on peut concevoir que si le produit "A" est remplacé par un produit "B" équivalent, la ligne de commande subsiste. À l'inverse, si la commande disparaît (le client change d'avis), alors là oui, plus question de conserver les lignes de commande.
Donc : conservez l'identification relativement à la commande, mais pas au produit


LIGNE DE COMMANDE associer LIGNE DE LIVRAISON (delivery line)
le modèle est conforme à R007 et R008
La quantité livrée est présente, mais pas la quantité acceptée : voir si elle n'est pas nécessaire (au regard du bordereau de livraison signé par le client, présence de réserves, produits détruits lors du transport...)
Remarque d'ordre général sur les quantités, toutes entités-type et associations confondues : sauf si tous les produits s'expriment selon la même unité de mesure (par exemple au kilogramme), il est nécessaire de préciser en regard de chaque quantité, l'unité de mesure de cette quantité (pièce, mètre linéaire, kilogramme, sachet, litre...).


LIGNE DE LIVRAISON se référer LIGNE DE FACTURE (bill line)
Les règles de gestion sont
R009 une ligne de livraison peut se référer à des lignes de factures
R010 une ligne de facture se réfère a une et une seule ligne de commande
Ce qui ne va pas
Il faut savoir s'il faut facturer la commande ou la livraison.
De plus, vous n'avez pas modélisé le lettrage qui est la façon classique de rapprocher ligne de facture et ligne de commande (ou peut être de livraison selon la réponse à ce qui précède).


J'arrête ici pour ce soir, le devoir m'appelle

[intikman]

Re !

Tout au plus, par cohérence, je reformulerai R002 pour utiliser le même verbe que dans R001 (et donc nommer l'association) ainsi : R002 commande a est passée par un et un seul client
Coté client, si phone_number est enregistré ici, c'est que tout client a un et un seul numéro de téléphone utile pour votre gestion.
Si vous avez besoin dans certains cas de connaître plusieurs n° (n° bureau, n° portable perso, n° d'astreinte...) alors il faut créer une entité-type distincte en relation 0,n ou 1,n avec le client.

Merci pour le conseille, et effectivement je souhaite juste un numéro par client que celui ci pourra changer par la suite s'il le veut, car l'idée dans un premier temps et que le client confirme son numéro de téléphone et renseignant le code reçu par SMS.

Qu'est ce que le statut d'une commande ? à préciser dans les règles de gestion

Le statut je pense peut être mettre un booléen (pas sure encore) pour une commande en attente ou confirmée.

Donc : conservez l'identification relativement à la commande, mais pas au produit

D’après ce que je comprends , je dois enlever "id_order_line" ?

le modèle est conforme à R007 et R008
La quantité livrée est présente, mais pas la quantité acceptée : voir si elle n'est pas nécessaire (au regard du bordereau de livraison signé par le client, présence de réserves, produits détruits lors du transport...)
Remarque d'ordre général sur les quantités, toutes entités-type et associations confondues : sauf si tous les produits s'expriment selon la même unité de mesure (par exemple au kilogramme), il est nécessaire de préciser en regard de chaque quantité, l'unité de mesure de cette quantité (pièce, mètre linéaire, kilogramme, sachet, litre...).

ça sera la même quantité entre la ligne de commande et de livraison, concernant l'unité dans un premier temps ça sera par pièce, mais plus tard j'utiliserai de d'autres unités.

R009 une ligne de livraison peut se référer à des lignes de factures
R010 une ligne de facture se réfère a une et une seule ligne de commande
Ce qui ne va pas
Il faut savoir s'il faut facturer la commande ou la livraison.

petite erreur de ma part c'est bien "livraison et pas commande"n

De plus, vous n'avez pas modélisé le lettrage qui est la façon classique de rapprocher ligne de facture et ligne de commande (ou peut être de livraison selon la réponse à ce qui précède).

La j'avoues que je suis perdu par rapport au lettrage, je ne vois pas ce qu'il faut faire malgré avoir compris le problème et j'ai bien lu "Parlez vous merise" à la page 63, mais pour ma part dans ma tête j'allai gérer avec l'utilisateur courant.

Dernier point à chaque fois j'ai voté, j'arrive a voir ça de mon coté.

J'attends votre réponse avec impatience.

[escartefigue]

Merci pour le conseille, et effectivement je souhaite juste un numéro par client que celui ci pourra changer par la suite s'il le veut, car l'idée dans un premier temps et que le client confirme son numéro de téléphone et renseignant le code reçu par SMS.

En ce cas inutile de compliquer le modèle, restons en à un numéro unique il sera toujours possible de faire évoluer le modèle l

D’après ce que je comprends , je dois enlever "id_order_line" ?

De "order_line" vers "order" via "concerne" on conserve la coche dans la case "identifiant relatif" de la patte coté "order_line" : l'identifiant de la commande contribuera à la PK de la table issue de "order_line"
De "order_line" vers "product" via "composer" on supprime cette coche : l'identifiant du produit ne sera qu'une clef étrangère ne participant pas à la PK de la table issue de "order_line"

ça sera la même quantité entre la ligne de commande et de livraison, concernant l'unité dans un premier temps ça sera par pièce, mais plus tard j'utiliserai de d'autres unités.

En fait ça dépend surtout du type de produits que vous proposez et du type de commerce.
Par exemple, en quincaillerie, les peintures sont vendues au litre, les barres métalliques au mètre linéaire, les boulons en sachets, les tondeuses de jardin à l'unité, il existe également des kits...

petite erreur de ma part c'est bien "livraison et pas commande"n

du coup un coup de peinture fraîche sur la règle de gestion concernée s'impose

La j'avoues que je suis perdu par rapport au lettrage, je ne vois pas ce qu'il faut faire malgré avoir compris le problème et j'ai bien lu "Parlez vous merise" à la page 63, mais pour ma part dans ma tête j'allai gérer avec l'utilisateur courant.

Il y a des lustres que je n'ai pas travaillé dans le domaine comptable et celui de la facturation. Je ne serai donc pas d'un grand secours.
Ce qui faut retenir c'est que tant la facturation que la comptabilité sont des domaines réglementés. Il convient donc de bien faire lire, relire et valider les règles de gestion dans ces domaines par les experts de ces métiers.

[intikman]

Re !

De "order_line" vers "order" via "concerne" on conserve la coche dans la case "identifiant relatif" de la patte coté "order_line" : l'identifiant de la commande contribuera à la PK de la table issue de "order_line"
De "order_line" vers "product" via "composer" on supprime cette coche : l'identifiant du produit ne sera qu'une clef étrangère ne participant pas à la PK de la table issue de "order_line"

La je comprends mieux et je trouve que tu as tout à fait raison que tu disais

Je ne suis pas fan de l'identification de la ligne de commande relativement au produit : on peut concevoir que si le produit "A" est remplacé par un produit "B" équivalent, la ligne de commande subsiste. À l'inverse, si la commande disparaît (le client change d'avis), alors là oui, plus question de conserver les lignes de commande.

.

du coup un coup de peinture fraîche sur la règle de gestion concernée s'impose

C'est bon pour le coup de peinture

Il y a des lustres que je n'ai pas travaillé dans le domaine comptable et celui de la facturation. Je ne serai donc pas d'un grand secours.
Ce qui faut retenir c'est que tant la facturation que la comptabilité sont des domaines réglementés. Il convient donc de bien faire lire, relire et valider les règles de gestion dans ces domaines par les experts de ces métiers.

Je comprends pourquoi notre ami google m'envoyé à chaque fois sur des réponses de comptabilité, je verrai ça en profondeur plus tard.

Je voudrai savoir si maintenant tout est nickel, pour mon MCD (coté Client, Commande, Livraison et facture) car j'ai d'autres questions.

Merci

[escartefigue]

Bonjour,

Quelques éléments supplémentaires

Ces règles de gestion sont mal formulées :

R019 une promotion peut déduire des lignes de commandes
R020 une ligne de commande déduit une et une promotion
R021 une promotion peut déduire des lignes de factures
R022 une ligne de facture déduit une et une seule promotion

il n'est pas question de déduire des lignes de commande, de facture ou autre (ce qui reviendrait à supprimer certaines lignes ), une promotion applique une déduction sur un montant, ce n'est pas la même chose
Vous n'avez pas donné de règle de gestion concernant les critères d'éligibilité aux promotions. Ce point est important, même si c'est "à la tête du client", il est préférable de l'écrire (la maîtrise d'ouvrage aura peut être quelques réticences à signer une règle de gestion stipulant que le vendeur est libre d'appliquer telle ou telle promotion sans le moindre critère d'application)



ORDER_LINE - DISCOUNT - BILL_LINE
Ici, il faut rappeler que selon R007, vous pouvez livrer une même ligne de commande en plusieurs fois et donc, par transitivité, avoir plusieurs lignes de facture pour une même ligne de commande
Du coup, si vous passez par l'association "déduire" vous obtenez un et un seul montant déduit pour une ligne de commande, mais si vous passez par les lignes de livraison et de facture puis par "deduire-2" vous pouvez avoir plusieurs fois le même montant déduit pour cette même ligne de commande...
Donc, soit la déduction s'applique sur la quantité commandée, soit elle s'applique sur la quantité livrée et donc facturée. Selon le cas, choisissez le chemin qui correspond



VAT
En France, les taux de TVA changent de temps en temps. Cf. https://www.tvacalc.com/info/30/Hist...ux-de-TVA.html
Pour faciliter les changements de taux, il est pratique d'ajouter des attributs date de début et date de fin de validité du taux.



CLIENT (user) - ADRESSE
La traduction est très approximative, ici on parle bien de clients puisqu'il s'agit de personne qui passent des commandes et qui sont ensuite facturés.
Si l'anglais devait être conservé pour les objets base de données, alors il faut nommer l'entité-type (qui deviendra une table) "CUSTOMER" ou "CLIENT" au choix.
Les cardinalités indiquent 1 à n adresses pour un client et 1 et 1 seul client pour une adresse. C'est conforme aux règles R017 et R018.
Si les différentes adresses sont prévues pour gérer adresse de livraison, de facturation... alors pensez à typer les adresses en ajoutant une nouvelle entité-type "TYPE ADRESSE" en relation 0,n --1,1 avec les adresses


Bon courage pour la suite

[intikman]

Bonjour,

Encore une fois merci pour les réponses apportées.

il n'est pas question de déduire des lignes de commande, de facture ou autre (ce qui reviendrait à supprimer certaines lignes ), une promotion applique une déduction sur un montant, ce n'est pas la même chose
Vous n'avez pas donné de règle de gestion concernant les critères d'éligibilité aux promotions. Ce point est important, même si c'est "à la tête du client", il est préférable de l'écrire (la maîtrise d'ouvrage aura peut être quelques réticences à signer une règle de gestion stipulant que le vendeur est libre d'appliquer telle ou telle promotion sans le moindre critère d'application)

C'est rectifié et les règles de gestions R021 et R022 ont été changé.

Donc, soit la déduction s'applique sur la quantité commandée, soit elle s'applique sur la quantité livrée et donc facturée. Selon le cas, choisissez le chemin qui correspond

J'ai failli mettre la clé sous la porte avant même de commencer .

En France, les taux de TVA changent de temps en temps. Cf. https://www.tvacalc.com/info/30/Hist...ux-de-TVA.html
Pour faciliter les changements de taux, il est pratique d'ajouter des attributs date de début et date de fin de validité du taux

C'est fait aussi.

Si les différentes adresses sont prévues pour gérer adresse de livraison, de facturation... alors pensez à typer les adresses en ajoutant une nouvelle entité-type "TYPE ADRESSE" en relation 0,n --1,1 avec les adresses

c'est fait et c'était l'une des questions que j'allais poser après validation du MCD.

La traduction est très approximative, ici on parle bien de clients puisqu'il s'agit de personne qui passent des commandes et qui sont ensuite facturés.
Si l'anglais devait être conservé pour les objets base de données, alors il faut nommer l'entité-type (qui deviendra une table) "CUSTOMER" ou "CLIENT" au choix

Justement une autre question après la validation de mon MCD, car je pense renommer l'entité "user" en "person" et créer deux entités une pour le client et une autre pour le fournisseur propriétaire du magasin, dés validation du MCD, je poserai la question avec plus de données pour mieux comprendre.

Je joint mes nouvelles règles de gestions :

R001 un client peut passer plusieurs commandes

R002 une commande a un et un seul client

R003 une commande concerne au moins une ligne de commande

R004 une ligne de commande concerne une et une seule commande

R005 une ligne de commande est composée d'un et un seul produit

R006 un produit peut composer une ligne de commande

R007 une ligne de commande peut associer plusieurs lignes de livraisons

R008 une ligne de livraison est associée a une et une seule ligne de commande

R009 une ligne de livraison peut se référer à des lignes de factures

R010 une ligne de facture se réfère a une et une seule ligne de livraison

R011 une ligne de facture contient une et une seule facture

R012 une facture contient au moins une ligne de commande

R013 une ligne de livraison se réfère a une et une seule livraison

R014 une livraison se réfère au moins a une ligne de livraison

R015 une livraison a une et une seule adresse

R016 une adresse peut avoir des livraisons

R017 une adresse possédé un et un seul utilisateur

R018 un utilisateur possédé au moins une adresse

R019 une promotion peut appliquer une déduction sur le montant des lignes de commandes

R020 sur un montant d'une ligne de commande s'applique une et une déduction de la promotion

R021 une adresse peut être définie comme adresse type

R022 un adresse type est défini comme une et une seule adresse

R023 une TVA peut être appliquée a des lignes de commandes

R024 une ligne de commande s'applique sur une et une seule TVA

R025 une TVA peut s'appliquer sur des lignes de factures

R026 une ligne de facture s'applique sur une et une seule TVA

ainsi que le nouveau MCD

Merci

[escartefigue]

Bonjour

Je n'ai pas déserté, mais un douloureux lumbago m'empêche de rester assis plus de quelques minutes, du coup je suis beaucoup moins actif en ce moment .

Puisque nous travaillons semble-t-il tous les deux avec looping, je propose d'échanger directement le MCD sous forme de PJ, ce sera plus simple

[intikman]

Bonjour,

Bonjour

Je n'ai pas déserté, mais un douloureux lumbago m'empêche de rester assis plus de quelques minutes, du coup je suis beaucoup moins actif en ce moment .

Puisque nous travaillons semble-t-il tous les deux avec looping, je propose d'échanger directement le MCD sous forme de PJ, ce sera plus simple

Je n'en doute pas, et je comprends qu'on ait d'autres choses à faire, de mon côté je continue d'améliorer le MCD que je pourrai t'envoyer en PJ.

encore une fois merci et prompt rétablissement.

[intikman]

Re !

Voila je joints un nouveau MCD ou j'ai rajouté un héritage, c'est la premier fois que j'utilise ça, en tant normal, j'aurais créé deux entités client et fournisseur que j'aurais relié a l'entité personne via des relations.

Mais bref je dois apprendre aussi des nouvelles choses, ma seule crainte c'est la représentation de cet héritage au niveau de ma future BDD.

voici les règles de gestions ou j'ai rajouté les réglés 025 et 026, mais je me pose la question si j'ai bien fait de mettre en relation le ligne de commande avec paiement si je n'aurais pas du relier avec facture.

R001 un client peut passer plusieurs commandes

R002 une commande a un et un seul client

R003 une commande concerne au moins une ligne de commande

R004 une ligne de commande concerne une et une seule commande

R005 une ligne de commande est composée d'un et un seul produit

R006 un produit peut composer une ligne de commande

R007 une ligne de commande peut associer plusieurs lignes de livraisons

R008 une ligne de livraison est associée a une et une seule ligne de commande

R009 une ligne de livraison peut se référer à des lignes de factures

R010 une ligne de facture se réfère a une et une seule ligne de livraison

R011 une ligne de facture contient une et une seule facture

R012 une facture contient au moins une ligne de commande

R013 une ligne de livraison se réfère a une et une seule livraison

R014 une livraison se réfère au moins a une ligne de livraison

R015 une livraison a une et une seule adresse

R016 une adresse peut avoir des livraisons

R017 une adresse possède un et un seul client

R018 un client possède au moins une adresse

R019 une promotion peut appliquer une déduction sur le montant des lignes de commandes

R020 sur un montant d'une ligne de commande s'applique une et une déduction de la promotion

R021 une adresse peut être définie comme adresse type

R022 un adresse type est défini comme une et une seule adresse

R023 une TVA peut être appliquée a des lignes de commandes

R024 une ligne de commande s'applique sur une et une seule TVA

R025 une ligne de commande est réglé par un et un seul paiement

R026 un paiement règle au moins une ligne de commande

R027 un paiement utilise au moins une méthode de paiement

R028 une méthode de paiement utilise un et un seul paiement

en le MCD est en pièce jointe

Un grand merci