Discussion :

[denys30]

Salut à tous,
Tout nouveau sur le forum, j'ai bien besoin de vos lumières!!!

Je crée une base de donner (sous Access 2002) pour gérer une activité commerciale.
Cette activité est un peut spécifique dans le sens où il y a deux stocks physiques à gérer simultanément (ainsi que des ventes).
Un stock dit « réserve » et un stock que l’on pourrai qualifier de « magasin ».

Les ventes aux « clients particuliers » sont déduites uniquement du stock « magasin », lequel devra être ré approvisionner avec le stock « réserve ». Les ventes aux « clients Pro » sont pour la plupart directement déduite du stock « réserve ».

Actuellement je gère tout sous Excel, mais cela est vraiment trop lourd, notamment lorsqu’il s’agît d’ajouter de nouveaux articles.

Je ne rentrerai le total des ventes que le soir, il me faut dans ce cas que les 2 stocks soient automatiquement mis à jour.

Les entrés de nouvelles marchandises se font suite à des livraisons (logique) et n’entrent que dans le stock « réserve ».

J’en arrive aujourd’hui sur le fait de créer 6 tables. « Articles » « Stock réserve » « Stock magasin » « Vente particuliers » « Ventes pro » « Livraisons » et éventuellement une 7ème « clients » mais celle ci ne me sera pas pour le moment d’une utilité primordiale.

Ce que je souhaite c’est que dans mes 2 tables « Stock » je puisse voir la totalité des articles directement sous forme de tableau.
Première question, faut-il pour cela que mes champs présents dans mes 2 tables « Stock » soient identique aux champs des la table « articles » ?

Voila pour une première présentation rapide des premières exigences de ma BD.

Pour info j’ai déjà travaillé il y a longtemps sur Access (j’en connais donc les principaux rudiments, je ne pense pas être un novice complet), mais il va me falloir quelques temps pour m’y réhabituer.

D’avance merci à ceux qui pourrons me donner un coup de main.

P.S. je suis sur une très vielle version d'Access, si je ne ma trompe pas c'est la 97 ou 2000

[paidge]

Bonjour,

Chacun peut avoir un point de vue différent sur la manière de concevoir son modèle de données. Néanmoins, voici ce vers quoi je m'orienterais avec les informations fournies (même s'il est tout à fait possible de mettre les 2 stocks dans une même table en rajoutant un 3ème champ par exemple).
Le champ typeClient détermine s'il s'agit d'un particulier ou d'un professionnel. Le prix de vente pourrait aussi être différent suivant si l'article provient du stock magasin ou du stock réserve. Dans ce cas, il faudrait enregistrer le prix de vente dans la(es) table(s) des stocks. La remise serait en % pour la facturation (si besoin). Mais comme tu n'as pas parlé de prix, je pense qu'il s'agit d'une information que tu ne souhaites pas stocker. Le champ IDlivraison pourrait être le numéro du bon de livraison par exemple. La date de livraison peut stocker l'heure aussi.

[denys30]

Merci pour ta réponse Paidge,

J'avance tout doucement sur cette BD, c'est vrai que je n'ai pas parlé de prix de ventes (et d'HA) mais ils sont important car je souhaite pouvoir connaître en fin de journée le CA et le coef de vente moyen.
Si je peux gérer les stocks sans références clients alors le type de clients ne m'intéresse vraiment pas pour le moment.

Ton idée de regrouper les deux stock en une seule et même table n'est peut-être pas une mauvaise idée, cela permettrait au contraire de visualiser directement où se situent les articles (par exemple un champs quantité_réserve et un autre quantité_magasin).

Par contre, est-il possible de visualiser d'un coup tous les articles présents dans l'un des stock sous forme de feuille tableur?

Je mets en PJ les tables et relations que j'en tire actuellement.

[fab.85]

Bonjour denys30, paidge,

ne faudrait-il pas introduire la notion de code barres dans les tables TdetailLivraison et tdetailfacture ?

denys30, il me semble que c'était l'objet de ton premier post...

Fabien

[denys30]

Bonjour denys30, paidge,

ne faudrait-il pas introduire la notion de code barres dans les tables TdetailLivraison et tdetailfacture ?

denys30, il me semble que c'était l'objet de ton premier post...

Fabien

Tout à fait, mais je pense que cela ne changera pas fondamentalement la structure de la BD et notamment les relations entre les tables non?

Par contre je ne sais absolument pas comment se gère la création et l'édition des code barre. Est-ce un point important dès maintenant, ou on pourra l'aborder une fois que les bases de ma BD serons bien fondées?

[fab.85]

Tout à fait, mais je pense que cela ne changera pas fondamentalement la structure de la BD et notamment les relations entre les tables non?

Je pense que TdetailsLivraison et TDetailFacure pourraient être reliées par le champ code barres. Mais ce n'est qu'une idée à vérifier.

Comment comptes-tu utiliser le code barres?

Comptes-tu te servir du code barres existant ou en créer un de toute pièce? En créer un implique l'étiquetage de chaque article avec ce nouveau code barre.

Un exemple: si un code barre représente l'entrée d'un article dans ton stock, il devra aussi représenter la sortie (facture).

j’espère que tu auras l'avis d'autre membres car c'est primordiale pour entamer ce type de gestion de stock...

et souviens toi:

En attendant l'avis d'autres membres toutefois, deux avis valent mieux qu'un comme dirait un vieux dicton

Fabien

[Robert1957]

Bonjour denys30, paidge, fab.85,

Tu devrais réfléchir à ceci, la différence entre tes tables "Ventes particuliers" et "Ventes pros" se situe au niveau de à qui tu vends, donc une seule table pourrait faire l'affaire avec un champ qui différencie le type de vente (Particulier vs Pro). L'avantage d'une telle structure est que supposons que dans 1 an tu vendes aussi à des semi-pro... avec ton MCD tu devrais créer une nouvelle table. C'est la même chose pour ton stock, une seule table devrait faire l'affaire encore une fois pour les même raisons (un champ pour différencier l'emplacement). Si l'entreprise grossit et que tu as 2 entrepôts au lieu d'un, tu devras créer une nouvelle table.

De plus, sauf exception, un total n'a pas besoin d'être saisie c'est seulement un calcul.

Si le CMUP fait partie de ton équation, tu veux un bel exemple regarde ici: http://claudeleloup.developpez.com/t...tion-de-stock/ C'est très complet.

Bonne journée

[paidge]

Bonjour à tous,

ne faudrait-il pas introduire la notion de code barres dans les tables TdetailLivraison et tdetailfacture ?

J'y avais pensé aussi Le code-barre étant unique pour chaque produit, il peut servir de clé primaire pour l'identification des articles et sera donc utilisé en tant que clé étrangère dans les autres tables liées à la table des articles.

Tu devrais réfléchir à ceci, la différence entre tes tables "Ventes particuliers" et "Ventes pros" se situe au niveau de à qui tu vends, donc une seule table pourrait faire l'affaire avec un champ qui différencie le type de vente (Particulier vs Pro).
...
C'est la même chose pour ton stock, une seule table devrait faire l'affaire encore une fois pour les même raisons (un champ pour différencier l'emplacement). Si l'entreprise grossit et que tu as 2 entrepôts au lieu d'un, tu devras créer une nouvelle table.

Je suis tout à fait de cet avis

[denys30]

Merci vraiment à vous pour vos réponses, je n'ai malheureusement pas eu trop le temps de m'y pencher dessus aujourd'hui mais ça avance doucement quand même.

Si le CMUP fait partie de ton équation, tu veux un bel exemple regarde ici: http://claudeleloup.developpez.com/t...tion-de-stock/ C'est très complet.

Merci pour ton lien je l'avais déjà lu et étudier il y a quelque temps depuis que le projet me tourne dans la tête, mais en fait ce n'est pas tout à fait ce que je recherche pour le moment.

Cette BD je ne souhaite dans un premier temps ne m'en servir vraiment que pour une gestion des stock et non pour de la facturation/compta.
En ce qui concerne les code barre cela ne fait pas de doute sur le faite de ré-étiqueter les articles (c'est déjà ce qui est fait, mais sans code barre justement). J'aurai donc à les créer de toute pièce pour chaque articles. Ils ne me servirons dans ce cas que pour totaliser et répertorier (gérer) les flux de stock.

Une seule table pour les 2 stocks sera en effet suffisant.

Par contre j'ai créer quelques article (même si pas encore de codes barre) mais je ne parvient pas à les faire apparaître dans ma table stock??

[denys30]

J'avance doucement après vos différentes réflexions.
J'arrive du coup à quelque chose de schématiquement plus simple (cf pj)

Pensez-vous déjà que c'est du coup plus cohérent?

Le "code_article" sera le n° code barre, mais là, quelle est la démarche pour le créer?
Encore merci de votre patience et conseils à tous.

[paidge]

Bonjour,
Pour les commandes, je mettrais plutôt un N° de commande en clé primaire. Il te faut une table intermédiaire entre T_livraison et T_articles (T_detailLivraison comme dans mon exemple plus haut ) . Sinon tu ne pourras avoir qu'un seul article par livraison - ce qui risque d'être embêtant :p Même remarque d'ailleurs si tu mets en place un N° de commande. même remarque pour les ventes. Sauf si tu considères qu'une vente ne concerne qu'un seul article A chaque fois que tu as une relation "Plusieurs-à-plusieurs", il faut une table intermédiaire. Par exemple : Un article peut être dans plusieurs commandes et une commande peut concerner plusieurs articles.
Sinon, pour les codes-barres, il y a ce tuto

[denys30]

Salut Paidge,
c'est vrai que j'avais regardé ton exemple sans prendre suffisamment le temps de l'analyser correctement
Du coup j'y ai apporter quelques modifs, par conte j'ai donc créer des tables intermédiaires, mais je me dis du coup que la table "T_vente" ne me servira pas puisque pour le moment je ne souhaite pas faire intervenir les noms et ref des clients.

Le schéma est-il mieux?

Merci pour le lien vers la création des codes barre, je vais étudier ça de prêt, mais vu que je n'ai strictement aucune base en VBA, ça risque de ne pas être évident. On verra bien!

[paidge]

C'est mieux Une remarque concernant la table T_stock. Tu vois bien qu'actuellement entre la table T_articles et T_stock, tu as une relation 1-à-1. C'est-à-dire que pour une ligne de stock tu as un produit et pour un produit tu as une ligne de stock. Ce qui signie que tu peux intégrer les champs de la table T_stock dans la table T_articles. Y'a le champ stock_initial que je ne comprends pas. Autre conseil : Evites les caractères accentués et les caractères spéciaux tels ° dans les noms de table, de champs, de contrôles, de formulaires/états, etc. Ce sera mieux pour la suite de ton développement Le mieux est d'utiliser le underscore (_) et/ou l'écriture camelcase

[denys30]

Pour ce qui est du champ "stock initial" c'était pour rentrer le stock du début et/ou les modif suite à inventaire, mais en faite il ne servira à rien, le stock du début serra rentré comme une livraison. Pour ce qui est des écart d'inventaire, je verrai par la suite, on arrive généralement à bien le gerer différemment.

entre la table T_articles et T_stock, tu as une relation 1-à-1. [...] Ce qui signifie que tu peux intégrer les champs de la table T_stock dans la table T_articles.

Ce qui voudrait dire en faite que je n'ai pas besoin au finale d'une table stock, je pourrais tout mettre directement dans la table article?

[paidge]

[QUOTE=denys30;7723749]Pour ce qui est du champ "stock initial" c'était pour rentrer le stock du début et/ou les modif suite à inventaire, mais en faite il ne servira à rien, le stock du début serra rentré comme une livraison. Pour ce qui est des écart d'inventaire, je verrai par la suite, on arrive généralement à bien le gerer différemment.[QUOTE]

En fait, pour l'inventaire, en faisant le total des entrées (commandes) et le total des sorties (ventes), la différence nous donne l'état global du stock théorique. Je te laisse réfléchir pour les éventuelles possibilités

Ce qui voudrait dire en faite que je n'ai pas besoin au finale d'une table stock, je pourrais tout mettre directement dans la table article?[/

Si les informations nécessaires sont toutes présentes, c'est effectivement le cas

[denys30]

En fait, pour l'inventaire, en faisant le total des entrées (commandes) et le total des sorties (ventes), la différence nous donne l'état global du stock théorique. Je te laisse réfléchir pour les éventuelles possibilités

Avec simplement des requêtes formulées correctement ça devrait suffire non? Mais bon, pour le moment je n'y suis pas encore.

Si les informations nécessaires sont toutes présentes, c'est effectivement le cas

C'est à mon sens effectivement le cas. Je peux très bien avoir dans la table article les quantité présente pour l'article en question dans chacqun des stock, ce qui sera en plus nettement plus facile visuellement pour contrôler l'ensemble dispo.
En ce qui concerne le fait de connaître la valeur monétaire de chacun des stock, là aussi par une simple requête ça devrai être suffisant non?