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 functionality lets you influence what a user will be able to do with the product relations, view only for example.

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.


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.