Variants

Variants are products which are essentially identical except for certain key variant dimensions such as colour, size, etc.

For example, if you’re a retailer selling t-shirts you may have the same t-shirt in:

• 3 different sizes (Small, Medium, Large)
• 3 different colours (Black, White, Blue).

This corresponds to 9 unique combinations:

• Small, Black
• Medium, Black
• Large, Black
• Small, White
• Medium, White
• Large, White
• Small, Blue
• Medium, Blue
• Large, Blue

Instead of creating each of these as separate products you can create them as variants of a master product. This can be a time-saver, because often many of the properties are identical across the variants, e.g. the manufacturer, the VAT group, the description, etc. Instead of creating and maintaining the same information in 9 different places, you can add it to a master product and have each variant inherit the values.

There are two types of variants in Dynamicweb:

• Simple variants are identical with each other in all respects except the variant dimensions (colour, size)
• Extended variants have their own database entry, and as a result can have different values in (standard and custom) product fields, depending on the Fields-settings

In almost all scenarios extended variants are preferable; as soon as you have a variant, you will presumably have a separate and limited stock available for it. The exception could be variants which are built to order, or scenarios where each variant is in fact a type of configuration of the main product (but then you’re stretching the definition of ‘variant’ quite a bit).

In order to create variants you must first create variant groups – e.g. color – with variant options such as black, white, and blue.

A variant group is a category – e.g. Colour or Size – containing variant options, such as red, blue, and black or small, medium, and large. Variant groups are created on an ad-hoc basis, depending on what’s needed on the solution in question. On solutions integrating with a remote system they may also be created during import.

To create a new variant group manually:

• Go to Settings > Ecommerce > Product catalog > Variants
• Click New variant group to open the variant group view (Figure 2.1).
• Provide a name and optionally a description for the variant group

Figure 2.1 A variant group

It is from the variant group view that you create and configure variant options:

• Press Click here to add a new row to open the variant option view (Figure 2.2)
• Supply a Name – this is the name which will be used in frontend for the variant option.
• Optionally add:
  • A color
  • One or more images – e.g. an icon or something else. Only the Image Large value is available in frontend when using ViewModels
• Click OK

Figure 2.2 Creating a variant option

You can also extend variant options with custom properties – a kind of custom field. All property fields are simple text fields, and are shown below the images-fields in the variant option view.

Below, in the Relations section, you can see a list of all the products where the variant group is used (Figure 2.3).

Figure 2.3 Vatiant relations

Variants can be created manually or (in more advanced scenarios) as a part of an integration process.

To create variants manually:

• Go to Ecommerce or PIM and open a product details view
• Click Variants in the ribbon bar to open the variants view (Figure 4.1)

Figure 4.1 Creating product variants

Add variant groups and combinations:

• In the Group table use the green plus to add one or more variant groups to the product
• In the Variant combinations table:
  • Add a row per variant you want to create
  • Select a unique combination of variant options
  • Click OK
• Click Save as Extended or Save as Simple as appropriate

After a set of variant options have been created, you can use the Default (primary) variant for main product to select a default variant to show when the main product is accessed from frontend. If a variant has been extended, its icon will become colored in the Open variant column.

Variants created manually are sometimes created as simple variants – which means that don't have a separate database entry – but it’s easy to extend them:

1. Open a main product and click Variants in the ribbon bar
2. Click the Open variant icon – this opens a detail view of the variant
3. Save

Once a variant has been extended it can have values in product fields different from the values on the master product - if allowed by the Fields settings. A product with variants is recognizable in product lists by the small caret-icon on the left side of the product list row (Figure 5.1).

Figure 5.1 Extending variants

Click the icon to fold out a list of the variants (Figure 5.2) – extended variants have separate field values and a big black circle in the variant column, whereas simple variants are listed only with their variant options and a small black circle in the variant column.

In the variants view of a product, extended variants have a colored Open variant icon, whereas the icons for simple variants are greyed out.

Figure 5.2 The variants for a product are listed below the main product

How you control stock on variants differs slightly depending on the type of variant used and other factors:

• For simple variants stock is set on the main product and that’s that – simple variants do not have their own stock field.
• For extended variants stock is set on the main product and each variant individually
• For extended variants, if a default variant is selected, the stock field on the main product is read-only and contains the total sum of stock across all variants.

On integrated solutions, stock is almost always controlled by a remote system and imported to each variant separately.

Broadly speaking only two scenarios for handling variants in frontend make sense:

1. The main product is published to the product list – then, on the details page a variant selector is rendered, allowing the customer to add a specific variant to cart
2. Each variant is published to the product list – the main product is not published, and you cannot from frontend see that the published product is a variant, it is simply a product in the product list

The second scenario is sometimes referred to as a product family setup, because each variant is in fact treated as a separate product but only inherits select values from a master product, e.g. manufacturer details, various assets, and so on.

When you’re implementing scenario 1, the easiest way to exclude variants  is probably to at the query level, where you can simply check that the VariantID field is empty. This prevents all variants from being included in the list of products returned by the query.

When you’re implementing scenario 2 you must go about things in a slightly different way:

• First, you use the show in product list checkbox on the product families. You should check this on all variants but leave it unchecked on the master
• In the query used to publish product in frontend, add an expression checking if the calculated field Include Master/Variant in list is set to true – this field does the following:
  • If product is a master without extended variants it is published
  • If product is a master with extended variants with show in product list not set it is not published, but all variants with show in product list checked are
  • If product is a master with extended variants where no variant has show in product list set, the master product is published (and the variants are not)

Please note that since show in product list is used, this scenario is only supported via Dynamicweb PIM or on integrated solutions where the product family logic is handled in a remote system.

For integration purposes, please note that extended variants have their own database entries.

These are the database tables associated with variants: