APPLICATION DE GESTION
BONJOUR,
svp je fais une application de gestion de stock actuellement et j'ai deja creer le tables articles,entree,sortie. J'aimerais apres l'ajout d'une entree depuis le formulaire,la quantité de l'entrée s'ajoute à celui de la colonne stock de la table article. Merci
Réponses apportées à cette discussion
Salut,
quelle est la question exactement ?
Salut,
j'ai un formulaire qui me permet d'inserer les entrées et j'aimerais que apres l'insertion d'une entrée que la quantité de cette entrée s'ajoute à celle du stock qui se trouve dans la table articles. pour me permettre d'avoir une idée du stock de mes articles. Mais je sais pas quel code me permetra de le faire.Merci
Il y a deux possibilités :
- une requête de mise à jour de la table;
- une procédure stockée liée à un trigger AFTER INSERT ou AFTER UPDATE lors de l'insertion ou de la mise à jour des articles.
Pour la première option, c'est la même chose que d'ajouter des données dans la première table : il faut commencer par récupérer a valeur à modifier, y ajouter ou retrancher la quantité ajouté ou retirée et mettre à jour la table.
La seconde fait directement appel à du SQL un peu plus avancé. Il faudrait créer deux triggers, un AFTER INSERT et un autre AFTER UPDATE, les deux déclenchant une procédure stockée qui va calculer le nombre total d'articles et ensuite mettre à jour l'autre table.
Ceci étant, c'est généralement une mauvaise idée de stocker des valeurs calculées dans une base de données, il est préférable de collecter les informations en les calculant a chaque fois que c'est nécessaire, en s'appuyant sur l'agrégat SUM() avec un GROUP BY sur le type d'article.
Ok donc vous me conseiller l'agrégat SUM() avec un GROUP BY sur l'article?
C'est ça.
En fait, je suppose qu'à chaque nouvel article, vous ajoutez une ligne dans la table, et lorsque vous en vendez un, vous retirez la ligne de la table, non ? Donc pour avoir le nombre total d'articles, il suffit de faire un SUM() sur cet article pour connaitre le nombre qui est encore enregistré.
Mais bien entendu, ça peut dépendre d'un certain nombre de critères et cette solution n,est pas nécessairement la bonne. Je ne dispose pas de toutes les informations.
Par exemple, si chaque article individuel a un numéro de série unique, c'est la bonne solution. Mais si on a juste un numéro d'article qui peut exister en un nombre indéterminé d'exemplaire, il convient d'enregistrer les entrées et les sorties. Typiquement, on enregistrera ces mouvements avec un nombre et une date.
Par exemple, le 12, je rentre 5 nouveaux articles. le 15, j'en vends 3, et puis le 17 j'en vends encore 1. À ce stade, j'aurais trois lignes de données dans la table des mouvements : une avec la date du 12 et un nombre de +5, une autre avec la date du 15 et un mouvement de -3 et enfin une avec la date du 17 et un nombre de -1. Résultat, si je veux l'inventaire, je ferai un SUM sur le nombre. La table des mouvements comportera donc à priori de base 4 colonnes : une colonne mov_id, clé primaire de la table, un art_id, clé étrangère correspondant à l'article pour lequel on enregistre une rentrée ou une sortie, une mov_nombre (INT) et une mov_date (DATETIME).
Mais en fin de course, je n'enregistre aucun total nulle part, je fais le calcul lorsque j'en ai besoin dans la table mouvement avec un GROUP BY sur la colonne art_id.
Bonjour Cyrano excuse pour le temps mis j'etais dans un zone sans connection internet raison pourquoi j'etais pas en ligne! j'ai fais le SUM sur l'article et sa me donne effectivement le nombre total d'article.Merci bien
Mais je coince au niveau de l'ajout ou le retrait de quantité des entrées ou des sorties sur le stock!
Il faudrait que je sache quelle est la structure de données : comment sont agencées les tables avec leurs description et avec quelles colonnes elles sont construites ? Ça me facilitera la vie pour donner une réponse plus appropriée.
J'ai les tables articles (articleid,nom,quantite,stock,date);
entree(numentree,libelle,quantite,societe,date,articleid);
sortie(numsortie,libelle,quantite,service,date,articleid)
j'ai des formulaires qui permettent d'inseré les entrées dans la table entrée et les sorties dans la table sortie. Je souhaite que dès que j'insere une entrée que la quantité de cette entrée puisse aditionner la quantité du stock et pour la sortie que sa puisse soustraire. Je sais pas si je me fais comprendre!
Ok... pas top comme structure, surtout avoir une table pour les entrées et une seconde pour les sorties, au lieu d'une seule table de mouvements.
Par ailleurs, une colonne quantité dans la table articles n'a pas sa place du tout.
On pourrait revoir le tout autrement et surtout plus simplement. On va en profiter pour introduire une convention pour nommer les tables et les colonnes, ça va simplifier par la suite pour le codage.
+----------------+ +------------------+
| t_articles_art | | t_mouvements_mov |
+-----------+----+ +-------------+----+
| art_id | PK | | mov_id | PK |
| art_nom | |---------<| art_id | FK |
| art_stock | | | mov_libelle | |
| art_date | | | mov_sens | |
+-----------+----+ | mov_nombre | |
| mov_date | |
+-------------+----+
Convention de nommage
Les tables sont préfixées par un « t_ » et comportent un suffixe de trois lettres reprenant plus ou moins le nom de la table lui-même (ex. : art pour article)
Le suffixe de la table sera utilisé comme préfixe pour toutes les colonnes sauf pour les clés étrangères. Ici, on voit par exemple dans la table t_mouvement_mov une colonne art_id correspondant à la colonne de la table article qui y est en clé primaire : ça facilite beaucoup la relecture des requête et on s'y retrouve simplement.
La structure
Deux tables et non trois, une pour les articles, mais pas de quantité. J'ai gardé la date pour, à la rigueur, enregistrer la date d'ajout de tout nouvel article. Mais la colonne quantité a sauté. J'ignore à quoi correspond la colonne stock, je l'ai laissé, mais à priori, je serais tenté de la faire sauter aussi. Je n'ai pas ajouté, mais ça pourrait être utile, une colonne art_reference qui pourrait stocker un numéro de référence correspondant à un code barre ou encore une référence interne, à voir selon les besoins.
Utilisation
Là, c'est simple : pour tout nouvel article, on ajoute une ligne dans la table t_article_art et ensuite on ajoute les mouvements dans l'autre table. La première ligne sera à priori une entrée. La colonne mov_sens devrait être de type ENUM('entree','sortie') avec une valeur par défaut à 'entree' par exemple. Dans cette table t_mouvement_mov, on enregistre tout mouvement, l'identifiant de l'article, le libellé (? je ne sais pas trop à quoi ça peut servir, j'ai laissé la colonne), le sens, le nombre et la date du mouvement.
Il devient alors très facile de gérer les stocks et tout aussi simple d'avoir des statistiques sur une période donnée.
Est-ce que ça ne semble pas plus clair de cette façon ?
Oui vraiment claire! Merci!
donc mes entrées et sorties seront stocké dans la table mouvement?
C'est exactement ça.
La table t_articles_art stocke les références produits, la table t_mouvement_mov stocke les entrées et les sorties.
On enregistre chaque mouvement et la donnée n'est en théorie jamais modifiée sauf s'il y a eu une erreur de saisie par exemple. Donc pour un article donné, on aura d'abord une première entrée, puis des lignes d'entrées et des lignes de sorties. Le calcul sera alors très simple pour avoir l'inventaire, on additionnera le total des entrées et on y soustraira le total des sorties. Avec les dates, on pourra ainsi avoir des statistiques de ventes sur une période donnée.
Ok compris j'adapte ma structure à la tienne!
Bonjour sava j'esper, j'ai choisi le type "varchar" pour art_id et "int" pour mov_id . est ce que c'est bon?
Bonsoir Cyrano,stp pour faire l'addition ou la soustraction des entrées et sortie il faut une requete? car suis impeu perdu à ce niveau. Merci de me venir en aide!
Salut,
pas certain de comprendre la question, je crois qu'il faudrait être plus précis en me montrant ce que tu veux faire, même si tu sais que ton code ne fonctionne pas, ça m'indiquera l'idée générale.
Généralement pour calculer des totaux dans une base, on utilise ce qu'on appelle des agrégats, par exemple SUM(nom_de_la_colonne) assorti d'une clause GROUP BY quand on veut un total par catégorie en indiquant la colonne qui contient cette catégorie.
Voici ma requete :
SELECT mov_libelle,mov_sens,SUM(mov_nombre) FROM t_mouvement_mov GROUP BY mov_sens;
sa me donne le total de toutes les entrées et le total de toutes les sorties or je veux le total de chaque articles. Merci pour ta prompt reaction!
Il faudrait la structure des données pour que je sache sur quoi on peut effectuer le GROUP BY.
Là, je suis tenté de penser que le retour ne montre que deux lignes, le total des entrées, et le total des sorties. Quelles sont les colonnes de la table, et quelle table est liée par une clé étrangère pour désigner chaque article ?
J'ai fait la même structure que tu m'as conseillé l'a haut dans tes propositions
Ok, donc il faut rajouter art_id dans le GROUP BY, en plus du mov_sens, ce qui devrait produire deux lignes par articles, une pour les entrées, une pour les sorties.
Super Sa marche ! Merci bien vraiment merci
Mais j'ai un autre soucis car je souhaite avoir une Alerte permettant de me signaler l'état de stock bas de n'importe qu'elle article. Cela est il possible ?
Oui, c'est possible, quoique un peu plus complexe et pointu.
Il faudrait créer deux choses : d'abord une procédure stockée qui exécute une requête afin de repérer quel article a atteint un seuil à partir duquel il faut envoyer une alerte; Ensuite, il faut planifier une tâche. Là, il y a deux méthodes :
- Soit une tâche cron qui va exécuter un code PHP qui fera appel à cette procédure stockée pour définir s'il faut envoyer une alerte d'une manière ou d'une autre (courriel, sms, affichage d'une alerte lors de l'identification de l'administrateur, etc..., à définir);
- Soit utiliser le cron intégré de MySQL pour exécuter la procédure stockée et faire ensuite la même chose que ferait le script PHP. À noter que je ne suis pas certain que cette seconde option permette l'envoi de courriels.
À priori, la tâche cron qui peut être exécuté tous les jour par exemple à 2h00 du matin, voire plusieurs fois par jour, c'est relativement facile à définir. Il suffit pour dé.finir la fréquence de mesurer à quelle vitesse le stock de certains articles baisse et quelle fréquence habituelle est en vigueur pour renouveler le stock.
Voilà, ce ne sont bien entendu que les bases du principe, je te laisse explorer ces techniques et au besoin il faudra revenir me demander pour la mise au point de détails problématiques.
Ok compris,pour la procdure stocker après quelques recherche j'ai vu qu'elle se presente de la sorte:
CREATE PROCEDURE nom_procedure([parametre1[,parametre2...]])
"corps de la procédure"
Pour mon cas la procédure va utiliser m'a precedente requette? à savoir:
CREATE PROCEDURE alerte()
SELECT mov_libelle,mov_sens,SUM(mov_nombre) FROM t_mouvement_mov GROUP BY mov_sens,art_id;
Merci!
Pas de quoi.
Toutefois, il m'est venu à l'esprit une solution peut-être plus simple : un système d'alerte instantanée au moment de l'enregistrement d'une sortie.
Ainsi, au lieu d'une vérification planifiée à heure fixe, ça se ferait en temps réel. Je te laisse réfléchir à cette idée qui sera peut-être plus pratique : là, c'est une question plus fonctionnelle que technique.
Oui oui je pense que cela est plus pratique,comme cela dès la sortie de l'article je peut savoir si cet article à un stock bas!
Je sais pas trop par où commencer, dois-je agire sur ma requête d'insertion de sortie ou bien ?
Salut,
non, il faut de la logique : on ne peut pas savoir quel sera le solde tant que l'insertion ne sera pas effectuée, donc cette insertion doit être terminée. Partant de là, on peut alors effectuer une requête SELECT pour connaitre combien d'articles il reste, et selon ce retour définir s'il faut ou non envoyer une alerte.
Salut
OK
