Saphelp Utilities472 en 81 A0023b288dd720e10000000a114084 Frameset

Energy Data Management
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_utilities472/helpdata/en/81/a0023b288dd720e10000000a114084/frameset.htm
Created on February 10, 2017
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing
subtopics.
2017 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC Page 1 of 97
2014 SAP SE or an SAP affiliate company. All rights reserved.
Table of content
1 Energy Data Management
1.1 Profile Management
1.1.1 Profile
1.1.1.1 Profile Categories
1.1.1.1.1 Elementary Profile
1.1.1.1.2 Synthetic Profile
1.1.1.1.2.1 Usage Factor
1.1.1.1.3 Day Profile
1.1.1.1.4 Integral Profile
1.1.1.1.5 Formula Profile
1.1.1.2 Interval Length
1.1.1.3 Profile Header
1.1.2 Replacement Value Creation
1.1.2.1 Replacement Value Processes
1.1.2.1.1 Interpolation
1.1.2.1.2 Extrapolation
1.1.2.2 Replacement Value Procedure
1.1.2.2.1 Linear Replacement Value Procedure
1.1.2.2.2 Maximum Value Replacement Value Procedure
1.1.2.2.3 Minimum Value Replacement Value Procedure
1.1.2.2.4 Replacement Values Copied from Historical Values of Same Profile
1.1.2.2.5 Replacement Values Copied from Profile of Control Register
1.1.2.2.6 Replacement Values Copied with Reference to Factory Calender
1.1.2.2.7 Replacement Values Copied from Reference Profile
1.1.2.2.8 Repl. Vals Copied from Ref. Profile with Reference to FC
1.1.2.2.9 Replacement Values from Reference Consumption
1.1.2.2.10 Parameter
1.1.2.2.10.1 X_PROFILE_NUMBER
1.1.2.2.10.2 X_EPROFHEAD_DATA
1.1.2.2.10.3 X_REPLACE
1.1.2.2.10.4 X_REPLACEGRP
1.1.2.2.10.5 X_REPLACE_INDEX
1.1.2.2.10.6 X_REPLACE_TIMESLICE
1.1.2.2.10.7 X_NUM_INTERVALS
1.1.2.2.10.8 X_EPROFVALUES_TIMESLICE
1.1.2.2.10.9 X_REFPERIOD
1.1.2.2.10.10 XT_EPROFVALUES
1.1.2.2.10.11 XT_EPROFSTATUS
1.1.2.2.10.12 XT_EPROFVALUES_HIST
1.1.2.2.10.13 XT_EPROFSTATUS_HIST
1.1.2.2.10.14 Y_ERRORCODE
1.1.2.2.10.15 XYT_REPLACE_INDEX
1.1.2.2.10.16 XYT_EPROFVALUES_REP
1.1.2.3 Errors
1.1.2.4 Customizing
1.1.2.5 Features
1.1.2.5.1 Define Workflow
1.1.3 Profile calculation
1.1.3.1 Synchronous Calculation of Formula Allocations
1.1.3.2 Asynchronous Calculation of Formula Allocations
1.2 Settlement
1.2.1 Data Model
1.2.2 Settlement View
1.2.3 Settlement Unit
1.2.3.1 Settlement Unit Category
1.2.3.2 Example for Defining Settlement Units
1.2.4 Selection Variants
1.2.5 Settlement Document
1.2.6 Settlement Run
1.2.7 Selection Types
PUBLIC Page 2 of 97
1.2.8 Guidelines for the Development of Settlement Procedures
1.2.8.1 Requirements Analysis
1.2.8.1.1 Settlement Procedure Modeling
1.2.8.1.2 Identification of Settlement Steps
1.2.8.1.3 Identification of Settlement Parameters
1.2.8.2 Implementation of Settlement Steps
1.2.8.2.1 Reusable Implementation of Settlement Steps
1.2.8.2.2 Creation of New Settlement Steps
1.2.8.2.2.1 Redefine Methods
1.2.8.2.2.2 Coding Examples
1.2.8.2.2.2.1 Display Message in the Application Log
1.2.8.2.2.2.2 Set Alert
1.2.8.2.2.2.3 Display Error Message
1.2.8.2.2.2.4 Determine Points of Delivery That Are Relevant to Settlement
1.2.8.2.2.2.5 Read Profile Values (Incl. Status) From the Database
1.2.8.2.2.2.6 Read Profile Parameters
1.2.8.2.2.2.7 Check Status of Profile Values
1.2.8.2.2.2.8 Extrapolate Profile Values
1.2.8.2.2.2.9 Update Profile
1.2.8.2.2.2.10 Update Values
1.2.8.2.2.2.11 Arithmetic Operations with Profile Values
1.2.8.2.2.2.12 Determine Settlement Units
1.2.8.2.2.2.13 Select Additional Information on the Settlement Unit
1.2.8.2.2.2.14 Determine Grids & Customer Groups Relevant to Settlement
1.2.8.2.2.2.15 Select Additional Information on the Settlement Document
1.2.8.2.2.2.16 Send Profile to Service Provider
1.2.8.2.3 Change/Derive Predefined Settlement Steps
1.2.8.2.4 Customizing
1.2.8.2.5 Test Settlement Steps
1.2.8.3 Implementation of Settlement Procedures
1.2.8.3.1 Settlement Procedure as Workflow
1.2.8.3.2 Settlement Procedure as Job
1.2.8.4 Company-Specific Enhancements in Customizing
1.2.8.5 Test Settlement Procedure
1.2.8.5.1 Checklist A: Error During Parameter Determination
1.2.8.5.2 Check List B: Error During Point of Delivery Selection
1.2.8.5.3 Check List C: Error in the Settlement Procedure Process Flow
1.2.8.6 Overview
1.2.8.6.1 Settlement Parameters
1.2.8.6.2 Settlement Steps
1.2.8.6.2.1 Classes for Settlement Steps
1.2.8.6.2.1.1 CL_ISU_EDM_SETTLSTEP_0001
PUBLIC Page 3 of 97
1.2.8.6.2.2 Predefined Settlement Steps
1.2.8.6.2.2.1 ASSIGNPOD
1.2.8.6.2.2.2 CHECKPARAM
1.2.8.6.2.2.3 CHECKSETTL
1.2.8.6.2.2.4 DIFFSU
1.2.8.6.2.2.5 FACTGRP
1.2.8.6.2.2.6 FACTSUP
1.2.8.6.2.2.7 FACTSUPGRP
1.2.8.6.2.2.8 FASUPGRP01
1.2.8.6.2.2.9 LASTCONSSU
1.2.8.6.2.2.10 SENDGRIDPR
1.2.8.6.2.2.11 SENDSUGRPR
1.2.8.6.2.2.12 SENDSUPR
1.2.8.6.2.2.13 STATCHECK1
1.2.8.6.2.2.14 SUMGRID
1.2.8.6.2.2.15 SUMGRIDALL
1.2.8.6.2.2.16 SUMINTSU01
1.2.8.6.2.2.17 SUMINTSU
1.2.8.6.2.2.18 SUMRES01SU
1.2.8.6.2.2.19 SUMRES02SU
1.2.8.6.2.2.20 SUMRES03SU
1.2.8.6.2.2.21 SUMRES04SU
PUBLIC Page 4 of 97
!--a11y-->
1 Energy Data Management
Purpose
Energy Data Management is a solution that fulfills requirements by offering interval reading, settlement of energy quantities, scheduling, and billing of interval
energy consumption.
Integration
The Energy Data Management (SAP IS-U-EDM) component is fully integrated into the SAP IS-U system and can be installed in an existing SAP IS-U
system as a new component. SAP IS-U-EDM is also integrated into Intercompany Data Exchange (SAP IS-U-IDE). This component allows for data exchange
in standardized formats and enables the integration of cross-company business processes. SAP IS-U-EDM allows you to bill profiles in SAP IS-U. Profiles are
prepared in SAP IS-U-EDM and transferred to SAP IS-U billing via an internal interface. This allows you to bill new types of contracts, such as spot
purchases.
SAP IS-U-EDM also interfaces with automated meter reading systems.
Features
Energy Data Management covers the following areas:
Central database for energy data (Energy Data Repository)

Settlement and scheduling using the settlement workbench
Billing profiles using Real-Time-Pricing Billing
Profile Management
For further information see Profile Management
Importing Profile Values

You can import profile values using a standard interface as follows:
Using BAPIs of type ISUPROFILE.Upload (IDoc of type ISUPROFILE_UPLOAD1 )
Using BAPIs of type MSCONS
You can monitor the profile value import
Replacement Value Creation

For more information see Replacement Value Creation
Profile Display and Editing

Microsoft Excel has been integrated into IS-U-EDM via an OLE (object linking and embedding) interface. This interface allows you to:
Display profile values in Microsoft Excel.
Change profile values in Excel and save the changes in an Excel file.
Export profile values (including status) from SAP IS-U-EDM to an Excel file and edit them at your workstation.
Import elementary profile values (including status) from an Excel file into SAP IS-U-EDM.
The system performs predefined consistency checks during the import process.
Displaying Profiles on the Internet
PUBLIC Page 5 of 97
You can use an Internet Application Component to display profile values on the Internet.
Settlement
For more information see Settlement
Calculating Profiles
For more information see Profile Calculation
Sending Profiles
You can send profiles to communication partners and display a list of sent profiles.
To send profiles, see Energy Data Management Send Profiles in the Utilities Industry menu.
Profile Billing
For more information see Real-Time-Pricing Billing
!--a11y-->
1.1 Profile Management
Purpose
You can use
profiles to manage interval-related data (such as energy consumption values and prices) with the Energy Data Management component.
!--a11y-->
1.1.1 Profile
Definition
A profile is an object in the IS-U System that is used in energy data management to manage interval-related data. Interval-related data includes:
Values measured every 15 minutes by an interval meter
Values forecasted every 15 minutes for an interval meter
A price index from the energy exchange with an hourly amount
Structure
A profile consists of header data and profile values.
Profile characteristics are stored under the header data.
The most important characteristics are:
Profile type
Profile value category
Interval length
Consistency check group
Replacement value procedure group
Note that once you have saved the profile header you cannot make any changes other than to the name of the profile, consistency check
group, and replacement value procedure groups.
You can find the profile header transactions in the menu under Utilities Industry Energy Data Management Profile Management Profile Header .
!--a11y-->
1.1.1.1 Profile Categories

Profile categories allow for internal classification of profile types in the system.
The profile categories predefined by SAP are listed in the following documentation.
!--a11y-->
PUBLIC Page 6 of 97
1.1.1.1.1 Elementary Profile
Definition
Profile containing values that have been imported or entered manually.
!--a11y-->
1.1.1.1.2 Synthetic Profile
Definition
Profile containing values generated on the basis of predefined periods (day and season groups) and corresponding
day and annual profiles.
Use
Synthetic profiles are used when no interval data is available. These profiles classify the consumption patterns of certain groups of customers. Customers with
similar consumption patterns are allocated to the same synthetic profile.
Example
Bakeries have different peak times than other small businesses. As a result, you place bakeries into one customer group with the same
synthetic profile.
You can norm synthetic profile values in relation to a fixed reference value for a certain period (1 month or 1 year). These profile values can only be generated
for a period many times greater than the period length for norming.
Example
A synthetic profile represents 1000 kWh of consumption for a period of 1 year. The period length for norming is 1 year. The reference
value is 1000 kWh.
Structure
Synthetic profiles have a structure with three levels.
Profile values are generated based on predefined periods (defined via season and day groups) and corresponding standard profiles (
day and annual profiles). You define season and day groups in Customizing under SAP Utilities Energy Data Management Basic Settings.
You can use dynamic modification factors to change synthetic profile values. These factors prevent large jumps between season types and allow you to
maintain residential customers normal profile shape, for example.
PUBLIC Page 7 of 97
The system contains a predefined dynamic modification function for residential customers. This function complies with the standards of the German Electricity
Association. You can import or calculate your own dynamic modification functions. Dynamic modification factors are obtained from profile values of
elementary profiles of profile value category Factor .
You establish settings in Customizing under SAP Utilities Tools System Modifications User-Defined Enhancements for Energy Data Management
Dynamic Modification Factors for Synthetic Profiles.
Integration
Synthetic profiles are allocated at the installation level. There is one profile for each unit of measurement for billing.
You can allocate internal profiles with values managed in IS-U-EDM and external profiles with values managed in external systems.
You also allocate a
usage factor to profiles. In conjunction with the synthetic profile, the usage factor determines the consumption of an individual installation.
To optimize the determination of consumption, the system creates an
integral profile when the synthetic profile is created.
!--a11y-->
1.1.1.1.2.1 Usage Factor
Definition
Installation consumption in relation to a
synthetic profile.
Use
The usage factor is used to determine the following information:
Asset-specific consumption values
You can use a usage factor to determine the consumption of a particular installation from a synthetic profile. When you allocate a synthetic
profile to an installation you have to enter a usage factor.
Aggregated consumption of a group of customers
For the settlement, for example, a distribution or transmission company has to determine the total load shape for all customers that receive
energy from the same provider. In this case, the various usage factors and corresponding synthetic profiles are used to find the total of the
individual consumption values.
Expected consumption values
The system estimates consumption for the next period by estimating a usage factor based on the average of past usage factors.
A usage factor can have the following status:
automatically calculated
Usage factors for synthetic profiles managed in IS-U-EDM are calculated automatically.
The usage factor is calculated as follows:
Usage factor = consumption (billed) / consumption (synthetic profile)
If several registers belong to one installation (as in the case of a double-rate meter), the individual consumption readings of each register are
added together for each unit of measurement for billing and operand.
The usage factor is updated during billing or billing reversal. The variant QUANTI 24 is used to update the usage factor. You must include this
variant in the rate steps in order to trigger the update. The variant QUANTI 24 can be transferred to the current operand. This enables the system
to update different usage factors for each operand. The role used to allocate the profile to the installation controls which usage factors are
updated for which operands. In order to do this, the enhancement EEDMUFA1 must be defined.
extrapolated
The extrapolated usage factor is determined using the average of usage factors calculated automatically. Values are only extrapolated until the
next manual change (billing period 01.01.2001 01.30.2001, manual change on 08.01.2001 extrapolation period 02.01.2001 07.31.2001).
Manually entered
If you want to allocate a profile to a newly created installation or if the customers consumption patterns have changed, you have to enter the
usage factor manually.
PUBLIC Page 8 of 97
Calculated after a manual change
If the consumption pattern of the customer changes, and the usage factor is altered accordingly, consumption values that were settled before the
manual changes took place are no longer used for extrapolation of the usage factor. This would no longer reflect the current consumption pattern
of the customer.
The term usage factor always refers to a usage factor that has been calculated automatically.
Example
A synthetic profile defines linear consumption of 10 kWh per day.
1. Allocation of synthetic profile to installation
The usage factor was entered manually.

2. Meter reading entry (January)
Usage factor calculated automatically for period between 01/01/2000 and 01/31/2000:
Usage factor (automatic) = 155 kWh / (31 days * 10 kWh)
Estimated usage factor:
Equal to the usage factor calculated automatically
3. Meter reading entry (February)
Usage factor calculated automatically for period between 01.31.00 and 02.28.2000:
Usage factor (estimated) = (31 days / 59 days) * 0.5 + (28 days / 59 days) * 0.2 = 0.35
Changes in the Consumption Pattern
The consumption pattern of the customer changed on 02.28.

The usage factor was entered manually.
Meter Reading Entry (March)
Automatically calculated usage factor after a manual change for period 02.28.2000 to 03.31.2000
This usage factor has the status calculated after a manual change .
Equal to the usage factor calculated automatically
When the system determines the estimated usage factor, usage factors from before 02.28.2000 are not used.
!--a11y-->
1.1.1.1.3 Day Profile

Definition
Profile containing values measured at identical intervals and that describe one day.
Use
When
synthetic profiles are generated, the day profile reproduces the consumption of one day, such as a weekend day in summer or a weekday in winter. To use
day profiles, you must allocate them to a synthetic profile.
!--a11y-->
1.1.1.1.4 Integral Profile
Definition
PUBLIC Page 9 of 97
Profile calculated from a
synthetic profile by adding together individual profile values.
Use
To optimize the determination of consumption, the system always creates an integral profile when the synthetic profile is created.
Structure
!--a11y-->
1.1.1.1.5 Formula Profile

Definition
Profile containing values calculated using a formula.
Use
You can use formula profiles to determine the total network load for the grid, for example.
!--a11y-->
1.1.1.2 Interval Length
Definition
The interval length describes the period for which a value is valid. Each interval length refers to an interval length category . The following interval length
categories are available:
Minute
Day
Structure
The following interval lengths are available:
5 minutes (05)
10 minutes (10)
15 minutes (15)
30 minutes (30)
60 minutes (60)
One value per day (DAY)
The following restrictions exist:
You can convert interval lengths as long as they are even-numbered divisors or multiples of each other.
You can convert a 30 minute interval into a 10 minute interval.

However, you cannot convert a 15 minute interval into a 10 minute interval.
The interval length One Value per Day means that exactly one values is recorded for each day. It is mandatory that a value exists for every day. The
time at which this value was entered is not relevant here. The value is recorded as if it were entered at the time of the specified day offset. For the interval
length One Value per Day , only day offsets are permitted that do not include the time change from summer time to winter time or from winter time to
summer time. The time of the time change depends on the time zone in question.
!--a11y-->
1.1.1.3 Profile Header

Profile characteristics are stored under the header data.
The most important characteristics are:
Profile type
Profile value type
Interval length
Consistency check group
Replacement value procedure group
PUBLIC Page 10 of 97
Note that once you have saved the profile header you cannot make any changes other than to the name of the profile, consistency check group,
and replacement value procedure groups.
You can find the profile header transactions in the menu under Utilities Industry Energy Data Management Profile Management Profile Header .
!--a11y-->
1.1.2 Replacement Value Creation
Use
In the context of energy data management, values must be provided to replace missing or implausible profile values.
In addition, forecast values for
Profiles must be created for settlement simulations or schedule creation, for example.
With help from
replacement value procedure and replacement value procedure groups, you can determine how replacement values are created for profiles managed in IS-U-
EDM.
!--a11y-->
1.1.2.1 Replacement Value Processes

Replacement values for a profile must be created in two different processes. Therefore, you can allocate replacement value procedures to replacement value
procedure groups that each have one replacement value process.
The following replacement value processes exist:
Interpolation of profile values

Extrapolation of profile values
!--a11y-->
1.1.2.1.1 Interpolation
Purpose
If you want to replace missing profile values from the past with replacement values, the values must be interpolated.
Note that subsequent processes, such as RTP billing or settlement, are based on these interpolated values. Therefore, it is important that
the replacement values you create are as realistic as possible.
Example
You have allocated a profile to a register with the role Measured Consumption . An automated meter reading system (AMR) provides the profile with values on
a daily basis.
If values for a certain period could not be imported from the AMR (due to a technical defect, for example), you have to create replacement values instead. For
this purpose, you interpolate values for the profile.
Process Flow
!--a11y-->
1.1.2.1.2 Extrapolation
Purpose
If you want to forecast future profile values (to create a schedule, for example), the values must be extrapolated.
The extrapolated values are either overwritten with the measured values at a later date, or they are written in a separate forecast profile.
Note that subsequent processes, such as RTP billing or settlement, should not be based on these extrapolated values.
Example 1:
You have allocated a profile to a register with the role Measured Consumption . An automated meter reading system (AMR) provides the profile with values on
a daily basis.
You create a schedule today for the following day. For this purpose, you extrapolate values for the profile. On the following day, these extrapolated values are
overwritten with the measured values from the AMR.
Example 2:
You have allocated two profiles to a register: Profile 1 with the role Measured Consumption and Profile 2 with the role Forecast Consumption . An automated
meter reading system (AMR) provides profile 1 with values on a daily basis.
You create a schedule today for the following day. For this purpose, you extrapolate values for profile 2 based on the values from profile 1.
Process Flow
!--a11y-->
1.1.2.2 Replacement Value Procedure
The following
replacement value procedures exist:
Linear replacement value procedure

Maximum value replacement value procedure
Minimum value replacement value procedure
Replacement values copied from historical values of same profile
Replacement values copied from profile of control register
Replacement values copied with reference to factory calender
Replacement values copied from reference profile
Replacement values copied from reference profile with factory calender
Replacement values from reference consumption
!--a11y-->
1.1.2.2.1 Linear Replacement Value Procedure

Function module ISU_EDM_REP_METH_LINEAR
This function module creates all replacement values linearly. This means that the difference between the last known value before the missing value, and the
first known value after the missing value is split evenly amongst the missing intervals.
Example
The following values were imported:
Time Value
12:00 21.54
12:15 23.44
12:30 24.53
12:45
13:00
13:15
13:30 28.33
13:45 29.31
14:00 30.02
Three values (for the times 12:45, 13:00 and 13:15) are missing. To replace the missing values, the difference between the first known value after the missing
values (28.33) and the last known value before the missing values (24.53) is calculated.
28.33 24.53 = 3.80
This difference is split linearly amongst the number of missing values.
The number of missing intervals is always 1 higher than the number of missing profile values.
3.80 / 4 = 0.95
A replacement value is made up of the previous value plus the difference in the respective interval.
Time Value
12:45 24.53 + 0.95 = 25.48
13:00 25.48 + 0.95 = 26.43
13:15 26.43 + 0.95 = 27.38
The replacement values are added to the profile.
Time Value
12:00 21.54
12:15 23.44
12:30 24.53
12:45 25.48
13:00 26.43
13:15 27.38
13:30 28.33
13:45 29.31
14:00 30.02
Parameter
See
Parameter
Error Codes
1 Replacement periods are not consistent
2 Could not determine first base value
3 Could not determine last base value
See also:
Error
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.2 Maximum Value Replacement Value Procedure

ISU_EDM_REP_METH_MAXIMUM
This function module replaces missing values with the maximum value from the last known value before the missing values and the first known value after the
missing values.
Example
Time Value
12:00 21.54
12:15 23.44
12:30 24.53
12:45
13:00
13:15
13:30 28.43
13:45 29.31
14:00 30.02
Three values (for the times 12:45, 13:00 and 13:15) are missing. To replace these values, the maximum value from the first known value after the missing
values (28.43) and the last known value before the missing values (24.53) is calculated.
Max. (28.43 , 24.53) = 28.43
The missing values are replaced with this value.
Time Value
12:00 21.54
12:15 23.44
12:30 24.53
12:45 28.43
13:00 28.43
13:15 28.43
13:30 28.43
13:45 29.31
14:00 30.02
Parameter
See
Parameter
Error Codes
2 First base value could not be determined
3 Last base value could not be determined
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.3 Minimum Value Replacement Value Procedure

ISU_EDM_REP_METH_MINIMUM
This function module replaces missing values with the minimum value from the last known value before the missing values and the first known value after the
missing values.
Example
Time Value
12:00 21.54
12:15 23.44
12:30 24.53
12:45
13:00
13:15
13:30 28.43
13:45 29.31
14:00 30.02
Three values (for the times 12:45, 13:00 and 13:15) are missing. To replace these values, the minimum value from the first known value after the missing
values (28.43) and the last known value before the missing values (24.53) is determined.
Min (28.43 ; 24.53) = 24.53
The missing values are replaced with this value.
Time Value
12:00 21.54
12:15 23.44
12:30 24.53
12:45 24.53
13:00 24.53
13:15 24.53
13:30 28.43
13:45 29.31
14:00 30.02
Parameter
See
Parameter
Error Codes
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.4 Replacement Values Copied from Historical Values of

Same Profile
ISU_EDM_REP_METH_PROFHIST_COPY
This function module replaces missing values with historical values of the same profile.
In Customizing for the replacement value procedure, you must have selected the Replacement Period field and entered a reference period. This means that
for the specified reference period, historical values are read from the historical value tables XT_PROFVALUES_HIST and XT_PROFSTATUS_HIST, and are
added as replacement values in the place of the missing values.
Example
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00
01.01.2001 13:00:00
01.01.2001 13:15:00
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
The values for the 01.01.2001 at 12:45, 13:00 and 13:15 are missing. They are to be replaced with values from the same period of the previous year.
The replacement values are determined as follows:
1. The following values for the specified reference period (01.01.2000 at 12:45, 13:00 and 13:15) are read from parameter XT_EPROFVALUES_HIST.
Date Time Value
01.01.2000 12:45:00 26.21
01.01.2000 13:00:00 26.43
01.01.2000 13:15:00 27.12
The replacement values determined in step 1 are added to the profile for the replacement period.
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00 26.21
01.01.2001 13:00:00 26.43
01.01.2001 13:15:00 27.12
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
Parameter
See
Parameter
Error Codes
4 Values in replacement period only partially available
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.5 Replacement Values Copied from Profile of Control

Register
ISU_EDM_REP_METH_CONTROL_REG
This function module replaces missing values with values from the profile of a control meter.
Therefore, this function module does not require any historical values from the profile with the missing values.
Example
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00
01.01.2001 13:00:00
01.01.2001 13:15:00
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
The values for the 01.01.2001 at 12:45, 13:00 and 13:15 are missing. They are to be replaced with values from the profile of a control meter.
1. First of all, the system searches for the registers that are allocated to the profile with the missing values. Only one register may be allocated to this
profile within a specific period, as it is a measured profile. If this is not the case, the replacement value procedure terminates with error code 6.
Profile Day from Time from Day to Time to Register
4711 01.01.2000 00:00:00 01.01.2001 12:59:59 1000012111
4711 01.01.2001 13:00:00 12.31.9999 23:59:59 1004322354
The system determines the corresponding control register for every register determined in step 1. Only one control register may be allocate to each
register for a specific period. If this is not the case, the replacement value procedure terminates.
Register Day from Day to Control register
1000012111 01.01.2000 12.31.9999 0002327211
1004322354 01.01.2000 12.31.9999 0234322341
The system determines the measured profiles of the control registers.
Register Day from Time from Day to Time to Profile
0002327211 01.01.2000 00:00:00 12.31.9999 23:59:59 4712
0234322341 01.01.2000 00:00:00 01.01.2001 13:14:59 4713
0234322341 01.01.2001 13:15:00 12.31.9999 23:59:59 4714
The replacement values are read from the profiles of the control register for the replacement period.
Profile Date Time Value
4712 01.01.2001 12:45 24.65
4713 01.01.2001 13:00 24.64
4714 01.01.2001 13:15 26.54
The replacement values are added to the profile for the replacement period.
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00 24.65
01.01.2001 13:00:00 24.64
01.01.2001 13:15:00 26.54
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
Parameters
See
Parameters
Error Codes
5 Profile and source profile not compatible
6 Source profile not unique
7 Control meter not unique
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.6 Replacement Values Copied with Reference to

Factory Calender
ISU_EDM_REP_METH_PERIOD_CAL
This function module replaces missing values with values from a reference profile. You have the following options when determining this profile:
You have already entered the profile number of the reference profile in Customizing for the replacement value procedure
You have already entered the profile role in Customizing for the replacement value procedure
If you have neither entered the profile number nor the profile role, the missing values are replaced by values from the same profile
The reference period refers to the factory calendar that you entered in Customizing for Energy Data Management under Basic Settings Day Group
Define Day Types.
The weekday of the first day of the reference period must correspond to the weekday of the first day of the replacement period. If this is not the case, the
replacement values are created from the corresponding day from the previous week.
The system checks whether the last intervals of the reference period come after the first interval of the replacement period. If they do, the reference period is
shifted back one week.
To avoid missing values from a public holiday being replaced with values from a workday and vice versa, the following checks take place:
1. Are there any public holidays within the replacement period?
If there are, the replacement values must also be from a public holiday.
If the day, from which the replacement values are to be created, is not a public holiday but a workday, the replacement values are created from values from
the previous Sunday.
2. Are there any public holidays within the reference period?
If there are, these replacement values must replace missing values from public holidays.
If the day, for which the replacement values are to be created, is not a public holiday but a workday, the replacement values are created from
values from the previous week.
Example 1:
For the forecast profile, values are missing from the period 05.01.2001 at 00:00:00 to 05.31.2001 at 23:59:59. In Customizing for the replacement value
procedure, you have entered profile role 0001 (Template) and Last Month for the start of the reference period. The missing values are replaced with last
months values from profiles with the role 0001.
1. The profiles allocated the role 0001 are determined for the replacement period.
2. The start of the reference period is determined as follows:
1. Start of replacement period (05.01.2001 at 00:00:00) minus one month.

=> 01.04.2001 00:00:00
2. The weekday of the first day of the reference period (04.01.2001) must correspond to the weekday of the first day of the replacement period
(05.01.2001). As the 05.01.2001 is a Tuesday, the first day of the reference period must also be a Tuesday.
If this is not the case, the replacement values are created from the values from the previous Tuesday.
=> 03.27.2001, 00:00:00 (Tuesday)
3. The number of intervals in the replacement period (31), added to the start of the reference period give you the reference period:
From 03.27.2001 at 00:00:00 to 04.26.2001 at 23:59:59

3. The system checks whether the last intervals of the reference period come after the first interval of the replacement period.
If they do, the reference period is shifted back one week.
=> The 04.26.2001 does not come after the 05.01.2001.
4. The system checks whether the reference period contains any missing values.
If it does, the reference period is shifted back one week.
5. If no valid reference period can be found within the validity period of the profile, the system displays an error message. You would then have to create
the replacement values using a different replacement value procedure.
Example 2:
For the forecast profile, values are missing from the period 03.01.2001 at 00:00:00 to 03.31.2001 at 23:59:59. In Customizing for the replacement value
procedure, you have entered profile role 0001 (Template) and Last Month for the start of the reference period. The missing values are replaced with last
months values from profiles with the role 0001.
1. The start of the reference period is determined as follows:
1. Start of replacement period

03.01.2001 at 00:00:00 minus one month
=> 01.02.2001 00:00:00
2. Corresponding weekdays
03.01.2001 = Thursday
02.01.2001 = Thursday
3. Duration of reference period
03.01.2001 to 03.31.2001 (replacement period) = 31 intervals
=> 02.01.2001 + 31 intervals = 03.03.2001
4. Overlapping of replacement period and reference period
03.03.2001 comes after 03.01.2001

=> Start of reference period is shifted back one week
=> Reference period 01.25.2001 to 02.24.2001
2. The system checks whether the reference period contains any missing values.
If it does, the reference period is shifted back one week.
3. If no valid reference period can be found within the validity period of the profile, the system displays an error message. You would then have to create
the replacement values using a different replacement value procedure.
Parameter
See
Parameter
Error Codes
A Customizing entries missing
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.7 Replacement Values Copied from Reference Profile

ISU_EDM_REP_METH_PROFILE_COPY
Therefore, this function module does not require any historical values from the profile with the missing values.
Example
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00
01.01.2001 13:00:00
01.01.2001 13:15:00
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
The values for the 01.01.2001 at 12:45, 13:00 and 13:15 are missing. You have entered the profile role 0003 (Template) in Customizing for the replacement
value procedure. The missing values are replaced with replacement values with the role 0003.
profile within a specific period, as it is a measured profile. If this is not the case, the replacement value procedure terminates with error code 6.
4711 01.01.2000 00:00:00 01.01.2001 12:59:59 1000012111
4711 01.01.2001 13:00:00 31.12.9999 23:59:59 1004322354
The profiles, to which the registers determined in step 1 are allocated, are determined for the reference period.
Register Role Day from Time from Day to Time to Profile
1000012111 0003 01.01.2000 00:00:00 12.31.9999 23:59:59 4712
1004322354 0003 01.01.2000 00:00:00 12.31.9999 23:59:59 4713
The replacement values are read from the reference profile for the replacement period.
Profile 4712
Date Time Value
01.01.2001 12:45:00 26.21
Profile 4713
Date Time Value
01.01.2001 13:00:00 26.43
01.01.2001 13:15:00 27.12
The replacement values are added to the profile for the replacement period.
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00 26.21
01.01.2001 13:00:00 26.43
01.01.2001 13:15:00 27.12
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
Parameter
See
Parameter
Error Codes
See also:
Error
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.8 Repl. Vals Copied from Ref. Profile with Reference to

FC
ISU_EDM_REP_METH_PROFCOPY_CAL
If you have neither entered the profile number nor the profile role, the missing values are replaced by values from the same profile
To replace the values with historical values, you must have first selected the Start of Reference Period field and entered a reference period in Customizing
for the replacement value procedure This means that for the specified reference period, historical values are read from the reference profile, and are added to
the reference period as replacement values in the place of the missing values.
The reference period refers to the factory calendar that you entered in Customizing for Energy Data Management under Basic Settings Day Group
Define Day Types.
To avoid missing values from a public holiday being replaced with values from a workday and vice versa, the following checks take place:
1. Are there any public holidays within the replacement period?
If there are, the replacement values must also be from a public holiday.
If the day, from which the replacement values are to be created, is not a public holiday but a workday, the replacement values are created from values from
the previous Sunday.
2. Are there any public holidays within the reference period?
If there are, these replacement values must replace missing values from public holidays. If the day, for which the replacement values are to be
created, is not a public holiday but a workday, the replacement values are created from values from the previous week.
Example
You have allocated two profiles to a register:
Profile 1 Consumption measured
Profile 2 Consumption forecast
For the forecast profile, values are missing from the period 01.01.2001 to 01.07.2001. In Customizing for the replacement value procedure, you have entered
profile role 0001 (Template) and Last Week for the start of the reference period. The missing values are replaced with last weeks values from profiles with
the role 0001.
profile within a specific period, as it is a forecast profile. If this is not the case, the replacement value procedure terminates with error code 6.
4711 01.01.2000 00:00:00 01.07.2001 23:59:59 1000012111
The profiles, to which the registers determined in step 1 are allocated with role 0001, are determined for the reference period.
Register Role Day from Time from Day to Time to Profile
1000012111 0001 01.01.2000 00:00:00 12.31.9999 23:59:59 1
The replacement values for the replacement period should be read from the historical values of the reference profile.
Missing Values Replacement Values
01.01.2001 (PH) 12.25.2000 (PH)
01.02.2001 12.26.2000 (PH)
01.03.2001 12.27.2000
01.04.2001 12.28.2000
01.05.2001 12.29.2000
01.06.2001 (PH) 12.30.2000
01.07.2001 12.31.2000
The system checks whether values are missing on a public holiday. In this case, the 01.01.2001 and the 01.06.2001 are public holidays therefore, the
replacement values must also be created from public holidays.
01.01.2001 (PH)
12.25.2000 (PH)
02.02.2001 12.26.2000 (PH)
01.03.2001 12.27.2000
01.04.2001 12.28.2000
01.05.2001 12.29.2000
01.06.2001 (PH)
12.30.2000
01.07.2001 12.31.2000
Since the 12.30.2000 is not a public holiday, the values for the 01.06.2001 are replaced with the values from the previous Sunday (12.24.2000).
01.01.2001 (PH)
12.25.2000 (PH)
01.02.2001 12.26.2000 (PH)
01.03.2001 12.27.2000
01.04.2001 12.28.2000
01.05.2001 12.29.2000
01.06.2001 (PH)
12.24.2000 (Sunday)
01.07.2001 12.31.2000
The system checks whether the replacement values are from a public holiday.
01.01.2001 (PH) 12.25.2000 (PH)
01.02.2001 12.26.2000 (PH)
01.03.2001 12.27.2000
01.04.2001 12.28.2000
01.05.2001 12.29.2000
01.06.2001 (PH) 12.30.2000
01.07.2001 12.31.2000
In this case, the 12.26.2000 is a public holiday, the values of which should replace the missing values from the 01.02.2001. This is, however, not a public
holiday.
Therefore, the replacement values for the 01.02.2001 are created from values from the previous week (12.19.2000 = workday).
01.01.2001 (PH) 12.25.2000 (PH)
01.02.2001
12.19.2000
01.03.2001 12.27.2000
01.04.2001 12.28.2000
01.05.2001 12.29.2000
01.06.2001 (PH) 12.24.2000 (Sunday)
01.07.2001 12.31.2000
Parameter
See
Parameter
Error Codes
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.9 Replacement Values from Reference Consumption

ISU_EDM_REP_METH_GIVEN_CONSUMP
This function module replaces missing values using a reference consumption.
The user must enter the reference consumption. Therefore, you must select the Manual Entry field in all allocated replacement value procedures.
Example
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00
01.01.2001 13:00:00
01.01.2001 13:15:00
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
The values for the 01.01.2001 at 12:45, 13:00 and 13:15 are missing. The replacement values are determined as follows:
1. The user must enter a reference consumption and a period (for example, a reference consumption of 236.20 for the period 01.01.2001 at 12:00:00 to
01.01.2001 at 14:14:59).
2. First of all, the system adds together all of the existing values from this period.
21.54 + 23.44 + 24.53 + 28.43 + 29.31 + 30.02 = 157.27
3. The system calculates the difference between the reference consumption 236.20 and the existing value 157.27. This difference must be higher than 0,
otherwise the replacement value procedure terminates with error code 9.
236.20 157.27 = 78.93
4. The difference is split linearly amongst the number of missing intervals (in this case there are 3 missing intervals).
78.93 / 3 = 26.31
5. The replacement values are added to the profile for the replacement period.
Date Time Value
01.01.2001 12:00:00 21.54
01.01.2001 12:15:00 23.44
01.01.2001 12:30:00 24.53
01.01.2001 12:45:00 26.31
01.01.2001 13:00:00 26.31
01.01.2001 13:15:00 26.31
01.01.2001 13:30:00 28.43
01.01.2001 13:45:00 29.31
01.01.2001 14:00:00 30.02
Parameter
See
Parameter
Error Codes
8 Reference consumption could not be determined
9 Current consumption higher than reference consumption
See also:
Errors
Exceptions
SYSTEM_ERROR
Function Group
EEDM_REPLACE_METHOD
!--a11y-->
1.1.2.2.10 Parameters
The following parameters exist for the function modules that execute replacement value procedures:
X_PROFILE_NUMBER
X_EPROFHEAD_DATA
X_REPLACE
X_REPLACEGRP
X_REPLACE_INDEX
X_REPLACE_TIMESLICE
X_NUM_INTERVALS
X_EPROFVALUES_TIMESLICE
X_REFPERIOD
XT_EPROFVALUES
XT_EPROFSTATUS
XT_EPROFVALUES_HIST
XT_EPROFSTATUS_HIST
Y_ERRORCODE
XYT_REPLACE_INDEX
XYT_EPROFVALUES_REP
!--a11y-->
1.1.2.2.10.1 X_PROFILE_NUMBER
Number of the profile that contains the values to be replaced.
!--a11y-->
1.1.2.2.10.2 X_EPROFHEAD_DATA
Structure for the header data of a profile
Additional profile information from the structure EPROFHEAD_DATA (for example, division, profile category, profile value category, interval length).
!--a11y-->
1.1.2.2.10.3 X_REPLACE
The replacement value procedure to be executed by replacement value creation.
!--a11y-->
1.1.2.2.10.4 X_REPLACEGRP
Replacement value procedure group of the profile, for which values are to be replaced.
!--a11y-->
1.1.2.2.10.5 X_REPLACE_INDEX
Index blocks from an internal table
Indexes of internal table XT_PROFVALUES that limit the period, for which the replacement values are to be generated.
!--a11y-->
1.1.2.2.10.6 X_REPLACE_TIMESLICE
Period, for which replacement values are to be generated.
!--a11y-->
1.1.2.2.10.7 X_NUM_INTERVALS
Number of missing values to be replaced.
!--a11y-->
1.1.2.2.10.8 X_EPROFVALUES_TIMESLICE
Period, in which the current profile values are opened.
!--a11y-->
1.1.2.2.10.9 X_REFPERIOD
In this parameter, you can determine a reference period for the profile.
A reference period can contain any possible combination of season type, day type, and time-of-use type. This reference period is used during execution of the
replacement value procedure to generate replacement values based on time.
!--a11y-->
1.1.2.2.10.10 XT_EPROFVALUES
Table containing profile values
Internal table that contains the current values of the profile with values to be replaced.
Example
The system attempts to import the values for a profile for the period 01.01.2000 to 01.31.2000. However, several values are missing.
The table looks like this:
Date Time Value
01.01.2000 00:00:00 43.12
01.01.2000 00:15:00 42.89
01.01.2000 00:30:00 41.31
01.01.2000 00:45:00 42.34
01.01.2000 01:00:00
01.01.2000 01:15:00
01.01.2000 01:30:00 41.78
.................. .............. ..........
01.31.2000 23:30:00 41.65
01.31.2000 23:45:00 42.34
!--a11y-->
1.1.2.2.10.11 XT_EPROFSTATUS
Table containing status data for profile values
Internal table that contains the current status of the profiles with values to be replaced.
Example
The system attempts to import the values for a profile for the period 01.01.2000 to 01.31.2000. However, several values are missing.
The table looks like this:
Day from Time from Day to Time to Status
01.01.1999 00:00:00 01.01.2000 01:00:00 Valid
01.01.2000 00:45:00 01.01.2000 01:29:59 Invalid
01.01.1999 01:30:00 01.31.2000 23:59:59 Valid
!--a11y-->
1.1.2.2.10.12 XT_EPROFVALUES_HIST
Table containing historical profile values
Internal table that contains the historical values of the profile with values to be replaced.
The following parameters exist:
Start date of reference period
Duration of reference period
Replacement period
The historical values are read on the basis of these parameters.
!--a11y-->
1.1.2.2.10.13 XT_EPROFSTATUS_HIST
Table containing historical status data for profile values
Internal table that contains the status of historical values of the profile with values to be replaced.
The following parameters exist:
Start date of reference period
Replacement period
The statuses of the historical values are read on the basis of these parameters.
!--a11y-->
1.1.2.2.10.14 Y_ERRORCODE
Structure for transferring messages with error codes.
For each replacement value procedure, you can define different error codes. This allows the system to terminate the replacement value creation, for example,
and prevent profile values from being saved.
If the replacement value procedure terminates with an error, this parameter is given the relevant error code and an appropriate error message is displayed.
!--a11y-->
1.1.2.2.10.15 XYT_REPLACE_INDEX
Table category for EEDM_INDEX
Internal table containing the indexes of the replaced values of a profile.
Example
The values from the period 01.01.2000, 00:00:00 to 01.01.2000, 23:59:59 are to be replaced. If the replacement value procedure was executed without errors,
the replacement value table looks like this:
Index Date Time Value
1 01.01.2000 00:00:00 43.12
2 01.01.2000 00:15:00 42.89
3 01.01.2000 00:30:00 41.31
4 01.01.2000 00:45:00 42.34
.......... .................. ..............
96 01.01.2000 23:45:00 40.21
The table containing the indexes looks like this:
Index-from Index-to
1 96
If the entries 12 to 15 could not be replaced successfully, the table looks like this:
Index-from Index-to
1 11
16 96
This allows the multi-level creation of replacement values.
!--a11y-->
1.1.2.2.10.16 XYT_EPROFVALUES_REP
Table containing profile values
Internal table containing the replaced values of a profile.
Example
The values from the period 01.01.2000, 04:00:00 to 01.01.2000, 05:00:00 are to be replaced. If the replacement value procedure was executed without errors,
the table looks like this:
Date Time Value
01.01.2000 04:00:00 43.12
01.01.2000 04:15:00 42.89
01.01.2000 04:30:00 41.31
01.01.2000 04:45:00 42.34
!--a11y-->
1.1.2.3 Errors
Error Codes for the Replacement Value Procedure

If the function module executing the replacement value procedure cannot replace all of the missing values, the system displays error code.
A replacement value procedure should copy the profile values from a reference profile. If the profile values of the reference profile are not
complete for the replacement period, the replacement value procedure cannot replace all of the missing values. If this is the case, the
system displays error code 4 (Values in replacement period only partially available).
The following error codes are displayed by the standard replacement value procedures:
The replacement period and the reference period do not match
Example:
The duration of the replacement period is 01.01.2002 at 03:00:00 to 02.01.2002 at 03:59:59. With 15 minute intervals, this means there are 100 intervals to
replace.
The reference period, however, only has 96 intervals.
To be able to generate the profile values from a reference profile, the number of intervals must be the same.
For some replacement value procedures (linear replacement value procedure, for example), the last value before the missing values must be available. If this
is not the case, the system displays error code 2.
For some replacement value procedures (linear replacement value procedure, for example), the first value after the missing values must be available. If this is
not the case, the system displays error code 3.
The replacement values are read from the reference profile for the replacement period. They are, however, not complete.
The profile with the missing values and the reference profile are not compatible (the measurement units or the interval lengths are not the same, for example).
The reference profile could not be uniquely determined for the entire replacement period.
Example:
If you use a reference profile role to determine the reference profile, it must be unique. This means that only one profile with this role may be allocated to the
register of the profile containing the missing values.
7 Control meter not unique
A control meter is defined via the register relationship. Device 4711 is the control meter for device 4712. There should be only one control register for the
register of the profile to be replaced.
8 Reference consumption could not be determined
If no reference consumption had been entered, the system displays error code 8.
9 Current consumption higher than reference consumption
The current consumption of the replacement period is higher than the
reference consumption you have entered.
Example:
If a reference profile or a reference profile role should have been entered in Customizing for the replacement value procedure but was not entered, the system
displays error code A.
For each replacement value procedure, you can define different error codes that allow the system to terminate the replacement value creation, in combination
with the Follow-up Action for Errors , for example, and prevent the replacement values from being saved.
If you write customer specific replacement value procedures, you can also display customer-specific error codes. You must fill in the
Y_ERRORCODE output parameter. You allocate the error codes to the relevant replacement value procedures. You can determine the actions for these errors
in the replacement value procedure group.
Follow-up Actions for Errors in Replacement Value Procedure

An action determines how to proceed with replacement values after an error has occurred.
Continue processing; delete values

If the process is to be continued, the replacement value procedure with the next priority level (and the relevant number of values to replace) is called. All
values that have already been generated are deleted.
Continue processing; use values
If the process is to be continued, the replacement value procedure with the next priority level (and the relevant number of values to replace) is called. The
values that have already been generated are kept. (This means that the next replacement value procedure does not regenerate the values that have already
been generated).
Processing may only continue if the replacement value procedure group contains another replacement value procedure with a lower priority. This means there
is a replacement value procedure that can continue the replacement if this procedure terminates).
If there is no replacement value procedure to continue the replacement, the profile values that have not yet been generated are given the value Zero and the
status Interpolated or Extrapolated .
Exit processing; do not save values
The replacement value creation is terminated. The values that have already been generated are not saved in the profile.
Exit processing; save values
The replacement value creation is terminated. The values that have already been generated are saved in the profile. The periods, for which no replacement
values could be created, retain the status Missing Value .
Example
You have created a replacement value procedure group with the following replacement value procedure allocations:
Priority Minimum number of values Maximum number of values Replacement value procedure
1 1 9999 PROFCOPY1
2 1 9999 PROFCOPY2
The replacement value procedure PROFCOPY01 should use the historical profile values from last year. PROFCOPY02 should use the historical profile values
from 2 months ago.
The following values are missing and must be generated by replacement value creation:
Time Value
12.31.2001 23:45
01.01.2002 00:00
01.01.2002 00:15
First of all the system tries to use the PROFCOPY1 replacement value procedure to replace the missing values with the values from last year.
Time Value Time Historical value
12.31.2001 23:45 12.31.2000 23:45
01.01.2002 00:00 8.21 01.01.2001 00:00 8.21
01.01.2002 00:15 8.23 01.01.2001 00:15 8.23
The value 12.31.2000, 23:45 could not be generated using this replacement value procedure. Error code 4 (Values in replacement period only partially
available) is displayed.
The follow-up action for errors determines the next steps:
1. Continue processing; delete values
The values that have already been generated are deleted and the next replacement value procedure (PROFCOPY2) is called.
12.31.2001 23:45 7.45 10.31.2000 23:45 7.45
01.01.2002 00:00 7.43 11.01.2001 00:00 7.43
01.01.2002 00:15 7.44 11.01.2001 00:15 7.44
Continue processing; use values

The values that have already been generated are retained and the next replacement value procedure (PROFCOPY2) is called to generate the remaining
missing values.
12.31.2001 23:45 7.45 10.31.2000 23:45 7.45
01.01.2002 00:00 8.21
01.01.2002 00:15 8.23
Exit processing; do not save values
Time Value
12.31.2001 23:45 Status Missing value
The profile values in the period 12.31.2001, 23:45:00 to 01.01.2002, 00:29:59 have the status Missing value .
Exit processing; save values
Time Value
01.01.2002 00:00 8.21
01.01.2002 00:15 8.23
Profile value 12.31.2001, 23:45:00 has the status Missing value .
!--a11y-->
Customizing for Replacement Value Creation
You can define replacement value procedures and replacement value procedure groups in Customizing for Industry Solution for Utilities under Energy Data
Management Profile Management Replacement Value Creation .
Define Replacement Value Procedure
The parameters are as follows:
Function module for replacement value creation
A function module that executes the replacement value creation is allocated to every replacement value procedure. All function modules that you
enter here must refer to the same interface as function module ISU_EDM_REP_METH_LINEAR.
You can use function modules from function group EEDM_REPLACE_METHOD.
Function module for the determination of the reference period
You can also allocate a function module that determines the appropriate combination of season type, day type, time-of-use type and day type
exception for this profile. This can be used in the replacement value procedure to establish replacement values based on season type, day type,
and so on.
All function modules that you enter here must refer to the same interface as function module ISU_EDM_REP_TIME_SAMPLE.
Reference profile
Role of a reference profile
The profile role acts as a template for the replacement value procedure. As well as directly allocating reference profiles, you can use roles to
allocate them indirectly. In this case, you can determine the profile that you previously allocated to the interval meter with the specified role when
the replacement value procedure is executed.
Start of reference period
Historical values of the profile to be replaced
A reference period, from which historical values from the same profile are read, is defined from the start of the reference period and the
duration of the reference period .
The historical values are only read if the start of the reference period field and either the duration of the reference period or the
reference period corresponds to the replacement period fields are filled.
The start of the reference period can also be used in the value replacement procedure to read or to generate the replacement values from a
second profile for a certain period (one month/one year ago, for example).
Reference period corresponds to replacement period
This means that the duration of the reference period corresponds to the duration of the replacement period.
Define replacement value procedure group
In Customizing, you can allocate several replacement value procedures to a replacement value group. This enables you to use several replacement value
procedures when replacing profile values and to trigger various follow-up actions if errors occur. When you allocate replacement value procedures to a
replacement value procedure group, you can:
distinguish between different
replacement value processes
define priorities for every procedure
In this way, you can control the sequence in which the replacement value procedures are used.
determine, for every procedure, the number of values that can be replaced with this replacement value procedure
Example
If the number of values to replace lies between 1 and 3, the values are replaced with replacement value procedure x.
If the number of values to replace lies between 4 and 9999, the values are replaced with replacement value procedure y.
Before you can save the replacement value procedure groups, the system executes the following checks:
Priorities must be defined from 1-9 (in this order).
For every value to be replaced (in the interval 1-9999), a replacement value procedure must be allocated to every priority.
In the profile header data, you can then choose from previously defined replacement value procedure groups. You can find the profile header in the Utilities
Industry menu under Energy Data Management Profile Management .
!--a11y-->
1.1.2.5 Features
Replacement value procedures define the calculations that take place when replacement values are generated.
The most important functions are listed below:
Connection of the replacement value procedure group to a profile
You can allocate the profiles managed in IS-U to a replacement value procedure group. You can maintain the profile header in the menu under
Utilities Industry Energy Data Management Profile Management Profile Header .
Automatic interpolation of missing profile values
To automatically execute the interpolation of profile values after profile value import, select the import field in the replacement value procedure
group for the profile.
Replacement value creation is called if several of the profile values in the import period have the status Missing value .
If the missing values for a profile cannot be generated automatically (because the values have not yet been imported to a control meter profile,
for example), you can use the monitor import process function to repeat replacement value creation.
You can find the monitor import profile function in the menu under Utilities Industry Energy Data Management Monitoring Profile Value
Import .
You can display log entries for the profile value import in the following way:
Display entries that had missing profile values in the import period
Display entries for which profile values were successfully or unsuccessfully replaced
You can repeat replacement value creation for individual entries or for all displayed entries that were not replaced successfully.
To do this, choose Edit Generate Replacement Values for Profile or Edit Generate all Replacement Values in the menu.
Manual interpolation/extrapolation of missing profile values
You can also execute the interpolation/extrapolation of profile values manually.
You can find the functions to maintain profile values in the menu under Utilities Industry Energy Data Management Profile Management
Profile Values Change
Choose a profile and a period for which the profile values are to be replaced. Choose Carry Out a Mass Change You can then choose a
replacement value process in the dialog box.
Automatic extrapolation of profile values
In the context of IS-U-Billing, it is possible for
interval customers to execute a billing simulation based on the extrapolated profile values. For this purpose, the profile must be allocated to a replacement
value procedure group, to which a replacement value procedure of the Extrapolation process is allocated.
!--a11y-->
1.1.2.5.1 Define Workflow

If the interpolation of missing profile values was executed automatically after the import of profile values, the event ReplacementValuesRequired for BOR
object ISUPROFILE is issued.
The event has the following parameters:
1. RepPeriodFromDate
2. RepPeriodFromTime
3. RepPeriodToDate
4. RepPeriodToTime
Period, for which profile values were imported.
5. RepTimeslices
Periods, for which replacement values were created successfully. The relevant replacement value procedure used to create replacement values is listed for
every period.
6. FailedTimeslices
Periods, for which no replacement values could be created.
You use the replacement value event to define your own replacement value workflows, so that you can inform the person responsible that the interpolated
profile values have to be checked or released, for example.
!--a11y-->
1.1.3 Profile calculation
Purpose
Profile calculation is used to map constant profile dependencies that are to be valid for the long term.
For example, you can:
Use a profile addition
formula to combine several feedings for a customer in one profile.
Convert demand profiles into consumption profiles.
Prerequisites
Make the necessary Customizing settings for SAP Utilities under Energy Data Management Profile Management Formula Profiles.
SAP provides a series of formulas that can be used for profile calculation. To define additional formulas, make the necessary settings in Customizing under
SAP Utilities Tools System Modifications User-Defined Enhancements for Energy Data Management Formulas. (See
Formulas)
Process Flow
Profile values in a formula profile are calculated using a predefined formula. The whole calculation construct is known as a
Formula allocation. An example of this type of formula allocation is shown in the following diagram.
Profiles (with their profile values) or fixed values can be entered as input parameters for the formula allocation in the calculation.
An output parameter for the formula allocation can be the profile(s) to be calculated (some formulas have several output parameters).
An output parameter for a formula allocation can be entered in a different formula allocation as an input parameter. This creates a hierarchy of dependent
formula allocations as shown in the following diagram.
The formula allocation is structured when creating the profile header for the formula profile to be created. For more information, see the
Create formula profile section.
If values in an input parameter for a formula allocation change once the profile has been calculated, this invalidates the results of the formula allocation and
any dependent formula allocations. The system generates temporary
calculation triggers if any of the following events occur that trigger calculation:
Changes to profile values after profile value import
Profile value changes in the dialog with transaction change profile values
Calculation triggers are used for calculation flags. They indicate that the calculation must be repeated to obtain correct results.
Create formula profile
In the
Utilities Industry menu, choose Energy Data Management Profile Management Profile Header Create.
The system automatically determines the profile number if you have already defined number ranges for profiles in the Customizing settings for Energy Data
Management in Profile Management .
Enter a description for the profile type in the Prof. name field.
Choose a division.
Make the required entries on the General tab page.
Choose a profile type that refers to the Formula profile type in the Profile type field.
You define profile types in the Energy Data Management Customizing under Basic Settings .
Choose the
Details tab page.
Choose the formula to be used to subsequently calculate the values of the formula profile you create here in the Formula for profile calculation field.
To access the Customizing settings for the formula definition, double-click on the formula.
The following formulas are predefined by SAP: To define additional formulas, go to Customizing for SAP Utilities and choose Tools
System Modifications User-Defined Enhancements for Energy Data Management Formulas Define Formula.
Choose a status group that has been defined in the Customizing settings for Energy Data Management under Profile Management Formula Profiles
Automatic Profile Calculation Define Status Group and Statuses for Status Group .
Status groups are used during profile calculation to determine the status for the formula result. For more information, see the Implementation Guide (IMG).
The system automatically displays a consecutive number in the Formula Allocation field if you have defined number ranges for formula allocations in
the Customizing settings for Energy Data Management under Profile Management Formula Profile .
If you do not want to calculate this formula allocation subsequently, select the No Calculation field.
This ensures that the system does not generate a calculation trigger for this formula allocation and that this formula allocation is not marked for calculation,
even if events that trigger calculation occur (as described in the Process Flow section).
Warning regarding the hierarchy of dependent formula allocations

1. Case: No Calculation field selected for dependent fomula allocation
First you have created and saved both formula allocations. Then you have selected the No Calculation field for the dependent formula allocation.
No calculation triggers are generated for the dependent formula allocation, and this formula allocation is not marked for calculation, even if events that trigger
calculation occur.
Note that this can lead to incorrect result values of the dependent formula allocation (if for example, the values of the input profile of this formula allocation
have changed).
2. Case: No Calculation field selected for first formula allocation
First you have created and saved both formula allocations. Then you have selected the No Calculation field for the first formula allocation.
This is not possible, because this formula allocation is part of a hierarchy of dependent formula allocations. The output parameter of the formula allocation
enters the dependent formula allocation as an input parameter.
If, for example, the values of the input profile of the first formula allocation were changed, the result of the second formula allocation would also be invalid.
However, this would not be recalculated because no calculation triggers were generated.
A system message is issued that requires you to select the No Calculation field for the independent formula allocation (see Case 3).
3. Case: No Calculation field selected for both formula allocations
First you have created and saved both formula allocations. Then you have selected the No Calculation field for the dependent formula allocation (see Case
1).
In the second step, you select also select the field for the first formula allocation.
4. Case: No Calculation field selected for first formula allocation
You have created a formula allocation, for which you have selected the No Calculation field. This was possible because the formula allocation is not linked to
a hierarchy of dependent formula allocations.
In a second step, you have created an additional formula allocation that the output parameter of the first formula allocation should use as an input parameter.
In doing so, a hierarchy of dependent formula allocations exists, for which the No Calculation field is only selected for the first formula allocation. This is not
possible (see Case 2).
If you want to create such a hierarchy, also select the No Calculation field for the dependent formula allocation.
The date in the Allocation Validity group frame is used to display the formula allocation in the tree structure.
Chose Continue .
The Allocation of output parameters field shows which output parameters in the formula allocation can be allocated to the formula profile that is currently
being edited. This is only relevant for formula allocations with formula definitions that contain several output parameters (see section
Formula allocation with several output parameters).
The number of input and output parameters in the formula allocation as defined in the formula are displayed in a tree structure on the lower section of the
work area.
Allocate the profiles to the input parameters.
Select a line for an input parameter and choose Create Allocation .
Choose a profile whose values are to be entered in the formula input parameters in the Profile field in the table.
By double-clicking on a profile in the table, you branch directly to the profile values display for this profile.
Do not generate calculation triggers for individual profiles (field: Does not Trigger Calculation ).
Under certain circumstances it may make sense not to trigger a recalculation of the total formula allocation when changing the values of an input profile.
Example
Profile values are regularly imported to the input profiles A and B of a formula allocation. The formula profile should first be calculated when all profile values
have been imported. The profile values of input profile A are imported earlier than the profile values of the other input profile. By selecting the Does not Trigger
Calculation field for input profile A, you prevent the calculation at a time when errors would occur due to missing profile values. In this way the system is not
loaded with calculations that cannot lead to a result.
If you select this field, a temporary calculation trigger whose profile values have changed is generated at profile level This calculation trigger is flagged in the
calculation workbench as Does not Trigger Calculation . You can compress this calculation trigger at formula allocation level, but the formula allocation will
not be taken into account in the next calculation run. When you attempt to start the calculation, a corresponding message is issued.
However, the generated calculation trigger leads to the invalidation of all subsequently allocated result profiles. The calculation trigger is updated in billing and
then means that dependent profiles cannot be billed.
The formula profile is recalculated for the next event that triggers calculation and that affects this formula allocation.
Check allocation is used to ensure that profile allocations are consistent.
Save your data.
Once you have saved the formula profile, the profile allocation number is displayed on the Details tab page in the Formula Allocation field.
Formula allocation with several output parameters
An example of this type of formula allocation with several output parameters is shown in the following diagram:
To replicate this formula allocation in the system, proceed as follows:

1. Create the profile header of the first output parameter (profile 1401) as described in the
Create Formula Profile section.
Create the profile header for the second output parameter (profile 1402). Select the number of the formula allocation created in step 1 in the Formula
allocation field.
You can use the input help to display the formula allocations that correspond with the profile to be created regarding profile value category and
interval length, and are not yet fully configured. This means the ones for which output parameters still exist without an allocation.
Profile calculation
Formula allocations can be calculated in one of two ways:
Synchronous calculation
Asynchronous calculation
!--a11y-->
1.1.3.1 Synchronous Calculation of Formula Allocations

The selected formula allocation is calculated for synchronous calculation of formula allocations.
To perform synchronous calculation of formula allocations, you require a certain authorization (authorization object E_INSTCALC, authorization ISU_CALCFI,
field CALCS).
You can perform the synchronous calculation either from the profile header of the formula profile to be calculated, or in the calculation workbench.
Synchronous calculation from the profile header of the formula profile
In the profile header display of the formula profile, choose Calculate formula alloc. in the Details tab page.
You reach the screen for Calculation Status for Formula Profiles: Details. Either select the lines with the formula allocation that is to be calculated, or
enter a period (for which the calculation is to be executed) in the Restrict s ynchronous formula calculation group box, and choose Synchronous
Calculation.
You automatically go to the calculation log, where the status of the performed calculation is displayed.
Synchronous calculation in the calculation workbench
In the Utilities Industry menu, choose Energy Data Management Automatic Profile Calculation Calculation Workbench
.
Enter the number of the formula allocation that you want to calculate, in the Formula alloc. field.
Hierarchy display
To obtain a graphical display of the formula allocation, choose Hierarchy Display.
For very large formula allocations with many allocated input and output parameters, you can use the hierarchy display to obtain a quick overview of the
structure of the formula allocation. To do this choose Entire hierarchy.
Display formula allocation

To branch to the profile header of the formula profile, choose Display Formula Alloc .
On the lower part of the Details tab page, the number of the input and output parameters for the formula allocation (as defined in the formula) and the
allocated profiles are displayed in a tree structure.
In the From-Date and To-Date fields, enter the period for which the formula allocation must be calculated.
Choose Calculate Formula Allocation .
You reach the screen for Calculation Status for Formula Profiles: Details.
Either select the lines with the formula allocation that is to be calculated, or enter a period (for which the calculation is to be executed) in the Restrict
s ynchronous formula calculation group box, and choose Synchronous Calculation.
You automatically go to the calculation log, where the status of the performed calculation is displayed.
No separate calculation run number is issued for synchronous calculations, and therefore the display in the Current Calculation Run group box is not
changed.
!--a11y-->
1.1.3.2 Asynchronous Calculation of Formula Allocations

For the asynchronous calculation of formula allocations, all formula allocations are calculated using compressed calculation triggers.
After the following calculation-triggering events, the system automatically creates temporary calculation triggers for the profile with the changed values.
Changes to profile values after profile value import
Profile value changes in the dialog with transaction change profile values
Formula allocation changes
Because only completed formula allocations and not individual profiles are calculated, the temporary triggers are compressed at the level of the total formula
allocation. Compression of the calculation trigger is a prerequisite for asynchronous calculation of formula allocation.
The compression is blocked while the calculation trigger is being compressed so that no other compression can be started at the same time. If errors occur
during the process, compression remains to be blocked. You can, however, remove the block manually.
For optimum system performance, asynchronous calculation is run in parallel on multiple application servers and processes. To enable parallel processing,
asynchronous calculation consists of three steps:
1. Hierarchy determination
To calculate formula allocations that are connected as regards time and hierarchy in parallel, without causing blocks, the data must first be put into an
appropriate form as regards time and hierarchy.
2. Interval creation
With interval creation you can split formula allocations that are to be calculated into intervals.
3. Calculation of intervals
The following types of asynchronous formula allocation calculation exist:
Automatic asynchronous calculation
For an automatic asynchronous calculation, you can schedule periodic jobs.
Manual asynchronous calculation
For more information, see the following section.
Manual asynchronous calculation
In the Utilities Industry menu, choose Energy Data Management Automatic Profile Calculation Calculation Workbench
.
After the following calculation-triggering events, the system automatically creates temporary calculation triggers for the profile with the changed values.
If no calculation triggered events occurred, the system does not create automatic temporary calculation triggers. Because calculation triggers are a
prerequisite for asynchronous calculation of formula allocations, you must create them manually - even if you want to start a calculation run. To do this enter
the formula allocation to be calculated in the formula allocation field in the calculation workbench and select mark for calculation . This creates
temporary calculation triggers.
Select monitoring in the calculation trigger group frame.
This gives you an overview of the existing calculation triggers.
In the origin column, you can see whether a temporary or a compressed calculation trigger is involved.
To start an asynchronous calculation, all temporary calculation triggers must be compressed. To do this, select compress (compress calculation
trigger) in group frame calculation trigger from the calculation workbench.
If all calculation triggers are compressed, select schedule calculation (start asynchronous calculation).
In the calculation to field in group frame selection of calculation trigger , enter the date up to which the calculation trigger and the relevant formula
allocations should be taken into account for calculation.
In group frame interval creation enter either an interval size or the number of intervals.
Example
Starting point after compression of the calculation trigger is 20 formula allocations.
Enter 5 in the interval size field.
For the calculation, 4 intervals are created, each with an interval size of 5 formula allocations.
Enter 2 in the interval size field.
For the calculation, 2 intervals are created, each with an interval size of 10 formula allocations.
9. In the server name column of group frame job creation (parallel processing), enter the relevant application server on which the calculation is to run.
Enter the desired number of jobs per server in the number of jobs column.
10. Choose ( Execute ).
The system automatically creates a calculation run number for this calculation run if you have first defined the relevant number range in EDM Customizing
under Profile Management Formula Profile Automatic Profile Calculation Define Number Range for Calculation Run Number.
11. The following information is displayed in group frame current calculation run in the calculation workbench:
Calculation run number
Calculation creation date
Calculation start time
Creator ID
Date up to which the calculation trigger and the relevant formula allocations are to be taken into account for calculation
12. The parameters of the formula allocations to be calculated cannot be changed during a calculation run.
13. The status of the individual calculation steps is displayed in group frame status .
14. For more information on calculation runs see the following functions: calculation error , job overview , and action log .
Repeat run
If a calculation step has the status (not yet processed) or (error), the calculation remains blocked. After an error analysis and the successful
correction of the error, you can set the status to (successfully processed) manually by selecting change status .
If all calculation steps have the status (successfully processed), you can unblock the calculation by selecting unblock .
Now you can restart the calculation.
If you restart a calculation, the system automatically creates a restart number in addition to the calculation run number. The repeated calculation run is
managed under this restart number, in order to ensure a history of all calculation runs.
In group frame current calculation run , the field Rpt will inform you whether or not the current run is a repeat run. The number in the RestartNr field
informs you of how many repeat runs have occurred.
!--a11y-->
1.2 Settlement
Purpose
The settlement data flows in the following graphic are mapped with SAP IS-Utilities. Consumption data that is determined and managed in component SAP IS-
U-EDM is transferred during settlement. With the help of the processes provided by component SAP IS-U-IDE, this data can be communicated to other market
participants.
Description of the Settlement Unit
Settlement units allow you to control, which consumption values are selected for a settlement.
Allocation of Consumption Values to Settlement Units
The
point of delivery plays an important role in the allocation of consumption values to the settlement units. The allocation of a point of delivery (and its
consumption values) to a settlement unit is determined by the point of delivery services allocated to the point of delivery. A point of delivery service can be a
billable service in the form of a contract Point of delivery services for the following service categories are relevant for settlement:
Settlement coordination
The point of delivery service for this service category describes the
service provider responsible for the coordination and execution of the settlement.
In the German Associations Agreement Regarding Electric Energy, this is the

control area operator. The control area operator settles the grid usage of the supplier across distribution grids.
Distribution
The point of delivery service for this service category describes the service provider, in whose distribution grid a utility service is supplied to the
point of delivery.
Supply
The point of delivery service for this service category describes the service provider that supplies a utility service to the point of delivery.
You can define a settlement unit by defining the service provider for each of these service categories. Points of delivery are allocated to a settlement unit that
has a point of delivery service for the relevant service provider within these service categories.
Data Selection
An important function of settlement (
settlement step) is that you can select consumption values allocated using the points of delivery for every settlement unit.
You must differentiate between the following types of consumption measurement:
Interval reading
Consumption is read using an interval meter in the time intervals relevant for settlement. Therefore, the totaling of consumption values can be
done by totaling the consumption values for every time interval.
For interval reading, you can determine the allocation of the consumption value to the point of delivery using the allocation of the interval meter
to the point of delivery.
Note that you can differentiate between allocation to a technical point of delivery and to a deregulation point of delivery.
For more information, see
point of delivery.
Cumulative consumption measurement
Once a month or once a year, the consumption value is determined periodically as a cumulative consumption value. Distribution of the
consumption value must occur for time intervals relevant for settlement. Synthetic profiles are used for this purpose. The relationship of the
cumulative consumption value to the normed synthetic profile is described by the
usage factor.
The algorithm that is a result of the distribution of the non-interval consumption values is determined by the
settlement procedure. This can be created from the settlement step as a SAP business workflow.
In this way, you can, for example, define a settlement procedure that allows settlement in accordance with the synthetic settlement procedure or the
analytical settlement procedure as defined in the German Associations Agreement Regarding Electric Energy.
In this case, ensure that you take settlement procedures predefined by SAP into account.
In the case of cumulative consumption measurement, the synthetic
load profile is allocated to the installation and therefore also to the point of delivery. (This is only valid for deregulation points of delivery).
The allocated points of delivery are then determined for every settlement unit.
The following selections are executed for every point of delivery:
Selection of all
load shapes
Selection of all synthetic profiles (especially the usage factor for every installation)
All roles with which load shapes and synthetic profiles are allocated are taken into account. You can define the roles that must be taken into account for
settlement in Customizing for the utilities industry under Energy Data Management Settlement Settlement Procedure .
Multiple Installations for Point of Delivery
Multiple installations can be allocated to a point of delivery (deregulation point of delivery). This can be the case if, for example, you manage the grid usage
and the delivery as billable services in the system. This means that the point of delivery has two installations (a grid usage installation and a delivery
installation), where you manage the same consumption values. In order to avoid the point of delivery consumption value from being entered twice in the
settlement, define the service type in the settlement procedure, for which selection of the consumption values should occur. This is dependent on the
installation. In this way, you can determine, for example, that the consumption value allocated to the grid usage installation should always be used for the
settlement.
Taking Grids into Account
Using
grids, you can calculate the settlement results for every settlement unit and for every grid.
With the help of grids, you can recreate the distribution grid of a
distributor in the system.
If an actual distribution grid of a distributor covers multiple control areas, this distribution grid can be reproduced in the system with help of multiple grids (one
grid for each control zone). For settlement purposes, therefore, every part of the distribution grid that lies within one control zone is managed as one grid.
For every point of delivery, allocate the specific grid for which the consumption value is to be settled. Allocation of a point of delivery to a grid can be
determined automatically depending on the address (through the regional structure) and the voltage level.
Prerequisites
First of all, you must define the settlement procedure in Customizing for the utilities industry under Energy Data Management Settlement .
Settlement parameters, settlement steps and selection categories for settlement are predefined by SAP.
You can define additional settlement parameters and settlement steps in Customizing for the utilities industry under Tools System Modifications
Customer-Specific Function Enhancements for Energy Data Management Settlement .
Process Flow
Create and generate settlement units.
To create and generate settlement units, see Energy Data Management Settlement Master Data in the utilities industry menu.
Define model profiles for settlement parameters, by choosing Energy Data Management Settlement Master data in the utilities industry menu.
Create selection variants for settlement, by choosing Energy Data Management Settlement Selection Variants for Settlement in the utilities
industry menu.
Define a settlement document, by choosing Energy Data Management Settlement Settlement Document in the utilities industry menu.
Start the settlement run, by choosing Energy Data Management Settlement in the utilities industry menu.
Result
The result of a settlement consists of a profile (with the consumption values for every time interval) being created for every settlement unit or grid in the
settlement period and the profiles being distributed to other service providers.
!--a11y-->
1.2.1 Data Model

The following diagram shows the business objects used in settlement (IDE/EDM master data marked in blue):
The following new data objects have been added as a result of deregulation:
Point of delivery
Services
Service provider
Settlement unit
Grid
Interval meter
Profiles
Device information record
!--a11y-->
1.2.2 Settlement View

If the supplier and the distributor are managed in the same system, you may have to allocate a point of delivery used for settling settlement unit A to
settlement unit B in order to create schedules.
Settlement views separate the distributor and supplier views so that in every view a point of delivery is always uniquely allocated to a settlement unit.
In a subsequent step, you must allocate every settlement procedure and every settlement unit to a settlement view.
In Customizing for Energy Data Management under Settlement Define Settlement Procedures , select one of the defined settlement views. You use
this selection to allocate the settlement procedure to a settlement view.
In the menu for the Utilities Industry under Energy Data Management Settlement Master Data , select one of the defined settlement views in the
settlement unit. You use this selection to allocate the settlement unit to a settlement view.
You define settlement views in Customizing for the Utilities Industry under Energy Data Management Settlement Define Settlement Views.
See also:
The example for
Defining Settlement Units
!--a11y-->
1.2.3 Settlement Unit
Definition
The settlement unit is an object in the IS-U system that corresponds to a settlement area. As different terms are used in different German-speaking countries,
SAP uses the neutral term settlement unit .
Use
Settlement units allow you to control, which points of delivery are selected for settlement. The result of a settlement consists of at least one result profile (with
the consumption values per interval) being updated for each settlement unit within the settlement period.
Structure
A virtual technical point of delivery is allocated to a settlement unit. This point of delivery is necessary so that you can allocate profiles directly to a settlement
unit. These profiles are usually settlement results or input parameters of the settlement procedure that are calculated for each settlement unit. A register of an
interval meter (device info record) is allocated to the point of delivery of the settlement unit. Profiles can in turn be allocated to the register.
Integration
Determining Points of Delivery for Settlement Units
A settlement unit describes the points of delivery that are to be treated as a unit within a settlement. When settling a settlement unit, you must determine the
points of delivery that are to be settled together.
The allocation of a point of delivery (and its consumption values) to a settlement unit is determined by the services that are allocated to the point of delivery.
Point of delivery services for the following service categories are relevant for settlement:
The point of delivery service for this service category describes the service provider responsible for the coordination (execution) of the settlement.
Distribution (optional)
The point of delivery service for this service category describes the service provider, in whose distribution grid a utility service is supplied to the point of
delivery. This service category is only used to define the settlement unit if it refers solely to the points of delivery of a distribution grid.
In the German Associations Agreement Regarding Electric Energy, the settlement unit is defined for all distribution grids. This means that, in this case, a
service provider is not defined for service category Distribution for the settlement unit.
Supply
The point of delivery service for this service category describes the service provider that supplies the point of delivery (supplier).
Points of delivery that have a point of delivery service for the relevant service provider within these service categories are determined for the settlement unit.
When generating the settlement unit, the system compares the service providers specified in the settlement unit with the service providers specified in the
point of delivery. If the service providers match, the relevant point of delivery is taken into account when this settlement unit is settled. For each settlement
unit, the point of is uniquely allocated to a settlement unit.
If changes are made to the point of delivery (during move-in or move-out, for example), the supplier - point of delivery allocation is refreshed and the point of
delivery may be automatically allocated to a new settlement unit.
Use of Sub-Settlement Units

A settlement unit can be allocated to a higher-level settlement unit for the purpose of collective settlement. Settlement is then dependent on the higher-level
settlement unit.
See also:
The example for Defining Settlement Units
!--a11y-->
1.2.3.1 Settlement Unit Category

In the settlement unit category, you determine the service categories used to define the settlement unit.
Various categories are predefined in Customizing for the Utilities Industry under Tools System Modifications User-Defined Enhancements for Energy
Data Management Settlement Define Settlement Unit Category. Controls for the following service categories are required for every settlement unit
category:
Distribution
Supply
When you create a settlement unit in the menu for the Utilities Industry under Energy Data Management Settlement Master Data Create Settlement
Unit , you must select one of the settlement unit categories defined in Customizing.
Use of the Service Category Settlement Coordination
For settlement coordination, you must always specify a service provider in the settlement unit.
Use of the Service Category Distribution
Here you control whether a distributor (service provider with service category Distribution ) has to be specified for settlement units.
You have the following control options:
Service category must be defined
A service provider for distribution (distributor) must be specified when defining settlement units This service provider must then carry out the
service Distribution for all points of delivery allocated to the settlement unit.
Service category can be defined
A service provider for distribution (distributor) can be specified when defining settlement units
If you do specify a service provider, this service provider must carry out the service Distribution for all points of delivery allocated to the
settlement unit.
If you do not specify a service provider, the service Distribution must still exist for all points of delivery allocated to the settlement unit. It is
however not important which service provider carries out the service.
Service category must be defined (service from other service provider)
A service provider for distribution (distributor) must be specified when defining settlement units. The service Distribution must exist for all points
of delivery allocated to the settlement unit. However, it may not be carried out by this service provider.
Use of the Service Category Supply
Here you control whether a supplier (service provider with service category Supply ) has to be specified for settlement units.
You have the following control options:
Service category must be defined
A service provider for supply (supplier) must be specified when defining settlement units This service provider must then carry out the service
Supply for all points of delivery allocated to the settlement unit.
Service category may not be defined
A service provider for supply (supplier) may not be specified when defining settlement units. The service Supply may not exist for any of the
points of delivery allocated to he settlement unit.
Service category must be defined (service from other service provider)
A service provider for supply (supplier) must be specified when defining settlement units. The service Supply must exist for all points of
delivery allocated to the settlement unit. However, it may not be carried out by this service provider.
Example
You can use the settlement unit category to define a settlement area for renewable energy. For this settlement area you can only select points of delivery to
which no service provider with service category Supply is allocated. This is because these points of delivery are not supplied with energy but generate it
themselves.
The following settings are made in Customizing:
Service category settlement coordination Service category distribution Service category supply
Service category must be defined Service category can be defined Service category may not be defined
You can find more information in the implementation guide (IMG) under SAP Utilities Energy Data Management Settlement
General Information on Settlement.
!--a11y-->
1.2.3.2 Example for Defining Settlement Units

Scenario: Municipal utility company X (MUC X) carries out the role of distributor and supplier in one system.
Distributors Perspective
Suppliers Perspective
!--a11y-->
1.2.4 Selection Variants

A selection variant compiles
settlement units that are to be settled together.
Enter the selection variant and not the settlement unit in the
settlement document. The advantage of this is that newly created settlement units that fulfill the criteria of the selection variant are automatically taken into
account for the next settlement run.
You define settlement variants in the menu for the Utilities Industry under Energy Data Management Settlement Selection Variants for Settlement..
!--a11y-->
1.2.5 Settlement Document

Before you can start a settlement run, you must create a settlement document.
Settlement Run Tab Page
Define the following data in the header data:
Settlement period
Settlement procedure
Settlement mode
Selection variant
Once you have saved the settlement document, the status Created is displayed in the Status SD (status of settlement document) field. For further
information on the individual statuses, see the field help for each field.
To start the first settlement run select Start/Stop Settlement Run. Depending on the Customizing settings, you can start this settlement run as a workflow
and/or a report.
The status of the settlement document is updated according to the progress of processing.
Information on the settlement run is displayed in the Run Data group frame. From here you can also go to the technical log and the run log.
Settlement Unit Tab Page
By selecting the selection variant, the relevant settlement units are displayed on the Settlement Unit tab page and stored along with the document when you
save.
Profile Data Tab Page
If result profiles are updated, this is documented in the settlement document on the Profile Data tab page. The same applies for profiles that have been sent.
In addition, you can use Send Profile Data to send profiles subsequently from the settlement workbench.
Send history displays the complete history of sent items.

Error Log Tab Page
Errors that resulted in a settlement step being terminated are listed here. You can confirm these errors manually using Confirm. They are however
confirmed automatically after the next successful run at the latest.
Global errors and warning messages are displayed in the lower screen area. You require special authorization to display or confirm the alerts. You can hide the
alerts by selecting Extras Hide Alerts in the menu bar.
If a settlement run terminates with errors, you can use Run to create a new settlement run in change mode for the same document and subsequently start
a backbilling process. Backbilling means that only those settlement steps are executed again that terminated with errors or for which results were not saved
permanently.
You can only create the second run if the selection of settlement units corresponds with that of the first run.
If you want to execute all settlement steps again, you can use Create Document to create a follow-on document in change mode. This stops the original
document and automatically gives the follow-on document the same header data. The original document number remains visible.
!--a11y-->
1.2.6 Settlement Run
Process Flow
See also:
Settlement document
Settlement procedure
Selection variant
Settlement step
!--a11y-->
1.2.7 Selection Types

Selection types allow you to group together points of delivery that are relevant to settlement according to predefined criteria. By using settlement types, you
can settle multiple profiles (for the point of delivery) that are allocated to the point of delivery with various roles.
The selection type plays a role in defining selections for the settlement procedure.
If points of delivery are combined in a settlement unit in which energy is fed as well as consumed, you can use the selection type to
control what is balanced (energy feeding or consumption).
!--a11y-->
1.2.8 Guidelines for the Development of Settlement

Procedures
This unit describes the steps involved in developing and implementing settlement procedures using
IS-U-EDM.
It also contains additional information on implementation, the data model and interface descriptions.
The following diagram shows one possible scenario for development of a settlement procedure as an example.
If you intend to develop a new settlement procedure using IS-U-EDM, you require a basic knowledge of ABAP OO. You should also be
familiar with the tools required here (such as Class Builder, Workflow Builder).
!--a11y-->
1.2.8.1 Requirements Analysis

You should analyze your requirements before starting to develop new settlement procedures.
Read the following units:
Settlement Procedure Modeling

Identification of Settlement Steps
Identification of Settlement Parameters
!--a11y-->
1.2.8.1.1 Settlement Procedure Modeling

Before implementing a new settlement procedure or modifying a settlement procedure that was defined by SAP, you should analyze your requirements taking
the following points into account:
What are the input parameters for the settlement procedure?
Which input profiles (such as a grid energy-feeding curve) are available before a settlement run is started?
Which profiles or single values are requested as results of the settlement procedure?
Which data is to be communicated to which market participants at what stage?
Is this data to be sent automatically from the settlement run?
Which calculation guidelines are available for determining settlement results?
Are there similarities to the settlement procedures that have been predefined by SAP?
Is a flow control (such as user decisions, date monitoring) required?
Which error handling strategy is to be used in defined error situations?
When should a settlement run be terminated?
Which error situations are tolerable by the system (such as missing profile values)?
In which situations should global alerts be triggered?
Can parameters be determined using upstream formula calculations or batch jobs prior to the settlement run and then used as entry parameters for the
settlement procedure?
Can all points of delivery that are relevant to settlement be assigned to a
settlement unit uniquely?
A settlement unit describes the smallest number of points of delivery for which settlement can be performed collectively. Some settlement procedures
assume that all points of delivery that are relevant to settlement are settled collectively (such as the analytical procedure).
Must interim results for networks be calculated within the settlement units?
Should results be determined for higher-level grids? In these situations, the grid selection must be taken into account by the settlement procedure.
If the grids involved involve more than one settlement unit, all settlement units involved must be specified when you define the selection variants for
settlement.
Do some types of settlement units (such as the settlement area for renewable energy) require special handling?
Which profiles assigned to the point of delivery (assigned to the register or installation) are to be taken into account during settlement (such as the
measured load shape)?
If several profiles for a point of delivery are relevant to settlement, you must use additional selection types
.
!--a11y-->
1.2.8.1.2 Identification of Settlement Steps

Settlement steps implement the actual algorithms in the settlement procedure and determine the results of the settlement procedure (such as the total load
shape for each settlement unit) on the basis of the input parameters (such as the energy-feeding curve) and additional IS-U data (such as points of delivery,
load profile etc).
It is usually possible to represent an entire settlement procedure in a single settlement step. This procedure does not usually return meaningful results and
should therefore only be used in extremely simple settlement procedures. You should consider the following points when specifying the settlement steps
required:
Can calculation of settlement results be divided into partial calculations?
Partial calculations should be defined so that they return meaningful interim results (profiles or single values) that are available for subsequent
evaluations. Division into partial calculations is mandatory if user decisions or time control are required. Partial calculations are usually
performed in separate settlement steps. You must ensure that settlement steps create meaningful algorithm units for business purposes that can
then be used again in other settlement procedures.
Performance-critical calculations that use the same data basis should be performed in a single settlement step to keep overhead costs associated with
saving interim results on a temporary basis or identical data selections to a minimum.
Basic calculation options with profiles should usually be performed in separate settlement steps so that reusable SAP settlement steps can be used
(see also
Reusable Implementation of Settlement Steps).
Is the calculation algorithm similar to the reference settlement procedures provided by SAP (see also
Settlement Procedure)?
Can partial calculations be represented using the settlement steps provided by SAP (see also
Settlement Steps)?
You should base the definition of new settlement steps on existing settlement steps so that any missing steps can be implemented without difficulty (see also
Change/Derive Predefined Settlement Steps).
Partial calculations that are independent of one another or that are based on interim results that have already been determined should be identified to
define possible points where parallel processing or synchronization is possible. Parallel partial calculations should be modeled as settlement steps.
You must define all of the input and output parameters for all settlement steps required. Private data that is selected or created directly in the settlement step
(without being used in the data flow between settlement steps) is not defined as a parameter. Example: Points of delivery that are selected for the settlement
document are not settlement parameters.
Each settlement step is implemented by an ABAP OO class. Any steps required in addition to those settlement steps provided by SAP, must be implemented
(see also
Implementation of Settlement Steps) and defined in Customizing as a company-specific enhancement (see also Company-Specific Enhancements in
Customizing).
!--a11y-->
Identification of Settlement Parameters

Settlement parameters are all profiles and values that are to be saved as results of the settlement procedure and all profiles that are available as input
parameters prior to the settlement run for use in the settlement procedure.
Depending on which algorithm tasks are fulfilled by specific settlement steps, it is usually necessary to define additional settlement parameters that transport
interim results from the settlement procedure between the settlement steps.
Note that each output parameter in a settlement step used in a settlement procedure must be a new settlement parameter. Two different
settlement steps in a settlement procedure cannot calculate the same parameters.
Examples of settlement parameters include:
Energy-Feeding Curve
Total load shape for interval customers for each settlement unit.
Distribution Factors for each customer group.
Settlement parameters (profiles, values), that are used as input parameters, results or interim results in the settlement procedures provided have already been
defined in Customizing.
Before defining a new settlement procedure, you should check whether additional company-specific settlement parameters are required for the settlement
parameters that have been predefined by SAP.
Settlement parameters are distinguished using the following criteria:
Parameter category
The following parameter categories exist:
Value for single values
Profile for load shape, factor profile and so on. It is only currently possible to use profile parameters as input parameters in settlement procedures.
Usage type
The usage type in the parameter defines whether the parameter contains (interim) results that are specific to each settlement unit, each grid or each
settlement procedure or each selection variant.
The usage type also controls how the input or results profile is saved. This means that the profile parameters used must be assigned to the virtual point of
delivery for the settlement unit, grid or settlement variant according to their usage type (see also Virtual Points of Delivery and Profile Assignment).
The energy-feeding curve is specific to the settlement procedure or selection variant.

Frequency of use
Repeatable parameters contain several profiles or values. All parameters that are defined specifically to the settlement unit for each grid or customer
group are usually repeatable parameters.
Example: A repeatable results parameter is the total load shape for all customers in a settlement unit. The parameter is calculated for each settlement
unit.
Use of the reference profile
Any reference profile specified can be taken into account during automatic profile determination. All profile parameters that refer to another profile (such as
a synthetic customer group profile), must contain the reference profile in their header data. These types of parameter are usually also repeatable
parameters. (Example: Distribution factors for each customer group are repeatable parameters that refer to a reference profile (synthetic profile).)
Private data that is selected or created directly in the settlement step (without being used in the data flow between settlement steps), is not
defined as a settlement parameter. (Example: Points of delivery that are selected for the settlement document are not settlement parameters).
!--a11y-->
Implementation of Settlement Steps

Three types of implementation are available for new settlement steps and these are described in detail in the following sections:
Reusable Implementation
Straightforward Customizing change: No ABAP knowledge required
New Implementation
Requires basic knowledge of ABAP OO. Is used if a completely new function is required or a derived implementation is not possible.
Derived Implementation
Requires basic knowledge of ABAP OO. Is used if implementation of the settlement steps provided is to be modified
The following basic functions are provided automatically for all steps regardless of the type of implementation so that new implementation is not required each
time.
Allocate input parameters (profiles, single values)
Perform general consistency checks
Log processing status
Update settlement document
Enter error messages (and other messages) and alerts
Parameter determination and settlement results update (profiles or single values)
Provide display parameters for subsequent steps
!--a11y-->
1.2.8.2.1 Reusable Implementation of Settlement Steps

Before creating a new implementation for the settlement step, you should check whether one of the reusable classes is suitable. This type of implementation
can be used by various settlement steps that calculate different results or evaluate different input parameters according to the Customizing settings made.
To use a reusable implementation for the settlement step in the new settlement procedure, you must enter the parameter assignment for the settlement step in
Customizing.
Add profile types
The CL_ISU_EDM_SETTLSTEP_0005 (4215) class is used to add any profile parameters required. Profiles transferred here can include reusable or single
profiles for one or more settlement parameters.
Parameter number Description
01 (Importing) to NN (Importing) Any profile parameters to be added. Interval lengths and units of
measurements for all profiles must be compatible with the results profile.
01 (Exporting) Total load shape
Customer group profiles can be totaled for a settlement unit or a total load shape can be calculated from several interim results.
Subtract profile types
The CL_ISU_EDM_SETTLSTEP_0009 (4219) class is used to subtract any additional profile parameters from a profile. The profile from which additional profile
parameters are to be subtracted must be defined as an input parameter with parameter number 01.
01 (Importing) A single profile from which additional profiles are to be subtracted. The profile
and the results profile must have the same units of measurement.
01 (Importing) to NN (Importing) Any profile parameters to be subtracted. Interval lengths and units of
measurements for all profiles must be compatible with the results profile.
01 (Exporting) Difference load shape
The total load shapes for interval customers (for each settlement unit), grid losses, lighting unit load shape and so on are subtracted from
the energy-feeding curve to determine the remaining curve (load profile for non-interval customers).
Multiply profile(s) by a value
The CL_ISU_EDM_SETTLSTEP_0008 (4218) class is used to multiply values in a profile by factors that you specify.
01 (Importing) A single profile that is to be multiplied by a factor. The profile and the results
profile must have the same unit of measurement and interval length.
02 (Importing) Value parameters with a factor of the EPROFVAL type. If several individual
factors are transferred (repeatable parameters for a customer group), the
system creates a corresponding number of results profiles that contain the
context for the factor parameter.
01 (Exporting) Results profile(s)
The remaining curve is multiplied by supplier factors to determine the load profile for non-interval customers for each settlement unit
(simple analytical procedure).
Multiply profiles
The CL_ISU_EDM_SETTLSTEP_0007 (4217) class is used to multiply values in a profile by factors from specified factor profiles.
01 (Importing) A single profile that is to be multiplied by a factor profile. The profile and the
results profile must have the same unit of measurement and interval length.
02 (Importing) Factor profile(s) as settlement parameters. If several factor profiles are

transferred (repeatable parameters for a customer group), the system creates
a corresponding number of results profiles that contain the context for the
factor parameter.
01 (Exporting) Results profile(s)
The remaining curve is multiplied by

distribution factors to determine the load profile for non-interval customers for each customer group (enhanced analytical procedure).
Check status of profile values
The CL_ISU_EDM_SETTLSTEP_0010 (42110) class is used to identify whether valid profile values are available in the settlement period.
01 (Importing) to NN (Importing) Profile parameters that have valid profile values in the settlement period.
The energy-feeding curve must contain valid profile values for the entire settlement period in the analytical procedure.
!--a11y-->
1.2.8.2.2 Creation of New Settlement Steps

New settlement steps can be implemented if new settlement steps are required to represent the settlement procedure and none of the reusable
implementations are suitable.
New settlement steps must be implemented as ABAP OO classes.
Two abstract classes are available from which you can derive new settlement steps:
CL_ISU_EDM_SETTLSTEP_0001 is derived if arithmetic operations are to be used for profile values (see also 452).
CL_ISU_EDM_SETTLSTEP is derived if arithmetic operations are not required for profile values in the new settlement step.
Use the Class Builder to create a new class for settlement step implementation. Display the abstract class and on the Characteristics tab page choose
Subclass (Create subclass ). The Class Builder is found in the Tools menu under ABAP Workbench Development.
!--a11y-->
1.2.8.2.2.1 Redefine Methods

All methods that are inherited from a super class and have not been defined as final methods, can be redefined in the derived class. Classes for settlement
steps must redefine the process method and can redefine the prepare_save and save methods. You can redefine a method that you have selected in the
Class Builder by choosing the Redefine function on the Methods tab page. The Class Builder is found in the Tools menu under ABAP Workbench
Development.
Process Method
This method must be redefined in the derived class. It contains specific information on the settlement step. The following parameters are available for this
method:
General instance data (such as settlement document, period, settlement unit(s), session etc)
General control data (such as repeated execution, error during processing etc)
Table that contains profile parameters Parameter number, profile number, settlement unit (optional), grid (optional), reference profile (optional)
Table that contains value parameters Parameter number, value, key (optional), settlement unit (optional), grid (optional), reference profile (optional)
The process method itself must not trigger any messages in coding (such as MESSAGE xnnn). It must not generate a termination or display a dialog box. All
messages/exceptions must be captured internally and returned to the calling application using the Set_Msg, Set_Error, Set_Alert methods. If this is not the
case, the settlement step will not be processed correctly.
You cannot use change accesses to the database or remove a commit work in the process method.
If the settlement step calculates profile or value parameters, these must be made available with the context information (settlement unit, grid, reference profile)
as exporting/changing parameters.
See
Coding Examples
Prepare_Save Method
This method must only be derived if the settlement step is to save local attributes that are not available as profile or value parameters persistently. The
Prepare_Save method must be redefined if company-specific tables are to be updated. It returns the value X if data has been changed and is to be saved.
You cannot generate exceptions, use change accesses to the database or remove a commit work in the redefined Prepare_Save method.
Save Method
This method must only be derived if the settlement step is to save local attributes that are not available as profile or value parameters persistently. It contains
specific write access to the database.
You cannot generate exceptions or remove a commit work in the redefined method.
!--a11y-->
1.2.8.2.2.2 Coding Examples

The following examples show how you can implement simple functionality in the settlement step.
Display Message in the Application Log

Set Alert
Display Error Message
Determine Points of Delivery that are Relevant to Settlement
Read Profile Values (Incl. Status) From the Database
Read Profile Parameters
Check Status of Profile Values
Extrapolate Profile Values
Update Profile
Update Values
Arithmetic Operations with Profile Values
Determine Settlement Units
Select Additional Information on the Settlement Unit
Determine Grids and Customer Groups that are Relevant to Settlement
Select Additional Information on the Settlement Document
Send Profile to Service Provider
A detailed list of available methods can be accessed under
Overview.
!--a11y-->
1.2.8.2.2.2.1 Display Message in the Application Log

The application log is used to enter messages on the progress of the settlement step (such as success messages, error messages, information). You should
ensure that the amount of information is kept within sensible limits. You should only save aggregated information on success messages in the application log.
DATA: l_msg TYPE eedmsettlmsgbody.
l_msg-msgid = co_msg_class.
* No load shapes were selected for the period from &1 to &2
l_msg-msgty = co_msgtype_warning.
l_msg-msgno = '011'.
l_msg-probclass = co_probclass_other.
WRITE x_instance_data-from-datefrom TO l_msg-msgv1.
WRITE x_instance_data-to-dateto TO l_msg-msgv2.
CALL METHOD set_msg( x_msg = l_msg ).
The following components in

eedmsettlmsgbody must be entered:
MSGTY: Message type
MSGID: Message class
MSGNO: Message number
PROBCLASS: Problem class of a message
The
probclass component is used to classify the message and can be used to prevent the messages being entered in the application log or to set a filter for display.
Messages can have the following classification:
Very important messages: co_probclass_veryhigh
Other important messages: co_probclass_high
Messages of medium importance: co_probclass_medium
Additional information: co_probclass_info
Other messages: co_probclass_other
Additional information can be entered in the following components in
eedmsettlmsgbody:
MSGV1: Message variable

MSG_COUNT: Number of cumulated messages
T_PAR: Application log: Table containing parameter names and values
ALTEXT: Application log: Standard text
SETTLUNIT: Message context: Settlement unit
GRID_ID: Message context: Grid
SETTLCONTTEXT_1: Context for settlement log
The msgid, msgty, msgno, msgv1, msgv2, msgv3, msgv4 components are entered in the same way as the system fields SY-MSGNO, SY-MSGID, SY-
MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3 and SY-MSGV4). Where possible, you should specify a context for each message that can be used to locate
messages more quickly.
!--a11y-->
1.2.8.2.2.2.2 Set Alert
DATA:
l_msg TYPE eedmsettlmsg.
Critical consistency errors found during
parameter assignment
l_msg-msgv1 = x_instance_data-settldoc.
l_msg-msgty = co_msgtype_error.
CALL METHOD set_alert( x_msg = l_msg ).
The following components from

eedmsettlmsg must be entered:
MSGTY: Message type
All components in
eedmsettlmsg are entered in the same way as the system fields (SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3 and SY-MSGV4).
An alert must be confirmed manually in the settlement workbench. Special authorization is required to view or confirm alerts.
An alert generates a BOR event simultaneously that can be used in the workflow to send a notification mail.
!--a11y-->
1.2.8.2.2.2.3 Display Error Message

If the system displays an error message with the set_error method, the settlement step will be terminated with the Terminated with error status. No data
transport to subsequent settlement steps takes place and no database update is performed. Once processing has been terminated, an exception is triggered
that must be handled accordingly in the workflow or job. The settlement run is usually terminated in this situation.
DATA: l_msg TYPE eedmsettlmsg.
Critical consistency errors found during
parameter assignment
l_msg-msgv1 = x_instance_data-settldoc.
l_msg-msgty = co_msgtype_error.
CALL METHOD set_error( x_msg = l_msg ).

eedmsettlmsg must be entered:
MSGTY: Message type
All components in
eedmsettlmsg are entered in the same way as the system fields (SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3 and SY-MSGV4).
An error message always indicates a critical error situation and is logged in the settlement document and the application log. Error messages entered can be
confirmed manually in the settlement workbench. Automatic confirmation of error messages takes place during the next settlement run (backbilling following
error) when the cause of the error has been eliminated.
Error messages should only serve as information and not result in backbilling being terminated. They can only be displayed as
messages in the application log.
The settlement unit and/or grid should be specified for the error message to classify the cause of the error in more detail.
CALL METHOD set_error( x_msg = l_msg
x_settlunit = TEST_UNIT
x_grid_id = TEST_GRID ).
!--a11y-->
Determine Points of Delivery That Are Relevant to Settlement
DATA: lt_eedmsettlin TYPE t_eedmsettlin,

lt_eedmsettluf TYPE t_eedmsettluf.
* Determine points of delivery for interval customers

CALL METHOD get_own_points_of_delivery
EXPORTING x_seltype = co_seltype_consumption
IMPORTING yt_eedmsettlin = lt_eedmsettlin.
* Determine points of delivery for non-interval customers

CALL METHOD get_own_points_of_delivery
EXPORTING x_seltype = co_seltype_consumption
IMPORTING yt_eedmsettluf = lt_eedmsettluf.
The get_own_point_of_delivery method only returns points of delivery for settlement units that are processed in the settlement step accessed. Points of
delivery can also be selected by grids and roles in the profile allocation if grids and/or roles in the profile allocation are also specified as parameters when the
method is accessed.
ASSIGNPOD must be executed in the settlement procedure as an initial settlement step so that points of delivery can be determined.
The following data is provided for interval customers:
SETTLUNIT: Settlement Unit
SELTYPE: Selection type for settlement (usually consumption)
GRID_ID: Grid is only returned if grid selection has been activated for the settlement procedure.
To do so, select the GridSel field in Customizing under Energy Data Management Settlement Define Settlement Procedure . (Execute grid
selection).
DATETO: To-date in profile allocation
TIMETO: To-time in profile allocation
INT_UI: Internal point of delivery key
DATEFROM: From-date in profile allocation
TIMEFROM: From-time in profile allocation
ANLAGE: Installation
PROFROLE: Role in a profile allocation
PROFILE: Number of the allocated profile
The USEFACTOR individual consumption factor is returned in addition to the data specified above for non-interval customers.
Consumption information for these types of customer is only usually required in an aggregated format (such as previous years consumption,
aggregated customer group profile). Settlement steps that can be used according to the methods shown here are available for these types of
application.
See also:
Data Selection
!--a11y-->
1.2.8.2.2.2.5 Read Profile Values (Incl. Status) From the

Database
DATA: l_profile_ref TYPE REF TO if_isu_edm_profile_data,
l_profile_number TYPE e_profile,
l_from LIKE x_instance_data-from,
l_to LIKE x_instance_data-to.
l_from_utc LIKE x_instance_data-from_utc,
l_to_utc LIKE x_instance_data-to_utc.
* open new DB profile
CALL METHOD open_profile
EXPORTING x_profile = l_profile_number

IMPORTING y_handle = l_profile_ref
EXCEPTIONS OTHERS = 1.
IF sy-subrc <> 0.
* e.g. repeat sy-msg and close processing with set_error
EXIT.
ENDIF.
* convert valid time range from local timezone to UTC (improve
* performance during reading)
CALL METHOD convert_to_utc
EXPORTING x_from = l_from

IMPORTING y_utc_from = l_from_utc.
CALL METHOD convert_to_utc
EXPORTING x_from = l_to
IMPORTING y_utc_from = l_to_utc.
* read profile values for given time periods
CALL METHOD read_profile_data
EXPORTING x_handle = l_profile_ref

x_date_from = l_from_utc-datefrom
x_time_from = l_from_utc-timefrom
x_date_to = l_to_utc-dateto
x_time_to = l_to_utc-timeto
* X_TIMEZONE = 'UTC'
IF sy-subrc <> 0.
EXIT.
ENDIF.
Read access to profile values, header information or status takes place using the reference to the
IF_ISU_EDM_PROFILE_DATA Interface.
l_profile_ref->profile_number
l_profile_ref->headerdata
l_profile_ref->value_tab
l_profile_ref->value_stat_tab
A more straightforward access to profile values during the settlement period is available in classes that are derived from
CL_ISU_EDM_SETTLSTEP_0001.
DATA: l_profile TYPE tp_profile.
l_profile-profile = 123456.
* read profile and check the status of values
CALL METHOD open_and_read_profile
EXPORTING x_profile = l_profile.

x_instance_data = x_instance_data
IMPORTING y_handle = l_profile_ref
IF sy-subrc <> 0.
EXIT.
ENDIF.
!--a11y-->
1.2.8.2.2.2.6 Read Profile Parameters

Profile parameters (temporary or persistent) are made available to the settlement step as an internal table. You must specify a parameter number in order to
access specific profile parameters.
DATA: l_profile_ref TYPE REF TO if_isu_edm_profile_data.
FIELD-SYMBOLS: <profile> LIKE LINE OF xt_profile.
READ TABLE xt_profile ASSIGNING <profile>

WITH KEY parnumber = co_parnumber_profile.
IF sy-subrc <> 0.
* e.g. close processing with an error message
EXIT.
ENDIF.
* open profile and read values for settlement time range
CALL METHOD open_and_read_profile
EXPORTING x_profile = <profile>
IMPORTING y_profile_ref = l_profile_ref
IF sy-subrc <> 0.
* e.g repeat sy-msg and close processing with set_error
EXIT.
ENDIF.
Access to profile values, header information and status takes place similarly to the DB profile using the reference to the IF_ISU_EDM_PROFILE_DATA
Interface
l_profile_ref->profile_number
l_profile_ref->headerdata
l_profile_ref->value_tab
l_profile_ref->value_stat_tab
The local variable profile_no_values contains a list with numbers of profiles that contain invalid profile values during the settlement period.
!--a11y-->
1.2.8.2.2.2.7 Check Status of Profile Values

The invalid_profile_values_exist method can also be used to check whether valid profile values are available during the settlement period.
DATA: l_handle TYPE REF TO if_isu_edm_profile_data,
l_profile_number TYPE e_profile,
* open profile
EXPORTING x_profile =
l_profile_number
IMPORTING y_handle = l_handle
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF invalid_profile_values_exist( x_handle = l_handle ) = co_selected.
* there are invalid profile values
ENDIF.
!--a11y-->
1.2.8.2.2.2.8 Extrapolate Profile Values

If profile values are not yet available for periods that are relevant to settlement, suitable
replacement value procedures can be used to extrapolate the missing profile values. The header data for the profile to be changed must contain a
replacement value group that provides a procedure for extrapolation.
DATA: l_replace_success type kennzx.
l_handle TYPE REF TO if_isu_edm_profile_data,
lt_error TYPE iedm_replace_message_struct,
l_profile TYPE e_profile.
* open profile for changing values
EXPORTING x_profile = l_profile

x_read_only = space
IMPORTING y_handle = l_handle
IF sy-subrc <> 0.
ENDIF.
* profile values will be estimated (according to given estimation group)
CALL METHOD forecast_missing_values
EXPORTING x_handle = l_handle

IMPORTING yt_error = lt_error
y_replace_success = l_replace_success
IF sy-subrc <> 0.
* e.g. repeat sy-msg and write error into application log
ELSEIF l_replace_success = co_selected.
* e.g. store l_handle to be saved
ELSE.
* e.g. write lt_error as warning into application log
ENDIF.
The
prepare_save and save methods must be redefined to save extrapolated profile values. Modified profile values can be saved to the database by calling the
save_forecasted_profile method. Profile values must be generated at a earlier stage using the forecast_missing_values.
CALL METHOD save_forecasted_profile
EXPORTING x_handle = l_handle

IF sy-subrc <> 0.
* e.g. repeat sy-msg and write error message
ENDIF.
!--a11y-->
1.2.8.2.2.2.9 Update Profile

Profiles that have been defined as parameters for the settlement procedure (output parameters or interim results) are updated automatically. The settlement
step must create a temporary results profile and make the corresponding profile values available in the profile value table. The parameter number used during
creation (
co_parnumber_result) must match the parameter number in the Customizing settings for the settlement step.
DATA: l_result_ref TYPE REF TO if_isu_edm_profile_data,
l_profile_parameter TYPE tp_profile.
* create temporary profile for result parameters
CALL METHOD create_profile
EXPORTING x_parnumber = co_parnumber_result

x_date_from = x_instance_data-from_utc-datefrom
x_time_from = x_instance_data-from_utc-timefrom
x_date_to = x_instance_data-to_utc-dateto
x_time_to = x_instance_data-to_utc-timeto
IMPORTING y_handle = l_result_ref
y_profile = l_profile_parameter
IF sy-subrc <> 0.
EXIT.
ENDIF.
* e.g. store settlunit, grid id and reference profile as context, if needed
* l_profile_parameter-settlunit = TEST_UNIT.
* l_profile_parameter-grid_id = TEST_GRID.
* l_profile_parameter-refprofile = 123456.
* e.g. fill data
* l_result_ref->value_tab = .
* append new entry to exporting parameters
APPEND l_profile_parameter TO yt_profile.
The number of the EDM profile is first determined from the parameter context in the Customizing settings for the settlement procedure and the profile
assignment during the runtime. (compare with the
Automatic Parameter Determination section under Execution of a Settlement Step). If the parameter has a global character and does not refer to a specific
settlement unit and/or specific grid and/or specific reference profile (customer group), it is not necessary to specify the context for the settlement parameter.
Updated profiles are logged in the settlement document.
Profiles can also be updated by saving
extrapolated profile values.
!--a11y-->
1.2.8.2.2.2.10 Update Values

Single values that have been defined as parameters for the settlement procedure (output parameters or interim results) can be updated automatically in
company-specific tables. The settlement step must provide the complete key for the table to be updated in addition to the parameter value. The table name
and field name (optional) must be specified in the Customizing settings for the settlement procedure. You cannot insert new lines or update existing lines in the
database table until you do so. If no field name is specified during parameter definition in Customizing, the single value must be a structured type and
correspond to the line type in the company-specific table.
DATA: l_value_parameter TYPE tp_value,

l_data TYPE string,
l_key type ?????, " table type
l_factor TYPE profval.
* e.g. write single value

l_value_parameter-parnumber = co_parnumber_result.
MOVE l_factor TO l_data. " conversion doesn't work directly with c(255)
l_value_parameter-value = l_data.
MOVE l_key TO l_data. " conversion doesn't work directly with c(255)
l_value_parameter-tablekey = l_data.
* e.g. store settlunit, grid id and reference profile as context, if needed

* l_value_parameter-settlunit = TEST_UNIT.
* l_value_parameter-grid_id = TEST_GRID.
* l_value_parameter-refprofile = 123456.
APPEND l_value_parameter TO yt_value.
The parameter number used when entries were created ( co_parnumber_result) must match the parameter number in the Customizing settings for the
settlement step.
You do not need to specify the key if parameter values are only used as temporary interim results in the settlement procedure. Note that the interpretation of
values (that are transferred as c(255)) must take place in the subsequent steps. Subsequent steps must recognize the type definition for the values in order to
access them.
If the parameter has a global character and does not refer to a specific settlement unit and/or grid and/or reference profile (customer group), it is not necessary
to specify the context for the settlement parameter.
The process of updating parameter values described here should only be used for single values. Mass changes should be made in the
redefined save method by calling the optimized function modules.
!--a11y-->
1.2.8.2.2.2.11 Arithmetic Operations with Profile Values

Settlement results are usually the result produced by performing various arithmetic operations on profile values. Methods that simplify data handling, contain a
large number of consistency checks and automatically convert compatible units of measurement are available for basic operations. These methods can only
be used if the settlement step has been derived from the
CL_ISU_EM_SETTLSTEP_0001 class.
Available methods are listed below:
DATA: l_profile_ref TYPE REF TO if_isu_edm_profile_data,
l_result_ref TYPE REF TO if_isu_edm_profile_data,
l_factor_ref TYPE REF TO if_isu_edm_profile_data,
l_subtrahend_ref TYPE REF TO if_isu_edm_profile_data,
l_factor TYPE
profval,
l_integral TYPE profval
* references have to be created via open_and_read_profile and create_profile
*******************************************
* calculate integral of given profile
*******************************************
CALL METHOD calculate_integral
EXPORTING x_profile_ref = l_profile_ref

EXPORTING y_integral = l_integral
IF sy-subrc <> 0.
ENDIF.
*******************************************
* add values of currently opened profile to result profile
*******************************************
CALL METHOD add_subtract_values
EXPORTING x_profile = l_profile_ref

x_addition = co_selected
CHANGING xy_result = l_result_ref
IF sy-subrc <> 0.
ENDIF.
*******************************************
* subtract values of currently opened profile from result profile
*******************************************
CALL METHOD add_subtract_values

x_addition = space
IF sy-subrc <> 0.
ENDIF.
*******************************************
* subtract values of two profiles and write results to result profile
*******************************************
CALL METHOD subtract_values

X_subtrahend = l_subtrahend_ref
IF sy-subrc <> 0.
ENDIF.
*******************************************
* multiply profile values by factor profile and write results to result profile
*******************************************
CALL METHOD multiply_values

x_factor = l_factor_ref
IF sy-subrc <> 0.
ENDIF.
*******************************************
* multiply all profile values by single factor write results to result profile
*******************************************
CALL METHOD multiply_values

x_factor_single = l_factor
IF sy-subrc <> 0.
ENDIF.
*******************************************
* divide result profile by profile values
*******************************************
CALL METHOD divide_values

IF sy-subrc <> 0.
ENDIF.
The (
l_profile_ref, l_result_ref) data references must be generated prior to calculation using the open_and_read_profile and create_profile methods.
Before implementing new settlement steps that only perform simple arithmetic operations, you should check whether one of the
reusable settlement steps is suitable.
!--a11y-->
1.2.8.2.2.2.12 Determine Settlement Units

The settlement unitss that are to be processed/observed in the called settlement document can be accessed from the instance data (see
Category Definition of the Class CL_ISU_EDM_SETTLSTEP). To determine all the settlement units belonging to the settlement document, you can call the
method of the class CL_ISU_EDM_SETTLEMENT.
DATA:
lt_settlunit type T_EEDMSETTLDOCUNIT.
* All settlement units belonging to the settlement document
CALL METHOD cl_isu_edm_settlement=>select_docunit
EXPORTING X_SETTLDOC = x_instance_data-settldoc " Document number
IMPORTING YT_EEDMSETTLDOCUNIT = lt_settldocunit
EXCEPTIONS others = 1.
IF sy-subrc <> 0.
* ????
ENDIF.
!--a11y-->
1.2.8.2.2.2.13 Select Additional Information on the

Settlement Unit
Methods in the CL_ISU_EDM_SETTLUNIT class can be used to obtain a complete definition of the settlement unit.
DATA: l_settlunitdata type EEDMSETTLUNIT_DB_DATA,
l_settlunittxt type E_EDMSETTLUNITTXT.
* read all data on the settlement unit (header data and historical allocation)
CALL METHOD cl_isu_edm_settlunit=>db_single
EXPORTING IM_SETTLUNIT = x_instance_data-settlunit
IMPORTING EX_DB_DATA = l_settlunitdata
EX_SETTLUNITTXT = l_settlunittxt
IF sy-subrc <> 0.
* ????
ENDIF.
!--a11y-->
Determine Grids & Customer Groups Relevant to Settlement

DATA:
lt_grid_id TYPE t_grid,
lt_refprofile TYPE t_eedmsettlcustgrp.
* Grids relevant to settlement
lt_grid_id = get_grids( ).
* Customer groups relevant to settlement
lt_refprofile = get_refprofiles( ).
ASSIGNPOD must be executed in the settlement procedure as an initial settlement step so that customer groups and grids can be determined. The
grids relevant to settlement can only be accessed if the settlement procedure supports grid selection.
!--a11y-->
1.2.8.2.2.2.15 Select Additional Information on the

Settlement Document
Most data on the settlement document that is required to execute the settlement step is available in the instance data or control data (see
Type Definitions for the CL_ISU_EDM_SETTLSTEP Class). Additional attributes with methods from the CL_ISU_EDM_SETTLEMENT can be selected if
required.
DATA: l_edmsettldoc type eedmsettldoc,
lt_settldocrun type,
l_settldocinfo type EEDMSETTLDOCRUNINFO.
* Read header data on settlement document
CALL METHOD cl_isu_edm_settlement=>select_doc_single
EXPORTING X_SETTLDOC = x_instance_data-settldoc " document number

IMPORTING Y_EEDMSETTLDOC = l_edmsettldoc
IF sy-subrc <> 0.
* ????
ENDIF.
* Read information on specific run
CALL METHOD cl_isu_edm_settlement=>cl_get_run_information
EXPORTING X_SETTLDOC = x_instance_data-settldoc " document number

X_SETTLDOCRUN = x_instance_data-settlrun
IMPORTING Y_INFO = l_settldocinfo " Data on settlement run
IF sy-subrc <> 0.
* ????
ENDIF.
* Read information on all runs in the settlement document
CALL METHOD cl_isu_edm_settlement=>cl_get_all_run_information
EXPORTING X_SETTLDOC = x_instance_data-settldoc " Document number

IMPORTING Y_SETTLDOC = l_edmsettldoc " Header data on document
YT_SETTLDOCRUN = lt_settldocrun " Data on settlement runs
IF sy-subrc <> 0.
* ????
ENDIF.
!--a11y-->
1.2.8.2.2.2.16 Send Profile to Service Provider

Settlement results can be sent to specific service providers from the settlement run. Formats that are used to send profiles (such as
MSCONS, DELFOR etc.) are defined for each service provider in the data exchange definition (see Send Settlement Results).
The data exchange definition describes which data to exchange, using which due date, between which service providers and in what format. This is determined
at service provider level. It is, however, possible to maintain this definition at point of delivery level in exceptional cases (redefined definition).
DATA: l_receiver TYPE service_prov,
wa_profile TYPE eedmsettl_sndprofile.
lt_profile TYPE t_eedmsettl_sndprofile.
wa_profile-profile = 123456.
wa_profile-datefrom = x_instance_data-from-datefrom.
wa_profile-timefrom = x_instance_data-from-timefrom.
wa_profile-dateto = x_instance_data-to-dateto.
wa_profile-timeto = x_instance_data-to-timeto.
wa_profile-time_zone = x_instance_data-timezone.
append wa_profile to lt_profile.
CALL METHOD send_profiles
EXPORTING x_receiver = l_receiver
xt_profile = lt_profile
x_continue_after_error = co_selected
IF sy-subrc <> 0.
* error message is generated by method send_profiles
* continue sending to send as many profiles as possible
ENDIF.

eedmsettl_sndprofile must be entered:
PROFILE: Profile number
DATEFROM: From-date for profile values
TIMEFROM: From-time for profile values
DATETO: To-date for profile values
TIMETO: To-time for profile values
TIME_ZONE: Time zone for settlement
SETTLUNIT and GRID_ID should be specified if the settlement results refer to specific settlement units and/or grids.
All profiles that are transferred in the
t_eedmsettl_sndprofile table are logged with the associated send status (send started, error when sending) automatically in the settlement document. They can be
sent again manually from the settlement workbench.
Any error that occurs when the profile is being sent triggers an alert and is logged as an error in the settlement document.
!--a11y-->
1.2.8.2.3 Change/Derive Predefined Settlement Steps

You can use the settlement steps provided as a template for your own implementation or use the derivation technique to modify their functionality. These
changes are downward compatible and are not lost if an AOSP is imported. You can only derive those classes that have not been defined as a final class.
You must define your own methods for the derived class in the customer namespace.
The derived class can redefine all methods that are inherited from super classes and have not been selected as final . All classes supplied with their
enhancement options are listed under
Classes for Settlement Steps.
To modify the implementation of the settlement steps provided, use the Class Builder to derive a new class from the implementation selected and redefine the
methods to be changed (see
Redefine Methods).
The entire functionality is not usually changed. The main implementation with the prefix super-> can only be accessed in situations in which the process
method that contains the settlement algorithm implementation is to be redefined.
* e.g. call superior functionality after some additional checks or initialization
CALL METHOD super->process
EXPORTING xt_profile = xt_profile

xt_value = xt_value
x_control_data = x_control_data
IMPORTING yt_profile = yt_profile
yt_value = yt_value
CHANGING xyt_profile = xyt_profile
xyt_value = xyt_value.
IF x_control_data-error_occurred = co_selected.
* error message was generated by super class
EXIT.
ENDIF.
* e.g. some additional checks of calculated results can follow
!--a11y-->
New settlement steps must be defined in Customizing so that they can be executed in the settlement procedure (workflow, job). This procedure is identical for
all types of settlement step implementation described.
Reusable Implementation
New Implementation
Derived Implementation
!--a11y-->
1.2.8.2.5 Test Settlement Steps
Since testing the entire settlement procedure (see
Test Settlement Procedure) is usually very complex and does not allow online debugging, the main process flow for settlement steps should be replicated
using a test report that is executed during online processing. All settlement steps can therefore be accessed in a test session. You should note however, that
options for stand-alone testing of new settlement steps that does not incorporate them in a settlement procedure are extremely limited.
The system does not update results, settlement documents or logs to the database during a test session.
All messages that are to appear in the application log are displayed in a dialog box. You must ensure that the log is complete and does not contain any
errors.
All input parameters required must be made available.
You must specify a settlement document if data is to be processed from a point of delivery selection.
Any algorithm errors can be identified through sequential processing of the settlement step. You should set a break point in the redefined process method.
DATA: lt_profile TYPE t_settlsteppar_contprofile,
lt_settlunit TYPE t_settlunit,
l_settldoc TYPE e_edmsettldoc.
BREAK-POINT.
* Set parameter
* Call settlement step in test mode
CALL METHOD cl_isu_edm_settlprocess=>start_step_testmode
EXPORTING
x_settlstep = 'STATCHECK1'
x_settldoc = l_settldoc
xt_impprofiles = lt_profile
xt_settlunits = lt_settlunit
x_datefrom = '20000101'
x_dateto = '20000131'
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
!--a11y-->
1.2.8.3 Implementation of Settlement Procedures

The basic components in a settlement procedure are always identical:
Generate settlement run instance
Set initial status for settlement run (status: started)
Execute settlement steps: Such as selecting points of delivery, determining load shapes for interval customers etc.
Set final status (status: completed OK or terminated)
Settlement procedures are differentiated by their settlement steps and flow control.
A settlement procedure can be represented as follows:
Workflow should be chosen if processes with a long runtime are to be represented and/or the flexibility of the workflow environment (date control, notification,
user determination, parallel processing for sub-processes) is required.
Job is suitable for simple settlement procedures.
!--a11y-->
1.2.8.3.1 Settlement Procedure as Workflow

We recommend that you use the predefined SAP workflow template when you develop your own workflows. The workflow templates contain examples on the
tasks described below.
For each workflow you can activate schedule monitoring, define address data for messages, specify repetition counters for temporary errors (when profiles are
blocked, for example) and so on. For information on configuration options, see Workflow Builder.
To start a settlement run as a workflow, you must first use the background task TS20500362 to generate an object reference. The reference is required in
order to execute the settlement steps.
The data flow definition must contain the settlement document number and the run number. In the workflow container, these parameters must be defined as
input parameters. The settlement workbench transfers the parameters at the start of the workflow.
If the settlement run was successfully instantiated, ISUEDMSettlement und SettlUnits output parameters contains the instance reference and the table with all
the settlement units that are taken into account in the settlement document.
Change Status of Settlement Run

Directly after an instance of the settlement run is generated, you must use the task TS20500364 to change the status of the task to Started . This prevents
additional runs for settlement documents with the same data basis (same settlement units) from being started. In the settlement workbench, the user can then
follow the status of the settlement run.
Apart from the instance reference, the only parameter that is transferred is the internal status description. This can be:
01: Started
02: Finished with OK
03: Terminated
The Finished with OK status should be the last action in the workflow. The Terminated status should be set before the workflow is terminated after a
critical error. Otherwise, a new run for the settlement document cannot be created and the recalculation of the settlement steps cannot be recalculated.
Execute Settlement Step

The backgound task TS20500361 (IS-U-EDM execute settlement step) is used to execute a settlement step. The data flow definition determines which
settlement step is executed.
Generally all the settlement steps (with the exception of parallel steps- see Execute Parallel Settlement Step) and all the parameters (profiles and values) are
transferred to the background task and the results are added to the parameter container. This ensures that, apart from the names of the settlement steps, the
data flow for each step is identical. The settlement step has an automatic filter to calculate the required input parameters. The name of the settlement step
must be transferred (in capital letters) as the SettlStep element.
The Return element can be evaluated in order to determine whether the settlement step ended with a warning.
To ensure that the workflow runs without errors, the following outputs should be modeled:
Step executed
Processing of settlement unit &1 terminated with error &
The simplest way of handling an error is to set the status of the settlement run (see Change Status of Settlement Run), thereby terminating the workflow.
Execute Parallel Settlement Step

Some settlement steps can only process one settlement unit only.
In order to enhance system performance, these settlement steps are executed in parallel. The table of settlement units is used for parallel processing.
Unlike a global settlement step, only one settlement unit may be specified in the data flow definition. This unit is determined by the index access to the table
of settlement units.
If additional settlement steps cannot be called unit all the settlement units were processed, the task running in parallel must be encapsulated in a parallel
section.
Parallel sections can also be used to distribute long-running independent calculations over different servers, thereby optimizing the total runtime.
Set Alert
An alert can be triggered from the workflow. This is necessary if, for example if a settlement step that is critical for processing is terminated due to an error.
The background task used for this is TS20500368.
The following elements must be entered in the data flow:
MSGTY: Message category
The elements are entered in the same way as the system fields (SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3 and SY-
MSGV4).
An alert generates a BOR event simultaneously that can be used in an additional workflow to send a notification mail.
Set or Read Parameter Value

The value parameters of settlement steps that work with values as input parameters are transferred to the container. These parameters are generally
calculated by a pre-stored settlement step. A parameter value can also be set directly in the workflow by the task TS20500369 and then added to the workflow
container.
The parameter name, value, and if necessary context (settlement unit, grid, reference profile) are defined in the data flow. The parameter name must be
entered in capital letters. When you specify the value, ensure you use the technical display (as in ABAP coding) because the entries are not converted.
To read a given value from the workflow container (for example to evaluate the value in a branch condition), use task TS20500370. The selection criterion is
the parameter name (in capital letters), together with the optional criteria of settlement unit, grid, reference profile or key in the data flow definition.
!--a11y-->
1.2.8.3.2 Settlement Procedure as Job

Settlement procedures that are implemented as reports, run identically to procedures controlled by workflow. The mains difference between these 2 forms of
implementation is that the workflow environment contains additional functions such as schedule monitoring, agent determination, parallel processing for partial
processes and so on. Consequently, the report procedure is more suitable for simple processes.
When you implement new settlement procedures, you can use the predefined settlement reports for reference purposes.
Settlement reports have a uniform structure, shown below:
REPORT reedmsettlproc_vv2_synth .
*******************************************
* global prameters of settlement run
PARAMETER: settldoc TYPE e_edmsettldoc OBLIGATORY,
settlrun TYPE e_edmsettldocrun OBLIGATORY.
*******************************************
* global data definition
DATA: process_ref TYPE REF TO cl_isu_edm_settlprocess,
settlunits TYPE t_settlunit,
settlunit TYPE e_edmsettlunit,
impvalues TYPE t_settlsteppar_contvalue,
impprofiles TYPE t_settlsteppar_contprofile,
expvalues TYPE t_settlsteppar_contvalue,
expprofiles TYPE t_settlsteppar_contprofile,
settlsteplevel TYPE e_settlsteplevel.
*******************************************
* class interface
CLASS cl_isu_edm_settlement DEFINITION LOAD.
START-OF-SELECTION.
*******************************************
* Set run status to started (unit 3321)
*******************************************
* Generate instance of settlement run (unit 3322)
*******************************************
* Execute settlement steps (unit 3323)
*******************************************
* Set run status to finished with OK (unit 3321)
Status of Settlement Run

The first activity in the report that models the settlement run entails settings the status of the settlement run to Started
(cl_isu_edm_settlement=>co_settlrunstatus_started). In the settlement workbench, the user can then follow the status of the settlement run.
START-OF-SELECTION.
*******************************************
* set initial status
CALL METHOD cl_isu_edm_settlement=>cl_set_run_status
EXPORTING x_status = cl_isu_edm_settlement=>co_settlrunstatus_started
x_settldoc = settldoc
x_settldocrun = settlrun
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE 'S' NUMBER sy-msgno
EXIT.
ENDIF.
You cannot process additional runs for settlement documents that process the same settlement units until the system sets the status until Finished with
OK (cl_isu_edm_settlement=>co_settlrunstatus_ok) or Terminated (cl_isu_edm_settlement=>co_settlrunstatus_error). The Finished with OK status
should be the last action in the workflow. The Terminated status should be set before the job is terminated after a critical error. Otherwise, a new run for the
settlement document cannot be created and the recalculation of the settlement steps cannot be recalculated.
*******************************************
* set final status of settlement run
EXPORTING x_status = cl_isu_edm_settlement=>co_settlrunstatus_ok
* in case of error: x_status = cl_isu_edm_settlement=>co_settlrunstatus_error
EXCEPTIONS
OTHERS = 1
.
IF sy-subrc <> 0.
EXIT.
ENDIF.

To execute settlement steps, an instance of the settlement run must be generated. When settlement workbench starts the job, you must enter the document
number and run number as input parameters.
PARAMETER: settldoc TYPE e_edmsettldoc OBLIGATORY,

settlrun TYPE e_edmsettldocrun OBLIGATORY.
DATA: process_ref TYPE REF TO cl_isu_edm_settlprocess,

Settlunits TYPE t_settlunit,
settlunit TYPE e_edmsettlunit,
settlsteplevel TYPE e_settlsteplevel,
temp_settlsteplevel TYPE e_settlsteplevel,
impvalues TYPE t_settlsteppar_contvalue,
impprofiles TYPE t_settlsteppar_contprofile,
expvalues TYPE t_settlsteppar_contvalue,
expprofiles TYPE t_settlsteppar_contprofile.
*******************************************
* set initial status first !
EXPORTING x_status = cl_isu_edm_settlement=>co_settlrunstatus_started
IF sy-subrc <> 0.
EXIT.
ENDIF.
*******************************************
CREATE OBJECT process_ref
EXPORTING x_settldoc = settldoc
IF sy-subrc <> 0.
exit_error_repeat_msg.
ENDIF.
*******************************************
* create new run instance
CALL METHOD process_ref->create_settldocrun
EXPORTING x_settldoc = settldoc
IMPORTING yt_settlunit = settlunits
IF sy-subrc <> 0.
exit_error_repeat_msg.
ENDIF.
If the settlement run was successfully instantiated, the yt_settlunit output parameter contains the table with all the settlement units that are taken into
account in the settlement document.
Execute Settlement Step

The methods of the CL_ISU_EDM_SETTLPROCESS class are used to execute settlement steps. As described in the unit Generate Settlement Run Instance
unit, an instance of the settlement run must have been generated beforehand. The x_settlstep parameter determines which settlement step is executed.
This parameter must therefore contain the name of the settlement step to be executed in capital letters.
*******************************************
* call single settlement step
* calculate suplier factors (as profile and single value)
CALL METHOD process_ref->start_step
EXPORTING x_settlstep = 'FACTSUP'
xt_impprofiles = impprofiles
xt_impvalues = impvalues
xt_settlunits = settlunits
IMPORTING yt_expprofiles = expprofiles
yt_expvalues = expvalues
CHANGING xy_settlsteplevel = settlsteplevel
IF sy-subrc <> 0.
* e.g. set status of settlement run and quitt processing
MESSAGE s415(eedmset).
EXPORTING x_status = cl_isu_edm_settlement=>co_settlrunstatus_error
IF sy-subrc <> 0.
* e.g. repeat sy-subrc
ENDIF.
EXIT.
ENDIF.
APPEND LINES OF expprofiles TO impprofiles.

APPEND LINES OF expvalues TO impvalues.
All the settlement steps have a uniform interface.

X_SETTLSTEP: Settlement parameter name
XT_IMPVALUES: Table containing value parameters for settlement steps (optional)
XT_IMPPROFILES: Table containing profile parameters for settlement steps (optional)
XT_SETTLUNITS or X_SETTLUNIT: List of settlement units for global settlement steps, or individual settlement unit
YT_EXPVALUES: Table containing value parameters for settlement steps
YT_EXPPROFILES: Table containing profile parameters for settlement steps
Y_COMPLETED_WITH_WARNINGS: Return parameter
XY_SETTLSTEPLEVEL: Level of settlement step processing
Generally all the settlement steps (with the exception of steps that run for each settlement unit) and all the parameters (profiles and values) are transferred and
the results are added to the parameter container. The settlement step has an automatic filter to calculate the required input parameters.
The y_completed_with_warnings determines whether the settlement step ended with warning messages.
An exception when start_step is called indicates that a critical error occurred when the settlement step was executed. The simplest way of handling an error is
to set the status of the settlement run, thereby terminating the job.
Some settlement steps can only process one settlement unit only. If you use these steps, note that the description of the settlement unit must be transferred
in the x_settlunit parameter. The xt_settlunits parameter is only used for settlement steps that process the data of more than one settlement unit.
*******************************************
* call settlement step that is processed for one settlement unit only
LOOP AT settlunits INTO settlunit.
*******************************************
* calculate load profile of all interval metered customers of one
* settlement unit
temp_settlsteplevel = settlsteplevel.
CALL METHOD process_ref->start_step
EXPORTING x_settlstep = 'SUMINTSU'
xt_impprofiles = impprofiles
xt_impvalues = impvalues
x_settlunit = settlunit
IMPORTING yt_expprofiles = expprofiles
yt_expvalues = expvalues
CHANGING xy_settlsteplevel = temp_settlsteplevel
IF sy-subrc <> 0.
* e.g. set status of settlement run and quitt processing
EXIT.
ENDIF.
APPEND LINES OF expprofiles TO impprofiles.
APPEND LINES OF expvalues TO impvalues.
ENDLOOP.
settlsteplevel = temp_settlsteplevel.
Every time the start_step method is called, the processing level (settlsteplevel) of the settlement step in the settlement procedure increases. To ensure that a
step has the same processing level for each settlement unit, the processing level should be reset in loops.
Set Alert
An alert can be triggered from the job. This is necessary if, for example if a settlement step that is critical for processing is terminated due to an error.
DATA: wa_alert TYPE eedmsettlmsgalert,

lt_alert TYPE t_eedmsettlmsgalert.
wa_alert-msgty = 'E'.
wa_alert-msgno = '488'.
wa_alert-msgid = 'EEDMSET'.
wa_alert-msgv1 = settldoc.
wa_alert-msgv2 = settlrun.
* wa_alert-msgv3 = .
* wa_alert-msgv4 = .
* wa_alert-settlunit = .
* wa_alert-grid_id = .
wa_alert-settldoc = settldoc.
wa_alert-settldocrun = settlrun.
wa_alert-settlalertstatus =
cl_isu_edm_settlement=>co_settlalertstatus_activ.
append wa_alert to lt_alert.
* set alert
CALL METHOD cl_isu_edm_settlement=>cl_alert_write
EXPORTING xt_alert = lt_alert
The following components in eedmsettlmsgalert must be entered:

MSGTY: Message type
SETTLDOC: Settlement document
SETTLDOCRUN: Settlement run number
SETTLALERTSTATUS: Activate alert (cl_isu_edm_settlement=>co_settlalertstatus_activ)
The input parameters of the alert are entered in the same way as the system fields (SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-
MSGV3 and SY-MSGV4). Enter the alert context (settlement unit and grid) if the message refers to a specific settlement unit and/or grid.
An alert generates a BOR event simultaneously that can be used in the workflow to send a notification mail.
Set or Read Parameter Value

Access to the t_settlsteppar_contvalue parameter table can be used to set or read a parameter value. Note that you must enter the parameter name in capital
letters.
Read Data for Run

The reference to the settlement run can be used to access runtime information on the run (process_ref->run_information). The reference contains the following
data:
SETTLDOCMODE: Settlement run mode (simulation, active)
SETTLRUNTYPE: Type of settlement run (for example re-calculation after error)
!--a11y-->
New settlement procedures must be defined in Customizing so that they can be started from the settlement workbench. This procedure is identical for both
types of settlement procedure implementation described (
Workflow, Job).
See also:
Implementation Guide (IMG) for SAP Utilities under Energy Data Management Settlement .
!--a11y-->
1.2.8.4 Company-Specific Enhancements in Customizing

Company-specific enhancements for settlement parameters, settlement steps and settlement procedures are made in Customizing for the SAP Utilities
component under: Tools System Modifications Customer-Specific Function Enhancements for Energy Data Management Settlement .
!--a11y-->
1.2.8.5 Test Settlement Procedure

A settlement procedure test must take at least the following points into account :
Customizing checks for company-specific enhancements
Settlement procedure Customizing checks
Parameter allocation checks
Settlement result checks
Correct error handling
Correct logging
Prepare Test Data
A settlement procedure test requires a complete set of Customizing and an minimum amount of test data. The diagram below shows the main activities
involved in building a simple test scenario.
Search for Errors/Check List

The graphic below can be used as a guide when searching for errors. Subsequent pages contain checklists for activities A, B and C. These simplify error
analyses.
The following checklists enable you to localize typical sources of errors and correct them. Once the error has been corrected, the settlement text can be
continued/repeated.
Checklist A: Error in Parameter Determination

Checklist B: Error During Point of Delivery Selection
Checklist C: Error in the Settlement Procedure Process Flow
!--a11y-->
Checklist A: Error During Parameter Determination

Have all input parameters, output parameters and interim results for the settlement procedure been defined correctly and completely? Note that there are
various types of parameters: Procedure-specific, specific to each settlement unit, specific to each grid.
Have all mandatory input parameters and all output parameters in the settlement procedure been configured completely? A role for the profile allocation or a
profile number (global parameters only) must be specified for each profile parameter.
Have sample profiles been created and assigned to the parameters for all output parameters and interim results? A profile that is used as a sample during
results creation must be specified for each profile parameter that is generated in the settlement step. Header data for the sample profile (profile type,
profile values type, unit of measurement, interval lengths etc) must be compatible with the assigned results profiles.
Have all profile parameters been assigned to the point of delivery for the variant or the settlement unit or grid (according to the parameter type) with the
correct role (and the correct context if necessary)? Profile parameters must be unique. This means that the same profile cannot be used for different
parameters.
Have roles been specified for point of delivery selection and profile sending?
Has point of delivery selection been performed for the settlement document if grid or customer group-specific parameters are used? A complete test of
parameter determination is only possible following target group selection.
Do all remaining error messages/warnings refer to optional input parameters and interim results? These types of messages can be ignored.
!--a11y-->
1.2.8.5.2 Check List B: Error During Point of Delivery
Selection
Is the settlement step for point of delivery selection (ASSIGNPOD) called in the settlement procedure? If the settlement procedure has been defined as a
workflow, you should also check the data flow definition and workflow Customizing settings.
Has processing of the settlement procedure been terminated prior to point of delivery selection? You should only usually perform general consistency
checks prior to point of delivery selection. If these steps cause the procedure to terminate, you must first correct the error that is causing the
termination.
Has the grid selection been specified in the Customizing settings for the settlement procedure if grids are to be considered here?
Have the correct roles for point of delivery selection been specified for interval customers and residential customers? Customer groups cannot be
evaluated if no residential customers are selected.
Have synthetic profiles with the role(s) specified been assigned to the installations? Have profiles for interval customers been assigned to registers with
the correct role(s)?
Are points of delivery relevant to settlement and have they been assigned to the correct settlement units? The point of delivery is assigned to the
settlement unit implicitly by specifying the point of delivery services (settlement coordination, distribution and supply).
!--a11y-->
1.2.8.5.3 Check List C: Error in the Settlement Procedure

Process Flow
Have all settlement steps been performed in the correct order? Have settlement steps that calculate all results in the settlement procedure been called?
Are settlement steps only called once for each settlement unit?
Are all input parameters in the container made available to the settlement steps? Have output parameters been attached to the container? If the
settlement procedure has been defined as a workflow, you should also check the data flow definition.
Has executing the settlement step triggered a short dump? Settlement steps that trigger an exception that has not been covered here can be identified in
the application log by the fact that the last processing status is the same as Being processed . (Technical context: These types of steps have the In
progress step in the workflow log). Implementation of the respective settlement step contains errors.
Have all settlement steps calculated the output parameters requested? The missing/calculated output parameters are listed as technical information in
the application log.
Does the interval length in the results profile correspond to the interval length specified in the settlement procedure?
Are the correct results profiles updated? Do the settlement steps and the settlement procedure have the same parameter definition? Have all profile
parameters been assigned to the point of delivery for the variant or the settlement unit or grid (according to the parameter type) with the correct role (and
the context if necessary)?
If the settlement procedure has been defined as a workflow, you should also check the workflow Customizing settings. Are errors listed in the workflow
log (list with technical details)?
Is the status of the run set to Completed OK or Terminated before the settlement run has been completed?
Have technical error messages been displayed in the application log? The cause of the error is described in greater detail in the error message long text.
Have the settlement steps been logged correctly and completely?
Can errors described in check lists A and B be eliminated?
!--a11y-->
1.2.8.6 Overview
This overview contains a short description of the
settlement parameters, settlement steps, and settlement procedures delivered by SAP.
The methods that you can use for the implementation of company-specific settlement steps and settlement procedures are listed in other sections (see
Classes and Interfaces for Implementing New Settlement Steps and Classes and Category Definitions for Implementing New Settlement Procedures).
For information on the selected technical concepts see
Technical Concepts.
!--a11y-->
1.2.8.6.1 Settlement Parameters

The table below contains the definition of the settlement parameters (profiles, values) that are used as input parameters, results, or interim results in the
predefined SAP settlement procedure.
Parameter name Parameter description Category Usage type Repeatable Reference profile
PrDiffLoadSup Overtake and undertake Profile Specific parameter for One difference profile for
amounts in the settlement each settlement unit each settlement unit
unit (supplier)
PrFactGrp Distribution factors for Profile Specific parameter of One factor profile for each Synthetic profile of
customer group settlement procedure customer group customer group
PrFactSup Supplier factor Profile Specific parameter for One factor profile for each
each settlement unit settlement unit (supplier)
PrFactSupGrp Supplier factor for Profile Specific parameter for One factor profile for each Synthetic profile of
customer group each settlement unit customer group and customer group
settlement unit (supplier)
PrInpLoad Energy feeding curve Profile Specific parameter of

settlement procedure
PrLoad02 Load profile of all non- Profile Specific parameter of

interval customers settlement procedure
(remaining load shape)
PrLoadGrid Total load shape in grid Profile Specific parameter for One load profile for each
each utility grid grid
PrLoadGridAll Total load shape in grid Profile Specific parameter for One load profile for each
including lower-level grids each utility grid grid
PrLoadGrp01 Load profile of non-interval Profile Specific parameter of One load profile for each Synthetic profile of
customers for each settlement procedure settlement unit and grid customer group
customer group (within the settlement unit)
PrLoadSup Total load shape in Profile Specific parameter for One load profile for each
settlement unit each settlement unit settlement unit
PrLoadSup01 Load shape of interval Profile Specific parameter for One load profile for each
customers of the each settlement unit settlement unit
settlement unit
PrLoadSup02 Load profile of non-interval Profile Specific parameter for One load profile for each
settlement unit
PrLoadSup02s Load profile of non-interval Profile Specific parameter for One load profile for each
settlement unit (synthetic)
PrLoadSupAll Total load shape for each Profile Specific parameter for One load profile for each
settlement unit including each settlement unit higher-level settlement
sub-settlement units unit
PrLoadSupGrid01 Load shape of interval Profile Specific parameter for One load profile for each
customers of the each utility grid settlement unit and grid
settlement unit in the grid (within the settlement unit)
PrLoadSupGrid02 Load profile of non-interval Profile Specific parameter for One load profile for each
customers of the each utility grid settlement unit and grid
settlement unit in the grid (within the settlement unit)
PrLoadSupGrp01 Load profile of the non- Profile Specific parameter for One load profile for each Synthetic profile of
interval customer group of each settlement unit customer group and customer group
the settlement unit settlement unit (supplier)
PrLoadSupGrp01s Load profile of the non- Profile Specific parameter for One load profile for each Synthetic profile of
interval customer group of each settlement unit customer group and customer group
the settlement unit settlement unit (supplier)
(synthetic)
PrLoadSupSettl Settled total load shape in Profile Specific parameter for One load profile for each
settlement unit each settlement unit settlement unit
PrLossAdd Other losses in the energy Profile Specific parameter of

feeding area settlement procedure
PrLossGrid Losses in the grid Profile Specific parameter for One load profile for each
each utility grid grid
PrLossSup Losses for each settlement Profile Specific parameter for One load profile for each
unit each settlement unit settlement unit
VFactSup Supplier factor as Value Specific parameter for One factor for each
individual value for the each settlement unit settlement unit (supplier)
settlement period
(corresponds to
PrFactSup)
VFactSupGrp Supplier factor for Value Specific parameter for One factor for each Synthetic profile of
customer group as each settlement unit customer group and customer group
individual value for the settlement unit (supplier)
settlement period
(corresponds to
PrFactSupGrp)
VLastConsSupGrp Previous years Value Specific parameter for One value for each Synthetic profile of
consumption from non- each settlement unit customer group and customer group
interval customers for each settlement unit (supplier)
settlement unit
!--a11y-->
1.2.8.6.2 Settlement Steps

Settlement steps are the smallest (algorythmically sensible) units from which settlement procedure can be assembled.
Settlement steps model settlement algorythms. You can link input parameters (profiles and individual values) and calculate output parameters.
The implementation of settlement steps is object-oriented. They can be inherited in order to modify them to minor changes to your requirements. An
implementation can be used repeatedly in different contexts.
See also:
Classes for Settlement Steps

Predefined Settlement Steps
!--a11y-->
1.2.8.6.2.1 Classes for Settlement Steps

CL_ISU_EDM_SETTLSTEP_0001: General Methods
CL_ISU_EDM_SETTLSTEP_0002: Allocating Points of Delivery
CL_ISU_EDM_SETTLSTEP_0003: Determine Load Shape of Interval Customers for Each Settlement Unit
CL_ISU_EDM_SETTLSTEP_0004: Load Profile of Non-Interval Customers (Synth.) for Each Settlement Unit
CL_ISU_EDM_SETTLSTEP_0005: Adding Profiles
CL_ISU_EDM_SETTLSTEP_0006: Determine total load shape including sub-settlement units
CL_ISU_EDM_SETTLSTEP_0007: Multiplying Profiles
CL_ISU_EDM_SETTLSTEP_0008: Multiplying Profiles and Values
CL_ISU_EDM_SETTLSTEP_0009: Subtracting Profiles
CL_ISU_EDM_SETTLSTEP_0010: Check Status of Profile Values
CL_ISU_EDM_SETTLSTEP_0011: Determine Supplier Factor for Analytical Procedure
CL_ISU_EDM_SETTLSTEP_0012: Send Result Profiles to Settlement Unit
CL_ISU_EDM_SETTLSTEP_0013: Send Result Profiles to Grid
CL_ISU_EDM_SETTLSTEP_0014: Supplier Factor for Enhanced Analytical Procedure
CL_ISU_EDM_SETTLSTEP_0015: Distribution Factor for Enhanced Analytical Procedure
CL_ISU_EDM_SETTLSTEP_0016: Load Profile of Non-Interval Customers for Each Grid
CL_ISU_EDM_SETTLSTEP_0017: Load Shape of Interval Customers for Each Grid/Settlement Unit
CL_ISU_EDM_SETTLSTEP_0018: Determine Total Load Shape for Each Grid
CL_ISU_EDM_SETTLSTEP_0019: Determine Total Load Shape Including Lower-Level Grids
CL_ISU_EDM_SETTLSTEP_0020: Load Profile of Non-Interval Customers (Enh. Analyt.)
CL_ISU_EDM_SETTLSTEP_0021: Previous Years Consumption of Non-Interval Customers for Each Settlement Unit
CL_ISU_EDM_SETTLSTEP_0022: Send Result Profiles for Grids and Settlement Unit
CL_ISU_EDM_SETTLSTEP_0023: Consistency Checks
CL_ISU_EDM_SETTLSTEP_0024: Estimate Missing Profile Values
CL_ISU_EDM_SETTLSTEP_0025: Calculate Supplier Factors for Each Customer Group
CL_ISU_EDM_SETTLSTEP_0026: Check Status of Upstream Settlement Procedure
!--a11y-->
General Methods
Abstract class derived from CL_ISU_EDM_SETTLSTEP
The class contains universally valid methods that can be used by settlement steps that process profiles.
!--a11y-->
Allocating Points of Delivery

Final class derived from CL_ISU_EDM_SETTLSTEP
The process method determines the allocated PoDs for each settlement unit in a settlement run. The method determines whether consumption for each PoD
is entered via an interval meter or a normal consumption meter (synthetic load profile is allocated at installation level) see also Data selection.
If a selection document was entered, a new selection is not executed. Instead, the system checks whether valid data already exists for the settlement period.
The selection results are saved in the following tables in the database:
EEDMSETTLUF for synthetic load profiles including usage factor
The profile number of the synthetic load profile also contains information about the allocation to a customer group (for non-interval customers)
in the table.
EEDMSETTLIN for load shapes (measured using an interval meter)
!--a11y-->
Load Shape of Interval Customers for Each Settlement Unit

Class derived from CL_ISU_EDM_SETTLSTEP_0001
The process method adds the load shapes of all interval customers that have the selection type consumption, for the settlement period and the transferred
settlement units. It then provides the total load shape (per settlement unit) as a result parameter with the parameter number 01.
All selected load shapes must have compatible interval lengths and units of measurement (an error message is issued if this is not the case). The units of
measurement and the interval lengths are automatically converted into the unit of measurement and interval length of the result profile (for example, 30
minutes into 15 minutes).
The system issues a warning if load profiles were not selected for the transferred settlement units, or if the selected load profiles contain invalid data in the
settlement period.
Class CL_ISU_EDM_SETTLSTEP_0003 can be derived.
Application examples for derived classes

In the redefined constructor , the co_seltype variable can be set to process the load shapes to another selection type.
In the redefined write_log method, an error/alert message can be issued if too many profiles contain invalid values.
!--a11y-->
Load Profile of Non-Interval Customers for Each Settlement Unit

The process method determines the load profiles of non-interval customers with the selection type consumption , for the settlement period and the
transferred settlement units. It supplies the total load profile (per settlement unit) as a result parameter with the parameter number 01. An additional total load
profile with the parameter number 02 is also made available for every customer group in the settlement unit. The load profiles are calculated from the synthetic
profile of the customer group and the consumption factors.

In the redefined constructor , the co_seltype variable can be set to process the profiles to another selection type.
!--a11y-->
Adding Profiles
The process method adds the values of transferred profiles from the settlement period and supplies the total load shape as a result parameter with the
parameter number 01.
Any number of profiles with compatible interval lengths and units of measurement can be transferred. The result profile context corresponds to the resulting
context of all input profiles.
The system issues a warning if the transferred profiles contain invalid data in the settlement period. An error message is issued if the units of measurement
from the input parameters and the result parameter are incompatible.

In the redefined process method, profile parameters can be grouped according to different criteria and then added in the super->process
method (for example, CL_ISU_EDM_SETTLSTEP_0018: Determine Total Load Shape for Each Grid).
In the redefined write_info method an alert, for example, can be triggered if the transferred profiles contain invalid values in the settlement
period.
!--a11y-->
Total Load Shape Including Sub-Settlement Unit

The process method adds the total load shapes of the transferred settlement units in the settlement period. These are then transferred as input parameter 01
in accordance with the settlement unit hierarchy. The total load shape (including subsettlement unit) for every higher-level settlement unit exists as a result
parameter with the parameter number 01. If a settlement unit does not contain any subsettlement units, the result profile for this settlement unit corresponds to
the total load shape.
The system issues a warning if a total load shape is not transferred for a sub or higher-level settlement unit.

In the redefined write_log method, an error/alert message can be issued if a total load shape is missing for a subsettlement unit or a higher-
level settlement unit.
!--a11y-->
Multiplying Profiles
The process method multiplies the values of the transferred load profile by the factors from a profile for the settlement period. It supplies the resulting profile
as result parameter with the parameter number 01.
Both input parameters must have compatible interval lengths:
Input parameter 01 => load profile
Input parameter 02 => profile(s) with factors
If several factor profiles are transferred (parameters in table form, for example, per customer group), the system creates a corresponding number of result
profiles that contain the context for the factor parameter.
from input parameter 01 (load shape) and the result parameter are not compatible. The unit of measurement of the result parameter is preset via sample profile
allocation to the settlement parameter.
Example: The energy-feeding curve is multiplied by distribution factors for each customer group in order to produce the load profile of non-interval customers in
a customer group.
In the redefined process method, profile parameters can be grouped according to different criteria and then multiplied in the super->process
method. This enables you, for example, to assign factors to a several profiles one after the other.
In the redefined write_info method, an alert, for example, can be triggered if the transferred profiles contain invalid values in the settlement
period.
!--a11y-->
Multiplying Profiles and Values

The process method from CL_ISU_EDM_SETTLSTEP_0001
For the settlement period, the settlement step multiplies the values of the transferred load profiles by a factor, and supplies the resulting profile as result
parameter with the parameter number 01.
Input parameter 01 => load profile
Input parameter 02 => single factor from category EPROFVAL (or table with single values)
If several individual factors are transferred (parameters in table form, for example, for each customer group), the system creates a corresponding number of
result profiles that contain the context for the factor parameter.
The system issues a warning if the transferred load profile contains invalid data in the settlement period. An error message is issued if the units of
measurement from input parameter 01 (load shape) and the result parameter are not compatible. The unit of measurement of the result parameter is preset via
sample profile allocation to the settlement parameter.
The energy-feeding curve is multiplied by supplier factors to obtain the load profile of non-interval customers of a settlement unit.

In the redefined process method, profile parameters and factors can be grouped according to different criteria, and then multiplied in the
super->process method. This enables you to assign factors to a number of profiles one after another (for example,
CL_ISU_EDM_SETTLPROCESS_0020).
period.
!--a11y-->
Subtracting Profiles
For the settlement period, the process method subtracts the values of transferred profiles from the load profile, and supplies a profile as a result parameter.
Any number of profiles with compatible interval lengths and units of measurement can be transferred:
Input parameter 01 => load profile from which other profiles are subtracted.
Input parameter 02. NN => profiles to be subtracted
from the input parameters and the result parameter are incompatible. The unit of measurement of the result parameter is preset via sample profile allocation to
the settlement parameter.

In the redefined process method, profile parameters can be grouped according to different criteria, and then subtracted in the super-
>process method.
period.
!--a11y-->
Check Status of Profile Values

The process method checks the status of profile values in the settlement period for all transferred profiles and generates an error message if any single
profile values have an invalid status.
!--a11y-->
Supplier Factor for Analytical Procedure

The process method calculates the supplier factors for the analytical procedure. It does this using the current allocation of PoDs to settlement units and non-
interval customers consumption from the previous year.
The previous years consumption for non-interval customers per customer group and settlement unit must be entered as input parameter (01).
A profile with supplier factor(s) is updated per settlement unit using parameter number 01. In addition, a single value for each settlement unit with the
parameter number 02 is also made available for further processing in the settlement process.
Supplier factor =
Previous years consumption for non-interval customers in the settlement unit /
Previous years consumption of all non-interval customers
!--a11y-->
Send Result Profiles for Settlement Unit

Class derived from CL_ISU_EDM_SETTLSTEP
The process method sends settlement result profiles to service providers of the settlement unit. In order to select the service provider, the definition of the
settlement units is interpreted. Profile values are sent for the settlement period if the profiles with the roles entered for the settlement procedure have been
allocated to the corresponding service provider (distributor, supplier, settlement coordinator).
A warning is issued if the service provider has not been allocated any profiles to be sent.
Processing is terminated with an error and no data is sent if the system cannot determine a point of delivery for one of the service providers.
An alert is triggered if an error occurs when profiles are sent. The other profiles are still sent, however. All profiles to be sent are (automatically) saved in the
settlement document and given a send status.
The settlement step cannot be started again (for example, after an error) if data has already been sent to the same settlement document.

The redefined continue_processing method must return co_selected if the settlement step is to be called again after data has been sent to
the same settlement document.
The redefined append_profile_to_send method can be used to additionally filter or set the parameter context of the profiles to be sent.
In the redefined get_service_provider method, you can enter the service providers who are to receive the data (for example,
CL_ISU_EDM_SETTLSTEP_0013).
In the redefined get_profile_context method, the parameter context (settlement unit, grid, reference profile (customer group)) can be
determined if profiles that are not settlement parameters must be sent.
!--a11y-->
Send Result Profiles for Grid
The process method sends settlement result profiles to the service provider. In order to select the service provider, the grid definition is interpreted. Profile
values are sent for the settlement period if the profiles with the roles entered for the settlement procedure have been allocated to the distributor.
A warning is issued if the distributor has not been allocated any profiles to be sent. Processing is terminated with an error and no data is sent if the system
cannot determine a point of delivery for one of the service providers.
An alert is triggered if an error occurs when profiles are sent. The other profiles are still sent, however. All profiles to be sent are (automatically) saved in the
settlement document and given a send status.
The settlement step cannot be started again (for example, after an error) if data was already sent to the same settlement document.

See CL_ISU_EDM_SETTLSTEP_0012.
!--a11y-->
Supplier Factors for Enhanced Analytical Procedure

The process method calculates the supplier factors for the analytical procedure. It does this based on the current allocation of PoDs to settlement units and
non-interval customers consumption from the previous year per customer group.
A profile with supplier factor(s) is updated per settlement unit and customer group. Single factors and the previous years consumption per customer group is
also made available:
Parameter number 01 => profile with supplier factors
Parameter number 02 => supplier factor as single value
Parameter number 03 => previous years consumption for customer group
Supplier factor of customer group =

Previous years consumption for customer group in the settlement unit /
Previous years consumption for all customers of the customer group
!--a11y-->
Distribution Factors for Enhanced Analytical Procedure

The process method calculates the distribution factors for the enhanced analytical procedure using the previous years consumption for the customer group
(see CL_ISU_EDM_SETTLSTEP_0014) and the synthetic profile.
A profile with distribution factors (parameter number 01) is updated per customer group.
Synthetic load profile of customer group =

Synthetic profile * Previous years consumption for customer group /
Synthetic annual consumption
Distribution factors of customer group =

Customer group load profile /
Total profile of all customer groups
!--a11y-->
Load Profile of Non-Interval Customers for Each Grid

The process method determines the load profiles of non-interval customers for the transferred settlement unit and grids for the settlement period. It supplies
the total load profile for the settlement unit (parameter number 01) and the total load profiles per grid in the settlement unit (parameter number 02) as result
parameters. The load profiles are calculated from the synthetic profile of the customer group and the consumption factors.
The settlement step can only be called using a settlement unit.

In the redefined process method, super->process can be called per settlement unit if different settlement units are to be processed using the
same algorithm in the derived settlement step .
!--a11y-->
Load Shape of Interval Customers for Each Grid/Settlement Unit

The process method adds the load shapes of all interval customers for the transferred settlement unit and grids for the settlement period. It supplies the total
load shape of the settlement unit (parameter number 01) and the total load shape per grid in the settlement unit (parameter number 02) as result parameters.
All selected load shapes must have compatible interval lengths and units of measurement (an error message is issued if this is not the case). The units of
measurement and the interval lengths are automatically converted into the unit of measurement and interval length of the result profile (for example, 30
minutes into 15 minutes).
The system issues a warning if load profiles were not selected for the transferred settlement unit, or if the selected load shapes contain invalid data in the
settlement period.

In the redefined process method, super->process can be called per settlement unit if different settlement units are to be processed using the
same algorithm in the derived settlement step .
!--a11y-->
Total Load Shape for Each Grid

The process method adds profiles with the same grid context (for all settlement units) for the settlement period and supplies the total load shape per grid as
result profile 01.
The system issues a warning if the load shapes contain invalid data in the settlement period.

An error/alert message can be issued in the redefined write_log method, if data is not transferred to a grid.
!--a11y-->
Total Load Shape Including Lower-Level Grids

The process method adds the total load shapes of the transferred grids (input parameter 01) for the settlement period, taking into account the hierarchy. The
total load shape (including lower-level grids) exists as result parameter 01 for every higher-level grid. If a grid does not have any lower-level grids, the result
profile for this grid is the total load shape.
Only one total profile is allowed per grid as result parameter. Processing is terminated if a total load shape for a lower-level grid is not transferred.
!--a11y-->
Load Profile of Non-Interval Customers

The process method multiplies the values for the billing period from the transferred load profiles of the customer group by a supplier factor, adds together the
results for all customer groups and supplies the resulting profile as a result parameter.
Input parameter 01 => load profiles of customer groups
Input parameter 02 => single factor (supplier factor)
The settlement step is used in complex analytical procedures to produce the load shape of non-interval customers in a settlement unit.
!--a11y-->
Previous Years Consumption from Non-Interval Customers for

Each Settlement Unit
The process method multiplies the values for the billing period from the transferred load profiles of the customer group by a supplier factor, adds together the
results for all customer groups and supplies the resulting profile as a result parameter.
Input parameter 01 => load profiles of customer groups
Input parameter 02 => single factor (supplier factor)
The settlement step is used in complex analytical procedures to produce the load shape of non-interval customers in a settlement unit.
!--a11y-->
Send Result Profile for Grids/Settlement Units

The process method sends settlement result profiles to different service providers. In order to select the service provider, the definition of the utility grids and
the settlement units is interpreted. Profile values for the settlement period are sent if the profiles have been allocated the role entered for the settlement
procedure and one of the following points:
The grid distributor
The settlement coordinator
The settlement unit distributor
The settlement unit supplier
A warning is issued if a service provider has not been allocated any profiles to be sent. Processing is terminated with an error and no data is sent if the
system cannot determine a point of delivery for one of the service providers. An alert is triggered if an error occurs when profiles are sent. The other profiles
are still sent, however. All profiles to be sent are (automatically) saved in the settlement document and given a send status.
The settlement step cannot be started again (for example, after an error) if data was already sent to the same settlement document.

See CL_ISU_EDM_SETTLSTEP_0012.
!--a11y-->
Consistency Checks
The process method checks for critical consistency errors in the allocation and Customizing of settlement parameters. These errors normally cause the
system to terminate the settlement procedure and are therefore output as an alert. You can execute the same consistency check from the settlement
document by choosing Goto Test Parameter Determination .
The settlement step is called after the data selection.
!--a11y-->
Estimate Missing Profile Values

The process method extrapolates missing profiles for interval customers for the settlement period. If the profile is not allocated to the entire settlement
period, the profile values are only extrapolated for the allocation period. Once profile values have been extrapolated, the changed profiles are saved in the
save method.
The algorithm for extrapolation is calculated from the definition of the replacement value procedure group in the profile header of the current profile.
An error message is issued if profile values cannot be extrapolated.

If you do not want extrapolated values to be saved, the prepare_save and save methods must be redefined (no implementation necessary).
The extrapolated profile values can then only be processed further (for example, added) in the redefined process method once super -
>process has been called.
!--a11y-->
Calculate Supplier Factors for Each Customer Group

The process method calculates the supplier and distribution factors for the enhanced analytical procedure. It does this for each customer group based on the
current allocation of PoDs to customer groups (synthetic profiles) and non-interval customers usage factors.
The aggregated (synthetic) load profile for non-interval customers per customer group and settlement unit must be entered as input parameter (01).
A profile with supplier factors is updated (output parameter 01) for each customer group and settlement unit:
Supplier factors of customer group =
Load profile of customer group per supplier / Total profile of all customer groups
with
Load profile of customer group per supplier =
Synthetic profile * Usage factor of customer group per supplier
A profile with VDEW distribution factors for each customer group (output parameter 02), and a profile with a VDEW supplier factor (output parameter 03) for
each settlement unit can be updated if this is necessary based on the VDEW interim results. Output parameters 02 and 03 are only calculated if the
parameters have been entered in Customizing for the settlement steps.
The VDEW distribution factors are calculated by addtion the SAO supplier factors for each customer group.
VDEW distribution factors of customer group = Load profile of customer group / total profile of all customer groups
with
Load profile of customer group = Synthetic profile * Usage factor of customer group
Sum of all VDEW distribution factors per hour is equal to 1.00.
The VDEW supplier factor for each customer group corresponds to dividing the supplier factor of the customer group with the VDEW distribution factor.
VDEW supplier factor =
Supplier factors of customer group / VDEW distribution factors of customer group
For performance reasons, only enter output parameters 02 and 03 in Customizing if necessary based on the VDEW interim results (distribution
and supplier factors).
Alternatively, the supplier factor can take on different values every quarter of an hour. This is because the usage factor can be prorated to the
day. However, since the calculated and forecasted usage factors that are relevant for settlement are generally identical, the difference is
negligible.
!--a11y-->
Check Status of Upstream Settlement Procedure

The process method checks whether the upstream settlement procedure entered in Customizing was carried out successfully. The last settlement run of the
upstream settlement procedure must have been calculated correctly for the same settlement period and the same selection variant.
The system issues an error message if no successful active run of the upstream procedure took place during an active run, or if no run of the upstream
procedure took place for a simulation run.
Only use the settlement unit if an upstream settlement procedure is entered in Customizing.
!--a11y-->
1.2.8.6.2.2 Predefined Settlement Steps
The following settlement steps are predefined by SAP:
ASSIGNPOD: Allocating Points of Delivery to Settlement Units
CHECKPARAM: Consistency Check for Parameter Determination
CHECKSETTL: Status Check for Upstream Settlement Procedure
DIFFSU: Overtake and Undertake Amounts for Each Settlement Unit
FACTGRP: Determine Distribution Factors for Enhanced Analytical Procedure
FACTSUP: Determine Supplier Factor for Analytical Procedure
FACTSUPGRP: Determine Supplier Factor for Enhanced Analytical Procedure
FASUPGRP01: Determine SAP Supplier Factor for Enhanced Analytical Procedure
LASTCONSSU: Previous Years Consumption from Non-Interval Customer Group for Each Settlement Unit
SENDGRIDPR: Send Result Profiles for Grid
SENDSUGRPR: Send Result Profiles for Grid and Settlement Unit
SENDSUPR: Send Result Profiles for Settlement Unit
STATCHECK1: Status Check for Profile Values of Energy Feeding Curve
SUMGRID: Determine Total Load Shape for Each Grid
SUMGRIDALL: Determine Total Load Shape Including Lower-Level Grids
SUMINTSU: Determine Load Shape of Interval Customers for Each Settlement Unit
SUMINTSU01: Determine Load Shape of Interval Customers for Each Grid/Settlement Unit
SUMRES01SU: Load Profile of Non-Interval Customers (Synth.) for Each Settlement Unit
SUMRES02SU: Load Profile of Non-Interval Customers (Analyt.) for Each Settlement Unit
SUMRES03SU: Load Profile of Non-Interval Customers for Each Grid in a Settlement Unit
SUMRES04SU: Load Profile of Non-Interval Customers (Enh. Analyt.) for Each Settlement Unit
SUMRES05SU: Load Profile of Non-Interval Customer Group (EXTANALYT) for Each Settlement Unit
SUMRES06SU: Load Profile of Non-Interval Customers (EXTANALYT) for Each Settlement Unit
SUMRES07SU: Load Profile of Non-Interval Customer Group (Synthetic) for Each Settlement Unit
SUMRESALL: Load Profile of All Non-Interval Customers
SUMRESGRP: Load Profile of Non-Interval Customer Group (Enh. Analyt.)
SUMSU: Determine Total Load Shape for Each Settlement Unit
SUMSU01: Determine Total Load Shape (Without Losses) for Each Settlement Unit
SUMSUALL: Determine Total Load Shape Including Sub-Settlement Units
!--a11y-->
1.2.8.6.2.2.1 ASSIGNPOD
Name ASSIGNPOD
Allocating Points of Delivery to Settlement Units
Class CL_ISU_EDM_SETTLSTEP_0002
Additional information The settlement step provides basic data for subsequent steps in the settlement
procedure and consequently must be executed at the beginning. The selection of
points of delivery for interval customers and non-interval customers is based on the
role definition and the selection types for the settlement procedure (see also Data
Selection).
If the grid selection function was activated in the settlement procedure, the grid is
determined for each point of delivery.
Parameter number/type None
Parameter description
!--a11y-->
1.2.8.6.2.2.2 CHECKPARAM
Name CHECKPARAM
Consistency Check for Parameter Determination
Additional information The settlement step can be used to report configuration errors as alerts.
The point of delivery must be selected (ASSIGNPOD) before the settlement step is
called if you want to save grid or customer group-specific results.
Parameter number/type None
Parameter description
!--a11y-->
1.2.8.6.2.2.3 CHECKSETTL
Name CHECKSETTL
Status Check for Upstream Settlement Procedure
Class CL_ISU_EDM_SSETTLSTEP_0026
Additional information The settlement step is used to check the calculation status of the upstream
settlement procedure when determining overtake and undertake amounts
(settlement procedure FINSETTL).
!--a11y-->
1.2.8.6.2.2.4 DIFFSU
Name DIFFSU
Overtake and Undertake Amount for Each Settlement Unit
Additional information The difference between the energy quantity actually consumed and the energy
quantity settled (overtake and undertake amount) is determined for each settlement
unit.
The settled energy quantity is generally an input parameter of the settlement
procedure. The quantity of energy actually consumed must be determined from the
actual meter reading results (load shapes, usage factors) before settlement step
DIFFSU is executed.
Parameter number/type 01 - Importing
Parameter description PrLoadSup Total Load Shape in the Settlement Unit (current)
Parameter number/type 02 Importing
Parameter description PrLoadSupSettl - Settled Total Load Shape in the Settlement Unit
Parameter number/type 01 - Exporting
Parameter description PrDiffLoadSup Overtake and Undertake Amount in Settlement Unit
!--a11y-->
1.2.8.6.2.2.5 FACTGRP
Name FACTGRP
Determine Distribution Factors for Enhanced Analytical Procedure
Additional information The distribution factors for the enhanced analytical procedure are determined from
the non-interval customers consumption from the previous year and the synthetic
load profiles. The synthetic profiles must be generated for the settlement period.
The settlement step provides basic data for the purpose of dividing the remaining
curve between the customer groups.
Point of delivery selection (settlement step ASSIGNPOD) and consumption
determination (settlement step LASTCONSSU) should already have been executed
before the settlement step is called.
Note: See the note for settlement step LASTCONSSU.
Parameter description VlastConsSupGrp Previous Years Consumption of Non-Interval Customer for

Each Customer Group of the Settlement Unit.
Parameter description PrFactGrp - Distribution Factors for Customer Group
!--a11y-->
1.2.8.6.2.2.6 FACTSUP
Name FACTSUP
Determine Supplier Factors for Analytical Procedure
Additional information The supplier portions (supplier factors) of the load shape of non-interval customers
are determined from the non-interval customers consumption from the previous
year in the settlement unit. There is one factor profile for each settlement unit for the
purpose of updating the supplier factors. For further processing in the settlement
procedure, the supplier factor is usually used as a single value.
The settlement step provides the data basis for dividing the remaining curve
between the settlement units in the analytical procedure.
Parameter description VLastConsSupGrp Previous Years Consumption of Non-Interval Customer for

Each Customer Group and Each Settlement Unit.
Parameter description PrFactSup Supplier Factor
Parameter description VFactSup Supplier Factor as Single Value
!--a11y-->
1.2.8.6.2.2.7 FACTSUPGRP
Name FACTSUPGRP
Determine Supplier Factor for Enhanced Analytical Procedure
are determined, for each customer group, from the non-interval customers
consumption from the previous year in the settlement unit. There is one factor profile
for each settlement unit and each customer group for the purpose of updating the
supplier factors. For further processing in the settlement procedure, the supplier
factor is usually used as a single value.
between the settlement units in the enhanced analytical procedure.
Note: See the note for settlement step LASTCONSSU.

Parameter description PrFactSupGrp Supplier Factor for Customer Group
Parameter description VFactSupGrp Supplier Factor for Customer Group as Single Value
!--a11y-->
1.2.8.6.2.2.8 FASUPGRP01
Name FASUPGRP01
Determine SAP Supplier Factor for Enhanced Analytical Procedure
are determined, for each customer group, from the usage factors of the non-interval
customers in the settlement unit. There is one factor profile for each settlement unit
and each customer group for the purpose of updating the supplier factors.
between the settlement units in the enhanced analytical procedure (EXTANALYT).
Point of delivery selections (settlement step ASSIGNPOD) and determination of
aggregated synthetic profiles (for each supplier and customer group) (settlement
step SUMRES07SU) must have already taken place before the settlement step is
called.
Parameter description PrLoadSupGrp01s Load Profile of Non-Interval Customer Group of Settlement

Unit (Synthetic)
Parameter description PrFactSupGrp Supplier Factor for Customer Group
Parameter description PrFactGrp Distribution Factors for Customer Group
!--a11y-->
1.2.8.6.2.2.9 LASTCONSSU
Name LASTCONSSU
Previous Years Consumption from Non-Interval Customers for Each Customer
Group for Each Settlement Unit
Additional information The non-interval customers consumption from the previous year is determined in
the settlement unit for every customer group. To determine the previous years
consumption, the corresponding synthetic profile is valuated using the consumption
factors of the previous year. To optimize the calculation time, you can use the
Generate Consumption History transaction (or report
REEDMSETTLPODCONSGEN) to generate the consumption history before starting
the settlement run
The settlement step is obsolete. It provided the data basis for calculating
supplier and distribution factors in the analytical and enhanced analytical
procedures (VV2_ANAEXT, VV2_ANALYT) , which have been replaced by the
optimized enhanced settlement procedure (EXTANALYT).

!--a11y-->
1.2.8.6.2.2.10 SENDGRIDPR
Name SENDGRIDPR
Send Result Profiles for Grid
Additional information The settlement results are sent to the distributors of the grids that are taken into
account during settlement (including all higher-level grids). You must have
activated grid selection for the settlement procedure. All distributors must be fully
created as business partners (with contract, installation, and so on). The profiles to
be sent are allocated to the point of delivery of the corresponding business partner
(see Sending Settlement Results).
All settlement results must already have been calculated and transferred in the
container to the settlement step before calling the settlement step.
Parameter number/type Not specified
Parameter description All settlement parameters
!--a11y-->
1.2.8.6.2.2.11 SENDSUGRPR
Name SENDSUGRPR
Send Result Profiles for Grid and Settlement Unit
Additional information The settlement results are sent to the distributors of the grids that are taken into
account during settlement (including all higher-level grids), and to the service
providers of the settlement units. You must have activated grid selection for the
settlement procedure. All service providers (suppliers, settlement coordinators,
distributors) must be fully created as business partners (with contract, installation,
and so on). The profiles to be sent are allocated to the point of delivery of the
corresponding business partner (see Sending Settlement Results).
!--a11y-->
1.2.8.6.2.2.12 SENDSUPR
Name SENDSUPR
Send Result Profiles for Settlement Unit
Additional information The settlement results are sent to the service providers of the settlement units that
are taken into account. All service providers (suppliers, settlement coordinators, and
distributors (optional)) must be fully created as business partners (with contract,
installation, and so on). The profiles to be sent are allocated to the point of delivery
of the corresponding business partner (see Sending Settlement Results).
!--a11y-->
1.2.8.6.2.2.13 STATCHECK1
Name STATCHECK1
Status Check for Prof. Values of Energy-Feeding Curve
Additional information The system checks whether the profile values of the energy-feeding curve are
complete for the settlement period.
If the energy-feeding curve is an input parameter of the settlement procedure (for
example, in the analytical procedure), the settlement step should be called at the
beginning of the settlement run.
Parameter description PrInpLoad Energy-feeding curve
!--a11y-->
1.2.8.6.2.2.14 SUMGRID
Name SUMGRID
Determine Total Load Shape for Each Grid
Additional information The total load profiles of the interval and non-interval customers in the grid (and the
grid losses if they are available) are added together. Only those grids are taken into
account, for which points of delivery relevant to settlement were selected
(settlement step ASSIGNPOD). In this way, at least one input parameter is
transferred to the grid.
The total load shapes must be determined before you call the settlement step (for
example, SUMINTSU01 and SUMRES03SU).
The settlement step only provides valid results if you activated grid selection in the
settlement procedure.
Parameter number/type 01 Importing optional
Parameter description PrLoadSupGrid01 - Load shape of interval customers from the settlement unit in the
grid
Parameter description Load profile of non-interval customers from the settlement unit in the grid
Parameter description PrLossGrid - Losses in the grid
Parameter description PrLoadGrid - Total load shape in grid
!--a11y-->
1.2.8.6.2.2.15 SUMGRIDALL
Name SUMGRIDALL
Determine Total Load Shape Including Lower-Level Grids
Additional information The grid load shapes of the lower-level grids are added to the grid load shape. Only
one total load shape per grid is allowed as an input parameter. Processing is
terminated if a total load shape for a lower-level grid is not transferred.
The total load shape for each grid must be determined before you call the
settlement step (for example, SUMGRID).
Parameter description PrLoadGrid - Total load shape in grid
Parameter description PrLoadGridAll - Total load shape in grid including lower-level grids
!--a11y-->
1.2.8.6.2.2.16 SUMINTSU01
Name SUMINTSU01
Load Shape of Interval Customers for Each Grid/Settlement Unit
Additional information The load shapes of the interval customers are added for each grid for the
transferred settlement unit. In the process, compatible measurement units and
interval lengths are automatically converted to the measurement unit and interval
length of the result profile.
You should have already selected a point of delivery (settlement step ASSIGNPOD)
before you call the settlement step.
Parameter description PrLoadSup01 - Load shape of interval customers from the settlement unit
Parameter description PrLoadSupGrid01 - Load shape of interval customers from the settlement unit in the
grid
!--a11y-->
1.2.8.6.2.2.17 SUMINTSU
Name SUMINTSU
Load Shape of Interval Customers for Each Settlement Unit
Additional information The load shapes of the interval customers are added for the transferred settlement
unit. In the process, compatible measurement units and interval lengths are
automatically converted to the measurement unit and interval length of the result
profile.
Parameter description PrLoadSup01 - Load shape of interval customers from the settlement unit
!--a11y-->
1.2.8.6.2.2.18 SUMRES01SU
Name SUMRES01SU
Load Profile from Non-Interval Customers (Synth.) for Each Settlement Unit
Additional information For the transferred settlement unit, the synthetic profiles of the non-interval
customers are evaluated using individual consumption factors, and the total load
shape is determined for each customer group and settlement unit. The total load
profile for each customer group is only made available for those customer groups
with points of delivery in the transferred settlement unit that are relevant to
settlement.
Parameter description PrLoadSup02 - Load shape of non-interval customers from the settlement unit
Parameter description PrLoadSupGrp01 - Load shape of non-interval customers for each customer group
of the settlement unit
!--a11y-->
1.2.8.6.2.2.19 SUMRES02SU
Name SUMRES02SU
Load Profile from Non-Interval Customers (Analyt.) for Each Settlement Unit
Additional information The load shape of the non-interval customer for the transferred settlement unit is
calculated by multiplying the remaining curve with the supplier factor.
The remaining curve (settlement step SUMRESALL) and the supplier factors
(settlement step FACTSUP) must be determined before you call the settlement step.
Parameter description PrLoad02 - Load profile of all non-interval customers (remaining curve)
Parameter description VFactSup Supplier factor (as single value)
!--a11y-->
1.2.8.6.2.2.20 SUMRES03SU
Name SUMRES03SU
Load Profile from Non-Interval Customers for Each Grid in a Settlement Unit
Additional information For the transferred settlement unit, the synthetic profiles of the non-interval
customers are evaluated using individual consumption factors, and the load shape
is determined for each grid and settlement unit. The total load profile for each grid is
only made available for those grids with points of delivery in the transferred
settlement unit that are relevant to settlement.
Parameter description PrLoadSupGrid02 - Load shape of non-interval customers from the settlement unit
per grid
!--a11y-->
1.2.8.6.2.2.21 SUMRES04SU
Name SUMRES04SU
Load Profile from Non-Interval Customers (Enh. Analyt.) for Each Settlement
Unit
Additional information The load shape of the non-interval customer for the transferred settlement unit is
calculated by multiplying the customer group profiles with the corresponding
supplier factor and adding the profiles.
The customer group profiles (settlement step SUMRESGRP) and the supplier
factors (settlement step FACTSUPGRP) must be determined before you call the
settlement step.
Parameter description PrLoadGrp01 - Load profile of non-interval customers for each customer group
Parameter description VFactSupGrp Supplier factors for each customer group (as single value)

Saphelp Utilities472 en 81 A0023b288dd720e10000000a114084 Frameset

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Saphelp Utilities472 en 81 A0023b288dd720e10000000a114084 Frameset

Загружено:

Авторское право:

Доступные форматы

Energy Data Management

PDF download from SAP Help Portal:

Created on February 10, 2017

1 Energy Data Management

Central database for energy data (Energy Data Repository)

Importing Profile Values

Replacement Value Creation

Profile Display and Editing

Displaying Profiles on the Internet

1.1 Profile Management

1.1.1.1 Profile Categories

1.1.1.1.2 Synthetic Profile

1.1.1.1.2.1 Usage Factor

The usage factor was entered manually.

Changes in the Consumption Pattern

The consumption pattern of the customer changed on 02.28.

1.1.1.1.3 Day Profile

1.1.1.1.4 Integral Profile

1.1.1.1.5 Formula Profile

1.1.1.2 Interval Length

You can convert a 30 minute interval into a 10 minute interval.

1.1.1.3 Profile Header

1.1.2 Replacement Value Creation

1.1.2.1 Replacement Value Processes

Interpolation of profile values

Linear replacement value procedure

1.1.2.2.1 Linear Replacement Value Procedure

13:00 25.48 + 0.95 = 26.43

13:15 26.43 + 0.95 = 27.38

The replacement values are added to the profile.

1.1.2.2.2 Maximum Value Replacement Value Procedure

1.1.2.2.3 Minimum Value Replacement Value Procedure

1.1.2.2.4 Replacement Values Copied from Historical Values of

Date Time Value

01.01.2001 12:00:00 21.54

01.01.2001 12:15:00 23.44

01.01.2001 12:30:00 24.53

01.01.2001 13:30:00 28.43

01.01.2001 13:45:00 29.31

01.01.2001 14:00:00 30.02

Date Time Value

01.01.2000 12:45:00 26.21

01.01.2000 13:00:00 26.43

01.01.2000 13:15:00 27.12

Date Time Value

01.01.2001 12:00:00 21.54

01.01.2001 12:30:00 24.53

01.01.2001 12:45:00 26.21

01.01.2001 13:00:00 26.43

01.01.2001 13:15:00 27.12

01.01.2001 13:30:00 28.43

01.01.2001 13:45:00 29.31

01.01.2001 14:00:00 30.02

1.1.2.2.5 Replacement Values Copied from Profile of Control

Date Time Value

01.01.2001 12:00:00 21.54

01.01.2001 12:15:00 23.44

01.01.2001 12:30:00 24.53

01.01.2001 13:30:00 28.43

01.01.2001 13:45:00 29.31

01.01.2001 14:00:00 30.02

Profile Day from Time from Day to Time to Register

4711 01.01.2000 00:00:00 01.01.2001 12:59:59 1000012111