Discussion :

[bboy_lil_mak]

Bonsoir.

J'ai une petite question d'ordre générale. Je suis en train de créer une application de gestion de stock. C'est au niveau de mon MCD que je m'interroge. J'ai donc une table ARTICLE avec des champs stock actuel et stock alerte. Des que mon stock actuel est inférieur ou égal à mon stock alerte, ca m'enregistre l'article en tant que stock négatif. Pour modifier cela je lance une commande. Ma question se pose la : faut il directement relié ma table article a ma table commande ? Sachant que je souhaite commander plusieurs article dans une seule commande.

Help me thanks

[Paul TOTH]

cas classique avec 3 tables : articles, commandes et lignes_de_commande

[bboy_lil_mak]

Et ligne_de_commande correspondrait à quoi exactement ?

[Paul TOTH]

articles
-------
id nom
1  Delphi
2  C++
3  Java

commandes
-----------
id date
1  28/07/2013 
2  29/07/2013

lignes_commande
----------------- 
id commande article quantité
1  1        1       10
2  2        1       1
3  2        2       1
4  2        3       1

voici deux commandes, la première le 28/07 pour 10 delphi, la seconde le 29/07 pour 1 delphi, 1 C++ et 1 java

[Rayek]

Pour ma part je séparerai l'article et le stock car si un jour tu veux gérer la taille et la couleur tu seras obligé de créer un article par taille et par couleur.

Article : Id, Nom, etc ...
Stock : IdArticle, Qte, QteStockMini
Commande : IdCmd, Date, etc ...
LigneCmd : IdLigne, IdArticle, Qte

Et le jour ou tu as besoin de rajouter la taille et la couleur

Article : Id, Nom, etc ...
Taille : Id, Nom, etc ...
couleur : Id, Nom, Etc ...
Stock : IdArticle, IdCouleur, IdTaille, Qte, QteStockMini
Commande : IdCmd, Date, etc ...
LigneCmd : IdLigne, IdArticle, IdCouleur, IdTaille, Qte

[ShaiLeTroll]

Il y a surement autant de modèle possible que d'analyste

Surtout que tous les articles n'existent pas forcément dans toutes les tailles et coloris
Dans ce cas, utile d'avoir la table Article qui fourni le catalogue dès combinaisons existantes,
souvent à chaque combinaison est associé un code barre unique,
bien plus pratique pour les process de Picking et Packing d'avoir une référence unique non ambigüe

Modele : IdModele, Nom
Couleur : IdCouleur, Nom
Taille : IdTaille, Nom
Article : IdArticle, IdModele, IdCouleur, IdTaille, CODEBARRE, etc ...
Stock : IdStock, IdArticle, Qte, QteStockMini
Commande : IdCmd, Date, etc ...
LigneCmd : IdLigne, IdCmd, IdArticle, Qte

C'est une vision simpliste du stock qui ne prend pas en compte, les différents entrepots, la gestion des emplacements de stockage, ... important de savoir où l'on a stocké une marchandise pour pouvoir la distribuer vers d'autres entrepots ou site de vente : Gestion de la chaîne logistique \ Supply chain management

Et ligne_de_commande correspondrait à quoi exactement ?

Au final, LigneCmd n'est qu'une relation Many to Many (n-n) entre Article et Commande

[Paul TOTH]

Pour ma part je séparerai l'article et le stock car si un jour tu veux gérer la taille et la couleur tu seras obligé de créer un article par taille et par couleur.
...Et le jour ou tu as besoin de rajouter la taille et la couleur

je n'aime pas cette idée de clé multiple (article, couleur, taille), dans ce cas je préfère ajouter une table "conditionnement" par exemple qui reprend un article d'une couleur, d'une taille éventuellement en lot. Les "lignes" font alors référence à un conditionnement, exemple 5 x "10 paires de chaussettes en laines noires".

souvent à chaque combinaison est associé un code barre unique,
bien plus pratique pour les process de Picking et Packing d'avoir une référence unique non ambigüe

est-ce que tu suggères d'utiliser le code barre comme clé unique ? c'est toujours une mauvaise idée d'avoir une clé significative, l'exemple le plus flagrant, c'est que je veux saisir un article X dont le code barre est 123456, or il existe déjà un article possédant ce code. Je n'ai pas cet autre article sous la main et ne peux pas vérifier son code barre qui est manifestement faux, mais je ne peux pas saisir mon nouvelle article pour lequel je n'ai aucun doute En utilisant une clé autoincrémenté non significative je vais pouvoir saisir mon nouvel article avec le même code barre, et noter qu'il faudra modifier l'autre au plus vite.

[ShaiLeTroll]

est-ce que tu suggères d'utiliser le code barre comme clé unique ?

Le CodeBarre a juste un index unique pour avoir une DB correcte mais dans les jointures, tu utilises IdArticle
J'ai justement mis en gras-souligné les PK et juste en souligné les FK, tu noteras que CodeBarre n'est ni l'un ni l'autre
IdArticle serait d'un proche de ton IdConditionnement
Le CodeBarre c'est juste un critère de recherche !

Par contre, à un moment, le Code barre servira d'identifiant unique
lorsqu'il sera lu par un lecteur manuel utilisé par un manutentionnaire ou un scanner d'un système de tri automatisé

Ensuite le programme consulte le cataloque pour trouver le IdArticle correspondant au CodeBarre dans la table Article
A partir de la tu peux ensuite effectuer les jointures nécessaires sur les différentes tables

On voit cela tous les jours à la caisse du supermarché, le codebarre identifie l'article et le système en trouve le prix, la TVA, le libellé ...
Rien d'extraordinaire

c'est toujours une mauvaise idée d'avoir une clé significative ?

Hein ?
Je n'ai pas évoqué de clé significative, j'ai juste évoqué un code barre, et là, tu dois t'adapter au besoin du client !
Par exemple en EAN13, tu as des normes a respecter,
si le client souhaite les suivre, tu développes ton application en fonction de cela !
si le client ne s'en préoccupe pas, tu utilises l'AutoInc comme valeur du CodeBarre

D'ailleurs, le CodeBarre au sein de l'entrepot n'est pas forcément le même qu'en boutique, justement à cause du conditionnement

Pour ma part, je ne me suis jamais occupé de l'obtention du code barre,
je ne fais que l'exploiter comme un critère de recherche pour trouver l'ID au sein des différents projet de logistique d’entrepôt dans lesquels j'exploitais différents types de scanner

Dans le médical, j'ai vu pratiquer la même chose,
le code barre est un numéro unique identifiant le patient, la plupart du temps c'est un simple compteur
mais certains clients voulaient avoir une valeur compréhensible
comme yyyypppcccccc avec yyyy = année de naissance, ppp = département de naissance et cccccc un compteur remis à zéro à l'année


Tant que le client paye, tu peux lui faire ce qu'il veut, après tout ce n'est que de l'affichage et du calcul, en interne, tu utilises tes PK et FK

[SergioMaster]

je n'aime pas cette idée de clé multiple (article, couleur, taille),

je ne vois pas pourquoi (mais clé multiple ne veux pas forcément dire index primaire) ,

Jje travaille depuis longtemps dans le textile/chaussure en fait un Modèle a plusieurs Coloris et une Grille de Pointure
une association Modèle+Coloris (on dit aussi assortiment ou couleur) donne un Article pour les tailles ou pointures (36 max en chaussure) personnellement j'ai toujours utilisé un tableau plutôt que 1 record par pointure (mais là c'est un choix qui n'engage que moi)
pour ce qui est de l'EAN13 'normalisé' on sera obligé , pour utiliser au maximum la codification de mémoriser un code EAN13 pour chaque Triplet (modèle+coloris+pointure) , sinon utilisé un code barre EAN13 commençant par 2 revient à dire qu'il s'agit d'un code interne laissant beaucoup de place à l'imagination

Voici la forme que j'utilise dans ma GPAO
2MMMMMMAAAPPC ou MMMMMM= numero modele
AAA = Numero Coloris
PP = Position Pointure
et C = CheckDigit

Quant au conditionnement s'il y en a , c'est encore à part , dans tout les cas clients que j'ai eu soit ils vendaient à l'unité soit c'était en paquet de n , mais jamais les deux

[ShaiLeTroll]

soit ils vendaient à l'unité soit c'était en paquet de n , mais jamais les deux

Au pire un paquet de n avec n = 1

[SergioMaster]

Ce que je voulais dire par là , c'est que si l'article était vendu sous 2 conditionnements alors c'était tout simplement considérés comme 2 articles différents
du style : article a = 1 paire de collants
article b = 5 paires de collants (article a)
(ici je parle de collants de danse , seul cas qui s'est présenté chez mon employeur)

[Paul TOTH]

Ce que je voulais dire par là , c'est que si l'article était vendu sous 2 conditionnements alors c'était tout simplement considérés comme 2 articles différents
du style : article a = 1 paire de collants
article b = 5 paires de collants (article a)
(ici je parle de collants de danse , seul cas qui s'est présenté chez mon employeur)

c'est amusant, pour ce qui me semble le même problème tu as utilisé deux solutions différentes

un des intérêts de gérer les coloris dans le stock c'est de pouvoir proposer des collants blancs quand les noirs ne sont plus disponibles, c'est facile, c'est le même article.

mais là impossible de proposer 5 fois 1 paire au lieu d'un lot de 5 car ce n'est pas le même article sauf évidemment si un autre champ fait le lien entre les deux.

quand je dis que je n'aime pas les clés multiples, c'est parce que c'est pénible à gérer...j'affiche un article, et je veux savoir le stock, et bien je suis obligé de balader 3 champs pour avoir cette information : collants, noirs, en 38. Il est toujours plus pratique d'avoir un id unique pour identifier une information...et c'est encore plus vrai en mode web

[Andnotor]

un des intérêts de gérer les coloris dans le stock c'est de pouvoir proposer des collants blancs quand les noirs ne sont plus disponibles, c'est facile, c'est le même article.

Dans ce cas, il n'y a pas de conditionnement

[SergioMaster]

un des intérêts de gérer les coloris dans le stock c'est de pouvoir proposer des collants blancs quand les noirs ne sont plus disponibles, c'est facile, c'est le même article.

pas d'accord , c'est le même modèle même pas le même article !
j'imagine la gueule du client s'il reçoit ces collants blancs à la place des noirs

[Paul TOTH]

pas d'accord , c'est le même modèle même pas le même article !
j'imagine la gueule du client s'il reçoit ces collants blancs à la place des noirs

dans ma phrase il y a "proposer"

d'une manière générale, je trouve les sites marchants très mal foutu (bon là on est pas sur du web, mais pour moi c'est pareil, il est question d'organiser les données)...donc je demande des collants noir en taille 38, il n'y en a pas...j'aimerais savoir s'il y a en stock un article similaire. On peut supposer que la taille est importante, mais peut-être que je me satisferais d'une autre couleur, ou que s'ils sont vendus par deux, je les prendrais tout de même.

bref l'organisation des données est supposée faciliter leur exploitation