Discussion :

[Adadry06]

Bonjour,

J’ai actuellement pour mon entreprise un tableau Excel qui me permet de gérer les stocks et inclure des commandes. Ce fichier Excel est limité et lourd à l’utilisation sans compter les erreurs d’utilisation.
Pour faire simple, j’ai différentes références appelées A, B, C… Dans chaque référence j’ai plusieurs coloris. Les quantités de stock dans ce tableau sont en kg. A ce stock, je peux ajouter une commande de référence (exemple : référence A coloris rouge 100kg au stock initial) et ajouter des commandes de clients (exemple : Client Alfred me commande de la référence B coloris noir 50kg, 50 à soustraire du stock à jour).

Je sais qu’il est important d’avoir les bonnes bases pour faire une gestion de stock sur Access.

Ma solution à ce jour serait de créer les éléments suivants :
- « Table stock » avec référence, coloris, quantité initial, quantité entrée (commande d’une référence), quantité sortie (commande d’une référence par le client), date modification.
- « Table commandes références » avec n°cde, référence, coloris, date cde, date livraison et Etat
- « Table commandes client » avec client, nom commande, référence, coloris, date cde, qté cde et date livraison souhaitée.

- Une requête pour chaque table pour afficher un stock de la référence que l’on souhaite visualiser à jour (car j’ai une trentaine de références, il n’est pas agréable d’afficher toutes les références et tous les coloris de toutes les références), un suivi des commandes et un suivi des commandes client.

- Un formulaire commandes références
- Un formulaire commande client où l’on peut ajouter une commande avec toutes les quantités (car un client peut demander plusieurs références et plusieurs coloris pour une commande.

Pouvez vous me dire si c’est une bonne solution de faire tous ces éléments ? Il y a surement plus simple à faire.

Merci pour vos réponses, et j’espère pouvoir me lancer dans cette base de donnée.

[SergioMaster]

Bonjour et bienvenue

C'est très, très léger comme structure de base de données et vous allez avoir plein de redondances !
Ajoutez une table articles (code, désignation, prix) une tables coloris(code, libelle), une table Clients (Code,Nom ...)
pour les tables utilisez les codes à la place de références (quand j'ai lu références au départ je croyais que c'était ça jusqu'à ce que je lise votre exemple)
mettez des contraintes de clé étrangères etc...

Mais, je me pose la question, quel est le rapport avec Delphi ?

[Adadry06]

Merci Sergio,

Pour les références je ne comprends pas de quoi vous parlez des codes?
Exemple : nous avons une référence que l'on appelle "300", pourquoi dois je utiliser des codes? Car le client va nous demander 30kg dans la référence 300.

Je ne comprends pas votre question avec delphi?

[SergioMaster]

Bonjour

Je ne comprends pas votre question avec delphi?

Cette question est posée dans le forum Delphi/Base de Données, or dans votre question il n'est nulle part fait mention de programmation Delphi. Du coup je me demande si vous avez posté dans le bon forum puisqu'il s'agit plus d'une validation de structure de base de données (Access qui plus est)

Exemple : nous avons une référence que l'on appelle "300", pourquoi dois je utiliser des codes? Car le client va nous demander 30kg dans la référence 300.

pour moi, une référence est un libellé "300" qui n'a rien à voir avec un code unique numérique (même si par hasard il peut avoir la même valeur)

Une table références ou articles contiendrait
un code numérique unique non nul servant de clé primaire
un libellé chaine de caractères non nul unique, pouvant servir d'index (ce que vous appelez référence)
et toute autre information liée comme : l'unité, le prix unitaire etc...
Reste à définir ce qu'il en est pour les coloris mais c'est un peu le même principe une table coloris(code,couleur) c'est mieux que de soumettre la base de données à des erreurs d'orthographe
exemple :

REFERENCES
1 Référence 200489 L 10.50
2 Référence 300 KG 30.00


COLORIS
1 VERT
2 ROUGE
3 BLEU
4 JAUNE

Votre table "stocks" ne doit pas utiliser le libellé (ce que vous nommez référence) mais le code numérique de la table au-dessus
pour donner un exemple si vous utilisez les libellés "référence 300", "Référence 300", "REFERENCE 300" , aléas de saisie, sont des articles différents

Stocks
1,1,10,0,5
2,3,0,15,0

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
--  Stock valorisé au PU
SELECT R.REFERENCE,C.COULEUR, S.I+S.E-S.S as Stock,R.UNITE ,(S.I+S.E-S.S)*R.PU  
       FROM STOCKS S 
       JOIN REFERENCES R ON R.CODE=S.CODE 
       JOIN COLORIS C ON C.CODE=S.COULEUR

Référence 200489 VERT 5 L 52.50
Référence 300 BLEU 15 KG 450.00

[Adadry06]

D'accord je comprends mieux le rôle des codes.

Par contre, je ne peux pas dire par exemple que "2 référence 300" fait 30kg. c'est : nous avons 30kg de référence 300. Le client ou autre ne commande pas un certains nombre que l'on peut multiplier par le poids unique pour en trouver le total. Le client me commande directement 15kg.

Mais après sur mon formulaire je peux quand même enregistrer une commande où l'on inscrit la "référence" et le coloris? Car ce n'est pas évident de connaître tous les codes.

[SergioMaster]

Mais après sur mon formulaire

Au risque de me répéter, vous êtes sur un forum DELPHI, et donc c'est l'interface utilisateur qui proposera une liste, un combobox ou tout autre moyen de sélection pour la saisie.

je ne peux pas dire par exemple que "2 référence 300" fait 30kg.

vous avez mal lu mes propositions "2 Référence 300 KG 30.00" , le 30.00 ne fait pas référence à un poids mais à un prix unitaire

Car ce n'est pas évident de connaître tous les codes.

je connais des entreprises où les références font jusqu'à 21 chiffres, il est effectivement commercialement parlant de donner un nom comme "roulement à bille de 20*50*15" ce qui devient compliqué à écrire sans se tromper , mais j'en connais qui font la relation sans ordinateur et pourtant, il y en a des pièces dans ce magasin

[Galet]

D'accord je comprends mieux le rôle des codes.

Par contre, je ne peux pas dire par exemple que "2 référence 300" fait 30kg. c'est : nous avons 30kg de référence 300. Le client ou autre ne commande pas un certains nombre que l'on peut multiplier par le poids unique pour en trouver le total. Le client me commande directement 15kg.

Mais après sur mon formulaire je peux quand même enregistrer une commande où l'on inscrit la "référence" et le coloris? Car ce n'est pas évident de connaître tous les codes.

Bonjour,
Le problème n'est-il pas l'unité de stock ? Si l'unité de base pour la référence 300 (qui est bien une référence et non un nombre) est le kg, il est simple de considérer que le stock en contient 50 kg et que le client en commande 30 kg ou 15 kg...
Cordialement,

[ShaiLeTroll]

Faudra savoir pour cette gestion de stock
Est-ce une gestion de stock commerciale ou une gestion de stock logistique, ce n'est pas la même granularité

Gérez-vous des UVC différentes des ULS avec la possibilité de fractionnement ou composition lors de l'étape de conditionnement ?

Mais tout ça ce n'est que de l'étude et modélisation qui ne semble pas abouti pour arriver à la phase de réalisation en Delphi
Je ne vois pas pourquoi la question a-t-elle été posé ici !