Skip to Content

The Conundrum of Time Dimension

Any planning and budgeting can never be done without considering the Time dimension. Time is the essence of all planning, forecasting, budgeting or for that matter, most of the time, any analysis also. It is important to know how the time is handled in any planning related application. In this blog, let us try to see how SAP Business Planning and Consolidation 7.0 version for Netweaver handles time.

First, let us talk about the terminology used in BPC and Netweaver. Fortunately we have an excellent blog at The specified item was not found.  that describes the difference between the terminology for BPC and Netweaver objects. By far, the most enigmatic term is ‘Dimension’. BPC uses Dimension to denote what Netweaver accomplishes through a Characteristic info-object. So a dimension in BPC is equivalent to a characteristic in Netweaver BI and dimension members in BPC are equivalent to characteristic values in Netweaver BI. Taking this further, when a user creates a dimension in BPC7NW, a Netweaver BI characteristic is generated in the BPC namespace for the same. When a user creates a dimension member for that dimension in BPC7NW, a characteristic value is generated in Netweaver BI in the master data of characteristic corresponding to that dimension. When a user creates a BPC application in BPC7NW by selecting a few of the BPC dimensions, an infocube is generated in the BPC namespace that includes all the characteristics corresponding to the selected BPC dimensions. (You can read more about the BPC namespace at A reservation of a different kind – why, what and how of BPC namespace)

All this is good enough but the folks, who are new to the Netweaver, sometimes get confused with the term ‘Dimension’ that exists in Netweaver BI. There is no direct equivalent of that in BPC. So if you are referring to a dimension in BPC, you can relate that to a characteristic in Netweaver. But if you are referring to a dimension in Netweaver, there is no direct point of reference for non-Netweaver folks to correlate. Let us try to clear this obfuscation here and see how it all the pieces perfectly mesh together.

In Netweaver BI, the term dimension is used to group the characteristics. There can be upto 248 characteristics in a dimension in Netweaver BI. (If a dimension in Netweaver BI has only one characteristic, it is a line item dimension). There are 3 fixed or default dimensions in Netweaver BI for Unit, Time and Datapackage. There can be 13 more user defined dimensions available in Netweaver BI for each infocube. This means that there can be a maximum of 13*248 = 3224 characteristics possible in an infocube. The characteristics that are included in the Unit, Time and Datapackage dimensions of Netweaver BI, are generally SAP delivered characteristics. So the Time dimension in a typical Netweaver BI (non-BPC) infocube may have one or more of the SAP delivered time characteristics such as 0CALMONTH, 0FISCYEAR, 0FISCPER, 0CALWEEK, 0CALDAY etc. These time characteristics are grouped together in the Netweaver BI Time dimension in a typical Netweaver BI infocube. The SAP delivered time characteristics follow some specific set of rules regarding the use and master data maintenance of those time characteristics.

In BPC, however the story is different. BPC has a BPC dimension type called time and a user can create any dimension of the type time and create dimension members for the same. So what should the system do when it tries to generate the characteristics for such user defined BPC dimensions of the type time? Should it create a new general Netweaver BI characteristic and include it in the existing Time dimension on Netweaver? Should it map one of the SAP delivered time characteristics to the user generated BPC time dimension? Or do something else? Every option is fraught with making huge trade-offs. Well, what we have in BPC7NW falls under the category of ‘something else’ and that is: to create a new characteristic and create a new Netweaver dimension (named Time) as well. There are several reasons for this. Firstly, this is the path of least resistance. If we don’t use any of the SAP delivered time characteristics and time dimension, we are not bound by the rules governing them. Secondly using a generated characteristic and generated dimension is in line with all other BPC dimensions. Thirdly, we are not compromising the end user flexibility to create as many user defined time dimensions and dimension members as the business needs without having to worry about any IT imposed restrictions. Finally, even if we have two (or for that matter even more) Netweaver dimensions named Time, the BPC end user won’t be bothered about them. He or she won’t even see them unless he/she goes to the BI backend. Hence there are two Netweaver Time dimensions in the infocube for Apshell. Let us see how all these things look like in the final product:

Here is the time dimension in BPC in Apshell:


The generated characteristic for this BPC time dimension is as follows:


The planning application in the Apshell that has this time characteristic looks like the follows:


We can see that there are two Netweaver Time dimensions here. One that is a default Netweaver Time dimension (you can see this dimension between Data Package and Unit dimensions) and the other, which is a generated dimension named as Time. Also we can see that the generated characteristic is included in the generated Netweaver Dimension and we don’t use any SAP delivered time characteristics in the Netweaver Time dimension. When we copy the Apshell to another Appset, this structure also gets copied (ofcourse with a new set of generated characteristics). It is very important to note this point about time dimension especially if we are trying to load data from into BPC generated infoobjects and infocubes using Netweaver ETL tools. We should use the time characteristic that is generated by BPC in the BPC name space and not the SAP delivered time characteristics. If we are loading data from other non-BPC infocube in the SAP EDW, the SAP delivered time characteristics should be mapped to the BPC generated time characteristic in the BPC namespace.  The best part of this is that all this is handled automatically and there is practically nothing that any Netweaver BI administrator has to do to ‘monitor’ this.

Fathoming the time dimension was not very easy even for a person of the caliber of Einstein; but even he would not have imagined integrating multiple time dimensions from multiple applications with different capabilities and present a unified front to the end users. We should give credit to BPC7 NW for accomplishing that!

You must be Logged on to comment or reply to a post.
  • Thanks for enlightening us with latest update on BPC NW. It makes sense to have separate characteristic on Netweaver side to represent BPC time dimension. At this point, I think it would be very helpful to have a blog on reporting aspect with actuals being in SAP terminology and plan being in BPC terminology. For example, if January 2009 is represented as ‘2009.Jan’ in BPC world and ‘2009.001’ in SAP world, then how the actual/plan reporting will be handled on BI side?

    Also, when we create hierarchies in BPC dimension how will they be stored on Neaweaver side: just as another attribute or Neaweaver hierarchy?

    Thanks, Rahul