When planning, you need to take into account numerous and sometimes complex relationships among different objects within an organization. For example, in most companies it is not sufficient to simply plan against a product in isolation. You also need to see that plan aggregated through the product group, division, business unit, profit center, and so on. Since it is through such relationships that you make sense of the figures, it makes sense that you also deny users the ability to plan the product against the incorrect product group, division, and so on. These relationships change, and this is something else that you need to take into account within a planning system with the minimum of effort.

The necessity to take into account these functional requirements surrounding such relationships is handled within Strategic Enterprise Management-Business Planning and Simulation (SEM-BPS) through the characteristic relationship functionality, which allows you to propose, check, and derive characteristic values (e.g., which product belongs to which product line) based on relationships encompassed in

• BW hierarchies
• BW attributes
• Reference data
• User exits

These options have helped SEM-BPS reach a level of maturity and integration with SAP BW (and R/3 for that matter) that has made it an increasingly attractive option. In fact, many companies waited until release 3.1 to begin their SEM-BPS implementations, primarily because of the characteristic relationships functionality it delivers. Nonetheless, I’ve seen confusion among BPS and BW practitioners over how this functionality works and how they can best use it. This being the case, I’d like to explain how characteristic relationships are configured (using BW hierarchies as the primary example). I’ll also provide examples of how you can use them in real settings.

How Characteristic Relationships Are Formed

Those of us who work with SEM-BPS are more than happy to allow our BW friends to do the majority of the relationship forming. BW teams often work at forming relationships between characteristics using hierarchies and attributes, and they are usually the ones to load transactional data. More often than not, you will find that they have already done a great deal of the groundwork within the transactional system. By reusing the BW structures, you ensure data consistency throughout our systems.

Within your Planning area (menu path SEM>BPS>Cross Application Planning>Planning Workbench), the Characteristic Rels tab (Figure 1) shows four choices when it comes to deciding on which basis you check, propose, and derive your characteristic values.

Figure 1

Your four options under the Characteristics Rels tab

Attribute: This is a popular option. You can use the attributes within a BW characteristic’s master data to help propose, check, and derive the necessary relationships. For example, you can derive the cost center group on the basis of the cost center. Or, you can ensure that when the merchandise planner selects the category, only the brands that belong to that category are proposed and posted. In addition, the usage of attributes does not preclude you from showing your characteristic relationships in a hierarchical format. You can achieve this by using Planning layout settings, as I’ll show you later.

From a BPS perspective, the settings for attribute-formed characteristic relationships are similar to those for hierarchy-formed relationships. Therefore, the concentration in this article on the latter type is relevant here.

Reference Data: From an SEM-BPS viewpoint, this is a very controllable and powerful option. You can use any reference transaction data within your BW system to check, propose, and derive relationships. For example, you might follow a process whereby top-down targets have been formed for you as part of the strategic planning cycle. You may then reference the strategic plan version to propose the new characteristic combinations that were formed (e.g., new products proposed for your sales division) as you begin your short-term detailed plan. Alternatively, the sales managers may decide to form the rough-cut targets for customer/product/salesman combinations based on last year’s actual data.

The idea is a simple one: You point the system toward the characteristic/key figure slice of data that is forming your reference point. In my example, the sales manager would propose the customer, product, and salesman based on the reference data Fiscal Year: 2003, Version: Actuals, Key Figure: Net Sales, and so on.

Exit: As always, when you can’t get what you want using the standard options, the user exit is there to save the day. A good example of a typical user exit is the derivation of time. In the example shown in Figure 2, you derive 0FISCPER3 (Posting period) and 0FISCYEAR (Fiscal year) from 0FISCPER (Fiscal year/period).

Figure 2

Derivation of time example via a user exit

Bear in mind that the derived values (0FISCPER3 and 0FISCYEAR in this case) do not have to be contained in the planning level and that you have to enter user exits for the FM: Comb. Proposal and FM: Comb. Check fields even though you are not using them (the value Z_NOTHING is therefore just an empty function module). With just 0FISCPER in the planning level, you get the result in the fact table shown in Figure 3 after saving.

Figure 3

Result with just OFISCPER in the Planning level

Hierarchy: I’m focusing the remainder of this article on the usage of BW hierarchies in forming relationships between characteristics. This is an area that generates equal amounts of interest because of the possibilities it presents and confusion due to the settings. The settings that I discuss here are also, on the whole, relevant for characteristic relationships using attributes.

Numerous types of BW hierarchies can be used in SEM-BPS, such as those formed of multiple characteristics (internal hierarchy), just one characteristic (external hierarchy), and hierarchies with text nodes. While only BW hierarchies with multiple characteristics (e.g., product and product line) can be used in forming characteristic relationships, the other two types (which by definition contain one characteristic) can still be used to add structure to the data within layouts. In the case of the external hierarchy, they can carry out budget control during the budgeting process.

SEM-BPS Settings

Considering that only internal hierarchies are useful to form characteristic relationships, let’s investigate how you can propose, check, and derive values based on a product line/product hierarchy. This BW hierarchy (Figure 4) contains the hierarchy-bearing characteristic Product and then an additional external characteristic, Product Line. This is important as the composition of the hierarchy (i.e., a hierarchy containing only one characteristic versus a hierarchy containing many characteristics) fundamentally affects how you configure the results in SEM-BPS, as you will see shortly.

Figure 4

The BW hierarchy for product

You can make three fundamental settings in SEM-BPS depending on your intentions.

Planning area: It is within the Planning area that you determine whether you wish to propose and check or propose, check, and derive values based on the characteristic relationships formed within your BW hierarchy (or attributes, reference data, or user exit). In the example shown in Figure 5, you have selected the hierarchy (as shown in Figure 4) and determined that you wish to check the relationships between the product line and product. You can, of course, check and propose relationships among more than two characteristics. Note also that SEM-BPS can take into account different versions and different time dependencies for the hierarchy.

Figure 5

Defining characteristic relationships has multiple steps

As you can see from Figure 5, you can have multiple steps in the definition of characteristic relationships. This means that you can, for example, have more than one hierarchy involved in the process.

In another example, you might form characteristic relationships from a BW hierarchy involving time characteristics. This is a common example of the usage of time in a retail environment where you may need to have, say, periods/ weeks tied into a season. In this case, you are using the hierarchy shown in Figure 6 to derive the season as the data is saved. Therefore, the settings shown in Figure 7 in the Planning area lead to the relevant season being derived and posted into the fact table (Figure 8).

Figure 6

Hierarchy to determine season

Figure 7

Planning area settings for the Seasons hierarchy

Figure 8

Fact table for Seasons

Planning level: Returning to the product line/product example, the second set of settings to make is in the Planning level. This is where the confusion usually begins. Many people assume that entering the hierarchy — or a node of the hierarchy — within the Planning level automatically means that the Planning layout displays the results as a hierarchy and that the values are validated regardless of the settings within the Planning area.

These assumptions are incorrect. Entering the hierarchy in the Planning level only proposes a set of characteristic values that the system then processes for you. If you want the values to be displayed as a hierarchy, then you need to let the Planning layout know (see the next section). Likewise, if you want the values checked (i.e., validated), then you need to must make the settings within the Planning area. To illustrate this point, if you enter the hierarchy in just the Planning level (Figure 9) and make the relevant settings in the Planning layout with no settings in the Planning area, the result would be as shown in Figure 10.

Figure 9

Hierarchy entered in only the Planing level

Figure 10

Results of entering hierarchy only in the Planning level with no settings in the Planning area

This means that you have only proposed the relevant values by putting the hierarchy in the Planning level. Due to settings in the Planning layout, the system is then showing them as a hierarchy but with no check being carried out against the original BW hierarchy. Therefore, all product lines are being combined with all products. If, however, you enter the hierarchy for combination check and proposal in the Planning area, then the system carries out the required validation and you get the correct result shown in Figure 11.

Figure 11

The correct unsorted results

Or should I say, almost correct result. You may have noticed that the original BW hierarchy was sorted so that Soft Drinks came before Alcohol. As a default, SEM-BPS sorts alphabetically according to technical name. This may not seem important in this example, but imagine the problems with a hierarchy showing your income statement! To get over this issue, you can make one further setting in the Planning level. You can create a BW hierarchy like the one shown below against the Product Line that takes care of the sorting in the Planning level, as Figure 12 shows. This gives the correct result (Figure 13).

Figure 12

Product Line hierarchy to achieve correct sorting

Figure 13

Correct sorted results

Planning layout: The settings in the Planning layout vary depending on which type of hierarchy you are using. If you are using a hierarchy formed of one characteristic (an external hierarchy), then you need to ensure that the hierarchy-bearing characteristic is the only characteristic in the Lead Column within the Layout Builder. Select and right-click on your layout within the Planning Workbench, and then select Change. Then select the icon and then the following option:

This option is not available for hierarchies formed with multiple characteristics, however. To have the hierarchy displayed in the layout in this case, you need to ensure that all the relevant characteristics are in the Lead Column and in the correct order (i.e., Product Line first and then Product). When more than one characteristic is in the Lead Column, then the BW Hierarchy with Postable Nodes option is no longer offered, leaving you with the option below:

This is the source of the confusion I outlined in the Planning level section. The BPS Characteristic Hierarchies option takes the values offered in the Planning level and the Lead Column and creates a hierarchy based on all options. This is why you need the Planning area settings to limit the options to only those that you need.

What you are doing is using the existing BW hierarchy and the settings in the Planning area and Planning level to propose and validate the values and the BPS Characteristic Hierarchies settings in the Planning layout to display the values and allow budgeting (including budget control) to be carried out.

The settings for characteristic relationships may seem a little convoluted, but the confusion melts away once you break them down. With a little thought, you can use them imaginatively. For example, a hierarchy with text nodes is of limited use on its own for budgeting. If you combine it with a BW hierarchy that derives the product line, division, SBU, and so on, then you have a far more powerful option.

Settings in the Planning area validate and derive. Settings in the Planning level allow you to be more precise (e.g., selecting a specific node), but are only proposing values. Settings in the Planning layout actually determine how you want to see the values displayed.

¹ This functionality is available in previous releases through user exits SEMBPS01 and SEMBPS02, but Release 3.1 marked the first time that the configuration for these relationships had been brought forward from the backwaters of ABAP to the SEM-BPS Planning Workbench (via transaction BPS0). For more information, see SAP note 387524.