Skip to main content

Product relations

Front end in-progress

Although the functionality for linking items is already available in Suite, the actual displaying of these items in the front ends is still under construction.

Product relations can be used to link products to each other, to either show proper replacement products, or products that complement each other.

Permissions

The ProductRelationTypes permission lets you influence what a user will be able to do with the product relations, view only for example. Permissions are managed from the Roles and rights chapter namely, from the functionalities card of a users role.

Create product relation​

The page consists of two parts: the Information and the Products card. The latter card will change depending on what you select in the first card.

The first field is most important, as it determines the product Relation type. This relation type dictates the behavior of the relation between the products, by setting its direction. You can choose from the following three options:

Uni-directional​

This is a relation between 2 products, but only works one way. So you have the primary (A) and the secondary product (B). Product B replaces product A, but product A doesn’t replace product B. To make it even clearer, product A is a processor for a niche motherboard and product B is a processor that fits all types of motherboards. Also, when product A (as primary) is linked to product B (as related), then product B cannot be linked as primary to product A.


Bi-directional​

Same as unidirectional, but works both ways. For example: Product 1 is a hook. If that is sold, you can advise Product 2 which is a fork and vice versa.


Group​

This is a grouping of products and doesn’t do anything with the 'RelatedProductID'. It only accepts 'PrimaryProductID’s' to form a bond between multiple products. Products that go well with each other. For example: a blue shirt, a blue set of shoes, a blue hat, etc.


Dynamic relation​

The toggle Use dynamic relation product as related product can be used to configure a dynamic relation.

Simply, switch it on, specify the dynamic Product ID or name, and you'll be off to a good dynamic relationship.

Example: When turned on, the result from the ProductSearchTemplateID or ProductSearchFilters will be considered as primary products and the DynamicRelationProductID will be considered as the related product.

Example: When turned off (default), the DynamicRelationProductID will be considered as the primary product and the result from the ProductSearchTemplateID or ProductSearchFilters will be considered as related products.

note

Use of the dynamic relation toggle is not possible if the initially selected relation type was Group.

Adding products​

The uni and bidirectional adding of products is done via the familiar product modals, in which you can specify a search property, add the necessary values and select the products. The Group variation works slightly different, letting you add the products In bulk (pasting comma-separated values of product properties) or by using the standard product filter (selecting from Values, Range or Prefill).

Stock replacing switch​

For all orders that run through Order Orchestration, the stock replacing switch can be quite useful. Noting that it can only be used with Uni-directional and Bi-directional relations.

A switch On in the case of uni-directional relation would mean that the secondary product would be a suggested replacement to the primary product in instances where the primary product is out of stock. Further, the available stock for the secondary product would also show in the GetProductAvailability of the Primary Product.

A switch On in case of bi-directional relation would mean that product 1 would be a suggested replacement to product 2 in instances where product 2 is out of stock and vice versa. Further, the available stock of each product would show in the GetProductAvailability of the respective product.

note

The default state of this switch is off.

Invoiceable product relations​

It's possible to create a product relation type for the purpose of restitutions. This is best explained by means of an example:

Say you create a discount where only part of the invoice is paid by the customer, while the other part is to be paid by the manufacturer. In order for the manufacturer to receive that invoice, the manufacturer will be marked in EVA as a restitution OU which is in turn listed in the discount.

The discount itself is applied to various types and variations of shoes. Because we don't want the manufacturer to receive 100s of invoices for all those different shoes, we want to replace all those items with a single invoiceable product. That's where product relations come in.

Broadly speaking, there's three steps to setting this up.

Step 1: the invoiceable product​

First off, create the product that will serve as the catch-all product in the product relation type, say Brand shoes.

Step 2: the product relation type​

Secondly, create the product relation type itself, bearing in mind:

  • Not to toggle Is stock replacing;
  • To set it as Uni directional, since it's a one way link;
  • To specify a BackendID

Now add all the products to be included and set the catch-all product as Product 2.

Step 3: fill the setting​

Thirdly, and lastly, we have to take the BackendID from step 2 and specify it in the following setting: Orders:Restitution:ProductRelationTypeBackendID. This setting must be set on either the RestititutionOrganizationUnit itself or on a higher level.

With all of that in place, for each product that will be in the RestitutionOrder, the given product relation is checked and when there is a product available (Product 2), the product will be replaced on the order. If there is no product relation available however, the original product will be in the restitution order.

In some instances a setup is required where the created product relation is not desired to be shown for specific organization units. For that, a setting called App:Product:HideRelations can be used to hide a specific product relation from showing on the front end apps of an organization unit.

The setting expects a value that pertains to the ProductRelationTypeBackendID. This ID is what was filled in at time of product creation as BackendID. If initially filled in, it can also be retrieved from the Product relations chapter overview for existing ones.