Discussion :

[Salsaboy60]

Bonjour, je suis en train de creer au boulot une bdd gestion de stock. J'ai creer déjà pas mal de tables, j'ai déjà creer mes documents commande fournisseur et factures etc.
Mais la base reste quand même le calcul du stock par article/emplacement. Suivant les exemples sur internet, j'ai creer une table Marchandise (n°IdProduit, numéro d'article, description, n°fournisseur, prix d'achat, prix de vente, idfamille, idsous-famille, code barre, units in stock(non utilise), units in order(non utiliser) et re-orderlevel(non-utiliser), une table ArticleEmplacement(N°Id, N°IdProduit, Emplacement et Quantité), une table Commande/Detail commande, une table Facture/Detail Facture et j'ai prévu une table Detail Stock.
Par quelle moyen va t-on maintenant calculer son stock. Stock initial, plus Commandes, moins Factures. Mais le niveau de stock ce garde ou dans la bdd, comment le calculer et comment le stocker??
C'est peut-être basic comme question, mais j'aimerais bien quelques indications dans quelle directions je dois me tourner pour essayer de réaliser ce projet. Une coup de pousse pour me mettre en route. Merci d'avance pour votre precieuse aide.

[Invité]

Bonjour et bienvenue sur le forum Office de DVP.

A mon avis, dans ton schéma il te manque une table Mouvement qui permettra de stocker les entrées et sorties.

A partir d'une requête tu pourras déterminer le stock.

Philippe

[Siguillaume]

Bonjour et bienvenue
Je rejoins aussi Phillipe pour l'ajout d'une nouvelle table.
Mais j'ai une question et une suggestion.

Question: que comporteras ta table Detail Stock?
Suggestion: envoies aussi ton MCD (image), pour qu'on puisse mieux te suivre

Merci

[Salsaboy60]

Bonjour a vous Philippe et Danjos,

Je ne sais pas qu'est ce que c'est le MCD, mais j'ai attacher un pdf avec l'image de mes tables et leurs relations.
j'ai créer les tables Stock et Détail Stock, mais il ne sont pas encore utilisé. J'ai trouvé quelque part sur internet une schéma qu'il l'ajoutait, alors je les ai creer en cas ou.
Donc : Stock : Ligne de stock (clefs primaire) Ref interne, Qte entree, Qte sortie, Qte retour et Date de modification
Detail Stock Ligne de stock + N°IdProduit (ensemble clef primaire), Prix d'achat UHT, date entree, date sortie, retour, date modification.

Si je comprends bien votre raisonnement, le stock n'est pas un chiffre dur, encodé quelque part dans un table, mais un chiffre calculé à chaque fois via une requête.

Mais comment est ce que je stock les données de quantité issu des tables DetailCommande et FactureClientDetail dans une table DetailStock pe. Aussi via une requête?
Et comment est-ce que je tiens compte de mes emplacements?
Bien à vous pour une réponse. Parfois les solutions sont simple mais on ne les vois pas.

[Siguillaume]

Je ne sais pas qu'est ce que c'est le MCD, mais j'ai attacher un pdf avec l'image de mes tables et leurs relations.

Oui c'est bien de cela qu'il s'agit

j'ai créer les tables Stock et Détail Stock, mais il ne sont pas encore utilisé. J'ai trouvé quelque part sur internet une schéma qu'il l'ajoutait, alors je les ai creer en cas ou.
Donc : Stock : Ligne de stock (clefs primaire) Ref interne, Qte entree, Qte sortie, Qte retour et Date de modification
Detail Stock Ligne de stock + N°IdProduit (ensemble clef primaire), Prix d'achat UHT, date entree, date sortie, retour, date modification.

Là je ne te comprends pas du tout.
Quelle est la différence fondamentale entre ces deux tables?

Et même, à quoi servent ces tables? A enregistrer les stocks? Alors pourquoi "calculer" le stock, et à quoi servirait l'application?

Si je comprends bien votre raisonnement, le stock n'est pas un chiffre dur, encodé quelque part dans un table, mais un chiffre calculé à chaque fois via une requête.

En suivant le raisonnement de Phillipe, on te demande simplement d'avoir une table où te va enregistrer les différentes entrées et sorties.
Vu que le stock=total des entrées-total des sorties, tu pourras gérer cela facilement dans une requête.

Bon courage!

[Salsaboy60]

D'accord.

En etudiant la question, je pense que la table Stock peut disparaître. J'utiliserai donc la table DetailStock pour stocker mes informations rélatifs au entree et sortie. Je l'ai déjà amélioré dans ce sens. Je vois maintenant les contours de ce qu'il me reste à faire.

Pour repondre à ta question à quoi servira l'application, ça doit devenir une systeme de gestion de stock d'un entrepôt de matériel des machines de jeu (par emplacement) avec création des commandes, factures client, sortie pour l'atelier pour des réparation et eventuellement une gestion des pièces en consignation chez des clients.

Dernière précision svp. Je travail donc avec des formulaires (commande, bon de retour, factures etc). Les quantitées et dates sont par conséquent stocker dans les tables liés. Ce qu'il me reste à faire donc c'est de creer des requêtes ajout que j'appele au moment de quiter le document par exemple via une procédure événementielle. Est-ce que c'est comme ça que ça fonctionne?? Merci de ta reponse.

Hans

[Siguillaume]

A priori, je vois que tu avances sur la conception, c'est bien.

Je travail donc avec des formulaires (commande, bon de retour, factures etc). Les quantitées et dates sont par conséquent stocker dans les tables liés. Ce qu'il me reste à faire donc c'est de creer des requêtes ajout que j'appele au moment de quiter le document par exemple via une procédure événementielle. Est-ce que c'est comme ça que ça fonctionne??

Là je comprends pas encore ce que tu veux faire
Qu'est ce que tu désignes par tables liées? Donnes-en un exemple sur ton MCD.

S'il s'agit des tables intermédiaires entre deux tables entités, je ne crois pas que passer par une requête ajout est la meilleure solution, bien que cela soit possible.
Fais plutot d'autres formulaires, où tu pourras utiliser des listes déroulantes qui auront pour source, les tables entités.

Bon courage à toi

[Salsaboy60]

Merci pour tes reponses.

Ce que je veux dire (excuse moi que mon languages n'est pas tjs approprié) par tables lie, c'est que j'ouvre une frmCommande/sousfrmDetailCommande, ou l'utilisateur saissie les donner rélatif à une Commande fournisseur. Ensuite ces données sont stocker dans les tables Commande et Detail Commandes, idem pour FactureClient et DetailFactureClient.

Donc mon problème ce trouve maintenant dans le processus pour extraire ces données de ces tables et les stocker dans une table Stock.

Ou est-ce que je me complique tout bêtement la vie??

Hans

[pier.antoine]

Si je comprends bien les relatiosn entre les tables, on a :

- une partie commande qui sert à renouveleler le stock, à acheter les marchandises pour les avoir en stock.
- une partie facture qui concerne les marchandises vendues aux clients.

Est-ce si pertinent de séparer les deux? Dans le fond ces deux opérations sont équivalentes à la direction près.
Je pense qu'une seule table "Commande" devrait suffire, , en relation avec une table client-fournisseur, dans laquelle le mouvement peut-être négatif (vente de marchandise à un client) ou positif (achat de marchandise à un fournisseur).
Ensuite, en fonction de la direction (achat ou vente) j'édite soit un bon de commande, soit une facture.

Cette table peut tout à fait faire office de table "Mouvement de stock". Mais je préférerais passer par un intermédiaire pour avoir une vision réelle du stock. En effet, en particulier pour les commandes, il y a un temps entre la demande et la réalsiation. Je commande une marchandise, je sais que je vais l'avoir, mais je ne l'ai pas encore, donc mon stock va bientôt augmenter, mais ce n'est pas fait. Donc gérer ce décalage.

Pierre

[Siguillaume]

Si je comprends bien les relatiosn entre les tables, on a :

- une partie commande qui sert à renouveleler le stock, à acheter les marchandises pour les avoir en stock.
- une partie facture qui concerne les marchandises vendues aux clients.

Est-ce si pertinent de séparer les deux? Dans le fond ces deux opérations sont équivalentes à la direction près.
Je pense qu'une seule table "Commande" devrait suffire, , en relation avec une table client-fournisseur, dans laquelle le mouvement peut-être négatif (vente de marchandise à un client) ou positif (achat de marchandise à un fournisseur).
Ensuite, en fonction de la direction (achat ou vente) j'édite soit un bon de commande, soit une facture.

Cette table peut tout à fait faire office de table "Mouvement de stock". Mais je préférerais passer par un intermédiaire pour avoir une vision réelle du stock. En effet, en particulier pour les commandes, il y a un temps entre la demande et la réalsiation. Je commande une marchandise, je sais que je vais l'avoir, mais je ne l'ai pas encore, donc mon stock va bientôt augmenter, mais ce n'est pas fait. Donc gérer ce décalage.

Exact
Mais je crois que c'est ce que nous essayons d'expliquer depuis le début

[Salsaboy60]

Merci beaucoup,

tes réflexions vont bien m'aider. Je vais essayer de créer la bdd dans ce sens la. A la différence prêt que il me faut bien deux table pour les fournisseur et les clients, car chez nous dans l'entreprise, ils peuvent exister une client et un fournisseur avec le même numéro. Mais ça c'est un détail par rapport au reste.
Encore merci.

Hans

[pier.antoine]

Pour moi, pas la peine de faire 2 table différentes.

Il suffit de créer, dans la table "Client-fournisseur", un champ ID (unique qui servira à identifier l'élément "client-fournisseur"), un champ numéro qui permet de stocker le numéro client ou le numéro fournisseur, et qu'importe si deux enregistrements ont le même numéro, puisque on ne s'en servira que pour faire de l'affichage; éventuellement un autre champ "Type"(??) pour indiquer si c'est un client ou un founrisseur.

Je pense que c'est plus rationnel de ne faire qu'une table pour des données sommes toutes identiques. En plus cela permet de rechercher dans cette table, sans être obligé de savoir d'abord si c'est un client ou un fournisseur.

Pierre

[Salsaboy60]

Ok, merci

Je vais re-penser l'organisation de mes tables.

Hans