2010-10-15 12 views
0

En supposant une structure de schéma en tant que telle.Méthode optimale de stockage des unités de quantité pour les articles en stock

----------------------------------------- 
Stock (ID, Description, blah blah) 
----------------------------------------- 
StockBarcode (ID, StockID, Barcode, Price, blah blah) 
----------------------------------------- 

Quelle est la manière optimale de stocker des unités de mesure pour vos articles en stock? Étant donné que le prix StockBarcode peut être pour 1 article, pour 10 articles, pour 10 grammes ou pour 10 livres?

Stock à StockBarcode est une relation un à plusieurs. (Bien que je suis sûr que vous na pas besoin de moi vous dire que)

cheers :)

+0

Merci pour les réponses à ce jour. Un code à barres trop élaboré serait spécifique à une UDM car vous ne voulez pas que votre utilisateur entre une UDM au moment de l'entrée. (En outre, vous n'avez pas besoin de 2 étant donné que l'UOM doit avoir des codes-barres différents) En ce qui concerne l'utilisation du SKU, vous ne savez pas si cela fonctionnerait. Imaginez un scénario où vous recevrez un paquet de 50 crayons, tous les crayons contiendraient le même SKU mais vous pourriez les vendre individuellement et en paquets de 5. (Cela ne fonctionne que si votre fournisseur les fournit dans les différentes QTÉ) –

Répondre

3

J'ajouterez Qty et UOMID colonnes à la table de StockBarcode, puis une nouvelle table comme

StockUOM (ID, Description) 
+0

était dans le sens de ce que je pensais. –

+0

+1 J'ajouterais aussi un facteur de conversion à la table StockUOM, de sorte que (par exemple) Les kilogrammes pourraient être convertis en grammes en multipliant par 1000, ou les paquets de 5 convertis en singles en multipliant par 5. (De toute évidence, les grammes ne pas être converti en paquets de 5!) –

0

Si Je comprends correctement votre tableau de stock, il se compose des produits que vous stockez à vendre.

Une option à considérer est que, au lieu de stocker des données, vous devriez peut-être envisager de garder les données en fonction de ce que dans le jargon de stock, est appelé SKU (stock keeping unit) Information.

Chaque SKU lui-même peut être composé de plus d'un article, mais comme il ne peut être vendu de cette façon, vous n'avez pas à vous soucier de ces détails dans la plupart des scénarios. Les détails comme le prix, etc. sont toutes les propriétés qui sont ensuite associées au SKU. Par exemple: Si un produit dit «bière» peut être vendu individuellement/6 paquets/12 paquets, il est associé à 3 SKU.

Ensuite, vous avez des relations:

Products --> SKU's which is 1:many 

SKU --> StockBarCode which is 1:1 (en supposant que vous avez le même code à barres pour toutes les unités du même SKU - sinon il peut être 1: Beaucoup aussi)

+0

@Maxim Gershkovich - Je vois le point que vous essayez de faire dans votre commentaire ci-dessus et c'est un point valide. En y réfléchissant un peu plus, SKU serait défini en fonction de la façon dont vous vendez vos produits plutôt que de la façon dont vous les recevez des fournisseurs. Cependant, je vois toujours votre point que si le POS a une option pour ouvrir un paquet de 5 crayons et le vendre individuellement, cela signifierait mettre à jour l'information sku chaque fois qu'il fait quelque chose comme ça, ce qui serait encombrant! :-) – InSane

0

Existe-t-il un StockBarcode unique pour chaque UOM? Par exemple, y a-t-il un code à barres pour les grammes, un code à barres pour les livres et un code à barres pour les articles individuels? Si oui, la solution d'Andrew fonctionnera. Si ce n'est pas le cas, vous devrez créer une autre table contenant le StockID, la Qté et l'UOMID. Lorsque vous numérisez le code-barres, vous devez entrer dans quel UOM vous recherchez. Ensuite, le logiciel peut mettre à jour la table StockCount en fonction de l'élément analysé. Cela peut être une bonne solution de repli si vos articles n'ont pas plus d'un code à barres et que vous stockez plus d'un UDM (commun).

4

Vous pouvez envisager de placer une colonne UOM supplémentaire sur TOUTES les tables où se trouvent les champs Qty et une colonne Currency supplémentaire sur toutes les colonnes money.

TOUS les écrans d'entrée doivent demander Qté et UDM.

table Item - ajouter l'inventaire/Stockage UOM, Achats/Recevoir UOM, Prix UOM, Expédition/Envoyer UOM, production UOM, composants colonnes UOM

nouvelle table UOM - ID, Abbrev., Description, regionId, UOMTypeID

nouvelle table UOMRegion - ID, Code, Description (exemple des données - 1, Royaume-Uni, Royaume-Uni, 2, aux États-Unis, États-Unis, 3, INT, International)

nouvelle table de UOMType - ID, code, description, DefaultUOMID (exemple données - 1, V, Volume 15; 2, A, Superficie, 45; 3, W, poids, 32; etc.)

nouvelle table UOMConversionFactor - ID, FromUOMID, ToUOMID, Conv ersionFactor (données d'exemple - 1, 1, 1, 1; 2, 1, 3, 0,026021066655565; 3, 3, 1, 38,430399999999000)

(notes - Conversion de UOM à même UOM est le 1er mai mettre en table ou pas Chaque disque que j'ai habituellement une colonne implicite FromQty qui est toujours 1. Marque. vous ConversionFactor permet un très grand nombre si les chiffres définitifs se révèlent plus précis lorsque la grande quantité sont impliqués)

pensées - 1) certains UOM ne sont pas assez spécifiques tels que « tonneau » (il y a un baril de marchandises sèches États-Unis, un Baril américain pour les canneberges, baril fluide américain, UK un baril de bière, baril de bière américain, baril de pétrole, etc.), 2) UOM est affectée par région si vous vous inquiétez d'un stagiaire demande officielle (c.-à-d. 3) Je peux recevoir une caricature de l'article X, la stocker dans des palettes et l'expédier dans chacune d'elles. 4) les articles "kit" ou "build" peuvent être des matières premières dans l'UOM plus divers composants dans des UOM différentes qui aboutissent finalement à un produit final dans une UOM différente.