Keeping it consistent: using naming conventions in SAP PCM

13 April 2016

Steve Mainprize

Steve Mainprize


As any IT system becomes larger or more complicated, it becomes harder to understand and maintain. One discipline that helps users and developers alike is a good naming convention.

The benefits of a good naming convention apply to SAP Profitability and Cost Management (PCM) models just as much as they do to any IT system. In PCM terms, a naming convention is just a set of rules for choosing the names of items. The most usual place for such a set of rules in PCM is for dimension members – Responsibility Centres, Activities, Cost Objects and so on. But you can (and often should) apply the same techniques to other objects within PCM, including model names, functions, item properties, books and layouts.

Every model is different, and some of the reasons for having a naming convention may not apply to you. But these are a few guidelines for you to consider.

Naming dimension members

Within a single PCM model, PCM will not allow you to have two dimension members the same in different dimensions. If you try to create a dimension member that has the same name as a member in another dimension, you will get a message like this:


This is actually a great help; it reduces the risk of loading data into the wrong data cells. Sometimes clashes occur, however. Typically it is things like “Marketing” being used for both an Activity name and a Responsibility Centre name, or the same name being used for both an Activity Driver name and a Resource Driver name.

To get round this, specify names for your dimension members so that they include a short text string to identify what type of PCM entity it is, e.g. “RC” for Responsibility Centres, “AC” for Activities, “AD” for Activity Drivers. This also helps the readability of model rules.

Then you may want to include a short string that uniquely identifies the member within the dimension. Often this is a numeric code, e.g. “000”, “001” etc. You need to make sure this has enough characters for future development. For example, if you currently have 90 members in the dimension, it is usually a good idea to assign more than two digits, so that in future if the model grows to beyond 100 members you can continue to use the same naming convention.

You can also include a natural language string that is readable and understandable to humans. This will help you understand the model during development and beyond; for example, you might have to refer to the documentation to figure out what the Activity “AC_0001” is, but if it’s named “AC_0001_Perform Quality Checks”, then it is a lot easier to understand.

Here is something to watch out for: a bad naming convention can actually make the model less usable, if you are using lots of dimensions and have limited screen real estate. For an example of this, have a look at this screenshot: 


You cannot immediately see enough of each Activity name to know what each one is.

So, when you are choosing a naming convention, do not make your prefixes too long or you will be forever scrolling to the right to try to read the member names.

In many organisations, there is already a naming convention in place for organisational entities such as cost centres, or business outputs like products, and the internal codes are widely known and indeed often used in informal conversations. In that case, it is OK to do without the natural language string. It might be a good decision to do this if it makes it easier to interface your PCM model with other data sources, but only do so as long as you are not going to compromise the readability of your model.

Small, fixed dimensions versus large, fluid dimensions

Some dimensions get new members frequently, and are large. One good reason for having a naming convention for these is that is saves you having to think about what you are going to call every new dimension members.

For other dimensions, however, there are fewer members and they change rarely, if ever: for example, Version and Period dimensions. You do not need to use a structured convention for these. You should be OK to have members of the Version dimension called “Actual” and “Budget”, and members of the Period dimension called “January”, “February”, “March”, and so on. You do not need to have a Version called “VE_01_Actual” or a Period called “PE_01_January”.


Another approach is to use PCM’s “Alias” feature. You can define any number of alternative naming conventions for your PCM system, which allow you to refer to dimension members by alternative names. The aliases defined in your PCM system exist automatically for all models in that PCM system (although you can choose whether to use them or not).

You can define your own aliases, but each PCM system comes with a number of predefined aliases, including DEFAULT ALIAS, CODES and DESCRIPTION.

The usual way of using these aliases is:

•    DEFAULT ALIAS is used by the person or team building the model
•    CODES contain the internal code identifier for each PCM dimension member in the data source
•    DESCRIPTION is user-readable text that is presented to the users in books and reports.

There are plenty of neat ways that aliases help you.

When loading data into the PCM model, you do not need to tell the ETL process which alias you are using. If the source system provides a field that corresponds to the PCM DEFAULT ALIAS, PCM will load it, but if the source system provides a field that corresponds to the PCM CODES, it will recognise the dimension member that you mean, and load the data correctly.

If you do not define a value for the alias, PCM will just use the DEFAULT ALIAS until such time as you give the model the alias that you want.

You can use the aliases in the PCM search boxes without having to tell PCM that you are giving it a DESCRIPTION instead of a DEFAULT ALIAS.  For example, here we are searching for Responsibility Centre that represents the “Edinburgh” branch, but we do not need to know the Default Alias.


We search for “Edinburgh” and PCM automatically finds the RC, even though our naming convention means that “Edinburgh” is not part of the RC name.

Naming conventions within PCM books

The classic setup for a PCM book shows one or more grid objects, each of which is linked to a DataManager object and a keys object. Often, when building books in a hurry, it is tempting to accept the default object names. Book builders may fully intend to come back and make the names more meaningful, but once they have moved on to something else, it rarely happens.


It’s much better to give the objects sensible names, and to use related names to identify objects that are linked, like this:



PCM is not unusual in benefiting from a naming convention. Understanding, stability and ongoing development of any computer system benefits from having a consistent approach to the naming of items. Understanding PCM’s own particular features will help you develop a naming strategy that will allow your PCM models to grow and develop smoothly over the years, making it easier and more reliable to manage your organisation’s costs and profitability.

Bluefin and SAP S/4HANA - welcome to the one horse race