Requete qui calcul le stock
Résolu/Fermé
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
-
31 mai 2021 à 14:43
Tessel75 - 4 juin 2021 à 10:35
Tessel75 - 4 juin 2021 à 10:35
A voir également:
- Requete qui calcul le stock
- Calcul moyenne excel - Guide
- Logiciel calcul plancher bois gratuit - Télécharger - Architecture & Déco
- Formule de calcul excel - Guide
- Logiciel gratuit calcul surface m2 - Télécharger - Outils professionnels
- Logiciel gratuit calcul valeur nutritionnelle - Télécharger - Santé & Bien-être
5 réponses
jee pee
Messages postés
39504
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 mars 2024
9 205
Modifié le 31 mai 2021 à 15:51
Modifié le 31 mai 2021 à 15:51
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
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
1 juin 2021 à 18:01
1 juin 2021 à 18:01
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;
jee pee
Messages postés
39504
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 mars 2024
9 205
Modifié le 1 juin 2021 à 18:15
Modifié le 1 juin 2021 à 18:15
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
jee pee
Messages postés
39504
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 mars 2024
9 205
1 juin 2021 à 18:25
1 juin 2021 à 18:25
@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
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
1 juin 2021 à 20:25
1 juin 2021 à 20:25
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
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
1 461
1 juin 2021 à 23:07
1 juin 2021 à 23:07
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.
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
>
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
Modifié le 1 juin 2021 à 23:26
Modifié le 1 juin 2021 à 23:26
OK vous n'avez pas tenu compte du secteur
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
1 461
>
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
1 juin 2021 à 23:32
1 juin 2021 à 23:32
je ne vois pas de secteur dans ta demande initiale.
tu as maintenant amplement les connaissances pour adapter ces requêtes à ton cas particulier.
tu as maintenant amplement les connaissances pour adapter ces requêtes à ton cas particulier.
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
>
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
1 juin 2021 à 23:48
1 juin 2021 à 23:48
Je vais essayer
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.
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
1 juin 2021 à 22:04
1 juin 2021 à 22:04
Je vais essayer, mais je pense que vous avez oublié la date de l'opération dans cette table opération
jee pee
Messages postés
39504
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 mars 2024
9 205
>
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
1 juin 2021 à 22:15
1 juin 2021 à 22:15
et l'idsecteur
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
>
jee pee
Messages postés
39504
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
28 mars 2024
1 juin 2021 à 22:24
1 juin 2021 à 22:24
OK je vais essayer et je vous reviens
Tessel75
>
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
2 juin 2021 à 00:43
2 juin 2021 à 00:43
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.
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
1 461
2 juin 2021 à 14:08
2 juin 2021 à 14:08
c'est une option, et je ne pense pas que c'est fondamental.
par contre, pourquoi garder deux champs pour les quantités?
je ferais plutôt un seul champ pour les quantités, en ajoutant peut-être un champ "type d'opération", ainsi qu'une date.
par contre, pourquoi garder deux champs pour les quantités?
je ferais plutôt un seul champ pour les quantités, en ajoutant peut-être un champ "type d'opération", ainsi qu'une date.
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
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
3 juin 2021 à 12:33
3 juin 2021 à 12:33
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
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
>
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
3 juin 2021 à 14:23
3 juin 2021 à 14:23
en fait dans ma base de données ; jai deja une table mouvement qui retrace tous les mouvements des livraisons des fournisseurs et donc il reste à integrer ceux qui permettent de faire les entrees et sorties et transferts entre les differents points de vente ains que le magasin principal
Tessel75
>
Oholabi12345
Messages postés
498
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
29 octobre 2022
4 juin 2021 à 01:30
4 juin 2021 à 01:30
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.
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
1 461
>
Tessel75
4 juin 2021 à 09:46
4 juin 2021 à 09:46
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.
Tessel75
>
yg_be
Messages postés
22623
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
28 mars 2024
4 juin 2021 à 10:35
4 juin 2021 à 10:35
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.
31 mai 2021 à 18:31
Erreur de syntaxe
31 mai 2021 à 18:34
et sans les outer?
31 mai 2021 à 20:56
31 mai 2021 à 20:59
1 juin 2021 à 01:14
erreur de synthaxe;(operateur absent) dans l'expression produit.idproduit=entree.produit
left joint sortie on produit.idproduit=sortie.idproduit