CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

Multi-Level Product Configuration in SAP CPQ

8 min read

Overview

There are many times when a business needs to have complex multi-level products in SAP Configure Price Quote (CPQ). These may be the creation of sites and products within a telecom implementation, a multi-phase service offering, a complex fabrication line, or as you may have seen in trainings and simpler scenarios such as a rack servers. The creation of a multi-level configuration takes some work to set up properly, but once done will greatly assist in the sales process. This article will describe how to build these, some common issues that may arise and how to ensure that sales users can navigate the system efficiently and without confusion. The estimated time for setup is 1 hour.

Table of Contents

The Use Case

We will be taking the example of a telecom company that needs to create multi-site offerings. Each of these sites can contain their own products. These products can be dependent on other products in the site, or even on the entire solution. There are times where sites are very similar to others such as with satellite offices and only differ for a number of users. Because of this, you may want a way to copy sites and make changes to them. In addition, a subtotal price for each site needs to be known as this will be used for order fulfillment. You could try to accomplish this by using item custom fields. The field value for each product item would indicate which site the product belongs to. This though cannot meet all needed requirements: there is no true hierarchy, you can't view a single site and all of its offerings and so, you need to decide to take another approach.

Core Concepts in SAP CPQ

The main way that you accomplish this kind of implementation is by containers. Containers are an attribute type that is set up like a table. Multiple rows of this container can be added, each of which can be its own configuration. You can determine what columns the container has such as a site address and total price. Data can be passed from the top down to the children layers to aid in configuration. Think of it as a parent/child relationship of configurable products, where a parent configuration can control and send information to all of its children.

Now let’s take a look at some of the basics of the setup.

Configuring the System

The first thing that we will need is an entry point for the sales user which will be a configurable product.  

Warning It is important to set up the Display Type as a Parent/Child System.  Although it may seem to work as a Configurable Product there will be difficulties later on when working with items such as pricing and with how some scripts work.


This configurable product will be the top layer of the build. The 2nd layer (which is each individual site) will be added to this product by using a container. To do this follow the below steps.

  1. Create the next layer of product which is called "Site" in this example. This product will not be directly accessible to the sales rep so it should be placed in a category they do not have access to. The only way to create a site is through the Solution Configurator.
  2. Create a container called "Sites". This will give you a method to allow the user to create sites in the Solution Configurator.
  3. To link the products to the sites container add it as a product to the Sites Container.
  4. Add this container to the Solution Configurator product just like any other attribute. You should also mark this as a line item.


At this point there is a container in the product, but it doesn’t really have much of a UI. What kind of information might be needed at a high level in the sites container? A site name, maybe a location, the total number of users at that site, or maybe which products have been quoted there. This will be dependent on the customer requirements. But here is a simple example that will illustrate how this starts to come together.  You should add three columns to the container; Site Name, Total Users, and Included Products. Note that Name and Users are editable, while Products are not.


The next step is to allow transferring of data from one level to the next. Site Name is an easy example of this. We want the sales user to be able to enter in the name at the Solution Configurator level or at the site itself. That means these need to share data. To do that a new attribute called Site Name is created and added to the Site Product. When we return to the Sites Container a new option is available under the column for Name.


When you pick the Column Type of Product Attribute you can select from the attributes in the site product. In this case there is only one called Site Name, select it. The Site Name is now linked to the site itself.

If a site is added you can type in the site name at the top-product level, or type in the name at the site level, as the same field is accessible in both places. The same process can be followed for total users.

Now let's address how could this be used.

Say for example pricing for some products is based on the number of users. The configuration is completed and 6 different products have been added, each of which use the same 500 users. The customer returns with a change that they need 550 users at that site and all products still use all 550 users. Instead of opening each product the number can be changed at this top level and passed down to its children. This reduces the amount of time a otherwise needed to navigate products and update values.

This information can also then be repeated at the individual level, say that each product is using a different number of users. At the site level you could have another container that has each configuration that is part of that site. The users could then be changed from this level as well without opening the entire configuration.

Cautions

One important thing to keep in mind is processing time. The rules and logic need to run on each level. So, if 20 configurations are changed by altering the number of users. 20 different configurable products need to execute their rules. Sales users and administrators should be aware that this can take significant time. However, it is much less than opening each product and individually changing the parameters.

There isn't a technical limitation to the number of layers possible, however it should be minimized so as to not cause confusion. It is very likely that there will be a lot of information that can’t be displayed at the container level. In this case a user will need to navigate the system to complete a configuration. If this is 6 layers deep, this may be very confusing for a user.






Conclusion

Containers provide a powerful way to nest configurations. There are many practical applications of this and nearly limitless ways these can be utilized. However, the basics remain similar. Multiple layers of configurations, a container linking them together, and some type of data flow between the layers. Many times, this data flow layer is far to complex for simple attributes to be used as in the case of a name. In that situation often scripting is used to aid in this. Scripting can, from the parent layer navigate through and change information throughout the entire hierarchy. This allows you to build complex hierarchies that each layer is dependent on the others.

You can read about parent/child structures here. To get yourself familiar with other two types of multi-level products in SAP CPQ (used less frequently in comparison to parent/child) read about System (List) of Configurable Products and  Collection of Configurable Products.

Overlay