Discussion :

[free_dom]

Bonjour,

Je suis entrain de développer une application pour la gestion de stock d'un magasin,
- il y a des bons d'entrée et des bons de sortie.
- un bon d'entrée peut avoir un ou plusieurs articles.
- pour chaque bon d'entrée et pour chaque article un calcul du prix moyen pondéré (PMP) doit être effectué et enregistré dans la table stock.
- le bon d'entré est sous la forme d'une fenêtre qui contient les infos du bon en haut et une table qui contient tous les articles concernés.
- le calcul du PMP pour chaque article, est comme suit: (Valeur Stock + (Qte Recue * Prix U) / (Qte Stock+Qte Recue)
- une possibilité de modification du bon de réception existe et c'est la le problème.

Ma question; Dans le cas de modification (suppression ou ajout) d'un article dans la table du bon d'entrée, comment je peux recalculer le PMP.

j'espère que c'est clair et qu'il existe un moyen pour le faire.

Merci.

[serendib]

Bonjour,

Un bon d'entrée (réception) a une date (d'entrée) et le Prix achat,
un bon de sortie (livraison) a une date (de sortie).
On peut ainsi reconstituer un stock à un instant T (Fondamental pour permettre d'éditer un état de stock à posteriori)
Et donc recalculer un PMP à une date précise à tout moment, à fortiori en cas de modif ou d'ajout.
C'est ainsi que je procède et je n'ai jamais rencontré de problème.
Après deux méthodes possibles :
- en temps réel au moment de la modif de la réception ou de la livraison.
- en batch, ce qui s'avère souvent suffisant dans les petites structures.
C'est au client que revient la décision.

[DelphiManiac]

Bonjour,

Un bon d'entrée (réception) a une date (d'entrée) et le Prix achat,
un bon de sortie (livraison) a une date (de sortie).
On peut ainsi reconstituer un stock à un instant T.
Et donc recalculer un PMP à une date précise à tout moment, à fortiori en cas de modif ou d'ajout.
C'est ainsi que je procède et je n'ai jamais rencontré de problème.

A condition que l'on autorise pas les stocks négatifs !! Ce qui n'est pas toujours le cas en situation réelle.

Un stock négatif étant du au fait que l'on saisi le bon d'entrée après le bon de sortie (erreur de saisie de date lors de la saisie de la pièce par exemple), cela peut être du aussi à une erreur de quantité sur le bon d'entrée.

Il faut aussi intégrer dans cet algorithme les retours de marchandises (a quelle valeur ?, celle de la date de sortie, il faut dans ces cas retrouver la pièces d'origine), les dépréciations de stock (pour raison comptable), les rectifications de stocks (vols, dépérissement de la marchandise).

D'autre part sur des gros volumes, il n'est pas vraiment envisageable de reconstituer le stock à chaque fois que l'on a besoin de connaître le PMUP (lecture et tris pas date de plusieurs milliers d'enregistrements).

En théorie, il est possible de calculer un PMUP juste tout le temps, en pratique, ce n'est pas toujours le cas. Du moins, je ne connais pas de règle absolu.

[serendib]

Bonsoir Eric,

Il est, en pratique, difficile de ne pas autoriser les stocks négatifs.
L'utilisateur final ayant une forte tendance à remettre au lendemain ce qui devrait être fait le jour même.
Ainsi il effectuera demain ou même plus tard la réception d'un produit reçu ce jour.
Et puis il peut se tromper de produit, ou de qté.
Donc chez moi on autorise les stock négatifs.
Il convient dans ce cas de bien avertir le réceptioniste que lors de son entrée en stock il doit veiller à ce que la date de réception
soit la date réelle de celle-ci et non bêtement la date du jour.
Pour ma part, lors de la réception, si le stock est négatif, je l'averti que que le PMP n'est pas calculable.

Lors de la modification d'une réception à posteriori recalcul du PMP.
Idem lors d'un retour de marchandise (avoir).

La méthode que j'utilise :
Sur la fiche produit, un bouton permet de recalculer le PMP d'un produit (c'est très rapide, même pour un produit à forte rotation)
Et puis même si ça durait 10 secondes (ce qui serait énorme) , c'est à faire, point de salut.

D'autre part une fenêtre permet de recalculer tous les PMP, avec indication de toutes les anomalies.
Tout est automatique sauf en cas d'anomalies ou l'utilisateur intervient.
La plupart du temps il s'est planté sur la date de réception ou la qté.
Il corrige et je recalcule.
Cette fenêtre sert également à sortir une valo d'inventaire à une date précise (antérieure bien entendu)
J'utilise cette méthodologie chez mes clients depuis plus de vingt ans et personne n'a trouvé à redire, pas même le comptables,
ni même les experts comptable (c'est dire !)
Bien entendu c'est assez complexe à mettre au point mais ça a le mérite d'être fiable.

[free_dom]

Bonsoir,

Je vous remercie serendib et Eric de vos interventions,
je suis débutant en Windev, et je viens de réaliser le calcul du PMP après chaque entrée d'un article,
pourriez vous m'indiquer comment je peux recalculer le PMP après une modif (suppression ou ajout) d'un article qui concerne un bon d'entrée,
je ne sais pas si c'est compliqué à le réaliser et si vous avez une piste qui explique comment codifier cette opération en windev ça sera mieux,

Merci.

[free_dom]

Quelqu'un a une idée comment je peux codifier la solution ...

Merci

[serendib]

Montres-nous déjà ton analyse.
Tout dépends d'elle.

[free_dom]

Bonjour,
Je m'excuse pour ma réponse tardive,
vous trouvez ci-joint l'analyse du projet, je ne sais pas si c'est correcte, à vous de donner les remarques.
Merci.

[serendib]

Bon, les deux fichiers qui seront utiles sont Détail_BR et Détail_BS.
Perso, dans Détail_BR je rajouterais la date d'entrée, et dans Détail_BS la date de sortie.
Ceci pour optimiser le recalcul sans être obligé d'aller lire les en-têtes des Bons.

Il suffit alors de concaténer ces deux fichiers détails et de les trier par date en privilégiant l'entrée si même date.
On peut utiliser un tableau, une table mémoire, un fichier temporaire, bref, c'est au choix.
Ensuite c'est simple, on recalcul pour chaque ligne le PMP selon la formule consacrée.
Reste à prévoir les anomalies citées dans mon post plus haut, en permettant à l'utilisateur d'intervenir.
(par exemple il a saisi une livraison avant la réception, il corrigera une des deux dates.)
A vous de prévoir tous les cas.

Reste à définir à quel moment on effectue ce contrôle.
- en temps réel lors d'une modif, suppression ou ajout de réception.
- dans un traitement spécifique de contrôle de tous les articles.

Tout dépend de la qté de réceptions/livraisons d'un même article, d'une part,
de l'importance stratégique du PMP d'autre part.
Si l'info marge est primordiale il faut du temps réel, si le PMP ne sert qu'à calculer la valeur du stock
au bilan, on peut se contenter d'un traitement global de temps en temps.
C'est à vous mais surtout à l'utilisateur de choisir.
Attention, tout celà peut se révéler plus compliqué selon
- le type d'entreprise (fabricant, négoce, commerce)
- le type de produit (produit simple, produit composé, nomenclature)
et donc nécessite une belle reflexion avant de se lancer dans la codification.
Mais n'est-ce pas l'intérêt de notre métier ?
Voilà, vous avez tous les élements de cette réflexion.
A vous de jouer.

[free_dom]

Merci serendib, je vais essayer de réfléchir comment je peux codifier ça selon votre solution.
je vous tient au courant.

[free_dom]

Bonjour,

Je reviens pour travailler sur le projet de Gestion de Stock, et je voudrais poser quelques questions:
Dans mon cas, je fais la modification en temps réel et le PMP est calculé après chaque entrée,
en cas de modification, le client doit informer la DFC en établissant un Bon de régularisation.

Concernant la modification du Bon de réception, Bon sortie ou Bon de retour, est ce que je dois procéder à la modification de tous les produits cités dans le bon en question ou juste le produit modifié (Prix, quantité), sachant que des fois le client supprime un produit ou le remplace avec un autre.

Il y a aussi le cas de modification de la date du Bon, est ce je dois recalculer tous les PMP des produits en mouvements après la nouvelle date du Bon concerné.
sachant que le PMP figure dans la table Stock.

Merci.

[free_dom]

Il suffit alors de concaténer ces deux fichiers détails et de les trier par date en privilégiant l'entrée si même date.
On peut utiliser un tableau, une table mémoire, un fichier temporaire, bref, c'est au choix.
Ensuite c'est simple, on recalcul pour chaque ligne le PMP selon la formule consacrée.

Suite à mon message précédent,

j'ai les variables: StockRest, StockVal qui sont propres à chaque produit dans la table Stock,
donc pour chaque entrée (Bon de réception), je fais:

Code :

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

1
2
3
StockRest = StockRest + QteRecue
StockVal = StockVal + (QteRecue*PU)
PMP = StockVal / StockRest

Dans ce cas, pour recalculer le PMP pour chaque ligne, je n'ai pas les valeurs instantanées du StockRest et StockVal en cette date de modification (date du BR ou BS).

qu'est ce que je dois faire dans ce cas ?

Merci.

[serendib]

Bis repetita :

Bon, les deux fichiers qui seront utiles sont Détail_BR et Détail_BS.
Perso, dans Détail_BR je rajouterais la date d'entrée, et dans Détail_BS la date de sortie.
Ceci pour optimiser le recalcul sans être obligé d'aller lire les en-têtes des Bons.

Il suffit alors de concaténer ces deux fichiers détails et de les trier par date en privilégiant l'entrée si même date.
On peut utiliser un tableau, une table mémoire, un fichier temporaire, bref, c'est au choix.
Ensuite c'est simple, on recalcul pour chaque ligne le PMP selon la formule consacrée.

[free_dom]

J'ai rajouté à mon dernier message des détails,
et cela après la concaténation des deux fichiers, alors j'ai créé un nouveau fichier qui s'appelle mouvement,

j'ai posé la question suite à l'obstacle que j'ai eu lors de la programmation, j'ai dit que je n'ai pas les valeurs instantanées du StockRest et StockVal en cette date de modification (date du BR ou BS) en se basant sur les calculs cités ci-dessus.

Peut être j'ai oublié une information à rajouter.

[b_reda31]

Bonsoir,
Je m'excuse de déterrer un sujet aussi ancien, mais je me trouve dans cette même problèmatique qui est : la repercussion des valeurs de pmp sur les lignes de mouvement suite à une modification.

Bon, les deux fichiers qui seront utiles sont Détail_BR et Détail_BS.
Perso, dans Détail_BR je rajouterais la date d'entrée, et dans Détail_BS la date de sortie.
Ceci pour optimiser le recalcul sans être obligé d'aller lire les en-têtes des Bons.

Il suffit alors de concaténer ces deux fichiers détails et de les trier par date en privilégiant l'entrée si même date.
On peut utiliser un tableau, une table mémoire, un fichier temporaire, bref, c'est au choix.
Ensuite c'est simple, on recalcul pour chaque ligne le PMP selon la formule consacrée.

J'ai ecris une procédure 'CalculerPMPLigneMouvement(IdProduit)' qui se charge de recalculer les pmp dans l'ensemble des ligne de mouvement d'un produit donné en paramètre.
J'utilise le principe décrit par Serendib :
Parcours de l'ensemble des lignes de mouvement (d'un produit) par date heure, et calcul du pmp de chaque ligne selon la formule consacrée au pmp.

Maintenant si l'utilisateur modifie une ligne de mouvement d'un produit, il suffira d'appeler cette procédure afin de regler les pmp sur l'enemble des lignes du produit.

Sachant que les ligne concernée par la mise à jour du pmp seront forcément posterieures à la ligne modifié, il est en effet inutile de recalculer les pmp avant la modifs,
j'ai donc penser à "optimiser" ce traitement de manière à fournir la date heure à partir de laquelle commencer les calculs.
Par exemple si un produit contient 100.000 ligne de mouvements et qu'on modifie l'avant dernière lignes (la ligne 99.999 en teme chronologique), il sera inutile de revoir toutes les lignes puisque seule la ligne 100.000 sera concernée par une mise à jour de pmp.

j'ai donc pensé à ré-ecrire le procédure de calculer en lui fournissant un deuxième paramètre qui représente la DateHeure à partir de laquelle commencer le traitement.
le problème c'est que la forumule de calcul du pmp fait intervenir deux valeurs qui ne sont pas stockée dans la bases : QtStockPrécédente, ValeurStockPrécédente (valeur juste avant la dateheure)

Pensez-vous qu'il soit judicieux de stocker ces deux valeurs dans le fichier de LigneMouvement afin d'éviter de les recalculer (en parcourant tous les mouvement) ?
Avez-vous d'autres solutions ?