Projet: Générer des devis, et gestion de stock [SGBD Access] - SQL/NoSQL - Programmation
Marsh Posté le 19-02-2008 à 15:41:23
1) Je n'ai pas vu la question
2) Le but du jeu d'un forum ce n'est pas de discuter en privé, mais en public.
Marsh Posté le 19-02-2008 à 16:07:45
J'ai oublié de mettre l'adresse URL donc voila pour voir les tables:
Sinon pour la question, je voulais savoir ce que vous pensiez de mon projet, si c'est réalisable, si les tables vous semble correctes, et si vous pouvez me donner un coup de pouce
Marsh Posté le 19-02-2008 à 19:08:13
A première vue, ton modèle me semble étrange.
1/ Un devis ne porte que sur UN article ?
2/ C'est quoi ces tables "prix ..." ? Pourquoi y'a un prix unitaire et une quantité ? Pourquoi y'a pas de table de référence pour le produit concerné ? Pourquoi y'a 3 tables de même structure ?
3/ Pourquoi une commande n'est pas reliée à un devis ? (ou inversement)
4/ Pourquoi ta commande et tes mouvement de stock parlent de références produit, alors que tes devis ne font pas mention de produit ?
5/ Pourquoi deux tables différentiant un devis d'une commande ? A la base, une commande, c'est juste un devis validé...
6/ Je ne pige clairement pas cette histoire de produits "de base" (les 3 tables "prix ..." ) Pas de liens avec les commandes, les fournisseurs et les stocks
7/ "Mouvements", c'est des mouvement de stocks, ou des lignes de commande ? Elles sont où les lignes de ta commande ?
8/ Ton stock, tu comptes le calculer comment ? Rejouter tous les mouvements depuis l'an 1 à chaque lecture ?
Remarques :
1/ Client <-> Fournisseur : même structure, autant mutualiser la table. Comme ça, le jour où tu veux constituer une base de prospects par exemple, tu as déjà tout ce qu'il faut sans devoir créer une troisème table.
2/ Vire ces noms à ralonge, accentués et bourrés de caractères non ASCII. Tu comptes écrire comment le SQL avec des noms pareils ?
3/ Access, étant donné qu'il y a une partie des flux qui sont ouverts aux clients (validation du devis, éventuellement, le suivit de la commande, etc.) pourquoi ne pas faire un site internet ? (PHP/MySQL si tu comptes faire un truc pourri -on est pas vendredi mais bon-, .NET/SQL Server par exemple si tu veux faire un truc propre)
Marsh Posté le 19-02-2008 à 20:57:04
Merci pour ta réponse même si j'ai pas tout pigé, alors j'ai apporté les modifications que j'avais comprise, je met la le screen de mes nouvelles relations:
En ce qui concerne le point numéro:
1: Oui un devis ne porte que sur une pièce
2:Il y a trois tables de prix, car une fois le DPS calculé, on calcule le prix selon si c'est une base rectangle, cylindrique, ou autre, et j'ai rentré des formules différentes pour chacune des bases, donc une fois le DPS calculé on choisi entre base rectangle, base cylindrique... tu vois?
J'ai mis un champ Qte et un PrixUnitaire car on en a besoin pour calculer le prix du lot
La table reference c'est la table produit
Les trois tables on peut etre la meme structure, mais les formules sont différentes (pour calculer les volumes)
3:J'essai de relier la table Cde a la tableDevis mais dans la table devis je veux un clé primaire de type texte ex FenH100 pour une fenetre de hauteur 100, et dans la table cde j'ai une clé primaire de type numérique, je pense que c'est mieux de numéroter les commandes
4: rectifié merci
5:je différencie le devis de la commande, car je veux faire apparaitre tous les prix calculé précédemment, puis créer un etat pour l'envoyer au client, et une fois validé le passer en commande, mais je pense que je pourrais le passer sur commande, je me demande si cela ne posera pas de problème avec les calculs
6:les 3 tables prix sont compris en fait dans le devis, et les stock devront etre décrémenté a partir du devis ou de la commande
7,8: je pensais calculer mon stock avec ma table mouvement et produit, mais je sais pas si cela est possible
Remarques:
1: ces deux tables ont les mêmes structures, mais elle ne renvoient pas au même enregistrement, si je les mutualise on risque de s'embrouiller non, et qu'est ce qu'une base de prospects
2: rectifié merci
3: je travail sur access car on ma demandé de travailler sur sa pendant mon stage, et c'est le seul logiciel que j'ai a ma disposition dans l'entreprise
Voila désolé si c'est long, mais je débute et j'écoute vos conseil du mieux que je peux. merci
Marsh Posté le 20-02-2008 à 00:08:48
1/ ok
2/ pas trop pigé, m'enfin de toute façon c'est pas bien gênant (je trouve juste que c'est se compliquer la vie pour pas grand chose, et limiter le modèle : le jour où t'as une base triangulaire, t'as plus qu'à créer une 4° table )
3/ ben rien n'empêche dans la cde ou le devis de rajouter un champ qui est une clé étrangère vers l'autre table.
4/ ok
5/ l'un n'empêche pas l'autre : contractuellement, le montant de la commande doit être le même que le devis accepté
6/ pas tout compris. et on ne décrémente pas un stock à partir d'un devis. tout au pire, on "isole" ou "réserve" des produits, mais on ne les sors pas du stock avec un devis
7,8/ oui, ça reste possible. mais une table "dépôt" avec comme champs : id_produit, quantite_stock me semble plus simple à gérer. à toit ensuite de faire attention à bien la mettre à jour lors des ajouts de mouvements de stock, et éventuellement écrire une procédure de recalcul des compteurs (rejouer tous les mouvements enregistrés pour recalculer le stock exact). c'est très important, parceque tes stocks peuvent être incrémentés/décrémentés sans que des commandes n'aient été touchées (produits détruits, perdus, retrouvés, etc.). à la limite, si t'as qu'un seul dépôt et que ça changera jamais, tu peux ajouter "stock" dans la table des produits, ça évite de créer une table supplémentaire
1/ ça dépent, un champ "type_de_tiers" permet de dire si c'est un client, un fournisseur, un prospect ou autre par exemple
2/ ok
3/ c'est effectivement une raison suffisante. pas convenable, mais suffisante
Marsh Posté le 20-02-2008 à 17:38:19
Bonjour merci pour ces conseils, j'ai essayer de remédier aux tables devis et commandes afin de n'en faire qu'une seule comme vous m'avez indiqué, mais maintenant niveau relation je trouve sa beaucoup plus compliqué, sachant que je n'arrive pas a mettre toute les relation que je veux, d'autant plus qu'avec les tables de prix, les relations deviennent trés étendue, je ne sais pas comment remédier a cela, dois je dupliquer les relations en 3 a chaque fois, ou regrouper ces trois tables en une.
Pour le stock, dans la table produit j'ai déjà une ligne QteEnStock sa ne suffit pas?
Je mets ici mon nouveau schéma relationnel si vous pouvez y jetter un coup d'oeil et me dire ce qui ne va pas.
Merci
Marsh Posté le 20-02-2008 à 19:38:34
J'avais pas vu que tu avais un compteur de stock dans la table produit, donc oublie ce que j'ai dit à propos des stocks
Je suis habitué à travailler en multi-dépôt, donc j'ai même pas imaginé un instant sur le coup trouver ce champ dans la table produit Mais si t'as qu'un seul dépôt, aucun problème.
Marsh Posté le 20-02-2008 à 19:53:58
oui je n'ai qu'un seul dépôt, mais pour les relations, tu as vu sa se croise dans tous les sens, et encore je n'ai pas pu faire toute les relations, sa te semble normal? il n'y a pas un problème quelque part?
Marsh Posté le 20-02-2008 à 20:20:20
une question: si je supprime la table mouvement, et que je cre un champ, QteEntré et QteSortie dans la table Produit c'est pas plus simple?
Marsh Posté le 20-02-2008 à 21:04:32
non. garde la table mouvement, elle a une vocation différente du compteur qui est dans produit.
c'est un cas particulier de dénormalisation : tu acceptes la présence potentielle d'erreurs infimes dans ton compteur, plutôt que de devoir le recompter à chaque fois.
dupliquer le compteur en deux, c'est multiplier le risque d'erreur, mais surtout, supprimer la table des mouvements, c'est l'incapacité de recalculer les stocks en cas d'erreur détectée.
Marsh Posté le 20-02-2008 à 21:39:30
D'accord je vois, maintenant si je garde la table mouvement, mais que je crée un champ Qte Entre et QteSortie, c'est pas plus clair, ou sa augemente le risque d'erreur?
Sinon comment je lis la commande chez un fournisseur de matiere premiere, je n'ai pas de trace de sa non?
Marsh Posté le 20-02-2008 à 23:56:30
là effectivement j'en vois plus trace, je crois que t'y es allé un peu fort sur la simplification du modèle
Marsh Posté le 29-02-2008 à 20:20:04
Je reviens avec ma base:P, je vais essayer un truc que j'ai vu sur le net pour gérer mes stocks, j'ai créé 3tables que voici
Je voudrais savoir comment faire pour voir toutes mes lignes de stock, et voir le stock, j'ai vu des solutions en rajoutant des table entre et sorti mais je n'ais pas compris
Marsh Posté le 06-03-2008 à 14:48:17
Bonjour j'ai reussi a faire mes lignes de stocks, maintenant je voudrais réaliser une requete pour effectuer un premier tri, j'entend par la rentrer une catégorie dnas une premiere liste déroulante et je veux que la deuxieme liste déroulante (produit) ne m'afficher que les produits dans la catégorie sélectionner auparavant.
J'ai une table tbleproduit avec idproduit, nomproduit, idcategorie
et une table tblcategorie avec idcategorie, categorie
quel est la conditions a rentrer pour que cela fonctionne merci.
Marsh Posté le 19-02-2008 à 15:19:26
Bonjour je me lance, alors je dois mettre en place une base de donnée sur access 2007 pro pour l'entreprise ou je suis en stage au canada!
On ma demandé de permettre de faciliter le calcul des devis, afin de les envoyers au client par mail, une fois retourné et validé on passe la commande, on fabrique la pièce avec les quantité voulue, on rentre les pièces necessaire a la fabrication et on mets à jour le stock, en théori sa devrait aller, sauf que je suis débutant alors sa va pas!
J'ai crée 11tables, je les mets ici: Pour vous permettre de critiquer mes tables.
Le but de la bd est de faire sur formulaire un menu général sur lequel on peut gérer les clients, les employés et les fournisseurs d'une part.
D'autre part on gère aussi les devis, pour cela j'aimerais commencer par rentrer le nom ou numéro de DPS (un des prix a calculer pour l'élaboration du devis), ensuite on a le choix entre 3 types de base, soit rectangle, soit cylindrique ou autre, j'ai rentrer les calculs dans les formulaire, mais ces calculs sont différents selon la base donc je les ai dissocié. Et je voudrais avoir un dernier formulaire qui me récapitule le nom ou numéro de dps+base, le prix du dps et de la base, faire un total, l'envoyer au client, et si validation, le valider et l'envoyer en commande.
Suite à cela, j'aimerais selon la commande incrémenter ou décrémenter les pieces necessaire, plus le rebut, et pouvoir avoir les stock en temps réel.
Voila dite moi ce que vous en pensez s'il vous plait, si jamais quelqu'un veut voir de plus prés a quoi cela ressemble donnez moi votre adresse en mp je vous l'envoi .