If you make UPCs for your products, then you probably already know the answer.  The retail industry requires each product to have its own UPC and product ID/color/size.  One 205-liter product is considered different from a 198-liter version of the same product, thus they should be treated as two products -- two UPCs, two product IDs, etc.  You see the same thing in supermarkets: an individual roll of toilet paper and a 6-pack of the same toilet get two different UPC barcode on their packaging.  

So your Access database needs to be set up to accommodate that.  You can have one product table that stores every product, whether it is a pack, bulk, or an individual item.  You can have a field that specifies the "unit of measure" of a product: box, roll, pallet, carton, etc.  An individual item is called an "each", I believe.  Every product needs an unique product ID, as required by database "normalization" as well as the industry you work in.

I worked in wholesale and retail in my old job and we dealt with this all the time.  If we sell a pack of 6 garments, then the pack itself gets a UPC and product#, and each of the 6 garments also gets its own UPC and product#.  Any configuration of things that is to be sold on its own needs its own UPC, product#, etc.  And every one of these products is entered as a separate record in the product table.  

Sometimes our clients would demand a unique set of products just for them -- instead of the standard 6-pack garment, they want 12- or 18-pack.  And we have create a new product just for them -- new product ID in Access, new UPC, everything.

This is not an easy concept to build into a database. I cover it in detail in Access Developer 42. I do have a TechHelp video coming out on the subject soon though as a lot of people ask about it. Stay tuned.

Richard add me as a +1 for that video!

I'm still tuned and waiting for this helpehch video.

Hello Richard and everyone in this site,
I watched the developer lv 1, 16, 23 and 42
But again after I started to design my tables, I stuck in problem: Here is the problem...
Products can be sale with pack and without pack each one has it's own price, but both in the same stock (inventory) only the delivery method is different, each one of those delivery method has its price.
Where should I put the price and where should I put the QtyOnHand.
Option table was: ProductID, OptionID, Category, Pack, PackSize ==== here I can put the OtyOnHand but can not put the price.  
But If I build it as: ProductID, OptionID, Category, Pack, PackSiez, DeliveryMethod ==== Here I can put the price but not the QtyOnHand.

Please help

In my old job, delivery methods (and charges) are stored in the order table, not the product table.  The order as a whole is usually what determines how it should be shipped, not the individual products.  For instance, you may ship 1 unit of Product A differently from shipping 1000 units of it.  You may ship a box containing Product A, B, C differently from how you ship a box of Product B, C, D.  If you are in wholesale, sometimes the customers even dictate (require) how you ship and pack.  Regarding shipping charges, our order table stored only an estimate of the shipping charge.  When the order was actually weighed and the actual shipping charge calculated, the actual charge would be stored in the invoice table, to be billed to the customer.  Regarding product prices, our product table only stored suggested retail prices.  The actual selling prices were, again, stored in orders, when customers placed them.  On invoices, the prices might change yet again because some customers would get a discount if they paid within an agreed-upon period.  In short, our prices were stored in THREE tables (product, order, invoice -- all could be different), and shipping charges in two tables.  My whole point of this is that how and where you place these data can be (very) flexible, largely determined by your business needs.  If you can't place certain data the way you like, that's probably the wrong way because it doesn't fit your business needs, and you need to find the right one that does.

Kevin brings up some very good points. To put this into your perspective, you might have one of your lubricants that you package as a single-use item as well as a 5L bucket or a 100L drum. Same product - different packaging.

To illustrate one possibility of how this might be approached, take a look at the Chef's Kitchen Helper. Richard takes this TechHelp even further in the Access Developer 19 course.

Right... it's all about the SKU, not the product itself. Take AAA batteries. Same product... different SKUs for single, 2-pack, 4-pack, 16-pack, etc.

Access Developer 29 might also help you. In that class I show you how to take multiple components and turn them into a finished product for resale (SKU). The example I use is computer parts. You buy hard drives, motherboards, memory, etc. as individual components and then you BUILD a computer for resale. Same would work with your lubricants and such.

Okay,,
You mentioned AD29 and Scott mentioned AD19 I bought both of them and I wish to stop annoying you with more question about this case ....
Anyhow I'm still waiting for the HelpTech video you promised us with

Give me any special badge for this question .... lol

It's on the (very long) list.