[Olof]

Hello,

This is a blatant attempt ( ) to raise awareness of a critical shortcoming w.r.t. Options & Option Combinations.

Problem:
The current architecture of Options / Option Combinations makes it (nearly) impossible:
1. to have robust interfaces with other systems when you have Option/Option Combinations. Interfaces with Ebay, Amazon, Google, but also your POS and ERP systems.
2. for CS people to develop the same webshop functionalities for Option products as for 'normal' products.

Solution:
Replace Options with Group/Child structure, same as what Ebay, Amazon, Google, Magento, Woocommerce and Volusion do.

Please vote if you agree: http://cscart.uservo...y-amazon-and-go

More information on cause & solution:
http://forum.cs-cart...__fromsearch__1

thanks in advance
Olof

[johnbol1]

YEah I agree.
I have been banging on about options being a pain for some time now. CS seem to have have started to make options more of a priority with the 4.3.1 version regards import and export etc, but more can be done.

[JackConnick]

Options need to have a product code like any other product in the store.

[Kayokoko Swimwear]

Options need to have a product code like any other product in the store.

Yes, we need to have SKU or UPC for each option and a inventory value for each of those SKU / UPC's!

[P-Pharma]

Options need to be treated the same as products. The only difference between a product and an option is that a product does not have variants, while a option is a product available in multiple variants. i.e. an option needs to have hierarchy.

The way images, inventory, SKU, for options are configured in CS-Cart leaves a lot of room for improvement. CS-Cart would be so much easier to use if options would be revamped. Currently its not done in a logical, practical way and it costs us a lot of time.

It would also be useful to be offer a function to let customers order multiple options from the same page. Currently customers can only order one option.

I am afraid that I can not vote for it, because I have posted 10 suggestions in uservoice/ideas. This excludes me from voting on any suggestions.

[imac]

Options need to have a product code like any other product in the store.

Yes, we need to have SKU or UPC for each option and a inventory value for each of those SKU / UPC's!

I don't think Options need a SKU, but combinations do need it. And actually combinations have it's SKU: http://note.io/1JWzP69

Combinations have

[imac]

Hello,

This is a blatant attempt ( ) to raise awareness of a critical shortcoming w.r.t. Options & Option Combinations.

Problem:
The current architecture of Options / Option Combinations makes it (nearly) impossible:
1. to have robust interfaces with other systems when you have Option/Option Combinations. Interfaces with Ebay, Amazon, Google, but also your POS and ERP systems.
2. for CS people to develop the same webshop functionalities for Option products as for 'normal' products.

Solution:
Replace Options with Group/Child structure, same as what Ebay, Amazon, Google, Magento, Woocommerce and Volusion do.

Please vote if you agree: http://cscart.uservo...y-amazon-and-go

More information on cause & solution:
http://forum.cs-cart...__fromsearch__1

thanks in advance
Olof

Olof, I like your activity. Keep on! And thank you for all your efforts.

We do follow all the discussions. Right now we focused primary on upgrade center & bug fixes, but in the near feature we will come back to the new features.

[P-Pharma]

I don't think Options need a SKU, but combinations do need it. And actually combinations have it's SKU: http://note.io/1JWzP69

Combinations have

Of course options need a SKU. Options have a EAN (barcode) as well. After the product option is ordered, my staff needs to go into the warehouse and pick the product option. This is done by SKU and EAN. So the packing list must contain SKU and EAN for the product option.
From your remark it seems there may be some confusion about what is needed. The word 'option' does not really describe how this is used. The word option implies that a product is offered that has several configuration options. Similar to how you can buy a car with the option 'airbag'.
While this is applicable for some companies, most companies sell product variants. For example: a bicycle in black, red or blue.
Each variant needs its own inventory, SKU, EAN, API, multiple images, etc.

Currently inventory can be managed for options, but only under combinations. This is strange because a option/variant is not a combination at all. This illustrates that its hard to figure out how illogical some of the option related functionality works. It would be really helpful if this would be revamped into a logical way that allows us to quickly manage options.

[Flow]

Voted! It's about time options get a makeover. After so many years with cs-cart the options and combinations still confuse me and they make importing / exporting as well as connecting cs-cart to 3rd party software next to impossible.

[Kayokoko Swimwear]

I don't think Options need a SKU, but combinations do need it. And actually combinations have it's SKU: http://note.io/1JWzP69

Combinations have

Imac - combinations are insane waste of time. I can't use this cause it would take me 100 years to setup my products. It needs to be simple:

Tops
Small
SKU/UPC/EAN $price #quantity on hand
Medium
SKU/UPC/EAN $price #quantity on hand
Large
SKU/UPC/EAN $price #quantity on hand

etc.....

[Olof]

I don't think Options need a SKU, but combinations do need it. And actually combinations have it's SKU: http://note.io/1JWzP69

Combinations have

Hi Imac, my assumptions is that you posted this info as a friendly support help on what is possible now. And that it is not your solution to my posted Options-problem. I assume this because I know you have read and replied on my Options-problem & Uservoice elsewhere. But this reply of yours could potentially cause misunderstanding with other readers of this discussion thread.

Olof, I like your activity. Keep on! And thank you for all your efforts.

We do follow all the discussions. Right now we focused primary on upgrade center & bug fixes, but in the near feature we will come back to the new features.

Thanks. When you and your development team get around to it, please have them take a long & hard look at how Product Variants (= Options/Option Combinations) are structured at Ebay, Amazon, Google, Magento, Woocommerce and Volusion. They are all very, very similar in the underlying architecture.

And then get rid of Options/Option Combinations and follow the leaders.

I'm sure it's a major undertaking for you guys but at the end it would fix a large number of current issues and makes future feature-development w.r.t. product variants soooo much easier

[imac]

Imac - combinations are insane waste of time. I can't use this cause it would take me 100 years to setup my products. It needs to be simple:

Tops
Small
SKU/UPC/EAN $price #quantity on hand
Medium
SKU/UPC/EAN $price #quantity on hand
Large
SKU/UPC/EAN $price #quantity on hand

etc.....

yes, I understand this, in cases you have only one option like size in your case, there should be the ability to easily create combinations - actually it should be combination right after you create the option.
At the moment it's a bit overwhelm process.

[imac]

Hi Imac, my assumptions is that you posted this info as a friendly support help on what is possible now. And that it is not your solution to my posted Options-problem. I assume this because I know you have read and replied on my Options-problem & Uservoice elsewhere. But this reply of yours could potentially cause misunderstanding with other readers of this discussion thread.

That was my answer to particular post of Kayokoko Swimwear - because actually in CS-Cart 4.x.x. there is an ability to set a separate SKU for each combination (or one can call it option).

Thanks. When you and your development team get around to it, please have them take a long & hard look at how Product Variants (= Options/Option Combinations) are structured at Ebay, Amazon, Google, Magento, Woocommerce and Volusion. They are all very, very similar in the underlying architecture.

And then get rid of Options/Option Combinations and follow the leaders.

I'm sure it's a major undertaking for you guys but at the end it would fix a large number of current issues and makes future feature-development w.r.t. product variants soooo much easier

We will do this.

[imac]

From your remark it seems there may be some confusion about what is needed. The word 'option' does not really describe how this is used. The word option implies that a product is offered that has several configuration options. Similar to how you can buy a car with the option 'airbag'.

yes, P-Pharma looks like the "option" word is the source of the misunderstanding.
In CS-Cart "option" term is used in the same meaning as product property like "color" or "size". Whereas "combination" is used in the meaning of a separate product with its own inventory and SKU - just like you said about the option.

I'm just trying to stick to CS-Cart terms.

So I have questions for you guys, can you give me your thoughts about terms currently used in CS-Cart:
"option" - as I mentioned earlier some kind of product property, each product can have many options like "Color" "Size" "Material" "Gift wrap" etc (http://note.io/1BsigYw)- do you think that we should rename this to something more clear like attribute?

"combination" - this is a set of product options that in fact appears as a single product. (http://note.io/1BsioaE) e.g. if we have a hat in two sizes "big" and "small" and in two colors for each size "black" and "white" than there will be 4 combinations of the hat.
"black & small" hat
"white & small" hat
"black & big" hat
"white & big" hat
same question here - do you think "combination" term is ok here?


I would like to describe the options architecture in v4.x.x so when you advise to change something please keep in mind that CS-Cart users can use any of the described cases.
In common CS-Cart options functionality has 3 levels of possible usage.
1) When your product is tracked without options. In this case option can be a gift wrap checkbox, or a input - where customer can place some greetings.
In this case you just create options and maybe add price modifiers.

2) Commonly used. When you have several options that affect product inventory and probably have different SKU. e.g. t-shirt in different color and size, glasses in different size etc. - Thats is what this topic about.
In this case you should generate option combinations in order to change SKU, amount and image for each of the separate product.

3) When you use options to configure your product. Common examples here is furniture or car parts. In most cases sequential options are used. E.g. I sell car engines and most probably I will configure the product the following way
option 1: Brand
option 2: Year
option 3: Model
Option exceptions widely used here to enable/disable some of the combinations.

[Kayokoko Swimwear]

don't think were still on the same page...

I have this structure:

Top Size (option)
No Top (variant)
Small (variant) UPC: 123456789 Cost: $98 Quantity On Hand: 7
Medium (variant) UPC: 478479393 Cost: $98 Quantity On Hand: 8
Large (variant) UPC: 982903423 Cost: $98 Quantity On Hand: 1

Bottom Size (option):
No Top (variant)
Small (variant) UPC: 374589245 Cost: $50 Quantity On Hand: 2
Medium (variant) UPC: 847320472 Cost: $50 Quantity On Hand: 1
Large (variant) UPC: 234250634 Cost: $50 Quantity On Hand: 0

My customers can buy just a top or just a bottom. or a small top and m bottom or literally hundreds of different "combinations".

This simply doesn't work for us customers who operate this way. The simple answer is to scrap combinations and build the system to handle inventory by option and variant.

this way you can add a feature that says... only 1 item left in this size. When option QTY = 0 then disable the option etc... powerful selling tools!

Not easy, I know but the combinations don't work for most of your customer base.

[Kayokoko Swimwear]

in other words each variant is unique and identifiable and should have an inventory value associated with it!

[P-Pharma]

Hi imac,

I really appreciate your openness to feedback. To come to your questions: I think the CS-Cart definitions should be changed to use words by their true English meaning.
The word 'option' is normally used for something optional, additional, or even an attribute. An enhancement the customer can choose to add to the product.
'Product Varieties' or 'Product Variant' is more fitting to describe this function.

A combination is a combination of multiple products. CS-Cart's use of this term is very confusing.
In fact after using CS-Cart for all this time I never understood what a combination is supposed to do, until you just explained it.
You should not use the word 'combination' to describe variant configuration.

In your example above you mention 'gift wrap'. This is a clear example of a 'product attribute' but its certainly not a 'product variety'. Its something that can be added to the product. Similar to how you can add insurance to an order. This is how the word 'option' should be used.
Its a mistake to combine 'product variations' like size and additional options like gift wrapping. This causes a lot of confusion and problems.

I find the way it is now and the functions you describe very confusing. I see how it works, but it makes very little sense when you start working with it.
For example: we only have products and product variations in CS-Cart.
We have added no combinations at all. Yet we need to use combinations.
We do have some products with multiple variation types. for example a product that is available in different sizes and also in different color. But its simply too confusing in CS-Cart and also does not offer a good presentation for product option, so we have chosen to enter different sizes as separate products.

[johnbol1]

Imac, I too appreciate your openness and willing to accept shortcomings.

yes, P-Pharma looks like the "option" word is the source of the misunderstanding.
I'm just trying to stick to CS-Cart terms.

Agreed

in other words each variant is unique and identifiable and should have an inventory value associated with it!

YEP

This simply doesn't work for us customers who operate this way. The simple answer is to scrap combinations and build the system to handle inventory by option and variant.

agreed

EG you sell T shirts

BASIC Adidas T shirt is add001

Adidas T shirt yellow Small is Ad001YelSm "option 1"
Adidas T shirt yellow Med is Ad001Yelmed "option 2"
Adidas T shirt yellow Lge is Ad001Yellge "option 3"
Adidas T shirt blue Small is Ad001BLUSm "option 4"
Adidas T shirt blue Med is Ad001BLUmed "option 5"
Adidas T shirt blue Lge is Ad001BLUlge "option 6"

This is how all wholesalers/manufacturers list there products and spreadsheets for export/import to customer databases/websites. Every single option or variant is distinct in its own right for stock/sales.
At the moment controlling all this via combinations is very hard, and also puts us off from using it too.

[JackConnick]

I agree with the above.

The other issue is that the "combinations" create a new main sku for the same product. We want one main prduct with variants that each have a SKU of their own, not an entire new one. We'd end up with hundreds if not thousands of skus. This is impossible for us to pull into Quickbooks as a group item.

We sell packages and have different lights/lengths of arms, housings etc in each. If we have one main product and then have options that have their own SKU then we can build the product and apply the varients in Quickbooks. Combinations are useless.

We are trying to figure this out with CartSpan to import orders into Quickbooks and it's impossible to map the group parts otherwise.

Magneto and other carts work this way.

Jack

[Olof]

yes, P-Pharma looks like the "option" word is the source of the misunderstanding.
In CS-Cart "option" term is used in the same meaning as product property like "color" or "size". Whereas "combination" is used in the meaning of a separate product with its own inventory and SKU - just like you said about the option.

I'm just trying to stick to CS-Cart terms.

So I have questions for you guys, can you give me your thoughts about terms currently used in CS-Cart:
"option" - as I mentioned earlier some kind of product property, each product can have many options like "Color" "Size" "Material" "Gift wrap" etc (http://note.io/1BsigYw)- do you think that we should rename this to something more clear like attribute?

"combination" - this is a set of product options that in fact appears as a single product. (http://note.io/1BsioaE) e.g. if we have a hat in two sizes "big" and "small" and in two colors for each size "black" and "white" than there will be 4 combinations of the hat.
"black & small" hat
"white & small" hat
"black & big" hat
"white & big" hat
same question here - do you think "combination" term is ok here?

Hi Imac, also many thanks from me that you are opening yourself up for feedback & input. I wish all software companies would behave like that!

Your Label questions are valid, but are frustratingly difficult to answer. Allow me to respond at 2 levels

Level 1. Naming conventions.
Their appears no standard naming convention, I went back and read up on it at Magento, Amazon, Ebay, Google and Woocommerce. However, the words 'Options' and 'Variations' are the 2 words that are used the most to describe physical differences of the same product:

Magento: "A simple product in Magento is just that: simple physical product that you ship. There are no options like size or color that the end user can pick during the order."

WooCommerce: "Simple products have one SKU, are shipped, and have no variations/options."

Amazon: "Similar products that vary according to defined variation theme, such as color or size, share a parent/child relationship"

Ebay: " ...For these categories, eBay allows up to 5 variation options to be specified with a maximum of 30 values each, for a maximum of 120 combinations..."

Level 2: Architecture
To be honest, I really don't care if you rename the current CSC labels 'Options' and/or 'Option Combinations' to something else. It's the wrong subject to discuss. You / CS team needs to let go of trying to find a solution within the current architecture of Option/Option Combinations.