SAP EDM Season types issue

[Former Member]

Hi experts,

I am facing an issue with the configuration of the season types.

I need to configure season types for summer and winter, and also define an offset change that applies during summer days. Therefore, offset change and season change must apply at the same time.

Our offset change (and therefore the summer time) happens from last sunday of March until last sunday of October. This means it changes every year (are not fixed dates as those pre-configured by SAP).

Standard offset configuration allows to define flexible rules to identify which are the days, months during which offset change applies, and also allows to define different rules by year. No problem here.

The problem is in the definition of season types. Here we can define which is the period (day and month) for summer and winter, but we cannot introduce the year value during the definition.

This means that if we want to set summer period from last sunday of march to last sunday of october, we can set a summer season type that goes, for 2014, from 30.03.2014 to 26.10.2014, but next year we will have to change the config.

Has anyone faced a similar issue? Is there a way to introduce a more flexible season types configuration that allow us to set the same rules applied for the offset?

Thanks and regards

Rafael

[Former Member · Accepted solution]

Hi Rafael,

Season Type is independent of year for both RTP Interface and TOU Interface.

I can think of a custom scenario(automation) but it would be for a simple case where only Season Type is used. Define a formula which will at runtime check if the date of the incoming profile falls in your season definition,say summer is defined as '1' and winter as '0'. The custom formula can be modeled on FM 'DATE_COMPUTE_DAY_ENHANCED' in function group 'SCAL'. Once it gets the season it can multiply the profile with the season price. So at the end you would have an RTP Interface which will have inputs of a profile and 2 prices(summer and winter) and output of factor(to hold season type:clarity purpose) and amount. Again this works for simple scenarios, for complex scenarios it might spiral.

Also can you please tell where this is defined in ISU. -> "Standard offset configuration allows to define flexible rules to identify which are the days, months during which offset change applies, and also allows to define different rules by year."

Cheers,

Rakesh..

sapisurdg.wordpress.com

[Former Member]

Hi Rakesh!

Thanks for the reply.

Regarding offset standard configuration, it is maintained in the SPRO. Path:

SAP NetWeaber --> General Settings --> Time Zones --> Maintain Time Zones

Here SAP maintains the summer times rules, and variable summer time rules.

The standard configuration says that in Central Europe (CET), from 02:00:00 of the last sunday of march, until 03:00:00 of the last sunday of october, there is a change of the offset to apply UTC +2 (rest of the year is UTC +1). That config applies since 1996, but we can enter new lines in case we wanted to change this logic each year, so it seems a very flexible configuration point.

The problem we are facing is that we want that during the execution of the RTP interfaces, the season types maintain the same logic than the offset change.

As per we have seen, by standard this is not possible (as you mention, season types are independent of year), and it seems strange to us, as this is a basic requirement.

By the way, thanks a lot for your suggestion about a custom formula. Currently we were looking for a more standard solution, in case it exists. In case it does not exist any standard solution for this issue, we will consider to implement what you mention.

Regards

Rafael

[Former Member]

Hi Rafael,

Thanks for the customizing link. I was able to check out the effect with a DST Time Zone.

Probably a similar table (custom) might work for you or you can work with this table only in your code.Would give lots of flexibility.

Thanks,

Rakesh..

sapisurdg.wordpress.com

[Former Member]

Thanks, Rakesh.

This seems to confirm that this requirement cannot be covered using standard functionality.

This looks strange to me, as I guess that in a lot of countries, the season change matches with the offset change...

Anyway, we will analize both option you mention to see how to cover it by costum code.

Regards