[AC-2010] Mise à jour de données et rétroactivité [Résolu]

[CaiiLle]

Bonjour à tous,

Je suis amené à créer une base de données pour suivre les commandes effectuées auprès des fournisseurs de mon entreprise.

Sachant que le tarifs des produits proposé par les fournisseurs varie à intervalle régulier, je me demandais si il était possible de mettre en place un fonction mise à jour tout en gardant en mémoire le tarif proposé à un instant T ?

Je vous propose de considérer que :
- le 01/01/2013 - le produit A est vendu au prix de 10 €,
- le 01/03/2013 - le produit A est proposé à 15 €.

Je crée une commande "COMMANDE001" le 02/01/2013 pour l'achat de 10 produits A soit 10*10=100 => Cette commande étant enregistré automatiquement dans une table associée (idfournisseur, idproduit, date commande).

Au 01/03/2013, le tarif évolue. Hors, je souhaite visualiser la commande "COMMANDE001" avec les informations antérieures à la mise à jour du prix du produit A.

Est-il possible de garder en mémoire les tarifs antérieurs pour une utilisation antérieure ?

Je vous remercie de votre aide

Cordialement

[minot83]

Bonsoir,

oui en créant une autre table destinée à recueillir les tarif datés.

Tu auras donc une table T_Produits (Id_Produit, Libellé_Produit, ...)
Une table T_Produits_Tarif (FK_Produit, Tarif_unitaire, Date_Tarif)
Une table T_Produits_Ventes (Id_Vente, FK_Produit, FK_Client, Quantité, Date_Vente,...)

Ainsi tu n'es plus limité à un seul tarif par produit, et conserve l'historique des prix.

[jimbolion]

CaiiLle,

Partant de l'idée de Minot83, tu pourrais même regrouper tes tables T_Produits_Tarif et T_Produits_Ventes en table mouvements.

Id_Mouvement (numero unique)
Type_Mvt (Entrée ou Sortie)
FK_Produit (clé de la table Produit)
Tarif_unitaire (prix de vente ou achat)
FK_Client (facultatif lors des achats)
Quantité (achetées ou vendues)
Date_mouvement (achat ou vente)
Parent_Id_Achat (facultatif : Id_Mouvement de l'achat pour la vente)

Cette table te permettrait d'anticiper les évolutions futures. A l'heure actuelle, tous mes process de gestion de stocks sont constitués ainsi.

Sinon l'idée de Minot83 est aussi tout à fait réalisable.

Je n'apporte qu'un niveau de réflexion supplémentaire à ta demande.

JimBoLion

[CaiiLle]

Merci pour vos réponse.

Vos tables me permettent-elles lors d'un visionnage d'une commande fournisseur antérieur de retrouver les prix pratiqués à cet instant T ?

[jimbolion]

CaiiLle bonjour,

Quelque soit la solution retenue, celle de minot83 ou la mienne pas de soucis. L'utilisation de filtres sur les dates te permettront de retrouver un prix d'achat à n'importe quel moment.

JimBoLion

[CaiiLle]

Merci pour ta réponse.

Il me semble donc que cette solution ce rapproche d'une gestion de stocks ?

Si tel est le cas, comment mettre en place une telle gestion ? (ne connaissant pas suffisamment les codes Visual Basic et compagnies...

[jimbolion]

CaiiLle bonjour,

Afin de mener à bien ton projet il va te falloir maîtriser queslques aspects de la modélisation (relations,index...).
Si ta base doit servir à plusieurs utilisateurs, il te faudra mettre en oeuvre une base frontale et dorsale (je la préconise même en environnement mono-utilisateur)
Après tu devras travailler sur la notion de formulaires et sous formulaires sur la partie IHM.

Dès lors tu te seras confronté aux problématiques de requêtes SQL et code VBA.
Commences par lire les différents tutos adaptés à ces notions, il y en a d'excellents sur ce forum).

Lorsque tu auras maîtrisé tout çà, tu reviens vers nous en posant des questions très précises et tu trouveras j'en suis sûr toutes les réponses à tes problèmes.

La durée de ton projet sera bien évidemment lié à l'importance de l'appli que tu devras développé. Commence par la gestion des mouvements (création de ta base articles et tes entrées-sorties). Pour les éditions et autres fonctions tu verras plus tard.

Tu trouveras également de nombreux exemples de sources sur le forum qui te permettront de t'aider dans tes recherches (Mais attention l’interprétation d'un code dont on n'est pas l'auteur est un exercice difficile : nous n'avons pas tous les mêmes raisonnements logiques).

Bon courage à toi

JimBoLion

[CaiiLle]

Bonjour Jimbolion,

Après lecture de tes informations et des essais.

Je viens de mettre en place une gestion des stocks à laquelle je compte intégrer la gestion des mise à jours prix.

Cependant et avant toute chose, la requête gestion de stock me pose quelque problème.

Pouvez vous m'aider ?

Je vous explique :
3 tables

T_Produit (NumProduit, NomProduit)
T_EntréeProduit (NumEntreeProduit, #NumProduit, DateEntreeProduit, QteEntreeProduit)
T_SortieProduit (NumSortieProduit, #NumProduit, DateSortieProduit, QteSortieProduit)

La requête Gestion de stock
NomProduit
QteEntreeProduit
QteSortieProduit
Stock (ici créé pour la requête) avec l'expression suivante :

Stock: [SommeDeQte_EntreeProduit]-[SommeDeQte_SortieProduit]

Bien que la requête fonctionne parfaitement, un problème intervient lorsque le champs [SommeDeQte_SortieProduit] est supérieur au champs [SommeDeQte_EntreeProduit].

Enregistrement de 100 produits en entrée
Enregistrement de 50 produits en sortie
- pas de souci calcul ok Stock=50

Enregistrement de 60 produits en sortie (normalement le résultat proposé doit être de -10)
- souci la requête "s'adapte"
- elle mets "sans aucune intervention" => 200 dans [SommeDeQte_EntreeProduit] puis effectue le calcul et propose comme résultat 110.

Avez vous une idée pour adapter la requête ???

Puis-je insérer une condition SI, qui empêche la validation de la saisie si le stock est inférieur à 0 ?

Je vous remercie de votre aide

[jimbolion]

CaiiLle bonjour,

Effectivement l'interprétation de la requête est bien étrange. Je n'ai jamais rencontré ce genre de problème sur des calculs sommés (même en négatifs).

Il me manque donc un certain nombre d'informations :

Comment est utilisé ta requête (générée dans du code VBA : dans ce cas une déclaration de variable peut être à l'origine de ton problème).

Je te propose de m'envoyer une version de ta base (même simplifiée par souci de confidentialité) avec l'origine de l'erreur ainsi que le moyen de la générée.

Je te fais un retour dans la journée.

JimBoLion

[CaiiLle]

Bonjour,

Vous trouverez ci-joint la base de données (aucune donnée n'est confidentielle).

Je vous remercie pour ton aide.



Ne prennez pas en compte la table TJonction_Site&Pole / T_Site / T_Pole
=> Car il devra remplacer à terme la table T_Client.

(Je vous explique le Site 1 via le Pole 1 commande les produits des fournisseurs attachés au pole en question)

[jimbolion]

CaiiLle bonjour,

Après lecture de ta requête j'ai identifié l'origine de ton problème, et il n'est pas du tout lié à des contrôles de mouvements de sorties supérieurs aux mouvement d'entrées. Partant de ton exemple tu peux mettre 10 et 10 dans tes sorties et tu verras que le résultat te donnera 180.

Donc ton problème vient de tes relations dans les requêtes, si tu enleves les valeurs de regroupements tu comprendras un peu mieux comment la mise en place des relations agit sur les requêtes SQL.

Donc je suis parti de 2 requêtes (une somme des entrées et une somme des sorties). La troisième requête agit simplement par différence. Il y a d'autres techniques, mais la réutilisation de ces requêtes pas regroupement te serviront plus tard. J'ai conservé ta requête d'origine (qui sera à supprimer + tard)

JimboLion

[mumen]

Envoyé par CaiiLle

Merci pour ta réponse.

Il me semble donc que cette solution ce rapproche d'une gestion de stocks ?

Si tel est le cas, comment mettre en place une telle gestion ? (ne connaissant pas suffisamment les codes Visual Basic et compagnies...

J'ajoute mon grain de sel.

Pour ton problème initial, il n'est pas judicieux de mémoriser les divers tarifs de tes fournisseurs. Le produit doit juste comporter le dernier prix d'achat connu. Ensuite, et jimbolion à raison, c'est un problème de modélisation : la transaction (la commande) doit obligatoirement comporter le prix d'achat (et le produit et la quantité et la date). Pour connaître les tarifs de ton fournisseur dans le temps, c'est à cette table que tu feras référence, par exemple en ajoutant un sous formulaire dans un onglet de ton produit qui liste les n dernières commandes).

La modélisation d'une gestion de stock est quand même fort complexe si l'on veut penser à tout. Or toute simplification de départ peut s'avérer un contretemps terrible. Par exemple 'on ne commande qu'un seul produit à la fois' 'la réception comporte la même quantité que la commande', etc.

Tu dois penser (même si tu n'adopte pas toutes les pièces et leurs interactions) la chaîne d'achats (stock + = commande, réception, facturation, avoirs, retours) ET la chaîne de vente (stock - = devis, commande, bon de livraison, facturation, avoirs, reprise) ET l'inventaire. Et on ne parle pas de compte fournisseur et client.

[CaiiLle]

Merci !!!

Plus j'avance dans la mise en place de cette base de données et plus je me perds.

Cela fait plusieurs années que je n'ai pas utilisé Access. Et je vous avouerai qu'il est bien difficile de retrouver ces marques.

La base a pour finalité de gérer les stocks d'une société comprenant plusieurs établissements (chaque établissement ayant des pôles) et de la prise de commande fournisseurs.

Ces pôles au nombre de 4 sont Administration, Technique, etc...

1. D'un côté, une gestion des stocks

Les stocks étant entrée manuellement lors de la vérification à la livraison et sortie au fur et à mesure de l'utilisation des produits.

Pour cette partie, je pense être arriver à son terme. Merci à vous !!

1. De l'autre, une gestion des commandes achats

Chaque établissement via un pôle, commande les produits auprès des fournisseurs rattachés au pôle.
(Pour compléter cette information, le fournisseur OCTA du pôle ADMINISTRATIF est le même pour l'ensemble de la société)

Et à ce moment précis, je retombe sur la première demande formulée sur ce post, les tarifs des produits changent régulièrement. Et là, je coince !!!

Ici, la T_Client a terme sera remplacer par la/les table T_Site et T_Pole.

La gestion de commande avec un prix standard est plutôt facile à mettre en place par contre sélectionner un prix en fonction de sa date et générer une commande à laquelle nous souhaitons garder un oeil dans le futurs je n'y arrive pas.

Avez-vous des idées de mise en place ?

Je continue mes diverses recherches sur les forums spécialisés.

Je vous remercie pour votre aide et votre patience.

[mumen]

Dans ce que j'ai compris de ta formulation, deux problèmes sont posés qu'il faut discerner pour avancer.

1. Au 01/03/2013, le tarif évolue. Or, je souhaite visualiser la commande "COMMANDE001" avec les informations antérieures à la mise à jour du prix du produit A.

   Tu veux mémoriser et pouvoir afficher par la suite le prix qui a été pratiqué lors de la prise de commande : Oui ?
   
   

2. Et à ce moment précis, je retombe sur la première demande formulée sur ce post, les tarifs des produits changent régulièrement.

   Tu semble en mesure de pouvoir anticiper les prix de tes fournisseurs. Bien. Mais dans quelle mesure ? je veux dire peux tu prévoir une grille de tarification par fournisseur dans le futur et non pas juste le prochain prix et sa date d'application ?

Autre chose, dans ta description, il n'est jamais question d'une table des produits, c'est juste ?

[jimbolion]

CaiiLle bonjour,

As tu jeté un oeil sur le correctif que je t'ai envoyé ?

Concernant la suite de ton projet et concernant la gestion de tes commandes, je te propose de mettre cette discussion à Résolu (car on va mélanger toutes les aspects du projet) et de ré-ouvrir un message sur la problématique gestion des commandes.

Tu devras préparer ton modèle (tables, relations) ainsi que les contraintes (prix d'achats fluctuants...). Un simple document dans lequel tu imagines l'ihm et les enchainements (très concis) nous permettra de vérifier la cohérence du modèle. Une formalisation plus détaillée sur la finalité de l'applicatif (statistiques, reports...) permettra également de valider la viabilité de ta solution.

JimBoLion

[CaiiLle]

Bonjour,

• Pour la premier question.. C'est exactement ce que je souhaite mettre en place.

• Pour la seconde concernant les tarifs produits

Chaque fournisseur m'informe via un grille de tarif des tarifs applicable à un date donnée.
Ces nouvelles informations dès réception sont enregistrées dans la table T_TarifsProduit.

J'ai effectivement les tables paramétrées pour le moment de cette manière :

T_Produit (Num_Produit (clé), Nom_Produit, Num_Fournisseur (clé étranger T_Fournisseur))
T_TarifProduit (Num_TarifProduit (clé), Num_Produit, Tarif_TarifProduit, Date_TarifProduit)
T_Fournisseur(Num_Fournisseur (clé), Nom_Fournisseur, Num_Pole (clé étranger de T_Pole))

[Thierry_PALLIER]

Bonjour le forum .
En partant de l'idée de Minot83 , pour moi ,il faut ajouter un champ dans la table T_Produits_Tarif ,pour avoir la periode de validité d'un tarif .
Dans la table T_Produits_Ventes ,un champ Id_Tarif, et un champ "Tarif_unitaire" .Ce dernier champ n'est pas obligatoire mais évitera des requetes complexes..
Sans oublier un champ Id_Tarif
Une table T_Produits_Tarif (Id_Tarif, FK_Produit, Tarif_unitaire, DateDebut_Tarif, DateFin_Tarif)
Une table T_Produits_Ventes (Id_Vente, FK_Produit, Id_Tarif, Tarif_unitaire, FK_Client, Quantité, Date_Vente,...)
Ensuite, dans ton formulaire de vente ,sur l'evenement AfterUpdate de ton produit (FK_Produit) ,faire une procedure:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Private Sub QuelTarif(LeNumero_vente As Long, LeMatos As String)
Dim MonSql As String, MonRst As dao.Recordset
 
MonSql = "SELECT DISTINCT T_Produits_Ventes.Id_Vente, T_Produits_Tarif.FK_Produit, T_Produits_Ventes.Date_Vente, T_Produits_Tarif.Tarif_unitaire, T_Produits_Tarif.Id_Tarif" & _
" From T_Produits_Tarif, T_Produits_Ventes" & _
" WHERE (((T_Produits_Ventes.Id_Vente)=" & LeNumero_vente & ") AND ((T_Produits_Tarif.FK_Produit)=" & Chr(34) & LeMatos & Chr(34) & ") AND ((T_Produits_Ventes.depart) Between [T_Produits_Tarif]![DateDebut_Tarif] And [T_Produits_Tarif]![DateFin_Tarif]));"
'Debug.Print MonSql
Set MonRst = CurrentDb.OpenRecordset(MonSql)
With MonRst
Me.Tarif_unitaire = !Tarif_unitaire
Me.Id_Tarif = !Id_Tarif
End With
MonRst.Close
Set MonRst = Nothing
'Me.Refresh
End Sub

L'argument "LeMatos" representant FK_Produit en cours.
Ainsi ,tu retrouve le tarif et son identifiant en fonction de la date de vente.
Tu peux aussi ,facilement faire un formulaire de visualisation de ta vente passée ,avec le bon tarif puisqu'il est enregistré dans ta table.
J'ai repris cette sub de mon appli en adaptant le nom des champs
J'espère que c'est compréhensible .

[CaiiLle]

Jimbolion,

Je vous confirme que cela fonction bien et que c'est le résultat escompté.

Lorsque je m'attaquerai à la création de formulaire, j'adapterai la mise en page.

Merci

[CaiiLle]

Bonjour,

Ayant réfléchi à cette problématique de gestion des stocks.

La requête que vous me proposez me permet d'avoir un suivi des stocks pour l'ensemble de la société.

Comment puis-je faire un suivi des stocks par établissement ?

Merci pour votre aide