SAP Device Management configurations

1. Define Control Parameters for Scheduling

IMG -> Utilities 􀁯 Basic Functions 􀁯 Portion and
Scheduling 􀁯 Define Control Parameters for Scheduling



2. Define Number Ranges for Register Groups

IMG -> Utilities 􀁯 Device Management 􀁯 Technology
􀁯 Register Groups 􀁯 Define Number Ranges for Register
Groups

3. Define Register IDs

IMG -> SAP Utilities 􀁯 Device Management 􀁯
Technology 􀁯 Register Groups 􀁯 Define Register IDs.

This is used to to define the register identification of the Registers. The register
identification along with the division helps in defining the functions of a Register

4. Define Register Types

IMG -> SAP Utilities 􀁯 Device Management 􀁯
Technology 􀁯 Register Groups 􀁯 Define Register Types

The Register Type determines at what time a particular Register will start and stop registering the
energy consumption

5. Define Help Table for Specification of Material Reference

IMG -> Utilities 􀁯 Device Management 􀁯 Technology
􀁯 Device Category 􀁯 Define Help Table for specification
of Material Reference

This is to specify materials to be automatically used as reference
materials for the IS-U-specific material master for creation of Device Category.
Linking the IS-U Device Category to the material ensures integration of IS-U Device
Management with MM and therefore, use of the existing standard
functions in IS-Utilities.

6. Define Number Ranges for Logical Device Numbers of Devices

IMG -> SAP Utilities 􀁯 Device Management 􀁯
Installation 􀁯 Define Number Range for Logical Numbers
of Devices

The Logical Device Number identifies the position of a Device in a device location and
therefore, in the installation structure as well. In replacement of Devices, the new
Device adopts the Logical Device Number of the removed Device

7. Define Number Ranges for Logical Register Numbers of Registers

IMG -> SAP Utilities 􀁯 Device Management 􀁯
Installation 􀁯 Define Number Range for Logical Numbers
of Registers.

Logical Register Number is automatically assigned to all Device Registers upon
installation of Devices in a device location. The number is not displayed on the
screen and it only used internally in the programs

8. Define System Parameters for Installation/Removal/Replacement

IMG -> SAP Utilities 􀁯 Device Management 􀁯
Installation 􀁯 Define System Parameters for
Installation/Removal/Replacement.

This is used to maintain system parameters for installing, replacing, and
removing Devices

9. Define Technical Control Parameters for Meter Reading Data Processing

IMG -> SAP Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Basic Settings 􀁯 Define Technical Control
Parameters for Meter Reading Data Processing.

This is used to maintain the technical control parameters for meter reading
data processing. The following parameters can be configured in this step. The
parameters are valid for the entire system....
Display plausible meter readings only
Display implausible meter readings only
Change meter reading-relevant rate type

10. Define Control Parameters for Meter Reading Data Processing

IMG -> SAP Utilities 􀁯 Device Management 􀁯 Meter
Reading􀁯 Basic Settings 􀁯 Define Control Parameters
for Meter Reading Data Processing.

This can be used in for maintaining control parameters for meter reading
data processing like triggering of warnings or error messages for meter reads,
triggering of Service Orders or Service Notifications, etc.

11. Define Meter Reading Control

IMG -> SAP Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Basic Settings 􀁯 Define Meter Reading
Control.

This is used to control below parameters....

Permitted number of meter readings by customer
Permitted number of estimations
Sum of the permitted number of estimations and meter readings by the customer

12. Define Validation Class

IMG -> SAP Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Validation Checks 􀁯 Independent Validations
􀁯 Define Validations Class

This is used in for defining validation classes that are used in meter read
validations

13. Allocate Independent Validations to Validation Class

IMG -> SAP Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Validation Checks 􀁯 Independent Validations
􀁯 Allocate Independent Validations to Validation
Classes.

This can be used in for assigning the types of independent validations that
are to be performed...These validations are assigned to the Validation Classes

Zero consumption validation – Independent validation Number 01
Permitted number of estimated meter readings – Independent validation Number 03
Absolute tolerance limits – Independent validation Number 06

14. Define Validation Parameters for Validation Classes

IMG -> Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Validation Checks 􀁯 Independent Validations
􀁯 Define Validation parameters for Validation Classes.

This is used to define the number of days in a meter reading period in
which zero consumption of a register is accepted

15. Define Tolerance Limits for Validation Classes

IMG -> Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Validation Checks 􀁯 Independent Validations
􀁯 Define Tolerance limits for Validation Classes

This is used to define the tolerance limit for the independent
validation types. SAP allows defining the positive and negative limits for absolute
consumption deviation for a consumption period.

16. Define Number Ranges for Meter Reading Orders

IMG -> Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Meter Reading Order 􀁯 Order Creation 􀁯
Define Number Ranges for Meter Reading Orders

This is used in to define a number range object, which describes
number assignment used for the Meter Reading Orders

17. Define Meter Readers

IMG -> Utilities 􀁯 Device Management 􀁯 Meter
Reading 􀁯 Meter Reading Order 􀁯 Order Creation 􀁯
Define Meter Readers

This is used in to define the meter readers. has to allocate the meter
readers defined here to a Meter Reading Unit

18. Device Info Record

IMG -> Utilities 􀁯 Device Management 􀁯 Installation
􀁯 Device Info record

This can be used in to define the device info record. This could be used
where metering is done without physical device

SAP ISU meter to bill process

End to end process from meter to bill

• Creation of company codes, divisions
• Creation of regional structure: Streets,City, postal codes 
• Creation of business master data: CA,BP,contract
• Creation of technical master data: Conn object, premise, installation, device location, POD
• Creation of Register groups and winding groups                          
• creation of material in MM and corresponding device category in ISU
• Creation of device in ISU
• Creation of scheduled master records: Portion, MRU
• Creation of scheduled records
• Creation of street routes
• Creation of Meter reading validations: Dependent and independent
• Creation of Tech and bill Installation parameters
• Creation of billing master data: billing class, rate type,price,operands,rate,schema,rate cat,  rate determination, fact groups                     
• Creation of parameters for billing and invoicing documents
• Creation of billing validations
• Creation of fica sub transactions
• Creation of notifications and work orders

Billing definitions

Operand: It is a variable that is assigned values at run time. It is a variable that is used as input and output in variant programs.

Operand Category: It determines the function of the operand.

Operand Group: It helps to group operands in rates/rate categories/installations facts for display purpose

Weighing procedure: It is a method using which sap determines expected values of meter readings

Access Control: It defines how historical values of operands (in rate/rate category/installation facts) are accessed during billing.

Replacement value for operand: It indicates that the value of this operand is maintained at a different level or it is not calculated until billing. If you specify replacement value options (required value/optional value/run time value), you are not required to specify an operand value.

Variant Program: It is a function module in rate steps that performs basic calculation by using input and output operands. Some variant programs calculate values relevant to billing and generate billing line items. Some other variant programs convert values and in turn, make the results available to subsequent variant program.

Facts(rate/rate category/installation fact): Allocation of values to operands

Price adjustment block: To adjust the blocks/scales for qty based price if billing period differs from the basic time specified in the price.This is only valid for block price and not for scale price

Price adjustment clause: It uses price adjustment factor by which basic price is to be updated (summation or multiplication). The advantage is that is you maintain the price adjustment clause in all prices, then you can have same price increase/decrease applied to all prices where this price adjustment clause is maintained.

Periodic control: It helps to control how periods are to be calculated in rate steps. In other words, it is a customer defined version of the base calculation procedure which is used to calculate the length of time portions for billing relevant periods.

Variant control: Some variant programs require additional input parameters to define their actions. And these parameters are set in the rate step by using variant control. These parameters are different for different variant programs. For example, for quanti01 (if info lines to be written about quantity), for IF02 (amount 1>=< amount 2 ) etc.

Fact group: It enables different operand values to be used within one rate. For example, operand A can have value A under fact group A but value B under fact group B. Fact group is always entered in combination with rate type.

RTP billing

The billing of interval-related data (profiles) is called real time pricing billing (RTP billing). RTP billing allows you to define rates and prices freely across intervals and therefore enables you to structure contracts that are required in a deregulated energy market more freely.

RTP billing is based on rate models that evaluate energy requirements over a period of time. Consumption (and demand if necessary) are measured for each interval (for example 15/30/60 minutes) or for each rate period (for example peak and off-peak). The price for kWh of consumption, or kW/kWA demand is determined for every interval. This means the price may vary for every interval.

You can use RTP billing to calculate time-of-use pricing models and RTP models. You can define prices in advance or adjust prices to the spot price defined by the energy market.

Time-of-use pricing models are time-based. This means that prices are determined based on time groups.

RTP models are quantity-based. This means that prices are determined based on agreed reference quantities.

In the RTP billing, an important aspect is data storage which is done through profile management. Unlike standard billing where the meter readings are done once in a month/2 months or quarter, in RTP billing the consumption values are updated every 15/30 or 60 minutes. So we need to store and maintain this data differently, for which sap has provided profiles management.
Let's start by creating profile type.

After creating profile type, we need to set up interval length. We can assign more than one interval length to the profile type.

For profile type 89 that we created, we have assigned 15, 30 and 60 minutes intervals.

Next step is to create profile version. This is important because after creating profiles and adding values to it, if any change has been made, then historical values are stored as versions. For example we have got 60 minutes interval values for consumption as 5 KWH. Now if the data has been corrected for an interval as 7 KWH, there is a version created automatically, enabling us to know which values were created from original which values.

And that's why we select "always create" option so the system would always create a version whenever there is change made to the values.

Using transaction eedm06, we now create profile header. As per below, profile 171 has been created.

Once the values for 60 minutes intervals are downloaded, the profile looks like this. We have selected this profile for 30 days period which means that for 30 days, every 60 minutes data is stored in this profile.

Now let's change a couple of values manually and see if profile versions are created. In this case, we changed values for 2 intervals. These values 10 and 15 are highlighted when we select version from the top menu.

This completes the data storage process using profiles.

Next let's look at how complex billing is performed.

In regular billing, we maintain certain values at the device (registers) and devices are attached to the installation and thus those values are used for billing. But for RTP billing, that is not possible because we have to maintain values in profiles. That's why RTP interface has been created.

The RTP interface is a data object that links the Energy Data Management (IS-U-EDM) and Contract Billing (IS-U-BI) components.

The RTP interface enables us to use the profiles maintained in IS-U-EDM in IS-U billing. In order to this, we allocate the RTP interface to the rate used for billing an interval meter.

In the RTP interface we can execute billing-relevant processing steps carried out based on profiles. For example, we can process billing agreements for periods as small as 15/30/60 minutes. The results from such processing steps are then transferred to the rate steps in the rate. Billing lines can then be created from the rate steps.

So in order to bill based on time intervals, let's start setting up day group and day type.

And now let's set up TOU(Time of USE) types and groups.

And created On Peak, Mid Peak and Off peak TOU types.

And defined time period for each of them. For example, on peak time is set as 8 am to 6 pm.

Next, let's create TOU group and assign all 3 TOU types that we created earlier to this group.

Next step is to define RTP component.

And assign TOU group that we created to this RTP component.

And activate this component by clicking the "generate component code" icon in the top menu.

Next step is to define RTP interface.

Now we need to update information on all 3 tabs showing on the top menu. Below is the details we need to update on HDR tab.

Now the result parameter tab.

And on the RTP component tab

And once RTP interface is defined, then enter it while creating rate using transaction EA30

Travis Thomson page

The contents on this page has been contributed by my colleague and dear friend Travis Thomson, based on his experience in working with SAP ISU billing situations. Thank you Travis!

Things that we need to check when there is CMO (Change meter order) on the account

When there is a CMO, a 21 install in read MUST be the NEXT DAY in SAP after the 22 removal out read. If the device removal is June 4th in SAP, then the new install must be June 5th in SAP. An exception around this is if the 22 out read also happens to be an 03 move out. If it is an 03 move out, then the 21 install more than 1 day later is acceptable provided it is also an 06 move in.

In the case where there is a 22 removal, and 21 install with a gap of more than 1 day (in most cases I have seen it be just a couple weeks or couple months) it must first be determined whether or not the service should continue in that customer's name. Once determined, there are two routes:

A.) Have the CMO removed completely from SAP and re-entered with the correct dates according to field and account notes

B.) If the agent has clearance to do so, simply make the CMO 22 date a move out, ending that contract for the customer and make the CMO 21 a move in, which will start a new contract for that customer. This can be done in the IC Web "front end" (CRM)in the end contracts and moves/transfer screens, and is very straight forward. Make a special note to waive the start up fee if going this route, as the customer will be charged incorrectly since it is technically not a brand new service, just a new contract number. This is the faster route which is likely more suitable for urgent escalations that require immediate resolution. I personally have not ever seen this error occur without a CMO being involved.

While processing customer accounts for TOU billing, we regularly send BQ requests to obtain valid and billable readings. Some of the scenarios that may not allow BQ requests to go through successfully are listed below.

Things to we need to check if BQ requests fail

For sent BQ requests that do not show in a BQ table there are several unique variables that come into play and in my experience, 99% of the time have to do with make up of the MROs. I will list all the common examples I have encountered to the best of my memory that causes this problem.

A.) BQ for a CMO (22) will not send -- This is because the CMO 22 is not a move out, or there are no periodic MROs listed after it. If the CMO 22 is a service termination, creating a periodic MRO after it will allow BQ to send, but will not fulfill it properly. In this case, a move out date must be applied to the CMO 22 date and then send BQ (end the contract on the same date as meter removal date). It should fulfill fine, if not data repair is needed, which is a separate issue.

B.) There are multiple MROs (multiple allocations) for one period. For example 09, 11, 16, 13, 18, etc, and 01 exists for a scheduled MR date. -- This is because in addition to periodic billing period MRO, any other allocation is there, BQ will not request and if it does, there is no status or response. It must be determined which MRO is required in importance and the other should be removed using EL37, or nullified in EL29 or EL28.

C.) There are multiple move outs and move ins on the same installation. SAP will request BQ for the newer periods, but not some of the older ones -- In this case, when requesting the BQ, change your latest date to the last date that is not sending. For example, if you are requesting from January 1st 2014 to January 1st 2015, but BQ is only sending from April 1st 2014 and skipping the earlier months, simply make your latest date April 1st when sending BQR (using transaction ZBQR) and it should send.

D.) All the dates for the MROs are there and OK, with no duplicates or visible anomalies but it still won't send -- It is very likely that this is some kind of deeper defect or there are billing/invoicing documents you have not accounted for which are blocking the BQR. In cases like this, you have not actually created the MROs, only checked them and tried to send a BQR. Reverse the documents and try again.

If it is not the documents, it may be the device install which is prompted by a clarification case typically asking for some price change MROs missing. (normally 30-04-2012)

If it is not the clarification case, it may still have to do with devices. If your CMO dates are incorrect, it will cause an error in requesting. The table may request only some dates and not others, so if there are multiple CMOs on the installation (and some a even very close together) make sure to check the 21 in and 22 out dates. You cannot have a 22 out after a 21 in unless it is 2 days later in SAP. For example, if there is a 22 meter out on May 1st, and new meter installed 21 is on May 2nd, the next plausible date for a 22 meter out has to be May 4th or later.

To summarize, when BQ request does not go through, it is mostly due to very general and very variable MRO situations where something is missing, there are two many of something, a date was requested too early (before earliest device) or too late (in the future and we haven't got there yet like requesting May 2015)

SAP ISU Billing

Below  are some important basic terminology for SAP ISU Billing and it needs to be configured first.

Billing schema
Rate
Facts
Rate  facts group
Price key
Operand
Rate category
Rate  type
Rate determination
Master data creation (BMD + TMD )

Business master data.
1) Business partner: A person or legal entity with whom the organization has business relationship. It can be a customer, a vendor, an employee. 
Transaction code: FPP1

2) Contract Account: Customer's account that has information about billing method, payment method,collection method and more.
Transaction code: CAA1

3) Contract: It is an agreement between business partner and the utility company.
Transaction code: ES30 (Contract is automatically created when customer is moved in to a premise)

Technical Master data:
1) Connection Object: It's a building, piece of property or other facility that is connected to the supply grid.
Transaction code: ES55

2) Premise: It is an enclosed spatial unit that is supplied with energy such as an apartment or a factory.
Transaction code: ES60

3) Device location: It provides the physical location of device (meter)
Transaction code: ES65

4) Installation: It stores billing properties for one or more devices at the premise.
Transaction code: ES30

Billing configuration:
1) Billing schema: Structure that defines the order in which variant programs for rates to be billed must be executed.
Transaction code: EA35

2) Billing class: It classifies installation for billing (example: residential, non-residential, non metered etc). Change in billing class also requires change in rate category. Final billing is not necessary upon changes. It can be valid for several rate categories. It serves the purpose of validation and statistical criterion. It controls the determination of the MRU in in the regional structure.

3) Variant program: It is a functional module in rates or schemas that contains a billing rule.
For example, one of the billing rule is consumption quantity(KWH)Xprice ($)= Total charge amount ($) is accomplished by variant program QUANTI01

4) Rate: It stores billing rules which are executed during billing run. It consists of steps and values of how to calculate billing quantity and amount. Each step is executed with variant program. Values of input and output parameters of rate steps (quantity, price, factor, amount etc) are determined historically at run time.

5) Facts: They are concrete values (such as 100 KW) or keys (for prices etc) that are allocated to operands and are valid for a specific period. According to the level on which facts are allocated, they can refer to installation facts, rate category facts or rate facts.
Installation facts have precedence over rate category facts and rate category facts have precedence over rate facts.


6) Rate fact group: Grouping of individual facts that are allocated to a rate. Several rate fact groups can be allocated to one rate. Rate fact groups enable you to use the same rate

but apply different operand values.

Example: Different prices for Victoria North & Victoria South for SOLARIS & UNITED respectively

7) Price key:

8) Operand: Individually determined symbolic name for the assigned values that are used as input/output parameters in variant programs. One or more operands are allocated to an operand category.

Transaction code: EA50

9) Rate Category: It is classification of an installation for billing purposes. It contains one valid billing schema. It determines which outsorting billing checks occur during billing. In conjunction with rate type, it determines rates to be applied during rate determination process.

Transaction code: EA53

10) Rate type: It is classification of register, flat rate or reference value for billing purposes. Rate type is commonly allocated to register to classify the register type such as on peak, off peak, mid peak etc. It could also be allocated to device or installation level for use as a classification of flat rate or be a classification of reference value. In conjunction with rate category, it determines rates to be applied during rate determination.

11) Rate determination: In conjunction with rate category, rate type is used to determine the rate.

Transaction code: EA87