Sitecore OrderCloud Documentation

docs

Portal login

Child Products vs. Generated Variants

Published by Ashley Wilson on February 29, 2024

Products with variations are incredibly common in the commerce space.  Variations of products allow customers to choose the best size, color, material, style, or feature set for their needs.  Variations are present across every category -- clothing, electronics, appliances, housewares, athletic equipment, tools, services, and more.  OrderCloud provides two very different methods to support products with variations, and one may better suit your business needs.  Let’s take a look at Child Products and Variants so you can choose which is best for your commerce solution.  

  • Child Products operate as independent products in OrderCloud, however they have some properties that indicate their relationship to a Parent product (Product.ParentID and Product.IsParent).  Additionally, Child Products inherit information from the Parent product in specific scenarios. 

  • Variants are generated based on Specs & Options assigned to a product.  When generated, they create a matrix of variants based on every possible Spec-Option combo of the product (I.e. I have a Spec for Size with options Child and Adult, and I have a Spec for Color with options Red & Blue, I will get 4 generated Variants: Adult Red, Child Red, Adult Blue, Child Blue).  

Topic

Child Products

Variants using Specs & Options

Product IDs 

When creating Child Products, you explicitly set the ProductID for each product.  ProductIDs can be auto-generated as well if left null on Product create. 

Generated Variants will have an auto-generated VariantID based on the Spec/Option combo, however these can be overwritten to your specific VariantID.  

Product Information 

Child Products inherit information from the Parent product.  Additionally, you can overwrite the inherited information with detail specifically about the child – such as Name or Description.  Unlike Variants which are directly related to specs and spec options, there is no direct reference to which attributes make the Child a variation of the Parent; try using XP if this is needed. 

Variants can have their own Name and Description, but there is no inheritance from the primary product that they were generated from. The Spec and Option values are returned on the Variant for easy reference.  

Pricing 

Child Products inherit price from the Parent product; however, they can also have their own Price Schedule assigned, which will override the inherited price.  With their own Price Schedule, you can also set Sale Pricing, Subscription Pricing, Bundle Pricing, and min/max quantity on a Child Product. 

Variants inherit the price of the primary product they were generated from, but additional variant pricing can be controlled by Price Markups (or markdowns if a negative value is entered) on the Spec Option.  If your variations need different pricing, you have the option to set a markup type of: Amount Per Quantity, Amount Total, or Percentage on the Spec Option. 

 

Globalization 

Because Child Products can have their own price schedules, Child products have stronger globalization support as each price schedule can have a defined currency. 

The primary product for variants can have multiple price schedules with different currencies defined, however the markup types do not support reference to currencies (i.e. an Amount per Quantity markup of 5 would mean 5 USD, 5 Euro, or 5 Pesos, which all have very different value).  Percentage markup is the best way to support mark-ups on Variants for a multi-currency experience. 

Inventory 

Inventory can be set on each Child Product.  Inventory Records can also be assigned to Child Products. 

Inventory can be set on each Variant (make sure to set Product.VariantLevelTracking=true).  Inventory Records can also be assigned to Variants. 

 

Search Experience 

Child Products are returned on Product List calls, and therefore can be displayed on Product Listing pages.  They can also be hidden with a simple filter if they are not desired to be returned on Product Listing pages. 

To view Variants, you must have the primary Product ID.  This is sufficient for displaying product information on Product Detail pages, but showing Variants on Product Listing pages isn’t supported through a Product List call.  

Visibility 

Child products inherit product visibility from their Parent.  A Child Product can also be changed to Active=false to make it non-visible.  If the Parent is Active=false, all Child products will also be Active=false. 

Variants inherit product visibility from the primary product they were generated from.  A Variant can also be changed to Active=false to make it non-visible.  If the primary product is Active=false, a buyer won’t have access to the Variants, since they cannot access the Primary product. 

 

Product Generation 

You will explicitly create the Child products needed to represent your product set using POST /v1/products 

The Generate Variant endpoint (POST /v1/products/{productID}/variants/generate) will programmatically create every possible spec-option combo as a Variant. 

This is helpful if each Spec-Option combo is always an available variation in your catalog.  From the example above, if the Child Red item was not a supported variation, you would need to deactivate that Variant after generating Variants so it is not visible. 

Note that products nearing 100 variations may cause some performance issues. 

Facets 

With Child products, there is not a defining attribute for the variation.  Use XP to define those attributes, and then use that same XP to set-up Facets to build a product filtering experience.  

Specs and Options do not pass over natively to Facets.  If you’d like to use Facets to help buyers with filtering product sets, make sure to add xp on the product representing the attributes used for filtering (even if they are already Specs/Options).  Even if facets are used, a buyer will only see the Primary product in the search results.  

Other 

Child Products can have their own Specs as long as the Spec has DefinesVariant=false.  

 

So what do all of these differences mean?  Let’s review a few examples where one option may work better than the other.  

Child Products 

  • Products where all variations need to be searched and displayed in search results: Televisions are a good example of a product with variations that need to be searchable.  A common search entry for a shopper looking to purchase a TV may include the size, such as “47inch tv”.  The shopper would expect the search results to show all the 47” TV options.  This is only possible when creating a Parent Product as the TV, and Child Products representing each of the sizes available.  

  • Variations with distinct pricing: Occasionally, products have variations that have unique pricing, or get marked down at different rates.  For example, if a set of bedsheets have one variation with a surplus of stock (let’s say Twin-sized in an undesirable color), a business may want to clearance that one variation.  With Child products, the business can update the price schedule to the desired price or even use Sale Pricing to accommodate the new clearance price for that variation. 

  • Variation pricing that is unique for different Buying parties: If your product variations need to have unique pricing for different User Groups, this is very hard to accomplish using generated variants.  Separate Price Schedules can be assigned to the primary product, but the product contains the Spec Option with a defined mark-up, and that mark-up is applied across every price schedule in the same manner.  Use Child Products with their own price schedules assigned to each party to achieve this. 

Variants 

  • Products with standardized options that don’t warrant searchability: Customized greeting cards would be a good candidate for using Variants.  When creating a greeting card, you may get the option for paper type (photo paper, photo cardstock, and premium cardstock), envelope type (standard and premium), and corner shape (square, rounded, and fancy). Every greeting card order can have any combination of these three options.  Additionally, as a shopper, you probably wouldn’t want to see every combination of these options as its own product on a product listing page.  In this scenario it makes more sense to use Specs, Options and generated Variants rather than Child Products. 

  • Products that are sold in standard quantities: Perhaps a business sells their products in individual, case, and pallet amounts.  There may be a base price for the individual size, and then mark-ups for the case and pallet size. Additionally, if the product is always available in all three quantities, Variants may be a good option.   

  • Products with an add-on service: If the add on service is not sold independently, it may make sense to create a product with a Spec of “Warranty” and Options of “Include Warranty” and “Decline Warranty”, for example.  Then shoppers can choose which variation they want (with or without a Warranty) and add the variation to their cart.  As a shopper, you don’t need to see the warranty options when searching for the base product. 

 

For more information, make sure to review these articles as well: 

Child Products  

Working with Product Specs   


Still have questions?
Ask in our Community Channel

Content Powered By
Sitecore Logo

© Copyright 2024, Sitecore OrderCloud®. All rights reserved.

Contact Us
Privacy Policy
Sitecore