Introduction to the Parent/Child Variant Model

Some popular Marketplaces allow the exchange of products with third-party software such as Sales Layer and others do it by importing CSV or Excel files. 

Many of these Marketplaces suggest an exchange format when product variants become a factor. This exchange is based on a Parent/Child structuring that will allow a better arrangement of product information and variants in the final result.

In this document, we are going to talk about how to obtain valid import documents, when the items are conceived as product variants, and that follow the Parent/Child structure model, by using Sales Layer PIM connectors. It is mainly focused on connectors that incorporate it by default. Its output is formatted using Excel Template and its output is formatted using standard CSV.

It is important to know that not all Marketplaces support a Parent/Child structure when including variant information. For example, marketplaces such as Google Shopping, or Google Manufacturer, indicate NOT to include the parent item as a separate product in the exchange feed. Instead, they use a grouping field where each variant belonging to the same parent must report the parent SKU. 

If the product and variant tables are both enabled, the output will be a merged combination of the product data and its associated variants. This implies, in the default mode of operation, that if a product is associated with three variants of a product the output of the connector will show records that combine the connected variant data with the already matched data. If the product does not contain any associated product variants, it will also be outputted as an independent product with no values for the connected variant fields.

Note: The formulas function of the Sales Layer PIM connectors allows operations to be performed on product fields, variants, etc.  So it would be easy with a concatenation formula to obtain descriptions, for example in the Model section, that will combine other fields such as size and color. Example: Sport Xtreme Sneakers Size 41 Black.

Add parents of merged variants (as a separate record)

Sales Layer has connectors, such as Amazon Seller, where it is possible to indicate the ability to add the parent of merged Variants as a separate record. The need for such MarketPlaces to use this technique makes it possible to implement it from the connector when the intention is to work with variants.

Note: Platforms such as; Lengow or Amazon Seller, also allow feeds with information only at the simple product level. In these cases, feeds can be exported without following the Parent/Child model, which is recommended when importing feeds that include variants.

If we activate the Add parents to variants option, in the connectors that incorporate it, we will obtain an output that will include the parent article when it contains associated variants.

Let's look at an example:

We have one P1 product with three variants VP1, VP2, and VP3.

The connector, when merged, outputs only 3 records, as many as the number of variants it contains, so what it will return will be:

P1... VP1...

P1… VP2...

P1... VP3...

However, some marketplaces, such as Amazon Seller, require the association of products and variants through a topology known as Parent/Child, the way they detail the data of the parent and the different variants.

With this function, the result would be:

P1…. Parent

P1... VP1... Child

P1... VP2... Child

P1… VP3...Child

Thus, what it does is to add a new record to the result: the parent without combined data.

Specific formulas for parent/child modeling in connectors

When we activate the Product and Variant tables in a connector, and activate the Add Merged Variant Parents option, we can use two formulas in the connector fields. These will allow us to know the type of record being exported to combine with other formulas, which in return will allow us to specify the output data correctly.

IS_FUSION_VARIANT_PARENT()

Returns true if the returned record is a parent of a variant. 

* Requires that the Merging Variant Parents Output parameter is enabled.

IS_FUSION_VARIANT_PARENT_FREE()

Returns true if the record returned is part of a merger between products and variants and also has no associated variant. In any other case, it returns false. 

* Requires that the Merging Variant Parents Output parameter is enabled.

Usage example:

IF(IS_FUSION_VARIANT_PARENT(), PRINT("Parent"), PRINT("Child"))

The formulas can be used both in the Products tab and in the Variants tab. 

Note: When we connect the same output field in the variants and products tab with merging enabled, the ones specified in the formats tab take precedence over the product ones as explained below.

Usage example:

IF(IS_FUSION_VARIANT_PARENT(), IF(IS_FUSION_VARIANT_PARENT_FREE(), PRINT("Single Parent"), PRINT("Parent")), PRINT("Child"))

Usage example:

Removes products with no associated variant from the final output feed.

IF(IS_FUSION_VARIANT_PARENT_FREE(), REMOVE_FROM_LIST())

Usage example:

Generates Variant Names by combining field values.

IF(IS_FUSION_VARIANT_PARENT(), 

         CONCAT({Family} , “ “, {Model}) ,

         CONCAT({Family} , “ “, {Model} , “ “, {Size}, “/“, {Color}) )

Output by a combination of fields in merged tables

Maintaining a consistent data structure in the PIM (allowing flexible structuring) is advisable when organizing parent products and variants. 

Our advice is to define common fields in the products, and specific fields in the variants.

As an example of common product fields we could talk about: Brand, Attribute Set, environment images, characteristics, etc. ...

As an example of variant-specific fields, we could use fields such as; size, color, gender, etc.                                                                                                                                      

Depending on the type of business and its structure, the fields to be used (product, variant...) can vary greatly. For this reason, it will often be necessary to combine product-specific and variant-specific fields in the same field of the output feed.  One common product and variant field, for example, could be the price.

On those occasions when you have to connect a variant field and a product field on the same output field, there are overwrite rules.

• A connected field from the variant table will always take precedence over the value of a connected field from the product table. Either because the connected value is obtained directly from the value of the field in tables, or because the value is obtained by a formula.
• If the connected field in the variant table has a null value (an empty string or one without spaces is understood as such), the value used in the connected column of the output feed will be the one provided by the product associated to that variant.
• Parent products (without associated variants or as a result of activating the "Add parents to variants" parameter), do not have a default value for the unique fields in the variant table, only the value in product tables. So the output for those will be zero.
• If a formula is used to give a value to a feed output column (from the product or variant tab), the output value will be applied to all output records. Use the formulas IS_FUSION_VARIANT_PARENT and IS_FUSION_VARIANT_PARENT_FREE, to determine the type of the ejected record and determine the final value, as seen in the previous examples.

Assume the following data in PIM tables, connected as follows:

The output fields/columns SKU and Price in EUR are connected to the product and variant table fields.

1. Standard connector output without using formulas.
2. Connector output using a formula to remove the price of the Parent product (can be applied to any of the euro_price fields).

IF(IS_FUSION_VARIANT_PARENT() AND IS_FUSION_VARIANT_PARENT_FREE() = 0 , “ ”)

In this case, we remove the price of the Parent products that we have added, but only those that have associated variants.

Note: The correct connection of table fields with the output columns, together with the use of formulas, allows to automatically generating feeds according to any kind of specification and suggested typologies of the Parent/Child variant models.