1. Contents
  2. Guides
  3. Channels and tasks
  4. Custom
  5. Creating variants

Creating variants

A varnish in six shades and four pack sizes is one article with 24 variants, and in the shop it should stand as one article with two pick lists, not as 24 individual products. This page shows the way there: the axes as properties, the import that turns a flat file into parent and variant articles, and the place where the axes reach the shop. It applies to the file carrying one row per variant and none of its own for the parent article, because there the family only comes into being during the import. By hand it does not: the Parent Product field on the product is a link and not an input field. Where the connected system keeps its variants itself, its download task brings the family along ready-made, see your system's page under channels and tasks. The model behind it, that is why a variant is a full product with a Parent Product, is under data model.

Prerequisites

  • The running file import from importing products from a file. Variants are its extension.
  • A file with one row per variant. A row of its own for the parent article is not needed, it comes from the grouping.
  • Two entries per row: a feature holding the family together (a group identifier or a number prefix, say), and the values of the axes (shade and pack size, say).

Step by step

  1. Create the axes as option properties. An axis to be picked from in the shop is a property of the option type. Only an option has an option list, and only an option list has an order in which the variants later appear. Create one such property per axis, with Auto Fill, and the options are then created during the import from the file's values. The route in detail is under configuring properties.

  2. The first plan creates the parent articles. In the import task's transfer plan the leading record set gets the Grouping: a column or a script delivering the same value per family. One product is created per group, the parent article. The Mapping of the same record set carries the same expression as the grouping, because it gives the group its identity. Variants are only that row's most frequent case: the Grouping combines rows into one object, in the order import the position rows into one order. Where it sits in the structure is under transfer plan.

  3. The second plan attaches the variants. Create a second plan through Insert, again on the same file, this time without grouping and with the row identifier as its Mapping. Two assignments make it the variant plan:

    • Parent Product finds the parent article through the same expression as the grouping, wrapped into the lookup, FindProductWithMapping(GroupId) for instance.
    • The axis properties receive each variant's value from the file. If the file also carries single articles without variants, a filter separates the rows: the variant plan takes only the variant rows, the first plan keeps the rest.

  4. Check the order of the plans. The plans run per row in their order, and the plan creating the parent has to stand before the one looking it up. If it comes after, exactly the first variant of every family fails and only heals on the second execution.

  5. Decide the field distribution. What is the same within the family (the family's name, description, category) belongs into the parent plan; what differs per variant (EAN, weight, price, stock, the axis values) into the variant plan. A parent article carrying the EAN of its first variant is the error that grows out of a different distribution.

  6. Take the axes into the shop. Whether a variant appears in the shop as a selectable version is decided by the transfer plan of the upload task: the axis properties have to be in the section your system provides for variant axes, and that one is named differently per system. Which it is and what goes in there is on your system's page under channels and tasks.

The import task's two plans over the same file, with mapping and grouping on the GroupId column

Checking the result

Four looks after the execution:

  • The numbers: one parent article per family on top of the file's variant rows. On the demo dataset, 161 rows become 179 products, 18 of them parent articles with variants.
  • On the parent article the Common section lists the Product Variants as links. The variant shows its Parent Product.
  • The parent article carries no value on any axis. The variants carry one per axis.
  • In the shop the family appears as one article with one pick list per axis, in the order of the option list.

Frequent pitfalls

  • A nested record set creates no parent article. The obvious structure, an "article" node with a "variant" node below it, delivers exactly one product per row and no parent. The variants then fail because it never existed. The way is the two flat plans from steps 2 and 3, and the parent is produced by the grouping.
  • Mapping and grouping drift apart. After step 2 both carry the same expression. Where they differ, parents are created that no variant finds again.
  • The filter sits on the wrong node. On the grouped record set a row filter has no effect. It belongs on the ungrouped variant plan from step 3.
  • The axis was created as text. A text property has no option list, hence no order, and no pick list in the shop. The axis needs the option type as early as step 1, because after creation it cannot be changed. The only remedy is to create the property anew and reassign it.
  • All variants fail, the parent does not. That is almost always a follow-up error of the parent or the plan order from step 4. The number of errors is larger than the number of causes, see understanding error messages.

Further reading