From this point the article becomes technical!
For the time being, let’s get around the gap. Below is the solution I suggest to close this gap, even if it is not ideal.
Important statements are:
- “We want the ability to create many parameters, which should be usable in formulas, and maintainable by any authorized person.”
- “Formulas are made of operators and operands.”
- “Operands can be key figures, attributes or constants.”
- “We don’t want any constant (not agile).”
- “We can use key figures or attributes to make our design more agile.”
- “Oops, key figures are only numeric, so we will not be able to set a value = JAPAN.”. I suggested to SAP to allow string-based key figures. Rejected. “
- “Ok, we now have the attributes option left, which will make our day (isn’t it Clint Eastwood?).”
- “But attributes are linked to planning levels and master data types!”.
So, adding attributes is a touchy option, particularly if the IBP implementation already exists. That means changing master data types and integration jobs. Each solution has a cost; however, the proposed idea keeps this change as small as possible, although opening your design for 10, 50, 100 flexible parameters.
Adding attributes is not global to a planning area. Attributes are attached to master data types like product, product-location, etc.! Obviously, if we need a parameter that depends on Product Master, we can add this as an attribute to the Product Master.
Basically, we now have two options to extend a global design with many parameters.
Option 1 – The Robust One:
We create a new master data type (MDT), say PARAM, made up of the many attributes we need as parameters, plus a key attribute.
Example based on previous figures:
- ParamKey
- Customer
- Lowrebate
- Highrebate
With the Manage Master Data Fiori app, we maintain one single record of this MDT.
We insert the new PARAM MDT in our planning area, and we assign all attributes (parameters) to all our planning levels. Warning, we set the ParamKey of the MDT as a root attribute in all planning levels. If we do this in an initial IBP design it should not be an issue, although a little more to do. If this is for an existing implementation that also means a lot of change as all planning objects (PLOBs) have to be reconsidered with the ParamKey. As we have only a single record of PARAM, the root for ParamKey is unique and does not multiply the number of PLOBs.
From this point, all key figures in this design can use the parameters freely. Job done but costly!
Option 2 – The Smart One:
With this option, I don’t wish to alter the PLOB structure (root) of the many planning levels. I wish to keep things slim.
The question therefore is: Which dimension is the most used one in IBP? Product, indeed!
What if I attach to the Product MDT just one additional attribute to be ParamKey identical to the one defined in the MDT Param?
What if I attach to all planning levels, the parameters defined in MDT Param; however not changing any root?
If you do so, the planning area activation fails with “PLOBID blabla ….failed” ☹
The trick is to create an intermediate Virtual MDT between Product and Param MDT, then attach to the planning area the Virtual MDT, not the simple MDT. By doing so, the root resolution is working and active. Full success!
Cherry on the cake, the ParamKey can be multiple, defining different parameter sets, without adding any additional PLOB.