[BDD] Gestion de stocks prévisionnels

Bonjour à tous,

je bosse dans une mairie et le responsable de la restauration m’a posé une colle…

Il veut mettre en place une solution de gestion de stocks assez basique, mais gérant tout de même l’aspect prévisionnel de son boulot.

Je m’explique :

Les menus sont rédigés 3 semaines à l’avance, et il a, aussi, 3 semaines d’avance pour la commande des produits.

Il voudrait donc pouvoir avoir une prévisualisation de son stock dans 3 semaines, afin de pouvoir avoir un état des lieux précis des commandes à passer.

Pour le moment j’avais en tête la structure suivante

Table marchandises :

identifiant, date_entree, quantite, sortie_reelle, sortie_previ

Table References :

identifiant, type, conditionnement

l’objectif, c’est d’avoir, pour les magasiniers, la possibilité d’ajouter et de modifier au reel l’état des stocks, et pour le gestionnaire, en fonction du stock reel et des previsions de consommation, l’état previsionnel à 3 semaines.

Seulement, je pense qu’une fois de plus ma structure est bien trop simpliste et qu’il va me manquer des champs pour des infos auxquelles je pense pas.

De plus, à quoi devrait ressembler la syntaxe de la requete pour remplacer l’identifiant numerique (qui devrait etre un code barre) par le contenu de la ligne correspondante dans la table reference ? (en SQL)

marchi d’avance

mmm rapidement je pense à un truc assez simple:

  • Une table marchandise
    (code_marchandise, nom, stock_reel, code_fournisseur, description)

  • Table fournisseur (pourquoi pas hein)
    (code_fournisseur, nom, adresse etc etc etc)

  • Table EvenementsStock
    (id_eve, type_eve, code_produit, code_fournisseur, date_eve, quantite)

Dans EvenementsStock, le type_eve te permet de dire si c’est de l’achat ou de la vente, et tu peux faire une requete facilement pour un produit donné pour connaitre l’estimation des stocks à j+n en additionant les quantités de la table evenements.

Le champ stock_reel dans la table marchandise te donne la quantité que tu as actuellement dans tes entrepôts. Tu peux ensuite valider les evenements par une petite interface pour mettre à jour ce stock.

Par contre, je n’ai pas très bien suivi ta table References.

en fait j’aimerais à terme que ce systeme puisse être interfacé avec une douchette à codes-barres.

Aussi, pour qu’il fasse la relation « code numérique » == un produit dans un conditionnement etc… (passqu’on compte pas demander aux magasiniers de saisir « 1 boite de petits pois 450g », mais juste de bipper le truc, et que, fonction du code barre, il aille chercher tout seul dans une base de données les caracteristiques du produit)

si je te suis, dans le champ « evenementsstock », le champ « type_eve » contiendrait des trucs genre « sortie reelle, sortie previ, entree » ?

désolé pour les questions de béotien, mais j’ai jamais touché aux bdd autrement que pour faire des sites web à la con :stuck_out_tongue:

Alors, pour le code barre, ce n’est vraiment pas un soucis, il suffit de mettre le sku en identifiant de ta table produit (sku = stock keeping unit, comme on dit dans la jargon ^^). Un code barre ce n’est qu’une chaine de caractère encodée d’une certaine manière, et ta douchette ce qu’elle fait, c’est te retourner cette chaîne, c’est tout. Donc dans ton appli quand tu flashes ton code barre, tu récupères la chaîne et tu t’en sers dans ton select.

Pour le champ type_eve, tu met un peu ce que tu veux dedans. Tu peux très bien y mettre un chiffre (genre 1 -> sorie, 2 -> entrée), ou tu peux mettre un code sur n caractères un peu plus explicite (genre CDV pour commande de vente, CDA pour commande d’achat etc etc). L’avantage de ce système c’est que tu as une table pour n’importe quel type d’événement, et en fonction du type_eve tu sais comment traiter les infos dans ton code.

rien ne t’empêche ensuite de complexifier un peu le schéma, par exemple en considérant qu’un événement peut concerner plusieurs produits, tu peux rajouter une table EvenementStockLignes (code_eve, sku, qt). Tu peux égalemnt te rajouter une table de référence contenant tous les type_eve possible et leur description. Comme ça tu references type_eve dans evenements comme foreign key et tu as un truc à peu près clean ^^