2.6 - Block detection

The goal of the block detection system is to:

• Detect some specific module compositions of a modular product.
• When a recognized block matches the current composition, it will take precedence over the list of modules. The price of the composition will be the price of the detected block.
• Provide optional additional products not included in the detected block.

Definitions

Module

A module is a product used in a modular composition.

Modular composition

A modular composition is a list of modules attached together.

Block

A block is a recognized composition, materialized by a product with a thumbnail, name, price...

For example: when your composition consists in a "2-seater sofa" attached to a "corner sofa", itself attached to another "2-seater sofa", then the detected block can be a product named "L-shaped sofa".

Additional product

An additional product is a product not included in the block, that keeps its price when the block is detected.

Data contribution

Steps to follow

• Create the detected blocks 🔗 matching the blocks you want to recognize.
• Create a generic block product 🔗 that will hold the matching between the composition and the detected blocks.
• Configure the modular context 🔗 product to link it to the block detection system.
• Optional: configure additional products. 🔗
• Optional: configure compositions. 🔗

1 - Detected blocks

1.1 - Usage

Detected blocks are products. You can start by creating those products, so you can use them later. They will only be used as an output.

• They have no 3D representation.
• They have their own price grid.
• Their price will replace the price of the composition.
• They will appear in a specific attribute of the BOM. 🔗

1.2 - Pricing

If your detected block product has a fixed price, you just have to fill the price on the product.

If you need to make the price evolve based on the parameters of the composition, you can also do it like you would on any other product (using Configuration Sets or Product Mappings).

The pre-requisite is that the parameters that can modify the price should be the same that you used on the modular context product.

For example, if your composition has a "finish" parameter, and your detected block price changes based on the finish of the composition, you will need to:

• Declare the "finish" parameter on the modular context (so the user can change it on the composition).
• Declare the "finish" parameter on the detected block product, so you can make its price change based on it.

It's recommended to use a parameter definitions 🔗 to share the same parameter between the two products.

2 - Generic block product

2.1 - Usage

The generic block product is the unique product that links the current composition to the detected blocks. It will never appear to the end user, it's only an intermediate product used to centralize the block detection process of a product.

You will need to configure two things on this generic product:

• Parameters.
  • A mandatory productId parameter.
  • The optional parameters that can be used to detect a block.
• Product Mappings.

2.2 - Parameters

Mandatory productId parameter

Always create a productId parameter, of "Product" type. The possible values should be the modules 🔗 that you can use on your modular product.

Optional parameters

You can add other parameters as an input to detect a block only if a module has a specific configuration. They should match the parameters available on the modules. For example, if you want to detect this:

• A 2 seater with the "headrest" parameter set to "true".
• A corner with the "relax" parameter set to "false".
• A 2 seater with the "headrest" parameter set to "true".

You are using the "headrest" and the "relax" boolean parameters to detect the block. So you have to declare both parameters on this generic block product. Note that the example is about boolean parameters but this works for all types of parameters.

tip

If the ordering of the modules is important, you can make use of the index parameter of the modules 🔗.

2.3 - Product mappings

This is where you will make the link between a defined composition and the detected blocks.

See the generic documentation about product mappings 🔗

info

• The product reference should be one of your detected block product. 🔗
• You have to follow a specific format for the conditions to work, see below.

For each block you want to detect (like "L shaped sofa with headrest"), you will have to create a mapping with conditions that lead to this block.

Matching a composition

The description of a composition must always follow those requirements:

• It's a list of sub conditions
• Each sub condition must start with a condition based on "productId=..."
• Each sub condition is separated by "AND" operators

Example 1

(productId=XX1)
  AND
(productId=XX2)
  AND
(productId=XX3)

This will match if the current composition contains 3 modules: XX1, XX2, XX3, no matter their order from left to right.

You can be more specific in the sub conditions, but the first condition inside must always be the productId parameter.

Example 2

(productId=XX1 AND index=1 AND headrest=true)
  AND
(productId=XX2 AND index=2)
  AND
(productId=XX1 AND index=3 AND headrest=false)

This will match a composition containing three ordered modules: XX1 with a headrest, XX2, XX1 without a headrest.

Matching multiple compositions

Sometimes you may want to write multiple conditions that ends up being the same detected block.

When building the product mapping, you can put multiple conditions following the "matching a composition" guidelines 🔗, separated by OR operators. Like this:

(
  (productId=XX1)
    AND
  (productId=XX2)
    AND
  (productId=XX3)
)
  OR
(
  (productId=XX4)
    AND
  (productId=XX5)
    AND
  (productId=XX6)
)

3 - Modular context configuration

Once the other steps are done, you have to link your generic block product to the real product on which you want to enable block detection.

Link to the generic block product

To link your modular context to a generic block product, you have to create this parameter:

ID	Type	Default value
blockProduct	Product	The generic block product. 🔗

Parameters for pricing

If the detected blocks 🔗 you created have parameters that you want to use in their pricing, those parameters must be configured here.

Only global parameters 🔗 can be used for the pricing of a detected block.

4 - Additional products

When a block is recognized, the bom will be modified and the recognized block may include additional products, having a price. An additional product will appear in this list if:

• It's part of the composition (excluding the modules themselves that are never additional products).
• It was not used to recognize the block. We consider that a product is used to recognize the block if it's used in a mapping condition.
  • For example with leg="leg1" in the mapping, "leg1" will not be an additional product.
• It does not have a free tag 🔗 with the name NotAdditionalInBlock

So if you want to exclude a product from the additional product, you have to either:

• Use the parameter it's loaded on in the mapping conditions.
• Add a NotAdditionalInBlock free tag 🔗 on the product.

info

The additional products will keep their prices. If you made use of packs, they will be computed on the additional products only. It means that:

• If you sell packs of legs, and the legs are included in the recognized block (not additional products): you will have no leg pack.
• If you sell packs of legs, and the legs are additional products even if the block is recognized: you will have leg packs with their prices.

All other products of a composition will have no price when a block is recognized.

5 - Compositions as product

If you created compositions as products to be loaded in the Home planner, you will have to also apply the same process that you use on the modular context. 🔗 This will allow the Home planner to detect the blocks.