on 2021 Jun 06 1:30 AM
Hello Experts,
I am looking for a way to calculate a fill rate calculation that includes carry on unfulfilled demand, I want to the formula to calculate the same way wether the user request it at the monthly level (base planning level), or Quarter, or years.
I figured the formula was easy :
The problem: I haven't been able to make this calculation scalable, meaning, holding true at the request level as well. The reason is in order to do so, I have to make an offset at the request level calculation, which I know it's not possible.
My question to everyone that can help, Is there a way to this in IBP or should I just give up on this idea and just divide this calculation in as many key figures as time levels I have?
To give you an example I have attached an excel image

Thank you!
Request clarification before answering.
Hello Eddy
As you very rightly said that you are unable to use the formula at request level because you are using the PERIOD_SHIFT function in the KF expression which as of now doesnt support to be written at request level and hence you cant write your fill rate calculation at the request level.
PERIOD_SHIFT function has been introduced to get rid if the complexity involved in periodid transformation process that was used predominatly before this function came. Hence my suggestion is a follows.
Instead of using PERIOD_SHIFT please use PERIODID tranformation for the calculation of the P-1 shortage to be updated in the target KF. example using transformation like PERIODID3= PERIOD3+1. If you do that you dont need to calculate the previous period shortage using the PERIOD_SHIFT function as the system will dynamically update the last bucket shortage based on period id transformation. Hence you can use your fill rate calculation at request level by removing the PERIOD_SHIFT functions limitation.
Let me know if that works.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ayan,
Thank you for your reply and advise. Unfortunately, I tried and it didn't work, the problem is that I also want to do an offset the Last Period Aggregation level.
When I do the attribute transformation for Periodid3= Periodid3 +1, it's doing the offset yes and I can use the KF at the request level. However, the calculation will still be wrong because the aggregation is still falling in the wrong quarter

in the example, I am expecting the key Figure Last Period Shortage in Q3 21 to show a value of zero (the shortage of the last month of Q2 21), and Q4 21 to show 900 (the shortage of the last month of Q3 21)
A point to note here is that i'm using the IBP function IBP_LPA for last period aggregation.
Not sure If I were to use the old complex way to do LPA would bring me the results I wish.
Cheers,
Hello Eddy
I get your point. Since you are uisng the LPA function and the shortage KF is at a different planing level where the time period in not qtr. Hence the only possible solution for you is to have multiple shortage KF based on the time period that you wanrt to use. for example if you want to see the data and CALWK, MTH and QTR level then you need 3 different shortage KF where the base planning level should be CALWK, MTH and QTR respectively.
Similarly you need 3 different KF for calculating the last period shortage offset. Here you can use PERIOD_SHIFT as you need to do the offset at the respective base planinng level only.
Although you can have 1 single KF to show the fill rate at any level be it week , months or qtr, but you cant use the calculation at request level as you need to give the expression at 3 different levels where 1 is week , months, qtr and so on.
Hi Ayan,
I agree with you. I haven't found another way than to do 3 KF, not super elegant but we were always going to have limitations.
Thank you for the time investing in analyzing this problem with me!
| User | Count |
|---|---|
| 8 | |
| 7 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.