{Access} Variation de prix, cmt y remedier ?

Fermé
guillaumedt - 15 juil. 2009 à 11:46
moiced59 Messages postés 1145 Date d'inscription samedi 15 novembre 2008 Statut Membre Dernière intervention 18 août 2014 - 13 sept. 2009 à 10:38
Bonjour,

Je travaille actuellement sur une base de données classique qui me permet d'enregistrer les ventes, il y a donc 5 tables (clients, vente, detail de la vente, produit, lieu de vente), cette BDD me permet de calculer le montant dépensé dans le magasin par consommateur, j'ai créer un requête qui va chercher le prix de vente du produit dans la table produit et qui multiplie par la quantité pour obtenir le total de la vente.

Mon probleme est le suivant :

Si le prix de vente change, alors le montant va être recalcule pour les anciens clients, ce qui pose probleme car je veux comptabiliser le montant total vraiment dépensé en magasin.

Comment pensez vous que je puisse remédier au probleme ?

Merci,

Guillaume
A voir également:

9 réponses

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:23
Je pense qu'il faut créer une nouvelle table qui permet d'encoder le prix réellement payé et n'utilister ta table actuelle que comme "source pour les nouvelles ventes.
0
Rebonjour,

A priori, je pensais séparer ma table Produits en deux tables : NomProduits avec deux champs : RefProduit et NomProduit et une seconde table : PrixProduits avec 3 champs : RefProduit, PrixDeVente et DatedeMiseAJourPrix.

Ainsi, dans ma requête HistoriqueVente, la vendeuse rentrerais la date de vente, la référence du produit et automatiquement, access calcul le prix de vente. Comment demander a access le prendre le bon prix de vente par rapport a la date de vente ?

Cordialement,

Guillaume
0
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 à 17:30
Bonjour,

je reviens avec ma première proposition, qui me semble la plus simple, la plus sûre et la moins gourmande en ressources...

Pourquoi ne pas simplement créer une table qui reprendrait les produits vendus et leur prix au moment de la vente. et une table "source qui reprend les prix en cours, à mettre à jour, sans avoir besoin d'un historique.

le(a) vendeur(euse) n'a qu'à prendre le prix "valide" dans cette table et, une fois l'article acheté, son prix est fixé définitivement.

Ainsi, quand les prix varient, on le met à jour et ça n'influence pas les articles déjà payés. Ca me semble beaucoup plus simple que de devoir monter une table comportant un historique de tous les prix par date puis des requêtes pour les extraire...
0
D'accord, cela me parait simple, mais je croyais qu'une table ne pouvait pas enregistrer des informations par le calcul.

Pour etre plus precis, j'ai une table vente avec les champs : RefVente, Client, Date et Heure et j'ai une table DetailDeVente avec les champs suivants : RefDetailDeVente, RefVente, ProduitId et Discount.
Il faut donc que je modifie ces tables ou que je cree une table SalesHistory ?

Cordialement, Guillaume
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
zenon Messages postés 726 Date d'inscription jeudi 30 septembre 2004 Statut Membre Dernière intervention 13 février 2010 180
17 juil. 2009 à 18:26
Bonsoir,

Dans les deux tables que tu cites, je ne vois pas où se situe le prix (discount?)

Je verrais une table produits reprenant les infos produit et le prix en cours, à mettre à jour au fûr et à mesure,
une table clients et une table ventes reprenant le N°client, le N°produit, la date et le prix payé.

Ainsi il n'y a pas de lien direct entre le prix "actuel" d'un produit et le prix réellement payé dans la passé 'mais bien quant aux autres infos produit.
0
Lendcap Messages postés 1 Date d'inscription vendredi 11 septembre 2009 Statut Membre Dernière intervention 11 septembre 2009
11 sept. 2009 à 21:09
Bonjour mon frère,
je crois ke pour ton prb il faut spliter ta table produit en deux avec d'un côté refprod et nomprod dans la première table et de l'autre refprod, Prix et Date modification dans la deuxième table. Maintenant dans ton formulaire de facturation sur evènement afterupdate refprod assigner le Prix avec en critère DernierPrix. Bien entendu tu mets la propriété verouillé de prix à oui pour eviter toute modification.
0
moiced59 Messages postés 1145 Date d'inscription samedi 15 novembre 2008 Statut Membre Dernière intervention 18 août 2014 60
13 sept. 2009 à 10:38
pourquoi ne pas creer tout simplement une requete de mise ajour avec pour critere de mise ajour le new prix ?
ce nouveaux prix se trouve bien ds une table et il designe un article que tu as forcement ds une table dc c tres rapide com ca

non?
0
moderno31 Messages postés 870 Date d'inscription mardi 23 juin 2009 Statut Membre Dernière intervention 8 août 2012 92
15 juil. 2009 à 19:53
Hello,
Si j'ai bien compris quand le prix de vente change il ne faut pas que ça impacte des commandes précédement passées.
Ce à quoi je pense, il faut faire une table avec les prix de chaque référence ou modifier l'existant en mettant en place en fonction d'une date et d'un repère d'activation.
CE repère d'activation est juste 0 ou 1 qui est à prendre en compte quand tu cherches le prix d'un de tes produits.
Ex : Je veux le prix et la quantité du produit 'VR' à condition que son prix soit = 1.

Je me rends compte que ma solution n'est peut-etre pas complete. Je te laisse lire pour me dire si je me trompe ou pas.
Mais à mon avis peut-etre que ça se joue au nieau des références.

Tu me diras ton avis..
-1
Bonjour,

Je fais de mon mieux mais je ne comprend pas trop la solution, j'ai une requête qui s'appelle historique des ventes, tu penses qu'il vaut mieux que j'en fasse une table ?
Pour que cette requête ne soit pas impacte par un changement de prix, il faut que l'ancien prix de l'objet soit enregistre quelque part, ou bien que le résultat de la vente lui même apparaissant dans la requête soit enregistre quelque part.

Ce que je vois a priori, c'est dans la table objet, rajoute un champs qui serait : Date de changement de prix, ainsi pour chaque prix qui changerais, on réenregistrerait l'objet avec une nouvelle date, on pourrait donc avoir deux fois le même objet avec un prix différent, et lors du calcul de l'historique de vente, il prendrait le prix correspondant a la date de vente (condition sur la date).

Mais le gros probleme est le suivant, lorsque la vendeuse enregistre la vente, il faudrait pas qu'elle est le choix des différents prix aux différentes dates, il faudrait que ce soit impose par l'ordinateur. Est-ce possible ?

Merci,

Guillaume
-1