Discussion :

[Cyrion81]

Bonjour,

(Projet base de donnée d une recylcerie d 'un centre social ( quelqu'un donne un objet, il est stocké et estimé pour le prix et revendu a qui est intéressé)
Il m est demander de saisir dans un premier temps la valeur en euro d'un objet a la date X.......
Cet objet ne s'étant pas vendu à date X. + Deux mois, changer sa valeur -20% à date X. + 6 mois -50 % et à date X. + 10 mois donné aux associations caritatives.
La table de saisie générale comporte deux champs "valeur" en rapport avec le problème

• Valeur initiale de l'objet
• Valeur calculée en fonction de la date (processus décrit ci dessus)

Je précise que les périodes ne sont pas fixées, si ce n 'est max 1 an

Ma question en fait s adresse aux concepteurs d'applications dois je faire :

• Directement le calcul dans la table dans un champs calculé ?
• En VBA + requête SQL ( qui doit être "lancé" tout les jours) ?
• Requête ?
• Autres solutions auxquelles je n'ai pas pensé ?

Merci d avance

[madefemere]

Bonjour,

Valeur calculée, donc normalement à ne pas conserver dans la table des produits.
La valeur de vente sera calculée et affichée au moment de la vente (dans un champ indépendant).
Dans un souci d'historique, on peut garder cette valeur d'achat dans la table des opérations de vente (même si c'est encore calculable).

Donc
T_Produit : IdProduit - DateAcquisition - PrixEntrée - AutresInfo.....
T_Vente : IdVente - DateVente - IdClient - AutresInfo -...
T_VenteDetail : IdVente_FK - Quantite - PrixVente

C'est la solution que je propose, à toi de voir. Peut-être quelqu'un d'autres donnera encore son avis.

Bonne continuation

[zoom61]

• Directement le calcul dans la table dans un champs calculé ?

Faisable, mais peut avoir un inconvénient si les paramètres changent

• En VBA + requête SQL ( qui doit être "lancé" tout le jour) ?

Peut-être la solution la plus simple à mettre à jour en cas de modif.

• Requête ?

Remarque identique que pour le champ calculé dans la table.

• Autre solution à laquelle je n'ai pas pensée ?

Je n'en vois pas d'autres.

@+.

[Robert1957]

Bonjour Cyrion81,

Peut-être un autre point de vue...

Cet objet ne s'étant pas vendu à date X. + Deux mois, changer sa valeur -20% à date X. + 6 mois -50 % et à date X. + 10 mois donné aux associations caritatives.

Ma réponse suppose que tu fonctionnes toujours avec des mois et que tu ne veux pas avoir d'historique mais juste une valeur à un moment x dans le temps.

Avec une table qui reprend les 12 mois de l'année ou plus selon le cas, à chaque mois le % de réduction donc 2 champs. Une première requête : miniature 1 qui te donne l'age du produit. Une seconde requête qui te donne la valeur aujourd'hui : miniature 2. L'avantage de ceci est que si tu décides de modifier la réduction du produit tu n'as qu'à le faire dans la table des mois et tout est à jour automatiquement. Le désavantage est que tu n'as pas d'historique sur le prix à moins d'insérer dans ta table le prix au moment de la transaction.

Bonne journée

[Cyrion81]

Merci tout d abord de votre "coopération" 'd'autant plus que je débute sur un gros dev sous Access fait pour des opérateurs qui ne connaissent rien en quoi que ce soit. Se serai sur Excel aucun soucis, mais.... voila).

Donc je vais porter mon choix sur la méthode suivante:
Enregistrement de l objet table principale (descriptif.... valeur estimé du départ )
Création d 'une table Opération ventes + formulaire
Qui, lorsqu"on rentre le code du produit appelle une partie des renseignements de la table principale sur l'objet et calcule le prix suivant la période écoulée.
si la vente se réalise,à ce moment là le prix est inscrit dans un champs de la table principale, ce qui permet de le prendre en compta.

Au moment de la redaction de mon message, est arrivé le post de robert, l idée est séduisante.


Merci de vos idées, je pense que nous nous relirons

[Robert1957]

Bonjour Cyrion81,

Pour répondre à ta question, voir le fichier joint.

Bonne journée

[Cyrion81]

Bonjour
merci Robert ta solution par des requêtes fonctionne, mais uniquement en requête ponctuelle cela ne pose pas de problème avec ton système, pour calculer la nouvelle valeur de l objet par rapport a ce fameux champ datant la durée en mois et le % par rapport a cette durée.

Maintenant un autre problème surgit, comment passer cette nouvelle valeur à tous les objets d'une table (suivant une condition de temps de stockage ) et que ce soit mis à jour le champs [PrixVenteObjet] " au jour le jour", J'avais bien pensé à une requête "mise à jour", mais, je n'ai pas trouvé comment rédiger cette mise à jour conditionnelle en tenant compte du nombre de mois.

Je résume :

Une table d'objets T_Saisie_Objet
champs concernés :

• Date_Inscription : Enregistrement du produit
• EstimationObjet : Valeur estimé en Euro
• AgeProduit : DiffDate("m";[Date_Inscription];Date()) (formule Robert), requête de mise à jour suivant la date qui fonctionne (perso)
• MontantReduction : En fonction de AgeProduit
• PrixVenteObjet : EstimationObjet - MontantReduction

Comment faire cette mise à jour ?

je suis un peu dans le flou, si quelqu'un peut apporter un élément pour une nouvelle étape je lui en serait gré .

[Robert1957]

Bonjour Cyrion81,

Si tu regardes l'exemple que je t'ai fait il y a une date d'achat et une date de vente.

Une table d'objets T_Saisie_Objet
champs concernés :
Date_Inscription : Enregistrement du produit
EstimationObjet : Valeur estimé en Euro
AgeProduit : DiffDate("m";[Date_Inscription];Date()) (formule Robert), requête de mise à jour suivant la date qui fonctionne (perso)
MontantReduction : En fonction de AgeProduit
PrixVenteObjet : EstimationObjet - MontantReductio

Ne pourrait pas faire ce que tu veux. Il faut savoir la date de vente pour pouvoir calculer l'age du produit à cette date. De plus je ferais le calcul de la réduction à l'extérieur de la table. La raison étant simple, cette année la réduction est de 20% mais elle pourrait être ajustée l'an prochain et devenir 30%. Donc tu dois saisir le montant de réduction ou le % c'est comme tu veux au moment de la vente du produit. Le prix de vente n'a pas réellement sa place à moins que tu veuilles le modifier manuellement parce que tu décides que pour ce produit tu donnes une plus grosse réduction pour une raison x qui ne peut être calculé.

La solution de madefemere :

T_Produit : IdProduit - DateAcquisition - PrixEntrée - AutresInfo.....
T_Vente : IdVente - DateVente - IdClient - AutresInfo -...
T_VenteDetail : IdVente_FK - Quantite - PrixVente

Est une bonne structure. Il faut calculer le prix de vente de la troisième table avec la requête que je t'ai fait en fonction de la date de vente de la deuxième table et la date d'acquisition de la première table et le tour est joué. Tu insères le prix de vente dans le sous-formulaire soit par une requête ou du VBA. De plus avec cette structure supposons que tu as 3 fois le même produit, tu n'as pas besoin de le répéter 3 fois dans la table "Produit". Avec ce que je vois de ta structure il faudrait que tu saisisses 3 fois le même produit.

Bonne journée

[Cyrion81]

Bonsoir,

Merci robert ta solution semble la plus facile à mettre en œuvre, ce que je ferai, mais les liaison entre les tables me fait fumer le nez à chaque fois. (là c est vrai va falloir que ma caboche fasse le nécessaire )
En attendant, j ai fait une solution d 'urgence (peut être peu élégante) car lundi me faut présenter le projet.
Voila
J'ai une requête mise à jour qui opère des l ouverture de la base (formulaire d 'accueil), cette requête n'est activée que lorsque le champ "DateDeVente" est vierge(comme Jeanne).
Dans le formulaire permettant l'enregistrement de la transaction ( donc appel de l objet par son IDObjet) j'ai créé un champ Texte indépendant auquel j'ai mis en source la formule suivante:

=VraiFaux([StockeDepuis]<=4;[PrixVenteObjetD]*1;VraiFaux([StockeDepuis] Entre 5 Et 6;[PrixVenteObjetD]*0,8;VraiFaux([StockeDepuis] Entre 7 Et 9;[PrixVenteObjetD]*0,5;VraiFaux([StockeDepuis] Entre 10 Et 11;[PrixVenteObjetD]*0,2;[PrixVenteObjetD]=0))))


Ce qui permet à L'opérateur(trice) d'avoir le prix avec la ristourne.
Lorsque la vente est enregistrée, le prix calculé est inscrit dans la table de base dans le champ qui va bien, ce qui permet de prendre en compte cette valeur en compta.

C'est vrai, que évidemment comme c est souligné plus haut, un opérateur(trice) lambda ne peux pas changer la ristourne facilement, donc va me falloir passer par la soluce de Robert ou de madefemere.

merci en attendant aux généreux donateurs de matière grise dont font partis Robert et Madefemere, pour mon projet, qui, d'après ce que je sais sur ce que l'on va me demander est loin d'être fini (stat mensuelles etc..)