on 2025 Feb 04 6:18 PM
Hello experts
I will appreciate your opinion and advice with an issue I'm having. I have checked for any previous (similar) questions and SAP website with no success
I'm trying to make a copy of last year sales into a stored KF that I will be using for a disaggregation expresion.
The new stored KF has the same Planning Level as the IBP standard ACTUALSQTYPRIORYEAR (WKPRODLOCCUST; Week (technical)). So I'm expecting a mirrored copy of the value. Still, when I look in Excel the values are shifted by 10 weeks.
The ACTUALSQTYPRIORYEAR is reading correctly offset 52 periods back
The IBP standard ACTUALSQTYPRIORYEAR uses a helper keyfigure which is 'PERIODID5 + 62'. This is the only hint that makes me believe that the extra 10 period shifts comes from 10 + 52 = 62. But if that would be the case then ACTUALSQTYPRIORYEAR would have the same issue and it does not.
Question:
a.- Why is it that I cannot make a identical copy without shifting?
b.- If the reason is in the helper key figure used to offset (PERIODID5 + 62), why is that not at issue with IBP Std ACTUALSQTYPRIORYEAR?
My plan B is a copy operator from ACTUALSQTY using 'Period Shift' = 53 in the Time Setting of the Copy Operator and it does the copy correctly. Still for completeness and knowledge I would like to understand why the other approach does not work
Thanks in advance for taking your time
Best regards
Roberto
Request clarification before answering.
Hallo Roberto,
thanks for providing the additional information. Looks like we are getting closer to the root cause for the issue.
I see from your new screenshots that you are indeed using a customized time profile where the technical week on level 2 is called "fiscal week". This as such shouldn't be an issue. However I now wonder how these time periods have been generated in your case? The standard approach for the technical week is that you have two buckets for a week that is shared between two months. You can see this from the screenshot that I posted yesterday (where I did a drill-down to this technical week level). With this approach you get 62 buckets in a typical year (normally you have one extra bucket for each of the twelve months, except for cases where the month ends on a Sunday and so there is no split).
Can you confirm that in your case the "fiscal week" was loaded without considering this split? Then you would have indeed only 52 buckets on your PERIOD5 level. This would explain the behavior of the system, as when you use your "fiscal week" in the copy operator, the system is expecting 62 buckets (as you already showed from the calculations in ACTUALSQTYPRIORYEAR).
If this assumption is correct, this would also mean that you had selected "calendar week" in your very first screenshot where you showed the data from your planning view. Is this correct? So there the key figure ACTUALSQTYPRIORYEAR was calculated in real-time on PERIOD4 level with using 52 buckets and you got the result you were expecting. You may try to regenerate this using a drill-down on your fiscal week and should see the difference.
Indeed a solution in your case then could be to do the copy to ZSTOREDACTUALSQTYPRIORYEAR using the calendar week as copy level.
best regards
Bernd
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bernd
We use technical week as our we map our Fiscal Year in IBP and we need to differentiate it from a calendar week. There are two specific reasons: a.- The period is a fiscal period, it does not necessarily end on the end of the month but the whole year follows a 4/4/5 weeks pattern per quarter. b.- The year ends on the 30th of September and we might that its a mid week day, in which case we have a classic IBP technical week.
I will follow your advice and use calendar week as a copy level and I will revert back with the results
Thanks again for your help
User | Count |
---|---|
7 | |
5 | |
3 | |
3 | |
2 | |
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.