Weekly time shift with Attribute transformation

[Former Member]

Hi all,

Our requirement is to be able to display the previous year's data on a week or technical week level.

The issue is that the number of weeks / tech. weeks is not constant each year, so a simple shift of 52 weeks or 62 tech. weeks is not accurate.

Does anybody have a solution?

Best regards,

Ivan

[Irmi_Kuntze · Accepted solution]

shifting with technical week does not work from business perspective in the first place, as your technical week last year will be 100% different from this year - it cannot work, has nothing to do with the technical solution but just with calendars.

Working with calendar split: here the challenge is that some years have 52 and some have 53 weeks. Usually a simplification by using 52 weeks is sufficient as that is most cases. If that should not be the case for your project, you can try with working with an integrer attribute you add to PERIODID, and which you would need to load. But still you would face the issue that if you shift "1 year" , for two years in a row one may have 52 and one 53, so which value do you want to take? You cannot skip one week or squeeze in one that does not exist, so you need to decide on one of the 2 values anyhow.

[Former Member]

Dear Irmhild and Achal,

Many thanks for your answers. Here is the solution we've finally implemented: It is a dynamic attribute transformation at calendar week level (PERIODID4 in our case), close to what Irmhild had suggested:

• We create a new shifted planning level (at calendar week)
• We define PERIODID4@shifted PL = PERIODID4 + KF1
• KF1 has either a value 52 or 53, depending on the year. This is simply defined by an IF condition, where PERIODIDs for years with 53 weeks are hard-coded for a long-term horizon
• The reference KF to be shifted (request level = shifted PL) has an additional IF condition to zero out the value in all PERIODIDs corresponding to week 53

As a result:

• The yearly shift (52 or 53 weeks) at calendar week level is always correct
• Week 53 value in the shifted KF is left blank, so as to keep the yearly sum equal to the previous year in the reference KF
• Week 53 value from the Reference KF is removed from the shifted KF, which has only 52 weeks --> This level of inaccuracy is acceptable, given the low frequency of this event (every 5.6 years on average)

Illustration

Best regards,
Ivan

[achal_gautam2]

Shifting a technical week by 62 technical weeks may not be accurate everywhere. The only option I see here is to do attribute transformation at higher level and disaggreate it to technical week level.

Regards,

Achal