In our day to day operations and IBP implementations we always come across to use the last period aggregation (LPA) concept for Key Figures and SAP has also explained the configuration with Note.
In this Blog , I would make an attempt to explain the one use of LPA with an example. I would try using standard KF of Projected Stock in my example.
The projected stock is the stock of a product that is expected to be available at the location at the end of a period.
So if an aggregated period let’s say a week spreads over two months (so two technical weeks) the correct projected stock will be the value of last technical week.
For eg: If Week 9 has two technical weeks 09a and 09b :
The correct values will be to show the week 09b values for week 9.
Now let’s try decoding the same piece by piece from config perspective:
First we see the Calculation Definition of Projected Stock KF . Kindly note only the highlighted ones play part in LPA. Rest to be used in some other Calculations.
Now Let’s say the Period id for Tech week 09a = 53071 and for Tech Week 09b = 53072.
First we need two planning levels typically the copy of your planning levels at which you want to display your Projected Stock values. For eg WKPRODLOCUOMTO
The First One . Remove all other time elements and keep only PERIODID. This is because we want to assign each technical week’s values to it’s relevant period id.
( Will see later)
The other one similar to WKPRODLOCUOMTO with all attributes but having PERIODID as root. This will be used to aggregate the values and ensure that all the attributes of WKPRODLOCUOMTO are included in this level. ( we will see later)
Now Let’s see the First Calculation which will be used for LPA:
In this step we say that for each bucket’s value in Technical week , we will use maximum of that value. This step is just to read the value at PERIODID level.
So After this step (nothing changes as max of the values are same) : PERIODID (53071) will hold 915 and PERIODID(53072) will hold 830 at PERPRODLOCUOMTO1 level. Please note that Value at WKPRODLOCUOMTO is same as shown in Technical week levels.
In the next step we assign these values to a different planning level : This is a simple assignment of the KFs but it’s the Input KFs which will make a difference.
We see that HKFPER@PER1 is also assigned as an input here.
So Let’s check what’s the reason for this.
This KF at Planning level WKPRODLOC equals the PERIOD0 (Technical week’s Period Id values) which in our case are 53071 and 53072. And at PER planning level and when we read it on week time level where week 9 has two period ids , it takes maximum of these two period ids so only 53072 goes as maximum of 53071 and 53072.
So HKF@PER = 53072.
Attribute Transformation Part : When we read any KFs at PER1 level ( at week level) it defaults to HKPER@PER values. Which in our example will be 53072 From above step.
PER and PER1 are two identical planning levels used in attribute transformation with PERIODID as root.
So with this configuration , The input KF HKFPER@PER1 (At week level) will read the values stored at PERIODID 53072 and hence the out put of HPROJECTEDINVENTORY@PERPRODLOCUOM2 will read the values of PROJECTEDINVENTORY for period id 53072 which is 830.
Next we assign the above values at request level for helper KF.
The Final output of our original KF Projected Inventory at request level (at week level) will be read from request level of helper KF. In this way we can avoid to use any Avg, Min , Max and Sum (between the values 830 and 915) .Any of the other aggregation mode for this KF which will show wrong output. The aggregation mode will be then be set as Custom.
Whenever uses tries to change the planning view or read at aggregated level , the KF will read from helper KF , which is using last period aggregation and shows the output of maximum of the period ids (which is always last period in the aggregation).
Hope this helps. For more detailed Configurations kindly refer to Note referred in the blog above.