[Access]Gérer la var. des prix des art.
Fermé
Delphine
-
Modifié par blux le 10/08/2011 à 22:11
blux Messages postés 26536 Date d'inscription dimanche 26 août 2001 Statut Modérateur Dernière intervention 19 décembre 2024 - 11 août 2011 à 11:29
blux Messages postés 26536 Date d'inscription dimanche 26 août 2001 Statut Modérateur Dernière intervention 19 décembre 2024 - 11 août 2011 à 11:29
A voir également:
- [Access]Gérer la var. des prix des art.
- Gta 6 prix - Accueil - Jeu vidéo
- Word art - Télécharger - Bureautique
- Gerer les profils netflix - Guide
- Prix licence windows 10 - Accueil - Installation
- Gerer foyer netflix - Accueil - Guide streaming
2 réponses
blux
Messages postés
26536
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
19 décembre 2024
3 317
10 août 2011 à 22:08
10 août 2011 à 22:08
Salut,
si tu as ce genre de 'souci', c'est que ton modèle de données n'est pas correct par rapport aux traitements que tu souhaites faire.
Un lien entre article et BL est normal (quoi que), mais il ne doit pas embarquer le prix et d'autres choses qui sont susceptibles d'être modifiées (taux de TVA, libellé article...).
Peut-être faudrait-il éclater encore ta table article pour créer une table prix article, avec le prix par période temps ?
Comme ça, ton BL serait toujours bon, si on va chercher le prix de l'article correspondant à la date du BL, et tu aurais également l'historique d'évolution du prix. Une liaison n-n avec une table fournisseur, et tu peux ensuite comparer qui est le plus intéressant pour chaque période que tu désireras.
En principe, un BL est une donnée de type 'archive', c'est-à-dire que son contenu ne doit pas être fluctuant, à aucun moment. Une facture suit le même comportement.
si tu as ce genre de 'souci', c'est que ton modèle de données n'est pas correct par rapport aux traitements que tu souhaites faire.
Un lien entre article et BL est normal (quoi que), mais il ne doit pas embarquer le prix et d'autres choses qui sont susceptibles d'être modifiées (taux de TVA, libellé article...).
Peut-être faudrait-il éclater encore ta table article pour créer une table prix article, avec le prix par période temps ?
Comme ça, ton BL serait toujours bon, si on va chercher le prix de l'article correspondant à la date du BL, et tu aurais également l'historique d'évolution du prix. Une liaison n-n avec une table fournisseur, et tu peux ensuite comparer qui est le plus intéressant pour chaque période que tu désireras.
En principe, un BL est une donnée de type 'archive', c'est-à-dire que son contenu ne doit pas être fluctuant, à aucun moment. Une facture suit le même comportement.
Bonjour et merci pour ta réponse, qui me fait bien réfléchir...
Si tu t'y connais bien, est-ce que tu peux jeter un coup d'oeil à ma base, je mets le lien de la copie écran des relations de mes tables...
Ton (quoi que) me fait réfléchir....
Je pense que l'éclatement de ma table article peut s'avérer fastidieux, car les prix changent souvent, et parfois sur une même date :
exemple : nous achetons 30 ML de tuyaux PVC chez le "fournisseurA" pour le "chantier 1" --> 10€ le ML
Un autre collègue achète chez le même fournisseur 10 ML pour le "chantier2" --> 12.50€ le ML
J'aurais donc 2 BL à saisir, avec un prix différent au ML
Comme tu peux le voir dans mes relations, hier j'ai remplacé dans la table Article le PrixUnitaireHT par PrixUnitaireConstaté, et j'ai mis le PrixUnitaireHT dans la table des détails de lignes de mes BL.
Ca à l'air pas trop mal... Mais je n'en suis qu'au début et je ne me rends pas bien compte de l'impact futur que cela peut avoir dans ma base..
Je ne sais pas trop si c'est bien de faire ainsi...
Lien copie écran des relations :
http://www.cijoint.fr/cjlink.php?file=cj201108/cij0RJSh80.jpg
Bonne journée,
Si tu t'y connais bien, est-ce que tu peux jeter un coup d'oeil à ma base, je mets le lien de la copie écran des relations de mes tables...
Ton (quoi que) me fait réfléchir....
Je pense que l'éclatement de ma table article peut s'avérer fastidieux, car les prix changent souvent, et parfois sur une même date :
exemple : nous achetons 30 ML de tuyaux PVC chez le "fournisseurA" pour le "chantier 1" --> 10€ le ML
Un autre collègue achète chez le même fournisseur 10 ML pour le "chantier2" --> 12.50€ le ML
J'aurais donc 2 BL à saisir, avec un prix différent au ML
Comme tu peux le voir dans mes relations, hier j'ai remplacé dans la table Article le PrixUnitaireHT par PrixUnitaireConstaté, et j'ai mis le PrixUnitaireHT dans la table des détails de lignes de mes BL.
Ca à l'air pas trop mal... Mais je n'en suis qu'au début et je ne me rends pas bien compte de l'impact futur que cela peut avoir dans ma base..
Je ne sais pas trop si c'est bien de faire ainsi...
Lien copie écran des relations :
http://www.cijoint.fr/cjlink.php?file=cj201108/cij0RJSh80.jpg
Bonne journée,
blux
Messages postés
26536
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
19 décembre 2024
3 317
11 août 2011 à 10:31
11 août 2011 à 10:31
J'aurais donc 2 BL à saisir, avec un prix différent au ML
Si tu veux pouvoir, comme tu l'as indiqué initialement, suivre les évolutions de prix, tu n'as pas le choix...
Par contre, j'avais compris que tu voulais éditer des BL en tant que vendeur, et non pas en tant qu'acheteur...
Pour ton modèle de données, je ne peux pas dire, ne connaissant pas le but de la manoeuvre.
Si tu veux pouvoir, comme tu l'as indiqué initialement, suivre les évolutions de prix, tu n'as pas le choix...
Par contre, j'avais compris que tu voulais éditer des BL en tant que vendeur, et non pas en tant qu'acheteur...
Pour ton modèle de données, je ne peux pas dire, ne connaissant pas le but de la manoeuvre.
Le but de la manoeuvre est de saisir les bons de livraison de nos achats chez nos différents fournisseur, (j'en suis là :) )puis de saisir nos factures fournisseurs et pointer les BL correspondants.
Cela dans le but de faire un peu d'analytique et pouvoir imputer nos dépenses par catégories, et également de voir l'évolution des coûts de nos achats.
Cela dans le but de faire un peu d'analytique et pouvoir imputer nos dépenses par catégories, et également de voir l'évolution des coûts de nos achats.
blux
Messages postés
26536
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
19 décembre 2024
3 317
11 août 2011 à 10:52
11 août 2011 à 10:52
J'aurais définitivement supprimé la relation entre détailBL et article.
Quid d'un produit qui disparaît ? Qui change de nom ? De référence ?
En corollaire, dans détailBL, on va retrouver tout ce qui est dans article, mais ça ne bougera plus, autorisant donc des requêtes historisées.
Quid d'un produit qui disparaît ? Qui change de nom ? De référence ?
En corollaire, dans détailBL, on va retrouver tout ce qui est dans article, mais ça ne bougera plus, autorisant donc des requêtes historisées.
Je suis d'accord avec ton raisonnement, mais la où je décroche, c'est que selon toi, il faut saisir les libellés des articles manuellement dans chaque BL ?? Le problème est que par exemple, on peut saisir "TUBE PVC Ø 160" et "TUYAU PVC Ø 160" selon les appellations des fournisseurs.... (je te donne un exemple simple)
Si je saisis manuellement mes lignes de BL, les requêtes ne pourront pas être d'une grande utilité, non ?
De plus, je croyais que le but d'utiliser access est qu'il stocke moins de données redondantes, sinon autant rester sur Excel, non ?
(d'ailleurs ce que j'ai actuellement : base excel avec N°BL, date BL, nom founisseur, code article, libellé article, Unité, Qté, PUHT, etc...
J'utilise des validations de données sur mes listes d'articles et de fournisseurs, et ma base devient très lourde...
D'où mon passage à access
Si je saisis manuellement mes lignes de BL, les requêtes ne pourront pas être d'une grande utilité, non ?
De plus, je croyais que le but d'utiliser access est qu'il stocke moins de données redondantes, sinon autant rester sur Excel, non ?
(d'ailleurs ce que j'ai actuellement : base excel avec N°BL, date BL, nom founisseur, code article, libellé article, Unité, Qté, PUHT, etc...
J'utilise des validations de données sur mes listes d'articles et de fournisseurs, et ma base devient très lourde...
D'où mon passage à access
blux
Messages postés
26536
Date d'inscription
dimanche 26 août 2001
Statut
Modérateur
Dernière intervention
19 décembre 2024
3 317
11 août 2011 à 11:25
11 août 2011 à 11:25
Je suis d'accord avec ton raisonnement, mais la où je décroche, c'est que selon toi, il faut saisir les libellés des articles manuellement dans chaque BL ??
Non, tu viens les piocher dans la table article (grâce au N°article) avec une requête INSERT INTO.
Le problème est que par exemple, on peut saisir "TUBE PVC Ø 160" et "TUYAU PVC Ø 160" selon les appellations des fournisseurs.... (je te donne un exemple simple)
Si je saisis manuellement mes lignes de BL, les requêtes ne pourront pas être d'une grande utilité, non ?
Sans objet si saisie par 'recopie'.
De plus, je croyais que le but d'utiliser access est qu'il stocke moins de données redondantes, sinon autant rester sur Excel, non ?
Un SGBD n'est pas que là pour réduire la masse d'information, il permet aussi de créer des liens entre les informations.
Si tu suis les canons de l'algèbre relationnelle (formes normales et autres joyeusetés), alors oui, il ne faut pas dupliquer une donnée.
Cependant, ne pas perdre de vue la finalité d'un modèle de données, c'est s'autoriser à dériver du modèle 'pur et parfait' pour prendre en compte les contraintes amenées par un besoin de traitement particulier (création d'un index supplémentaire, duplication des données pour éviter des équijointures lourdes en traitement...)
Non, tu viens les piocher dans la table article (grâce au N°article) avec une requête INSERT INTO.
Le problème est que par exemple, on peut saisir "TUBE PVC Ø 160" et "TUYAU PVC Ø 160" selon les appellations des fournisseurs.... (je te donne un exemple simple)
Si je saisis manuellement mes lignes de BL, les requêtes ne pourront pas être d'une grande utilité, non ?
Sans objet si saisie par 'recopie'.
De plus, je croyais que le but d'utiliser access est qu'il stocke moins de données redondantes, sinon autant rester sur Excel, non ?
Un SGBD n'est pas que là pour réduire la masse d'information, il permet aussi de créer des liens entre les informations.
Si tu suis les canons de l'algèbre relationnelle (formes normales et autres joyeusetés), alors oui, il ne faut pas dupliquer une donnée.
Cependant, ne pas perdre de vue la finalité d'un modèle de données, c'est s'autoriser à dériver du modèle 'pur et parfait' pour prendre en compte les contraintes amenées par un besoin de traitement particulier (création d'un index supplémentaire, duplication des données pour éviter des équijointures lourdes en traitement...)
