Skip to main content

Product relations

Product relations can be used to link products to each other. By using these links, you can enable your front ends to either show replacement products, or products that complement each other.

The Product relations overview shows you all currently active sets of relations between products.


Permissions

This chapter requires you to have the ProductRelationTypes permission. These are managed from the Roles and rights chapter's functionalities card of a users role.

Create product relation​

Click the '+' icon to start creating a new product relation. This process consists of two parts.

The first part concerns general information about the relation in the making and lets you specify its Relation type. The available options in the second step depend on your selected type. We'll go into each type below.


Parent-Child​

This parent-to-child (or uni-directional) type entails a relation between one and another product which works as a one-way street.

This allows you to add any number of replacement products for a single product.

So you have the Parent (A) and the Child (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.

Bear in mind that once a product is linked as a parent to a child product, the reverse can not be configured, So if product B is linked as a child product to A, then product B cannot be linked as parent to product A.


Equal relation​

This equal (or bi-directional) relation is similar to the parent-child one, but works both ways: the two products specified here act as each others replacements.

For example: Product A is a hook. If it were to be sold out, you can advise product B 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​

Product selection per relation type differs, but all are just as intuitive.

In the case where you are selecting just a single product, such as the Parent product in a Parent-Child relation, or when selecting either product in an Equal relation, you can make use of either the Query search or a Search property.


When there is need for specifying multiple products, you can do so via the product modals that has been around in Admin Suite from the start: either add products In bulk (pasting values of product properties) or use the Add products filter (selecting from Values, Range or Prefill (select an existing template)).


By clicking the 'looking glass' after specifying your products, you can check the list of resulting products in more detail.


Stock replacing switch​

For all orders that run through Order Orchestration, the Is stock replacing checkbox can be used to make EVA treat all replacement products as if it's the same stock. This means that if product A is out of stock, EVA will check the stock of the related product(s) to see if an order is deliverable or not.

This is mostly used for products which are functionally identical, but are still treated by EVA as being different products. For example the same product with a different barcode.

Keep in mind that that's all EVA does - a stock check. It's up to employees to properly replace a product in that case.

In practice the available stock of each product would show in the GetProductAvailability of the linked product.

A switch On in the case of Parent-Child relation would mean that the child product will replace the parent product in instances where the parent product is out of stock.

A switch On in case of Equal relation would mean that product 1 will replace product 2 in instances where product 2 is out of stock and vice versa.

A switch On in case of Group is not applicable.

Don't forget to enable this in Order orchestration

Aside from specifying the relations here as being stock replacing, you need to configure this in your order orchestration sheet's options as well. See 4. Using replacement products in out-of-stock situations.

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 a Parent-Child relation, 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 you do not want to display the created product relation on 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 the ProductRelationTypeBackendID as a value. This ID is the one used at time of product creation as BackendID. If you didn't specify it at first, you can still do so in the relation at a later moment.