Requete qui calcul le stock
Résolu
Oholabi12345
Messages postés
498
Date d'inscription
Statut
Membre
Dernière intervention
-
Tessel75 -
Tessel75 -
A voir également:
- Requete qui calcul le stock
- Calcul moyenne excel - Guide
- Calcul km marche à pied gratuit - Télécharger - Sport
- Où est stocké le presse-papier - Guide
- Calcul charpente bois gratuit - Télécharger - Architecture & Déco
- Logiciel gratuit calcul valeur nutritionnelle - Télécharger - Santé & Bien-être
5 réponses
Bonjour,
Quand l'une ou plusieurs des tables peut ne pas avoir de correspondance il faut utiliser une jointure externe (OUTER JOIN)
Après si plusieurs entrées et plusieurs sortie, il faut un GROUP BY et un SUM().
Enfin moi je commencerait par la table produit et outer join sur entrée puis sorties.
Je n'utilise pas access mais on aurait quelque chose comme
Quand l'une ou plusieurs des tables peut ne pas avoir de correspondance il faut utiliser une jointure externe (OUTER JOIN)
Après si plusieurs entrées et plusieurs sortie, il faut un GROUP BY et un SUM().
Enfin moi je commencerait par la table produit et outer join sur entrée puis sorties.
Je n'utilise pas access mais on aurait quelque chose comme
select produit.idproduit, sum(quantiteentree), sum(quantitesortie) from produit left outer join entree on produit.idproduit = entree.idproduit left outer join sortie on produit.idproduit = sortie.idproduit group by produit.idproduit
jai complété le code en tenant compte du secteur dans lequel les produits sont affectés ; en fait la table R_entree permet d'affecter les produits a un secteur bien defini ; le stock fonctionne mais quand les memes produits sont sortis ( vendus) à des secteurs differents il diminue le stock dans les differents secteurs;voici le code :
SELECT produit.idproduit, Sum(R_ENTREE.quantitentree) AS SommeDequantitentree, Sum(R_SORTIE.quantitesortie) AS SommeDequantitesortie, [quantitentree]-[quantitesortie] AS STOCKVRAIE, R_ENTREE.IdSecteur
FROM (produit INNER JOIN R_ENTREE ON produit.idproduit = R_ENTREE.idproduit) LEFT JOIN R_SORTIE ON produit.idproduit = R_SORTIE.idproduit
GROUP BY produit.idproduit, [quantitentree]-[quantitesortie], R_ENTREE.IdSecteur;
SELECT produit.idproduit, Sum(R_ENTREE.quantitentree) AS SommeDequantitentree, Sum(R_SORTIE.quantitesortie) AS SommeDequantitesortie, [quantitentree]-[quantitesortie] AS STOCKVRAIE, R_ENTREE.IdSecteur
FROM (produit INNER JOIN R_ENTREE ON produit.idproduit = R_ENTREE.idproduit) LEFT JOIN R_SORTIE ON produit.idproduit = R_SORTIE.idproduit
GROUP BY produit.idproduit, [quantitentree]-[quantitesortie], R_ENTREE.IdSecteur;
pourquoi ne pas prendre en compte tous les critères voulus au départ !!!
le group by sur [quantitentree]-[quantitesortie] est tout a fait incongru ;-))
sur entree et sortie tu devrais considérer le secteur dans la jointure
le group by sur [quantitentree]-[quantitesortie] est tout a fait incongru ;-))
sur entree et sortie tu devrais considérer le secteur dans la jointure
SELECT produit.idproduit, R_ENTREE.IdSecteur, Sum(R_ENTREE.quantitentree) AS SommeDequantitentree, Sum(R_SORTIE.quantitesortie) AS SommeDequantitesortie, [quantitentree]-[quantitesortie] AS STOCKVRAIE FROM (produit INNER JOIN R_ENTREE ON produit.idproduit = R_ENTREE.idproduit) LEFT JOIN R_SORTIE ON produit.idproduit = R_SORTIE.idproduit and R_SORTIE.idsecteur = R_ENTREE.idsecteur GROUP BY produit.idproduit, R_ENTREE.IdSecteur
@yg_be : tout d'un coup un grand doute ne vient, généralement on ne fait pas une table entrée et une table sortie mais une table mouvement, avec de + et des -
là la jointure va fausser les SUM
produit Y entrée 2
produit Y entrée 4
produit Y sortie 1
produit Y sortie 3
donne en jointure un produit cartésien
produit Y entrée 2 sortie 1
produit Y entrée 2 sortie 3
produit Y entrée 4 sortie 1
produit Y entrée 4 sortie 3
total jointure sum(entree)=12
total jointure sum(sortie)=8
ces 2 résultats étant faux, respectivement 6 et 4
là la jointure va fausser les SUM
produit Y entrée 2
produit Y entrée 4
produit Y sortie 1
produit Y sortie 3
donne en jointure un produit cartésien
produit Y entrée 2 sortie 1
produit Y entrée 2 sortie 3
produit Y entrée 4 sortie 1
produit Y entrée 4 sortie 3
total jointure sum(entree)=12
total jointure sum(sortie)=8
ces 2 résultats étant faux, respectivement 6 et 4
donc je reprends en remplacant ces deux tables par la table mouvement ou je continue ; je suis vraiment perdu ; en fait jai une table produit qui est approvisionnée par les livraisons les differents fournisseurs ; ensuite ces produits sont livrés dans différents points de vente ou secteurs (R_ENTREE) et par la suite les client viennent faire des achats (R_SORTIE) dans ces differents secteurs
c'est donc ces differents stocks dans chaque point de vente qui est recherchée
c'est donc ces differents stocks dans chaque point de vente qui est recherchée
bien vu!
Si on en arrive, à tort ou à raison, à avoir des tables entrées et sorties, il faut plutôt faire une union des deux, surtout pas un join:
avec Access, le plus clair est de faire d'abord une requête union (qui regroupe tous les mouvements), et ensuite de l'utiliser dans la requête suivante:
requete entreeplussortie:
requête finale:
on peut évidemment faire des sommes dans la première requête, tout en sachant qu'on devra encore faire la somme ensuite.
Si on en arrive, à tort ou à raison, à avoir des tables entrées et sorties, il faut plutôt faire une union des deux, surtout pas un join:
avec Access, le plus clair est de faire d'abord une requête union (qui regroupe tous les mouvements), et ensuite de l'utiliser dans la requête suivante:
requete entreeplussortie:
select idproduit, quantiteentree as q from entree union all select idproduit, -quantitesortie from sortie
requête finale:
select produit.idproduit, sum(q) from produit left join entreeplussortie on produit.idproduit = entreeplussortie.idproduit group by produit.idproduit
on peut évidemment faire des sommes dans la première requête, tout en sachant qu'on devra encore faire la somme ensuite.
Bonjour,
Je ne discuterais pas des liens InnerJoin ou LeftJoint ou RightJoint, parce que je fais toujours mes requêtes en mode graphique, mais je voudrais te reprendre sur un point qui me parait fondamental. C'est qu'il ne te faut pas une table pour les entrées et une autre pour les sorties, mais une seule (Flux) avec quatre (4) champs, IndexOpération (la clé primaire) IndexProduit, Entrées, Sorties. A côté, tu auras une table "Produits", avec IndexProduit, DénominationProduit, etc. Et un lien, un à plusieurs entre la table "Produit", et la table "Opérations".
Après tout sera beaucoup plus simple et plus souple pour calculer tes stocks, parce qu'il te suffira de faire une requête avec "SommeEntrées-SommeSorties" groupée par produit, càd par "IndexProduit" de ta table des entrées/Sorties.
Bon courage.
Je ne discuterais pas des liens InnerJoin ou LeftJoint ou RightJoint, parce que je fais toujours mes requêtes en mode graphique, mais je voudrais te reprendre sur un point qui me parait fondamental. C'est qu'il ne te faut pas une table pour les entrées et une autre pour les sorties, mais une seule (Flux) avec quatre (4) champs, IndexOpération (la clé primaire) IndexProduit, Entrées, Sorties. A côté, tu auras une table "Produits", avec IndexProduit, DénominationProduit, etc. Et un lien, un à plusieurs entre la table "Produit", et la table "Opérations".
Après tout sera beaucoup plus simple et plus souple pour calculer tes stocks, parce qu'il te suffira de faire une requête avec "SommeEntrées-SommeSorties" groupée par produit, càd par "IndexProduit" de ta table des entrées/Sorties.
Bon courage.
Oui, tu as raison. Mais je ne prétendais pas être exhaustif dans l'énoncé des champs nécessaires, je voulais indiquer un principe général, avoir une table des Entrées/Sorties et les autres à côté, chacune avec un type de données permettant de lier les unes aux autres, sans avoir à répéter plusieurs fois une même donnée complexe dans un champ parce qu'on n'a pas prévu qu'elle réapparaitrait souvent.
Pour ton projet, il suffit d'imaginer que tu construis une base pour une banque, ou une base pour la trésorerie d'une entreprise. Tu as des clients, des agences, des comptes, des opérations d'entrées/sorties, et à la fin tu cherrches à savoir combien a chaque client sur son/ses comptes, ou bien reste en caisse pour chacune des agences, etc..., etc....
Avant de ses lancer dans les problèmes de requêtes, il faut se poser la question de savoir de quelles informations on va avoir besoin, comment on va construire les tables, et comment on va relier tout ça. Et après seulement les requêtes. Mais on aura tout ça dans la tête.
Pour ton projet, il suffit d'imaginer que tu construis une base pour une banque, ou une base pour la trésorerie d'une entreprise. Tu as des clients, des agences, des comptes, des opérations d'entrées/sorties, et à la fin tu cherrches à savoir combien a chaque client sur son/ses comptes, ou bien reste en caisse pour chacune des agences, etc..., etc....
Avant de ses lancer dans les problèmes de requêtes, il faut se poser la question de savoir de quelles informations on va avoir besoin, comment on va construire les tables, et comment on va relier tout ça. Et après seulement les requêtes. Mais on aura tout ça dans la tête.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Je vois que tu as mis la question en résolue, mais je réponds tout de même si tu passes par là pour regarder.
1°) Il faut 2 champs (Entrée + Sortie) pour être sûr qu'on n'oublie pas de mettre le signe " - " pour indiquer les sorties, sinon ce sera vite un bazar incroyable et les erreurs seront introuvables. Et à l'arrivée tout le travail, à la fois de conception de la base et de remplissage des données sera à mettre à la poubelle parce que irrécupérable.
2°) Pour le coup pourquoi deux formulaires, un pour les entrées et un pour les sorties, alors qu'un seul peut suffire, avec deux contrôles correspondants aux 2 champs (sans compter les autres que tu trouveras nécessaires)
De toutes façons, le plus à craindre sont les erreurs de saisies. Avoir 2 formulaires, peut être une option pour éviter de s'emmêler les pinceaux entre le contrôle de droite et celui de gauche, surtout si tes formulaires sont de couleurs différentes par exemple.
3°) Enfin, dans ton formulaire, tu peux prévoir, soit en tête de formulaire, soit en pied de formulaire, un contrôle calculé de type DSum(Entrée) - DSum(Sortie)
qui te donne l'état de ton stock; et alors il n'y a pas de danger d'avoir un stock négatif.
Salut
1°) Il faut 2 champs (Entrée + Sortie) pour être sûr qu'on n'oublie pas de mettre le signe " - " pour indiquer les sorties, sinon ce sera vite un bazar incroyable et les erreurs seront introuvables. Et à l'arrivée tout le travail, à la fois de conception de la base et de remplissage des données sera à mettre à la poubelle parce que irrécupérable.
2°) Pour le coup pourquoi deux formulaires, un pour les entrées et un pour les sorties, alors qu'un seul peut suffire, avec deux contrôles correspondants aux 2 champs (sans compter les autres que tu trouveras nécessaires)
De toutes façons, le plus à craindre sont les erreurs de saisies. Avoir 2 formulaires, peut être une option pour éviter de s'emmêler les pinceaux entre le contrôle de droite et celui de gauche, surtout si tes formulaires sont de couleurs différentes par exemple.
3°) Enfin, dans ton formulaire, tu peux prévoir, soit en tête de formulaire, soit en pied de formulaire, un contrôle calculé de type DSum(Entrée) - DSum(Sortie)
qui te donne l'état de ton stock; et alors il n'y a pas de danger d'avoir un stock négatif.
Salut
Bonjour, tout ce effort que nous avons fait jusqu'à maintenant est donc unitile, je note vos recommandations et on repartira en créant une table mouvement avec les champs :
Idmouvement, idproduit, datemouvement, typemouvement( entree, sortie), quantite,Idsecteur, Idemploye
Ensuite je dois créer un seul formulaire basée sur la table mouvement, ainsi le type de mouvement pourrait être choisi en fonction de du typemouvement
Mais je reviens sur le stock négatif, il est clair que si il n'existe pas de produit ou que la quantité en sortie est supérieure à la quantité disponible, l'opération s'avère impossible
C'est ce que je pense
Dans l'ensemble je vous remercie pour ces remarques très pertinentes
Idmouvement, idproduit, datemouvement, typemouvement( entree, sortie), quantite,Idsecteur, Idemploye
Ensuite je dois créer un seul formulaire basée sur la table mouvement, ainsi le type de mouvement pourrait être choisi en fonction de du typemouvement
Mais je reviens sur le stock négatif, il est clair que si il n'existe pas de produit ou que la quantité en sortie est supérieure à la quantité disponible, l'opération s'avère impossible
C'est ce que je pense
Dans l'ensemble je vous remercie pour ces remarques très pertinentes
Je n'avaais pas vu tes remarques. Aussi je reprends. Tu écris : "Ensuite je dois créer un seul formulaire basée sur la table mouvement, ainsi le type de mouvement pourrait être choisi en fonction de du type de mouvement"
Je ne comprends pas bien. Tu voudrais un champ qui indique si c'est une entrée ou une sortie, et que tu saisirais chaque fois???? Mais dans ce cas, tu as aussi vite fait d'avoir un champ pour les entrées et champ pour les sorties; ce serait bien plus sûr et bien plus pratique pour d'autres opérations dont tu pourrais avoir besoin plus tard, et tu n'aurais pas besoin de spécifier chaque fois si c'est une entrée ou une sortie, le simple fait que c'est enregistré à droite ou à gauche suffirait. Pour dire les choses simplement, il faut que ta table ressemble à un relevé de compte bancaire, avec 2 colonnes, les entrées et les sorties. Le reste est bavardage. Pour autant l'idée d'avoir 2 formulaires, un pour les entrées et un autre pour les sorties, n'est pas mauvaise, et peux aussi permettre une plus grande vigilance quant à ce qui entre et ce qui sort. Mais tous les cas, l'un et l'autre saisirait les données dans la même table, mais pas dans le même champ.
Après la question d'un éventuel stock négatif. C'est évidemment absurde; mais si tu en arrives là, c'est que la tenue de ta comptabilité est fausse, et alors se posera la question de savoir si les produits pour lesquels tu arrives à un stock positif sont-ils aussi inexacts que ceux pour lesquels le stock apparait comme négatif. Et cela, tu ne peux pas te le permettre.
Je ne comprends pas bien. Tu voudrais un champ qui indique si c'est une entrée ou une sortie, et que tu saisirais chaque fois???? Mais dans ce cas, tu as aussi vite fait d'avoir un champ pour les entrées et champ pour les sorties; ce serait bien plus sûr et bien plus pratique pour d'autres opérations dont tu pourrais avoir besoin plus tard, et tu n'aurais pas besoin de spécifier chaque fois si c'est une entrée ou une sortie, le simple fait que c'est enregistré à droite ou à gauche suffirait. Pour dire les choses simplement, il faut que ta table ressemble à un relevé de compte bancaire, avec 2 colonnes, les entrées et les sorties. Le reste est bavardage. Pour autant l'idée d'avoir 2 formulaires, un pour les entrées et un autre pour les sorties, n'est pas mauvaise, et peux aussi permettre une plus grande vigilance quant à ce qui entre et ce qui sort. Mais tous les cas, l'un et l'autre saisirait les données dans la même table, mais pas dans le même champ.
Après la question d'un éventuel stock négatif. C'est évidemment absurde; mais si tu en arrives là, c'est que la tenue de ta comptabilité est fausse, et alors se posera la question de savoir si les produits pour lesquels tu arrives à un stock positif sont-ils aussi inexacts que ceux pour lesquels le stock apparait comme négatif. Et cela, tu ne peux pas te le permettre.
Je pense qu'il y a une confusion entre les contrôles des formulaires et les champs des tables.
Les formulaires sont organisés pour faciliter le travail des utilisateurs et pour éviter les erreurs.
Les tables sont conçues indépendamment de cela, sur base d'autres critères.
Il peut être souhaitable qu'un formulaire, ou un état, ressemble à un relevé de comptes bancaires.
L'apparence des tables n'a pas d'importance, elles sont faites pour enregistrer des données, pas pour être vues.
Les formulaires sont organisés pour faciliter le travail des utilisateurs et pour éviter les erreurs.
Les tables sont conçues indépendamment de cela, sur base d'autres critères.
Il peut être souhaitable qu'un formulaire, ou un état, ressemble à un relevé de comptes bancaires.
L'apparence des tables n'a pas d'importance, elles sont faites pour enregistrer des données, pas pour être vues.
Il n'y a aucune confusion entre les champs et les contrôles, il suffit de regarder mes posts précédents pour s'en rendre compte, où j'utilise l'expression "Champ/Contrôle" pour bien montrer qu'il s'agit de 2 notions différentes. J'utilise Access depuis plus de 30 ans, j'ai commencé avec Access-2, c'est assez pour ne pas confondre. Je voulais juste souligner la nécessité d'avoir 2 champs sur une même table, (soit 2 colonnes dans une table comme ce le serait sur un tableau Excel), pour les entrées et les sorties, et non pas un seul champ avec des + et des - , ou encore 2 tables séparées pour les entrées et les sorties. Ces 2 solutions me paraissent à proscrire.
Erreur de syntaxe
et sans les outer?
erreur de synthaxe;(operateur absent) dans l'expression produit.idproduit=entree.produit
left joint sortie on produit.idproduit=sortie.idproduit