Discussion :

[rabis]

bonjour; je suis entrain de realiser un programme de gestion de stock;mais je n'arrive pas à faire le calcul des produits sorties et ceux rentrees.

[le_dilem]

Dans tes entrées tu dois avoir un champ pour appuyer ta requête 'E' par exemple
et "S" pour les sortie.

sinon je vois pas comment tu peux faire

[Raptor92]

Bonjour,

Dans tes entrées tu dois avoir un champ pour appuyer ta requête 'E' par exemple
et "S" pour les sortie.

sinon je vois pas comment tu peux faire

Je pense que c'est un peut raccourci, en fait, il faudrait que rabis nous donne plus d'explications.

- Le type de BDD
- Quels sont les fichiers (ou tables) utilisés
- Avez vous mis en place un fichier (ou table) des mouvements entrés / sorties ?

Et lorsque vous dites avoir un problème de calcul, cela veut il dire que vous bloquez à un endroit spécifique de votre code (et dans ce cas où...), où avez vous un souci autre ?

Et pour finir, quel est le type de produit en question ?

La réponse peut avoir son importance, car si je compare à notre cas, un produit de découle ne plusieurs coloris et plusieurs tailles, ce qui nous donne un nombre important d'article à gérer.

Au vue de vos réponses, il sera beaucoup plus facile de vous aider

Bonne après midi

[Marco46]

Quand j'ai eu à faire ça j'avais une table des mouvements de stock, rattachée à ARTICLE (clef de article dans mvt_stock donc) et j'avais un fichier des STOCK_QTE rattaché à ARTICLE en relation 1<->1 (je sais plus pourquoi, pour avoir un truc séparé d'articles je crois).

Ensuite dans les mouvements j'avais mis un champ MVT_NATURE pour définir si c'est une entrée ou une sortie, ET un champ MVT_TYPE pour dire si le mouvement est dû à une manipulation d'administrateur, à un BL, à un inventaire, etc ... Histoire de pouvoir faire des stats non seulement en fonction des entrées/sorties mais aussi en fonction de l'action effectuée.

Après on peut rajouter tout un tas de données sur le mouvement, date, heure, opérateur, ... L'essentiel étant d'implémenter les transactions lors de la modification du stock. Avec des procédures globales ou une classe pour avoir le code d'entrée et de sortie à un seul endroit.

Je vois pas trop quoi dire de plus.

[Raptor92]

Bonjour,


Pour compléter ce que dit Macro46:
Pour l'exemple, j'utilise le terme "Table" en cas d'utilisation d'une BDD SQl

La structure de la BDD soit être celle ci:

1- TABLE ARTICLES
2- STOCKS
3- MOUVEMENTS
4- TYPES

Il est important de déterminer le type de mouvement, pour cela il vous faut renseigner la table TYPES

Exemples:

EDS- ENTRE DE STOCKS
SDS- SORTIE DE STOCKS
BLDIR - BON DE LIVRAISON SANS COMMANDE
..........

Ceci est un début de piste............mais il serait bon que rabis nous donne de plus amples explications sur ses besoins.

Bonne après midi

[Marco46]

2 remarques :

1 - Je pense que c'est mieux de distinguer la nature (E/S) et le type (Inventaire, BL, etc ...) pour être plus précis.
2 - Les types ne devraient pas être un fichier de base mais des constantes car il sera probablement nécessaire d'avoir des prédicats (SI machin = type_inventaire ALORS ...) basés sur ces types. Donc il faut bien que le programmeur saches que telle constante est un inventaire dans le code.

Je reconnais cependant que si il s'agit simplement d'afficher des stats alors on peut avoir une gestion des types dynamique via un fichier de base.
Mais pour le coup je préfère des constantes en dur dans un fichier texte .WL inclus dans le code d'init du projet.

[vmolines]

Question sans rapport avec le sujet mais quel est l'intérêt d'un fichier externe de constantes par rapport à une déclaration de constantes directement dans les sources du projet ?

[Raptor92]

Bonjour,

Et à Vmolines....

Question sans rapport avec le sujet mais quel est l'intérêt d'un fichier externe de constantes par rapport à une déclaration de constantes directement dans les sources du projet ?

Je ne suis pas d'accord, ceci est pile dans le sujet, il n'y a à mon sens, aucun intérêt à utiliser un fichier texte.
Ceci doit être considéré comme une variable de la table MOUVEMENTS.
Le type étant le type de document et non pas le type de mouvement.

Je n'ai pas forcement compris Macro26 en ce qui concerne l'inventaire..mais si cela est en vue de la réalisation d'un inventaire, alors je pense que cela doit faire l'objet d'un autre débat, car dans ce cas, il faut intégrer la notion de mémorisation de stocks i tout....i tout.....

Venant de finaliser avec succès les phases test de cette partie, je sais que cela n'a rien a voir avec la gestion de stock proprement dite....

Bonne fin d'après midi

[vmolines]

Je voulais dire sans rapport avec le thème principal du sujet (mais oui elle émane bien de la remarque de Marco).

Après la gestion de stock ne m'intéressait pas spécialement , je vous laisse vous battre

[Raptor92]

Bonsoir Vmolines,

Je suis dans le même cas de vous, mais si je peut aider....
C'est une partie pour moi qui comme vous se trouve derrière moi.

Je suis simplement curieux de la réponse de rabis....

Bon WE

[EDM-TAHITI]

Hello,
Bonjour à tous... Je prends le post en route, désolé...
Pour la gestion des stocks, sujet déjà abordé, deux notions à savoir
la première, les sortie sont forcément des pièces clients, donc identifiables, donc, lorsque une facture, un bon de livraison est saisi et validé, il faut simplement destocker les articles du style

PARTIE CLIENT

article.qte -= facture_article.qte
modifier la fiche article

si suppression de la ligne de facturation article

article.qte += facture_article.qte

Mais, il y a aussi les modifications de la ligne d'article pour les qté, il faut donc gérer la derniere saisie enregistrée (ex_qte) et faire

article.qte += facture_article.qte - facture_article.qte_ex

PARTIE FOURNISSEURS

Lors de la saisie d'une facture fournisseurs, il faut normalement calculer le PUMP (prix unitaire moyen pondéré) et garder dans la fiche article le dernier prix de revient (PRE - prix revient entrepot)
Une fois la saisie de la facture FOURNISSEURS réalisée, il faut mettre à jour les stocks par une procédure

// stockage des données
qte est un entier = article.qte
pump est un reel = article.pump
// calcul entrée de stock
article.qte += facture_fournisseur.qte
article.pre = facture_fournisseur.prix_achat_ht
article.pump = ( (qte*pump) + (facture_fournisseur.qte*facture_fournisseur.prix_unitaire_ht) ) / (qte+facture_fournisseur.qte)

Voilà comment je fais, mais c'est très succincte . J'explique simplement les grands principes...

Après, il faut pouvoir gérer les stocks sur bon de livraison, si cette option est retenue (pour avoir des stocks a jour), avoir l'option de facturer sur des stocks négatifs (à faire absolument), etc...

Voilà ce que je peux vous écrire, mais la gestion des stocks est la partie la plus ardue dans une gestion commerciale...

[SevenSoftware]

Bonjour,

Vrai que, si Rabis pouvait nous en dire plus...

Perso, je signe les quantités dans le fichier mouvements. Au pire,
en l'absence d'autres critères, je pourrais toujours sélectionner les qtés négatives pour les sorties et positives pour les entrées...

La réalité etant généralement plus complexe !

Patrick.

[Raptor92]

Bonsoir,

Et particulièrement à Eric,

Je pense pour ma part que ce sujet a été débattu à de nombreuses reprises (N'est pas Eric ?.......) et que cela va ce terminé par le fait qu'un jour nous devrions soumettre un tuto sur le sujet.

Mais quoi qu'il en soit, et pour finir, une gestion de stock ne rime à rien si, (comme nous n'arrêtons pas de le dire......) cela ne s'intègre pas d'une manière générale avec la gestion des articles, des commandes fournisseurs et clients, ds réceptions et des livraisons.......
N'étant pas obligatoire la facturation, car certains décideurs peuvent préférer des outils hautement performant en la matière....

J'oubliais............la numérotation automatique de tous ces petits documents.

A oui, j'oubliais.....on parle..on parle.............mais qu'en pense l'intéressé ?

Bonne soirée

[Marco46]

Question sans rapport avec le sujet mais quel est l'intérêt d'un fichier externe de constantes par rapport à une déclaration de constantes directement dans les sources du projet ?

Alors c'est vrai que ça n'a d'intérêt que lorsque plus d'un développeur travaillent sur le même projet ET utilisent le GDS, j'aurais dû préciser !

Ça permet de rajouter du code utile et fréquent pendant le développement (variables globales, constantes, ...) sans avoir à batailler avec le WDP et le GDS.

Je m'explique :

1 - Le fichier WDP contient en plus du code d'initialisation du projet la liste de tous les éléments du projet.
2 - Le fichier WDP est automatiquement extrait en mode test à l'ouverture du projet sur le GDS.

Pour réellement modifier le WDP il faut fermer le projet, aller dans l'admin du GDS, effectuer une extraction, ré-ouvrir le projet, effectuer la modif. Fermer le projet. Réintégrer manuellement depuis l'administrateur du GDS.

Les problèmes arrivent dès lors que 2 développeurs différents ont rajouté des éléments au projet chacun de leur côté sans avoir effectué une extraction dans l'admin du projet au préalable ce qui est très fréquent. Là il y a l'un des deux qui risque de perdre les éléments qu'il a ajouté, et s'il fait de mauvaises manip à l'ouverture du projet, il peut carrément perdre ses ajouts ! Déjà vécu à de nombreuses reprises. Et c'est encore pire lors du renommage d'éléments comme des fenêtres ou des classes.

Bref, la gestion du WDP étant particulièrement pénible, on a pris l'habitude avec quelques collègues de se faire des fichier EXTERNE au moins pour les constantes que l'on extrait/réintègre manuellement depuis l'admin du GDS et que l'on modifie avec un simple éditeur de texte. Comme ça il suffit juste d'un update + recompilation pour avoir le projet à jour sans toucher au WDP.

Ceci dit, comme parfois on démarre un projet seul et que d'autres dev peuvent être amenés à se rajouter temporairement au projet en cours de route, c'est pas une mauvaise idée de fonctionner comme ça même seul.

Fin de la parenthèse

Ceci doit être considéré comme une variable de la table MOUVEMENTS.

Oui, dont les valeurs possibles sont des constantes, et pas les ID d'enregistrement d'un fichier de type. Ça ne donne pas les mêmes possibilités en terme de codage derrière.

Pour le reste je dis juste qu'il faut faire le distinguo entre la nature du mouvement et son type. Se sont 2 choses différentes. Enfin j'ai conçu une gestion de stock sur ce principe et ça donne vraiment plus de clarté à l'arrivée, comme par exemple pouvoir facilement requêter toutes les entrées dans le stock de date à date (par exemple) sans distinction de type.

[EDM-TAHITI]

Hello à tous,
oui, effectivement, Dom, tu as raison, sujet largement débattu, ressasser, mais ô combien sensible puisque la gestion des stocks est bien le nerf de la guerre, comme je le laissais sous entendre avec les pump, les pre, etc...

A vrai dire, je ne comprends pas l'intervention de Marco46 sur le sujet du GDS (mais j'ai peu dormi en 48h, 5h00 seulement) aussi excusez-moi si je n'ai rien compris.........

Pour le reste, oui, Dom (Raptor92), tu as raison, un tuto serait sympa, je me suis proposé de le faire déjà pour la notion comptable et exportation (j'attends le feu vert d'un modérateur ou plus sur la pertinence du sujet), le fait de faire un tuto sur la gestion de stock va en plus renforcer l'export compta (j'expliquerai cela plus tard car ce serait hors sujet)

En résumé et conclusion, et cela n'engage que moi sur mes propos, je suis assez sidéré de voir que la base même d'une gestion de stocks soulèvent autant d'interrogations, sauf à vouloir faire faire par les autres des tâches si ardues (car elle l'est vraiment, croyez-moi, par expérience personnelle qui m'appartient à moi-même tout seul - rires) de gestion de stocks.
En effet, elle est particulièrement inérante à la constitution de votre base ARTICLES et à la façon dont vous gérez vos pièces de gestion (DEVIS,COMMANDE,LIVRAISON,FACTURES, AVOIRS - et ce pour la partie CLIENTS mais aussi et surtout pour la partie FOURNISSEURS)
Bref, il n'y a pas de recettes miracles, mais des algo que tout le monde connait et qui sont applicables sans soucis, mais les intégrer dans une analyse (qui part en cacahuètes - comprennez mal faite), cela relève de la gageure intellectuelle (prise de tete) , physique (temps passé devant l'écran qui ne répond pas - je parle du cerveau), morale (mise en doute de ses compétences)...
Et c'est l'expérience irremplaçable qui parle, faisant fi du quand-diras-t-on, au risque de passer pour un 'Vieux C..', je suis prêt à aider, mais pour ceux qui se donnent la peine (aie, j'attends une volée de bois vert).

Pour terminer, rien ne sert de faire une gestion de stock si à la base, la gestion des pièces comptables (tient, on y revient), n'est pas gérée.
Pourquoi se casser la tête à vouloir faire une gestion de stocks sans saisie de facture fournisseurs (entrée de stocks) et de saisie de factures clients (ca, je sais, tout le monde le fait, et sait faire - quoique...). J'abordais le sujet épineux (et combien il l'est) du destockage (stock positif, à zero, négatif)
Le destockage, il faut le faire quand on commande (réservation), quand on livre (total ou partielle - gestion des reliquat en fonction des stocks???), sur facturation???? Notion de contrôle sur les réassorts (ouille, ca se complqie vraiment) sur le temps de commande, de livraison, sur les sorties moyennes pondérées du mois, des trois dernier mois, des six derniers mois, de la notion des commandes en fonction des prix d'achats, mais aussi et surtout des prix de revients entrepôt - j'explique succinctement, vous pouvez acheter un articles A chez B à 100,mais chez C, il vaut vaut 110, mais le même article revient pour B à 120 et pour C à 115 (frais, acheminement, taxes, etc..).
Il faut donc acheter à C et non à B (et pourtant, le PA - prix d'achat est plus intéressant chez B que C).
Enfin, cerise sur le gâteau, le veillissement des stocks (eh oui, ca existe aussi en comptabilité, n'en déplaise à certains) qui est partie prenante d'une bonne Gestion Commerciale qui doit être en mesure de donner ces informations lors d'un bilan, mieux encore, un compte de résultat (comprendront les initiés).
Pour conclure, je pourrais vous en écrire des tonnes, mais cela ne ferait qu'alourdir le sujet de fond (j'ai abordé la forme). La gestion des stocks est VRAIMENT UNE GESTION PARTICULIERE QUI DOIT ETRE TRAITEE COMME UN DEVELOPPEMENT A PART ENTIERE
Je proposerai donc, pour la seconde fois, un tuto sur le sujet, et je le ferai avec d'autant plus de plaisir qu'il sera la porte d'entrée à la gestion comptable... Encore faut-il que je recoive l'accord sur le principe (même pas sur le fond) pour que je démarre...
Bref, je suis confronté à cela tous les jours, d'autant que là ou je suis, c'est hyper important de pouvoir calculer lors de la commande un prix d'approche (PCH), avec les codes douaniers français, les droits et taxes, le prix du baril de pétrole, les délais d'acheminement, etc....
Entre le prix d'achat (PA) et le Prix rendu entrepôt (PRE), y'a une méga marge (pour ceux qui veulent gérer au plus juste - à juste raison)
Voilà, je vous laisse méditer à tout cela, mais je suis prêt à vous aider, mais donner vous la peine, au risque de voir votre application remise en cause, et vos compétences aussi..

[Raptor92]

Bonjour à Tous et bonjour Eric,

Je ne vais citer EDM_TAHITI avec qui je suis 100% d'accord.
Par contre,je suis désolé de ne pas être en accord avec Macro46, en effet, un type de mouvement n'a absolument rien à voir avec le type de document.

Le type de document permet de les distinguer les uns aux autres, alors que le type de mouvement permet lui le traçage d'un article.

Et à propos de l'article, là aussi, (et là aussi je suis désolé..), mais je ne suis pas d'accord avec Macro46 sur votre précédente réponse, je pense que si il n'est pas fait de différence entre un produit et un article, cela peut entrainer un mauvais développement:

Je m'explique:

Produit = Ordinateur portable
Modèle = XX
Couleur= Noir

Ces trois paramètres sont en fait l'article ou plus particulièrement ce qu'on appelle une Unité de vente consommateur

Et pour comprendre une fois pour toute qu'une gestion de stock ne peut pas se faire sans être intégrer dans une gestion commerciale, voici un exemple qui je pense devrait convaincre les indécis:

Prenons le cas d'un CD:

Code :

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

1
2
3
Stock théorique     : 10
Quantité vendue    :  7
Stock réel             :  3

Cela peut vous semblez juste...........mais en fait, non.............c'est FAUX.
Non pas que 10-7=3.........quoi que...

Alors pourquoi, vous diriez vous............
Et bien, que faites vous des commandes fournisseurs, des commandes clients, des ventes sur place (et oui, il y a aussi des clients qui ont toujours la mauvaise idée de venir vous acheter un CD sans avoir passé de commande)

Alors reprenons l'exemple de CD:

Code :

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

1
2
3
4
5
6
7
Encours commande fournisseur : 100
Encours de stock                   :  10
Encours commandes clients     :   50
Quantité vendue         :   7
Ventes sur place         :   2
Stock réel                  :   1
Stock théorique          :  51

Arrêtons le temps un instant...Et bien oui, car sinon, une vente suffira pour changer les données:

A cet instant précis, nous avons 10 pièces en stock, nous en avons livrés 7 et vendus 2 au comptoir, le stock disponible réel sera de 1.

Sauf que dans le même temps, nous en avions commandés 100 chez le fournisseur et nous en avons encore 50 en commandes clients.

Donc, les 100 commandés - les 50 en commandes clients = 50 + 1 en stock = 51
...............en pas 3 (comme quoi 10-7 ne fait pas 3...enfin pas tout le temps..)

Et j'oubliais...............dans mon cas, il me faut gérer une dizaine de lieux de stockage, 3 plate forme étrangères et 90 magasins ainsi que des clients et franchises.
Vous livrez un client mais vous transférez de la marchandise à une boutique.
Sachant que certaines boutiques ne possèdent pas la même raison sociale et donc doivent faire l'objet d'une facturation.

Tout ceci pour dire et convaincre, qu'une application de gestion de stock ne se limite pas à une entré et une sortie, mais bien que cela fait partie intégrante d'une gestion commerciale.

Il existe pour autant des application de gestion de flux ne faisant pas partie d'une application de gestion commerciale.
Ceci arrive lorsque vous possédez un ERP ne possédant pas, lui, un système de gestion de stock (et / ou de flux logistique).
Dans ce cas, l'ERP envoi l'ensemble des données à l'application de gestion de stock, et dans ce cas, vous n'aurez pas à gérer la facturation.................. Mais.......parce qu'il y a toujours un mais..........

Vous devrez gérer la gestion des échanges entre votre application et l'ERP

Je trouve cela marrant, car cela empêche de dormir.....

Et plus sérieusement pour conclure, même quant vous aurez terminé et mis en service votre application, vous vous rendrez compte que cela évolue en permanence et qu'il vous faudra vous adapter.

Alors non la gestion de stock n'est pas un + et un -, cela serait manquer de respect à tous ceux comme vmolines, Edm-Tahiti et bien d'autres dont je fais partis qui ont passés des nuits blanche à résoudre leurs problèmes (et qui en passeront encore)

Je suis désolé pour Eric de ne pas avoir de réponse d'un modérateur quant à l'élaboration d'un tutoriel, car je pense que cela serait très intéressant vu tes compétences en comptabilité (J'en sais quelques choses, grâce à toi, mon application d'intégration vers SAGE* fonctionne très bien)
Et j'en profite pour dire que je regrette que Guardian ne soit plus l'un des gardiens du Temple..

Et bien, si avec tout ce que nous avons développer sur le sujet rabis n'arrive pas à trouver la bonne piste......

Très bon samedi à Tous.........et Toutes

PS: Pour Eric...........3h50 du matin....c'est plus du développement, c'est de la rage..

[RougeCitron]

Bonjour à toutes et tous,

Magnifiques démonstrations d'Eric et Dominique.
Et encore, aucun des deux n'a abordé la gestion du premier entré premier sorti.
Je gère des produits pharmaceutiques avec des dates de péremption strictes (poches de sang, vaccins, etc) et je peux vous dire que c'est une galère au quotidien.
En effet, il faut gérer au plus près les emplacements dans les différents lieux de stockage et être sûr que les consignes de prélèvement et de mise en stock sont bien respectées.
De plus, il faut gérer des priorités de sortie en fonction des urgences instantanées.
J'en passe........

Si je peux apporter mes connaissances, ce sera avec un immense plaisir.

Cordialement

RougeCitron
André

[Raptor92]

Bonjour RougeCitron,

Vous avez absolument raison, en anglais "first in-first out", souvent utilisé en effet dans votre cas ou plus général dés lors que l'on parle de denrée périssable, mais dans mon cas (prêt à porter), on se sert de cela afin d'affiner les statistiques entrés / sorties ou pour la gestion des flux logistique.

Une autre utilisation consiste à gérer les emplacements de stockage en fonction des first in - first out.

Je m'explique:

Un article x est entré et stocké à l'adresse y.
Dans le cas ou le même article entre une deuxième fois, il doit être proposé à l'opérateur de le stocker au même endroit ou à défaut, à l'endroit disponible le plus proche.

Et bien voilà....................attendons la réaction de rabis

Bonne après midi

[zouzoukha]

My God

J'ai l'impression que tous mes projets sont à refaire en lisant ce post

Je crois qu'on ne verra pas de si tôt Rabis

[Marco46]

Houla. Loin de moi l'idée de faire une leçon de gestion à des gens qui ont 30 ans d'expérience dans le domaine !

J'expliquais juste succinctement la manière de travailler du client pour lequel j'avais eu à réécrire la gestion de stock pour l'adapter à une gestion de production intégrée à une gestion commerciale. C'est tout. Je crois que c'est une manière de fonctionner simple et réutilisable bien que pas forcément universelle.

Pour l'histoire de la différence produit/article, je comprends la démarche mais dans la gestion commerciale utilisée il n'y a pas ce distinguo. Les couleurs sont distinguées dans la désignation de l'article. Je précise que c'est un choix de gestion du client.

Par contre,je suis désolé de ne pas être en accord avec Macro46, en effet, un type de mouvement n'a absolument rien à voir avec le type de document.

Là je comprends pas.

C'est quoi un type de mouvement ?

C'est quoi un type de document ?

Pour moi il n'y a pas de type de document dans les mouvements. Il y a une nature (entrée ou sortie) et il y a un type (inventaire, BL client, BL fournisseur, etc ...).