Conseil pour schéma relationnel : gestion stock/ventes/commandes

[sarah33]

Bonjour,

Je suis en train de créer une base de données ACCESS 2013 (en mode bureau) pour la gestion d'une boutique de jouets pour enfants.

Les fonctionnalités souhaitées sont:

• Gestion des stocks (entrés - sorties)
• Gestion des ventes (sorties), par client
• Gestion des commandes (entrées), par fournisseur

Voici le schéma relationnel de ma base de données:



Petite description de mes tables:

• Tfournisseur et Tclient: recensent fournisseurs & clients
• Tarticle : recense l'ensemble des articles de la boutique
• Tcommandes_F: recense l'ensemble des commandes fournisseurs et correspond aux "entrées" du stock
• Tventes: recense l'ensemble des ventes réalisées et correspond aux "sorties" du stock
• Element : permet d'avoir plusieurs articles, dans une commande ou une vente

Tout d'abord, j'aimerai avoir votre avis sur mon schéma, est-il juste?

Ensuite, j'aimerai ajouter une fonctionnalité à cette base de données.
J'aimerai créer des commandes clients (table que je nommerai: Tcommandes_C), lorsqu'un article n'est pas en stock. Puis, à réception de la marchandise, j'aimerai pouvoir transformer cette commande client en vente.

Pouvez-vous m'aider à concevoir le nouveau schéma?

Merci d'avance pour votre expertise, je reste disponible pour interagir avec vous.

Sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour

Pourquoi pas tout simplement un champ dans la table T_ventes qui précise si c'est une commande en cours ou terminée : cela permet de différencier les commandes en attentes de commandes vendues. Éventuellement prévoir une date de commande et une date de réalisation.

Tu dois être capable de rééditer une vente à l'identique plusieurs mois après (législation). Pour cela le prix de vente doit figurer

• soit dans la table Element
• soit dans un table de prix avec les date de validité du prix

C'est aussi souhaitable pour le prix d'achat qui peut varier au fil du temps : cela permet de suivre l'évolution mais c'est moins une obligation.

Tel que ta structure ne permet pas d'acheter un article chez plusieurs fournisseurs.

Je ne mélangerais pas les Elements de ventes et ceux de commandes Fournisseurs : je prévoirais une table LignesVentes et une autre LignesAchats.

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour Chris,

Tout d'abord, merci pour ta réponse (j’espérais secrètement que tu passes par mon fil pour me répondre )

J'ai bien réfléchie sur tes suggestions, et voici mon nouveau schéma:

• J'ai renommé les tables, c'est plus claire maintenant.
• Diviser la table "Element" en deux: une pour les ventes T_LignesVentes et l'autre pour les commandes fournisseurs T_LignesAchats
• Quelques modifications sur la table: T_ventes:
  - Prix: on voit le prix total des articles (lignes de ventes)
  - Réduction: on peut faire une réduction sur le prix total de la vente.
  - Prix de vente = Prix - réduction
  - Date_commande = la date à laquelle le client à valider son achats
  - Date_réalisation = date à laquelle la finalisation de la vente est prévue (ex: si l'article n'est pas en stock, la date à laquelle on prévoit de le recevoir et donc de le livrer au client pour finaliser la vente).
  - Finalisation (oui/non): lorsque la vente est entièrement payée, et que tous les articles sont livrés.
• Ajouter une table T_paiement, pour avoir un suivi des paiement: Si un client paye en plusieurs fois une vente, ou donne un acompte, ça me permet de suivre ça de plus près.

Concernant la table LignesVentes, voici ma logique:

T_LignesAchats - T_LignesVentes(qui ont le statut effectué) = Stock
Lors d'une vente, si le stock d'un article est > 0 ; alors l'article est en stock, la Ligne de vente peut alors être réalisée, et le statut de la ligne de vente devient :"effectué"
Si stock = ou < 0; nous sommes en rupture pour cette article. La vente peut se faire, mais la ligne de vente ne sera pas effectué, mais "à commandé". (on rempliera aussi le champs: "prévu le", pour garder en tête la date de livraison client).
Lorsque nous aurons fait la commande au fournisseur, le statut de la commande sera alors: "commandé".
Puis lorsque nous aurons reçus l'article, et nous l'aurons livré au client, le statut sera "effectué"

Qu'en penses-tu?


Fonctionnellement, mon but est de pouvoir:
* connaitre quels articles sont à commander, et en cours de commande.
* une fois commandés (changement de statut), ils disparaissent de ma liste d'articles "à commander".
* une fois reçu et livré au client (changement de statut), ils sont décomptés dans le niveau des stocks. Et la vente peut être clôturée.

* avoir une trace pour tous les clients: de chaque ventes, paiements, commandes.
* avoir une trace de toutes les ventes non clôturées.
* avoir un rapport régulier hebdo/mensuel du CA et des ventes
* avoir accès à mon niveau des stocks en temps réel

Selon vous, est-ce que le schéma de ma BD permet tout cela?
Si oui, je vais devoir passer à l'étape d'après: les formulaires ou requêtes?
Pourriez-vous me guider ou me renseigner vers des tutos (y en a des milliers sur le net, je ne sais pas vers lesquels me tourner).


Merci d'avance.

sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour

Voir mes commentaires dans ton message

Bonjour Chris,

Tout d'abord, merci pour ta réponse (j’espérais secrètement que tu passes par mon fil pour me répondre )

J'ai bien réfléchie sur tes suggestions, et voici mon nouveau schéma:
Regarde la pièce jointe 311728

• J'ai renommé les tables, c'est plus claire maintenant.
• Diviser la table "Element" en deux: une pour les ventes T_LignesVentes et l'autre pour les commandes fournisseurs T_LignesAchats
• Quelques modifications sur la table: T_ventes:
  - Prix: on voit le prix total des articles (lignes de ventes). Je conseille aussi de garder le prix de vente dans la ligne détail donc dans T_LignesVentes. Si on garde aussi le prix d'achat dans T_LignesAchats on peut calculer sa marge brute plus facilement
  - Réduction: on peut faire une réduction sur le prix total de la vente.
  - Prix de vente = Prix - réduction
  - Date_commande = la date à laquelle le client à valider son achats
  - Date_réalisation = date à laquelle la finalisation de la vente est prévue (ex: si l'article n'est pas en stock, la date à laquelle on prévoit de le recevoir et donc de le livrer au client pour finaliser la vente).
  - Finalisation (oui/non): lorsque la vente est entièrement payée, et que tous les articles sont livrés.
• Ajouter une table T_paiement, pour avoir un suivi des paiement: Si un client paye en plusieurs fois une vente, ou donne un acompte, ça me permet de suivre ça de plus près.

Concernant la table LignesVentes, voici ma logique:

T_LignesAchats - T_LignesVentes(qui ont le statut effectué) = Stock (selon champ Finalisation ou statut(?) de la table T_LignesVentes, stock réel ou théorique : il faut faire attention aux champ qui permettent de faire ce calcul article par article sans ambiguïté.
Lors d'une vente, si le stock réel d'un article est > 0 ; alors l'article est en stock, la Ligne de vente peut alors être réalisée, et le statut de la ligne de vente devient :"effectué"
Si stock = ou < 0; nous sommes en rupture pour cette article. La vente peut se faire, mais la ligne de vente ne sera pas effectué, mais "à commandé". (on rempliera aussi le champs: "prévu le", pour garder en tête la date de livraison client). C'est un peu plus compliqué car il peut y avoir des commandes fournisseurs en cours. Il faut donc tenir compte du stock réel et du stock théorique pour savoir si on attend le produit ou s'il faut en commander
Lorsque nous aurons fait la commande au fournisseur, le statut de la commande sera alors: "commandé".
Puis lorsque nous aurons reçus l'article, et nous l'aurons livré au client, le statut sera "effectué"

Qu'en penses-tu?


Fonctionnellement, mon but est de pouvoir:
* connaitre quels articles sont à commander, et en cours de commande.
* une fois commandés (changement de statut), ils disparaissent de ma liste d'articles "à commander".
* une fois reçu et livré au client (changement de statut), ils sont décomptés dans le niveau des stocks. Et la vente peut être clôturée.

* avoir une trace pour tous les clients: de chaque ventes, paiements, commandes.
* avoir une trace de toutes les ventes non clôturées.
* avoir un rapport régulier hebdo/mensuel du CA et des ventes
* avoir accès à mon niveau des stocks en temps réel

Selon vous, est-ce que le schéma de ma BD permet tout cela?
Si oui, je vais devoir passer à l'étape d'après: les formulaires ou requêtes?
Pourriez-vous me guider ou me renseigner vers des tutos (y en a des milliers sur le net, je ne sais pas vers lesquels me tourner).


Merci d'avance.

sarah

Voilà très rapidement. Globalement cela me paraît bien.

Peut-être prévoir une table d'ajustement de stock lors de l'inventaire ou bien une pseudo vente en positif (ou négatif)

Commencer par les requêtes pour bien valider la pertinence et l'adéquation structure/besoins.
Penser à inscrire dans la structure des tables les possibilités de listes déroulantes : exemple pour la saisie d'un article en T_LignesAchats ou T_LignesVentes, la liste issue de la table article : les formulaires en hériteront naturellement.

A propos pour ces 2 tables utiliser plutôt une clé primaire composite : N° commande+ N°ligne

Pour Access il y a le site Forums self-access.com dont l'auteur a écrit des bouquins assez bien faits. Il y a aussi des ressources sur developpez.net.

Je pars très bientôt me mettre au vert donc je ne serais que très peu sur XLD...

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Salut Chris, le forum,

Suite à tes remarques, j'ai apporté quelques modifications sur mon schéma:

J'ai également peaufinée mes règles de stock:

T_LignesAchats - T_LignesVentes(qui ont le statut effectué) = Stock (selon champ Finalisation ou statut(?) de la table T_LignesVentes, stock réel ou théorique : il faut faire attention aux champ qui permettent de faire ce calcul article par article sans ambiguïté.
Lors d'une vente, si le stock réel d'un article est > 0 ; alors l'article est en stock, la Ligne de vente peut alors être réalisée, et le statut de la ligne de vente devient :"effectué"
Si stock = ou < 0; nous sommes en rupture pour cette article. La vente peut se faire, mais la ligne de vente ne sera pas effectué, mais "à commandé". (on rempliera aussi le champs: "prévu le", pour garder en tête la date de livraison client). C'est un peu plus compliqué car il peut y avoir des commandes fournisseurs en cours. Il faut donc tenir compte du stock réel et du stock théorique pour savoir si on attend le produit ou s'il faut en commander

Stock réel = le stock qui est physiquement en stock
Stock théorique = stock réel + les marchandises en cours d'arrivage - les marchandises commandées par les clients (réservées)
* stock théorique: si il est négatif, c'est qu'il faut commandé des articles, car des clients l'ont déjà réservés; s'il est nul, c'est qu'il n'y a aucun arrivage prévu, ou que l'intégralité de l'arrivage prévu est déjà réservée par les client.

T_LignesVentes et T_LignesAchats ont un champs: statut.
Ce champs est une liste déroulante contenant 3 mentions: "à commander" ; "commandé" ; "effectué"

voici la nouvelle règle:
Stock réel = T_Inventaire + T_LignesAchats (statut: effectué) - T_LignesVentes (statut: effectué)
Stock théorique = T_Inventaire + T_LignesAchats - T_LignesVentes
Pour savoir ce qu'il faut commander (par rapport aux réservation clients): T_LignesVentes (statut: à commander)
Pour connaitre les articles qu'on a commandé et qui sont attendus par les clients: T_LignesVentes (statut: commandé)
Lorsque la commande fournisseur est réceptionnée, et que nous livrons le client, le statut devient: "effectué"
Lorsqu'un client achète un article en stock, le statut de la T_LignesVentes est directement: "effectué"


Lorsqu'une vente est achevée : tout est payé, et le client est en possession de tous ses articles:
L'ensemble des T_LignesVentes d'une vente (T_Ventes) ont le statut "effectué", et le champs Prix de la vente (T_Vente) est égal à la somme des Paiement (T_Paiement; champs "montant") associés à cette Vente.

Pour savoir quelles sont les ventes en attente de paiement: L'ensemble des T_LignesVentes d'une vente (T_Ventes) n'ont pas le statut "effectué"
Pour savoir quelles sont les ventes en attente de livraison d'article: le champs Prix de la vente (T_Vente) ne correspond pas à somme des Paiement (T_Paiement; champs "montant") associés à cette Vente.

Sommes nous en phase?
En tout cas Chris, merci pour ces précieux conseils, et bonnes vacances !

sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour

Stock réel = T_Inventaire + T_LignesAchats (statut: effectué) - T_LignesVentes (statut: effectué) (selon dates des achats et ventes > date dernier inventaire

Il faut aussi la date de réception en stock dans T_LignesAchats car elle est différente de la date commande fournisseur.

A priori rien d'autre sauf la remarque déjà faite : sur les tables T_LignesAchats,T_LignesVentes et T_Paiement utiliser des clés composites de 2 champs : N° de la cde (client ou fournisseur selon la table)+numéro de ligne (ou paiement). Cela assure une meilleure intégrité référentielle et facile l'exploitation.
Le numéro de ligne ne sera pas en numéro auto mais propre à chaque sous-ensemble.

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour Chris, le forum,

Waouh, je me suis bien pris la tête sur ces clés composites de 2 champs.

J'ai donc mis 2 clés primaires pour les tables T_LignesVentes et T_LignesAchats. (c'est bien ça que tu m'as suggérer de faire?)
les 2 champs: "N°Ligne" et N°(commande ou vente).
Le problème est que mon champs N°Ligne est en n° auto, et à la fin de ton message tu dis qu'il ne l'est plus...
Comment faire?
Je le laisse en numérique, et dans mes formulaires je fais une macro pour compter la ligne à chaque fois?


Autre point, j'ai laissé le prix des table T_LignesVentes et T_LignesAchats.
Cependant, c'est un champs déjà existant dans T_Articles. Je bloque un peu sur ce point, car je me demande s'il faut que je fasse des relations?
Je souhaite garder une certaine souplesse: à la fois, lorsque je fais un T_LignesAchats ou T_LignesVentes, il faut que le prix pardéfaut soit le prix figurant dans T_Article, mais à la fois, il faut que je puisse le modifier lors des négociations, ou ajustement pendant ou une vente ou un achat.... je suis un peu pommée là sur ce point.. c'est là ou la notion d'intégrité référentielle intervient n'est-ce pas?

Car même pour les autres jointures de mon schéma, je ne sais jamais si il faut appliquer: intégrité référentielle, mettre à jour en cascades les champs correspondants et Effacer en cascade.....
(J'ai systématiquement appliquer les 3 case à cocher pour chaque relation...)


Merci d'avance.

sarah

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes


Voilà mon nouveau schéma.

* j'ai fait une relation entre T_LignesVentes & T_CommandesF, afin d'avoir la possibilité de commander les articles reservés par le client en T_LignesVentes, dont le statut est "à commander". Ce n'est qu'une petite partie des commandes qui seront dans ce cas là.

* J'ai rajouté une table T_Catégorie , pour la typologie d'article: ce qui permettra d'ajouter simplement de nouvelles catégories d'article.

* J'ai fait ma première requête!!! et pas la moindre. J'ai fait une Union (nommée: "Union_Stock") de T_Inventaire / T_LignesAchats / T_LignesVentes, afin de regrouper en une table, les références, statut et quantités.
J'ai décidé que les valeurs de quantités de la T_LignesVentes seraient négatives (un formulaire se chargera plus tard de saisir ces données en "négative" sans que l'utilisateur n'est à mettre le "-"), afin de différencier et soustraire plus simplement les valeurs sorties du stock.

Pour finir, j'ai créée une autre requête avec la formule: stock réel: Somme(VraiFaux([Union_Stock]![Statut]="finalisé";Nz([Union_Stock]![Quantité];0))) pour obtenir mon stock réel.

Si tu as des suggestions, commentaires et remarques je suis preneuse !!!!

PS: c'est ma première BD Access (je n'y avais jamais touché auparavant, je faisait tout sur Excel.) donc n'hésitez pas à me recadrer sur les bonnes manières, etc.


merciiii byeeee


sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour

Juste 2 remarques

Pas vérifié mais je crains que le relation entre T_LignesVentes & T_CommandesF car tu ne pourrais a priori avec ce champ vide pour les ventes sans commande Fournisseur associée.

Tu pourras utiliser le champ sans relation ou avec une relation sans intégrité référentielle.

Peut-être une question de vocabulaire : la requête union reste une requête pas une table.
De façon générale il ne faut pas générer de table sur des données calculées.

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour Chris,

Merci pour tes remarques, j'ai fait les modifications.

J'ai un autre point sur lequel je bloque un peu: au niveau de T_Articles:

* Certaines Référence (T_Articles) peuvent être le résultat de plusieurs autres Références:
exemple Référence A = 2x Référence B + 3x Référence C

* Certaines Références peuvent être des options d'autres Référence:
exemple: les Références E et F sont des options qu'on peut ajouter à la Référence A
L'idée c'est de savoir rapidement quels sont les options de la Référence A lorsque je la selectionne

Je suppose qu'il faut que je crée 1 table (peut être 2?)?

Mais je ne vois pas du tout quels champs et quelles relations il faudrait que j'applique?

Merci d'avance pour vos lumières.

sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour

Pour les options, il faut qu'un champ de la table article spécifie que c'est un article ou une option ou un kit et créer une table de liaison articles/options possibles : clé article principal + clé article option (autant d'enregistrements pour un article que d'options).
Ces options sont physiques ?

Pour les kits c'est plus complexe, il faut un code article pour le kit plus une table des kits : clé article kit + clé article composant + quantité (autant d'enregistrements pour un kit que de composants)

Dans les 2 cas cela complique la gestion de stocks... et de réappro

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Une option est un article, qui peut être commandé à part de l'article qu'il vient compléter, c'est donc physique.
Au niveau de la gestion des stocks je pourrais faire 2 requetes?
* une prenant en compte uniquement les kits sans ses composants
* l'autre prenant en compte les composants sans les kit (notamment pour la réappro)

Qu'en penses tu?

sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

RE

Tout dépend si tu rentres ou non les kits en stock (pour les ventes) et aussi si tu assembles les kits ou les achètes en kit (pour les achats) ...

 

[sarah33]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour le fofo, chris,

Punaise, quelle galère j'ai passé ma soirée sur cette histoire de Kit.... essayée de tournée le problème dans tous les sens...voici ma rélfexion:

Pour les options:
Une référence T_Articles, peut avoir une option (si champs option de T_Articles<>""). Cette option T_Option est composée de plusieurs Référence d'articles T_RefOption.
Une option n'est donc pas physique puisque ça sert juste à associer des Références existantes à d'autres, il n'y a aucune nouvelle Référence à créer.
==> Pas de changement pour la gestion des stocks, cette fonctionnalité permet principalement de faciliter les ventes en sachant directement quels sont les options existantes pour un article.


Pour les kits:
Un Kit T_Kit est un composé de plusieurs Références T_Articles, associées à des quantités via la table T_RefKit.
Il comprend les même champs d'information que T_Articles.
Lors d'une vente ou d'un achats, ceux sont ses composants (Références) qui seront commandés/Vendus.
Cependant, des informations comme: Désignation, Description, Prix seront utilisés pour les formulaires permettant de créer une T_Ventes ou T_Commande, et calculer les prix.
Je pense donc créer une requete Union, afin que lors d'une vente / achats, on puisse sélectionner un Kit. Cependant, ceux sont ses composants qui seront ajouter aux LignesVentes & LignesAchats

Pour la gestion des stocks:
* une requete ne prennant pas en compte les Kit
* une requete prenant en compte les kits: un calcul (avec arrondie inf) sera nécessaire pour déterminer le nombre de Kit disponible. Cette deuxième requete sera "faussée", car si on additionne le nombre de kit + le nombre de composant et qu'on reporte tout en composant, le niveau de stock est faux.

Qu'en penses tu?


PS: je viens de voir que j'avais oublié la relation T_Kit à T_Options, car un Kit peut avoir des options...

sarah

 

[chris]

Re : Conseil pour schéma relationnel : gestion stock/ventes/commandes

Bonjour

Pas bien compris l'utilité de N° option. Le fait qu'un article ait ou non des options suffit et on peut les trouver dans la table d'association article/options : double clé primaire clé article principal et clé article option et pas d'autres champs.

Je rangerais les kits dans les articles : il faut donc un champ "article ou kit" plus une table d'association comme pour les options mais avec quantité en plus. Donc finalement un champ "article ou kit ou option" unique sauf si un même article peut remplir les deux fonctions.

A la limite une table unique d'association kit et options avec un champ "type" pour option ou kit et une quantité à un pour les options doit pouvoir faire l'affaire.

La vente se ferait sur le kit mais la commande pourrait détailler le contenu (le prix du kit n'est sans doute pas la somme des P.U.)
La requête de stock pourra utiliser T_lignesVente et la table association kits : cela devrait faire le bon calcul.

Tu n'as pas précisé si tu achètes les kits ou les assemble : cela change pas mal les choses pour les ventes comme pour les achats...

Les options du kit sont les options des composants je pense : cela complique un peu la commande et le calcul du prix...