Requete qui calcul le stock [Résolu]

bonjour,
et sans les outer?

C'est le même message qui apparaît

et avec le point-virgule à la fin?

ca ne marche toujours pas ; le message est le suivant :

erreur de synthaxe;(operateur absent) dans l'expression produit.idproduit=entree.produit
left joint sortie on produit.idproduit=sortie.idproduit

as-tu vraiment ajouté un t à join?

Non j'avais juste copié ce que vous m'avez transmis

mais ca ce n'est pas bon : produit.idproduit=entree.produit

et j'espère que par rapport à mon exemple tu as au moins mis le nom de tes propres tables R_SORTIE et R_SORTIE ;-)

Voici ce que jai dans ma requete:

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

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 

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

maintenant que tu as tous les ingrédients, tu devrais trouver tout seul

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;

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

OK vous n'avez pas tenu compte du secteur

je ne vois pas de secteur dans ta demande initiale.
tu as maintenant amplement les connaissances pour adapter ces requêtes à ton cas particulier.

Je vais essayer

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;

as-tu testé?

Oui j'ai testé et le stock est correct par secteur

et l'idsecteur

OK je vais essayer et je vous reviens

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.

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

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

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 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.

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.