Product Variants is new way of specifying how different product properties such as size and colour can be combined to give different supplier SKUs.

In the past, dealing with different product combination SKUs properly was only possible using one of the following limited methods:

  • A separate CPP product for each combination
  • Using the basic API options for SKU formatting and concatenation

Going forward it is recommended that the above methods are avoided and product variants used wherever possible instead.

Note CPP v1 does not support product variants. It will only be possible to see and set them in v2 (basic prototype available by September).

An Example

PF Concept product 33S05 (CPP ID 1415489) is a T-shirt:

https://g3d-app.com/s/app/acp3_2/en_GB/default.html#p=1416664&r=2d-canvas&guid=99999&_usePs=1

It has several available colours (handled using aspect options) as well as several sizes.

Each combination has a SKU which would have been difficult to reproduce using the older methods.

However because of product variants, the SKU can simply be defined for each combination.

Colour (Aspect Option 1) Size (Attribute 1) Variant SKU
White 104 33S05011
Dark Red 104 33S05281
White 116 33S05012
Dark Red 116 33S05282
etc…    

Note The variant SKU is specified in full, even if it contains the base SKU.

Which Things Make Up a Variant

Currently, a product variant can be specified as a combination of the following things:

  • Aspect Option 1
  • Aspect Option 2
  • Attribute 1
  • Attribute 2
  • Print Size

Personalisation Apps Order Flow

When a user creates a print job in a personalisation app for a product using variants, the active variant is saved along with all of the other details such as text and image details.

The active variant is determined automatically by the app based on the selections that have been made by the user.

Note Product state must be enabled when using product variants. If the user tries to add to cart without product state enabled, OMS will not be able to determine the correct SKU.

The variant SKU will then be passed back to the website via an additional field in the callback data, variant_sku. The base SKU will still be available in the sku field.

When an order is subsequently sent from the website to OMS via the order API, OMS will automatically use the correct variant SKU (only if Override Incoming SKU is enabled).

Retailer Integration Order Flow

Retailer integrations are able to detect that a product variant SKU has been provided and will work backwards from the variant to determine all of the relevant attributes that need to be applied to the item.

Variant SKUs can be mapped in the same way as normal SKUs.

To prevent any issues with existing integrations, product variants must be explicitly enabled in the integration’s settings (Enable Product Variants). The setting will only be available in the v2 interface.

If the integration has no such setting, please create a support ticket.

Loading a Product Variant

It is also possible to load a product variant via an app URL (the product ID must still be specified). For example, the below URL will load Dark Red and size 116 as default:

https://g3d-app.com/s/app/acp3_2/en_GB/default.html#p=1416664&r=2d-canvas&guid=99999&_usePs=1&state[variant]=33S05282

The value of the state[variant] parameter should be the SKU of the desired variant.

Planned Future Development

  • Adding text area option support, so that a text area’s selected option value can change the product SKU (especially useful for CSV based retailer integrations).

  • Full support for dynamic pricing, so each variant gets its own price.