Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Gestion commerciale
Bonjour,
Je vais développer une application sous Visual Studio permettant la gestion de stock d'un ou de plusieurs magasins. Il y a aussi les mouvements de stocks.
Je souhaite que vous partagiez vos connaissances afin que je puisse améliorer ma base de données.
Est-ce que vous avez des idées pour améliorer cette base ? Si vous pouvez faire une critique, merci d'avance ! Il s'agit d'un projet tutoré.
Il y a le MPD en pj et le script SQL.
Merci d'avance de votre aide,
Cordialement,
Bonjour,
Ton MPD me semble quel que peu étrange.
En effet, déjà, pour moi ce n'est pas une gestion de stock, mais une gestion commerciale (même si elle est très limitée).
Ensuite, je ne vois pas de notion de stock à proprement parler. Il y a une pauvre colonne "quantité en stock" dans la table produit. Et un lien avec le magasin qui passer par les commandes d'approvisionnement.
Ça me semble on ne peut plus étrange.
Soit ton modèle correspond à une problématique très précise, et à ce moment, on ne peut émettre aucune critique avant que tu n'aies énoncé l'ensemble des règles.
Soit ton modèle est affreusement bancal, et il faut commercer par revoir les bases de la modélisation.
En règle générale :
- Un magasin dispose de 1,n dépôts (la surface de vente, la réserve, et éventuellement des dépôts annexes)
- Un dépôt dessert 1,n magasins (un hangar en banlieue peut servir de dépôt à plusieurs magasins dans la ville)
- Un produit peut être présents dans 0,n dépôts. Attention, tous les produits ne sont pas stockables (services, nomenclatures, etc.)
- Un produit peut être une nomenclature (un "ordinateur", c'est une tour, un écran, un clavier, une souris, etc. le tout stocké séparément)
- Certains produits sont suivis par lot (date de péremption, etc.), mais pas tous
- Les dépôts sont généralement suivis par emplacements (travée E, rayon 12 étage 3, tu trouves ton stock de souris du lot X), mais pas tous
- Pour les règles d'affectation du stock à un bon de livraison, il y a des règles qui peuvent être complexes, qui dépendent à la fois du produit, du dépôt, du magasin et du client (FIFO, LIFO, date de péremption la plus proche en dessous d'une limite définie par le contrat client, etc.)
- De la même façon, il y a des formules de réassortiment, afin de proposer automatiquement des commandes d'achat en fonction de critères
- Pour calculer le disponible à la vente, il faut prendre en compte les commandes passée et non livrées, ainsi que les réceptions attendues, et éventuellement le délai de réassortiment, qui dépend du dépôt, du produit et du fournisseur principal du produit pour le dépôt
- On doit pouvoir tracer, à chaque instant, le niveau de stock de chaque produit dans chaque dépôt
- On doit pouvoir faire des inventaires (et ce n'est pas un bête "update" dans la table de stocks)
- On doit pouvoir gérer les stocks tampons de contrôle, allotissement, retours SAV, etc.
- Il y a des produits qui nécessitent d'être stockés à un endroit précis (surgelés, matières dangereuses, etc.)
- Il y a des produits qui ne doivent pas être stockés à moins d'une certaine distance les uns des autres (conbustibles/comburants)
Bref, là je viens de te faire une mini-liste très incomplète de ce qu'une GESCOM (et non un WMS) doit savoir faire en standard. Il y a bien d'autres fonctionnalités propres au WMS (domaine que je ne connais pas du tout).
On ne jouit bien que de ce qu’on partage.
Bonjour,
Je me permets de répondre en public à la question que tu m'as posé en privé (je déteste les messages privés, un forum c'est fait pour que tout le monde profite des discussions et puisse intervenir)
Envoyé par student68
Il s'agit donc bien d'une petite GESCOM (Gestion Commerciale) et non d'un WMS (Warehouse Management System).
Si tu as des questions précises, n'hésite pas à les poser. Moi-même et d'autres personnes seront tout à fait disposés à te répondre.
En revanche, pour t'aider efficacement, il faut beaucoup plus d'informations que ça.
J'imagine que ton sujet de projet c'est pas "Il faut de gérer les ventes, commandes fournisseurs/clients, les mouvements, les dépôts donc mais pas l'emplacement des articles dans le dépôt."
Et en fonction de toutes les règles qui t'ont été données, le modèle des données peut être drastiquement différent.
Je veux bien de donner des pistes, mais attention à ce que "le cas général" que je te présente ne soit pas contraire aux règles précises qui te sont imposées.
Donc attention, tout le pâté qui suit, relève du cas général (je pompe outrageusement le modèle des données d'un ERP que je connais bien).
Dans une GESCOM, on a, niveau entités on a :
Evidement, on a des produits, c'est le nerf de la guerre. On y trouve un fournisseur principal (celui par défaut) ainsi qu'un prix de vente standard, c'est à dire avant toute négociation contractuelle avec les clients. Un produit est classé dans une famille de produits, et est assujetti à un type de TVA donné (standard, réduit, etc.)
Produit (id, nom, fournisseur_principal_id -> Fournisseur[id], prix_vente_standard, famille_id, type_tva)
Et des clients, qui ont une position fiscale donnée (particulier, entreprise, exonéré, corse, DOM, étranger hors UE, étranger UE, etc.) ce qui permet de calculer le taux de TVA
Client (id, nom)
Qui peuvent avoir plusieurs adresses de plusieur type (facturation, livraison, prise de commande, etc.)
AdresseClient (id, type_adresse, client_id -> Client[id], libelle, numero, voie*, code_postal*, ville*, bureau_distributeur*)
* : Toutes les colonnes marquées avec une étoile peuvent donner lieu à des listes de valeur, éventuellement hiérachisées (par exemple pour bureau-distributeur > code_postal > ville > voie)
Un client commande un produit dans une unité donnée, sous un code produit donné, et éventuellement avec un seuil minium et un multiple de quantité (négociés contractuellement)
ReferenceClient (id, client_id -> Client[id], produit_id -> Produit[id], unite_id -> Unite[id], reference, quantite_min, multiple)
Un client peut acheter un produit à un prix différent des autres clients
PrixVente (id, produit_id -> Produit[id], client_id -> Client[id], prix, unite_id Unite[id])
Les quantités sont exprimées en unités
Unite (id, nom)
Et les unités ont des taux de conversion propres aux produits (un "rouleau" de moquette n'a pas le même nombre de mètres qu'un "rouleau" de scotch)
Conversion(id, produit_id -> Produit[id], unite1_id -> Unite[id], unite2_id -> Unite[id], valeur)
On retrouve exactement les même informations pour les fournisseurs
Fournisseur (id, nom)
Qui peuvent avoir plusieurs adresses de plusieur type (facturation, livraison, prise de commande, etc.)
AdresseFournisseur (id, type_adresse, fournisseur_id -> Fournisseur[id], libelle, numero, voie*, code_postal*, ville*, bureau_distributeur*)
* : Toutes les colonnes marquées avec une étoile peuvent donner lieu à des listes de valeur, éventuellement hiérachisées (par exemple pour bureau-distributeur > code_postal > ville > voie)
On commande un produit chez un fournisseur donné dans une unité donnée, sous un code produit donné, et éventuellement avec un seuil minium et un multiple de quantité ainsi qu'un délai de réapprovisionnement (négociés contractuellement)
ReferenceFournisseur (id, fournisseur_id -> Fournisseur[id], produit_id -> Produit[id], unite_id -> Unite[id], reference, quantite_min, multiple, delai_reappro)
Un fournisseur vend un produit à un prix différent des autres fournisseurs
PrixFournisseur (id, produit_id -> Produit[id], client_id -> Client[id], prix, unite_id Unite[id])
Ensuite, on a des commandes de vente.
CommandeVenteEntete (id, client_id -> Client[id], date_commande, libelle, livraison_souhaitee, adresse_commande, adresse_livraison, adresse_facturation)
Qui sont éclatées en lignes. Les informations unite_id, prix et taux_tva, qui sont déduis des autresq tables sont stockés, car ils peuvent être modifiés à la main (le prix notamment) ou évoluer dans le temps (tva par exemple) et doivent donc être stockés dans la commande. On stocke aussi les quantités livrées et perdue, qui servent à savoir si la commande est livrée, en reliquat ou abandonnée.
CommandeVenteLigne (id, commande_vente_entete_id -> CommandeVenteEntete[id], produit_id -> Produit[id], unite_id -> Unite[id], quantite, prix, taux_tva, quantite_perdue);
Ensuite, on livre les lignes de commande (attention, on ne livre pas les commandes, car des produits peuvent être en rupture !). Les livraisons partent d'un dépôt.
LivraisonVenteEntete (id, client_id -> Client[id], date_livraison, adresse_livraison, depot_id -> Depot[id])
LivraisonVenteLigne (id, livraison_vente_entete_id -> LivraisonVenteEntete[id], commande_vente_ligne_id -> CommandeVenteLigne[id], quantite)
On retrouve la même chose pour les factures (attention, on stockera à nouveau toutes les informations de prix dans la facture, car on doit pouvoir la rééditer des années après son émission).
Pour faire ça correctement, il faut aussi gérer les avoirs (facture en montant négatif) et les retours (livraison en quantité négative)
Pour l'achat, c'est passablement la même chose, avec pour détail près qu'on se fait livrer pour un magasin dans un dépôt donné
Pour la TVA, il s'agit d'un tableau croisé entre position fiscale du client et type de tva du produit : (taux arbitraire, je les ai pas en tête)
particulier / produit standard = 20%
particulier / TVA réduite = 7%
corse / produit standard = 13%
corse / TVA réduite = 5.5 %
etc.
On a donc :
TVA (id, position_fiscale, type_tva, taux)
Ensuite, les stocks.
On a des magasins :
Magasin (id, nom, adresse_magasin, depot_magasin)
On a des dépôts :
Depot (id, nom, adresse)
Des dépôts affectés aux magasin :
DepotLivreur (id, depot_id, magasin_id)
Et des stocks (attention, un produit est stocké dans une unité, qui peut être différente de l'unité d'achat ou de revente !)
Stock (id, depot_id, produit_id, quantite_physique, unite_id)
Et des stocks datés (on récopie la ligne de stock en cours avant toute modification, en ajoutant la date)
StockDate (id, depot_id, produit_id, quantite_physique, unite_id, date)
Maintenant, les stocks, c'est joli, mais il faut aussi savoir :
- quand j'aurai ma quantité disponible en stock, histoire de dire au client "ok, là on n'a plus rien, mais on attends une livraison pour demain matin"
- ce qui va sortir de mon stock, histoire de pas dire "ok, je vous livre en fin de semaine", alors qu'une grosse expédition est prévue jeudi, et va vider le stock"
On doit donc faire des vues qui :
- Ajoutent au stock physique l'ensemble des réceptions attendues pour le dépôt, regroupées par date, ainsi qu'une ligne avec une quantité "infinie" positionnée à la date du jour + délai de réappro du fournisseur principal (si je commande 1000 unités, que j'ai rien en attente, et que mon délai de réappro chez mon fournisseur est de 1 mois, alors je dois dire "ok, je peux vous livrer dans 1 mois".
- Retranchent au stock physique l'ensemble des quantités commandées pas encore livrées et pas abandonnées, regroupées par date de livraison prévue.
Ceci permet d'avoir "le stock disponible", jour par jour.
Ensuite, à l'écriture dans les tables "livraisonventeligne" et "receptionachatligne", on doit avoir un trigger qui va incrémenter/décrémenter le stock du dépôt de la quantité saisie.
Le trigger peut aussi écrire dans une table des "mouvements" une trace de ce qu'il a fait :
MouvementStock (id, depot_id, produit_id, unite_id, livraison_ligne_id (nullable), reception_ligne_id (nullable), quantite, unite_id, date)
Ca peut permettre de suivre des changements étrange dans les stocks, ou pour alimenter un outil de BI, de réappro, etc.
Voilà, dans les très grandes lignes.
Après, t'as aussi des notions de taxes parafiscales (la taxe SACEM sur les disques, la taxe sur les boissons sucrée, la taxe éco-emballage, etc.).
Des notions de transfert inter-dépôt.
Des notions de livraison "contremarque" (livraison directement du fournisseur au client, sans passer par le dépôt)
Des notions de consolidation des commandes/réceptions d'achat (les N commandes des magasins sont consolidées en une grosse commande pour chaque fournisseur, et qui livrent ensuite une plateforme de transbordement, qui permettent de charger ensuite les camions de chacun des magasins)
Des notions de tarifs complexes (20% de remise sur une famille de produits donnés si on commande pour au moins 1000 euros d'un produit donné, 2+1 gratuit, etc.)
Des notions de tarifs dégressifs (1 kg = 1 € / 1 tonne = 800 €)
Bon, faut que je m'arrête là, je sens que t'es perdu
On ne jouit bien que de ce qu’on partage.
Bonjour,
Pour l'instant, je ne souhaite pas compliquer le MCD dans le but d'apporter + de fonctionnalités au logiciel que je vais développer, mais je souhaite qu'il soit fonctionnel et cohérent.
Si vous pouvez donc m'apporter vos avis concernant le MCD et une éventuel correction.
Voici une partie des cahiers des charges :
Il s'agit de développer une application sous Visual Studio en csharp.
Un groupe dispose d’environ 10 magasins. Un magasin comporte 5 à 10 personnes. Un gérant peut diriger un ou plusieurs magasins. Le matériel est acheté auprès des fournisseurs. Les clients sont des particuliers.
Lorsque le magasin passe une commande au fournisseur, le fournisseur dressera la facture et après paiement, le fournisseur livre la marchandise au magasin. La livraison est à gérer. Il faudra connaitre la quantité introduite dans le magasin. On fera de même lorsqu’un client passe une commande au magasin. Un client d’un magasin ne commande pas auprès d’un fournisseur. Lorsque qu’il y’a une livraison, il y’a systématiquement un paiement.
Les magasins ont le même nom, ce nom est celui du groupe. Cependant, on doit pouvoir différencier les magasins des uns des autres. Le groupe dispose d’un seul siège social.
La gestion commerciale sera à effectuer. Il faudra gérer les ventes et les achats, mettre en place un système de facturation.
On ne tient pas compte de l'emplacement des produits dans un magasin. Les produits sont systématiquement commandés aux fournisseurs lorsque le stock devient trop faible.
Nous devons avoir la possibilité de livrer une commande dans un magasin X ou un magasin Y. Une commande peut contenir plusieurs produits.
Ce n’est pas parce qu’une commande est faite qu'il y'a une livraison. La livraison s’effectue que si le paiement est effectué. Une commande peut être annulée. Il peut y avoir une remise.
Il n'y a pas de fournisseurs secondaires. Dans le cas d'un achat ou de la vente, on fait une mise à jour du stock. Clients et magasins peuvent faire plusieurs commandes.
Un fournisseur peut fournir plusieurs articles. On ne tiendra pas compte des Unités de quantité. La quantité seule suffira.
Seuls les gérants peuvent organiser des rendez-vous. Un responsable peut organiser aucun ou plusieurs rendez-vous. Il faudra indiquer les personnes concernées par ces rendez-vous et les personnes disponibles. On le répète, il y'a juste en 5 et 10 personnes dans l'entreprise.
Il faudra savoir à qui est concerné la livraison ou une commande.
Pour le mcd :
Paiement ou facture client/magasin sont séparés pour car ça me parait plus clair. Paiement client, c'est quand le client va payer pour sa livraison. Paiement magasin c'est quand le magasin paye pour avoir des articles au fournisseur.
Merci d'avance,
Ça fait très longtemps que j'ai pas regardé de MCD (à vrai dire, depuis que j'ai terminé mes études en 1999
J'aurais moins de mal à lire un MPD qui ressemble plus à ce qu'on trouve dans la base de données.
Du coup je vais pas analyser en détail ton MCD, mais quelques points.
Dans ta réponse, tu m'as indiqué ne pas vouloir complexifier inutilement le modèle : tout ce qui a été omis dans l’énoncé ne sera pas modélisé. Ca me semble en effet prudent pour un projet tutoré, qui n'a de toute façon pas vocation à représenter la réalité, mais à valider tes connaissances et ta capacité à les mettre en oeuvre.
Je vais donc me concenter sur les cardinalités, car j'ai l'impression que tu as introduit inutilement de la complexité à leur niveau.
Une facture donne lieu à 0 ou 1 paiement.
Un paiement concerne une et une seule facture.
Actuellement, tu nous a fais un truc dans lequel un même paiement peut concerner des bouts de plusieurs factures, qui sont elles mêmes honorées par plusieurs paiements partiels. Si c'est bel et bien comme ça que ça se passe dans la réalité, même dans la réalité, on ne s'aventure que rarement à modéliser ça de la sorte, car les rapprochements en compta sont alors un vrai cauchement.
Donc pour moi (au détail près que je sais jamais dans quel sens sont les cardinalités) tu devrais avoir :
Paiement --(0,1)---(Honorer)----(1,1)---- Facture
On retrouve un peu le même problème du le long de cette chaîne : facture-livraison, livraison-commande.
Et le problème est présent aussi sur la partie vente (tu acceptes des livraisons et paiement partiels, je ne pense pas que ce soit désiré).
Il manque, à mon sens, une entité des stocks prévisionnels.
Cette entité n'a aucune utilité d'un point de vue fonctionnel, et peut donc être omise.
En fait, quand tu passes une commande d'achat, la table de stocks prévisionnels doit contenir une entrée physique du produit, avec la date attendue de la réception. Si la date de la réception change, alors la date du mouvement prévisionnel change aussi. Lorsque la réception est effective, alors la ligne dans le stock prévisionnel est supprimée, et les quantités appliquées au stock réel.
Idem pour la vente.
C'est une dénormalisation nécessaire d'un point de vue performances. En effet, si tu te contente d'une vue qui va lire les commandes non soldées (en achat et en vente), tu retrouveras la même information. C'est donc une donnée calculée, qu'on t'a dit de ne pas stocker. Cependant, dans la réalité, le lundi matin, quand 10 personnes dans chacun des magasins va lancer les procédures d'approvisionnement, et saisir les commandes reçues par courrier le week-end, il va y avoir des accès intensifs aux tables de commandes d'achat et de vente, avec certainement des locks.
Il sera donc impossible de consulter les stocks prévisionnels dans de bonnes conditions, d'où l'importance de stocker cette information dans une table à part. En revanche, si tu le met en oeuvre, il faudra bien étayer la raison, car en soit, stocker des données calculées ou en doublon est contraire aux règles de modélisation.
Ensuite, sur les fiche de stock, il manque un seuil de réappro.
Il n'y a pas de lien entre le produit et le fournisseur. Ce lien doit être porteur de l'information délai de réappro.
Pour les rendez-vous, il y a un 1,1 qui ne me plait pas trop. Ca devrait être 1,n car une personne peut être conviée à plusieurs rendez-vous.
Après, j'ai pas regardé tout dans le détail (il faut bien laisser un peu de boulot à ton prof
On ne jouit bien que de ce qu’on partage.
J'ai mis le MPD en p.j histoire que ça vous parle un peu +.
Il est obligatoire de gérer le délai de réapro ?
J'ai modifié l'histoire du rendez-vous. Je n'ai pas touché au système de facturation/paiement. Est-ce que ça pose un réel problème si je ne le fais pas ?
Une grosse question qui m'embrouille : Au MCD, j'ai une association "SeTrouve entre_mp" entre magasin et produit. Ceci permet au client de connaitre les produits+qté dans un magasin. Mais avec ce MCD/MPD, quand le magasin fait une commande au fournisseur, le magasin ignore les produits proposés à la vente non ? Il n'y a pas un problème ?
Je suis pas sur, mais ne fait-il pas qu'un "SeTrouve entre_fp " + la quantité entre Produit et fournisseur ?
Merci beaucoup de l'aide
C'est moins bancal qu'avant hein ? Les jurys trouveront assez de choses à critiquer ...
Les délais de réappro et le seuil de réappro ne sont en effet pas vitaux.
Cependant, le délai permet de donner un délai maximum au client quand il n'y a plus de stocks (ça évite de dire simplement "plus de stock" et empêcher de commander).
Pour ce qui est de la relation entre magasin et produit, c'est à dire la fiche de stock, je ne vois pas de problème.
En revanche, effectivement, si on ne doit pouvoir :
- approvisionner le magasin
- vendre aux client
Que des produits qui ont une fiche de stock dans le magasin (et seulement dans ce cas) alors on peut remplacer, dans le détail des commandes (achat et vente) le lien vers produit par un lien vers la fiche de stock : car en effet, on va commander une quantité à partir de la fiche de stock du magasin, et non plus un produit arbitraire, potentiellement inexistant en stock.
Cependant, ce type de lien est tout sauf évident pour le gars qui repasse derrière. J'aurais tendance à le gérer plutôt à l'aide d'un trigger ou autre règle check. D'autant plus qu'il y a des produits qui ne sont pas suivis en stock (forfait d'installation, de livraison, de montage, etc.), qu'on doit pouvoir commander, mais qui n'ont pas de fiche de stock.
On ne jouit bien que de ce qu’on partage.
Je vais commencer le développement de l'application. Je vais peut être avoir besoin d'aide.
Merci beaucoup !
----
Site Web : http://florianwalther.fr/
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager