Discussion :

[jessenierin]

Bonjour
Je suis entrain de développer une application de gestion de stock.
Voici a peu près comment la fiche de l’article va se présenter. (Voir piece jointe)
Pour la colonne des entrées et de sorties ; je ne rencontre pas de problème. Seulement pour la colonne de stock cela se complique. Sur Excel (voir Tableau A) ; la fonction est facile mais sur accès 2003 ; je n’arrive pas a faire une fonction qui tienne compte du résultat antérieur.
Exemple : comment calculer la valeur c4 en partant de sa valeur précédente (C1) plus l’entrée du jour et la sortie du jour ??
Il en est de même pour le calcul de c6 ; c7 ; c9 ……
Je suis perdu
Help please.

[marot_r]

Access ne fonctionne pas du tout sur le même principe que Excel.

Et si tu veux éviter d'autre mauvaises suprises de ce genre consulte les tutoriaux sur les bases de données relationnelles.

En gros une table Access c'est un 'bête' tableau qui ne dispose d'aucune faciliter de calcul. Elle ne contient que des données inertes. L''intéligence' est dans les forms, les modules et les requètes.

Il faut enregistrer ton solde initial quelque part et ajouter les mouvements survenus depuis pour obtenir le solde courrant. C'est la méthode la plus simple.

A+

[random]

On peut parfaitement dans access reproduire le fonctionnement d’excel, c’est seulement un peu moins intuitif.
En fait le problème est de savoir aller chercher la ligne précédente que l’on souhaite trouver, pour cela il faut disposer d’une clef unique ordonnée, un compteur numérique ou un champ horodaté convient parfaitement.
A titre d’exemple pour ton problème de stock je te propose de créer une table (matable) avec les champs suivants :
Maclef clef principale compteur auto
Monproduit champ texte
Maval champ numérique
Maval2 champ numérique

Il suffit alors de lancer la requête ajout suivante pour créer des enregistrements calculés

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
NSERT INTO matable ( monproduit, maval, maval2 )
SELECT monproduit, [qute] AS nval, [maval2]+[qute] AScumul
FROM 
(SELECT TOP 1 monproduit, maval2
FROM matable
WHERE monproduit=[produit]
ORDER BY maclef DESC);

[PatriceLep]

Personnellement je conseille de ne pas mettre de champ calculé dans une table de ce type. Il vaut mieux, dans le formulaire, état ou requête, mettre une zone calculée via une requête.
Si non il devient totalement impossible de revenir sur des saisies déjà effectuées.

Patrice

[random]

en matière de gestion de stock il est préférable de mettre en dur dans la table
les champs calculés
d'autre part on ne revient jamais en principe sur les saisies effectuées aussi erronées soient elles, tracabilité oblige , on prévoit des transactions spécifiques de retour client ou fournisseur

[PatriceLep]

en matière de gestion de stock il est préférable de mettre en dur dans la table les champs calculés

Peut-être mets-tu également la valeur du stock ... sachant qu'avec une gestion par lots (traçabilité oblige) la valeur d'achat est souvent connue après avoir effectué les sorties ... dur, dur !!

d'autre part on ne revient jamais en principe sur les saisies effectuées aussi erronées soient elles, tracabilité oblige , on prévoit des transactions spécifiques de retour client ou fournisseur

Si les procédures ISO 9000-xx prévoient une interdiction de modification des saisies effectuées (ce qui est rare à ma connaissance : domaines déjà traités = aéronautique, armement, automobile, nucléaire, etc.) cela ce réalise par des règles de gestion de la base de données et ne change rien au principe de recalcul des champs calculés, juste pour un principe d'unicité de l'information.

Patrice
Débutant depuis 35 ans

[random]

Sur la question des champs calculés, le fil rouge n’est pas l’orthodoxie mais l’efficacité. Si la base est peu volumineuse et les calculs simples, on appliquera normalement les principes canoniques « pas de champ calculé, information unique etc ». Par contre si on prévoit de nombreux accès, si les calculs sont longs et complexes, ou si les volumes sont importants il peut être productif d’introduire des champs calculés. Les techniques de gestion et d’organisation de base et les diktats de merise sont avant tout au service d’un résultat qu’ils doivent accompagner et non entraver.

Je respecte tes 35 ans d’expérience (le temps ne fait rien à l’affaire) mais sur le principe d’intouchabilité des opérations saisies je serais plus ferme, au niveau des fichiers de base on doit pouvoir tracer les opérations élémentaires dans la plupart des domaines qu’ils soient iso ou non. Une simple application de gestion ne devrait jamais procéder par destruction de données pour les annulations, mais par création d’une information nouvelle modifiant le statut
de l’information antérieure.

[PatriceLep]

Je respecte tes 35 ans d’expérience (le temps ne fait rien à l’affaire) mais sur le principe d’intouchabilité des opérations saisies je serais plus ferme, au niveau des fichiers de base on doit pouvoir tracer les opérations élémentaires dans la plupart des domaines qu’ils soient iso ou non. Une simple application de gestion ne devrait jamais procéder par destruction de données pour les annulations, mais par création d’une information nouvelle modifiant le statut
de l’information antérieure.

Le problème des saisies correctives (donc annulation puis re-saisie de la bonne opération) est quelles risquent de fausser les analyses statistiques (rotation des stocks, consommation, etc. dans ce cas) et de rendre la traçabilité quasi inutilisable.

Mais tout est question d'analyse. Il n'y a pas de règle absolue.

Dans le cadre de ce topic ou il est question de passer une gestion de stocks sous Excel à Access, il me semble évident que le volume de mouvements saisi et le nombre de références ne doit pas relever de la gestion d'un hyper-marché. La règle de non enregistrement des champs calculés me semble donc parfaitement applicable (ce qui est d'ailleurs le cas actuellement sous Excel). Quant à la protection des mouvements saisis, je doute de son existence dans une application Excel.

Patrice
toujours débutant et heureux de l'être

[adelaine33]

bonjour jessenierin ,

Avez vous reussi a faire fonctionner un champs calculé a partir d'une valeur precedente.
Car moi aussi je monte une application de gestion de stock et j'ai lme meme probleme que vous pour le calcul du cout moyen unitaire pondéré.
"Exemple : comment calculer la valeur c4 en partant de sa valeur précédente (C1) plus l’entrée du jour et la sortie du jour ??"

Comment avez vous resolu votre probleme sur access?

Cordialement

adelaine33
tutu33-64@hotmail.fr

[clo5000]

Bonjour,

la valeur précédente peut être obtenu en recherchant dans le champ clé unique, qui peut être une date ou un numérique. tu peux utiliser les fonctions de domaine dans VBA ou directement dans le champ du formulaire qui doit recevoir cette valeur.