[quote]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.
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.
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.
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.[/quote]
I have made a table in an attempt to show how the market leaders handle the different type of products you can have in a webshop. I believe (and hope) that it can help to clear up what we are all talking about.
For example, Magento defines 6 different types of products, but ALL 6 types are based on the same building block, type 1. Here below the first 2 types:
Simple - 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.
Configurable product - A t-shirt that comes in three colors (red, white and blue) and three sizes (small, medium, large) is a configurable product. A configurable product is made up of other simple products
A very good article about the 6 types of Products: http://www.customerp…-product-types/
—
Imac, with regards to your comment:
[quote]
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.[/quote]
Yes, this is the type of product we are talking about. And no, no, no (sorry…) the optimal solution is NOT to generate option combinations!
How it should be done (in a future release of CSC) is exactly the other way around as how it is done today. The data-creation in CSC starts (not ends) with the physical end products (like Tshirt - yellow -large)
step 1: set up each individual 'option combination' (CSC current term for unique SKU products) as a Simple product. In the normal Product table. It is here where each 'Option Combination'/'Simple product' get its unique SKU code, bar code, inventory, pricing, images, discounts, etc…
It then becomes MUCH easier to interface this product data with outside parties & systems.
step 2: then create a Configurable product (Magento term) or call it Parent product (Amazon term) or call it Variable Product (WooCommerce term) or call it Group Id (Google term) or Product-with-variations (Ebay term) or whatever. This Configurable/Parent/… thing can be thought of as a non-buyable “umbrella” which connects the different Simple products. This " umbrella" is a product page in the webshop
step 3: give the end-user the choice when he lands on that Configurable/Parent/Umbrella page which options he can choice form. Usually from a drop-down menu which displays all the Simple products which fall under that particular Umbrella.
CONCLUSION
The main points I'm trying to make:
All variations of a product ('Option Combinations' in current language) should reside in the Product table. For a variety of reasons I've mentioned elsewhere (better data management and all market leaders do it)
I agree 100% that webshop visitors have a need to have drop-down menu's/tables in order to select the correct option (Imac's usage level 2) or going through some type of configuration steps (Imac's usage level 3). BUT, this is search & select functionality which should not be intertwined with the data structure!
Get rid of this current thinking & structure w.r.t. Options & Option Combinations. It is not working. Primary reason is that the current functionality is combining data structure with search & select functionality, and failing at both. Separate the data structure from the search & select functionality
I could not agree more with Olof. Product options and combinations feel like a completely separated part of Cs-Cart. The combinations make life super difficult, because of a plethora of reasons as mentioned.
For example search does not work on combinations, which is plain stupid from a customers point of view. Also I am unable to create product sets, that I absolutely need, because it's impossible to do when using combinations.
If combinations where ordinary products that could be combined under a special product (as in Magento etc.) all these problems would go away. I also feel that the internal design would be much simpler.
Now that 4.3.4 has been released, I'm 'bumping' this topic. In the hope that CSC-team will give this issue its highest development priority... :grin:
CSC data architecture w.r.t. Option/Option Combinations is not good as compared to its major competitors (Magento, Volusion, Woocommerce, etc...) and as compared with the major sites for which data sync is needed (amazon, ebay, etc...).
Please vote for it if you haven't done so. Many other uservoice suggestions can be (relatively easily) developed when this architecture change has been implemented:
I recently contacted an integration specialist company to connect CSC to an ERP/CRM. They already created integration for many other e-commerce software. They said it was next to impossible because of how variants work in CS-Cart. They advised us to move to one of the 22 other e-commerce platform that they can support.
We have reached the same conclusion. CSC is probably the best solution out there for stand-alone webshops. However, not ´ideal´ for those of us with deep and rich integration wishes.
We are now slowly, and reluctantly, preparing to move away from CSC. Deep data integrations with our ERP system is critical for us. And further down the road, syncs with Amazon and Ebay and various other 3rd party databases.
We have reached the same conclusion. CSC is probably the best solution out there for stand-alone webshops. However, not ´ideal´ for those of us with deep and rich integration wishes.
We are now slowly, and reluctantly, preparing to move away from CSC. Deep data integrations with our ERP system is critical for us. And further down the road, syncs with Amazon and Ebay and various other 3rd party databases.
It´s sad, but for us there is no other way.
Olof,
From March I plan to start developing a prototype of new Product Options architecture.
After we made and MVP we will provide a demo to discuss the final implementation of this feature.
These are all great ideas but keep in mind that even in Magento the actual use of product variants in a multi vendor setting does not work very smooth. I have used all multi vendor plug ins for Magento and they are as complicated or more complicated than CS Cart to use in a live site. uMarketplace suite is probably the best multi vendor for magento and even their implementation of configurable product is time consuming and takes some practice to get efficient using it. Hopefully this change for CS Cart multi vendor can be less time consuming and simplified. I actually don't mind the current method but I can see how it might not fish with some peoples eCommerce sites.
Products with options that are saved to the wishlist do not maintain the options selected. I even tried this in the demo store to make sure it wasn't something I was doing wrong.
For example, I selected a t-shirt, size Large, added to wishlist.
View wishlist, item is there, but when you click it to view it again, the options go back to the default selections.
One thing that is not working is letting customers buy multiple variants. If you offer socks in red, black and blue color then customers should be able to order any amount of the 3 colours. CS-Cart only allows the customer to add one color to the cart, after which the customer asked to go to cart or checkout. It should be possible for the customer to select 2 red, 1 black, 3 blue and then click add to cart. At least the webmaster should be able to set it up this way.
Cs is growing. Have to say. Improvements probably can be achieved. Also I’m reading about a need for data exchange with some erp’s. Restful is standard for such communication and major systems can interact with the de facto standard.
One thing that is not working is letting customers buy multiple variants. If you offer socks in red, black and blue color then customers should be able to order any amount of the 3 colours.
CS-Cart only allows the customer to add one color to the cart, after which the customer asked to go to cart or checkout.
It should be possible for the customer to select 2 red, 1 black, 3 blue and then click add to cart. At least the webmaster should be able to set it up this way.
I don't think we will add this to default package, unless you have some examples of famous stores with this feature.
Products with options that are saved to the wishlist do not maintain the options selected. I even tried this in the demo store to make sure it wasn't something I was doing wrong.
For example, I selected a t-shirt, size Large, added to wishlist.
View wishlist, item is there, but when you click it to view it again, the options go back to the default selections.
Hi Imac, Any update on progress you can share with us?
Can not share any news right now, except that this task is in progress. Right now we are working on technical aspect of this task, i.e. if it possible to implement this without refactoring CS-Cart completly and is there a chance we can have a backward compatibility.
