Sign In
8
What do Amazon, Ebay, Google, Magento, Woocommerce, Volusion, etc.. have in common?
They all define product variations (=options) the same way. CSC does not, which creates big headaches.
See my 2nd post in this thread for more details
Benefits if CSC changes:
1. MUCH easier integration with Amazon, Ebay, Google and with 3rd party ERP / inventory / accounting systems!
2. MUCH more pricing & discount functionalities can be had PER variant, such as own discount structures, price tables, wholesale pricing, etc...
3. Basically all webshop product-functionalities can become available for each variant.
[end Edit]
-----------------------------------------------------------------------------------------------------------------------------------------
Dear CSC,
Your Option & Option Combinations structure are not working optimally. And I (humbly) believe it's a dead end in terms of future road map. I'm sorry this is a long post, but please read it carefully.
Thanks
Request
Please create the possibilities of what other webshop platforms have called 'Grouped items' , 'Simple items' and / or 'Child items' in order to deal with variants & options. Basically, it means that regardless of the type of item, all manifestations of an item (=SKU) resides in one product table.
Grouped items = those products with options/variants
Simple item = those products without any options. Each option/variant of a Grouped item is a simple item in of itself. A simple item can be sold like this, or only be visible under a grouped item
Example: one physical SKU is ShirtXYB-Yellow-Large. This would be called a simple product. Many variations of this SKU all come together under the grouped product called 'ShirtXYB'
For more information, see how others have implemented this:
Magento: http://www.customerp...-product-types/
Woocommerce: http://www.modernmar...in-woocommerce/
Volusion: http://support.volus...cial%20Settings
Why is current CSC Options & Combinations not optimal:
It creates 2 product tables instead of one. One for products without any options (= 'simple' products) and one for those products with options/variants (= 'grouped' products).
This creates all kinds of hassles in data management AND creates all kinds of development requests to you as users want to have the same functionality for Products also available to Options Variants.
Moving to a Grouped & Child structure would eliminate these problems.
Hassles in data management
1. When exporting/importing you have to export/import 2 files instead of one (Products & Product Combinations)
2. When trying to sync inventory & master data with outside databases (ERP, customer database, ..) it is very complicated as certain Product ID items sit in export/import file A, other Product ID items sit in export/import file B
3. Remember that in most other systems/databases, each SKU has its own full record in that database. So Shirt-yellow-large is one 1 SKU is 1 'Simple' item.
4. Various export fields are already very complicated to read/understand/manage in Excel. Field 'Options' for example. This field will only get more complicated as you develop more functionalities for Options/Variants as per user requests.
Increasing development requests
1. As you can read on the forum, many of us users want to have more and more functionalities build into the variants/options/option combinations. Things such as their own discount structures, price tables, images, wholesale pricing, etc...
These requests are logical, because most of us (from an inventory, erp and sku perspective) view each Option/Variant as its own physical product!
2. I believe it's crazy trying to keep 2 product tables development right next to each other. No wonder that the functionalities of Options/Variants lags very much behind to the normal Products.
