Requete qui calcul le stock [Résolu]

Signaler
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
-
 Tessel75 -
Bonjour, j'ai une requete basée sur deux requete qui devrait afficher le skock mais ce nest pas le cas parceque je nai saisi que les quantités entres et les quantités sorties sont pas encore saisie; je souhaiterais que dans ce cas le stock soit le total des entrees saisies

voici le code sql de la requete: SELECT R_ENTREE.IdProduit, Produit.Designation, [QUANTITENTREE]-[QUANTITESORTIE] AS STOCK3, R_ENTREE.QUANTITENTREE, R_SORTIE.QUANTITESORTIE
FROM R_ENTREE RIGHT JOIN (R_SORTIE INNER JOIN Produit ON R_SORTIE.IdProduit = Produit.idProduit) ON R_ENTREE.IdProduit = Produit.idProduit;

merci



Configuration: Windows / Firefox 88.0

5 réponses

Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021
7 725
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

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 


Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021
7 725 >
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

voir https://docs.microsoft.com/fr-fr/office/vba/access/concepts/structured-query-language/perform-joins-using-access-sql

Be aware that the first JOIN clause is enclosed in parentheses to keep it logically separated from the second JOIN clause. C'est peut être une particularité d'access ???

Alors
select produit.idproduit, sum(quantiteentree), sum(quantitesortie)
from ( produit
    left outer join R_ENTREE on produit.idproduit = R_ENTREE.idproduit )
        left outer join R_SORTIE on produit.idproduit = R_SORTIE.idproduit
group by produit.idproduit 
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021

oui ca va maintenant mais il m'affiche tous les produits de la table produit
en fait ; je veux juste ceux qui ont été mouvementés dans la table R_ENTREE ; ce sont ces produits entrés qui seront utilisés dans la table R_SORTIE
merci
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021
7 725 >
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

maintenant que tu as tous les ingrédients, tu devrais trouver tout seul
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021

je pense que cest bon voici le code

SELECT produit.idproduit, Sum(R_ENTREE.quantitentree) AS SommeDequantitentree, Sum(R_SORTIE.quantitesortie) AS SommeDequantitesortie
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;
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021
7 725 >
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

oui dans le cas où tu ne veux pas toute la table produit, et qu'une sortie ne peut avoir lieu sans entrée préalable (?), tu n'as pas besoin de l'outer join, du moment que tu choisis bien l'ordre des jointures
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

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;
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021
7 725
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

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 
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021
7 725
@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


Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021
866 >
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

je ne vois pas de secteur dans ta demande initiale.
tu as maintenant amplement les connaissances pour adapter ces requêtes à ton cas particulier.
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021

Je vais essayer
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021

en tenant compte du secteur voici le code sql donnant les stocks par produit entree ; jesspere que cest bon

SELECT produit.idproduit, produit.Designation, Sum(R_Union.q) AS SommeDeq, R_Union.idsecteur
FROM produit INNER JOIN R_Union ON produit.idproduit = R_Union.idproduit
GROUP BY produit.idproduit, produit.Designation, R_Union.idsecteur;
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021
866 >
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

as-tu testé?
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021

Oui j'ai testé et le stock est correct par secteur
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.
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
32119
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
10 juin 2021

OK je vais essayer et je vous reviens
>
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

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.
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021
866
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.
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021

En ce qui concerne le typeopération, j'ai déjà réalisé deux formulaires différents, un pour l'entrée des produit et un autre pour la sortie,
Et en ce qui concerne la quantité, je souhaiterais qu'elle soit affichée dans mon formulaire de sorte à pourvoir faire une comparaison avec la saisie de quantité sortie enfin d'éviter les stocks négatifs
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

Merci,est ce que on doit créer une table vente, et quelles pourraient être ses champs
Est elle reliée à la table mouvement ? Si oui par quelle champ ?
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
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

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
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021
>
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

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
>
Messages postés
222
Date d'inscription
vendredi 21 août 2020
Statut
Membre
Dernière intervention
4 juin 2021

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.
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021
866 > Tessel75
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.
>
Messages postés
15976
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
10 juin 2021

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.