Discussion :

[denissay]

Bonjour à tous,

J'ai réalisé ce mcd en vue de créer une petite application gérant le stock d'une entreprise...



J'y ai mis les entrées (fournisseur) et sorties (achat client)... et j'aimerai bien que quelqu'un puisse me le corriger

Merci d'avace

[pfortin]

Bonjour,

Ton modèle semble plutôt orienté gestion commerciale avec la présence de commandes et factures qui influencent plutôt l'affectation des stocks.
Expédition et Réception ne seraient-ils pas plus adaptés ou manquants ?

Sinon, il donne furieusement envie de généraliser :
- Client et Fournisseur en Partenaire
- Commande et Facture en Flux_Logique
et éventuellement
- Expédition et Réception en Flux_Physique

[denissay]

Salut pfortin

Ces tables-là servents pour garder un historique des opérations...

Sinon, il donne furieusement envie de généraliser :
- Client et Fournisseur en Partenaire

Rassembler ces deux tables en une seule, j'y ai pensé

- Expédition et Réception en Flux_Physique

par contre ici, je ne vois pas ce que ces deux tables sont sensée contenir et donc je ne vois pas où les mettre. Veux tu m'explique d'avantage stp

[denissay]

J'ai modifié le MCD en rassemeblant les tables qui se ressemblent afin d'éviter la redondance...



Qu'est ce qu'il y a d'autre à modifier?

[pfortin]

Salut,

Je pointe juste un doute sur le vocabulaire :
Une commande et une facture peuvent n'engendrer que des flux financiers (pas toujours heureusement).
Ex : les pétroliers font des achats/ventes (flux logiques) dans les réservoirs des dépôts de carburants qui sont purement financiers.
Le carburant reste au même endroit depuis sa réception jusqu'à sa livraison effective (flux physiques).

J'appelle flux logique un changement de propriétaire, flux physique un changement de lieu.
Ca n'est qu'une proposition. L'idée est là, le vocabulaire est adaptable.

A toi de voir ce que tu veux suivre :
- la propriété des produits (achat/vente)
- les documents associés (commande/facture)
- les mouvements de stock (réception/expédition)
...et il en manque...

Mais les dates sont généralement différentes dans chaque cas :
date de commande =/= date de livraison =/= date de facturation =/= date de paiement ...

De toute façon, si tu en a besoin, tout cela peut tenir dans ton nouveau modèle sans vraie modification.

Quelques remarques quand même :
- commande peut être généralisé en document
- penser à gérer le sens de tes flux (quantités positives/négatives ou type de document )
- les documents sont des relations entre 2 partenaires (émetteur et destinataire) bien que l'un soit souvent implicite. On vit bien sans le gérer explicitement dans les cas simples. un homme averti...

[denissay]

Bonsoir pfortin,



J'ai fais quelques modifications:

- J'ai rajouté les tables "Reception" & "Expedition" qui devraient représenter le "Flux physique"... à toi de me dire si je les ai bien intégrées...
- J'ai rajouté une liaisons entre partenaire et produit: permet de voir quels produits sont disponibles chez le fournisseur.

Encore une petite clarification:
- Un client peut se connecter (par internet ou sur place depuis une interface mise à disposition) et reserver un produit qu'il retirera par la suite -ya pas de livraision-
- Si on atteint la quantité de "stock alerte" => besoin d'approvisionnement => on recherche parmis nos fournisseur celui qui a le produit manquant => on créera une commande qui sera reçus par la suite

Merci d'avance

[pfortin]

- J'ai rajouté les tables "Reception" & "Expedition" qui devraient représenter le "Flux physique"... à toi de me dire si je les ai bien intégrées...

Réception et Expédition ont la même structure.
D'où l'idée de n'en faire qu'une entité : Flux Physique avec une Quantité signée ou un type/sens.

Plus généralement, il y a toujours une symétrie dans ces flux dont chacun est une fois émetteur, une fois récepteur.
Toutefois, si tu a besoin d'aller + loin, des informations spécifiques peuvent justifier de les différencier ou de les spécialiser par un héritage.

- J'ai rajouté une liaisons entre partenaire et produit: permet de voir quels produits sont disponibles chez le fournisseur.

Tu viens de créer le Catalogue.

- Un client peut se connecter (par internet ou sur place depuis une interface mise à disposition) et reserver un produit qu'il retirera par la suite -ya pas de livraision-

C'est un mode de livraison particulier (enlèvement par le client).
D'ailleurs, il a son 'Bon de Livraison' : le reçu signé par le client.

- Si on atteint la quantité de "stock alerte" => besoin d'approvisionnement => on recherche parmis nos fournisseur celui qui a le produit manquant => on créera une commande qui sera reçus par la suite

Ca, c'est un traitement. c'est l'objet du MOT dans Merise.

Par contre, j'en profite pour faire une digression sur un piège associé.
<DIGRESS>
Ce traitement semble mettre en lumière l'absence d'une QuantitéEnStock dans produit à comparer au seuil de réapprovisionnement.
Toutefois, si tu as une règle de gestion du genre "Stock = Somme des entrées - Somme des sorties" alors pas besoin de QuantitéEnStock.
Celle-ci peut être calculée (en théorie) à partir des entrées/sorties.
Dans la pratique, les écarts d'inventaire existent et constituent des entrées/sorties particulières (pas de partenaire identifié).
Stocker le résultat d'un calcul est plutôt une mauvaise pratique en base de données (problèmes lors d'accès concurrents) mais peut améliorer grandement les performances.
Quoiqu'il en soit, ceci doit être traité au niveau MLD/MPD.
</DIGRESS>

[denissay]

Bonjour pfortin,

Mise à jours du mcd:

Toutefois, si tu a besoin d'aller + loin, des informations spécifiques peuvent justifier de les différencier ou de les spécialiser par un héritage.

Non, pas besoin

Ca, c'est un traitement. c'est l'objet du MOT dans Merise.

Mouais, je sais, j'ai juste détaillé pour voir s'il manque quelque chose dans le MCD...
Et en pralant du MOT, j'essaie de dessiner un (avec le MCT) sur PowerDesigner (la version anglaise de powerAMC), mais je ne trouve pas comment, je ne retrouve pas les symboles/tableaux correspondants :/ , si tu t'y connais, veux tu bien me guider

Ce traitement semble mettre en lumière l'absence d'une QuantitéEnStock dans produit à comparer au seuil de réapprovisionnement.
Toutefois, si tu as une règle de gestion du genre "Stock = Somme des entrées - Somme des sorties" alors pas besoin de QuantitéEnStock.
Celle-ci peut être calculée (en théorie) à partir des entrées/sorties.
Dans la pratique, les écarts d'inventaire existent et constituent des entrées/sorties particulières (pas de partenaire identifié).

C'est comme ça que je voyais les choses, et je pensais à permettre de faire un inventaire regulier ce qui reduit tout écart possible, mais j'hesite sur la manière de l'integrer dans mon modèle (table à part, ou rajouter dans table existante: Produit en l'occurence)

[pfortin]

Dans quelle unité sont exprimées Montant et Quantité ?

Non, pas besoin

Du coup, Document et Flux Physique se ressembleront beaucoup, elles aussi.
N'y a-t-il pas de date ni de quantités sur une facture ou une commande ?

Par ailleurs, si tu souhaites reconstituer une expédition/commande/..., peut-être faut-il envisager une structure Entête / Détail ou Ligne.

Et en pralant du MOT, j'essaie de dessiner un (avec le MCT) sur PowerDesigner (la version anglaise de powerAMC), mais je ne trouve pas comment, je ne retrouve pas les symboles/tableaux correspondants :/ , si tu t'y connais, veux tu bien me guider

Je ne dispose pas de ce module hélas.
Et mes connaissances manquent de fraicheur.

C'est comme ça que je voyais les choses, et je pensais à permettre de faire un inventaire regulier ce qui reduit tout écart possible, mais j'hesite sur la manière de l'integrer dans mon modèle (table à part, ou rajouter dans table existante: Produit en l'occurence)

L'inventaire sera de toute façon fait, programme ou pas. Le document d'écart lié aussi.
C'est surtout une question d'implémentation.

[pfortin]

Bonjour,

Je serais en vacances à partir de la semaine prochaine.
Pour continuer la réflexion, je vous conseille la lecture de cet article.

Cordialement,

[denissay]

Dans quelle unité sont exprimées Montant et Quantité ?

Je ne vois pas ce que tu insinues parceque je te repondrais bettement que Montant: de type "Money" et Quantité de type "number"...

Du coup, Document et Flux Physique se ressembleront beaucoup, elles aussi.
N'y a-t-il pas de date ni de quantités sur une facture ou une commande ?

Par ailleurs, si tu souhaites reconstituer une expédition/commande/..., peut-être faut-il envisager une structure Entête / Détail ou Ligne.

Ce qui m'emmène à les integrer dans une seule table, en mettant quantité dans la relation "Porter" (ce qui permettra de garder l'historique après...)

Egalement j'ai rajouté un autre type de personne "personnel" (il était temps !! je ne sais pas où j'avais la tête), c'est lui qui gère tous: passe les commandes auprès des fournisseurs, confirme les commandes des clients,....

Je veux que tous soit simple, pas besoin de complications... J'aimerai donc, si tu peux me valider une dernière fois ce modèle et si tu n'y vois pas d'incohérence: cycle ou autre...

Je joins ici le MCD et le MLD correspondant (pour mieux voir)




Merci d'avance

[SmileSoft]

Salut,

Je ne vois pas ce que tu insinues parceque je te repondrais bettement que Montant: de type "Money" et Quantité de type "number"...

Montant est un attribut calculé, il ne doit pas figurer dans un mcd, je crois qu'il faut mettre une entité "ligne de commande" parce que généralement le prix d'un produit change d'une commande à une autre, par conséquent il faut mettre une entité "ligne de facture", voilà cette miniature présente un mcd d'une gestion de stock de produits pharmaceutiques, tu peux t'en inspirer:



et si tu veux t'amuser à lire 161 messages voilà le détails , commences par le 29eme message.

//personnellement j'ai appris beaucoup de choses dans cette discussion.

Bon courage!

[denissay]

Bonjour SmileSoft,

Ta remarque est pertinente (mais où est ce que j'avais la tête )...
J'ai effectué une petite modification: Ajouter prix_unitaire dans l'association "Porter" (qui deviendra une table après)... ça devrait suffir non?

[pfortin]

Bonjour,

Si je comprends bien la devise (€/$/£) et l'unité (unité/kg/m3/boite de 14) sont implicites. Ca ne me pose pas de problème.

Juste une question sur Type_Personne : Un fournisseur peut-il être aussi client (pour un autre produit par ex) ?
Si ces types sont cumulables, tu as un problème et le choix entre 2 solutions :
- proposer toutes les combinaisons autorisées dans le type de donnée (pas très évolutif)
- isoler cela dans une entité (rôle ?) associée à Partenaire

Sinon, ce MCD me semble tout à fait correct.

[Mstreatboy]

Je pense que prix unitaire devrait être une propriété de produit revoit sa.
Quitte à toi de voir les possibilité de remise. Tu peux ajouter des taux dans 'porter'