Settlement by rate category

[Former Member]

Hello everybody.

Has anyone of you ever made a settlement by rate category?

The tables EASTL and EASTS contain the rate category on installation and register level. Which settlement step would be the best to adapt for this requirement?

Thanks in advance.

Thorsten

[Former Member]

OK, more likely the relevant table to consider is EANLH where the rate category is stored for each installation.

During settlement step ASSIGNPOD the metered and synthetic load profiles are stored in the corresponding tables EEDMSETTLIN and EEDMSETTLUF.

A first approach would now be to also select the rate category during ASSIGNPOD and store it in the table. That would require to add a custom field to both tables changing the SAP standard implementation.

If anybody has an idea or consideration about that approach, I really woul appreciate it - since I´m not sure whether this would be the best way to do it...

Thanks in advance!

[Former Member]

Hi Thorsten,

Nope never seen settlement on basis of rate category.

Yes settlement step assignpod is what you would need to copy and modify. Data in the standard tables should be filled in based on your criteria of Rate category(Interval/Non interval). With this you would NOT have to make any other changes in other settlement steps.

Hope this helps.

Cheers,

Rakesh..

sapisurdg.wordpress.com

[Former Member]

Thanks for your reply Rakesh,

The command to select the installation then may look something like this:

DATA l_tariftyp  TYPE eanlh-tariftyp.
l_tariftyp = '2.0A'.


    SELECT z~settlunit a~int_ui c~ab c~bis z~ab z~bis
           a~anlage d~service b~profrole b~profile c~usefactor
           a~datefrom a~timefrom a~dateto a~timeto
      INTO TABLE y_iufactor
      FROM   eedmuisettlunit AS z INNER JOIN euiinstln AS a
        ON  z~int_ui     = a~int_ui
        AND z~bis       >= a~datefrom
        AND z~ab        <= a~dateto
          INNER JOIN elpass AS b
          ON  a~anlage     = b~objkey
          AND a~dateto    >= b~ab
          AND a~datefrom  <= b~bis
            INNER JOIN eufass AS c
            ON  b~objkey     = c~objkey
            AND b~loglprelno = c~loglprelno
            AND b~bis       >= c~ab
            AND b~ab        <= c~bis
              INNER JOIN eanl AS d
              ON c~objkey = d~anlage
                INNER JOIN eanlh AS e
                ON d~anlage = e~anlage
      WHERE z~settlview  = l_settlview
      AND   z~settlunit IN surange
      AND   z~settluse   = 'X'
      AND   b~objtype    = co_objtype_instln
      AND   c~objtype    = co_objtype_instln
      AND   b~profrole  IN rolerange
      AND   b~profile   <> space
      AND   y~datefrom  <= x_dateto
      AND   y~dateto    >= x_datefrom
      AND   z~ab        <= x_dateto
      AND   z~bis       >= x_datefrom
      AND   a~datefrom  <= x_dateto
      AND   a~dateto    >= x_datefrom
      AND   b~ab        <= x_dateto
      AND   b~bis       >= x_datefrom
      AND   c~ab        <= x_dateto
      AND   c~bis       >= x_datefrom
      AND   d~service   IN servrange
      AND   e~tariftyp   = l_tariftyp
      AND   z~bis       >= e~ab
      AND   z~ab        <= e~bis.

As a consequence the rate category has to be assigned over the whole settlement period. If the rate category changes within the settlement period, the installation will not be selected, right?

Regards,

Thorsten

[Former Member]

Hi Thorsten,

Yes, changes has to be done considering the periods. You can have a test case on this.

It don't have access to a system but I think one of the time slices (in case changes are done once ) would come in the selection. Do check on the performance of the code.

Cheers,

Rakesh..

sapisurdg.wordpress.com

[Former Member]

Hi Rakesh,

As far as I´ve understood the concepts, it will be necessary to implement a settlement procedure for each rate category, right?

A more convenient approach would be to define one settlement parameter for each rate category and then aggregate all load profiles selected by their corresponding allocation roles into the result profiles corresponding to the rate category.

So, one settlement procedure for all rate categories containing one settlement step for each rate category.

Instead of selecting the installation according to the rate category, I would need to select and aggregate the rate categories of all installations that are assigned to a settlement unit.

Could you give me some hint on how to achieve this?

Thanks!

Thorsten

[Former Member]

Hi Thorsten,

Sorry for the delay in replying.

As you have mentioned go with this "one settlement procedure for all rate categories containing one settlement step for each rate category."

If the Rate categories can be grouped probably by Billing class or MRU or nomenclature you can then define less settlement steps.( you can have more importing and exporting settlement parameters for each sub rate category). In the settlement procedure you would need to assign profiles or roles for each parameter , so be prepared for that.

This step would work after the ASSIGNPOD step as you would have the data in the tables for settlement.(you had mentioned some tables earlier). Once settlement is done the profiles allocated to the exporting parameter would hold your data and can be sent to external parties(customizing).

Method 'process' has all the code for processing in the SAP standard classes, you need to work on the same custom

New rate categories(if created after project closure) would require new development of settlement steps and parameters.

------------------------------------------------------------------

The BAdi is for custom allocation. Say I have modified my PoD to include the Rate Category in its name.(just an example not recommending as Rate category changes,PoD doesn't). So when this BAdi is called I can call for a check on the PoD name and allocate the master data in custom table on Rate Category basis. As custom table is involved all subsequent steps would have to be custom.

-----------------------------------------------------------------

Hope this helps.

Cheers,

Rakesh..

[Former Member]

Thanks a lot for your answer, Rakesh!

I will think about it and tell you later.

Regards,

Thorsten

[Former Member · Accepted solution]

Maybe BAdI ISU_EDM_UI_SETTLUNIT is of help as well. Here you can change the automatic allocation of PoD's to settlement units. So you might create settement units as per your rate categories and then have PoD's allocated to them through this BAdI.

[Former Member]

Thank you both for your answers!

Currently I´m thinking of defining a settlement parameter named just as the rate category and then do the settlement for each of those rate-category-related settlement parameters.

This way It would easily possible to adapt the implementation to changing requirements.

Another requirement is to read some product-specific parameter from the installation operands (table ETTIFN). I think this would be pretty much the same since there is a key field "ANLAGE" in that table, too.

As for the BAdi, mentioned by Erik, I still don´t know how this works - since I still have no experience with this technology. If I understand you right, the idea would be to create a settlement unit for each rate category and then select the relevant profiles, right?

If so, I might not be able to use this approach, because I need to do an aggreagation based on company specific criteria.

Well, I will go thinking about the best solution and try a bit....

Thanks again for your help!

Thorsten

[Former Member]

...one more thing: The aggregation scheme looks like this:

So, it doesn´t make much sense to build settlement units for product type or rate category - I would end up with 45 settlement units per department (currently there are four departments).

That means,that I have to set up settlement parameters and steps for each of these criteria which in turn will be applied on each settlement unit. I was thinking about customizing settlement parameters, that are named just like the product and rate category respectively to avoid the need for so many settlement units.

But I think it will be necessary to implement one settlement unit for each product type - for each department in order to do the aggregation.

Would you think the same way or are there any alternatives?

Regards,

Thorsten

[Former Member]

Hi,

I was thinking of using method "Me->GET_PARAMETER_TEXT" to get the parameter name (which would be the rate category) thus selecting the corresponding installation (e~tariftyp = l_tariftyp).

The same concept would apply to product parameter taken from table ETTIFN.

This way, I could easily adapt the selection via customizing - what would you think?

What I still don´t know is, how to do the aggregation - would I allways need a settlement unit for that? If so, the data model will be really complex...

Regards,

Thorsten

[Former Member]

OK,

We´ve been talking here in the office about requirements - and integration with IDE.

What I (almost sure) will have to do is an aggregation of profiles for the product type and rate category related settlement parameters defined, that means for each settlement unit one parameter for each rate category and one for each product type.

The disadvantage is that I can´t aggregate according to rate category within product types - only for rate category and product type independantly of each other.

It looks like, that the service providers specified for settlement (installation level) need to correspond to service providers exchanging information within the market.

Am I right or do you know a better solution for this?

Regards,

Thorsten

[Former Member]

Settlement parameters are either profiles or individual values. Not sure on how you plan to use rate category as parameter.

Having a settlement unit per rate category would indeed be quite a lot of settlement units.

What I would think of is having a profile role per rate category.

Department could be Selection Variant or higher level settlement unit.

Product would be settlement unit.

Each rate category would then be a profile role on the settlement unit.

You can then have settlement steps that aggregates per rate category.

I would copy/derive class CL_ISU_EDM_SETTLSTEP_0003 to aggregate to the correct profile role on the settlement unit.

You might need some customer specific table to map rate category to profile role.

For each rate category you would have a settlement step, all based on this same class, output to settlement parameter with the role as rate category.

Above is not ideal as on addition of rate category you would need to create a new settlement step and update the settlement units and procedure.

Not really dynamic.

Maybe you can make it a bit more dynamic by reading rate categories at start of settlement procedure and looping over them. That would save changing the settlement procedure but still require a new step and update of settlement units.

[Former Member]

Hi Erik - thanks for your answer!

Yes, the approach of one settlement unit per rate category does not make sense, at all.

Like you suggest, I think the best solution would be, one output profile for each rate cagtegory assigned to the settlement unit. Then one settlement step for each rate category.

The result is then an aggregation of profile values by rate category for each settlement unit.

The client had been using Excel tables for settlement and now wants a similar functionality in SAP. Therefore, he requires a break down of the overall load to subsequent levels based on various criteria - like rate category, product type, regional criteria, cost type, technology (solar, wind, cogeneration), etc.

I think, in order to meet all the requirements, I need to dedicate some time and effort to the conceptional design of the settlement unit structure.

Since an energy plant can be categorized by various criteria at the same time, e.g. rate category, technology and product, I thought of different settlement views. One Installation for each criteria assigned to the same POD. Different service types (contracts) at installation level permit assigning the POD to different setlement units with different views. So I can aggregate by each criteria into the output profiles of the settlement unit.

The next step is then, aggregating upwards into total load shapes - just like in Excel. There´s a lot of custom development, I think. Among other tasks, we have to avoid summing profile values twice during aggregation which would lead to incorrect totals.

Well, there´s still a lot to think - thanks again for your help!

Thorsten

[Former Member]

Good afternoon everybody!

After some analysis, I´ve come to the conclusion that I will need some 136 result profiles per settlement unit. That´s indeed a bit scaring!

Another problem is, when assigning two installations to each POD in order to do a selection by product type as well as regional criteria, I can not easily add a superior settlement unit that aggregates quantities of both views.

For example on the bottom level there are two settlement units: PRODUCT view and REGIONAL view. On the superior level there is one settlement unit for the view BUSINESSLINE. Allowing additional views by creating a custom type of settlement unit doesn´t seem to work neither.

Looks like the only solution would be a custom report, right?

Thorsten

PS: But maybe an aggregation of PRODUCT + REGION isn´t even necessary since this would result in counting quantities twice...