This article explains the basic principles of Attribute Transformation in SAP IBP and will highlight the basics for implementing this feature, with few examples, as to where this can be used.
We will also highlight some IBP planning scenarios like displaying last year’s data, weekly or monthly offset calculations, displaying dependent demand from IBP supply to IBP demand and how this can be achieved using Attribute Transformations in SAP Integrated Business Planning.
What is an Attribute Transformation?
SAP IBP provides a special feature called Attribute Transformation, that allows us to convert the values of any attributes based on certain calculation expressions.
Going into the flashback, where we used auxiliary key figures in SAP APO macros to calculate date offsets (e.g. Sales Year -1), SAP IBP, provides an similar, but improvised method, called Attribute Transformation, which can be used to achieve similar outputs. Please keep in mind, that Attribute Transformation in SAP IBP, is capable of achieving much more complex data transformation, than what we are using, in this article, as examples. I won’t be covering those complex examples here, as those will be highly technical in nature and requires deeper understanding of IBP period ID calculations and Key Figure expressions.
Just to give a heads up, if we try to look into the whole concept and idea of attribute transformation, from an SAP binocular, it will be too vast for our present understanding. What we are seeing at present, is even less than the tip of an iceberg. Attribute transformation is a sleeping giant that will surely redefine the future of custom development, as we see it today.
In a layman term, by using Attribute Transformation, we do not need to store data in multiple key figures, which helps reduce data redundancy, and makes those calculation pretty dynamic in nature, thus reducing batch jobs & macros efforts and execution time, to achieve the similar results.
For example, we will develop a scenario where we want to offset and aggregate the value of a particular key figure to a different KF, based on the offset value that we maintain in a 3rd key figure.
This is KF1 which is a stored KF that we will use as an input for offset
This is KF2 which is a stored KF which will contain the no. of buckets that needs to be offset
This is KF3 which is a calculated KF which will show the value of KF1 after the offset.
How does Attribute Transformation work?
Let us understand the working principles with a basic requirement, where we need to display the offset quantity of KF1 into KF3 based on the offset value maintained in KF2. So, for that we have to do the following.
Create a new planning level (e.g. CWKPRODLOCAT5) which is identical to the base planning level for KF1 & KF2.
Create a period ID transformation as shown below in the picture.
Since we will be using KF2 as a basis for determining the offset, hence we have used the KF2 (MDPWEEKLYOFFSET) in the above calculation. IBP provides flexibility to use hard coded numbers, KFs and attributes that have numeric data type.
Since we are using KF1 and KF2 as an input for the transformation, hence we need to select both the KF’s as input.
The data displayed in KF3 is based on the KF1 value that has been offset based on the offset value mentioned in KF2.
Power of Attribute Transformations
A lot has been said about Attribute Transformation on time based horizon. Now let’s talk about what other things we can achieve. As we can transform a time bucket, Attribute Transformation can be used to transform any other attributes like Product or Location. With Attribute Transformations, we can convert any attribute, be it either Time, Product, Location or any other dimension. Few examples of possible use of Attribute Transformation are provided below.
Displaying historical sales in the past & forecast in the future timeline in a single key figure.
Displaying static attribute values (e.g. UOM, Safety Days) as time independent key figures.
Many experts & articles says, that Attribute Transformation is the beginning of the end, to custom developments. Even many prospective clients think that SAP IBP will bring an end to custom development era. As an objective choice, the answer is yes, because the ability to write custom code in IBP is almost zero, with an exception of ‘L-Codes’, which only SAP can write and deliver, as of now. But deep down, I believe it cannot be the end of custom developments. Although features like Attribute Transformation, Operators and Key Figure expressions all play a role to minimize the scope for custom development, by transforming data, innovative configurations, to meet custom business requirement. But here are my questions to challenge this
How long will SAP hold the L Script, in their own cradle? Down the line they will have to open it for all.
In the area of Operators, either SAP has to be really prompting to release new operators or allow customers to write their own.
A rarely explored area, is integrating local key figure data in the database. Either SAP need to develop something or open up space for others to write some good integration codes to sync EPM local KF and EPM global KF.
So, to conclude, we all have developed many custom enhancements in SAP APO ranging from simple routines to highly complicated programs / BADI, where we needed to change time buckets, update CVC or navigational attributes or enabling CIF exits to manipulate master & transnational data. However, with IBP, we can manage most of the custom developments by innovative configurations in our planning area, but that is not going to suffice the ever changing custom requirements which are very very industry and process specific in nature and keeps on changing over time.