Discussion :

[adama13]

Bonsoir à tous et à toutes!

C'est toujours un plaisir pour moi d'ouvrir une nouvelle discussion sur ce Forum pour exposé mon problème

Je gère un Magasin de vente de sucrerie, de biscuit et d'Eau. En vu des récentes pertes de somme d'argent dans mon Magasin, dû surement aux erreurs de calcule, j'ai décidé de me tourner vers Access pour la création d'une base de donnée capable de m'aidé à faire la gestion de mon magasin. Vu que je suis Débutant en Access et je continu toujours d'apprendre les cours la suit, je ne sais pas par ou commencer, combien de table dois je créer?, quelle type de requête dois je créer?, quelle est la relation que je dois utilisé? Au temps de question que je me pose sans réponse

Voici comment cette base de donnée doit fonctionner:

***** Je suis dans une ville donnée "Odienné" et les produits me parviennent d'une autre ville "Man" donc j'aimerais que dans cette base de donnée je puisse avoir une fonctionnalité qui me permettrait de saisir tout ce qui vient de cette ville "Man".
***** Ensuite puisque le magasin est ouvert tout les jours de la semaine(même le Dimanche, jour férié, jour de fête) de 07H30 minutes a 18h45 minutes donc ce qui veut dire qu'il me faut une autre fonctionnalité qui va me permettre de saisir tout ce que je vend par jour(quotidiennement)
***** Enfin j'aurais besoin d'une dernière fonctionnalité qui va me permettre de savoir ce qui me reste en vente dans le Magasin. A partir de cette info je pourrais passé une commande.

Voici les différents Produit que je vend:

PEPSI COOL
PEPSI COOL EVERVESS
PEPSI COOL SEVEN UP
PEPSI COOL MIRINDA
TAMPICO 24
TAMPICO 12
TAMPICO 6
MIRINDA 1.5 LITRES
MIRINDA 0.5 LITRES
TONIC JAUNE 12
Eau celestre
Eau Water
Biskrem
Biscuit Tempo
Nectar de Mangue
Ivorio jus d'ananas
Ivorio jus de Mangue
Ivorio jus de Tamarin

NB: Il peut y avoir d'autres Produit à ajouter encore(des fois, la société me livre de nouveau produit)
Donc voila, j'ai besoin de votre aide pour la création de cette base de donnée.
Merci d'avoir pris la peine de lire le sujet jusqu'ici

En attente d'une suite favorable, recevez chère membre de ce Forum unique en sont genre(qui a été le seul à m'aidé beaucoup à améliorer mon niveau en Access) mes salutations les plus distinguées.

[Didier L]

Bonsoir,

Vaste projet

Pour faire simple dans un premier temps il peut suffire de deux tables.
Une table "Produits" avec un identifiant, la désignation et la quantité en stock.
Une seconde table "Mouvements" avec la date du mouvement, la référence (identifiant) du produit concerné, le sens du mouvement (avec un flag) afin de savoir si c'est une entrée ou une sortie et enfin l'origine (ou ville).
Ensuite soit a chaque saisi d'une ligne de mouvement on met à jour le stock (selon le sens, entrée ou sortie) dans la table produits et on a toujours le stock réel, soit on saisi dans cette table le stock initial et ensuite on fais une requête afin de recalculer le stock réel en fonction de tous les mouvements.

Ensuite, il faut faire les formulaires, le code et tout et tout

Bon courage

[adama13]

Merci a vous Didier de porter un interet a mon sujet.
J'arrive pas a comprendre ce que veux dire Flag.

[Didier L]

Bonsoir,

Un flag c'est un champs oui/non.
Par exemple si j’appelle ce champ "vente", quand il est coché (oui) alors c'est une vente et dans le cas contraire c'est une rentré en stock

[adama13]

Bonjour Monsieur Didier.

Comme je suis debutant en Access vous pourez me donner un coup de pouce en m'aidant a creer les requetes.

[Didier L]

Bonjour,

Aucun souci
Mais il faut avant, créer vos tables et ensuite poser vos questions par rapport aux requête que vous voulez créer afin de savoir quelles sont les difficulté que vous rencontrer.
On ne peut pas tout mettre dans le même sujet.
Chaque post ou sujet doit concerner un thème, une question ou problème.

Alors si vos tables sont créés, poser dans un autre post une question clair et simple et vous verrez que la communauté vous repondra et vous aidera.

[adama13]

Merci Monsieur,
j'en prend note.
je vais essayer de creer les 2 tables et relation si cela est fait aors je posterais un autre post pour les requetes.

[adama13]

Bonsoir Monsieur Didier,

Vous allez surement dire qu’il m’a fallut plusieurs jours pour créer simplement les tables et rélation de la Base de donnée de gestion de Vente et de Stock. Même si je suis novice en Access je suis quand même des cours de certain même de ce forum comme Claude Leloup, Jimbolion pour ne ce citez que cela. En fait il y’a eu une panne du réseau internet dans ma région(c’est aussi sa l’Afrique). Brèf J’ai réussit à créer les deux tables. Voici une illustration :




La rélation existante entre ces deux tables :




Une troisième table :


J'ai créer une troisième table parce que lors de l'encodage des donnés dans tMouvement j'ai constaté que dans le champ designation je devrais saisir les noms des differents produits or il y a plus de 30 produits donc vous voyez que cela me mettra en retard

Voici un exemple d'encodage de donnée:




J'ai une question à vous posez:
Es ce qu'avec seulement ces deux tables j'arriverais a saisir
---les entrés(les produits qui me parviennent de la ville de Man),
---les sorties(les produits que je vend quotidiennement) et savoir le nombre de produit qui me reste en vente?
(pour moi il aurait fallut 4 tables)


Merci d'avence!

[Didier L]

Bonsoir,

Votre approche est différente de ce que j'avais pensé mais tout aussi juste.
Et dans ce cas vous avez effectivement besoin de ces 3 tables.
Vous gérer des mouvements pour une date et dans ces mouvements vous avez des lignes de détail de produits concernés.
Pour une meilleur compréhension, renommé votre table tProduit en tDetailMouvement par exemple.
Ensuit dans cette table au lieu récupérer la désignation du produit, récupérez plutôt son identifiant et faite aussi une relation entre la table tNomProduit (que vous pouvez appeler simplement tProduit) et tDetailMouvement en créant le champ tptoduitfk.
Rajouter dans cette table tNomProduit ou tProduit selon comment vous l’appellerez la quantité initiale (celle que vous avez actuellement en stock.
Ou alors vous saisissez un mouvement (entrée) avec le stock actuel.
Pour le champ Oui/non vente, s'il est coché c'est que c'est bien une vente (sortie quotidienne) et dans le cas contraire une rentrée (provenant de la ville de Man)
Ainsi vous pourrez faire la somme des quantités entrées moins la sommes des quantités vendues et cela vous donnera ce qui vous reste en stock à tout moment.

[adama13]

Bonsoir Monsieur Didier

Merci de m'avoir repondu. Je vais essayer sa de suite meme.

[adama13]

Bonsoir Monsieur Didier,

J'ai pas bien saisit votre message:

Vous dite:

Pour une meilleur compréhension, renommé votre table tProduit en tDetailMouvement par exemple

Oui j'ai déjà fait sa.

Ensuite dans cette table au lieu de récupérer la désignation du produit, récupérez plutôt son identifiant et faite aussi une relation entre la table tNomProduit (que vous pouvez appeler simplement tProduit) et tDetailMouvement en créant le champ tptoduitfk.

Donc de supprimer le Champ Designation?

Rajouter dans cette table tNomProduit ou tProduit selon comment vous l’appellerez la quantité initiale (celle que vous avez actuellement en stock.
Ou alors vous saisissez un mouvement (entrée) avec le stock actuel.

Donc le Champ Quantite qui se trouvais dans tProduit au depart de le supprimer pour l'envoyer dans tProduit(autre fois tNomProduit)?

J'ai un peut la tête Dur, je le reconnait

Merci de d'Avance

[Didier L]

Bonsoir,

Je n'était peut-être pas très clair.
J'aurais comme vous trois tables qui se nommeraient :
tMouvement, tProduit et tDetailMouvement

tMouvement est bonne.

Dans tProduit j'aurais les champs : idProduit, NomDuProduit, QuantiteStock (pas obligatoire)

Dans tDetailMouvement j'aurais les champs : idDetail, tMouvementfk,tProduitFk, Quantite

En fait la table tDetailMouvement est la table qui permet de mettre en relation les table tProduit et tMouvement.
Car un mouvement peut concerner plusieurs produits et un produit peut être livré ou vendu dans plusieurs mouvements.
Et a chaque fois ce qui est important c'est de pouvoir saisir la quantité reçue ou vendu pour un produit lors de ce mouvement.
Ensuite la QuantiteStock ,n'est la que pour saisir un état initial, mais peut être compensé en saisissant un mouvement de livraison pour le stock actuel comme si on venait d'être livré pour la première fois.

C'est peut-être plus clair ainsi

[adama13]

Bonsoir Monsieur Didier,

Pour l'éclaircissement.

J'ai exactement fait pareil comme vous.

Voici l'illustration



Voici la relation:



Es ce que je fais juste.
NB: J'ai coché l'intégrité référentiel, la mise a jour en cascade et la suppression en cascade des deux relation.


Pour tout.

[Didier L]

Bonsoir,

Super nous avançons bien

La structure de la base est juste.
Maintenant juste une ou deux petites précisions.
Les "ID" des tables tMouvement et tProduit sont des NuméroAuto.
Donc il ne pourrons jamais changer une fois attribué donc il n'est pas utile de cocher dans les relation "mise à jour en cascade"
L'intégrité référentiel de la relation interdit de saisir un détail de mouvement pour un produit qui n'existerai pas.
Donc si nous avions une relation avec un champ de type texte (comme une référence produit) et que cette référence dans le temps venait à être changé, alors si on avait pas coché "mise à jour en cascade" nous ne pourrions pas modifié notre référence.
Il faudrait créer un nouveau produit avec la nouvelle référence et éventuellement modifier par traitement tous les enregistrement de la table tDetailMouvement avant de pouvoir supprimer l'ancien produit. Ce qui pourrait être lourd. voila pourquoi le system permet dans certain cas de mettre à jour en cascade. Mais ce n'est pas notre cas dans la base actuelle.

Ensuite l'intégrité référentiel, interdit aussi la suppression d'un élément qui risquerai de laisser des "orphelins". Autrement dit, je n'ai pas le droit de supprimer un produit que j'ai déjà reçu ou vendu (qui apparaît dans la table tDetailMouvement). C'est une sécurité pour justement garantir l'intégrité des informations.
Cependant parfois on pourrais désiré que si je détruit un mouvement complet, je veux que le system détruise du même coup toutes les lignes qui s'y rattachait.
Dans ce cas l'option de la relation "Suppression en cascade" est intéressante car le simple fait de supprimer une ligne dans la table tMouvement, supprima toutes les lignes de détail du mouvement.

Donc pour ma part, je la cocherai pour la relation entre tMouvement et tDetailMouvement, mais je ne la cocherai pas entre tProduit et tDetailMouvement, ainsi c'est une sécurité qui m’empêchera de supprimer par mégarde une fiche produit avec lequel j'ai déjà travaillé

Maintenant pour que notre structure soit parfaite et que dans l'avenir même si nous avons beaucoup de données, pour que la base siot bien optimisé, il faut au minimum indexé les champs de liaison.
Les clé primaire sont indexé sans doublon par définition. Mais les clés secondaires (ou foreign key) ne le sont pas systématiquement. Ors nous les sollicitons beaucoup de par les relations. Il faut donc que ces champs tMouvementfk et tProduitfk soient indexé avec doublon.

Voila la structure est complète et bonne.
Il ne vous reste plus qu'a créer des formulaire de saisi (je vous conseil de regarder les tutos et éventuellement ensuite de poster vos questions sur d'autres posts), créer des requêtes pour interroger votre base et éventuellement faire des états pour présenter ces résultats. Ensuite viendra le temps des macros ou du code VBA pour enchainer et automatiser le tout

Ensuite, il sera toujours temps d'enrichir vos tables pour gérer d'autres informations, comme par exemple un prix d'achat et un prix de vente pour vos produit. Cela vous permettra aussi de dégager une marge par produit et une marge sur une période
Pour ces questions, vous pourrez revenir sur ce forum de modélisation si besoin.
Car dans mon exemple de prix, si cela semble évident de mettre les champs dans la table tProduit, cela ne suffit pas.
En effet dans le temps ces prix peuvent évoluer a la baisse ou a la hausse. Donc nous n'avons qu'un seul prix qui est l'actuel (Achat ou vente).
Il est donc nécéssaire de le stocker aussi lors de la transaction que ce soit de l'achat (livraison) ou de la vente.
Il faudrat donc nécessairement créer un champ prix dans la table tDetailMouvement avant de le conserver au moment du mouvement.
On pourra ainsi facilement connaitre le Chiffre d'affaire pour une période donnée.

Juste pour vous dire qu'il faut se poser beaucoup de question et ne pas hésiter a refaire valider un schéma en expliquant ce que l'on veut faire.

Bon courage

[adama13]

Bonsoir Monsieur Didier, Merci de m'avoir répondu

J'ai fait comme vous me l'avez demandez

Ensuite, il sera toujours temps d'enrichir vos tables pour gérer d'autres informations, comme par exemple un prix d'achat et un prix de vente pour vos produit. Cela vous permettra aussi de dégager une marge par produit et une marge sur une période
Pour ces questions, vous pourrez revenir sur ce forum de modélisation si besoin.

Donc si j'ai bien compris, je dois ouvrir une nouvelle discussion si jamais je veux gérer les informations concernant le prix d'achat et de vente?

[Didier L]

Bonsoir,

Effectivement c'est mieux de décomposer les problèmes et les posts.
C'est plus facile à lire et a suivre pour les autres.
Cela permet aussi plus facilement de retrouver un problème commun.
Ne poster pas tout de suite vos questions.
essayer de regarder dans les tutos et les questions fréquentes si votre solution n'y est pas déjà expliquée.
ensuite chercher dans les forum si quelqu'un n'a pas eu le même soucis;
Et enfin si vous ne trouver rien, poser votre question.
Cette recherche est très enrichissante car parfois cela nous donne d'autres idées et nous apprend beaucoup de chose.

Donc par rapport a ce post, si vous penser que j'ai répondu à votre première question, pensez à mettre le sujet "Résolu"

Bonne soirée et à bientôt pour la suite

[adama13]

OK j'en prend note de vos recommandations

Merci pour l'aide que vous m'aviez apporté pour la création de cette Base de Donnée.

Grâce à vous je peut enfin voir le bout du tunnel

Il ne me reste plus qu'une dernière question à poser dans le Forum de Modélisation pour ensuite passer à celui des Requêtes................ .

J'espère de tout cœur que je vous verrez surement dans d'autre discussion.

Encore une fois Mille à vous MONSIEUR DIDIER

[kam1er]

Je pense plutôt que pour une gestion plus fluide et rationnelle, tu dois créer plus de 3 tables. Il te faut en réalité les tables : Tabproduit(Reproduit, libproduit, description, PrixHT, Numfournisseur, TauxTVA, ...), TabCommande(Numcommande, date commande, NumClient, TotalHT, TotalTVA, TotalTTC, TypeCommande[Achat,Vente], ...), TabLigneCmde(IdLignecmde, Numcommande, Refproduit, quantitéCommandée, PrixHT, ...), TabClient(NumClient, Civilité, Nom, prénoms, Téléphone, ...), TabFournisseur (Numfournisseur, Société, Civilité, NomContact, PrenomContact, Téléphone, ...), TabStock (Idstock, Refproduit, QuantitéEnStock, StockVirtuel[Stock-Quantitécommandée], Date modification, ...), dans l'optique de fidéliser ta clientèle sinon la table client n'est pas nécessaire dans ta gestion. Supposons qu'un client veuille commander plus de trois produits ou qu'un fournisseur qui te livre plusieurs produits à la fois, pour minimiser l'utilisation de ton espace disque, il serait plus approprié de faire qu'un seul enregistrement d'où l'utilité de la table TabLigneCmde. Je pense que ma contribution te sera utile.

Cordialement Marcellin kouakou.