Discussion :

[alassanediakite]

Salut
Je suis actuellement sur un MCD de société de solution informatique (achat, vente, formation, location, dev...).
Cette question concerne la partie achat-vente.
Faut-il choisir une entité article comme suite...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
article (idarcticle, libelle, enlotde, qttelot, PUlot, #idachat)
où enlotde est le nombre d'élément par lot, qttelot est le nombre de lot  et PUlot le prix du lot.

?...
ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

article (idarcticle, libelle, qtte, PU, #idachat)

?
Sachant que les achats et ventes peuvent être en gros (lot) ou détail (unité simple).
En fait le gros du problème est la fixation des prix unitaire (d'achat ou de vente) quand on achète en gros(prix par lot).
Merci d'avance.

[CinePhil]

D'abord, une entité type "article" ne doit contenir que les propriétés des articles, pas celles sur leurs ventes.

article (art_id, art_reference, art_libelle...)

Si certains articles peuvent être vendus uniquement par lots et d'autres uniquement à l'unité, il suffit de considérer l'unité mini de vente et cette propriété peut être mise dans la table article, ainsi que le prix de vente unitaire de base hors-taxes.

article (art_id, art_reference, art_libelle, art_qte_mini_vente, art_prix_unitaire...)

Si, par contre, certains articles peuvent être vendus tantôt par lot, tantôt à l'unité, avec des prix différents et que le prix de vente par lot n'est pas le résultat d'une formule de calcul uniforme, alors il faut séparer les tarifications des articles.

Règle de gestion :
Un article peut avoir plusieurs tarifs et un tarif correspond à un seul article.

MCD :
article -0,n----avoir----1,1- tarif

Tables :
article (art_id, art_reference, art_libelle...)
tarif (trf_id, trf_id_article, trf_quantite_lot, trf_prix_lot...)

[alassanediakite]

Salut CinePhil
Cela fait un moment que je réfléchie sur le MCD d'achat vente d'une SSI. Le schéma habituel

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

achatVente, TypeArticle, article, ligne_achatVente

pose un gros problème sur la multitude de formes et de types d'articles informatiques. J'ai trouvé comme solution la liaison directe de l'entité [type] article à l'entité achatVente (je fusionne article et ligne_achatVente).
Quant aux tarifs de vente votre modèle est une très bonne solution. Il me suffira de le compléter par un attribut "reduction" au niveau de détail vente.
Je joins le MCD brouillon au format analyseSI. D'ici vos suggestions je me cherche des antimissiles.
Merci d'avance.

[CinePhil]

Je ne peux pas lire ton fichier .asi car je n'utilise pas AnalyseSI.
Poste plutôt une image.

[alassanediakite]

Salut
Voici l'image png.

[JPhi33]

Bonjour alassanediakite,

Si j'ai bien suivi, ce qui te pose problème, c'est de ne pas pouvoir appliquer le schéma habituel : achatVente, TypeArticle, article, ligne_achatVente. Parenthèse : à la place d'AchatVente on trouve parfois Commande.

Tu peux rester dans ce schéma car il répond à ta problématique mais à condition de replacer les propriétés au bon endroit et à spécialiser les articles.
Il semble que ce que tu nommes "article" dans ton post correspond aux entités : "materiel", "logiciel", et aux associations "mat_maintMat" (maintenance matériel ?), "formation_logiciel", "maintlog_log" (maintenance logiciel ?) -- et peut-être d'autres entités ou associations.

Afin d'être générique, tu peux considérer que chaque article est une Prestation. On aurait donc le MCD :

[ Contrat ]--0,n----( ligne_contrat )----0,n--[ Prestation ]

Chaque ligne_contrat porte une quantité qui, selon la prestation représente un nombre d'heures, une fréquence ou une simple quantité (ou autre chose).

Ensuite, il faut spécialiser la prestation en matériel, logiciel, etc.

[ Prestation ]--0,1----( est )----1,1--[ Matériel ]
[ Prestation ]--0,1----( est )----1,1--[ Logiciel ]
[ Prestation ]--0,1----( est )----1,1--[ Maintenance ]
[ Prestation ]--0,1----( est )----1,1--[ Location ]
[ Prestation ]--0,1----( est )----1,1--[ Formation ]
[ Prestation ]--0,1----( est )----1,1--[ ... ]

Les tarifs unitaires prennent leur place dans les entités spécialisées.

C'est un premier jet. Ce principe doit être vérifié avec ton besoin. Notamment, il faut déterminer s'il convient pour l'achat et pour la vente.

Attention, AnalyseSI ne permet pas la spécialisation ("héritage") à moins que ce logiciel n'ait été amélioré dernièrement.

[alassanediakite]

Salut et grand merci
En fait "article" représente seulement "matériel".
Le fait de ne peut utiliser le schéma habituel est plutôt une solution à une partie de mon problème.
Votre schéma est très proche du mien. Moi j'éclate "ligne_contrat" en autant d'entités qu'il y a d'association avec contrat et prestations. Par ailleurs votre entité "ligne_contrat" posera un problème de non homogénéité de données. Une table fourre-tout ne peut pas nous aider dans le calcul des résultats périodiques (bénéfice ou perte) ou solde client...
Par contre votre schéma m'a fait savoir que l'achat de logiciel peut être confronté au même problème de lot (ex: une boite de 3 licences) ou unité (une licence).
@+

[JPhi33]

Bonjour alassanediakite,

En fait "article" représente seulement "matériel".

Il eut été judicieux de l'annoncer dès le départ afin d'éviter les confusions. Evidemment, ceci remet en cause ma proposition puisqu'elle est fondée sur la généricité de l'article (renommé "Prestation" dans ma proposition).