Copy ACTUALSQTYPRIORYEAR values are shifted by 10 weeks

[robvid]

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

[BBRI]

Hallo Roberto,

interesting case, so I tried to reproduce it. Now here it works as expected:

So I assume there is something different or special in your configuration.

Two areas that I could think of:

• You haven't posted the setup of your original copy operator profile. Maybe there is something odd here?
• However more likely: From your last screenshot actually it looks that your planning area is using a customized time profile (as fiscal week isn't in the standard profile). Actually my current thought is that the issue is coming from here and that due to this during the copy the system believes that you would be at the PERIOD5 level.

[BBRI]

.

[dlellou]

Roberto,

You are on one of the touchy fields in IBP. 62, 52, 12, 53, etc when it comes to timeshift.

You have 2 options for perform timeshift

1- Using IBP_PERIODSHIFT allows shifting in the number of periods of the base level of the keyf itself. In your case techweek hence no chance as  10 techweeks are often < 10 weeks. Either you decide for an empirical 11 tech weeks check that in average in outlook you could figure out 10 calweeks relate most of the time to 11 techweek. THis is my preferred as this is supported with a very simple formula

2- You set an attribute transformation (ATTTRF), which I am opposed because of maintenance and complexity, to shift the value. THere in SAPIBP1 former version it was done like you explain with 62 on techweek plevel, as in average 1 year = 62 techweek. Not any better to option 1 in fact and much more complex. However may be with ATTTRF yu could try the transfo on the CALWEEK level, maybe this works but I have serious doubts and personally I would not invest 10 minutes even

Then Option 3, that is not realtime unfortunately. Use Copy operator to shift by 10 calweek. Not sure again you can define CALWEEK whereas the keyf is TECHWEEK

Then Option 4. Discussing with SAP development last year, they will soon propose an alternative for ATTRTRF based on a formula I suggested instead of the current complexity. Here maybe there would be some goodies. Don't know yet.

Cheers, Daniel

[BBRI]

Good feedback. I'd like to add one more option:

Option 5: to populate ZSTOREDACTUALSQTYPRIORYEAR via CI-DS. Of course this option adds quite some overhead, but at least you could precisely control the number of periods involved (at least if you ignore the fact that some years have 366 days)

[dlellou]

Indeed, but as stated another dimension of solution for a perceived simple need.

[robvid]

Thank you BBRI. 

Here is the screenshot of the copy operator

It uses Technical Week. After checking the Standard Copy Operators and the custom Copy Operator (built by the consultant) they all use Fiscal Week as well. I wouldnt expect having to change this to ...Calendar Week. Still if I use Calendar Week instead the values are aligned .... but why ? Why is not a copy from Technical Week of Prior Year into corresponding Fiscal Week of the target KF?

'However more likely: From your last screenshot actually it looks that your planning area is using a customized time profile (as fiscal week isn't in the standard profile). '

You are right and my mistake I posted the screenshot of the IBP1 Model. Here is our Time Profile

and the Time Attributes of the Planning Level

I guess that in the example (screenshot) you posted it was a simple copy operator ...?

Anything regarding our Time Profile I would expect that the standard KF Prior Year will have the same impact and still the shifting of the quantities and dates are correct for this one. Then why a copy of this one into another would shift the figures by 10 weeks?

[robvid]

Hi Daniel 

Thanks for your suggestions. I can get the results by using the copy operator from the Actuals Key Figure. All I had to do was use the Period Shift and it would be equivalent but easier than the Prior Year Key Figure. You might say, I have a solution then I have no longer a problem. I still choose to post the question because I couldnt/cant find a reason why using the copy from Prior Year to the Stored KF the values are shifted by 10 weeks and are not a time phased mirror. As shown on my excel screenshot Prior Year is shifted as expected but the Stored KF which is a copy of the former is not 

I wonder if its anything mentioned by BBRI

Thank you both for taking the time and any other thoughts comments on this 

Best regards

Roberto