topic Aggregation of load shapes over hierarchical structure of settlement units in SAP for Utilities Discussions

Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Wed, 29 Apr 2015 20:11:52 GMT

Good afternoon everybody,

A client needs to aggregate settlement results over several levels (departments, functional areas, business lines, etc.). My conceptional intent is to build a hierarchical structure of settlement units representing the required structure (4 - 5 levels).

Now my question is if it would be very complicated to select and aggregate setlement parameters of a lower level into specified load profiles at the superior level.

Does this scenario require a ot of programming or can it be achieved through customizing?

Thanks in advance!

P.D.: This is basically what I'm talking about: Hierarchy of Settlement Units - Settlement - SAP Library

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Thu, 30 Apr 2015 03:41:49 GMT

Hi Thorsten,

It would depend on how complex the settlement procedure is. It would involve both customizing and checking the report executing the settlement procedure. Especially the settlement steps of SUMSU and SUMSUALL as these are the ones which do the aggregation.

If you are following the standard settlement procedure then it would work definitely.

Hope this helps.

Cheers,

Rakesh..

sapisurdg.wordpress.com

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Sun, 03 May 2015 22:08:09 GMT

Good afternoon Rakesh - thanks for your reply!

Right now I´m still thinking about some design considerations (market role: Supplier).

1) Allocation of POD´s to settlement units

At the bottom level of my settlement unit hierarchy:

Renewable Energy (own company within the group)
Product types
Regional criteria (south / west / north)
B2B (one or two profiles per business partner)
Contract types (modalities)

=> Since not all of the settlement units belong to a different company but form part of the supplier company, does it make sense, to create service categories and service providers for these?

2) Aggregation of settlement results

At the higher level settlement units, I will do aggregation according to specified criteria according to the following scheme:

Profiles A, B, C of the bottom level settlement unit are aggregated into profile X of the superior level settlement unit
Profilews A, E of another bottom level settlement unit are aggregated into profile Y of another superior level settlement unit

Basically I have to do a selection/settlement on settlement result profiles in order to aggregate them into other settlement results.

Can this be done by adapting the SUMSU and SUMSUALL settlement steps?

Which approach would you prefer - any suggestions?

Thanks in advance!

Thorsten

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Mon, 04 May 2015 04:51:31 GMT

Hi Thorsten,

1.The segregation of the settlement results would be based on the service provider derived from the settlement unit. If its required to have specific output at the levels you have mentioned then this segregation has to me modified.

2. Yes, adapting SUMSU and SUMSUALL would help. Though a doubt with your example. Would Profile A be included in both settlement units. If yes then you would have to play with the selection criteria, as settlement unit takes its selection of profiles based on Supplier,Settlement Coordinator and Distributor(it's optional).

Example for Defining Settlement Units - Energy Data Management - SAP Library

Hope this helps.

Cheers,

Rakesh..

sapisurdg.wordpress.com

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Mon, 04 May 2015 07:35:15 GMT

Hi Rakesh,

1. Does this mean that I allways need specific service categories (and service providers) in order to allocate profiles to specific settlement units or is there another way?

2. Profile A does not go into two different superior level settlement units (bad example). A profile of a lower level settlement unit allways goes up to one specified higher level settlement unit. What I tried to point out was, that several profiles can be aggregated into one or more higher level profiles - they don´t just move upwards one by one. That means, that I will need several cascaded settlement procedures in order to do the aggregation, right?

3. Another thing that I forgot, is the aggregation of price profiles. Can I just allocate a price profile to a second register and aggregate the energy price that corresponds to the load profile on the first register the same way?

Regards,

Thorsten

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Mon, 04 May 2015 09:10:10 GMT

Hi Thorsten,

1. Nope. I guess PoD groups or Service type in Installation would help to that effect.

2. Yes, You would define the Selection Variant appropiately.

3. I haven't seen any Settlement Parameters in the standard config for this, but you can always define new ones.

Hope this helps.

Cheers,

Rakesh..

sapisurdg.wordpress.com

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Mon, 04 May 2015 10:37:43 GMT

Hi Rakesh,

Setting up the whole scenario seems to be a bit more complicated than what I was thinking before.

Anyway, I will think a bit more about possible solutions and play a bit with the data and information I have so far.

Thanks so far for your help!

Thorsten

Re: Aggregation of load shapes over hierarchical structure of settlement units

Former Member — Mon, 26 Oct 2015 14:13:51 GMT

Hello again,

Looks like we´re getting closer to the final solution, now. In order to aggregate settelment results to a higher-level settlement unit, I will have to set up separate settlement parameters for the aggregated results?

The structure looks like this:

So, I will have to duplicate each parameter that I want to aggregate to a higher-level settlement unit?

...or is thera a way to re-use Parameter 1 - 3 for the aggregation step?