[AC-2010] [démo] Gestion de stock avec les évènements de table

[f-leb]

Bonjour le forum,

on parle peu d’Access 2010 avec ses évènements de table (triggers) et pourtant…

La démonstration s’appuie sur une gestion de stock (simplifiée) avec le schéma suivant volontairement dénormalisé avec le champ QtteStock:


Le but est de tenir à jour le champ QtteStock suivant l’évènement produit dans la table des mouvements (insertion et/ou mise à jour). Comme nous interceptons les évènements sur TblMouvement grâce au mécanisme de triggers proposés par Access 2010, nous pouvons effectuer les saisies directement dans la table en mode "feuille de données".

Partons du jeu suivant :


Insérons une première entrée :


On vérifie que la table des articles est mise à jour :


Poursuivons avec quelques mouvements supplémentaires :

Chaque insertion a bien été prise en compte.

Que se passe-t-il si on insère une sortie de 100 scoubidous (zéro en stock) ?

Avant d’insérer la ligne (évènement : avant modification), on teste si le mouvement est possible. S’il ne l’est pas, la ligne ne peut être validée et un message apparait.

Testons la mise à jour d’un mouvement existant.
Le mouvement idMouvement=5 était en fait une entrée de 50 pommes :


Ah non, gouré ! Le mouvement idMouvement=5 était en fait une entrée de 50 scoubidous :


Et puis modifions totalement la ligne idMouvement=5 :

La mise à jour est OK dans tous les cas.

Bien entendu, avant toute mise à jour, on teste si le mouvement est possible. Essayons en modifiant une dernière fois ce mouvement idMouvement=5 :


Il reste le cas des suppressions de mouvements qui me pose encore quelques problèmes dans certains cas et qui n’est donc pas implémenté pour le moment.

Ci-joint le fichier GestionStock.accdb.

Un peu d’indulgence pour le code un peu cracra, je n’ai Access 2010 que depuis 15 jours mais le but était de montrer les nouvelles possibilités de programmation dans les évènements de table.

Quoi que la mise au point et le déboguage des macros de données m’a semblé peu évidente, je pressens quand même que de nombreux évènements vont prochainement être interceptés de cette manière plutôt que par du VBA dans les évènements des formulaires.

Et vous ?

[Philippe JOCHMANS]

Bonjour

En dehors du fait que je n'ai pas Access 2010 , merci pour cette petite démonstration d'une des nouveautés de cette version.

Travaillant actuellement sur un logiciel de gestion de stock, je voudrais mettre un petit bémole, mais pas sur ta démonstration, mais sur le but.

Tu utilises cet évènement pour mettre à jour une table qui te donnera l'état du stock du produit, hors cette information peut-être obtenue par la table des mouvements, elle est donc redondante, cela va à l'encontre de ce que l'on explique souvent dans la partie modélisation (où je te remercie pour ton excellente participation dans celui-ci).

En résumant, même si l'exemple est parlant, il est pour moi à éviter dans la redondance d'infos.

Philippe

[f-leb]

Bonsoir Philippe,

en tant que normôlatre je ne peux qu'approuver ta remarque

Envoyé par f-leb

... avec le schéma suivant volontairement dénormalisé avec le champ QtteStock:

dénormalisation= redondance, risque d'incohérence etc...

Toutefois dans la pratique, on trouve de temps en temps quelques entorses à la règle (comme le prix de l'article, le nom&adresse du client que l'on recopie dans la table des commandes). Je pense par exemple au cas où le traitement pour connaître l'état du stock s'avère coûteux en temps de calcul ou plus complexe encore avec la gestion FIFO etc....

Je n'incite évidemment pas à dénormaliser mais quitte à le faire (calculs ou règles de gestion complexes), autant le faire en minimisant les risques d'incohérences. Je trouve que les évènements de table sont alors particulièrement adaptés pour gérer la redondance.

Envoyé par Philippe JOCHMANS

...même si l'exemple est parlant...

C'est déjà ça

[Philippe JOCHMANS]

Re

Envoyé par f-leb

Je pense par exemple au cas où le traitement pour connaître l'état du stock s'avère coûteux en temps de calcul ou plus complexe encore avec la gestion FIFO etc....

Tu as raison

[naphta]

Bonjour,


mon fils fait un stage dans une société qui lui ont demandé une mini gestion de stock sous access et je suis tombé sur une base modèle de gestion de stock chez microsoft.
A peu près la même chose que ce qui est proposé ici, une gestion de stock par mouvements.

Je trouve cela pas mal car c'est dynamique, on peut revenir facilement sur un mouvement comme dans un journal de transactions.
C'est certain qu'au niveau conception et mise en place c'est sportif.

La responsable de la boite ou bosse mon fils à rien compris au mcd et lui a demandé de revenir sur un système tradi à cumul, mdr.

a+