Sana Connector 3.0 - Setting up variants

The Sana Connector completely relies on the ECommerce API for setting up variants. So please consult the ECommerce API manual for setting up variants.

When it comes to setting up variants for use by a Sana-shop the following should be noted:

1. All variants created in Perfion must also exist in ERP-system. Otherwise, it would be impossible to put on order on such a variant.

2. A KeyField-mapping on the Variant entity that maps the feature that holds the unique identifier for each variant and maps that to a Field named Id in Sana. This must be done on variants in the exactly the same way as it is done for products. Note that it is ok that another feature holds that identifier on Variants than it is on product. Usually, though, it will be the same feature.

Note that in some ERP-systems, variants are only in one dimension. Let us say you have a cup that comes in 3 sizes and 4 colors. This gives a total of 3 x 4 = 12 variants of that cup. Some ERP systems only supporting variants in one dimension will hold these variants in one big list. However, having variants logically grouped by their dimensions gives the user a much better experience. This is called multiple dimensions and is supported by both Sana and Perfion.  How variants in multiple dimensions is set up in Perfion, is described in the ECommerce API manual. When it comes to the Sana Connector it should be noted that it is OK to define these variant dimensions in Perfion, despite the fact that they may or may not be in the ERP-system.

Assuming the chapter on setting up variants in the ECommerce API has been studied, this chapter from here shows an example where variants are set up in Perfion. For details regarding any “ECommerce specific” type mentioned, please consult the ECommerce API manual.

Figure 1 show the Bodum Bistro-product that we want to also have in Perfion.

Open

Figure 1: The product with variants in the ERP-system

Note from the figure that the unique id for the product is BODUM BISTRO. Note further that this product has 6 variants (with ids 11581B, 11582B, 11591B etc.). We can also tell that these variants seem to vary at least on their size, suggested by their title. Furthermore, since this title has the same size listed twice, it seems likely that there is another variant dimension.

The corresponding items in Perfion could be made as shown in Figure 2:

Open

Figure 2: The same product showing the same variants in Perifon with the few additions needed to support variants

In Figure 2, we see that the base value for variants indeed matches the Id from the ERP-system. Then we have a Color-feature and a VolumeL-feature containing values on the variant

Settings

In order to enable variant handling a single setting must be set to true:

Mappings

As everything in the ECommerce API which feature that must hold the whether an item is a Product or a Variant is controlled by a mapping. Therefore, you can pick any name you want. The mappings shown in Figure 31 will take our variants from the ERP-System to Sana:

The mappings shown above does the following (check ECommerce API manual for more details):

• ECommerceType-feature is given the Output Kind ECommerceType. This tells the connector (or more precise the ECommerce API), that this feature holds either the value Product or Variant (or blank) describing what entity the item in Perfion represents.
  Note: This mapping put on the Product entity, but must also be filled out on variants.

• ECommerceVariantOfProduct-feature is given the Output Kind VariantOfProduct and the entity Variant. This tells the connector that this feature for each Variant holds the Id of the product. In this case, it holds the value of the Value-feature. In Figure 29 we indeed have, that all variants contains the value BODUM BISTRO pointing to their product.
  Note: In Figure 2, this value is set on all variants. It could as well have been set on the product, and inherited on all variants. For the connector there is no difference.

• Value-feature is then chosen as the KeyField. As for products, variants must have a KeyField matching the Ids from the ERP-System.

• Finally, we have 4 features: ItemName, Color, VolumeL and Image being mapped on the Variant. These are not telling the ECommerce API anything, except that these contain information that needs to be transported to Sana.

A general note: Figure 2 shows that some of the feature-values are coming from their parent-nodes (using inheritance) and others are assigned “directly” on each variant. You can do what you prefer. The connector works with both.

With the above mappings in place we can test the it on the Sana front end. The result is shown in Figure 5:

Notice how the variants are in one dimension.

Since we in Perfion have information regarding multiple dimensions we might as well take advantage of the. It requires only a single new mapping:

This tells the connector (ECommerce API) that a feature named ECommerceVariantDimensions is on products, and that it will contain the name of all features on Variants that contains the dimensions. For our cups it would be the Color-feature and the VolumeL-feature (captioned Volume (l) in Perfion).

This means, that we need to get back to our BODUM BISTRO-product and add the information for the product. This is done in Figure 7 below:

The feature ECommerceVariantDimensions is inherited, so the variants get the same value as the product as shown in the figure. This is not necessary. As long as the feature-names are added to the product, it suffice.

Note that it is possible to mix products with multiple dimensions with products having variants in only 1 dimension with products not having variants at all.

The result of our efforts can be checked in Sana and is shown in Figure 8: