Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
On ne modélise pas pour que ce soit "plus facile" mais pour stocker de manière juste et efficace. Sans vouloir entrer dans les détails de l'exemple proposer, il est certain que vos types de documents n'ont pas besoin des mêmes informations et ne doivent donc pas être stockés dans une même table.Envoyé par leonidas34
edit : Enfin, tout ce sujet ne concerne en rien une problématique Windev ...
Normalement la ou les livraisons s'effectuent sur la base d'une commande qui sera transformer en facture je ne sais pas si je me trompe mais je pense que c'est le processus métier correct :
Commande->Livraisons->Facture
Une table/entité livraison qui contiendra un champ stockant l'identifiant de la commande et une autre table/entité ligne_livraison. La liaison, l'association, pourrait être etablie à l'aide d'une autre table entre entre commande et facture afin de recuperer les livraisons liées à une facture. Ca c'est un cas de figure.
Un autre cas de figure qui consite à faire des livraisons sans avoir de commande. Mais je pense que je vais corriger ce que j'ai dis plus haut (puisque c'est à l'instant que je viens trouver) qu'il faudrait une table associative entre commande et livraison (table commande_livraison) et renoncer à ce champ identifiant la commande dans livraison
Là c'est trés clair. C'est ce dont j'avais besoin de comprendre, merci.
Donc la nécéssité d'avoir une table associant commande et facture est indispensable je le suppose.....???
Tout à fait
Cette discussion est une exception à la règle et n'est là que pour clarifier certains points concernant la gestion de stock et la gestion comptable.
WinDev étant essentiellement orienté développement de gestion, cela ne me semble pas inutile
Les associations ne se font pas au moyen d'une table suplémentaire, mais via les relations entre tables (table pris ici au sens fichier et non Table WinDev)Donc la nécéssité d'avoir une table associant commande et facture est indispensable je le suppose.....???
Pour les identifiants :
En ce qui me concerne, tous mes fichiers ont un identifiant automatique géré par WinDev.
Ensuite, je gère "manuellement" un identifiant de "l'objet", client, fournisseur, facture, etc.
Pour ce qui est des fichiers, je rejoins vmolines, leur structure dépend uniquement des informations à conserver. Il faut, à mon sens, éviter la redondance d'informations et la mise en commun d'informations disparates. Pour le reste, on peut toujours sortir l'information sous la forme désirée quelle que soit la structure de la base
Bonjour tous !
Euh... oui et non je m'élève contre ce propos dans la mesure ou tous ces à cotés, aussi indispensables qu'ils puissent être, peuvent être gérés par d'autres applications avec lesquelles il faudra prévoir des interfaces.
Pour moi, une gestion de stock n'est qu'une gestion de stock. la manière dont ça doit s'imbriquer avec la comptabilité ou l'administration des ventes peut être une politique d'entreprise.
Cordialement
Hello,
Nous revoilà parti dans la gestion des stocks, libellé du sujet initial.
Guardian, que je salue, ainsi que Mogwai162 et tous les autres, précise que ce sujet n'est pas directement lié à l'utilisation de Windev, mais bien de ses possibilités. Et WD peut le faire, yes, it can do it...
Windev est à mon sens l'un des outils les plus performants en matière de gestion et de développement (rapidité temps-Hommes).
Mais, car il y a un mais, il n'apprend pas aux débutants à programmer, comme tous les langages. Cela s'apprend avec le temps, des tests, des exemples, de la patience, et une once d'oppiniatreté.
A partir du moment ou on commence a parler gestion de stocks, il faut avoir à l'esprit que cela ne se réalise pas en claquant des doigts.
Zouzoukha, suite à différents posts, disait avec humour qu'en voyant nos échanges, elle devrait certainement revoir ses notions de stocks (rires).
C'est un peu vrai. Une bonne gestion de stocks implique une excellente gestion des pieces (devis, Commande, Bon de livraison, Facture, Avoir)
Ce cheminement se fait tout ou partiellement dans cet ordre, quoique...
Raptor92 (dom) a déja démontré, par des exemples simples, et son expérience, que cela pouvait très vite devenir un plat de spaghettis.
J'y rajoute que désormais, on s'oriente de plus en plus vers des postes nomades (portable, gsm, tablette) qui vont devoir gérer des bases déconnectées, et ce de plus en plus souvent.
Et c'est là la force de WD, il propose des sytemes de gestion, déjà en natif, mais qu'il faut améliorer, de réplication, de suivi, etc...
Mais revenons au sujet: il ne faut pas confondre Gestion de stocks et gestion de pieces comptables, même si effectivement, une imbriquation est réalisée.
L'expérience que j'ai, en la matière, m'amènne à vous dire que la plupart du temps, la Gescom est réalisée pour des contraintes métiers, mais que dans 99.99% des cas, la compta est un logiciel grand public.
Et dès le départ, il faut penser à une multitude de choses, au risque, comme je l'écrivais déjà il y a quelque temps, de se retrouver la tête dans le mur, car l'analyse de départ ne peut plus évoluer sans en remettre en cause une bonne partie.
Pour terminer, il existe, et c'est heureux, plusieurs types de gestion de pieces, mais qui ne visent qu'à la gestion des stocks. Après, on en fait ce que l'on veut. Mais il faut à mon sens pouvoir suivre les données client entre l'intention (devis) et la concrétisation (facture).
Et ce n'est pas tout
Salut à tous !!
En effet, il faudrait peut-être revoir la définition de la gestion des stocks.
Dans aucun des posts il n'a été question de la dépréciation de ces stocks et de la volatilité.
Un exemple : un boulanger commande X quintaux de farine pour fabriquer son pain. Il sait que pour fabriquer Y baguettes il a besoin de Q quintaux de cette farine.
Jusque là, pas de problème. Sauf que dans ses calculs il n'a pas tenu compte de la farine qu'il utilise pour les manipulations dues à la fabrication.
Au bout d'un certain temps, il lui manque de la farine !!!
Même chose dans la restauration. Une salade doit donner tant de plats, mais jamais on ne peut y parvenir.
Et j'ai d'autres exemples à la pelle (tient, justement, dans la construction, le cubage de béton n'est jamais exact).
Et dans ces cas, pas de document comptable ou autre.
Juste éventuellement un inventaire permanent et tournant pour connaître la réalité des choses.
Cordialement
Hello,
j'y rajouterai, dans la dépréciation des stocks et leur valorisation, le fait qu'il est admis qu'une valeur de stocks vieillisse elle aussi, dans le temps (valorisation), ce qui permet en autre, avec un stock vieillissant, de ne pas porter la valeur initiale dans le compte de résultat, mais bien sa valeur à l'instant ou il est valorisé (suis-je clair???).
Mais cela ne peut se faire qu'avec une excellente gestion de stocks et une tracabilité des entrées sorties (et là, toutes les pieces sont en jeu, partie clients et parties fournisseurs).
la remarque judicieuse de RougeCitron aborde le sujet entre la théorie et la pratique. En effet, comme pour les primeurs, ils achetent 30 kilos de pommes, mais après quelques jours, l'eau s'étant évaporée, ils pésent moins lourds. Si je prends cet exemple, c'est que suite à un controle fiscal, il a fallut que le primeur démontre à son inspecteur (qui était une inspectrice) qu'il ne faisait pas du 'black' mais que c'etait la dépréciation physique de son produit qui faisait des écarts entre théorie et pratique.
Et là, dans ce cas, sauf à connaitre un algo qui prenne en compte la chaleur, le taux d'humidité, et je ne sais quoi encore, il n'y a pas de solution miracle.
En résumé, seuls les inventaires tournant et programmés peuvent donner la photo instantanée des stocks (et je ne parle pas de la démarque inconnue, hein! - vol pour les non initiés).
Je suis assez d'accord pour éviter les redondances. Toutefois, dans le cadre d'une facture, il est important de mémoriser beaucoup de choses, car un logiciel de gestion doit être capable de ressortir à l'identique une facture pendant 10 ans !Pour ce qui est des fichiers, je rejoins vmolines, leur structure dépend uniquement des informations à conserver. Il faut, à mon sens, éviter la redondance d'informations et la mise en commun d'informations disparates. Pour le reste, on peut toujours sortir l'information sous la forme désirée quelle que soit la structure de la base
Donc les notions de désignations, prix, remises, taux de tva, ... j'en passe et des meilleures doivent être «redondées» dans ce cas précis !
Bonjour,
Effectivement et ca devient un casse-tête pour ceux qui sont habitués de ne mettre que les identifiants de l'article dans les tables lignes par souci d'optimisation car une désignation peut-être sujette ne serait-ce qu'a une légère modification.
Donc, ressortir à l'identique........ ca devient un dileme
Bonsoir,
Sur le principe, Mogway n'a pas tord, pour autant, dans la mesure ou la gestion des articles est inexistante, cela implique qu'il ne puisse y avoir certains contrôles.
Un exemple:
Dans notre cas, nous possédons plusieurs marques au sein d'un même groupe.
L'une des méthodes de contrôle mise à notre disposition consiste à vérifier que l'article scanné appartient bien à la société autorisée.
Cette information figure dans la fiche du produit.
Si je comprends bien Mogway, cela ne serait il pas pénalisant de pouvoir scanner un produit et de procéder ainsi à son entrée en stock sans contrôler son appartenance, ou à sa simple existante au sein de la base articles ?
Je comprends tout à fait, et je tente tous les jours de l'appliquer, qu'il faille simplifier et d'aller à l'essentiel du pourquoi de la demande qui nous est faite, mais est ce applicable dans le cas présent ?
Quoi qu'il en soit, le sujet est d'autant plus passionnant, qu'il m'intéresse de m'améliorer sans cesse sur ce sujet
Bonne soirée et excellent week end à Toutes et Tous
Tout dépend de la manière d'éditer les documents.
Par exemple, sous WD15, il est possible de gérer des duplicatas.
Ainsi, tous les renseignements y sont consignés et valides pour toute recherche ultérieure.
C'est une méthode que j'utilise depuis que je développe. Et quel que soit la méthode utilisée. J'ai toujours eu un fichier duplicata (factures, BL, avoirs, etc....)
Cordialement
Re...
Autant j'ai des doutes quant au fait de ne pas gérer les articles au sein d'une gestion de stocks, autant je pense que parler de facturation au sein d'un développement de gestion de stock est une erreur
Les deux parties ne sont pas liées car la gestion de stocks d'une entreprise ne passe pas forcément par de la facturation.
Et la livraison d'un article de stock à un client ne fait pas forcément partie de la gestion de stock mais plutôt de la gestion commerciale.
Bonne soirée
Voici un début de définition de ce qu'est un stock :
Définition des stocks
Il s’agit des biens ou services entrant dans le cycle d’exploitation de l’entreprise pour être vendus en l’état ou après production ou transformation, ou être consommés à la première utilisation.
Ils doivent appartenir à l’entreprise, et celle-ci doit en être propriétaire au moment de l’inventaire, ce qui signifie en particulier que doivent être compris dans les stocks les produits en cours d’acheminement ou reçus, mais dont la facture n’a pas encore été comptabilisée, et à l’inverse doivent être exclus les produits qui ont été livrés aux clients mais non encore facturés.
La notion de facture est en effet un peu réductrice. Il faudrait, peut-être, parler de documents de mouvements de stocks.
Et encore....
Car, par exemple, un agriculteur qui moissonne son champ de blé n'établit pas un document pour savoir la quantité engrangée. Et pourtant, son stock s'est augmenté de la quantité récoltée !!!
Cordialement
Bonjour.
Afin d'éclaircir encore un peu plus ma pensée, j'ajouterai les choses suivantes :
Sauf dans le cas ou nous travaillons dans une société de services qui se doit de vendre un produit complet, notre devoir en tant que développeur est de bâtir une application qui correspond au mieux au besoin des utilisateurs de nos produits. Ce qui implique donc de faire tout ce qui nous est demandé mais aussi rien que ce qui nous est demandé.
Par exemple, dans notre entreprise il existe peut être un logiciel qui gère déjà très bien les les expéditions et/ou la facturation et qui n'est pas inclus dans le logiciel de gestion de stock. Cela peut impliquer de vouloir conserver cette partie lors de la réécriture du logiciel de stock.
Il est alors a notre charge de gérer les interfaces au mieux entre ces deux systèmes et de le prévoir dès l'analyse bien sûr. De ce fait ces interfaces peuvent et doivent inclure tout ce qui est nécessaire non seulement à la bonne gestion du stock mais aussi à la bonne gestion de l'expédition ou de la facturation. Il peut être alors nécessaire de gérer les produits dans les deux systèmes ET de gérer une interface qui va transférer des données du produit d'un système vers l'autre. Nos interfaces se doivent tout comme notre logiciel être le plus complet possible.
Exemple : Dans une société, un service achats avec son logiciel de gestion de matières mais deux ateliers qui vont fabriquer des choses sans rapport entres elles, c'est à dire avec des matières premières différentes. Le système 'achat' est verrouillé, impossible de lui faire dire quelle matière va dans quel atelier. les stocks sont gérés dans le système achat' Donc dans chaque atelier, il a fallu créer manuellement les matières mais il existe une interface qui permet lors de chaque transfert du stock transférer le stock des matières crées dans l'atelier et de modifier le libellé et d'autres informations du produit de manière à s'assurer que les deux systèmes aient les mêmes informations à chaque instant.
En conclusion j'ajouterai ceci :
Chaque situation est différente et c'est bien pour cela qu'il faut établir un cahier des charges complet.
Il doit être bien différent de travailler dans une société de services que dans une entreprise finale et ceci pour d'autres raisons non développées ici encore.
A chaque fois que l'on parle de facturation ou de valorisation de stock par exemple et ceci même si ces deux éléments sont indispensables, on s'éloigne du sujet qui est la gestion de stock.
Cordialement
Bonjour à Toutes et Tous,
Je suis d'accord avec ce que dit Mogway, et j'ajouterais ceci, dans notre société, nous possédons un CRM gérant nos boutiques (96),nos 30 corners, nos franchises, clients multimarques ainsi que nos magasins d'usine.
L'ensemble de la facturation s'effectue par le biais logique de ce progiciel.
En parallèle à celui ci, nous avons développé une application de gestion de flux logistique (d'où mon précédent message quant à la relation des articles avec la gestion de stock).
Les deux systèmes communiquent entre eux par le biais de batch.
Tous ceci pour dire que le lien entre la gestion de stock et la facturation n'est absolument pas une obligation et ne peut faire partie d'une norme quelconque, comme le dit Mogway, ceci dépend bien des besoins de l'entreprise.
Si le rôle d'un développeur est d'interpréter au plus juste le besoin qui lui est fait, il n'en ressort pas moins que l'une des obligations que nous avons est d'optimiser les outils déjà en place.
Dans un mode idéal, un ERP incluant toutes les fonctionnalités serait LA solution, pour autant, l'entreprise d'aujourd'hui nous demande d'aider au pilotage du progiciel en place.
J'ajouterais que dans notre cas, il est vraisemblable que nous soyons amenés à changer de système de gestion d'ici deux ans car, notre éditeur actuel a été racheté récemment et le nouveau vient de nous informer de sa décision d'en arrêter la maintenance.
Pour autant, un ERP idéal gérant la compta, la partie Retail, la logistique, les achats et la fabrication nous couterait entre 1.2 et 1.5 M€, ce qui est impensable, ceci implique donc que nous allons acquérir le noyau principal qui sera la partie Retail, les achats et la fabrication, et nous allons nous débrouiller avec la compta et la logistique.
Donc, là encore, la partie facturation n'a rien à voir avec la gestion de stock.
Beaucoup de mots peut être, mais nécessaire à expliquer la raison de la contradiction.
Bien entendu, et comme toujours, que nul ne se froisse de nos avis, car, ces échanges sont fait que pour nous permettre d'élargir notre horizon.
Très bonne journée
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager