How do you handle the estore, one item with different variations?

blackhorse

For example, if the estore sell the t-shirt.

the t-shirt, online code is t101.

And the t-shirt has several options, "red", "white", "blue".

There will be several approaches to handle it.

1) we will treat the t-shirt as one item, all there variations will use the same online code - t101. when shopper buy it, they pick up t101, plus, they will need to pick up the color variations. I saw many big department stores online shop use this approach.

2) we will treat the t-shirt every variation as individual item, say the online codes will be t101-1, t101-2, t101-3. This way, every individual item will have a 1-1 relationship with the online code. But will this approach require us to input the product three times of the similiar item? we may use a code (group code), you input the group information once, and t101-1, t101-2, t101-3 will all get the same information from the group if they have the same group code.

How you handle this? How the off shelf open souce systems such as zen cart, oscommerce handle this?

Thanks!

etully

I am having the same question and I'd really like to hear from one of our experts on this. A client is asking me to handle clothing. A certain pair of shoes comes in 8 sizes (mens 5-13) and four widths. I'm sure it wouldn't be hard to imagine a product with 10 sizes, 10 widths, and 10 colors. That's 1000 SKU's. If I have 10,000 products (which is not unreasonable), I don't want to have to do 1000 SKU's for each product. (Even with automated entry in the database, that's making my database 1000 times bigger than it has to be and much much slower to search through. And I'd need bigger disk drives.)

But if I don't do it as individual SKU's, how do I track inventory and manage stock levels without (10,000 products X 1000 variations) in the database? That's 10 million database records for a measly 10,000 products. There has to be a better way.

blackhorse

They will have different prices, right?

I think you have to treat them as different products using "product_id"+"options_id", to track the inventory and to assign different price to the variations.

If the clothing is your major or only inventory. And most of your products will have this kind options. Then it will be easy to make the decision.

I did it in another project.

For example, as usual, your product database will have tables of "product_categories", "products"

and the "products" will have the price and inventory fields.

But in your case,

You will have

"product_categories", "products", "options", "option_categories", "price_and_inventory"

the changes are

1) "products" will not hold the price, inventory information. "price_and_inventory" will hold the price and inventory information identify by "products_id" and "options_id".

2) "options_categories" table will hold the options categories you will use
id name
1 size
2 width
3 color
4 ..

3) "options" table will have fields
id, options_cateories_id, product_id, options_name
1, 1, 101, size 1

Meaning, product 101, the option is for the size and it is "size 1".

And in all your estore codes, in the past, where you use the product_id, now you will use "product_id" and "options_id" together to identify the product.

My current project is we use the same price, we don't have to track the inventory, then do I still need this kind approach? The client want it to be simple. That is what I am debating now.
How zen-cart or oscommerce handle this? anyone know?

MarkR

blackhorse wrote:
How you handle this? How the off shelf open souce systems such as zen cart, oscommerce handle this?

Very badly.

Because they haven't really been thought out properly.

Oscommerce doesn't even have the concept of storing a SKU, and only stores the manufacturer's code instead (which in most cases is not a SKU).

It certainly doesn't record stock levels per variant, doesn't give you any ability to control variants and has a crappy UI for setting them up.

Our online shop does not have variants, for this precise reason.

If you're making a specific shop, then normally you'll find that the merchant uses a fixed scheme to produce a variant SKU from the base SKU and variation info - e.g. could be adding -S -M or -L for small/med/large.

Otherwise, you'll need a complicated system allowing you to look up an individual variant based on its variables.

Then you'll need to store the SKU, price, stock aganist that variant rather than anything else and it all gets a bit complicated. But if your client is prepared to pay, fair enough.

Mark