{Access} requêtes
Fermé
Utilisateur anonyme
-
12 juil. 2009 à 01:47
zenon Messages postés 726 Date d'inscription jeudi 30 septembre 2004 Statut Membre Dernière intervention 13 février 2010 - 16 juil. 2009 à 22:54
zenon Messages postés 726 Date d'inscription jeudi 30 septembre 2004 Statut Membre Dernière intervention 13 février 2010 - 16 juil. 2009 à 22:54
A voir également:
- {Access} requêtes
- Access appdata - Guide
- Acer quick access - Forum Logiciels
- Nos systèmes ont détecté un trafic exceptionnel sur votre réseau informatique. cette page permet de vérifier que c'est bien vous qui envoyez des requêtes, et non un robot ✓ - Forum Virus
- Exemple base de données access à télécharger gratuit ✓ - Forum Logiciels
- Acer Quick Access - affichage CapsLock, VerrNum - Forum logiciel systeme
10 réponses
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
12 juil. 2009 à 14:48
12 juil. 2009 à 14:48
C'est une requête "mise à jour":
Il y a un assistant qui permet de la créer facilement.
Si tu me donnes la structure de la table, je peux essayer de te donner le code SQL...
Il y a un assistant qui permet de la créer facilement.
Si tu me donnes la structure de la table, je peux essayer de te donner le code SQL...
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
13 juil. 2009 à 12:51
13 juil. 2009 à 12:51
je vois ça ce soir...
(pas le temps d'ici là)
(pas le temps d'ici là)
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
13 juil. 2009 à 21:26
13 juil. 2009 à 21:26
Je pense qu'il y a des données inutiles dans ta table. Elle ne doit contenir que la quantité en stock.
Comment compte-tu faire fonctionner la base?
Si elle fonctionne en temps réel, il suffit que la quantité vendue soit utilisée pour mettre à jour le stock.
Si ce dernier descend en dessous d'une valeur seuil, tu peux afficher un message d'alerte.
Dans ce cas, tu devrais, lors de l'exécution de la commande, exécuter une mise à jour du stock.
En principe, c'est très simple: [stock] =[stock]-[Quantité vendue]
même pas besoin d'une requête.
(juste une remarque, si tu ne mets pas d'espaces dans le nom de tes champs, Tu ne devras pas taper les [], Access les ajoutera tout seul et ça évitera qu'il les confonde avec des chaînes de caractères et les mette entre "")
Comment compte-tu faire fonctionner la base?
Si elle fonctionne en temps réel, il suffit que la quantité vendue soit utilisée pour mettre à jour le stock.
Si ce dernier descend en dessous d'une valeur seuil, tu peux afficher un message d'alerte.
Dans ce cas, tu devrais, lors de l'exécution de la commande, exécuter une mise à jour du stock.
En principe, c'est très simple: [stock] =[stock]-[Quantité vendue]
même pas besoin d'une requête.
(juste une remarque, si tu ne mets pas d'espaces dans le nom de tes champs, Tu ne devras pas taper les [], Access les ajoutera tout seul et ça évitera qu'il les confonde avec des chaînes de caractères et les mette entre "")
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Utilisateur anonyme
13 juil. 2009 à 23:46
13 juil. 2009 à 23:46
stp a quel niveau devrai je taper le message d'erreur? eskcuse moi mais je sui débutant dans accès mais j'aime ce que je faits!
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
14 juil. 2009 à 12:15
14 juil. 2009 à 12:15
Bonjour, ce n'est vraiment un message d'erreur...
Ca dépend comment tu veux gérer les données.
Tu peux vérifier, par exemple au moment où tu fais les commandes quels sont les produits qui ont atteint le seuil de commande.
Dans ce cas, tu crées un formulaire qui trie tes enregistrements (type: SELECT... WHERE [Stock]<[Seuil]
et tu peux ensuite imprimer automatiquement des états qui partent vers les différents fournisseurs, enfin après les avoir crées (les états, pas les fournisseurs)...
Ou alors, tu peux afficher une boite de message qui s'ouvre quand le stock atteint la valeur seuil lorsque tu effectues une vente (c'est moins bien à mon avis: tu ne vas pas tout interrompre pour faire la commande d'un seul article).
Ca dépend comment tu veux gérer les données.
Tu peux vérifier, par exemple au moment où tu fais les commandes quels sont les produits qui ont atteint le seuil de commande.
Dans ce cas, tu crées un formulaire qui trie tes enregistrements (type: SELECT... WHERE [Stock]<[Seuil]
et tu peux ensuite imprimer automatiquement des états qui partent vers les différents fournisseurs, enfin après les avoir crées (les états, pas les fournisseurs)...
Ou alors, tu peux afficher une boite de message qui s'ouvre quand le stock atteint la valeur seuil lorsque tu effectues une vente (c'est moins bien à mon avis: tu ne vas pas tout interrompre pour faire la commande d'un seul article).
Utilisateur anonyme
14 juil. 2009 à 13:10
14 juil. 2009 à 13:10
c'est tres gantil de m'aider mais je suis encor au niveau de la création des formulaire.je voudrai en finir avant de creéer les états.donc j suis concé au nivau du formulaire PRODUIT surtout pour la mise a jour automatique du stock chak foi kil ya vente.
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
14 juil. 2009 à 15:53
14 juil. 2009 à 15:53
Dans ton formulaire vente, comment t'y prends-tu?
J'imagine que le client n'achète pas qu'un seul article.
J'imagine que tu as une liste des produits disponibles indexée par type de produit et par nom, que tu choisis l'article, la quantité, puis que tu valides l'achat, par exemple dans une autre table, liée à la table clients (éventuellement) pour suivre les mouvements.
A mon avis, c'est au moment où tu valides la vente que tu dois mettre à jour le stock. Ca peut se faire par le même bouton de commande que celui qui valide la vente de l'article (article par article(c'est le plus simple mais ça ne permet pas facilement de faire marche arrière)), ou à l'impression de la commande (c'est plus sûr puisque tu es certain que les produits sont effectivement sortis mais ça demandera de passer par une requête mise à jour, et c'est plus compliqué)
J'imagine que le client n'achète pas qu'un seul article.
J'imagine que tu as une liste des produits disponibles indexée par type de produit et par nom, que tu choisis l'article, la quantité, puis que tu valides l'achat, par exemple dans une autre table, liée à la table clients (éventuellement) pour suivre les mouvements.
A mon avis, c'est au moment où tu valides la vente que tu dois mettre à jour le stock. Ca peut se faire par le même bouton de commande que celui qui valide la vente de l'article (article par article(c'est le plus simple mais ça ne permet pas facilement de faire marche arrière)), ou à l'impression de la commande (c'est plus sûr puisque tu es certain que les produits sont effectivement sortis mais ça demandera de passer par une requête mise à jour, et c'est plus compliqué)
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
15 juil. 2009 à 13:21
15 juil. 2009 à 13:21
Dommage...
j'espérais être clair
Si tu as encore de l'énergie, explique en détail comment tu veux que ça fonctionne:
Pour la structure des tables, par article, je pense qu'il faut la quantité réelle en stock et le niveau de réapprovisionnement.
Pour les formulaires, j'imaginais que lors de la vente tu voulais mettre à jour automatiquement le stock.
Si tu ne le fais pas en temps réel, tu pourrais avec le même principe encoder les ventes a posteriori.
Sinon, tu devras aller voir dans le stock et ta base ne servira à rien: autant prendre une feuille de papier...
j'espérais être clair
Si tu as encore de l'énergie, explique en détail comment tu veux que ça fonctionne:
Pour la structure des tables, par article, je pense qu'il faut la quantité réelle en stock et le niveau de réapprovisionnement.
Pour les formulaires, j'imaginais que lors de la vente tu voulais mettre à jour automatiquement le stock.
Si tu ne le fais pas en temps réel, tu pourrais avec le même principe encoder les ventes a posteriori.
Sinon, tu devras aller voir dans le stock et ta base ne servira à rien: autant prendre une feuille de papier...
en fait mon application est consu pr gérer des ventes de moquettes et le reapprovisionement des stocks.
comme tables j'ai: produit, employer,fournisseur,commande,facture,client,livraison.
mai je pense que si je réussi a bien concevoir le formulaire "produit" se sera facil pour moi de fair les autres. J'ai vraiment besoin de ton aide surtout pour décrémenter le stock.
comme tables j'ai: produit, employer,fournisseur,commande,facture,client,livraison.
mai je pense que si je réussi a bien concevoir le formulaire "produit" se sera facil pour moi de fair les autres. J'ai vraiment besoin de ton aide surtout pour décrémenter le stock.
zenon
Messages postés
726
Date d'inscription
jeudi 30 septembre 2004
Statut
Membre
Dernière intervention
13 février 2010
180
16 juil. 2009 à 22:54
16 juil. 2009 à 22:54
Je ne voudrais pas te décourager (en fait d'après ton message précédent, c'est déjà fait) mais avec de la moquette, ça risque de ne pas être simple...
J'imagine que les gens ne t'achètent pas le rouleau entier. Il faut donc décomposer une étape plus loin en décomptant le nombre de mètres achetés dans chaque rouleau et prévoir des exceptions: imagine qu'il reste 5 mètres dans le rouleau entamé et que le gars en veut 6... Tout ça sans compter les chutes et le approximations des mesures. La vente à la pièce pose moins de problèmes.
Sinon, je ne sais pas si tu as bien en tête la structure des données.
Un formulaire n'est pas obligatoirement fondé sur une seule table. Pour une vente, il comportera à la fois des données concernant le client, le produit et les prix. En revanche, il n'y aura probablement pas besoin d'une table factures. Toutes les infos nécessaires sont déjà dans les tables... La facture, c'est plutôt le rôle d'un état.
En ce qui concerne le stock seulement, en partant de produits vendus à la pièce, tu peux avoir une table type: T_Produits(N°Produit,PrixUnitaire,SeuilCommande,Stock)
Dans ton formulaire où le vendeur effectue les commandes ou les ventes, on peut imaginer qu'il clique sur une liste déroulante qui reprend les produits pour les ajouter à la liste des achats puis qu'il indique la quantité vendue.
A ce moment, on peut écrire du code ou une simple macro qui met à jour le champ Stock avec un critère tout bète: Stock = Stock-Quantité vendue.
Au moment des commandes, tu peux exécuter une requête basée sur ta table produits qui extrait tous les articles dont la valeur en stock est inférieure à la valeur seuil. Le vendeur ne va pas interrompre sa vente pour faire une commande et si tu as besoin de plusieurs articles chez un même fournisseur, ce sera mieux de faire une commande groupée.
Je pense qu'une partie du problème vient du fait que tu essaies de fonder les formulaires sur les tables alors qu'il faut plutôt se demander comment on veut que l'application fonctionne de manière aussi intuitive et naturelle que possible.
si tu veux, envoie-moi un message privé avec ton adresse mail. Je pense qu'un exemple concret est plus parlant (précise-moi aussi sur quelle version d'Access tu travailles).
Bonne nuit...
J'imagine que les gens ne t'achètent pas le rouleau entier. Il faut donc décomposer une étape plus loin en décomptant le nombre de mètres achetés dans chaque rouleau et prévoir des exceptions: imagine qu'il reste 5 mètres dans le rouleau entamé et que le gars en veut 6... Tout ça sans compter les chutes et le approximations des mesures. La vente à la pièce pose moins de problèmes.
Sinon, je ne sais pas si tu as bien en tête la structure des données.
Un formulaire n'est pas obligatoirement fondé sur une seule table. Pour une vente, il comportera à la fois des données concernant le client, le produit et les prix. En revanche, il n'y aura probablement pas besoin d'une table factures. Toutes les infos nécessaires sont déjà dans les tables... La facture, c'est plutôt le rôle d'un état.
En ce qui concerne le stock seulement, en partant de produits vendus à la pièce, tu peux avoir une table type: T_Produits(N°Produit,PrixUnitaire,SeuilCommande,Stock)
Dans ton formulaire où le vendeur effectue les commandes ou les ventes, on peut imaginer qu'il clique sur une liste déroulante qui reprend les produits pour les ajouter à la liste des achats puis qu'il indique la quantité vendue.
A ce moment, on peut écrire du code ou une simple macro qui met à jour le champ Stock avec un critère tout bète: Stock = Stock-Quantité vendue.
Au moment des commandes, tu peux exécuter une requête basée sur ta table produits qui extrait tous les articles dont la valeur en stock est inférieure à la valeur seuil. Le vendeur ne va pas interrompre sa vente pour faire une commande et si tu as besoin de plusieurs articles chez un même fournisseur, ce sera mieux de faire une commande groupée.
Je pense qu'une partie du problème vient du fait que tu essaies de fonder les formulaires sur les tables alors qu'il faut plutôt se demander comment on veut que l'application fonctionne de manière aussi intuitive et naturelle que possible.
si tu veux, envoie-moi un message privé avec ton adresse mail. Je pense qu'un exemple concret est plus parlant (précise-moi aussi sur quelle version d'Access tu travailles).
Bonne nuit...
13 juil. 2009 à 00:14
reférence *
designation
prix unitaire(achat)
prix unitaire (vente)
quantité initiale
quantité stock
quantité seuil
Merci et si t'as d'autres suggestions c'est pas de refus.