Monday, 18 June 2019
The product configurator is the tool used to manage the possible combinations that can occur in the purchase process of a configurable product. Those in which the customer can customize the product according to their needs, such as when we buy a computer we can choose the RAM, storage capacity, monitor size, etc. So the final product will be a combination of components (by-products) and attributes.
However, leaving the product configuration process in the hands of users who do not have to know all the conditions that must be met for the sale of the product or service to be viable, is a significant challenge for system administrators. When selling a product, the compatibility with other products involved, the technical possibility of fulfilling the service, either by geographical area, type of client, agreements with specific customers, etc. must be verified.
To implement the logic that combines all these types of variables, Compatibility and Eligibility Matrices and Constraints are mainly used.
The Compatibility Matrix is a two-dimensional table that includes the list of products and their compatibility with each other.
Example: Prepaid Internet EXCLUDES Internet 50mg
The Eligibility Matrix defines how Products are displayed. The Siebel standard allows you to establish eligibility conditions according to some predefined fields such as: Postal Code, Product Line, Customer. Like Compatibility, it is two-dimensional. An example would be: Internet product 50 mg NOT AVAILABLE ZIP code 28350.
There are three options, which are configured at the cfg level and which can theoretically be dynamic, that is, one or the other according to the user’s profile (although this is a Siebel defect and does not work correctly, at least until 8.1). The eligibility options for a product Not Available would be: 1) displayed in “Read Only” mode 2) all displayed and selectable 3) not displayed. In addition, the configurator has a section that shows us indicative messages about the eligibility or not of the products.
Constraints are rules more similar to what an SQL statement is, but they are built intuitively from the application. The main difference with the Compatibility Matrix is that these are evaluated within the product configuration process and add more functionality to the process allowing to build conditions based on the product attribute or business component fields. They allow you to establish very specific conditions, but beware! They penalize performance a lot. I seem to recall that the recommended number of restrictions per product should not exceed 20 or 25.
Classes allow inheritance of objects. A product associated with a class will inherit the structure of the class. For a product to have attributes it must have a class associated with it, because attributes are associated only with the class and the product will inherit attributes through it. Therefore, when creating classes, the most sensible thing is to make a list of products with common attributes and create generic classes to associate with these products.
For performance reasons it is not advisable to build products with more than three levels. When we start the configuration of a product, the entire product class is read (that is, the class and its subclasses, if any) and each product of each sublevel in turn can have a class associated with their respective constraints, which generates a large volume of work to the component in charge of managing the requests of the Configurator. It will always be preferable to have more products with compatibility and eligibility rules than to have many sub-levels, which would imply a greater number of Restriction rules.
