How can we improve CS-Cart?

Structure product options like Ebay, Amazon and Google

Amazon, Google, Ebay all structure Product Options differently than CSC. Their definitions & data structure are all the same (or very similar). CSC does it differently

I suggest that CSC should conform their product structure on Product Options / Option Combinations like these big guys. It would greatly reduce the complexity of getting product-option data in/out of CSC.
Product data per option such as unique SKU codes, inventory levels, pricing, discount structures, bar codes, etc..

Please also see this discussion:

Thanks in advance

264 votes
Sign in Sign in with CS-Cart
Signed in as (Sign out)
You have left! (?) (thinking…)
Olof shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in Sign in with CS-Cart
Signed in as (Sign out)
  • Adminimac (Admin, CS-Cart) commented  ·   ·  Flag as inappropriate

    Thank you for the detailed comment.
    At the moment, I have a approx vision of how this feature will work. So I will mark with + field that will be specific to combination:
    + list price,
    + sale price,
    part number (our),
    part number (brand),
    discount (user class related),
    box size,
    + image/s,
    + brand logo, (it's will have separate images set, not sure what you mean under logo)
    delivery time,
    and short sub-description for that particular product or brand.

    All other field in theory you will be able to add through schema.

  • Wisefool commented  ·   ·  Flag as inappropriate


    Firstly, can you please give us an approx. release date of v5?

    Even though I see that this feature is now planned for v5 I would like to add the following comments.

    We have been with CSC since 2.1.4 but this is a critical feature for us to continue using this platform long term. We have had two different third party versions of this feature built but with limited success.

    When you build this feature please do not shortcut on the requirements outlined below as we see we would utilise most of them.

    Our business is auto-parts, so we would have the (non-saleable) parent product carrying all of the fundamental data e.g. description/s, part numbers, meta keywords, search words etc,
    whereas the child products are the different versions products we offer our customers e.g. OEM, Used, Reconditioned, Aftermarket brand 1, Aftermarket brand 2.

    All of these are individual products with their own;
    list price,
    sale price,
    part number (our),
    part number (brand),
    discount (user class related),
    box size,
    brand logo,
    delivery time,
    and short sub-description for that particular product or brand.

    This will save our customers having to troll through multiple listings when evaluating their purchase.

  • m commented  ·   ·  Flag as inappropriate

    This would also address a number of other request on this page, including the following:

    Products Options different VAT
    Add 'list price' to options variants
    Absolute Product Option Variant/Combination Price

    These requests should be grouped together and would have much higher vote count.

  • Olof commented  ·   ·  Flag as inappropriate

    There is a related discussion in the forum. In order to keep all related information together, I hereby add the thread to this suggestion: (Page 2 at the end has relevant information!)

    Specifically, the below information I think is critical to properly understand by CSC team when they start looking at Product Option restructuring:

    ......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.

    The main points I'm trying to make:
    1. 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)

    2. 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!

    3. 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

  • BarryH commented  ·   ·  Flag as inappropriate

    I have looked at other carts that have grouped products and can see how much easier it would be to manage, especially where price and weight are increased per combination. Quantity discounting would work better also, and could even be changed per option, eg you could offer 10% off 10 or more large red widgets, but only 5% off 10 or more small red widgets.

    Olof doesn't mention max and min order quantity, quantity step and list count - these also may need to vary per product combination in reality.

    I could see the need though to have a "short" name field for the combination products so the main product page wouldn't look cluttered with long titles all virtually the same.

    Hope CS can implement this functionality, it would resolve a number of ideas posted here in one fell swoop.


  • Olof commented  ·   ·  Flag as inappropriate

    Hi Imac,

    Out of the whole list of my " Functionalities PER product variant" you manage to pick out the one of which I'm least sure of.. very good :-)

    I'm not an expert at all on SEO matters. My concern is the 'findability' on Google of each product variant on its own. And I assume (that's only an assumption on my part) that SEO tags could help.
    There's an interesting blog about the discussion whether each variant should have its own URL or use canonicals or..:

    Thanks for looking into this

  • Adminimac (Admin, CS-Cart) commented  ·   ·  Flag as inappropriate

    Why do you need SEO tags or product title, these should be taken from main product. Do not forget that combinations is still displayed on the same page of main product.

  • Olof commented  ·   ·  Flag as inappropriate

    Just wanted to add some more reasons for why this suggestion is so important to implement.

    Each product variant (= option combination in CSC) is a physical product in the real world. And therefore each product variant needs to have ALL product-related webshop functionalities. Even if you do not need to import/export.

    Functionalities PER product variant such as:
    1. Unique product code (+ barcode!)
    2. Inventory control
    3. Images
    4. Features
    5. Filters
    6. Price
    7. Different discount structures possible
    8. Different VAT calculations
    9. Shipment cost calculations (based on dimensions, weights, ...)
    10. Product title
    11. SEO tags / description
    12. Discount promotions
    13. etc....

    Note: all of these fields should be accessible both through API and CSV import/Export

Feedback and Knowledge Base