Vous êtes sur la page 1sur 172

SAP Functions in Detail

mySAP Utilities

mySAP
UTILITIES

Copyright 2002 SAP AG. 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 AG. The information contained herein may be changed
without prior notice.

Some software products marketed by SAP AG and its


distributors contain proprietary software components of
other software vendors.

Citrix, the Citrix logo, ICA, Program Neighborhood,


MetaFrame, WinFrame, VideoFrame, MultiWin and other
Citrix product names referenced herein are trademarks of
Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered
trademarks of W3C, World Wide Web Consortium,
Massachusetts Institute of Technology.
JAVA is a registered trademark of Sun Microsystems, Inc.

Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and


SQL Server are registered trademarks of Microsoft
Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex,
MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,
WebSphere, Netfinity, Tivoli, Informix and Informix
Dynamic ServerTM are trademarks of IBM Corporation in
USA and/or other countries.
ORACLE is a registered trademark of ORACLE Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks
of the Open Group.

JAVASCRIPT is a registered trademark of Sun Microsystems,


Inc., used under license for technology invented and
implemented by Netscape.
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business
Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE,
Management Cockpit, mySAP, mySAP.com, and other SAP
products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of
SAP AG in Germany and in several other countries all over
the world. MarketSet and Enterprise Buyer are jointly owned
trademarks of SAP AG and Commerce One. All other product
and service names mentioned are the trademarks of their
respective companies.

CONTENTS
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilities Market Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Challenges Facing Utility Companies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Improving Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Replacing Customer Contracts with New Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clearing Services and Exchanging Data with Other Utility Companies . . . . . . . . . . . . . . . . . . . .
Supporting New Billing Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Predicting Customers Consumption Patterns with Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Information Technology To Provide On-The-Spot Customer Services . . . . . . . . . . . . . . .
Implementing New Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing Markets and Strengthening Marketing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13
13
15
15
15
16
16
16
16
16
16

What Must a Customer Information System Do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


mySAP Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Basic Functions and Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Postal Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Political Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Company Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enterprise Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Portioning and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20
20
20
20
21
21
21
22
23

Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Business Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contract Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utility Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Premise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utility Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Point of Delivery (POD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24
25
26
26
28
29
29
30
30
32

mySAP Customer Relationship Management for the Utilities Industry. . . . . . . . . . . . . .


Functional Scope of mySAP CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Supporting the Customer Relationship Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronization of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interaction Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33
33
33
34
37
37

Integration of mySAP CRM in mySAP Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


System Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronization of Data Between mySAP CRM and mySAP Utilities . . . . . . . . . . . . . . . . . . . . .
Master Data Generator Automatic Creation of and Changes to Master Data . . . . . . . . . . . . .
All Data at a Glance: The Cross-System Customer Fact Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrated Scenarios from mySAP CRM, mySAP Utilities, and SAP BW . . . . . . . . . . . . . . . . . . .
From Potential Non-Residential Customer to Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
From Potential Chain/Outline Contract Customer to Enrollment . . . . . . . . . . . . . . . . . . . . . . .
From Phone Call to Changes in Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical Front Office Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Move-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Move-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Business Partner Move-In/Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Bank Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Budget Billing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Installment Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bill Reprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40
40
42
43
44
44
45
46
46
46
47
47
48
48
48
48
49

SAP Business Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Bill Complaint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lay a Service Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disconnection/Reconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49
49
50
50

Internet Self-Service Including Automatic Changes in mySAP Utilities . . . . . . . . . . . . . . . . . . . . . 50


Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Energy Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Device Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Technical Device Data and Connection Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51
51
52
52
53
55

Meter Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Street Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Meter Reading Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Energy Data Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Meter Reading Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Load Shapes and Load Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Import of Profile Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Replacement Value Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Profile Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Analysis and Data Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Version Creation and Revision Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Preparation in the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59
60
61
62
62
62
65
66
66
66
66

Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Settlement Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptability and Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documenting and Logging Settlement Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exception Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Settlement Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Settlement Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taking Grids into Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schedule Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67
68
68
68
68
69
69
69
69
69
70

Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Contract Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Billing Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backbilling and Period-End Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Period Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Real-Time Pricing Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71
72
72
73
74

Billing Divisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Electricity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Water and Waste Water . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
District Heating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Divisions (Cable Television, Radio, Multimedia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77
77
77
78
78
78

Special Billing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Multiple Contract Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lighting Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Small Power Producers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78
78
79
79

Billing Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rate Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Discounts and Surcharges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79
79
81
81
81
81

Extrapolation/Statistical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sales Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unbilled Revenue Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consumption Statistics (for Customer Relationship Management) . . . . . . . . . . . . . . . . . . . . . .

81
81
82
82
82

Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Outsorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backlog Reduction Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parallel Processing and Monitoring Mass Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lock Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manual Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82
82
83
83
83
83
84

Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Invoicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bill Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85
86
86
88

Billing Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bill Printout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Outsorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Budget Billing Amounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Budget Billing Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Special Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89
90
90
90
91
92

Collective Bill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Contract Accounts Receivable and Payable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Account Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Business Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enhancement Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workflow Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95
95
95
96
96
96
96
98
98

Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Postings and Reversals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Payments Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Automatic Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Payment Lots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Cash Desk and Cash Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Check Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Control Clearing of an Open Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Returns Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Clarification Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Deferral and Installment Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Dunning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Interest Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Securities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Transfer Open Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Collective Bill Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Third-Party Billing in the Deregulated Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Write-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Correspondence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Statutory Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Reconcile Contract Accounts Receivable and Payable with the General Ledger . . . . . . . . . . . . 109
Closing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Account Balance Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Business Partner Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Integration with Additional Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112


Integration with Cash Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Integration of Consumption and Service Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Integration with mySAP Customer Relationship Management . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Integration with Credit Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Integration with Dispute Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Integration with FSCM Biller Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Integration with SAP Business Information Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Solution Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Intercompany Data Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Administration of Deregulation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Point of Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Supply Scenario for a Point of Delivery and Process Control
in a Deregulated Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Supplier as Billing Agent and Rate Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
The Distributor as Billing Agent and Bill Ready . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
The Supplier as Sole Provider (All-Inclusive Contracts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Dual Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Processing Data Exchange Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Data Exchange Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Data Exchange Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Communication Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Business Processes with Data Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Asset and Work Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122


Technical and Business Views of an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Preventative Maintenance and Malfunction Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Work Clearance Management and Safety at Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Customer-Oriented Service Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Technical and Visual Integration of Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A Detailed Look at Utilities-Specific Functions in Asset and Work Management . . . . . . . . . . . . . . 125
Description of the Technical Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Service Products and Service Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Service Objects in Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Multilevel Service Objects and Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
The Integration of Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
mySAP Business Intelligence for the Utilities Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Analysis of Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
An Example of a Marketing Campaign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
An Example of Change of Supplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Stock Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Transaction Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Sales Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Consumption Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Unbilled Revenue Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Individual Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Unbilled Revenue Reporting with mySAP BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

10

Analyses of Contract Accounts Receivable and Payable (FI-CA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 143


Analytical Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
mySAP Enterprise Portal for the Utilities Industry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Business Packages and iViews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Portal User Business Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Employee Self-Services Business Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Manager Self-Services Business Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Key Account Management Utilities Business Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Business Package Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Industry Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Deregulation Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Open System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
A Secure Investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Global Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Fast Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Visit our Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

11

12

INTRODUCTION
This SAP Functions in Detail provides a useful foundation for
understanding the scope of capabilities and functions available
with mySAP Utilities. This document describes how mySAP
Utilities supports utility companies. It covers, in detail, information related to data structures and exchange, customer
relationship management, energy data management, business
intelligence, work and asset management, enterprise portals,
and more.

readings, and so on. To exchange information, the customer


information systems of the various companies must communicate with each other, often through an industry-specific,
virtual marketplace. For example, this type of collaboration
is used to manage notifications sent by a distributor regarding
customers that have switched to another supplier. Another
example might be transferring meter-reading results from
the distributor to the supplier, or to another service provider,
so that a consolidated bill for the customer can be created.

UTILITIES MARKET OVERVIEW

The unbundling of utility companies in the deregulated market has changed the relationship between utility companies
and their customers. Whereas in regulated markets, a one-toone relationship with a local utility is the rule, customers in
deregulated markets deal with several types of utility companies. Customers have contracts for provisioning services with
energy suppliers (suppliers for short) and agreements often
contracts with a local distributor. Since deregulated customers are free to switch suppliers, the number of contractual
relationships increases over the course of time. Commercial
and industrial customers are free to simultaneously draw energy from several suppliers. Moreover, several models for market
deregulation create new relationships by assigning meter and
meter reading services to a yet another type of utility company the meter operator.
To coordinate, manage, and bill their services, this assortment
of utility companies must exchange data intensively. This information relates to the customers, contract contents, billing and
payment transactions, and locations. Information is also needed regarding technologies pertaining to energy supply, meter

Naturally, the huge number of transactions that are received


by customer information systems must be processed as quickly
as possible without any manual intervention a requirement
that until now could not be met by many systems.
Just as challenging, is the fact that the utilities industry has no
common definition of market deregulation. In every country,
the term has a different meaning. This results from differences
in the infrastructure of each countrys utility system, the property relationships in the local utilities industry, government
contracts, or the local population. The following examples
show how differently utility markets can be deregulated, as
well as what consequences deregulation can have for customer
information systems.
The deregulation models of the different countries have these
two features in common. First, the distributor is responsible
for operating the grid as far as the service connection. Second,
only the supplier is able to conclude competitive contracts
with customers for supplying energy.

13

In practice, all kinds of permutations arise between these


two facts. Responsibility for the meters and the meter reading
service can be assumed by the distributor or an (independent)
meter operator or even by the supplier. Either the supplier
or customers themselves may own the metering technology,
which, however, is installed, removed, maintained, and read
by the distributor or meter operator. It is also conceivable that
the distributor (or meter operator) assumes responsibility for
the metering technology and meter reading, but the customer
has to apply for the meter and meter reading service through
the supplier. The distributor then passes the application onto
the corresponding distributor or meter operator.

agree on a uniform standard for a unique premise ID. Since


practically every country interprets the term premise ID
differently, the customer information system must be able to
handle every conceivable form of premise ID (for example,
the German point of delivery).

A large number of deregulation scenarios require that the


distributor provide energy to customers that have not (yet)
decided to switch to a specialized supplier. Other procedures
necessitate transferring all the energy contracts to a supplier
in the same corporate group on a certain key date, to ensure
the strict neutrality of the distributor. This procedure requires
that communication processes with the related supplier be
managed in exactly the same way as with every other supplier.

For example, in the case of a dual contract model, the customer, in addition to their existing grid usage contract, concludes a second contract for getting energy through the supplier. In the case of the single contract model, the customers
contract with the distributor is cancelled and only the new
energy supply contract with the supplier remains.

Consequently, the customer information system must provide


flexible definition types of companies (distributor, meter operator, supplier) and processes (for example, managing metering
technology, meter reading, sales, contract billing, work management for meters and connections). This is because company
and process types are not defined as productive data until the
system is configured.
Unbundling, and the associated splitting of customer relationships between distributors and suppliers, means it is essential to
define the premise in a new way. The number of the consumption meter, which was used prior to unbundling, is no longer
suitable since, in a distribution grid with a multitude of distributors, this number is neither meaningful nor unique to one
premise. The utilities industry has thus far been unable to

14

The customer is essentially free to decide how and whether


to use the free market in energy sales. The procedure behind
choosing a supplier is one of the most discussed issues among
local deregulation authorities. Depending on the deregulation
rule used in a given country, a customer may conclude several
contracts with their utility company.

Deregulation rules in the various countries differ greatly on


the subject of enrollment. For example, who informs whom
about enrollments and the requirements that have to be met
before a customer and supplier can do business. There are substantial differences over enrollment and meter reading deadlines, as well as the treatment of customers in arrears, irregular
enrollment, or the transfer of data from distributors to suppliers.
Deregulation requires utility companies to develop a completely new form of service mentality, in which the customer
is the center of attention. Furthermore, utility companies
must optimize their energy sources and external services to
stay profitable. These realities make effective customer and
cost management a core requirement for an integrated IT
system landscape.

Keeping costs to a minimum is more imperative then ever.


Consequently, first class IT support can make a fundamental
contribution to achieving this goal. Deregulation also means
that the utility companies customer information systems
must be able to do more than billing and must meet the new,
key goal of customer satisfaction.
Customer satisfaction is highly dependent on having timely
and accurate customer-related information available. This
information is also needed by managers to successfully run a
competitive enterprise. Integrating the customer information
system with call centers, outage analysis systems, work order
management systems, automatic meter reading, and other
information systems helps utility companies maintain good
relationships with their customers. The customer information
system enables the utility company to monitor the status of its
customers and provide immediate solutions to customer problems. It helps the utility look after and analyze its most important source of revenue its customers.
To secure a competitive advantage in the deregulated market,
utility companies require extensive information, especially
about billing. The majority of billing solutions cannot fulfill
this requirement. Billing information can often be only partially displayed, and frequently causes technical problems
(for example, when interfacing with a customer relationship
management (CRM) system).
A modern IT system must be able to support the enormous
volume of transactions that take place in the deregulated utilities market. These transactions accrue when customers switch
to other providers when energy is traded, or when managing
a rapidly growing number of providers.
Enterprise resource planning (ERP) is a technology that meets
these varied requirements. Deregulation forces companies to
make the best possible use of their operational information,
while simultaneously cutting costs to a minimum. ERP soft-

ware provides a variety of business applications in an integrated


software package. For utility companies, this means replacing
single sources of information in the back office with an overall
software solution. The benefits are obvious. Legacy systems
no longer have to be maintained. Company data is more easily
accessible. The capacity of ERP and e-business solutions to
summarize and present information from various different
business divisions means that it is ideal for facilitating strategic
decisions. These advantages have convinced a large number of
utility companies to implement e-business solutions.
THE CHALLENGES FACING UTILITY COMPANIES

In the same way as other markets, utility companies have to


face up to globalization and increased competition. To survive
these challenges, utility companies must overcome their own
internal weaknesses, including the cumbersome structures and
organizations that grew over decades of regulated markets. The
key to adapting to these changes is flexibility. In this new environment, the survival of a utility company depends on:
Improving Customer Service
High-quality customer service is the key to a utilitys success.
Customer satisfaction determines the demand for a utilitys
services, shapes the customers view of the utility, and influences customer retention.
Replacing Customer Contracts with New Contracts
Deregulation has changed utility and service contracts. Customers now not only choose between different providers but
also between various rates, service levels, and types of contract.
Flexibility is therefore required when it comes to the content
of contracts. Moreover, utilities can offer new services alongside their traditional ones in the form of products, such as
electricity supplied at a cheap on- and off-peak double rate
when purchased together with a night storage heater (including installation by the utility).

15

Clearing Services and Exchanging Data with Other


Utility Companies
If a customer has contracts with more than one utility, these
companies have to exchange data relating to contracts, meter
readings, billing results, or move in/outs.
Supporting New Billing Scenarios
In addition to merely billing customers for one or more
supply sectors, the deregulated market allows for other
scenarios:
In unbundled billing, a company issues one bill for the basic
services that comprise a single sector provided by
various companies.
In convergent billing, a company issues one bill for utility
services as well as any other service from other companies
for example that comprise one sector.
Customers tend to prefer companies that offer an integrated
service. For example, in addition to its own services, the company manages administrative matters and billing issues on
behalf of other companies.
Predicting Customers Consumption Patterns with
Accuracy
A precise forecast of customers consumption patterns is an
important factor for a utility company competing in the deregulated energy market. Forecasting allows for balanced energy
procurement and minimizes price risks in the energy spot
market (also called energy exchange). For this reason, utility
companies agree on consumption profiles with customers, or
implement new metering technologies that make time-slicecontrolled measurements. When used in combination with
automated meter reading systems, new metering technologies
aid consumption forecasts and enable the creation of new rate
models. The customer information system manages consumption profiles and makes consumption forecasts.

16

Using Information Technology to Provide On-the-Spot


Customer Service
This form of support enables utility companies to both improve their productivity and raise their level of responsiveness
and the quality in customer service. It is vital to integrate utility services and on-the-spot services in common systems. To
achieve this, the customer information system must be integrated with the service management system (that maintains
existing installations) and the work management system (that
carries out work that is pending).
Implementing New Technology
New technology enables you to communicate better with customers through front-office functions, call center systems, or
the Internet, as well as interact with customers installations
through new metering, meter reading technology, and the
latest measurement devices.
Analyzing Markets and Strengthening Marketing
Activities
Marketing and marketing analyses are essential for gaining
new customers and retaining existing ones. To this end, the
customer information system must offer marketing and sales
functions.
WHAT MUST A CUSTOMER INFORMATION SYSTEM DO?

The new challenges of the deregulated market have immediate


consequences for the management of information in utility
companies. Above all, the greater importance of customer
information, customer service, and billing makes increased
demands on the customer information system.
A customer information system must:
Meet the requirements of market deregulation
Orient itself towards the customer
Be extremely flexible
Raise productivity
Successfully manage massive amounts of data

mySAP UTILITIES
mySAP Utilities is an industry solution developed to meet
the requirements of gas, water, and electricity companies of
all sizes. mySAP Utilities is based on the functions of the
mySAP.com e-business platform.
E-business solutions are frequently stand-alone, Web-based
applications that access information from a limited number
of data sources. All too often, these solutions lack interfaces
to the other information sources within your company.
Only an integrated e-business platform that links front- and
back-end systems can take full advantage of the potential of
e-business. mySAP.com fulfils these requirements.
In general, e-business embraces all activities from internal
to collaborative processes that involve external partners.
mySAP.com components, such as SAP R/3, offers functions
for internal processes and since its launch has proven its competence repeatedly. In a rapidly growing business environment
however, companies must implement end-to-end processes
using heterogeneous system landscapes.
mySAP.com enables you to accept these challenges and pursue
new strategies. Together with other SAP software components, such as mySAP Customer Relationship Management
(mySAP CRM), mySAP Business Intelligence with SAP Business Information Warehouse (SAP BW), or SAP Advanced
Planner & Optimizer (SAP APO), SAP R/3 is the technical
foundation of the mySAP.com e-business platform. With the
aid of this platform, you can build and manage end-to-end
business processes.

The development of SAP R/3 and other software components


evolving to mySAP.com reflects the wide-reaching adaptability
and flexibility of mySAP.com technology. When combined with
the power of the Internet, mySAP.com enables you to model
collaborative business processes. All this makes mySAP.com a
complete e-business platform.
Customers may wish to implement mySAP.com at their
own speed, or may initially only require part of an integrated
solution. Therefore, the component-based architecture of
mySAP.com offers the flexibility that companies need to implement solutions based on their internal structure and individual requirements, while retaining the option of seamlessly
integrating additional solutions in their existing IT landscape
later.
The mySAP.com e-business platform consists of the following
three key functional areas:
Cross-industry solutions
These solutions cover all the requirements of the respective
business area and, with the help of e-business solutions, give
companies a competitive edge.
Industry solutions
These solutions provide special functions that are oriented
towards the requirements of a specific industry or branch of
industry.

17

Discrete
Industries

Process
Industries

Consumer
Industries

Service
Industries

Financial
Services

Public
Services

mySAP CRM
mySAP Financials
mySAP E-Procurement
SOLUTIONS

mySAP SCM
mySAP PLM
mySAP BI
mySAP HR

SAP
WP

SAP
APO
SAPKW

SAP
Mobile

SAP
BW
External

SAP
SEM
SAP
BC

SAP
...

...

TECHNICAL
COMPONENTS

SAP
IS-U
SAP
R/3

SAP
...
SAP
GUI

ILOG

mySAP.com solutions build on the combined functions of several technical components

Figure 1: mySAP.com Solutions

Infrastructure and services


Infrastructure and services support the cross-industry solutions and industry solutions with technology and services
and ensure that these solutions can be implemented quickly
and without problems.
The mySAP Utilities Industry Business Unit (IBU) has developed Internet-enabled, fully integrated applications for managing customer relationships, employees, installations,

18

maintenance, work order processes, financial issues, procurement, and marketplaces. These applications are delivered in an
open, cross-company, personalized IT landscape.
The key functional areas of mySAP Utilities are:
Energy data management
Contract billing
Invoicing
Contract accounts receivable and payable
Intercompany data exchange

mySAP E&C

Billing and Contract Accounting


Manage millions of customer accounts
Third-party and intercompany billing
Electronic bill presentation and payment
mySAP High Tech

mySAP Automotive

mySAP Utilities

Cross-Industry
Solutions

mySAP Aerospace & Defense

mySAP UTILITIES

mySAP Enterprise Portal

mySAP CRM for Utilities


Operate your call center efficiently for improved customer satisfaction
Manage all B2B relations professionally

mySAP Business Intelligence for Utilities


Monitor your utility with dedicated key performance indicators
Make strategic decisions based upon relevant information

mySAP CRM
mySAP SCM
mySAP BI
mySAP Marketplace

mySAP PLM (ASSET AND WORK MANAGEMENT)


Monitor your assets to ensure cost-efficient operation of all kinds of assets
and facilities
Ensure highest efficiency for your maintenance staff and proactive service for
your customers by best-in-class work management solution

mySAP SRM
mySAP PLM
mySAP HR
mySAP Financials

mySAP Enterprise Portal


Dedicated portal for key account managers
Role-based portals for employees, retailers, and customers

mySAP Mobile Business

Figure 2: mySAP Utilities

Asset and work management


Regulatory reporting for utilities Federal Energy
Regulatory Commission (FERC)
Note that this area meets the special demands of regulatory
reporting in the American utilities market. Its tools use
financial data from the database to report to the authorities
at the federal, state, and municipal level.

Certain cross-industry solutions that are especially relevant


for utility companies have been modified to meet the requirements of the utilities industry and, like all other mySAP.com
solutions, can be integrated in mySAP Utilities. These include:
mySAP Customer Relationship Management (mySAP CRM)
mySAP Business Intelligence (mySAP BI)
mySAP Enterprise Portal (mySAP EP)

19

BASIC FUNCTIONS AND MASTER DATA


an address. In Germany, the postal code can often be determined directly from the city name. Data relevant to billing can
be stored for each street. This might include air pressure areas,
calorific value districts, meter reading units, and grids. These
values are automatically proposed when creating utility installations to be billed. A CD containing the postal data of customers outside the service territory can be applied to the postal
regional structure if required.

BASIC FUNCTIONS

Postal Regional Structure


The postal regional structure, also called city file, divides a
service territory by postal criteria. This is essentially composed
of cities and streets with their street sections. City districts and
P.O. boxes can also be represented. You can store a postal code
for each object. If you have completely maintained the postal
regional structure, all the addresses of objects in mySAP Utilities refer to elements of the regional structure. The central file
for city and street names and the allocated postal codes ensure
that the addresses are correctly spelled and structured. This
takes place in the address management component in SAP R/3.
Algorithms that are specific to each country make it easy to
enter addresses. For example, in the Netherlands, you only
have to enter a postal code and house number to fully specify

Political Regional Structure


The political regional structure divides the supply territory by
political and administrative criteria. Unlike the postal regional
structure, you can define the political regional structure yourself. First, you define the hierarchy (for example state, county,
and city) and then you allocate the elements, meaning the

Political

Postal

Internal

State

City

Administrative
area

Street

Dsitrict office

Street
section

Branch office

Administrative
district

County

Municipality

District

Figure 3: Relationship Between the Different Regional Structures

20

corresponding political entities (for example, San Francisco


and Boston), to the hierarchy levels. The political regional structure is linked to the addresses of the connection objects via
the postal regional structure. A connection object is usually
a building, but it can also be a property or other entity. The
allocated elements of the political regional structure are stored
for cities and streets (or street sections).
Organizational Structure
To strategically plan the use of personnel resources and efficiently control and monitor business processes, the organizational structure of a utility company in SAP industry solution Utilities (IS-U) must be well known and quickly accessible.
mySAP Utilities uses the Basis component Organizational
Management in SAP R/3 to do so. The organizational plan
contains agent determination functions that enable each task
and business process to be automatically assigned to the
responsible individuals or teams. (Agent determination allocates the appropriate contact person to business partners and
automatically distributes the individual tasks of a workflow to
the agents.) The organizational plan can also be used to set up
access authorizations and bill employees. All company data
can be stored centrally in the organizational plan and then
evaluated in graphical or textual form. This data includes:
Employees, together with work center, telephone number,
address, and so on
Job descriptions, positions, and the actual people who
hold the position
Organization in groups, departments, areas and so on,
including the hierarchy
Tasks and responsibilities
Vacations and substitute employee information

Company Regional Structure


In the company regional structure, the units of the utility
company as defined in the organizational structure (such as
administrative areas and district offices) are linked to the postal
regional structure. This facilitates agent determination at a
regional level, which provides optimum support for companies
with decentralized structures. You can also manage statistics
based on an internal division of the service territory.
Enterprise Structure
SAP R/3 provides several organizational units that you can use
to model your enterprise structure:
The client (usually a group or organization) forms the highest level of this hierarchy. In commercial, organizational,
and technical terms, the client is a self-contained unit with
separate master records and its own set of tables. The client
largely serves only one technical function; it enables you to
use several logically independent systems within one physical
SAP installation.
The company code (for example, a company) is the smallest
organizational unit for which a complete self-contained set
of accounts can be drawn up for external reporting purposes.
At least one company code must be set up for each client. As
a rule, a company code corresponds to one legally independent company.
The business area is an organizational unit in financial
accounting that represents a separate area of operations or
responsibilities within an organization and to which you
can allocate value changes recorded in Financial Accounting.
Plants (such as branches) structure the company according
to production, procurement, maintenance, and planning.
Sales organizations structure the company according to sales
requirements.
Profit centers structure the company for controlling purposes.

21

Role

Responsibilities

Task

Belongs to an object or process


(for example, device installation)
Shipped by SAP

Requires parameters
(for example, division or region)
Uses these parameters to
determine the responsibilities

Organizational structure with:


Organizational units
Positions
Users

Agents
or
agent groups

Figure 4: Agent Determination

Agent Determination
Agent determination allocates the appropriate contact person
to business partners (concerning a bill, for example) and automatically distributes the individual tasks of a workflow to the
agents responsible. This ensures a task is always sent to the
electronic inbox of the correct agent no matter what medium
is used (letter, workflow, telephone, and so on). Agent determination is based on the organizational structure of the utility
company (for example, organizational unit and position), each
agent being an element of that structure. Tasks are distributed
based on organizational units (such as the department or substitute employees), the attributes of the task (such as the division or regional allocation) and the data object. In many cases,
the data object is a business partner, but can also be a bill or
utility installation. As such, agents can be determined according to criteria including the following:
Company code
Division
Billing class (classification of contracts in a division,
for example, residential or nonresidential contracts)
Regional criteria (for objects with an address)
First letter of the business partners last name

22

The utility company can define additional attributes for use


in agent determination and freely allocate its agents to these
criteria.
Example: The increased volume of tasks resulting from an
extension of its supply territory causes a utility company to
create a new position in its customer service department. The
agent responsible integrates the position in the companys
organizational plan and defines the tasks and responsibilities of
the new employee in the activity profile of the position. Since
the new employee is solely responsible for the extension of the
supply territory, their tasks are limited to that region. To configure this area of responsibility, you define a regional structure
group in the responsibilities of the new employee (or of the
job/position).

Portion A

Portion B

MR unit A.1
MR unit A.2

MR unit B.1
MR unit t B.2

MR unit A.3

MR unit B.3
MR unit B.4

MR unit B.5

Portion C
MR unit C.1
MR unit C.2
MR unit C.3

Figure 5: Division of a Service Territory into Portions and Meter Reading Units

Parameter
record

Permitted BB cycles
BB scheduling

Portion

Billing dates
Permissibility
(cycles, divisions, billing classes)

MR unit 1 1
Ableseeinheit
Ableseeinheit
22
Ableseeinheit
Ableseeinheit
3

Dates for meter reading and


MR order creation
MR forms
Special features (MDE,
permissibility, intervals, etc.)

BB scheduling via allocated


parameter record

Figure 6: Scheduling: Interaction of Portion, Parameter Record, and Meter Reading Unit

Portioning and Scheduling


The scheduling function generates periodic dates for meter
readings, billing, and budget billing. Scheduling master records
for meter reading (meter reading units) and billing (portions)
must be created to do so. Portions are groups of contracts that
are to be billed collectively. A contract is allocated to a contract
either directly in the contract or indirectly through the meter
reading units that are specified in the utility installation
belonging to the contract. Meter reading units group utility

installations together according to regional criteria. They


contain all the data relevant to meter reading scheduling.
To generate due dates for budget billing, you have to maintain not only the portion but also the parameter record. The
parameter record contains the data either for the planned
partial bill or for printing the budget billing amounts. A
parameter record can be used for more than one portion.

23

MASTER DATA

Master data is data in mySAP Utilities that remains unchanged


over an extended period. It is divided into business and technical master data. The business master data consists of:
Business partner
Contract account
Utility contracts

The technical master data consists of:


Connection object
Connection
Premise
Device location
Utility installation
Point of delivery (POD)

mySAP UTILITIES HOUSE

Connection object

Apartment 1 = premise

Contract 1:
electricity

Business
partner

Contract
account

Contract 2:
gas

Hall

Apartment 3

Device location:
corridor

Apartment 2

Utilityinstallation 1:
elect. meter

Utilityinstallation 2:
gas meter
Basement

Contract 3:
water

Service connection: water


Supply grid

Figure 7: The mySAP Utilities House

24

Utilityinstallation 3:
water meter

Service connection: gas

Device location:
basement

Service connection: electricity

Business Partner
In SAP R/3, a business partner can assume a number of roles
simultaneously. However, a business partners master data is
stored just once in a central master record. This reduces the
amount of maintenance required and prevents data inconsistency. mySAP Utilities uses the business partner in the following roles:
Contract partner who has a contract with a utility company
for delivery and purchase of utility services. A contract partner can be a residential customer, nonresidential customer,
other utility company, service provider, local authority,
property owner, or third party.
Prospect who is the target of marketing or sales activities.
(See also Chapter 3 mySAP Customer Relationship Management
for the Utilities Industry).
Contact
person for a contract partner of the utility company

Installer who is authorized by the utility company to install


devices and is issued a license to do so
General business partner that is stored for information
purposes only and is neither a contract partner of the utility
company nor a contact person or prospect
In mySAP Utilities, business partners are classified according to
the business partner categories natural person, group, and
organization. You can store different information depending
on the business partner category you choose. When you create
or change a business partner, you can create a customer from
the Sales and Distribution component. This customer can
make use of services and maintenance. You can link business
partners to one another using relationship categories. Examples
include linking an organization and contact person with the
contact person relationship category, or the marriage
and shared living arrangement relationship categories.

The master record of a business partner contains data from


the following areas:
Name
Personal data
Search terms that you can freely define
Address, including telephone and fax numbers
You can enter other addresses in addition to the standard
address. The address management component manages the
addresses centrally with a uniform structure. It determines
whether the addresses entered meet country-specific rules
and whether the cities and streets exist in the postal regional
structure. It also allocates the business partner to the political regional structure and to the company regional structure
where necessary.
Bank details
More than one set of bank details can be entered
(for example, one account for incoming payments and
one for outgoing payments).
General data (for example, credit rating and countryspecific data)
A standard customer is created in the Sales and Distribution
component for a contract partner or prospect in mySAP
Utilities. That customer can:
Make use of service and maintenance offers
Purchase goods
Pay fees and taxes
Be the target of marketing activities (see also Chapter 3,

mySAP Customer Relationship Management for the Utilities


Industry)

A predefined reference customer is used as a template


for the standard customer.

25

DUNNING AND PAYMENT DATA

GENERAL DATA

General data
Account description
Acct no. in legacy system
Payment conditions
Tolerance group

Dunning data
Dunning control
Dunning recipient
Dunning disconnect reason

Control
Alt. bill recipient
Payment via collective invoice account
Additional bill

Inbound payments
Payment method
Bank details
Alternative payer

Contract
account

Acct assignment data


Item line display
Planning group
Account determination

Outbound payments
Payment method
Bank details
Alternative payer

Figure 8: Contract Account

Contract Account
A contract account groups together all of a business partners
contracts to which the same payment and dunning data
applies. The following payment transaction data is stored in
the contract account:
Bank details
Dunning data
Payment data
Alternative payer, payee, bill recipient, and dunning recipient

26

Utility Contract
A contract is an agreement between the utility company and a
business partner relating to a utility service. It forms the basis
for billing the following contract categories:
Delivery contracts
You can finalize delivery contracts for electricity, gas, water,
waste water district heating, and cable TV, which are all divisions supported by mySAP Utilities. You can also use other
service-related divisions if mySAP Utilities can bill them. The
contracts may relate to the entire division or to basic services
for that division. Basic services might be energy supply,
transmission, distribution, meter reading, customer service,
billing, and so on.

GENERAL DATA

BILLING DATA

General contract data


Contract account
Division
Company code
Plant/company cons.
Statistic group
Authorization group

Budget billing data


BB amt adjustment
BB cycle

Billing data
Joint invoice
Billing block reason
Outsorting group

Contract

Deregulation fields

Acct assignment data


Account determination ID
Cost center
Business area

Scheduling data
Contract start/end date
Extension data
Cancellation data
MOVE-IN/MOVE-OUT

Figure 9: Utility Contract

Purchase contracts for small power producers, solar plants,


and other energy feeding
Plant consumption contracts for the utility companys
generation and distribution installations
Company consumption contracts (the utilitys own
consumption) for example, for electricity consumption
in the utility companys own offices

Service contracts (for maintenance and repairs, for example)


are not managed in mySAP Utilities, but by the Sales and
Distribution component in conjunction with the Service
Management component. Contract data contains the following control data for consumption billing and contract
accounts receivable and payable:
General data (such as contract account)
Move-in and move-out data
Contract validity data (such as start and cancellation dates)
Data relevant to billing
Account assignment data (such as the account
determination ID)
Sales and distribution data
Deregulation data (such as service provider)
Data relevant to budget billing

27

Address
Street
City
Country
Time zone
County code
Political regional structure
Additional details

Notes to
field service

Connection
object

Characteristics
Maintenance plant
Authorization group
Regional structure group

Figure 10: Connection Object

A utility contract is allocated to a single contract account. You


can allocate more than one contract to an account and then
bill those accounts collectively. However, only one utility
installation can be allocated to each contract. With the exception of move-in and move-out data, you can change, display,
and check all the data of multiple contracts in a contract
account (this applies to those contracts that have not been
cancelled). The move-in and move-out dates represent the
beginning and end of energy supply in the division specified
in the contract, or partial service in a division. If a particular
utility service ends, the customer with that service is identified
as moving out and the utility contract is classified as canceled.
Possible reasons for these events are as follows:
The customer is no longer interested in the utility service.
The customer changes suppliers.
Immediately following move-out, a new contract takes
effect with the new supplier (move-in). See also Chapter 8
Intercompany Data Exchange.
The customer moves out of the premise.
In this case, all the customers utility contracts are canceled
(as a move-out for all contracts).

28

Connection Object
A connection object is usually a building, but it can also be a
property or other entity (such as a fountain or a construction
site). Since a connection object is allocated an address, it links
premises, device locations, and connections with the postal
regional structure. The connection object is allocated to a supply territory. The connection object is based on the functional
location of the Plant Maintenance component. This means
you can use the functions of Service Management to organize
the installation, removal, and maintenance of devices. In addition to the general data of the functional location, the connection object contains industry-specific data.

Connection
A connection is the technical link between a utility grid and
the connection object. Since it is division-specific, several
connections for different divisions or several connections for
one division can be located in a single connection object. The
connection is a piece of equipment from the Plant Maintenance component and does not have any industry-specific
enhancements in mySAP Utilities.
Premise
A premise is an enclosed spatial unit (such as an apartment
or factory) to which a utility service is supplied. Several utility

installations can be allocated to one premise (for different divisions, for example). The premise is therefore not related to one
specific division. It is allocated to a connection object and contains the address of that connection object. In addition, you can
maintain additional data about the location of the premise (for
example, which floor). You can enter the owner of a premise,
who is responsible for paying outstanding bills if the premise is
empty. A deregulated scenario exists if more than one utility
installation of the same division is allocated to a premise. Since
utility services are being unbundled, more than one utility
contract for the same division is allocated to the same premise
using the unique allocation of the utility installation.

SUPPLY GRID
Connection
Equipment

Configurable
Connection info
Back-up fuse
Length
etc.

Connection object
Functional location

Service connection for gas


Service connection for water
Service connection for electricity

Figure 11: Connection

Location
Connection object
Street
House number
Floor
Room number
Location description

Premise

Characteristics
Premise type
Owner
Number of persons
Authorization group

Figure 12: Premise

29

Device Location
A device location is a place within a connection object where
devices are installed. These devices can belong to different
divisions. You can allocate both the address of the connection
object and a particular premise to the device location, and
you can enter a description to define the exact location of the
devices. This means that you can use the device location to
locate an installed device. The device location, like the connection object, is based on the functional location of the Plant
Maintenance component. This means that you can also use
Plant Maintenance functions in the device location.

Utility Installation
In mySAP Utilities, the connection between the premise,
devices, and contracts is referred to as a utility installation
(or installation for short). The installation contains data
relevant to billing contracts, for example the reference values
(see below). The installation is not a technical construct.
Several devices can be installed in a utility installation, with
a variety of different relationships existing between them. In
turn, the devices can comprise several registers, each allocated
to different rates. All the data regarding device allocations,
register relationships, and rate allocated is stored in the instal-

Note to
field service
Location
Connection object
Location
Additional location info
Premise

Figure 13: Device Location

30

Device location
General data
Description
Authorization group

lation structure (see Chapter 4 Energy Data Management).


At any given time, the installation is allocated to a single contract. If the contracts in a deregulated scenario contain only
partial services from a single division, an installation in the
same premise exists for each contract. An installation is only
not allocated to a contract in exceptional circumstances (for
example, installation under construction, installation vacant,
and not allocated to an owner). Scheduling determines the
meter reading dates for the installation. The meter reading
unit to which the installation is allocated governs these dates.
The meter reading unit also links the installation to the por-

tion in which the billing dates are defined. You can store rate
categories in the installation. When the contract is billed, the
rate category determines and bills the relevant rates. For more
detailed information, see Chapter 5 Billing. The data in the
installation that is relevant to billing is managed historically.
This means that you can switch rate categories during a billing
period. You usually store general agreements and price information in the rate or rate category; in exceptional cases, you
can store them in the installation facts (for example, individual
prices or reference values).

Point of delivery
(deregulation)

Division
Premise
Current contract
Current business partner

Individual
facts

Time-dependent data

Utility
installation

Billing and
meter reading control

Allocated devices

Deregulation fields

Additional information

Figure 14: Utility Installation

31

Point of Delivery (POD)


The point of delivery describes the point at which a utility
service for a customer is supplied or determined. A unique
number, called the point of delivery ID, can identify a point of
delivery. This ID is used to communicate with external systems
and other market operators. The fact that each point of delivery ID is unique means that misunderstandings can be avoided
and data correctly allocated when information about the services supplied to a POD is provided. This is also the case if a
customer switches utility companies. There are two communication types:
Communication in the deregulated energy market is
communication between different utility companies in the
deregulated energy market. This can include the exchange
of information between a distributor and a supplier.
Technical communication is communication with an
automated meter reading system. This type of communication is used to import profile values to the Energy Data
Management component.

When you define a point of delivery, you can choose between


the following point of delivery types:
Deregulation point of delivery
When you create an installation, a deregulation point of
delivery is automatically generated, to which you have the
option of allocating a point of delivery ID. You classify a
point of delivery as deregulation if you require it for communication purposes in the deregulated energy market.
Technical point of delivery
You classify a point of delivery as technical in the following
instances:
The point of delivery is required to communicate with
systems that do not work with the point of delivery ID
common to your energy market.
The point of delivery is required to communicate with
systems whose measurement systems do not conform to
market requirements (in which, for example, a device
measures more than one point of delivery).
Figure 15 shows how the point of delivery is integrated in the
mySAP Utilities data model.

Contract
= billable service

Nonbillable
service

Deregulation point of delivery


Installation

Point
of
delivery

Premise

Device

Connection object

Device location

Figure 15: Point of Delivery

32

Nonbillable
service

Technical point of delivery

Register

mySAP CUSTOMER RELATIONSHIP MANAGEMENT


FOR THE UTILITIES INDUSTRY
The Internet and other virtual communication portals enable
even the smallest companies to compete in global markets.
This trend, however, has also raised customers expectations,
especially regarding service. All-encompassing, round-the-clock
customer service and personalized products and services are
now taken for granted. If dissatisfied, a customer can switch to
the competition at the click of a mouse. Consequently, as a
utility company, you must work with a modern, comprehensive customer relationship management (CRM) system that
supports a variety of different contact channels. Customer
service is not a tiresome obligation; it is a strategic necessity. A
CRM solution must facilitate communication with your customers across all channels, including telephone, fax, e-mail,
Internet, hand-held device, and personal consultation. Seamless
integration with all front- and back-office applications, company business functions, and business partners is also essential.
mySAP Customer Relationship Management (mySAP CRM)
can be used to win new customers in highly competitive markets and retain existing customers. Increasingly, companies are
looking for integrated software that guarantees a universal,
smooth, and efficient process, starting with customer interaction through to service provision, customer service, billing,
payment request, and monitoring.

FUNCTIONAL SCOPE OF mySAP CRM

Philosophy
mySAP CRM is a cross-industry solution that can be integrated
with mySAP Utilities to provide optimal, cross-system sales
and marketing processes for all customer groups in the utilities
industry. These groups may include residential customers,
non-residential customers, chain customers, and outline contract customers.
A CRM solution must meet several basic requirements:
It must provide a platform from which each employee,
partner, and customer has access to the information and
functions required. This platform must be adjustable to
meet the requirements of all users (people-centric CRM).
You must be able to view and process customer-oriented
business processes in all systems. The integration of frontend, back-end, and analysis tools is especially important. This
has been achieved by integrating mySAP.com applications
and technologies, expertise, and content. This is the only
means of guaranteeing that all processes are continuously
monitored and can be used as the basis for strategic decisions
(connected CRM).
The software must optimize collaborations with partners
and/or suppliers (collaborative CRM).

Identical processes across all channels are required in both


front-end and back-end systems to ensure that data is consistent. This enables you to handle customer-related business
processes in the most effective and cost-efficient way possible.
The ability to evaluate and analyze these processes with regard
to quality and costs is also highly important. A data warehouse
system that can collect and analyze data from financials, billing, and communication from all integrated systems is essential here. Using a data warehouse system in conjunction with
the front-end, back-end, and financial systems enables you to
develop and assess a suitable strategy for your company. You
are able to continuously monitor costs, and thereby track the
success of your interactions with customers.

33

mySAP CRM focuses on the customer relationship cycle, from


customer acquisition, through sales and supply (or management of the agreed service), to customer service and retention.
mySAP CRM provides optimal support for these processes and
allows for a very high degree of transparency from strategic
planning to service provision and success monitoring. All
processes are of course compatible with all modern communication methods, such as interaction centers, the Internet, and
mobile applications including hand-held devices and laptops.
Supporting the Customer Relationship Cycle
The following is a brief explanation of the business scenarios
that mySAP CRM supports. These explanations do not necessarily refer to different components, but instead to various
views within the customer relationship cycle.
Market analyses and analyses of target groups are provided by
mySAP Business Intelligence and the SAP Business
Information Warehouse (SAP BW). Data from a variety of different systems (for example, master data, and transaction data
from mySAP Utilities) is available in SAP BW. This information
can be combined with other data (such as contribution
margins from mySAP Financials) as required, and subjected to
multilevel and multidimensional analyses. Data on prospects
can also be purchased from external sources, imported into
SAP BW, and analyzed. The analyzed data can then be viewed
in mySAP CRM (in the case of a target group, for example).
Marketing planning enables you to display hierarchies for
marketing plans and campaigns, and calculate their cost. You
can store planned and actual start and end dates for each
element of the marketing plan, and allocate them to the
employee responsible. For each campaign, you can enter costs
and revenues, enabling you to compare planned and actual
costs and revenues with your overall costs and revenues.

34

Campaign management enables you to plan and conduct


marketing campaigns on multiple levels. You can conduct
campaigns using a variety of channels, such as telephone or
fax, Internet, or supplements included in bills.
Telemarketing enables you to conduct outbound telephone
campaigns, which typically entails working through the telephone numbers of your target group members. Interactive
scripting functions provide support for call center employees.
mySAP CRM also supports preview and predictive dialing in
conjunction with computer telephony integration (CTI).
Internet marketing enables you to send e-mails to selected
business partners (as part of, or independently of, a marketing
campaign). Help is provided with a flexible form generator. If
you include links to your Web site or Web shop in e-mails, you
can also determine who has logged on. In addition, SAP BW
provides click-stream analyses, which you can use to analyze
the way in which customers or prospects navigate around your
Web shop, and what interests them.
Field service sales allow field service employees to download
all the information relating to their customers and prospects
onto a laptop. While working offline, they can enter activities
for their business partners, agreements, or opportunities, and
upload them to the online system later.
B2C Internet sales enable residential and commercial customers to classify themselves according to certain criteria (for
example, type of customer, annual consumption, region, and
preferred means of communication) while online. They then
obtain a personalized product proposal from mySAP CRM.
They can also order selected retail items and choose from a
variety of payment methods.

mySAP CRM Customer Relationship Cycle

EN
G

AN

CT
SA

LL
FI

TR

FU
L

Operation/Service
Service interaction center
Internet self-services
Service center
Field service
Monitoring and success checks

E
IC

Contact management
Market analysis
Marketing planning
Target group selection and campaign
management
Telemarketing
Internet marketing
Monitoring and success checks

E
AG

SE
RV

Customer retention
Complaints management
Service-level management
Customer retention management
Customer development management
Monitoring and success checks

Sales
Field service sales
Internet sales (B2C)
Internet sales (B2B)
Telesales
Sales management and support
Monitoring and success checks

Figure 16: The mySAP CRM Customer Relationship Cycle

B2B Internet sales grant interval customers and non-residential customers special access to your Web site. Special products,
services, prices, and conditions available in Internet sales can be
made available to non-residential customers via this Web site.
Telesales provides call center employees with access to all relevant data on customers and products (of which you can enter
pictures). When employees select a product, they can enter
information about that product. When a customer orders a
product, the employee can view the product availability, price,
and attached conditions. Furthermore, telesales supports cross-,
down-, and up-selling by enabling you to store rules that relate

to given products or business partners. For example, a customer wants to sign a gas contract. The system suggests that
the customer also buy a gas contract together with a maintenance contract (cross-contract). Cross-, down-, and up-selling
product proposals can be displayed in combination with an
interactive script. Employees can also display partner-related
products. This means you can store products that are only
permitted for certain business partners (for example, certain
regions cannot be supplied with gas). Broadcast messages display important information for call center employees while
they are talking to the customer, so that telephone conversations can continue uninterrupted.

35

Sales management and support enable you to monitor and


control the sales field service. In this way, you can use opportunity management functions for forecasting, and pipeline
analyses to obtain information on the success quotas of sales
employees, sales regions, and profits and losses.
The service interaction center is tailored to the needs of the
service department and contains functions for processing service inquiries and orders. When customers call with inquiries
or technical problems, call center employees can search a database for answers and solutions. The proposed solutions can
then be faxed or e-mailed to the customer. If these are not sufficient to resolve a technical problem, the call center employee
can create an order for a service technician.
Internet self-services enable customers to perform certain
tasks themselves (such as changing their personal data).
Customers can also access the solutions database from here.
The service center enables scheduling of service transactions
(for example, maintenance and repair jobs) by accessing the
appropriate service employees data (for example, their qualifications and schedules).
The field service capability of mySAP CRM is a mobile solution for service employees. They receive notice of pending service jobs via a laptop download. The service employee can then
view all the necessary information about the customer and see
what materials are required for the job (for example, meters
or cable). The service employee can confirm completion of the
service transactions while still on site, and order new materials
or carry out new jobs. After processing, the changes are
reloaded to the online system so that the confirmed information can be transferred to the back-office system for billing.

36

Complaints management is important for retaining existing


customers and preventing customer churn. In addition to
complaints entry, predefined workflows support complaint
processing. You can tailor these workflows to the specific
requirements of your company. A wide variety of evaluations
is available for targeted complaint monitoring.
To use the following three business scenarios (service level
management, customer development management, and
customer retention management), you must perform a net
present value analysis of your customer groups in SAP BW.
You can use service level management to offer special services to especially valuable customers (for example, swifter
response times during outages or a special interaction center
number).
Customer retention management enables you to conduct
loyalty programs. Here, customers can collect loyalty points
based on certain criteria, such as timely payment of bills, and
upon reaching a certain number of points, exchange them for
a bonus or gift.
Customer development management enables you to determine the cross- and up-selling potential of certain customer
groups. Products or services can then be offered to these
groups at preferential rates.

You can use SAP BW to analyze all the interactions that are
conducted using mySAP CRM. You can use different criteria
(for example, status, duration, costs) to analyze campaigns,
complaints, orders and contracts, opportunities, and activities
with regard to their success. mySAP CRM supports all forms of
interaction between your company and customers, prospects,
or partners. Since CRM solutions do not usually contain any
billing functions, they must be smoothly integrated with backend solutions without any loss of performance. This is the only
way of ensuring that the value-added chain flows across all systems, and that the data viewed is uniform and consistent. SAP
provides a standard integration scenario between mySAP CRM
and other SAP solutions. The information below describes the
integration with mySAP Utilities and the business processes
supported by this scenario.
Synchronization of Data
CRM middleware is part of mySAP CRM and supports the
following functions:
Synchronization of data on both sides of the integration
scenario (mySAP CRM and mySAP Utilities)
Synchronization of data between mobile clients and the
central CRM system, in both directions
Messaging between the client and server in which information about the CRM middleware is stored on a temporary
basis

Interaction Center
The interaction center (IC) is a special form of portal for call
center employees. The IC provides a complete, CTI-enabled
user interface.
The IC is a Basis component that can be configured to fulfill
the requirements of your company. As such, the IC is commonly known as the service interaction center, telesales, or
telemarketing, depending on the area of implementation. In
each case, the name refers to a specific modification of the IC,
each of which has different functions. To work efficiently in
the IC, you can arrange the components using three different
basic layouts (see Figures 17-18). You can also create IC profiles,
each of which contains different structures and modifications
that meet the requirements of different employees. Consequently, a call center employee can work with those profiles
and configurations that correspond to their tasks. This is especially important in mixed call centers, which require both sales
and service functions. For example, a call center employee can
be allocated an IC service profile and an IC sales profile that
can be called as required.

Configuration

Service
interaction
center

Configuration
Basis IC

Data that is required in both systems is instantly synchronized.


If one of the systems is not available at a given time, the data
is synchronized when that system is operational. In this way,
your work in the other system is not impaired.

Telesales

Configuration
Telemarketing

Configuration

SAP provides preconfigured middleware for synchronizing the


data required in both mySAP CRM and mySAP Utilities. The
CRM middleware performs an initial download of data into
the CRM system. This is a one-off event that takes place during system migration.

Figure 17: Configuration Options for the Interaction Center

37

The IC work center is divided into components that perform


different functions. Employees can therefore access all central
functions on a single screen. Agents have access to the following functions:
Telephony functions
Enable the agent to accept, transfer, and end calls
Telephone status
Automatically identifies and displays the telephone number
of the customer calling (automatic number identification
ANI). If the system knows the telephone number, it displays
the business partner data of the customer in the data finder.
A dialed number identification (DNI) function displays the
number called by the customer. In this way, the employees
are prepared for each situation, which is a real advantage in
call centers.

Reminder scripting
Supports call center employees when dealing with customers. You can define interactive scripts to conduct
outbound marketing campaigns, or enable employees to
deal with typical customer inquiries.
Data finder
Enables employees to manually identify customers based
on various criteria. The system displays the business partner,
which the employee can then confirm.
Navigation area
After identification, the system displays the complete data
environment of the given business partner in hierarchical
form. From here, the employee can access all the relevant
customer data, such as the contact history, contract overview, and so on.

Telephony function bar


Data finder
Action box

Navigation area

Work area

Figure 18: Sample Configuration for the Interaction Center

38

Action box
Contains all the important transactions, which can be
accessed via drop-down menus. The action box enables the
employee to call SAP functions and execute Web-enabled
transactions in the work area. This enables employees to
enter customer inquiries, technical problems, and complaints efficiently, and use workflows to process them until
a solution is reached.
Work area
Contains relevant data on the business partner (and the
functions you have called) for viewing or processing (for
example, if the address of the customer needs changing,
the address data of that customer is displayed).
The IC can be configured to allow transactions and data
from mySAP Utilities to be called directly from the work area.
External systems with Web-enabled transactions can also be
integrated in the IC.

Example: A customer contacts the call center and wants to


change the budget-billing plan. The call center employee can
call the Change Budget Billing Plan transaction directly
from the IC. The transaction, which runs in mySAP Utilities,
is displayed in the work area. The customers business partner
number is also transferred, meaning that it does not have to
be re-entered. Integration of mySAP CRM and mySAP Utilities
enables the call center employee to view both systems. They
can display and process data that is not found in mySAP CRM.
All plausibility and consistency checks that take place with
independent access to the back-end system are also performed
here. Once the back-end transactions have been processed, the
system saves the data in that system, making it unnecessary to
store data in mySAP CRM. However, the contract log for the
call is available in mySAP CRM. This provides a uniform view
of the customer contacts (mySAP Utilities) and activities
(mySAP CRM).

Call center employees can therefore call data and transactions


from various different systems without having to:
Log on to other systems
Re-enter the required objects in different systems; the IC
guarantees seamless navigation with other systems.

39

INTEGRATION OF mySAP CRM IN mySAP UTILITIES

System Landscape

ANALYSES

FRONT-END

Electronic
business
(Internet)

SAP BW

Middleware

M Syste
P CR
m
SA

Business objects,
for example
business partners,
activities, contracts,
products, sales
projects, etc.

mySAP
Utilities

ITS/
WAS

CTI

Telebusiness

Mobile
applications

BACK-END

Figure 19: Integration of mySAP CRM, mySAP Utilities, and SAP BW

When mySAP CRM, mySAP Utilities, and mySAP Business


Intelligence with SAP Business Information Warehouse are
integrated, the most sensible approach is to run the processes
across all the systems. This approach has the following benefits:

40

Different tasks can be carried out in parallel without impairing the performance of the other systems. For example, a
billing run in the back-end system (mySAP Utilities) does not
affect the call center of the front-end system (mySAP CRM).

Even if some objects are available in both systems, not all

CTI interface that connects mySAP CRM with the telephone

data has to be synchronized between those systems. It is sufficient, for example, if all the prospects are in the front-end
system and are not synchronized in the back-end system
until they become real customers. This method keeps the
volume of unnecessary data to a minimum.
Physical separation of the systems. A prerequisite for qualitative analysis is a large variety of data from different sources
that can be subjected to multidimensional analyses. This
requires high data capacities and a high level of flexibility
when carrying out analyses. Therefore, the most sensible
option is to physically separate the analysis system from the
other systems. Otherwise, you would either have to do without data from the other systems or suffer impaired system
performance in other processes while analyses are running.
Another reason for physically separating the systems is so
that each system, complete with its respective functions, can
be integrated into existing IT landscapes.

system, ensuring full telephony integration for all


interaction center scenarios
Offline applications that enable you to access central mySAP
CRM data and functions via a laptop. The CRM middleware
synchronizes offline data with the online system.

However, be aware that running processes across all systems


does not mean that each system must run on separate hardware. An ideal solution for small and midsize businesses is the
industry-specific solution mySAP All-in-One. This solution is
based on mySAP.com and tailored to the needs of companies
with up to 2,000 employees. It integrates all the mySAP.com
solutions on a single server.
What role does each system play in the integration scenario?
mySAP CRM is the front-end solution for interacting with
customer, prospects, and partners. It contains all the functions needed for marketing, sales, and customer retention, and
enables you to communicate with your customers via a number of different channels, for example:
Web-based applications (Internet sales and Internet marketing) that are integrated in the CRM solution using modern
and open Java technology

As the front-end solution, all forms of interaction with the


customer in the areas of service, sales, and marketing either
run in, or are started from the CRM system.
mySAP Utilities is the back-end solution. Information on
a customer is not synchronized in mySAP Utilities until that
customer has concluded a contract. mySAP Utilities contains
all the data and transactions for energy data management,
billing, invoicing, and contract accounts receivable and
payable.
SAP BW is used for analysis, planning, monitoring, and
success checks. SAP BW enables you to collect information
from any system (mySAP CRM, mySAP Utilities, and external
systems) in information cubes to analyze this information at
multiple levels. SAP provides special contents for each SAP
solution that enables you to import data in SAP BW. They also
contain preconfigured analyses and reports that you can
enhance as required.
Technical integration of SAP BW, mySAP CRM, and mySAP
Utilities enables you to control all processes relating to customer interaction, and model and evaluate all sales processes
from acquisition of new customers through contract creation
to billing.

41

Data is synchronized immediately to ensure that it is both


consistent and transparent. Figure 20 shows which objects are
synchronized. Information on business partners and contract
accounts is found at the business partner level in mySAP CRM.
mySAP Utilities contracts are synchronized with mySAP CRM
service contracts. The point of delivery and connection objects
are synchronized with their corresponding technical objects in
mySAP CRM. Devices, meters, and so on are only found in
mySAP Utilities, but can be identified via the point of delivery.
mySAP Utilities contacts are synchronized with CRM activities
(one-sided replication), so that each interaction with the cus-

Synchronization of Data Between mySAP CRM and


mySAP Utilities
Both mySAP Utilities and mySAP CRM can be implemented
independently of each other, or in combination with external
solutions. To do so, central objects are required in both systems.
These objects are automatically synchronized by the CRM
middleware. They are:
Business partners and their contract accounts
Contracts
Connection object and points of delivery
mySAP Utilities contacts that correspond to CRM activities

SELECT PRODUCTS VIA


mySAP CRM CHANNELS:

MASTER DATA GENERATED OR


CHANGED IN mySAP UTILITIES

Fixed product information


Internet

Customer
(Susan Moore)

Call Center
(Connie Johnson)

mySAP CRM
product
Family Energy
Configuration

Master data
template
Family Energy

Master data
generator

Configuration

Hand-held

Variable product information

Cross-system business processes

Figure 20: Selling a Utility Product

42

mySAP
Utilities

tomer can be recognized at a glance in mySAP CRM regardless of whether it is a CRM activity such as a campaign, or a
mySAP Utilities contact, such as a disconnection.
In the deregulated market, utility companies can use campaigns to offer their customers products. Products are defined
in mySAP CRM. Each product must correspond with a master
data template in mySAP Utilities (see below Master Data
Generator). Products and their corresponding master data
templates are maintained manually. Changes are not automatically synchronized; however, utility companies generally only
offer a limited number of products, making the time spent on
product maintenance negligible.
Master Data Generator Automatic Creation of and
Changes to Master Data
When a prospect decides to become a customer of your utility
company, a large number of transactions are needed to model
that prospect as a customer with billable master data in the
back-end system. The system changes the role from prospect
to business partner, creates a contract account, contract,
installation, connection object and premise, performs a movein, enters meter readings at move-in, and so on. Master data is
usually created manually, which is both time consuming and
prone to error. SAP provides a master data generator, which
can be used to create and change master data automatically,
thus avoiding the need to spend time performing this task
manually.

Figure 20 shows an example of a product sale. Susan Moore,


a customer, calls regarding a direct mail marketing campaign,
conducted by her utility companys interaction center. She
wishes to switch to the utility product Family Energy to
reduce her energy bills. The call center employee, Connie
Johnson, takes Susans address, asks for her electricity consumption for the past year, and the start date for the new product (variable product information). Once Connie has saved this
transaction, the system uses the product information to create
all the relevant master data. Products contain both fixed information (which is identical for each business partner) and variable information that can differ for each business partner
(configuration). When selecting the product, the agent can
enter the variable product criteria, which can include annual
consumption, discounts, connection services, and so on.
Once the contract has been created in mySAP CRM, it is synchronized with mySAP Utilities. Since the contract specifies
which products were sold, information on the products is also
transferred to mySAP Utilities. Products have a corresponding
master data template that contains the fixed product information (that is identical for each business partner) in mySAP
Utilities. The master data generator now combines the fixed
information from the master data template with the variable
product information from the configuration. The master data
generator uses the combined information to create the billable
constructs required in mySAP Utilities (if the customer is new)
or change existing constructs (in the case of an existing
customer).

43

All Data at a Glance: The Cross-System Customer Fact


Sheet
Each time you interact or communicate with a customer, all
the important data relating to that business partner should be
accessible at a glance. Since most of this information is stored
in different systems, data must be made available in a consolidated form from a single interface.
mySAP CRM offers a cross-system customer fact sheet (CFS)
for each business partner that does just this. SAP provides
a preconfigured CFS for the utilities industry that you can
modify as required. The preconfigured CFS contains information from mySAP Utilities, such as budget billing plans, bill
amounts, and open items.
Information from external systems can also form part of the
CFS (for example, information from SAP BW on whether the
customer is classified as A, B, or C).
Integrated Scenarios from mySAP CRM, mySAP Utilities,
and SAP BW
The information below only describes scenarios supported by
single solutions. Naturally, all the processes contained in the
mySAP CRM solutions (such as activity management and opportunity management), and all the mySAP Utilities processes
(such as service management) are available.
From Campaign Through Sales Process with Residential
Customers to Invoicing
1. Master and transaction data from existing customers that
is required for the market analysis is transferred from
mySAP CRM and/or mySAP Utilities to SAP BW, where
target groups are analyzed. Externally purchased data on
prospects can also be imported to SAP BW.
2. The target group can be selected according to your
criteria in SAP BW.

44

3. Once selected, the target group is transferred to mySAP


CRM, where each prospect is created as a business partner
with the prospect role. Once the campaign is over, those
business partners who did not respond can be deleted.
4. A marketing plan is created (optional) in mySAP CRM.
One or more campaigns, including target groups, are allocated to the plan.
5. A suitable campaign can be created in mySAP CRM via
various different channels (for example, e-mail, telephone
call, fax, letter, visit from field service, or supplement in bill
or additional line in bill). When you choose the campaign
channel, you can enter the preferred contact method of
each customer/prospect, so that you can run one campaign
through different channels. Before you conduct the campaign, you must create template texts for letter, e-mail, bill
supplement, or fax campaigns. You can add the data on
your business partners to the template as required (for
example, name, or electricity consumption). In the case of
an outbound campaign, you can store suitable information
texts for the call center employees, and interactive scripts
that support telephone conversations.
6. When you conduct the campaign, activities for the individual business partners are created, enabling you to see
which partners were targeted by the campaign. A business
partners response to a campaign (for example, a partner
requests more information) is also created as an activity in
mySAP CRM and imported into SAP BW.
7. If a business partner contacts the utility company because
of the campaign and wishes to become a customer, the new
customer role is allocated to the corresponding prospect. If the business partner was already a customer, the
status does not change.
8. The business partner selects a product (during a call
to the call center, for example) and specifies the date on
which the new contract is to start, location of the premise,
and their previous utility company, if this information is
required. The system creates a contract in mySAP CRM,
which is replicated in mySAP Utilities.

9. Product selection activates the master data generator


(see above Master Data Generator). The master data generator uses the product information to determine whether
master data must be created (new customer) or changed
(existing customer with new rate or product), and creates
or changes the data as required.
10. Once the utility contract has been synchronized in mySAP
Utilities, the electronic data exchange process runs
(with either the distributor or previous utility company,
depending on the country).
11. Meter reading results are entered in mySAP Utilities at
a later stage and the contracts are billed and invoiced.
12. The billing data (sales and transaction statistics) is transferred to SAP BW, where the campaign number can be used
to analyze how much revenue was generated by the campaign and how many contracts were signed.
From Potential Non-Residential Customer to Enrollment
1. Since this process can last for several weeks or months,
potential sales to existing or potential non-residential customers are created as opportunities in mySAP CRM.
The opportunity contains both the expected revenue
figure, and the likelihood of a contract and probable date
of enrollment. The aim is to use the opportunity to continuously monitor the non-residential customer. The
opportunity also forms the basis for pipeline analyses, forecast calculations, and win/loss analyses. SAP also provides
a predefined sales methodology (a specially modified
opportunity) that supports and controls sales using predefined activities. Additional information on customers
(contact persons and sales arguments) and specialist sales
processes (employees, products, and price) can be stored
in the methodology for sales to non-residential customers.
The technical data for the various withdrawal points of the
non-residential customer (connection objects, premises,
and points of delivery, and their technical attributes) can
also be stored.

2. After the sales employee has made initial contact with the
(potential) non-residential customer, the quotation can
be prepared. The quotation uses the information that was
already entered in the opportunity about the customer,
withdrawal points, and products.
3. The calculation forms the basis of the quotation, where
consumption data or the load profile of the nonresidential customer is either imported into a calculation
tool (via SAP Energy Data Management (EDM) or a standard interface), or entered manually. The calculation is
then performed in mySAP CRM. You can use a number of
tools here, such as the Internet pricing configurator (IPC),
or the integrated Microsoft Excel application. You can also
use an interface to the external calculation tools used by
many companies. SAP provides an Excel-based productspecific catalog template that can be extended or modified
for all your products. The calculation template works out
a price for the consumption data/load profile of the customer, and determines the grid usage conditions (which
are derived from the distributors responsible for the withdrawal points). The results of the calculation are specific
to the quotation (such as monthly prices and demand).
4. The profitability and contribution margin of the quotation can then be calculated in the calculation template
based on integrated data from sales statistics, unbilled
revenue reporting, or by extrapolation, in the case of new
customers.
5. The calculated data is transferred to the quotation, which
can then be sent to the potential customer.
6. When the quotation is sent to the customer, or presented
by the sales force, a corresponding activity is created in
mySAP CRM permitting you to check that the customer
has received the quotation.
7. Contract negotiations can start once the quotation has
been reviewed. If the quotation conditions change during
those negotiations, an opportunity created for this purpose
can be changed.

45

8. If the customer accepts the quotation, the system converts


it to one or more contracts. The conditions are copied
into the contract automatically.
9. If the new contract causes an existing contract to be terminated, a contract end date is entered in the existing contract.
From Potential Chain/Outline Contract Customer
to Enrollment
Chains and outline contract customers negotiate with utility
companies for special contracts and prices. The sales process
is therefore different from the process for non-residential
customers described above.
In the case of chain and outline contract customers, the
individual customers are allocated to a customer group
hierarchy in mySAP CRM.
Process steps 1 to 3 are identical to those above. The profitability and contribution margin for each withdrawal
point (for example, for each branch office) can be calculated
in step 4.
Process steps 5 to 7 are also identical to those above. However,
after step 7 at the latest, an outline contract is modeled in the
system for the chain/outline contract customer.
Process step 8 is different, insofar as the individual quotation
items for the withdrawal points are realized in several utility
contracts (one for each withdrawal point).
Process steps 9 and 10 are identical to those above. However,
both the outline contract and the individual contracts are
replicated in mySAP Utilities.

46

From Phone Call to Changes in Master Data


1. A customer contacts the call center to change his or her
master data (for example, to report change of last name).
2. The call center employee (agent) identifies the customer by
name, customer number, address, or any other information
the customer provides over the telephone.
3. The agent accesses and modifies the appropriate master
data in mySAP CRM.
4. An activity is automatically created in mySAP CRM that
documents the changes made to the customers master
data.
5. Once the changes are saved in the CRM system, they are
automatically replicated in mySAP Utilities. However, the
agent could equally have made the changes in mySAP
Utilities; they would then have been replicated in mySAP
CRM.
Typical Front Office Processes
Front office processes are predefined sequences of individual
work steps that manage typical processes in call centers. They
are designed to process specific business transactions and transfer data between the different steps. Limited options for repeating steps and performing specific processing steps are available.
Front office processes enable you to execute SAP R/3 functions
in a predefined sequence. They have been developed to model
business processes in the system for immediate processing by
a call center employee. Unlike a workflow, no work items are
entered in the employees inbox; the necessary activities appear
on the employees screen instead.
A front office process consists of one or more process steps,
which in turn can consist of processes. Therefore, a front office
process can even start a workflow that completes the business
transaction (for example, in the case of a service connection).
If the call center agent is not responsible for processing the

customers request, the item can be resubmitted for the relevant agent. The initial agent can include additional information as notes, and specify a reference. The following front
office processes can be remotely called in mySAP CRM
but run entirely in mySAP Utilities.
Move-In
During a move-in, you can create a new business partner and
contract account for a customer, or select existing data. Contracts are created and allocated to a utility installation for each
division.
Example:
1. A customer informs the utility company that they intend
to move into the supply territory (or have already moved),
or want to be supplied by the utility company at a future
date.
2. The agent identifies the premise into which the customer
intends to move (or has moved).
3. The agent enters a new employee in the system.
4. The agent creates a new contract account and one or
more contracts (for example, for electricity or gas) for
the customer.
5. The agent now asks the customer for the meter reading
at the time of move-in.
6. The agent accesses the meter reading at move-in and
performs a meter reading in the system.
7. The agent enters each set of meter reading results from
the devices installed at the premise.
8. The rate data is then maintained and the billability of the
billing construct checked.
9. The credit rating of the customer can now be maintained
manually with a cash security deposit.

10. The budget billing plan and welcome letter can now be
created.
11. In the last step of the front office process, a move-in charge
can be requested.
Move-Out
In move-out processing, a contract with a customer is terminated. In the case of a customer change, the utilitys installations included in the contract are allocated to a different
customer after the move-out date.
Automatic steps in move-out processing include the following:
1. A customer informs the utility company that they intend
to move out of a premise, or out of the supply territory.
2. The agent identifies the customer and the contracts requiring termination in the system.
3. The agent asks the customer for the planned move-out
date and enters it in the system.
4. If the customer already knows the final meter reading, the
agent can enter it. If this is not the case, the following steps
and processing are automatically executed in mySAP
Utilities:
The customers contract(s) are terminated.
No additional budget billing amounts are charged.
Any outstanding dunning procedures are stopped.
The changes to the dunning procedure affect the open
items.
The following move-out processing steps are optional:
5. The agent can add data to the customers contact details.
6. The agent can process the customer and their contract
account.
7. The agent can perform the final meter reading immediately, invoice the final bill, and print it out for the customer.
8. The agent can create a move-out confirmation.

47

Business Partner Move-In/Out


You can use the complete set of functions from both move-in
and move-out here. This means you can process a move-in/out
customer fully and immediately, complete with bill and welcome letter.
Move-in/out processing steps:
1. A customer contacts the call center to register plans
for move-in/out.
2. The agent calls move-in/out processing, and identifies
the customer, and the current and future premises.
3. The agent identifies and enters the changes to the
customers data caused by the move-in/out, such as
the payment transactions and address.
4. The customer specifies current meter readings.
If the customer has a budget billing plan, it is stopped.
5. The agent completes the customers move-out.
6. The agent requests the customers move-in date and
meter readings at move-in.
7. The agent can also create a new budget billing plan
for the new premise and a welcome letter.
8. The customer receives a final bill for the old premise.
You can modify both the appearance of the screen and the
sequence of processing steps in the move-in and move-out
to meet your requirements.
Change Bank Details
The change bank details process consists of the following
steps:
1. A customer contacts the call center and informs the agent
of a change to bank details.
2. The agent identifies the customer and chooses the transaction for changing bank data.
3. The agent stores the new bank details in the customers
data.
4. In the next step, a new set of bank details is allocated in
the contract account.
5. The agent also has the option of creating a customer
contact.

48

Change Budget Billing Plan


A business partner wants the budget billing plan to be changed.
The change budget billing plan process consists of the
following steps:
1. A customer contacts the call center to change the budget
billing plan because of changed consumption patterns.
2. The agent identifies the customer and accesses the transaction for changing the budget billing plan.
3. The budget billing plan concerned is selected and a new
budget billing amount is entered. The amount can be
changed for each contract. The due date of the budget
billing amounts can also be changed, or a postponement
date can be specified. These changes can be made to affect
the entire budget billing plan or just individual amounts.
4. The agent has the option of creating a notification of the
changes for the customer and a customer contact.
Change Installment Plan
When a payment is to be made in installments, an installment
plan is created to cover the amount of the original receivable.
The individual installments and their respective due dates are
defined in the installment plan.
Judicial dunning procedures identify customers who have
repeatedly failed to meet their payment obligations.
1. The agent contacts the customer (a special form of customer service for debt advice) and proposes an installment
plan to repay the outstanding receivables.
2. The agent selects these open items and discusses possible
repayment conditions with the customer.
3. The agent enters the start date for repayment and the
number of installments, which determines each installment amount.
4. After the installment plan has been saved, a letter can be
sent to the customer.
5. The agent has the option of creating a customer contact.

Bill Reprint
A customer requests a copy of a lost bill.
1. The agent identifies the customer and uses the customer
overview to access the appropriate print document.
2. The agent starts the bill reprint process and selects a
dispatch medium (for example, e-mail or post).
3. The agent has the option of creating a customer contact.

the disputed bill. The workflow should be used when the


agent cannot decide whether the bill complaint is justifiable,
and requires a control reading to prove the complaint.

Bill Complaint
You can use this workflow if the customer disputes the meter
reading results used to create the bill.

The workflow is executed for a bill. Once the workflow has


been started, the following steps are run:
1. The agent chooses the billing documents from the bill to
which the customers complaint refers. (A billing can refer
to more than one contract and therefore contain more
than one billing document, for example, contracts from
several divisions, such as electricity, gas, and water.)
2. The Change Contract function is accessed for the selected
billing documents and corresponding contracts. The agent
can set a billing block here that prevents the contract from
being billed until the complaint has been resolved.
3. A meter reading order for a control reading is created for
the selected contracts.
4. No further processing takes place until all the control
readings for the contract have been entered.
5. If these meter reading results are available, a work item
is processed for the agent. This item enables the agent to
continue processing the complaint. All the meter reading
results belonging to the contract are displayed (both the
disputed meter reading results and the control readings).
The next step is a user decision, where the agent decides
whether to correct the disputed meter reading results.
6. If the meter reading results are corrected, a billing reversal
is executed for the contract. The disputed meter readings
are given to the agent for correction.
7. The agent can now instruct the system to estimate the
disputed meter reading results.
8. The agent can change the contract. This means that the
billing block that was set in step 2 can be removed so that
the contract can be re-billed.

The workflow describes a possible bill complaint process that


can result in a correction to the meter reading results. The
workflow can support and monitor entry of a control reading.
Based on this reading, the agent can decide whether to correct

The disputed meter reading results are now corrected. The


new billing for the billing orders is not part of the workflow.
Billing and invoicing now take place in the next billing and
invoicing run.

SAP BUSINESS WORKFLOW

The SAP Business Workflow enables you to define business


processes that are not modeled in the SAP R/3 System. These
processes can be simple release or approval procedures, or
complex processes, such as creating a service connection and
coordinating the departments involved in that process. SAP
Business Workflow is particularly useful in situations where
processes must be repeated, or where the business process
requires the attention of various agents in a certain order.
You can also use SAP Business Workflow to react to errors and
exceptional situations in other existing business processes. You
can start a workflow if events occur that have been previously
defined in the system. For instance, you can trigger a workflow
if a certain error is found during an automatic check.
SAP provides a number of workflows that model predefined
business processes. These workflows can be easily implemented.
SAP provides three workflows for customer service. These are
bill complaint, lay service connection, and disconnection/
reconnection.

49

Lay a Service Connection


This business process has also been implemented as a workflow. It contains all the steps, from quotation to creation of
a service order or bill that must be carried out to lay a new
service connection. For more information on this workflow,
see chapter 9, Work Management.
Disconnection/Reconnection
This workflow is required in cases when a utility service to a
customer must be temporarily suspended, above all as part of
a judicial dunning procedure. A disconnection is a suspension
of a utility service that does not entail removing a meter from
a premise. This may be due to a collection procedure resulting
from payment arrears, or a technical disconnection at the customers or utility companys request.
In the former case, the customer is reconnected when the outstanding payments are made; in the latter, at the request of the
party that ordered the disconnection. Flat-rate charges for disconnection and reconnection can be levied and invoiced in
mySAP Utilities.
This workflow, like the other two workflows and the front
office processes, is explained in detail in the corresponding
documentation.

Display and pay open items (by direct debit, either as a


one-off or repeatedly, or credit card)
Change billing address
Move-in and initial data creation, including electronic data
exchange
Move-out
Enter meter reading
Display consumption history (also in graphical form)
Display load profile
Initiate call-back
Use rate calculator
Grant direct debit authorization
To ensure maximum cost savings, these transactions can be
configured in such a way that changes are made directly in the
back-end system. You can also trigger a workflow that enables
agents to perform manual checks. Naturally, ISS enables you to
perform all forms of plausibility checks.
SOLUTION BENEFITS

When utility companies select a suitable CRM solution, integration is one consideration that is often overlooked. Ultimately,
however, the functional scope of a CRM solution is not the
only decisive factor in the success of the overall solution; the
way in which the individual solutions interact is equally
important.

INTERNET SELF-SERVICE INCLUDING AUTOMATIC


CHANGES IN mySAP UTILITIES

Internet self-services (ISS) provide your customers with roundthe-clock services. Customers can take advantage of your central services independently of your opening times and without
having to queue. These services also benefit you, as a utility
company, since they are significantly more cost-effective than
a call center contact or branch office visit.
Customers can use the following Internet self-services:
Registration (in conjunction with a complete address and
customer number)
Change password
Display bill (including cover sheet)

50

The integration of mySAP Utilities and mySAP CRM has the


following advantages:
Low overall project costs and short implementation times
since the most important processes are already integrated
Consistent and consolidated view of customers and data
Better service and higher levels of customer satisfaction
thanks to short processing times for customer inquiries
Improved ability to evaluate customer interaction processes
and campaigns
Ability to swiftly react to changing customer and market
requirements
Positive effect on your operating profit thanks to higher
revenues, returns, and lasting competitive advantages

ENERGY DATA MANAGEMENT


Energy data management (EDM) is a key functional area of
mySAP Utilities. It enables utility companies to manage all
energy data, such as load shapes and standard load profiles for
for individual points of delivery. Energy data can be validated
when it is transferred. It can then be saved and displayed in
a variety of formats and layouts.
The energy data management component consists of the
following areas:
Device management
Meter reading
Energy Data Repository
Settlement
With energy data management, you gain the following
capabilities:
Enables companies to manage its meter and device data
Supports the entry and management of meter reading
results and consumption data

Manages all types of interval data, such as prices and temperatures


Supports the creation and management of load profiles
and load shapes
Supports energy settlement procedures
Enables direct billing based on interval data (real-time
pricing and time of use)
DEVICE MANAGEMENT

If a company only uses device data as a source of information


for billing and, as a result, does not need to have the complete
device management component, it can use the device information record in mySAP Utilities to perform billing-orientated
functions. The device information record is an object in mySAP
Utilities that enables a company to map devices in the system
that are maintained by or belong to other companies. For this
reason, as a supplier, you do not have to have the complete
Device Management component in your system. Instead, you
create a device information record that only manages device
data that is required for billing, such as rate data, device alloca-

Device category description


Manufacturer & category

Register

Register group

Material number

Meter reading

Device category data


Device number (serial no.)
Device data

Figure 21: Data from Device Category and Device

51

tions, register relationships, and maintenance of logical registers. There is no longer a connection to the plant maintenance
(PM) component. Any communication with other systems,
such as importing consumption data, takes place via the point
of delivery. Companies that do want to use the complete
device management component can use it to manage technical
data, installations, and device inspections. In these cases, a
device in mySAP Utilities corresponds to a piece of equipment
in the plant maintenance (PM) component.
Devices can do the following:
Meter (for example, meters)
Control (for example, ripple control receivers)
Process data (for example, correctors)
Protect or adjust (for example, pressure regulators)
You identify a device by its device number. The device number
is generated in the materials management component during
goods receipt (where it is called a serial number) and then allocated to the device. Every device belongs to a particular device
category. A device category groups together devices with the
same technical characteristics and contains data that is common
to those devices, such as the device category description or certification data. The device category in mySAP Utilities corresponds to the material in the materials management component.
The various device categories are allocated to the following
basic device categories:
Meter
Transformer
Ripple control receiver
Remote meter
Counter
Corrector
Pressure regulator
Sensor
Other

52

A device category can also be a combination of several basic


device categories.
Device Movement
You implement device movements in mySAP Utilities through
the integration of the materials management component. The
following functions are available:
Procurement
You procure devices in purchasing using the purchase order
and purchase requisition components.
Inbound delivery
You enter the inbound delivery of devices in inventory
management using the goods receipt component. Since
equipment records are created automatically, you can use
functions from the plant maintenance component (for
example, maintenance planning and maintenance task lists).
Stock transfer
You transfer stock in inventory management using the stock
transfer and transfer posting components. You can either
transfer individual devices, identified by their device number,
or a whole stock of devices.
Retirement
Devices that no longer belong to a companys stock because
they have been scrapped or sold are processed in inventory
management using the goods issue and return delivery components. The master records for these devices are saved.
Technical Device Data and Connection Data
Technical device and connection data are grouped together in
the following components:
Register group
This component groups together the registers that belong to
a device or device category. It registers meter consumption
and demand. A register can be an actual physical device or a
display on an electronic device. The register group describes

the technical data (such as the number of digits and type of


display) and the billing data (such as rate usage type) of a
register.
Input/output group
This component groups together the inputs and outputs
that are valid for a device or device category and describes
the technical data. Inputs and outputs are interfaces for
devices. For example, remote meters have several pulse inputs and a modem interface.
Command group
This component groups together commands. A command
is a signal sent by a utility company that triggers a switching
procedure in a ripple control receiver. For example, the
command group for streetlights consists of the commands
Switch-on,Decrease Demand,and Switch-off.
Winding group
This component groups together windings that belong to a
device or device category. Windings define the transformation ratio (of transformers for example) and are divided into
primary and secondary windings.
Device Installation
There are three different types of device installation namely
technical installation, billing-related installation, and full installation. With a technical installation, you first link a device
to a device location. You can then allocate it to any number
of installations using a billing-related installation. For a full
installation, you can link a device to both a device location and
an installation in a single step.
You can install devices in the following ways:
Technical installation only
You use this option if a meter is not to be billed. This would
apply if the meter is a control meter or if it belongs to the
utility company.
Technical installation followed by billing-related installation
You use this option in the following cases:

If meters in an apartment building are installed first


and allocated to specific apartments later
If the two steps are handled by different agents
One technical installation and several billing-related installations
You use this option for a dual contract model or if a pressure
regulator or an ARCR controls several installations.
Full installation
This option is for single family homes, for example.
The following functions are available during installation:
Allocation of devices (transformer to meter, for example)
Entry of period consumption
Entry of meter readings at the time of installation
Creation of register relationships
Adoption of sample register relationships
There are also three different types of device removals: technical removal, billing-related removal, and full removal. All rate
data and relationships with other devices are deleted on the
removal date. However, they can still be traced using the time
slices. Reference values are not deleted automatically but you
can delete them manually. You can also enter the meter reading recorded at the time of removal. Device installation or
removal can trigger the following events:
Initial data creation
Installation extension
Periodic replacement/sampling procedure
Damage/complaint
Change in consumption behavior
Installation removal
Device installation and device removal differ from device
replacement.

53

Device replacement means that you replace one device with


another that has the same or a similar device category, and
that takes over the same function. Instead of removing and
then reinstalling a device, you replace a device if you want the
following data to be transferred automatically to the new
device:
Rate data
Register relationships
Device relationships
Register-related period consumption
Disconnection status
It is necessary to replace a device if an installed device is damaged or if it is to be certified. In the event of device replacement, you can enter the meter readings recorded at the time
of removal and installation. For deregulated contracts, you
must check and, if necessary, execute technical and billingrelated installation, removal, and replacement for all related
contracts. If you modify a device that is not installed, you can
change the following data depending on the device category:
Register group
Input/output group
Command group
You can also modify an installed device (device modification).
The data that you are allowed to change depends on the device
category. To modify an installed electronic meter, for example,
it would have to be reprogrammed. A device group groups
together devices into a logical unit (for example, integrated
water meter or transformer). The devices in a device group
must either all be installed or all not installed. If you want to
install or remove a device that belongs to a device group, the
system automatically displays all the devices in that group for
installation or removal. In other words, you cannot install or
remove individual devices that belong to a device group. It
makes sense to create a device group in the following cases:
If current and voltage transformers are placed into transformer groups, resulting in a certain transformation ratio
If two integrated water meters are installed together but
meter and are billed separately

54

The devices installed in a utility installation, their registers,


and their rate allocations make up the installation structure.
You can process the technical and billing-related data of
devices and registers in the installation structure. You can
process the following technical data:
Device allocations
Device allocations describe dependencies of devices with
other devices, such as meters controlled by ripple control
receivers or a transformer group connected to a meter,
for example.
Register relationships
Register relationships describe the relationships between
registers. The following relationships are taken into account
when you create a meter reading order:
Allocation of active registers to reactive registers when
calculating the cosine phi
Serial switching of several registers (primary/secondary
meter relationships)
Linking of registers to different usage types (On-peak/
off-peak check)
Control relationships
Special relationships for allocating thermal gas factors
Note that the registers may belong to different contracts.
Logical
registers

Logical registers describe the allocation of a certain task to a


register and are most important in device replacement. The
register of the old device must have the same logical register
number as the register of the new device, for the following
reasons:
The billing-related data is copied to the new register
The billing component must recognize which register is to
take over the role of the old device (especially in the case
of demand values)

Billing-related data, that is rate data, is dependent on the


installation. Therefore, you can only process the data if the
device is allocated to an installation. You can process the
following billing-related data:
The relevance of a register to billing
The rate data of a register
The price class
In a deregulated scenario, the installation structure data of the
partial service contracts involved may have the following differences:

The rental price and regulation price are only entered in the
service providers installation
Rating is dependent on consumption
Additional devices, such as ripple control receivers, are only
installed in the service providers installation
Device Inspection
If a device passes an inspection in accordance with prescribed
margins of error, it is certified for a certain period and can be
reinstalled. You can inspect and certify a device either as part
of a lot in a sample procedure, during periodic replacement, or

Device
category
B

Device
category
A

Periodic replacement year

Sample lot

Replacement
orders for sample devices and
spare sample devices

Replacement orders
for all devices

Figure 22: Overview of the Certification Procedure

55

Create lot

Put together
lot

Determine
devices for lot

1st drawing

2nd drawing

Check sample
devices

No

Yes
Passed ?

Delete lot

Certify
samples

Copy devices to
periodic
replacement list

Extend lot

Figure 23: Inspection using the Sample Lot Procedure

individually. The extent of the inspections you make depends


on the inspection plan of the material master record.
There are two types of certification procedures:
The calibration validity of a device is renewed using an external certification performed by a recognized inspection office
in accordance with legal requirements.
The quality of a device is inspected according to internal
certification guidelines.
If you want to inspect devices that are already installed, you
must first remove and replace them. The Service Management
component creates a work order for this purpose that can then
be billed in the Sales and Distribution component. You must
also create a work order for devices that can be inspected without being removed.

56

Device inspection consists of the following phases:


Sampling procedure
The sampling procedure is the basis for renewing the calibration validity of devices. First, sample lots are created from the
devices that are to be certified. A fixed number of sample
devices are drawn from each lot for inspection. If the sample
devices pass the inspection, the entire lot is renewed. If a lot
does not pass the inspection, all of the devices are included in
the periodic replacement list and certified individually. You
can create lots for devices that are subject to certification
from the electricity, gas, water, and district heating divisions.
Dividing sample lots into internal and external lots allows
you to inspect the lots according to legal requirements or
internal quality control.

Billing order

MR order creation

MR order

Order display

MR documents

Download

MR results
Entry
Quick/individual entry

Upload

Plausibility check

Correction
Billing

Figure 24: Meter Reading

Periodic replacement

METER READING

During periodic replacement, devices that are due to be certified are removed and replaced by equivalent devices. You
manage the devices to be replaced using the periodic replacement list, where you can also enter other devices (for example, all the devices from a certain lot). You can then choose
from the list those devices that have to be replaced at a certain time.
Certification
As an alternative to using the sample lot procedure to certify
devices, you have the option to certify them individually. If a
lot fails inspection, the devices have to be certified individually.
Inspection results management
You can manage inspection results using the quality management component. However, this is not a requirement of
certification.

You can read devices based on:


A customer request
Periodically for periodic billing
Aperiodically for control meter readings and readings at the
time of replacement
Removal
Disconnection
You determine meter reading dates and meter reading type in
scheduling. You can however override these entries. For example, you can create an order for a meter reader to read the
meter instead of a meter reading by the customer. In the case
of aperiodic meter readings, you can enter the dates manually.
To read meters, you must first create a meter reading order. If
the meter reading results are relevant to billing, you also create
a billing order that contains control data for billing. You cannot bill a contract without the billing order. Depending on

57

how you create the meter reading order, it is either printed out
as a meter reading document or downloaded to an external
recording system. The meter reading results are then uploaded
or you enter them manually before checking their validity and
correcting them if necessary.
Street Route
You use this function to determine the sequence in which you
want the devices to be read. This enables you to optimize the
meter readers route. You can create a shared street route for
several meter-reading units. You use the following criteria to
determine the street route within a meter reading unit:
City
Street
House number (connection object)
Device location
Device

MR unit
A

Meter Reading Order


The meter reading order contains register-specific data and
information on scheduled meter readings such as meter reader
and scheduled meter reading date. You create a meter reading
order for every register either for the utility companys meter
reader, for an external meter reading company, or for a meter
reading by the customer. You can also reverse meter reading
orders. If meter reading results already exist at the time of
reversal, you can either delete them or keep them for a new
meter reading order. You can create meter reading orders as
single orders or as mass orders:
Single orders
You usually create these orders for aperiodic billing (for
interim and control meter readings for example). However,
you can also create them for periodic billing (if, for example,
you have to create a new individual order because of an
error).

City district 1

Street 1

Connection
object 1
Street 2

Connection
object 2

Device location
1

Street n

Device 1
Connection
object n

Device location
2

City district 2

Device 2
Device location
n

City district n

Figure 25 Street Route

58

Device n

Mass orders

ENERGY DATA REPOSITORY

With periodic meter readings, you can create orders simultaneously for several meter-reading units. You can also do this
in parallel if there are large amounts of orders.
Since flat-rate installations do not contain metering devices,
you create a billing order for them and not a meter reading
order. There are two ways to output meter reading orders:
Print meter reading documents using the print workbench
Make orders available using a raw data interface (RDI)
An RDI, transfers meter reading orders to external entry
systems such as mobile data entry (MDE) devices and document readers (download). Alternatively, you can print them
out from external printing systems.

Interval
meter

Internet

The Energy Data Repository manages all types of energy and


energy-relevant data belonging to a company. This can be
meter reading results from cumulated consumption measurements. It can also be data created by load shape measurements in equidistant time intervals (time series) such as energy
time series, demand time series, energy feeding time series,
load time series (measured load shapes and analytical load profiles), schedules, or calculation results. You can also process
time series that cannot be directly allocated to the energy flow.
Price time series, conversion factors (for gas billing, for example), and weather data for load forecasts are all examples of
this. These time series are called profiles.

BAPI import
interface

ENERGY DATA REPOSITORY

Dialog
Residential
customer
meter
Other market
players

AMRS

Idoc
interface

MDE

Time slice
(load shape)
PoD

IDE
Meter reading

ENERGY DATA REPOSITORY


Data retrieval

Electronic data exchange

Data import

Replacement
value creation

Consistency
checks

Data evaluation
and
formatting

Archiving

Status management

Figure 26: Energy Data Repository

59

Meter Reading Results


You can determine meter reading results (the meter reading
of a device) in the following ways:
A meter reader from the utility company or an external
meter reading company records the result on the meter
reading order or enters it in the external entry system
The customer records the readings and provides the utility
company with them
The meter reading result is estimated automatically
The system records the meter reading results and the way
in which they were determined. The meter reading result
entry function enables you to transfer the results to mySAP
Utilities either manually or by uploading them from an external entry system. Meter reading results are uploaded using an
intermediate document (IDoc) interface through direct input.
IDocs are used for electronic data interchange between systems. A Business Application Programming Interface (BAPI)
also exists for importing meter reading results. Manual entry
is divided into fast entry and single entry:
Fast entry
You can enter a large number of periodic meter readings.
Fast entry is divided into the following types:
Fast entry without immediate correction
You have to correct and release implausible meter readings
later.
Fast entry with correction
If results are implausible, you can branch directly to a correction screen to correct them or carry out further checks.
Single
entry

You can enter meter reading results singly in the following


cases:
Control meter reading
Interim meter reading
Interim meter reading with billing
Service territory transfer with billing
Final meter reading (during move-out)
Periodic meter reading
Meter reading by customer

60

Every meter reading result undergoes validation, whether you


enter it manually, or whether you upload it from an external
system. There are two types of validation, namely fixed validation and variable validation. Fixed validation is mandatory and
is performed automatically by the system. This checks whether
previous meter readings are plausible or whether inactive
installations show any consumption. You can define variable
validations yourself to verify the following:
Zero consumption
Repeated customer meter reading or estimation
You can limit the number of customer meter readings
and automatic estimations.
Absolute, relative, and floating tolerance limits
The system compares the current consumption with
consumption from a similar period, for example. The
consumption must lie within certain tolerance limits.
Usage hours compared with a previous period or a fixed
value
Maximum/minimum approved contract demand limit
Meter overflow
The system checks whether the meter reading is lower than
the previous meter reading

Enter

Manipulate

Check

Correct

Enter in SB

Implausible

Plausible

Bill

Figure 27: Validation

Follow-up

In some cases of validation, you compare the meter reading or


consumption result with an extrapolated expected value. You
can extrapolate a meter reading result for a predefined date
based on the following information:
Meter reading result
Meter reading results have the highest priority with regard
to extrapolation, since they best reflect the consumption
pattern of the customer. You must ensure that the period
from which the customers meter reading results were taken
is representative. You determine the representative period in
the rate in relation to the length of the period. The representative period can be as little as one month or as much as one
year. To calculate the degree to which meter reading results
are representative, you take into account the weighting portions that are valid for the period. The weighting portions
are determined by the weighting procedure, which is allocated to the register operand of the rate.
Period consumption
If no previous meter readings exist, or if the period is not
representative, the system uses the period consumption as a
basis for extrapolation. You can record the period consumption at the time of device installation or customer move-in
for each register in a device. You can, of course, also make
subsequent changes to it if, for example, there is a change in
the customers consumption pattern.
PRIORITY

ORIGIN OF
BASE VALUE

BASE VALUE FOR


EXTRAPOLATION

Meter
reading

MR
result

Expected
consumption

Register

Period
consumption

Expected
consumption

The following weighting procedures exist:


Linear weighting
Weighting of energy feeding
Degree day weighting
General weighting
Mixed weighting
A sum of fixed or a percentage portion from linear weightings is added to the current weighting procedure. This
enables you to determine a minimum consumption value
for each month, for example.
Weighting with absolute linear portions
You can also define a period for a fixed value in this weighting procedure.
The validation result is determined by the status of individual
meter reading results. Depending on the outcome of the validation, you can either bill or correct the meter reading result.
You also have the option to correct plausible results. In some
cases, you may need to check meter reading results on site. If
this is the case, you create a new meter reading order (a correction order) with the updated information. If meter readings
and consumption values are missing, you can use mass estimation to calculate the meter reading results.
Monitoring
You can monitor the status of meter reading, billing, and entry.
This allows you to check the number of entered, implausible,
or billable meter reading results. You can limit the display to
specific business partners, meter reading units, periods, and so
on.

Figure 28: Extrapolation

61

Load Shapes and Load Profiles


You can use the energy data management (EDM) component
to process measured load shapes as well as load profiles and
their allocation to objects (such as meters and installations) in
the mySAP Utilities data model. You can classify this allocation
as measured consumption or as forecasted consumption. The
classification is called the profile allocation role or simply the
role. You can save standardized day load profiles and group
them into an annual load shape according to a factory calendar. You can then standardize the resulting synthetic profiles
(to 1000 kWh/year, for example). You also have the option to
consider dynamic modification factors. You can create dynamic modification factors directly in the system, save them as separate factor profiles and consider them when you generate the
synthetic annual profile. You can implement other algorithms
to determine dynamic modification factors when you need
them. A consumption factor that determines the relationship
between the standardized consumption of the synthetic profile
and the actual measured consumption of the non-interval customer is saved for every synthetic load profile. This consumption factor is automatically updated and saved when you determine the consumption of the non-interval customer. You
require consumption factors for settlement, forecasting consumption, and determining overtake and undertake amounts.
You can save several consumption factors for a single customer. You do this if you want to save different consumption factors for on-peak and off-peak rates.
Import of Profile Values
Energy data management (EDM) is a system with an open
system architecture. It contains interfaces that can be used by
different manufacturers of automated meter reading systems.
You can transfer data from electronic data interchange (in data
formats such as EDIFACT, ANSI X. 12, and XML) as well as

62

data from a commercial PC or an OLE interface (in Microsoft


Excel format, for example). You can check the imported data
using a monitoring function. You must manage status values
for every imported profile value. You can define how
to process status values and whether to display them as a table
or a graph. Processes such as billing can block profile values or
entire profiles from further modification. Predefined consistency checks are made for every profile value import. These
check the validity of the inbound data and react to the predefined measures (termination of import, for example). You can
group together individual checks (limit violated, values already
exist, for example) into user-defined groups and allocate them
to the desired profile.
Replacement Value Creation
You can create replacement values for imported profile values
that are missing or incorrect. You can also create forecast
values for profiles for billing simulation or schedule creation.
The following replacement value procedures exist:
Linear replacement value procedure
This procedure creates replacement values linearly. This
means that the difference between the last known value
before the missing values and the first known value after the
missing values is split evenly amongst the missing intervals.
Maximum value replacement value procedure
This procedure replaces missing values with the maximum
value from the last known value. This value is placed before
the missing values and the first known value after the missing values.
Minimum value replacement value procedure
This procedure 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.

KW

50
Extrapolation

30

10

00:00

12:00

24:00

October 5, 2000

Interpolation

October 6, 2000

Figure 29: Replacement Value Processes

Replacement values copied from historical values of same

Replacement values copied from reference profile with

profile
Replacement values copied from profile of control register
Replacement values copied from reference profile
This procedure replaces missing values with values from a
reference profile. You can determine the reference profile
using:
The previously entered profile number of the reference
profile
A previously entered profile allocation role

reference to factory calendar


This procedure replaces missing values with values from a
reference profile. The reference period refers to the factory
calendar. This is to ensure that missing values for a public
holiday are not replaced with values from a workday, or that
missing values from a workday are not replaced with values
from a public holiday.
Replacement values copied from reference consumption
This procedure replaces missing values using a reference
consumption value. You must enter the reference consumption manually.

63

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

Figure 30: Interpolation of Profile Values


70

60

50

40

30

20

10

0
1

Figure 31: Extrapolation of Profile Values

Replacement values must be created in two different replacement value processes. The following replacement value
processes exist:
Interpolation of profile values
If you want to replace missing values from the past with
replacement values, they must be interpolated.
64

Extrapolation of profile values


If you want to forecast profile values for the future (to create
a schedule, for example), they must be extrapolated. The
extrapolated values are either overwritten with the measured
values later or they are written in a separate forecast profile.

Profile Calculation
You can use the calculation workbench to further process
saved profiles according to any mathematical connections.
This enables you to map constant profile dependencies that are
to be valid for the long term. You have the following options:
You can use a profile addition formula to combine several
energy feedings for a customer in one profile
You can convert demand profiles into consumption profiles
The dependency between the input and output values of a
calculation is mapped in a formula. Formulas are flexible, userdefinable calculation guidelines that are based on mathematical function relationships. The whole calculation construct is
called a formula allocation.
A number of formulas are provided by SAP. You can create
other formulas if you need them. You can include previously

saved profiles (with their profile values) or fixed values in the


calculation as input parameters of a formula allocation. The
status of the values is taken into account during calculation.
The output parameter of a formula allocation or the calculation result is the profile to calculate. After a calculation run,
the results are available in the subsequent processes (billing,
settlement, and schedule creation). You can enter output
parameters of a formula allocation as input parameters in
another formula allocation. This creates hierarchies of
dependent formula allocations. If, for example, the values
in an input parameter of a formula allocation change after
you have calculated the profile, the results of the formula
allocation and the dependent formula allocation are no longer
valid. The following events generate calculation triggers:
Changes to profile values after profile value import
Changes to profile values in dialog processing
Changes to the formula allocation

INPUT PARAMETERS

OUTPUT PARAMETERS
1,205

1,200
Load shape of cust. A
kWh

SUM 01

Profile for
addition

120

Total
profile

Total load shape AB


kWh

15 min intervals
Add profiles
(quantities)

Historical profile

15 min intervals
Formula profile

1,201
KEY
Load shape of cust. B
kWh

15 min intervals

Profile

Calculation status

Formula
Historical profile

Profile allocation
Formula allocation
Unit
Formula
description

Interval length
Profile type

Figure 32: Formula Allocation

65

Calculation triggers are used for calculation flags. They indicate that you must repeat the calculation to obtain correct
results. Hierarchies of dependent formula allocations are taken
into account when you process events that trigger calculation.
You can calculate profiles directly in the dialog or as a mass
process using parallel processing.
Data Analysis and Data Formatting
You can display and analyze profiles in many different ways.
For this purpose, you have a range of screen dialogs in graph
and table format at your disposal that enables you to create,
display, and modify profiles. You can limit the display of
datasets using multiple filter functions. Sorting functions are
also available.
You can copy the data in table form directly to a spreadsheet
program such as Microsoft Excel. This enables you to further
process the data in your normal PC environment. You can also
copy data that has been modified in a spreadsheet program back
to the Energy Data Repository. The system checks that all entries
are correct in order to avoid inconsistent datasets. If an entry
leads to a reaction in the system (a change of status, for example), this is immediately updated in the tables and graphics.

Version Creation and Revision Security


Modifications to profile data are saved automatically and the
changes are logged. In the process, different profile versions are
managed historically. Every version is given an identification
which contains the reason the change was made, the person
that made the change, and the period during which the
change was active. This allows you to determine which data
was active in the system with which status and at which point,
or who made a change at a certain point. You can create new
versions manually or they can be created automatically using
an automatic business process such as settlement. As well as
creating versions, you can also fully lock data so that no
changes can be made. You do this for periods that have already
been billed or settled.
Archiving
Processing meter reading results and profiles involves large
quantities of data. Consequently, you can archive meter reading results and profile values that are no longer required
online. You can specify a retention period in the operational
database. The data that has passed the retention period is stored
in the archive. Dependencies from other archiving objects are
taken into account. Energy data management also supports
connections to external archiving systems. This ensures that
only data required at this time is contained in the system. You
can access older data at any time from the archive.
Data Preparation in the Internet
You can put data from the Energy Data Repository on the
Internet so that external market participants can access it.
Only authorized users can access the data.

Figure 33: Graphical Profile Value Display


66

SETTLEMENT

Settlement in energy data management refers to the settlement of energy quantities. All input data required for settlement comes from the energy data repository, or it is created
there using formula calculations. The required data is taken
directly from the system. In this way, the energy quantities to
be settled are determined in the same place as their source:
the customer information system and the billing system. The
advantage of this solution is that you can use the current data

record from the settlement period to perform settlement for


each day of your period, at any time, and without interfaces.
Settlement of energy quantities also includes the settlement of
grid usage and schedule creation. Schedule creation has the
same technical infrastructure as settlement. To manage, plan,
test, execute, and log settlement runs as well as to create
schedules, you use the settlement workbench, which was
specially developed for this purpose.

Plans and controls


settlement runs and
creation of schedules

SETTLEMENT WORKBENCH

Settlement document

Settlement procedure

Settlement run

Settlement mode

(e.g. synthetic, analytical)

Settlement
log
(Simulation, active)

SETTLEMENT PROCESS
Input parameter
Interim result
Output parameter

Settlement step ...1

(e.g. determine
total load shape)

Input parameter
Interim result
Output parameter

Settlement step ...2

(e.g. subtract
interval customers)

Input parameter
Interim result
Output parameter

Settlement step ...n

(e.g. send results


using IDE)

Figure 34: Settlement Workbench

67

The settlement workbench manages settlement documents,


which contain the basic data of settlement runs such as the
time of settlement, the settlement period, the settlement
mode, or settlement units.

by SAP can also be modeled in the system. You use an SAP


business workflow or an executable program to combine individual settlement steps in such a way that you can execute the
appropriate settlement procedure.

Figure 35: Settlement Document


Figure 36: Workflow

Settlement Procedure
Every settlement run takes places according to a previously
defined settlement procedure. These procedures are divided
into individual settlement steps that you can process
sequentially or simultaneously. The synthetic and analytical
procedures, in accordance with the German Associations
Agreement Regarding Electric Energy, are already implemented
by SAP.
Adaptability and Extensibility
Settlement procedures are developed as building block systems.
They consist of a number of individual settlement steps. Settlement steps are the smallest units (algorithmically meaningful)
from which a settlement procedure can be assembled. Settlement steps model settlement algorithms and can link input
parameters (profiles and single values) and calculate output
parameters. The implementation of settlement steps is objectoriented and can be easily modified according to changes to
your requirements. An implementation can be used more than
once in different contexts. You can also develop other settlement steps. Therefore, settlement steps that are not provided
68

The settlement procedures provided by SAP are preconfigured.


You can, however, make changes to them at any time.
Data Retrieval
You can send settlement results to the appropriate market participant (supplier, settlement coordinator) using a variety of
data formats (EDIFACT, XML, and so on). You send the data
using the intercompany data exchange component, which
is fully integrated with the energy data management component.
Documenting and Logging Settlement Runs
Comprehensive documentation and logging tools are available
for settlement runs. You can view the status of a full settlement run or individual settlement steps at any time. The
required runtime for each settlement step is specified at all
times. You can use a graphical tool to determine which settlement steps have already been run as well as the status of each
step (successful, terminated, and so on). These documentation

and logging tools ensure that the status of the settlement


procedure and the processes within it are as clearly structured
as possible. The tools also provide extensive information concerning the data that has previously been sent to other market
participants.
Exception Handling
Unsuccessfully or inadequately processed settlement steps
(due to missing or incorrect input data, for example) can trigger exception handling in every settlement step. Exceptions
(also called alerts) are issued either as warnings or as error
messages. Warnings provide you with information. It may,
however, be necessary for you to confirm the exception. Error
messages, on the other hand, lead to termination of the settlement run. Each exception can have an individual response in
the form of additional processing such as an e-mail notification to you, or an SAP business workflow.

settlement procedure is allocated to a settlement view. This


means that, for each settlement view, you can use a different
group of points of delivery for the settlement units.
Data Selection
The allocated points of delivery for each settlement unit are
first determined for settlement. The following selections take
place for each point of delivery:
Selection of all load shapes
Selection of all synthetic profiles (in particular the usage
factors for each installation)

Settlement Units
A settlement unit is an object in the mySAP Utilities system
that corresponds to a settlement area. Since different terms are
used in different German-speaking countries, SAP uses the
neutral term settlement units. Settlement units allow you to
control which consumption values are selected for settlement.
As a result of settlement, one profile (with consumption values
for each interval) is created for every settlement unit within
the settlement period. You can create a sub-settlement unit by
allocating a settlement unit to a higher-level settlement unit.
You can do this for collective settlement. Settlement is then
executed depending on the higher-level settlement unit.

You can allocate the points of delivery to the corresponding


supplier (to the day) using the services that belong to a point
of delivery or using the existing energy supply contracts. All
energy withdrawals that belong to a supplier are collected in
the settlement unit of the corresponding supplier. To the day
proration of the service provider is taken into account for the
point of delivery during processes such as change of supplier,
move-in, move-out, and so on. In the same way, the current
and the estimated annual consumption values are updated
in the form of consumption factors for every time interval
customers are billed using synthetic load profiles. This allows
you to determine, to the day and for any point in time, which
supplier is responsible for supplying energy. You can use the
points of delivery to determine the corresponding load shapes
and consumption values of interval customers and to update
them in the settlement unit. This is the case in a settlement
when the current status of the data is accessed using the
described procedures.

Settlement Views
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. You can then process
and settle the individual settlement views completely independently from the others. Every settlement unit and every

Taking Grids into Account


You can also include grids during settlement. You can divide
a distributors grid into several grids if, for example, the distribution grid covers transmission grids that belong to different
transmission companies. During settlement, you handle each
part of the distribution grid that lies within a transmission grid
as a separate grid. This allows you to use settlement procedures
that not only calculate the settlement results for each settlement unit but also for each grid.

69

Schedule Management
Suppliers can use the settlement workbench to create schedules
and send them to settlement coordinators. This process involves the technical infrastructure described in the section on
settlement procedures. Schedules are created in a series of individual steps ending when they are sent to the settlement coordinator. You can fully automate this process. If necessary, you
can also create and send schedules to subordinate distributors.
When creating schedules, mySAP Utilities uses the synthetic
profiles to determine the energy feeding volumes to be supplied to non-interval customers. The profiles are valuated
along with the estimated usage factors. For interval customers,
the system can create basic consumption forecasts itself or it
can use load forecasts from external forecasting systems.
SOLUTION BENEFITS

Implementing energy data management offers you a wide


range of advantages:
Scalability and the ability to create parallels
Utility companies of all sizes, from small municipal companies to multinational conglomerates, can benefit from
energy data management. As a result, the scope of the EDM
component can change according to each companys needs.
On the one hand, these refer to the amount of data that
needs to be stored, and on the other hand, to the processing
speed at which the business processes are to be executed.
The EDM data storage system can manage data ranging from
as little as a few megabytes to as much as several terabytes.
Business processes that process mass data and therefore requires high processing speeds can be processed in parallel.
This technology allows the energy data management component to scale according to your companys requirements.
As a result, EDM is the ideal solution for utility companies in
dynamic energy markets that are characterized by mergers,
takeovers, cooperation, and so on.

70

Open system architecture


For many companies, energy data management is the central
point for all primary energy profiles (such as load shapes and
load profiles) and all secondary, energy-relevant profiles
(such as spot prices and conversion factors). Since external
systems also provide data for, or require data from energy
data management, mySAP Utilities has an open system architecture and defined interfaces to external systems. These
interfaces allow you to integrate old and new solutions, SAP
and non-SAP solutions, as well as internal and external areas
in a single, comprehensible system landscape.
Integration
Energy data management is fully integrated with all mySAP
Utilities applications as well as with a variety of other
mySAP.com components. High-maintenance interfaces are
not used within mySAP Utilities. Integration takes place
within the application at the level of data storage, graphical
user interface, and processing of business processes. This
interface-free integration provides a range of time and cost
benefits, not only during product launch and implementation but also throughout the entire product life cycle. Moreover, you can also integrate non-SAP applications into the
system landscape using defined interfaces.
Global support
Energy companies that operate in more than one country
can use energy data management to implement a single
corporate strategy. Energy suppliers with customers and
partners in different countries can benefit from the international capabilities of the system to gain a crucial competitive
advantage.

CONTRACT BILLING
Contract billing is a central component of mySAP Utilities.
It enables you to bill for your companys utility services and
other services. The central billing program enables you to map
all possible combinations of billing steps. Dynamic rate determination allows you to quickly adjust complete customer
groups to new rates in the company. Contract billing provides
you with a variety of billing procedures as well as number of
selection and control options. The billing component supports
the following basic functions:
Billing of residential and non-residential customers with
user-defined periods
Flexible billing cycles (daily, weekly, monthly, quarterly,
twice a year)
Billing different divisions
Cross-contract billing
Numerous billing procedures
Billing simulations

Meter reading
order creation

Meter reading
order entry

Plausibility check for billing documents


Parallel processing and monitoring of mass runs
In addition to these basic functions, you can also use a number
of extra functions:
Outsorting
Reversal
Lock periods
Manual billing
Billing public lighting units and small power producers
Contract billing also enables you to map rate models, such
as real-time pricing, in deregulated markets.
Contract billing is based on meter reading data from the
meter reading (IS-U-DM-MR) component. The billing events
are transferred to the invoicing (IS-U-IN) component.

Billing

Billing order

Billing order

Meter reading
order

Plausible
meter reading
results

Invoicing

Billing document

Bill print

Print document

Correction of
meter reading
results

Implausible
meter reading
results

Figure 37: Billing Workflow

71

BILLING PROCEDURE

The billing procedure uses meter reading results or load profiles to determine the valuation basis for the execution of
schemas. Schemas are structures that define the sequence
in which variant programs (calculation/processing steps) are
executed. All arithmetic operations required to map rates are
run when a schema is executed. Different billing periods are
included in the different billing procedures. All master data
and billing data can change during a billing period. The billing
component ensures that any billing-relevant changes that
occur in a billing period are included in the procedure. If a
price changes, for example, the total period is divided into partial periods and each partial period is allocated the relevant
price for that time. At the same time, total consumption is also
divided up so that each partial amount can be calculated. A
particular strength of billing in mySAP Utilities is the ability
to process all known period types using different billing procedures:
Periodic billing periods are current billing periods that are
normally triggered by a meter reading, and whose time periods are defined in scheduling. You can use periodic billing
to create additional periods:
Correction periods: Correct periodic billing periods that
have already been billed (during period-end billing and
backbilling).
Advance billing periods: You can use these, for example,
to create a budget billing plan for the future.
Simulation periods: You can create these for any period in
the past, present, or future. The results can be saved in the
periodic billing document as informative lines or billing
lines relevant for posting. For example, you can display the
consumption values for a calendar year in every monthly
periodic billing period on your customers bills.
The
periodic billing period can also be a period-end billing

period in which you can execute year-end final billing.

out, when a contract is terminated, or when a service territory is transferred. You can combine different billing periods
and, as a result, different billing procedures. Dynamic period
control offers you the greatest flexibility when billing different
periods. You can simultaneously bill periodic, correction, simulation, and/or advance billing periods in a dynamic billing
schema.
Backbilling and Period-End Billing
Billing non-residential customers is based on measured demand.
Often, periodic billing periods that have already been billed
have to be changed. For example, whenever a new demand
peak occurs, a correction bill is executed using the current
average of the three peak demand values. You can select the
following criteria for this correction:

10 kW
Month 01

72

15 kW

10 kW

20 kW

20 kW

20 kW

25 kW

25 kW

25 kW

2 * 15 kW

Month 03

25 kW

3 * 20 kW

09

11

Month 04

Figure 38: Floating Backbilling over n Periods

.........

01

Unplanned interim billing can be executed for some billing


procedures. This can be done, for example, at the customers
request. You can execute final billing when a customer moves

15 kW
Month 02

02

03

04

05

Figure 39: Period-End Billing

06

07

08

10

12

13

Floating backbilling
Backbilling takes place within a fixed backbilling period,
for example, always in the calendar year.
Backbilling over n periods
You must enter the number of periods for the backbilling
period. This type of backbilling continuously moves the correction period so that the last three months are always corrected.
You can also use the period-end billing function to execute
calculations for several periodic billing periods (for example,
monthly) by creating a period-end billing schema. You can, for
example, use the total annual consumption to grant a scaled,
quantity-based discount. Period-end billing and backbilling can
be combined.

Dynamic Period Control


Dynamic period control allows you to manage any number
of correction and periodic billing periods. You can generate
billing documents based on estimated meter readings. The
meter reading results can be estimated using functions from
meter reading and stored in the database. Alternatively, they
can be generated during billing runtime. Entering an actual
meter reading result, at any time, triggers dynamic backbilling
to the last actual meter reading result. As a result, all billing
periods that are based on estimated meter reading results are
corrected accordingly.
Dynamic period control allows flexible billing in deregulated
scenarios where actual meter reading results are no longer
available in grids set by scheduling, but are transferred

MR0
MR1

Billing based on real meter reading results


Invoicing billing documents

MR0

123
MR1

Monthly billing based on estimated meter reading results - start


Monthly invoicing of billing documents - start

MR0

123

120

118

133

112
MR1

Monthly billing based on estimated meter reading results


Monthly invoicing of billing documents

MR0

123

Billing based on real meter reading results


Invoicing billing documents

120

118

133

112

117
MR1

Figure 40: Dynamic Period Control

73

between utility companies whenever they are needed. In the


billing schema, individual correction periods can be created
using the time slice generator. This enables you to backbill the
consumption prices in a billing document, without changing
the fixed lease price. You can define which steps are to be executed for actual meter reading results, and which are to be
used for estimated meter reading results. You can also choose
whether you want the whole correction period or just the
individual partial correction periods to be corrected. Advance
billing is also possible and can be backbilled. In dynamic period
control, you can use a simulated period to generate extrapolated, posting-relevant billing lines, or informatory lines in the

billing document. You can then correct these lines by


backbilling them. This allows you to display any number
of extrapolation periods on your customers bills.
Real-Time Pricing Billing
Billing based on interval data (for example, load profiles
measured in 1/4h intervals) can be executed using the realtime pricing (RTP) interface. You can manage the interval
data as profiles in the Energy Data Repository from energy
data management.

KW
60

30

10

Block 1
Price A

Block 2
Price B

Block 3
Price C

Example for time-of-use pricing


Different prices dependent on timeblocks such as time of day, day type
(weekday, weekend) or season type (summer, winter)

Figure 41: Example for Time-of-Use Pricing

74

Block 4
Price D

Block 5
Price E

Block 6
Price F

Seasonal aspects, such as different on- and off-peak rates for

The following are examples of billing procedures based on


a measured load profile:
Time-of-use billing
Consumption measured in intervals is added together and
evaluated.
Real-time pricing
Consumption measured in intervals is valuated with a price
that is valid for each interval.

summer and winter


Calendar aspects, such as different on- and off-peak rates for
working days, Sundays, and public holidays
Consumption aspects, such as valuating measured consumption portions in combination with consumption or demand
limits.
By using the RTP interface, you can model agreements with
special customers or customer groups at short notice. These
agreements can contain particular billing rules, such as individual prices. The RTP interface is an integral part of the bill-

The RTP interface provides you with flexible options for structuring rates for your non-residential and major customers.
You can select several aspects, including:

Spot price
KW
60

Measured
load shape
30

10

00:00

12:00

24:00
t = 15 min

Oct 5, 2000

Oct 6, 2000

Agreed Price

Example for real-time pricing


A new price every 15 minutes
Consumption within the agreed reference quantity (light-blue) = agreed price
Consumption outside the agreed reference quantity (blue) = spot price

Figure 42: Example for Real-Time Pricing

75

ing master data used for contract accounting. It allows you


to access directly the profiles managed in energy data management (for example, load profiles of customers to be billed).
The RTP interface also uses event parameters to supply the
billing schema with data relevant for bill creation. On-peak
rate/off-peak rate billing of non-residential customers is executed based on a load profile measurement. The measured

load profile is managed in mySAP Utilities/EDM. Billing is


carried out using an RTP interface allocated to the rate. The
measured load profile is processed in the RTP interface. The
profile is divided into a portion for the on-peak rate periods
and off-peak rate periods. Result functions calculate the total
values for the on-peak and off-peak portions. Once this has
been done, the values can be billed.

Meas.
inputprofile
kW/kWh
Offpeak

Onpeak

Offpeak

Onpeak

Resultprofile
Off-peak
Consmp.

Virtual
profile
Offpeak

Offpeak

Virtual
profile
Onpeak

Figure 43: Example of How an RTP Interface Works

76

Result
function

Offpeak

Resultprofile
On-peak
Consmp.

Offpeak

Onpeak

Result
parameter

Off-Pk cons.
kWh = 275
mySAP
Utilities
Business
Intelligence
Rate facts

Result
function

Result
parameter

On-Pk cons.
kWh = 500

BILLING DIVISIONS

Contract billing enables you to bill different divisions in one


contract account. The divisions are mapped at the contract
level. In addition to the basic functions, you can also use division-specific functions.

Gas procedure

Individual settings

Electricity
During electricity billing, the measured meter reading differences are converted into consumption values. Register factors
and billing factors are included in this process. When changes
are made to the billing master data using standard and customer-weighting rules, electricity billing enables you to divide
up consumption values (for example, for price changes) when
the actual meter reading results are not available. There are
particular functions in activity-based electricity billing (preprocessing demand), that, for example, calculate the average of
demand peak values, or allocate demands to a particular season. Based on the settings that have been selected, the n peaks
per billing month or per season are identified and the system
calculates the average. You can determine whether all peaks
should come from the same months, or whether they have to
come from different months. Preprocessing demand during
period-end billing and backbilling ensures that demand data is
transferred between the periodic billing periods and correction
periods. This means that correction periods can be backbilled
using the current peak average.

Individual settings

Calorific value procedure

Vol. correction factor


procedure

Determined calorific value


Arithmetic average creation
Weighted average

Fixed-volume correction factor


Determined vol. correction factor
Special procedure

Figure 44: Gas Procedure

Gas
In gas billing, meter reading and billing dimensions are normally different. Therefore, the amounts must be converted so
that the energy contained in gas can be calculated from the
measured volume. In the gas procedure, you can determine
the following types of billing:
Volumetric
Based on standard volumes
Thermal
The gas procedure combines the volume correction factor procedure and the calorific value procedure.

77

In the volume correction factor procedure, you determine


the physical variables (temperature, pressure, atmospheric
pressure, and compressibility) used for converting the measured volume into a standard volume. If, for example, a device
already includes temperature, the temperature does not have
to be entered in the volume correction factor calculation. You
can also include special influences in the volume correction
factor such as temperature changes due to a change in gas
pressure (the Joule Thomson Effect). You can also map different volume correction factor relationships, such as:
Transmitting the volume correction factor from one device
to another
Calculating the volume correction factor from the consumption values of two devices, where one device measures
standard volume and the other measures operating volume
In the calorific value procedure, the standard volume is
converted to energy.
You can store the physical influences as daily or monthly
values or as an annual value in the system. In the volume
correction factor procedure and the calorific value procedure,
you define how these factors are entered in the gas billing
procedure. For example, you can make calculations using
monthly calorific values. During this process, gas consumption
is divided up among the months in the billing period and
valuated with each monthly calorific value. Alternatively,
you calculate the arithmetic or weighted average and valuate
the total consumption of the billing period using this average
value.

78

Water and Waste Water


When billing water and waste water, you can map special cases
that occur specifically in these divisions. These can include:
Flat-rate subsidy and deduction amounts
Calculated subsidy and deduction amounts
Primary and secondary meter relationships
Combination billing
District Heating
In district heating, measuring processes differ according to the
heat carrier that has to be measured (for example, steam and
hot water). As a result, you can bill different measured physical
variables. In district heating billing, you can differentiate between weight (for example, tons), volume (for example, cubic
meters) or heat quantities (megawatt hours). These variables
can also be converted.
Other Divisions (Cable Television, Radio, Multimedia)
The flexible and universal basis of contract accounting allows
you to bill for non-utility divisions, such as cable television,
radio, and similar services. A flat-rate amount request normally forms the basis of this kind of billing, although measured
variables can also be billed.
SPECIAL BILLING FUNCTIONS

Multiple Contract Billing


Multiple contract billing allows the system to group together
contracts for billing purposes, such as for chain store customers and outline contract customers. An outline contract is
between a distributor that owns a grid to which the customer
is connected, and the customers supplier. There are three
different forms of multiple contract billing:
Purchasing communities receive a collective rate that enables
them to be billed with a lower price.

Collective zones are created. Once the meters have been read

BILLING MASTER DATA

for all individual contracts, and before they have been billed,
the total consumption is determined and used for the individual billing procedures.
In bonus calculation, all individual contracts are billed using
a temporary, scaled discount that is based on an assumed
total consumption. Once all contracts have been billed, any
changes required are made to the temporary percentage
scaled discount based on the actual total consumption.

Billing master data controls contract billing. This master data


stores the rate structures that contain your companys billing
rules and the contractual provisions.

Lighting Units
In contract billing, you can also use the following functions
to bill public lighting units (electricity/gas):
Managing lights individually or as a group
Connection loads
These can be differentiated according to operation types.
Billing using energy prices
Consumption can be measured or calculated. A burning
hour calendar containing the daily or monthly lighting
times of all units can be used to calculate consumption.
Billing using demand prices
The system determines demand from the connection loads,
and uses it for valuation.
Small Power Producers
In addition to large-scale suppliers of utility companies, there
are also a large number of smaller generation companies, such
as water, wind, and solar power plants. These are grouped
together under the term small power producers. The energy
purchase of a utility company is billed using similar criteria to
energy supply.

Rates
The rate is an important element of billing. It contains variant
programs that are executed sequentially in rate steps. Variant
programs determine how billing-related quantities (such as
measured consumption or demand) are processed and valuated. When defining a rate, you select the appropriate variant
programs and specify the sequence in which they are to run.
There are approximately 200 preset variant programs available,
including:
Valuate quantities or demand with a price
Multiply or divide with factors
Discounts on prices, consumption quantities, and amounts
Flat-rate billing
Rental price billing
IF-, ELSE-, ENDIF conditions
You can also create customized variant programs.
Rates define the following:
How meter reading results and consumption values are
extrapolated and prorated
Which prices are used
Which reference values are billed
Which constants, factors, and variables are included in the
calculation

79

The general ledger accounts to which the results of the cal-

How the time portions of the periods to be billed are calcu-

culations (billing line items) are posted


How the billing line items are handled statistically

lated (to the day or on a monthly basis)


The divisions and billing classes to which the rate is allocated

Installation

Installation struct.

Rate type

Rate cat.

For
example

Rate determ.

Operands
Demands
Prices
...

Rates
VarProg

Rate type

Rate cat.

Rate

Off-peak

Normal

Rate 1

On-peak

Normal

Rate 2

Operand values

Billing schema
Rate 1
Step 1
Step 2
Rate 2
Step 1

Figure 45: Master Data in Contract Billing

80

Variant program
For example,
Quantity x Price
Comp. 2 demands

Operand values
1000kWh, 0,25$
400kW, 300kW

Rate Categories
Rate categories contain data that controls the billing of multiple rates. Rate categories can do the following:
Define which billing schema is used
Control period-end billing and floating backbilling
Define the outsorting checks
Define which data relevant to billing is used at rate category
level (for example, quantities, demand values, prices, or
flat-rates agreed upon between the utility company and
customers)

Discounts and Surcharges


You can define discounts and surcharges as percentages or
as absolute values. They can relate to a quantity, a price, a
demand value, or an amount. You have flexible control over
the application of surcharges and granting discounts. Discounts
and surcharges can apply to several contracts (for example, for
one rate), or you can structure them individually for individual contracts. All discounts and surcharges appear as separate
billing line items in the document and can be displayed separately on the bill.

In some cases, you can override data by making individual


entries in the installation facts at installation level.

EXTRAPOLATION/STATISTICAL FUNCTIONS

Operands
Operands function as input and output parameters for the
variant programs. The operands are allocated values, such as,
prices, discounts, or surcharges, while the billing program
is running.
Prices
Prices are allocated to the following four price categories:
Quantity-dependent prices
Time-dependent prices
Rental prices, for example, for renting devices and meters
Flat rates

Simulation
Billing can be simulated. During this process, simulation billing documents are generated that can also undergo simulated
invoicing. The system executes mass simulation for a large
number of installations. This produces an evaluation basis
of periods that have not yet been billed for unbilled revenue
reporting or for sales statistics. The overall check checks if a
new billing structure can be billed. You can also use this function for a move-in. The overall check alerts you to errors in
device structures of the installation, missing billing master
data, missing rate determination data, and so on.

You can enter special rounding rules and price adjustment


clauses that control the price adjustment factor for all prices.
You determine the current price by multiplying this factor by
the base price, or adding it to the base price. You can define
additional zones or scales for quantity and time-dependent
prices. Zones for quantity-dependent prices can be adjusted to
each billing period.

81

Sales Statistics
The quantities and revenues that belong to a billing document
can be transferred to the SAP Business Information Warehouse
(SAP BW) and profitability management (CO-PA). You can
individually update billing document data:
You can determine the criteria that differentiate the billing
document data (rate category, voltage level, portion, and
so on).
You can define which key figures are to be used to update
the consumption values (on-peak, off-peak) and the
revenues (on-peak or off-peak energy price, basic price)

Consumption Statistics (for Customer Relationship


Management)
In mySAP Customer Relationship Management (mySAP CRM),
you can create consumption statistics if the correct variants for
writing the consumption history are used in the billing schema.
Consumption values for billed periods and simulated consumption values for periods that have not yet been billed can be
transferred directly to SAP BW. This consumption data can
then be used as a basis for different kinds of evaluations such as
selecting target groups for CRM campaigns.
ADDITIONAL FUNCTIONS

The quantities and revenues are divided among the consumption months during the update.
Unbilled Revenue Reporting
The update of quantities and revenues described in the previous section only affects the actual data of real billing documents (not simulated). Unbilled revenue reporting, however,
requires estimated values for not only billed revenues for a preset period, but also for revenues that have not yet been billed.
You can estimate revenues that have not yet been billed in the
flat-rate procedure using the functions from CO-PA, and by
extrapolating the actual data. This kind of estimation is usually
relatively inaccurate. As a result, SAP allows you to simulate all
contracts for the period that have not yet been billed using the
mass simulation function in the individual procedure. You can
also directly update simulation data to SAP BW or CO-PA in
mass simulation.

82

Outsorting
Outsorting is a procedure whereby a document is placed on an
exception list if it has failed validation during billing or invoicing. You must check and, if necessary, release each outsorted
document. Outsorting test functions prevent automatically
generated billing documents from being invoiced before they
have been checked. These functions check the plausibility of
billing documents (such as documents with a billing amount
over 1,000). Implausible billing documents are written into a
list of exceptions and automatically locked to prevent further
processing. Incorrect bills are, therefore, not sent. The agents
responsible can then work through the list of exceptions. In
work management, there are workflows that distribute tasks
among different agents. The backlog reduction engine also
enables the system to automatically correct any errors.

Backlog Reduction Engine


The backlog reduction engine systematically evaluates and
processes application logs. This function has the following
options:
Periodic extraction of entries from all billing run logs
Automatic processing of all extracts
Inbox for agents (automatic allocation of log entries to be
processed manually)
You can store both automatic and manual solutions in the
solution database. This capability is particularly useful in
phases where errors frequently occur (such as in migration).
Parallel Processing and Monitoring Mass Runs
When dealing with large numbers of contracts, you can execute billing and billing simulation in parallel processes. The
following parameters can be defined for parallel mass runs
using this function:
Number of parallel processes
Number or size of intervals of the billing orders to be
processed
Computer and number of processes allocated to an agent
Intervals are evenly allocated to every process during a parallel
mass run. All processes are distributed among different computers and started at the same time. This considerably reduces
the total processing time.

Monitoring mass runs valuates the results of parallel mass


billing runs in application logs. It supports the following activities:
Displaying application logs
Generating result statistics
Grouping application logs according to individual objects
(such as, according to installations)
Direct navigation to an object relevant to the log
Reprocessing incorrect or outsorted bills, for example,
using workflows, instructions for technical personnel
(service reports/orders), or problem management with case
management.
Lock Periods
When a utility installation or accompanying device is locked,
you can include the lock period in the bill. Billing-relevant
lock periods can be handled separately in billing. Schema steps
are marked as lock-relevant in the billing schema. If, for example, a schema contains a step for determining the basic price,
the basic price is not included when an installation is billed for
the locked period.
Reversal
Incorrect billing documents in a contract account can be cancelled using billing reversal. If several billing documents have
already been invoiced, but only one of them is wrong, you can
execute adjustment reversal just for the incorrect billing document. The resulting difference is then calculated in the next
billing procedure.

83

Manual Billing
Manual billing enables you to create manual billing documents in addition to automatic billing documents. These
manual documents can contain a credit memo or backbilling.
Either manual billing documents can be sent to customers as
individual bills or they can be included in the next periodic bill.
Manual billing supports the following activities:
Valuation of amounts and demand
Processing zone, scale, and gross prices
Processing billing orders
Rate determination
Transfer of current meter reading results to manual billing
Messages to customers about individual lines
Calculation of franchise fee
Data transfer from documents that already exist
Correction function for automatic documents
Tax simulation
Approval procedure via workflow connection
ARCHIVING

You can archive billing documents and always have access


to them:
Documents that are no longer needed online are deleted
from the database and written to archive files.
Archived documents can be displayed at any time.
You can upload archived documents again.

84

SOLUTION BENEFITS

Contract billing in mySAP Utilities offers you a wide range


of advantages.
The modular design of billing offers:
A more flexible rate structure
Simple implementation of different (for example, legal)
requirements
Easier rate-changing process
New requirements of deregulated markets are already
integrated:
Chain store customers and multiple-contract billing
Complex billing procedures based on load profiles
Operating costs are lower as a result of increased efficiency
and seamless integration with other SAP components and
mySAP.com solutions
Considerable savings are gained by automating many routine
tasks
The transparency and simple structure of the activities automatically improve customer service

INVOICING
The invoicing capabilities provided by mySAP Utilities can
be used to prepare bills in connection with contract billing.
It connects mySAP Utilities with the contract accounts receivable and payable module (FI-CA). It integrates subledger
accounting in mySAP Utilities, processes the mass data produced by contract billing, and is used to print bills. Invoicing
is responsible for a number of tasks:
Processes billing documents that have the following origins:
mySAP Utilities contract billing
Billing from the sales and distribution component (SD)
(sales, installation)
External billing
Posts documents to contract accounts receivable and payable
Clears billing requests with posting items, particularly any
budget billing payments made
Creates print documents and prints bills
Supports reversal processes
Contains automatic bill checks
Manages budget billing plans and provides functions for
maintaining budget billing amounts
Supports determination and collection of taxes, charges,
and duties
During bill preparation, invoicing supports additional
functions from contract accounts receivable and payable
such as:
Interest calculation
Dunning
Blocking
Account maintenance
Invoicing processes can be executed using individual processing
and mass processing (parallel processing). The system supports
appropriate portioning of the dataset to be invoiced in order to

External
billing

SD billing
sales, installation

IS-U billing
supply

Billing documents
Credit memos
Backbillings
Basis for budget
billing plans

Billing documents

Invoicing
Budget
billing
amounts
Accounting
documents

Open
items

FI-CA

Budget billing requests


Payment forms
Bills

Printer

Figure 46: Invoicing Processes

optimize transaction run-times. The processes involved are


divided automatically for processing. This applies particularly
to processes for bill preparation, bill reversal, and bill printing.
Invoicing can only take place if billing documents (such as
periodic billing documents, credit memos, and backbilling)
have been created and forwarded successfully from contract
billing. Billing documents are used as a basis for creating
budget billing plans. Invoicing produces the following:
Bill requests and credit memos that are processed further
in contract accounts receivable and payable
Additional postings in contract accounts receivable and
payable, such as clearing postings, interest documents,
and so on
Print documents as the basis for printing bills
Bill sent to the bill-to party

85

BILL PREPARATION

Bills are prepared for contracts in a contract account. You


can invoice billing documents for selected contracts and create
bills based on consumption:
You can prepare (partial) bills for budget billing plans.
You can also create collective bills based on consumption
and partial bills.
Documents from SD billing can be included when preparing
bills in mySAP Utilities. Various bill preparation processes that
allow individual or (parallel) mass processing are available. All
of these processes can also be executed as a simulation run.
Contract accounts to be processed can be selected using various criteria during bill preparation. If billing orders for billing
documents in the contract account selected are available, the
system generates a bill based on consumption. Billing documents are transferred to an accounting document in contract
accounts receivable and payable. Data from specific billing documents is summarized here using defined criteria in contract
accounts receivable and payable and additional company-specific controls. Budget billing payments made or budget billing
requests are taken into account automatically according to the

billing procedure used and are cleared by receivables from


the billing documents. New budget billing plans are created
automatically for the next budget billing period. During
bill preparation for budget billing plans, partial bills can be
generated in contract accounts receivable and payable. Budget
billing amounts that do not affect contract accounts receivable
and payable can also be requested. A print document that contains the information required to print the bill and that forms
the basis for bill printing is usually generated for each bill
created. It contains general data such as the creation date,
creation reason, document date, and so on. It also contains bill
print lines that provide information from the billing documents, bill preparation process, account balances, and budget
billing plan items. These document lines are characterized by
their document line type and can be selected accordingly during bill printing. You can usually connect bill preparation to a
contract account by specifying a reason and a validity period.
Basic Functions
A number of basic functions are performed during bill preparation that can be modified to meet the particular requirements of your company.

Account
determination

Tax/charge
determination

Bill
preparation

Budget billing
processing

Invoicing
Due date
determination

Payment form
reference

Determination
of
payment method

Figure 47: Basic Invoicing Functions

86

Final bill
amount

Billing documents or budget billing items are combined as


invoicing units so that they can be invoiced collectively and
displayed on a bill. This means that a bill can contain crossdivisional information on various contracts.
You can control the grouping proposed by the system for
creating the invoicing unit by defining contracts in a contract
account as follows:
Contracts whose documents must be invoiced collectively
or that have a common budget billing plan. Billing or budget
billing amounts due for these contracts should always appear
collectively on a bill (for example, contracts for a residential
customer for electricity, gas, and water).
Contracts whose documents are invoiced collectively or
whose budget billing plan items are to be requested collectively.
Contracts whose documents are to be invoiced separately
or whose budget billing amounts are to be requested on
separate bills.

CONTRACT ACCOUNT

BILLING

Contract 1
Mandatory contract

Document 1

Contract 2
Mandatory contract

No document
exists yet

You can make company-specific adjustments to the grouping


proposed by the system.
Various transactions from contract accounts receivable and
payable are used during invoicing. Specific internal transactions that control the program flow are used during bill
preparation. These document the aspect of the business transaction or business process on which the posting of a document
item is based. In conjunction with the company code, division
and account determination characteristics that are determined from the contract or contract account, these transactions control automatic determination of general ledger (G/L)
accounts. Receivables accounts are determined using main
transactions exclusively. Subtransactions that are provided
from billing are involved in the determination of revenue
accounts (see also Chapter 7, Contract Accounts Receivable and
Payable). Corresponding controlling (CO) additional account
assignments are assigned to posting items from invoicing so
that invoiced quantities and revenues can be transferred to the

INVOICING

No document as
Contract 2 is also
a mandatory contract

Contract 3
Mandatory contract

Document 3

Contract 4
Optional contract

Document 4

Document A

Bill

Contract 5
Cannot contract

Document 5

Document B

Bill

Figure 48: Sample Grouping for the Invoicing Unit

87

controlling component (CO). These are determined during


contract billing. The CO additional account assignment is
determined from information in the contract, account determination, or from the standard account assignment for the
cost type. CO account assignment keys that encode the valid
combination of CO additional account assignments are assigned to the contract master record and account determination.
You can indicate whether the tax indicator and tax rate are
determined during contract billing or during bill preparation.
This determines whether tax rates that are valid during the
billing period with consumption proration are used or whether
the tax rate that is valid during invoicing is used. The final
bill amount is an amount that the customer receives as the
result of bill preparation on the bill or payment medium. The
(re) payment method is determined for this account during
invoicing. You can define the final bill amount by totaling
open receivable or credit memo amounts in the account.
You can also use your own payment method determination
procedure instead of the standard repayment method determination procedure. The system determines the bills due

date based on the final bill amount. You can also record your
own due date determination rules here according to the payment conditions used.
Currency-specific rounding (for instance in Switzerland)
and rounding of the final bill amount is supported during
bill preparation.
Additional Functions
A variety of additional functions can be activated during bill
preparation. Control of additional functions is dependent on
the invoicing process, the composition of the invoicing unit,
and the contract account.
Open items that are to be drawn to the customers attention
on the bill can printed on the bill as sub-items. This means
that if the last bill that has not yet been paid; this can be printed on the current bill as a reminder. Automatic account maintenance that is integrated in invoicing is used to clear document items posted during invoicing with other open items

Account
maintenance

Item selection

Clearing
control

Invoicing
block
Invoicing

Interest
calculation

Due date
adjustment

Debit entries

Figure 49: Additional Invoicing Functions

88

Dunning

in the contract account. This means that you can define the
following:
Clearing with the first budget billing amount
Clearing of cash security deposits in the final bill
Clearing of payments on account

The due date adjustment function can be used to inform the


customer about other posting transactions and to obtain payment for these with the next bill. The due date in contract
accounting documents that have been posted is synchronized
with the due date for the bill during invoicing.

Clearing postings that result from account maintenance are


posted to a separate posting document that represents part of
the print document. The following contract accounts receivable and payable functions can also be executed:
Interest can be calculated for open receivables and cash
security deposits for the contract account.
Open due items for the contract account can be dunned.
Statistical items can be created as debit entries and cleared.
Statistical items can also be cleared without subsequent
postings.

BILLING REVERSAL

Flag old
document

Once the bill has been prepared, two options are available
to you for reversing it:
Invoicing reversal simply reverses the invoicing print
document. Billing documents are retained.
Full reversal reverses associated billing documents in
addition to the invoicing reversal.
Invoicing reversal reverses all steps that were performed during
bill preparation. Reversal documents from contract accounts

Reset due date


adjustment

Flag old
billing document

Create billing
order

Create reversal
document
Invoicing reversal,
full reversal, and
budget billing
request reversal
Delete new
budget billing plan

Reopen budget
billing item

Open old
budget billing plan

Invoicing reversal

billing reversal

Reset clearing
payments

Flag old document


and create reversal
document

Budget billing request reversal

Figure 50: Reversal Functions

89

receivable and payable are generated that reverse the bill requests or credit memos. Posting documents that have been
posted as clearing documents during invoicing or that were
created using additional invoicing functions are reversed. Data
required to print the reversal is prepared and a reversal print
document is generated. Budget billing plans and billing documents are processed and selected.
You can use the enhanced invoicing reversal function. This
automatically reverses clearing payments that have already
been made in response to the bill requests. Payments are then
posted as payments on account.

OK
Settlement

OK
Invoicing

Not OK

Bill printout

Not OK
Release

Reversal

Release

Reversal

Figure 51: Outsorting


BUDGET BILLING AMOUNTS

BILL PRINTOUT

This function is used to print or reprint bills. You can use


various criteria to select documents for printing and to print
bills, or transfer the print information to an external print
system. Bill printout has been designed as a mass process
(parallel processing) but can also be used to print or reprint
specific print documents. If necessary, shipping control that
is maintained in the contract account is taken into account
and an alternative bill-to party determined.
OUTSORTING

Bills that have been created automatically can be checked


before they are sent out. These automatic checks are performed during bill preparation and can be used to outsort
bills from automatic processing. Bills that have been outsorted
are placed in an exception list and must be checked by an agent
before they are sent out. Whoever checks these bills can either
reverse them or release them for printing.
You can save special plausibility checks in the system that are
performed during bill preparation. Bills that represent credit
memos can be outsorted. You can also record an outsorting
counter that determines the maximum manual outsorting
number. This means that the first two bills for a new non-residential customer can be outsorted so that you can check them
again before they are sent out.

90

If a utility company does not bill customers for its services


until the end of an annual billing period, as is the case during
annual consumption billing, this company can collect budget
billing amounts as payment for the anticipated bill amount to
be paid by the customer during the current period. However,
in the case of monthly billing , the utility company can negotiate with the customer which amount is to be paid with each
bill. The difference between the amount paid and the actual
bill amount is recorded and shown on a bill at a later stage.
These amounts and payment dates are recorded in a budget
billing plan that is used as the basis for collecting budget billing
amounts. Budget billing dates are either determined from the
portion valid for the contract and the associated parameter
record or are defined directly according to the budget billing
procedure used. You can define the following:
The length of the budget billing period (several months
or a year).
Budget billing frequency. This means that dates are distributed evenly across the period (one month or several
months).

You can also modify the dates calculated when you create the
budget billing plan. Automatic determination of budget billing
amounts is performed according to the budget billing procedure you have selected. It is based on the following information:
Calculations from the contract billing component. Automatic billing simulation with anticipated quantities and
services is used to extrapolate budget billing amounts for
the budget billing period.
Bill amounts from previous bills
Bill amounts and extrapolation amounts
Budget billing amounts can be modified on an individual basis
when you create the budget billing plan. You can also enter
budget billing amounts manually when you edit a budget
billing plan. Budget billing plans are usually created automatically during invoicing or a move-in, but they can also be
created manually. Budget billing amounts and the dates on
which these amounts are due can be modified in existing
budget billing plans. You can also set commercial blocks in
these plans such as a dunning or interest block. Any changes
are documented in change documents. Automatic changes
to budget billing amounts are supported according to the
budget billing procedure used. You can adjust budget billing
amounts automatically if price changes or other parameters
that are relevant to the budget billing amount are to be taken
into account. These amounts can also be adjusted automatically during interim billing rate maintenance.
Budget Billing Procedure
Various budget billing procedures are available that are primarily differentiated by budget billing dates and amounts,
management of budget billing data, and the posting procedure
used. The budget billing procedure is defined in the contract
account. The following billing procedures are available:
Statistical budget billing procedure
Partial bill procedure
Payment plan procedure
Payment scheme

The statistical budget billing procedure manages budget


billing due date data that is based on information in date
records and budget billing amounts that are derived from
extrapolation in the contract billing component in a budget
billing plan. This is created automatically when the annual
consumption bill is created. Budget billing plan items can be
displayed in the account balance display as statistical postings
immediately after the budget billing plan has been created.
Budget billing amounts can be requested in a separate letter
to the customer. G/L postings are not made until the budget
billing amount has been paid. For countries where value-added
tax (VAT) applies, the VAT is posted here. When the annual
consumption bill is created, budget billing amounts that have
been paid are reposted and displayed on the bill. This procedure is mainly used in Germany.
Like the statistical budget billing procedure, the partial bill
procedure manages budget billing due date data that is based
on information in date records and budget billing amounts
that are derived from extrapolation in the contract billing
component in a budget billing plan. In contrast to the statistical procedure, budget billing amounts are not visible in the
account balance display immediately after the budget billing
plan has been created. The budget billing amount receivable
and the VAT are not posted to the G/L account until the partial bill has been created. In contrast to the statistical procedure, the budget billing amount receivable cannot be settled
until the partial bill has been created. During invoicing, the
budget billing plan is deactivated and the partial bills are taken
into account when the final bill amount is determined regardless of whether they have been cleared. This procedure is used
in several countries such as Belgium, the Netherlands, Switzerland, Portugal, and Spain. It supports tax determination that is
required in these countries at the point of invoicing.

91

The utility company and customer come to a mutual agreement on the amount to be paid in each bill in the payment
plan. This allows the customer to replace the actual bill
amount that can be inconsistent because of seasonal consumption fluctuations with a fixed payment plan. The difference
between the amount paid and the actual bill amount is recorded and placed in the bill later. The following payment plan
procedures are available. These are principally differentiated
by the way in which budget billing amounts are determined:
BBP (budget billing plan) payment plan category
An average amount is determined for this payment plan
procedure that is calculated from billing for the last n
months. The customer pays this average amount for a
period of twelve months.
AMB (average monthly billing) payment plan category
The budget billing amount to be paid is determined again
each month if this payment plan procedure is used.
This is primarily used in North American countries that create
bills on a monthly basis.
The payment scheme is a budget billing procedure in which
the bill amount from the last consumption bill is copied into
the budget billing plan. The budget billing amount consists of
an extrapolation share and a share of the consumption bills
transferred. These transferred consumption billing documents
are not cleared directly by a payment but are only cleared by
individual budget billing payments. The payment scheme permits payments to be made at weekly, fortnightly, monthly,
quarterly, or annual intervals. This special procedure supports
country-specific requirements from the UK.

92

Special Functions
Migration objects are available that can be used to transfer
existing budget billing plans from your legacy system to
mySAP Utilities. If you are using the statistical budget billing
procedure, you can use the yearly advance payment function.
The yearly advance payment gives customers the opportunity to settle all budget billing items for the year in one payment.
In return for doing so, the utility company grants the customer a bonus. If you are using the statistical budget billing
procedure or the partial bill procedure, a function is available
to adapt budget billing plans automatically if billing dates are
changed. If the VAT is changed, existing budget billing amounts
can be changed automatically if you are using the statistical
budget billing procedure or the partial bill procedure. Billing
documents, print documents, and budget billing plans can be
archived:
Documents that are no longer required online are deleted
from the database and entered in archiving files.
Archived documents can be displayed at any time using the
corresponding standard transaction.
Archived data can be reloaded.
Standard transactions that can reverse documents or fundamentally change them take account of the current archiving
status of the document and it may no longer be possible to
execute these transactions.

COLLECTIVE BILL

The collective bill function is used to process contract accounts


collectively during bill preparation and ensures that contract
accounts in a collective bill continue to be regarded and processed collectively by subsequent business processes in contract
accounts receivable and payable. The collective bill function
has a variety of applications:
Property management companies
Housing associations
A utility company supplies tenants of a housing association.
The housing association manages payment transactions
(payments, dunning, returns, correspondence) for its
tenants with the utility company and bills the tenants.
However, tenants make payments for their bills through
the housing association.
Branch-head office relationships

SAMMLER INC.
Document 4711
Business partner
item 348.00

Stat.key.: S

A collective bill account is set up for the contract partner who


receives a collective bill and has also simultaneously defined
agreements with the utility company for managing payment
transactions for other business partners. Individual contract
accounts (single accounts) with the associated business partners are allocated to this collective bill account. To ensure that
the collective bill contract partner is able to manage business
transactions for individual contract partners, the system generates statistical postings in the collective bill account automatically if postings are made to the single accounts. This displays
a bill request that has been created by the total of all individual
bill amounts in the account balance of the collective bill
account. This receivable can be paid by the collective bill recipient. It can also be dunned, and interest can be calculated or
deducted. G/L postings are also made at individual account
level. A one-to-one relationship exists between individual post-

WINNIE CHUNG
Document 471200
Business partner
item 116.00

CBP doc. 4711


General ledger item
100.00
16.00

MARCUS ADAMS
Document 471300
Business partner
item 232.00

CBP doc. 4711


General ledger item
200.00
32.00

When you invoice contracts that are allocated to an individual account of a collective bill posting (CBP)
construct, statistical CBP documents are automatically generated for the collective invoice account.

Figure 52: Invoicing a Collective Bill

93

ing documents and the collective bill posting document for


business processes in contract accounts receivable and payable
for which a statistical collective bill posting document is created automatically. These business processes are as follows:
Post document
Create security deposits
Single processing for interest calculation
Interest run
During bill preparation however, several single documents
are combined as a statistical collective bill posting document.
When these single accounts are invoiced, the system generates
a statistical collective bill document parallel to creating single
documents.
Single bills are bundled in a separate process so that correspondence can be entered and sent to the collective bill contract
partner. This partner can be sent a collective bill cover sheet
during collective bill preparation with all associated single bills.
A collective bill print document is generated here.

94

SOLUTION BENEFITS

Invoicing in mySAP Utilities offers you the following


advantages:
High flexibility as a result of implementing various requirements (taxes, postings, and amount clearings).
You can use all common budget billing procedures available
worldwide.
New requirements of deregulated markets, such as crosscompany invoicing are already integrated in invoicing.
High levels of efficiency can reduce your operating costs.
Significant time savings can be made to routine activities
based on optimized runtimes.

CONTRACT ACCOUNTS RECEIVABLE AND PAYABLE


Contract accounts receivable and payable (FI-CA) is a type of
subledger accounting that is tailored towards the requirements
of industry sectors with multiple business partners and a large
number of documents for processing. To meet these demands,
FI-CA offers highly automated standard processes specialist
mechanisms to guarantee outstanding system performance
and optimized scalability. It also contains a range of functions
for managing processes that are particular to the utilities
industry. FI-CA is suitable for worldwide implementation. It
covers various statutory requirements (such as those that
relate to tax legislation and accounting principles) and country-specific processes (such as the management of payment
transactions).

BASIC FUNCTIONS

Document Principle
Postings are always saved in document format. The document
is a statement for each business transaction. Documents can
only be posted if the balance of the items they contain is zero.
A document consists of a document header and various document items:
The document header contains data that applies to all document items such as the document number, document date,
posting date, and document type. The document type classifies documents depending on which transaction they belong
to (for example, a payment from a collection agency, or a
customer payment).

Document header

Doc. Number:
Posting date:
Doc. type:
Currency:
Reconciliation key:
Reversed with:

010000234591
02/22/2002
F1
USD
TK2202200101
102345678

Business partner items

GPART
BUKRS
4711
U100
Clearing document:
Clearing reason:

Reversal

Doc. number:
Posting date:
Doc. type:
Currency:
Reconciliation key:
Reversal doc. for:

102345678
03/05/2002
S1
USD
TK05003200103
010000234591

Cleared items
Date
02/25/2002
102345678
05

Amount
230,00

GPART
4711

BUKRS
U100

Amount
230,00

Amount
200,00
30,00

BUKRS
U100
U100

G/L account
800000
175000

Amount
200,00
30,00

G/L and revenue account items

BUKRS
U100
U100

G/L account
800000
175000

Figure 53: Document Principle in FI-CA

95

Business partner items contain a reference to the business


partner and all data that is relevant to payment transactions
and dunning. They also contain the receivables or payables
account that was posted to the debit or credit side. Receivables to business partners are also known as receivables lines.
Revenue items contain data for profit and loss accounting
and sales tax information.
G/L account items contain the G/L account that is relevant
to the posting transaction (such as the cash receipts account
or tax account)
The following item types exist in contract accounts receivable
and payable:
Open items
Cleared items
Statistical items
Open items are receivables that have not yet been cleared. For
example, an invoice item is managed as an open item until it
has been paid in full and therefore cleared. The system records
a partial clearing for a partial payment.
In addition to documents that are updated in the general
ledger, you can enter statistical documents. These are simply
recorded in the subledger. They are used to enter noted items
for budget billing requests or dunning charges.
Account Determination
Each posting in FI-CA is defined by a business transaction that
consists of a main transaction and a subtransaction. The system uses business transactions in conjunction with additional
account assignment characteristics (such as the company code
and the division) to determine the relevant G/L and revenue
accounts and the corresponding credit/debit indicators automatically. Examples of business transactions include receivables
from consumption billing, charges from bank returns, and
other credit memos.

96

Business Blocks
The Contract Accounts Receivable and Payable component
in mySAP Utilities supports extensive automation of your
business process. However, there are situations in which this
is undesirable or where automatic processing should be
suspended. The system provides
a range of blocking options for these cases:
Dunning block
Payment block (for incoming and outgoing payments)
Interest block
Clearing block
Posting block
Blocks can be set manually or by triggering processes. In the
case of bank returns, a contract account can be blocked for
bank collection for a defined period. This allows you to gather
the facts of the situation, which can be clarified with the customer. You can also block collection to provide the customer
with written information on the next collection. Blocks can be
restricted to a specific period and can refer either to the entire
contract account or simply to selected documents. The system
records the user who has set the block, which is shown in the
blocking history.
Enhancement Concept
FI-CA offers maximum flexibility for adjustments to meet
your specific requirements. The system has been designed so
that customer-specific enhancements can be made to standard
functions that are retained in the event of an upgrade.
Interface Concept
FI-CA works in conjunction with invoicing in mySAP Utilities,
which ensures that the automatic transfer of the corresponding postings in FI-CA is possible. Postings from the sales and
distribution component (SD) can be transferred to FI-CA.
FI-CA can also be used to transfer data from external systems.
An intermediate document (IDoc) interface is available for

mass data transfer. This is used to transfer data efficiently


between an external billing system (EBS) and FI-CA. Therefore,
you can create the billing data in an EBS, transfer this data to
FI-CA, and post it as open items automatically. Optional additional information for profitability accounting and analysis can
also be transferred. Additional functions that are available to

you are the archive link transfer of optically archived bills and
mass reversal of documents.
In addition to the IDoc interface, a large number of Business
Application Programming Interfaces (BAPIs) are also available
for data transfer.

1
mySAP Utilities-CA
Rechnung
Rechnung
4711
Rechnung
4711
Bill
4711
4711

Doc. Nr.

0000815
0000816
0000817
0000818
0000819

xx.xx
xx.xx
xx.xx
xx.xx

Inv. Nr.

4709
4710
4711
4712
4713

CO-PA

Amount

xx.xx
xx.xx
xx.xx
xx.xx
xx.xx

Division Consumption Amount


Electricity
xxxx
xx.xx
Water
4709
xx.xx
Gas
4710
xx.xx

FI
External
billing
system

Account
880000
175000

Archive

Amount

xx.xx

mySAP Utilities-CA

Bill
4711

xx.xx

Doc. Nr.

0000815
0000816
0000817
0000818
0000819

Inv. Nr.

4709
4710
4711
4712
4713

Amount

xx.xx
xx.xx
storno
xx.xx
xx.xx

1. Open items to external billing system


2. Post FI-CA document and if neccesary update CO-PA
3. ArchiveLink to archived bills
4. Mass reversal

Figure 54: Interfaces with External Billing Systems

97

Workflow Connection
Contract accounts receivable and payable enables you to define
multistep processes for implementing approval or confirmation procedures (such as the dual-control principle). To do so,
FI-CA contains standard workflows for the following processes:
Post a document
Reverse a document
Modify a document (including mass changes)
Create an installment plan
Enter a repayment request
Release a document for payment
Flexible options for defining the situations in which a workflow is to be started, the approval levels to be run, addressees
and actions that are permitted up to final approval of the document are available. FI-CA functions have also been incorporated in the workflow for service connection order processing.
If a down payment is required for service connection order
management, the workflow waits for the corresponding
incoming payment for the down payment request. You can
also define additional workflows and trigger these at defined
points.
Performance Aspects
The utilities industry requires large volumes of data to be prepared and processed while the system is used by many users
simultaneously. Background processes can run in parallel in
FI-CA. This distributes system load and guarantees scalability
of contract accounts receivable and payable. FI-CA is also based
on streamlined data structures to reduce the database size to
the required minimum. FI-CA retains sufficient flexibility so
that you can add any additional fields required during system
configuration.

98

BUSINESS PROCESSES

The following describes the concepts behind the business


processes found in contract accounts receivable and payable.
Postings and Reversals
A document is generated for each posting (refer to the Document Principle in this chapter). Postings are usually generated
automatically by the corresponding business processes in FI-CA
or by invoicing. Additional options for automatic data transfer
are described in the Interface Concept in this chapter. Documents can also be posted manually. The account determination function can be used to determine G/L accounts automatically and to propose due dates using payment conditions in
the contract account. The following is a list of typical posting
documents found in utility companies:
Bills and credit memos
Dunning charges
Return charges
Interest
Cash security deposits
Incoming and outgoing payment postings including
payments on account and down payments
Budget billing amounts
These are postings resulting from a budget billing plan.
Additional information on budget billing amounts is available in Chapter 6, Invoicing.
Cross-company code postings are supported by mySAP
Utilities. In the deregulated market, it is possible that crosscompany code invoicing or billing for and by a third party will
be required. Postings can be reversed. During this process, a
reversal document is generated that creates a balance of zero
in conjunction with the reversed document. Both documents
are linked to one another by the reversal.

Payments Overview
FI-CA supports all commonly used payment methods for
incoming and outgoing payments in utility companies including any country-specific features. The system also provides
various business processes for payments. These can be classified
as follows:
Automatic payment by the utility company
This processing can be performed for all outgoing and
incoming payments if the customer has granted the utility
company the corresponding authority.
Process incoming payments using lots
The customer makes payments through the bank or post
office.
Cash desk and cash journal
The customer makes payments at the utility company.

Automatic Payment
This payment program is used to make automatic payments
and contains the following actions:
The system determines the items that are due. Credit memo
items that have been released for payment can be taken into
account automatically here.
Items for a business partner can be paid as a single total,
separately by contract account or individually. The system
observes your individual grouping rules and any minimum
amounts defined.
The system determines the respective payment method to
be used (see Table 1) based on information in the contract
accounts for the business partner. You can define the payment method for specific items on an individual basis. You
can propose the payment methods to be processed for each
payment run. This is for instance advisable if you only wish
to create checks for repayments on a weekly basis but wish
to execute debit memos on a daily basis.

Payment methods are available in the various payment processes as follows:


Payment is initiated
by the utility company

Payment is initiated by the customer

Collection or repayment
using automatic payment

Lot processing of incoming payments

Payment via the cash desk

Cash payment

Incoming check

Incoming check

Incoming bank transfer

Card payment

Card payment

Card payment

Direct debit

Debit memo

Returned check

Outgoing check

Refund by bank transfer

Postal order

Postal order

Decreasing level of automation

Table 1: Available Payment Methods

99

The system supports automatic determination of the house


bank while observing any information on payment optimization.
The system makes postings for payment documents and any
clearing postings automatically and clears items that have
been paid.
The system then creates the output media required (such
as data objects for banks and credit card companies, checks,
and so forth) and accompanying letters and payment advice
notes.
In addition to payment of invoices and credit memos, the system also allows budget billing amounts to be processed automatically and repayments from the clarification work list or
payments on account to be made. Customers who use the
bank collection method can be rewarded for doing so.
Payment Lots
Payment lots combine payments that have a common origin
or those that are to be processed collectively. They contain
data on the payment origin and the note to payee. There are
three basic types of lots:
Incoming check data is entered in a check lot manually.
Credit card payments either are entered manually or entered
in a credit card lot through an interface.
Incoming transfers can be transferred manually, by an
interface, or by using a transfer from the electronic bank
statement into a payment lot.
Lots are processed once data has been entered. Payments are
assigned to open items automatically using company-specific
rules. Items that have been assigned are automatically cleared.
Overpayments can be posted as payments on account and
underpayments can be posted as partial payments.

100

Cash Desk and Cash Journal


Cash desk functions are used to enter incoming and outgoing
payments in dialog processing with customers. In addition to
cash payments, credit card, check, and postal order payment
methods are also available. Items to be paid can be determined
automatically by the system (additional information is available under Control Clearing of an Open Item in this chapter). They can also be assigned by the user (in agreement with
the customer). Payments on account or partial payments for
various items are also possible. The system creates any documents required (such as checks or receipts). The cash desk is
integrated in the cash journal and can be implemented with
or without the cash journal. If the cash journal is used, additional functions are available that are described in the following sections.
The cash journal can be used to log and evaluate postings
made at cash desks in your organization in the system. The
cash desk structure includes cash desks at individual branches
of your company. Users are also assigned to their respective
cash desk. Postings are made for each cash desk and branch.
Cash desks can be opened and closed. Postings can only be
made to open cash desks. In addition to incoming and outgoing payments, deposits and withdrawals from the cash desk
and any differences can also be posted. You can perform a cash
desk closing for each cash desk. During this process, the system
clears the actual amount with the target amount from the
respective cash desk. Any differences can be posted to reconcile
the cash desk. The system can determine the current amount
in the cash register at any stage for monitoring purposes.
Evaluations based on cash desk transactions can be traced for
specific days or can be traced historically. The role concept in
the cash journal can be used to flexibly define responsibilities
(such as the cashier, branch manager, representative, and so
on). This means that branch managers are responsible for cash
desk reconciliation in all of their branches.

Check Management
FI-CA supports creation, management, and cashing of outgoing checks. The payment program or the cash desk can create
checks automatically. You can also enter and manage checks
that have been created manually in the system. Alternatively,
you can use prenumbered checks for each house bank account
or instruct the system to assign the check number.
Check management includes the following functions:
Display checks and associated payment documents
Create replacement checks
Voiding of checks with message to the bank
This can also cause the payment posting to be voided if
necessary. A replacement check can be created manually
or by the system as an alternative.
Check encashment
Cashing a check can be entered manually or take place by
automatically processing the electronic bank statement.
Reconciliation of checks that have been cashed can either take
place in the check clearing account in the general ledger or
in FI-CA. If the data reported by the bank does not match the
data in check management, the system automatically creates
an entry for clarification processing. Any postings required are
automatically generated by the system during the subsequent
clarification process.
Control Clearing of an Open Item
Open items can be cleared by various processes:
During posting of a payment document
By the payment run
During processing of payment lots
At the cash desk
During invoicing (if budget billing amounts that have
already been paid are cleared during invoicing or if automatic account maintenance is triggered from billing)
During automatic account maintenance
During manual account maintenance

The payment run is based on items that are due, to be paid,


or ready for collection. In these situations, the payment document is automatically linked with the item, which clears the
item. Budget billing amounts that have already been paid are
recognized and automatically cleared by the system during
invoicing. FI-CA also contains clearing control for additional
processes, which can be used to represent the clearing strategy
used by your organization in a flexible manner. Clearing control can be defined differently according to the contract
account and business transaction involved. During assignment
of incoming payments, the objective is to determine the note
to payee for the payment as precisely as possible. Any specifications made by the customer are processed. Industry- and company-specific rules can also be applied. (If, for example, the
note to payee is missing, payment of receivables in conjunction
with a specific contract type can take precedence over other
receivables or the payment amount can be distributed between
several receivables.)
Clearing processing during account maintenance takes place
for open items in a contract account that have already been
entered. Assigning items once the amount has been agreed
is not significant. The way in which credit memo items and
receivables are to be mutually cleared within specific boundaries (such as company code or within a division) is of far
greater interest. This can lead to partial clearing.
During dialog processing (for example, at the cash desk or for
manual account maintenance), clearing control rules mean
that while the system proposes items for clearing, you can
make an alternative decision. You can suggest that receivables
in a specific division or older receivables are given priority.

101

Returns Processing
Returns can appear in debit memo and collection procedures,
check deposits, or payments. Returns are combined in returns
lots. These lots can be created manually based on returns documents or automatically by transferring returns data from the
bank. Returns are then processed automatically as follows:
The payment clearing is reversed. This means that the
receivables or payables cleared by the debit memo then
become open items.
A returns document is created that contains offsetting
postings for items in the payment document. Both of these
documents have a collective balance of zero.
Additional postings are generated that are required because
of expense charges and any taxes included.
Bank charges and additional internal charges are placed
in the bill to the business partner.

The system always executes entries in the clarification work list


if the business transaction cannot be processed manually or
manual processing is explicitly requested in a specific situation.
Users responsible for clarification cases can be determined
automatically using the organizational structure. You can also
reserve a clarification case for a specific user meaning that it is
blocked for processing by other users (this can be a time restriction). You can remove the block at any time. Clarification cases
can also be transferred between users. Various actions are available in the system depending on the type of clarification case
involved. Incoming payments to be clarified can be assigned to
an open item in dialog, charged off, or flagged for repayment.
The system also supports clarification of partial amounts.
During clarification of the credit balance, you can transfer the
amount that will be clarified to the business partner, flag this
for follow-up, clear it, or repost it.

Returns can trigger the following subsequent actions:


Generate a customer letter
Set a deferral date
Block an account for collection
Trigger a workflow

Deferral and Installment Plan


If a customer is unable to honor his or her financial commitments, you can make a deferral or installment plan agreement
for one or more receivables. The number, amount, and due
dates for installments are defined in an installment plan.
During dunning and the payment run, the individual installments are recognized instead of the original receivable. An
installment plan can be deactivated if necessary so that the
original receivable is re-entered in payment and the dunning
run.

Subsequent measures are dependent on the credit standing


of the business partner and the returns frequency.
Clarification Processing
Clarification processing allows for exceptional situations that
can occur when processing incoming and outgoing payments,
returns, and credit balances, so that they can be processed
efficiently. The following exceptional situations can occur:
A note to payee is available for an incoming payment, to
which no open item can be assigned.
A due item cannot be settled by the payment program since
a payment block has been assigned to the contract account.
A customer has made an overpayment or a payment on
account.
Returns with a specific reason are always to be processed
manually.

102

The installment plan offers the following functions:


Interest based on the installment agreement can be
calculated and posted automatically.
A customer letter that includes any required payment forms
is created.
Installments that are not open can be deleted, amounts and
due dates can be modified, and installments can be added.
Partial payment can be made for installments.
Once a certain dunning level is reached, the installment plan
can be deactivated by the dunning run.

A deferral agreement means that an item is no longer dunned


up to the deferral date and no bank collection takes place. If
the deferral date is exceeded, the item with the original due
date is dunned again or a bank collection takes place.
Dunning
Business partners are reminded about (over)due open items
by payment reminders or dunning notices. The system uses
the dunning program to monitor payment behavior for customers and start the required activities. The respective dunning procedure plays a central role during dunning. It controls
the start date of the dunning process, the number of dunning
levels, and the requirements of the respective dunning level.
One example of this type of requirement is the dunning interval, which defines the length of time between reminders. This
means that you can avoid sending a business partner too many
dunning reminders in quick succession.

You define the actions to be performed by the system for each


dunning level. The following dunning activities are available
as standard:
Create dunning notice
Create bank statement
Create blocking document
Request cash security deposit
Deactivate installment plan
Hand over receivable(s) to the collections agency
You can define any additional dunning activities required, such
as those required to meet the statutory dunning requirements.
You can determine the amount limit from which dunning is
to start. Charges can be calculated automatically according to
your requirements and posted to the general ledger or simply
created as statistical postings. Interest can be calculated automatically for the items. The dunning procedure is recorded at

System configuration

Control
parameter

Amount limits, Days


in arrears,
Dunning interval

Fee schema
Print formulas

Business
partner

Contract
account
Determine
new
dunning levels

Generate
dunning
proposals

Generate
dunning
activities

Post
interest
and fees

Open
items

Dunning
history

Figure 55: Overview of Dunning

103

the contract account level. You can override individual items,


and temporarily exclude the item, or account from dunning. In
addition to standard receivables, you can perform dunning for
other items, such as budget billing requests and installment plan
items. You can control which items are dunned collectively
according to your business requirements by defining dunning
groups accordingly. This means that you can ensure that a separate dunning notice is created for each contract or division.
To ensure that you have statements on the dunning activities
performed at any stage, dunning data is listed in the dunning
history. Specific dunning proposals or an entire dunning run
can be cancelled if necessary (for example, if a customer makes
a complaint). This reverses dunning charges and specific dunning activities (such as handover to a collection agency or device
blocking).
Collection
FI-CA allows items to be handed over to an external collection
agency if dunning is unsuccessful, and supports you during
subsequent processes. This involves the following functions:
Release items for handover to a collection agency
Automatic release can take place from the preceding
dunning or charge-off processes. You can also release items
manually.
Determine additional items to be handed over (for example,
hand over all items for a contract, contract account, or
business partner).
Flexible determination of the responsible collection agency
Recall items that have been handed over
Recall can take place automatically because of an incoming
payment directly from the customer, or it can take place
because of items being transferred to another collection
agency. Manual recall can take place if items are handed over
incorrectly.
Automatic entry of incoming payments from the collection
agency
This includes assigning the associated receivables and automatic entry of interest and charges including all relevant
postings. If postings are entirely or partially unrecoverable,
the corresponding amounts can be written off automatically.
104

FI-CA supports electronic data exchange with collection


agencies. The following communication is possible:
Handover and recall of items
Transfer changes to the master data (such as a change
to the business partner address)
Reports of collection agency payments including interest
and charges
Since the system lists all processing stages of an item, you have
the option of creating detailed evaluations at any stage (so that
you can check the efficiency of your collection agency).
Interest Calculation
By calculating interest for line items, you can use interest to
control your customers payment behavior. For example, you
can pay interest for an incoming payment that is received earlier, while deducting interest for an incoming payment that is
received later. Interest calculation provides a number of functions that permit flexible individual processing of different line
items and therefore allow specific agreements with customers
to be implemented. The system differentiates between debit
and credit items, and between open and cleared items. You can
also decide what procedure is to be used for specialist line items
such as installment plan items, cash security deposits, yearly
advance payments for a budget billing plan, and statistical
items like budget billing requests.
You can start interest calculation in various processes:
Interest calculation in a mass run:
The system calculates interest for all line items that match
the selection requirements.
Interest calculation in individual processing
Interest is determined on an individual basis for selected line
items for a business partner, contract account, or contract.
Interest calculation in a dunning run
Interest is calculated for all overdue line items after
a dunning level that you define has been reached.
Interest calculation in invoicing
Interest calculation for cash security deposits can be
triggered from invoicing. Interest can be printed on the
bill or the dunning notice.

Interest keys control calculation rules and interest rates. They


can be recorded at contract account level, determined automatically for each item according to the business transaction
involved, or set manually. The interest key is determined from
the dunning level for interest calculation in the dunning run.
Interest blocks can be used to exclude specific items from
interest calculation. You can exclude certain business transactions (such as reversals or additional receivables). You can
also define amount limits. This avoids calculating interest
for minimum amounts.
The system can post the interest determined as a general ledger or statistical posting and can generate the necessary correspondence. Interest history is listed for an item, which ensures
that interest calculation can be tracked. It also ensures that
interest is not calculated more than once for items.
Securities
FI-CA supports requests for securities. Security deposits can be
requested from new customers or from customers who have
an irregular payment history. The system makes a distinction
between cash security deposits and non-cash security deposits:
Cash security deposits can be levied manually as required or
automatically at the contract start by processing a move-in.
They are posted to a specific contract or a contract account.
Cash security deposit payments that have been made are
refunded if the payment behavior of a customer develops
positively over an extended period. You can calculate interest
on cash security deposit payments across the entire period.
Cash security deposit payments and interest are usually
cleared as part of a final settlement. It can also be paid subannually or cleared.
Non-cash security deposits include savings accounts or
guarantees. The savings account holder or the guarantor
is specified when they are entered.
Transfer Open Items
It is always necessary to transfer receivables or credit memo
items if a business partner takes on the rights and responsibilities of another business partner, as is the case for inheritance
or debt transfer. It is sometimes necessary to transfer receiv-

ables or credit memo items within various contracts or contract accounts for the same business partner. This is the case if
a customer terminates a contract but the remaining receivables
are to be paid with the receivables for the new contract. During
transfer, the system clears the items selected and generates new
open items for the target business partner/account/contract.
Most of the posting information is copied during this process.
Collective Bill Processing
Collective bill processing enables you to combine documents
from different contract accounts or business partners for
collective processing, for example during bill creation, payment, or dunning processing. Individual documents are
grouped under a collective bill document number. Collective
bills are, for instance, used for building companies, municipal
administration departments, and major companies. Documents that are part of a collective bill appear on the individual
contract account and the collective bill contract account. You
can also assign an incoming payment to a collective bill or
individual contract accounting documents.
Third-Party Billing in the Deregulated Market
Contract Accounts Receivable and Payable supports various
scenarios in the deregulated utility market and is suitable
for use by service providers (companies that are involved in
supplying a point of delivery) as well as companies that create
bills. Additional information on these scenarios is available
in Chapter 8, Intercompany Data Exchange and in the Introduction.
The following sections describe special functions for contract
accounts receivable and payable that are used to represent
deregulation scenarios. A company can use FI-CA to manage
both its own receivables to its customers and the receivables of
third parties to these customers. Separating transmitted items
from your own receivables is a statutory requirement. Usually,
transmitted items also have different tax requirements to those
for your own receivables. FI-CA can be used to manage several
company codes in parallel and record different processing rules.
Processes can be performed across all company codes (for
example, payment processes).

105

Service provider (SP)

Billing party (BP)


Dunning

End customer A
(1) 600

600 (2)

End customer A

End customer B
(1) 400

400 (2)

End customer B

(3) 600

(3) 400

(4) 100

(4) 100

Payment

End customer
A

Bill
Rechnung
Bill

Revenues
1000 (1)

Receivables SP

Payable. SP

(2) 1000

(1) Service for end customer A, B


(2) Submit receivables to billing party

Revenues

1000 (3)

200 (4)

Dunning

Dunning

Payment

Payment

End customer
B

(3) Carry over receivables from SP


(4) Additional service for end customers A, B

Figure 56: Deregulation Advance Payment

FI-CA supports advance payment and customer payment


during payment management.
Advance payment
Advance payment involves all receivables for a service provider to its customers being handed over to a third party
(billing party). Payment to the service provider is made by
the billing party independently of the incoming payment
from the end customer. Any dunning notice for the service
provider is addressed to the billing party. The system automatically rejects collection of the bill amount from the end
customer. The end customer is dunned by the billing party
if advance payment is used. Payments to the service provider
are made independently from payments of the end customer
to the billing party and can be managed automatically by
the system. FI-CA supports both advance payment in which
the billing party simply acts as a billing agent as well as
procedures in which the billing party is the sole provider
(see Chapter 8, Intercompany Data Exchange).

106

Customer payment
Customer payment (comparable to advance payment)
involves the billing party being responsible for payment
management with the end customer. However, the service
provider does not receive payment from the billing party
until payment has been received from the respective end
customer. The service provider is usually responsible for
dunning unpaid items. Both the service provider and the
billing party need to be able to track each individual item.
FI-CA supports detailed payment advice notes for items in
addition to automated payment forwarding.

Service provider (SP)

End customer A
(1) 600

600 (2)

Billing party (BP)

End customer A

End customer B
(1) 400

(3) 600

400 (2)

(4) 100

End customer
A

End customer B
(3) 400

700 (5)

(4) 100
Bill

Revenues
1000 (1)

Receivables SP
(2) 1000

Payable. SP

600 (7)

(6) 600

Bank

1000 (3)

Revenues
200 (4)

Rechnung
Bill

Bank

(7) 600

(5) 700

600 (6)
End customer
B

(1) Service for end customer A, B


(2) Submit receivables to billing party
(7) Incoming payments from SP due to payment by
customer A

(3) Carry over receivables from service provider


(4) Additional service for end customers A, B
(5) Customer A pays
(6) Payment is transferred to SP

Dunning from customer B


through service provider

Figure 57: Deregulation Customer Payment

The company performing the service and the billing agent


both store detailed data on the end customer. The billing party
also creates a collective list of payables to the service provider
and the service provider has a corresponding list of all receivables to the billing party.
Write-Off
It is necessary to write off items if receivables are irrecoverable
or payables cannot be paid because it is not possible to determine the payment recipient. FI-CA supports automation of
this process. You can record individual write-off rules (such as
amount limits) in the system. FI-CA can also be used to write

off individual items in dialog processing or to write off partial


amounts. (Dialog processing is the opposite of background
processing. In dialog processing, the user can control what
happens during write-off. He or she cannnot do this in background processing.) The system automatically makes the necessary posting, including tax correction postings required during write-off. Write-off also includes the following functions:
Items to be written off can also be transferred to a collection
agency.
Items that the collection agency reports to be irrecoverable
are written off automatically.

107

Correspondence
Correspondence with your business partners can be controlled
by events in FI-CA (for instance during dunning) or can be
created periodically (bank statements). The system also allows
you to request single correspondence (such as a receipt or
account information). Standard forms are available for each
corresponding type that you can modify to meet your requirements. The following letters are available:
Bank statement
Balance notification
Business partner move-out
Dunning notice
Letter about installment payment agreements
Letter about deferral agreements
Print returns notice
Interest calculation letter
Notification about credit clarification
Notification about incoming payments and payment usage
Confirmation of changes made to the master data
Receipt for a cash-desk payment
Payment advice note
Request for securities
You can attach a payment form to correspondence that requests payment automatically. The system also provides
flexible options for determining the correspondence recipient
or recording additional correspondence recipients. You can
define different addresses for various kinds of correspondence.
Statutory Reporting
FI-CA contains comprehensive functions for managing statutory requirements with regard to sales tax, withholding tax,
and foreign trade declarations including the respective countyspecific regulations:

108

Tax returns for tax on sales/purchases


When transactions that are relevant to sales tax are posted,
such as receivables and payables, or down payments that are
managed as gross amounts, the system determines the tax
indicator and corresponding tax account to be used based
on the business transaction involved. Corresponding postings to the tax accounts are made automatically. Depending
on the statutory requirements and the level of detail required,
you can create your returns from the general ledger in the
Financial Accounting component (FI) or you can update a
separate reporting file in FI-CA. This is used as the basis for
creating returns. This means that reports can be created for
the posting date due dates or dates on which payment is
made. The level of detail for the returns and statements is
defined by making the corresponding system settings. You
can assign county- or region-dependent taxes or produce
a statement for the individual documents.
Withholding tax returns
FI-CA supports credit and debit withholding tax. The withholding tax indicator to be used is determined from the
master data for the business partner involved when the
receivables or payables are posted. The system makes the
corresponding tax postings automatically for incoming and
outgoing payments. A separate reporting file is created that
forms the basis for the return.
Foreign trade declarations
Transactions with tax-based non-resident companies include
stock reports and transaction reports. Transaction reports
that relate to payment transactions are based on a separate
reporting file that is updated if incoming payments are
received or outgoing payments are made. Stock reports are
made using open item lists that meet the corresponding
selection requirements. The legal recipient code, for example
the state central bank indicator for Germany, can be recorded
in the system settings and set automatically.

Reconcile Contract Accounts Receivable and Payable


with the General Ledger
In view of the large document volumes, sales figures are not
updated consecutively in the general ledger during posting in
FI-CA. Instead, FI-CA documents are summarized as summary
records. These are periodically transferred to the general ledger

FI-CA DOCUMENTS

Document
Reconciliation key
Posting date
Company code
Partner
Amount
Revenue account

10004711
TK980410
04.10.2002
U100
99000123
200.00
800003

Document
Reconciliation key
Posting date
Company code
Partner
Amount
Revenue account

10004712
TK980410
04.10.2002
U100
99000114
200.00
800003

Document
Reconciliation key
Posting date
Company code
Partner
Amount
Revenue account

10004713
TK980410
04.11.2002
U100
99000129
200.00
800004

in the Financial Accounting component FI or an external system. This improves performance and reduces document volumes in the general ledger. The reconciliation key connects
the general ledger within the subledger. It is used to itemize
amounts posted to the general ledger and perform reconciliation between FI-CA and the general ledger.

TOTALS RECORDS

Reconciliation key
Posting date
D 500.00
C 500.00
Posting date
D 600.00
C 600.00

TK980410
04.10.2002
140101
800003
04.11.2002
140101
800004

FI DOCUMENTS

Document
Reference key
Posting date
40
140101
50
800003

120001234
TK980410
04.10.2002
500,00
500,00

Document
Reference key
Posting date
40
140101
50
800003

120001234
TK980410
04.10.2002
500,00
500,00

Figure 58: Transferring FI-CA Documents to the General Ledger

109

Closing Activities
Contract Accounts Receivable and Payable supports all standard
closing activities. The following functions are available:
Foreign currency valuation
This valuation is used to revalue open items so that associated
payable and receivable accounts can be corrected when the
balance sheet is prepared. This valuation can use standard
valuation procedures (such as the lowest value principle).
Individual items that are open on the balance sheet key date
are used for the valuation. Valuation can take place in the
house currency and currencies that are managed in parallel
(such as in the group currency or hard currency). G/L
accounts, to which exchange rate differences from the valuation are to be posted, are determined and posted to by the
system automatically.
Receivables adjustment
This is used to mark receivables as being doubtful and to
correct individual receivables values. It brings receivables in
accounting into line with the estimated receivables value.
Receivables can be marked as doubtful if the business partner
may no longer be able to settle them. The receivable that has
been marked as doubtful is separated from other receivables
by making a posting to a separate receivables account. By
adjusting individual values, the value of each receivable can
be adjusted to any percentage rate. Adjusting individual
values triggers a posting to an expense account. The system
automatically posts any tax corrections. Adjusting a single
value is always based on a receivable that has been marked as
doubtful. However, a receivable can be marked as doubtful
without adjusting a single value. Marking receivables as doubtful and adjusting single values can be automated (based on
the age of the receivable). If adjusting a receivable triggers a
payment, the system performs all correction postings that
this requires.
Reclassification
Reclassification displays vendors with a debit balance, receivables, and payables according to their remaining term.

110

Revenue deferral
Revenue deferral represents time-related revenue recognition in FI-CA. Revenues are initially posted with the receivable. If revenue deferral postings are required, the system
performs these automatically.
Account Balance Display
Account balance display gives you an overview of financial
transactions at the business partner or contract account level.
You can define the display of the business partner or the contract account on an individual basis. In addition to selecting
the items required (such as cleared items only including statistical items), setting variants give you flexible control options
for line construction.
The following settings are available:
Variants for items define which document information are
displayed.
Totals variants define the criteria used to cumulate a single
item.
Sort variants define the sequence in which items are
displayed.
You can toggle between display variants, show additional information, or use search and filter functions within the account
balance display. The system makes all associated information
available starting from a specific document and allows you to
branch to other areas such as:
Business partner, contract account, and contract master data
Dunning, returns, and clearing history
Payment usage
Installment and budget billing plans
You can generate correspondence such as payment forms
or account balance information from the account display.

Figure 59: Account Balance Display

Business Partner Evaluation


FI-CA records the business behavior of your business partners,
which enables you to evaluate them. You can make this available to various processes as a credit standing. This means
that activities associated with dunning and returns can be performed differently according to the current credit standing of
the business partner. The current credit standing of a business
partner is updated by the following processes:
Transfer credit standing data from external data sources
Set a manual value
Dunning notices that take account of the respective dunning
level with the option of weighting this by time. This can be
defined so that current events have a greater influence on
the credit standing than those that are less recent.
Returns taking into account the return reason and the
option of weighting this by time
Write-offs

Evaluations
In addition to numerous evaluations at business partner and
contract account level, additional summary evaluations are
available for day-to-day activities and settlement purposes.
These include the following:
Open item lists for a key date
In addition to evaluating open items for each business partner or account, a number of additional functions are available for selection and output control.
Due date list for open items
Document journal
Statement of individual documents in the clarification
accounts
Integration with the SAP Business Information Warehouse also
enables you to implement your strategic reporting requirements.

111

INTEGRATION WITH ADDITIONAL COMPONENTS

Integration with the general ledger and other ledgers documents that are generated in G/L accounting when summary
records are posted offer you the same integration functions
as standard FI documents and lead to additional ledgers and
Controlling (such as overhead cost controlling or profitability
analysis) being updated automatically. Additional information
was discussed in this chapter under Reconcile Contract Accounts
Receivable and Payable with the General Ledger.
Integration with Cash Management
A posting in FI-CA triggers an immediate (synchronous)
posting in the cash management component (TR-CM). The
liquidity forecast and the cash position in cash management
are therefore always up to date.

Asynchronous posting
FI

Invoicing

FI-CA

Synchronous posting

Cash
Management

Figure 60: Integration with the General Ledger, Controlling,


and Cash Management

112

CO

Integration of Consumption and Service Billing


Invoices and credit memos from contract billing and invoicing
are posted in FI-CA automatically. You can also indicate
whether invoices and credit memos that were generated in
the Sales and Distribution (SD) component for services are
also to be managed in the Contract Accounts Receivable and
Payable component. As an alternative to generating billing
documents in the SD component, you can bill the corresponding amounts with the consumption bill.
Integration with mySAP Customer Relationship
Management
FI-CA works with mySAP CRM in a number of different ways.
As a result, many functions in FI-CA can be accessed from
the mySAP CRM interaction center (IC). The IC offers call
center capabilities for sales or customer service organizations.
The IC allows agents to process inbound and outbound contacts as well as business transactions related to a customer. You
can generate a call list from a dunning run that is automatically
available in mySAP CRM for processing.
Integration with Credit Management
Credit management functions are used to define and monitor
credit limits. Items that are currently open, as well as data on
a business partners credit worthiness are included here.
Integration with Dispute Management
Dispute management functions are used to create, edit, and
follow disputes. A dispute can be triggered directly by a customer complaint or indirectly by a corresponding customer

action (such as underpayment of the bill). Integration with


FI-CA involves the following functions:
Creation of a dispute case from FI-CA processes
Association of a dispute case with a FI-CA document to
facilitate straightforward resolution of the case
Option of accessing FI-CA functions from case processing
(to block an item for dunning)
Integration with FSCM Biller Direct
Financial Supply Chain Management (FSCM) Biller Direct
gives business partners online access to their accounts and
bills through the Internet. In addition to displaying data,
the following functions are available:
Payment authority (automatic debit, credit card debit)
Clearing of credit memos
Master data changes

SOLUTION ADVANTAGES

Contract Accounts Receivable and Payable offers you the


following advantages:
High levels of automation that significantly reduce the effort
required to complete routine tasks
Reduction in the average value of accounts receivable as
a result of increased efficiency in receivables management
Improved customer service due to transparency and simple
tracking of activities
High levels of customer satisfaction thanks to the option
of responding to the individual customer requirements
and representing these in the system
Reduced operating costs due to seamless integration with
other mySAP.com solutions
Employees are who motivated by functions that are easy
to use in a user-friendly system

Functions in the FSCM Biller Direct trigger an immediate


update in FI-CA.
Integration with SAP Business Information Warehouse
SAP BW permits strategic reporting based on FI-CA data that is
tailored towards your specific requirements. To do so, FI-CA
provides extractors for open and cleared items and a sequence
of standard reports that build on this information. Consequently, the system can be used to perform many different
types of evaluation and analysis. These include:
Display items in a sorted list
Overdue analyses
Analysis of payment behavior for specific customer segments
Seasonal variations in payment behavior
Average delay in payment

113

INTERCOMPANY DATA EXCHANGE


The intercompany data exchange (IDE) in mySAP Utilities
meets the requirements that have resulted from the deregulation of energy markets. IDE primarily consists of the following
parts:
Administration of deregulation data
Deregulation data includes points of delivery, grids, point
of delivery services, and service providers.
Processing of data exchange processes
Data exchange processes allow you to exchange the data that
is necessary for processing business processes in deregulated
energy markets.

Default value

Distributor

ADMINISTRATION OF DEREGULATION DATA

Point of Delivery
The point of delivery is the point to which a utility service is
supplied, or for which a utility service can be determined. The
unique key, called the point of delivery ID, prevents misunderstandings and incorrect allocations of registered data even if
a customer switches utility companies. The point of delivery
is the central object in the deregulated data model. A point
of delivery is created automatically for every installation. If
you specify a point of delivery ID, you can uniquely identify
any point of delivery during communication between market

Regional
structure

Service provider

Business
partner

Service
Non-billable

Contract
account

Service cat.
Distribution

Contract
Billable service

Deregulated
Grid

Point of delivery

Installation

Technical
Register

Figure 61: Data Model

114

Device

Premise

Connection
object

participants, such as suppliers and distributors. If no points of


delivery are defined within a market, or if the usual points of
delivery are not used, communication is still possible. However,
you must always ensure that other identification criteria are
available when you communicate with other service providers.
You can allocate several installations to the same point of
delivery.
Grid
A grid is an object in mySAP Utilities that corresponds to a distributors distribution grid, or part of it. You can manage grids
for a distributor. A distribution grid can be divided into several
grids for the following reasons:
To record grid hierarchies
You can record grid hierarchies in the system by specifying
higher- or lower-level grids. These hierarchies can be evaluated
when overall schedules are created for different grids.
If a distribution grid covers several control areas
If these control areas are managed by different control area
operators, you must manage each part of the distribution
grid that is located in a control area as a separate grid in the

system for settlement purposes. This means that you can use
settlement procedures that calculate the settlement results,
not only for each settlement unit, but also for each grid. The
grid is historically allocated to a distributor. The distributor
is a service provider who is allocated a service type belonging
to the service category Supply. You can allocate a grid to
several voltage levels.

Higher-level grid
Voltage level
(for example 20 kV)

Grid hierarchy

Grid

006

001

005

NetCo

004
002

Distributor

003
Regional structure

Figure 62: Grid Hierarchy

Control area operator

Control area operator

Regional supplier

Regional supplier

Municipal
utility company
Stadtwerk
Grid 1

Grid 2

Municipal utility

District utility company

Municipal utility

District utility company

Figure 63: Distribution Grid Across Several Control Hierarchies


115

If a distribution grid is divided into different voltage levels,


which are represented as separate grids in the system, you
can even allocate different grids (and therefore different
distributors) to different points of delivery for different
voltage levels when a connection object (with the same
postal address) has a number of points of delivery.

Service
provider

Business
partner

Service
Nonbillable

Contract
Billable
service

Point of
delivery

Installation

Contract
account

Services
A service is used to describe a service supplied to a point
of delivery. Services can be billable or non-billable. All SAP
or third-party services that are billed and/or invoiced are
modeled as a contract in the system. Contracts are also
described as billable services. All other services are non-billable
services and are modeled as a separate entity at the point of
delivery.
Service Provider
The service provider is a company that plays a part in supplying a point of delivery. A service provider can be a distributor,
a supplier, or a meter operator, for example. As a service provider, you can manage your own company in the system or
you can manage other companies with whom you have a business relationship for things like exchanging data or settling
payment. You can allocate different objects to the service
provider in mySAP Utilities.

Figure 64: Services

Business
partner
Contract
account

Vendor

Billing
category

G/L account

Service provider
Data
exchange
definition

Installation

Non-billable
service

Grid
Contract

Figure 65: Service Provider

116

SUPPLY SCENARIO FOR A POINT OF DELIVERY


AND PROCESS CONTROL IN A DEREGULATED
ENVIRONMENT

The chief aspect of deregulation is that different companies


(or service providers) take part in supplying a point of delivery
(a distributor and a supplier, for example). The supply status of
a point of delivery is described by the services that are allocated
to it. The services describe the service providers taking part in
the supply and their roles. Processing a point of delivery creates
processes that involve several service providers that are taking
part in the supply. Examples of these processes include changing a supplier and handling payments for grid usage charges.
These processes are not carried out by the energy supplier and
the end customer, but by the service providers that play a part
in supplying the point of delivery (or end customer). The way
in which these processes are controlled depends on the participating service providers. The question of who issues the bill to
the customer as well as the question of payment handling for
grid usage charges for the distributor and the supplier is of particular importance here. The following describes a number of
scenarios, in which you use intercompany data exchange. For
more information, see the Chapter 7, Contract Accounts Receivable and Payable.
Supplier as Billing Agent and Rate Ready
A billing agent is a service provider that creates bills and monitors incoming payments for services they provide themselves,
as well as services from any third parties involved. The rateready procedure involves a bill creation process and bill payment by the billing agents on behalf of the service provider
who is the service owner. The billing agent must have access
to all the data (such as rate data) required to create the bill.
This means that the customer receives one bill for all service
types.

The Distributor as Billing Agent and Bill Ready


The bill-ready scenario is a bill creation process performed by
the service provider who is the owner of the receivable. The
bill covers services provided by the service provider as well as
services from any third parties involved. The bill is transferred
to the billing agent who is responsible for bill payment. This
means that the customer receives one bill for all service types.
The Supplier as Sole Provider (All-Inclusive Contracts)
The sole provider is a service provider who, from the customers point of view, is solely responsible for all services. The
sole provider is also the owner of third-party receivables from
the customer. The distributor performs billing for grid usage.
The distributor bills the supplier for grid usage charges. Incoming bills from the distributor in the suppliers system are
aggregated and transferred to accounts payable accounting,
where they are cleared. The supplier pays the grid usage
charges to the distributor without invoicing them himself
in contract accounts receivable and payable. From the customers point of view, the supplier, as sole provider, is solely
responsible for both services (grid usage and energy supply).
The supplier does not list the grid usage charges separately on
the customers bill, but instead creates a separate rate for all
services.
Dual Billing
Dual billing is a bill creation process in which each service
provider creates its own bill and sends it to the customer.
This means that the customer receives several bills.

117

PROCESSING DATA EXCHANGE PROCESSES

The deregulation of the energy market has resulted in the


development of new business processes that require data to
be exchanged between market participants (supplier and
distributor, for example). In a business process, an exchange
of data consists of several steps. We refer to these steps as data
exchange processes. If a customer changes supplier, for example, the new supplier sends the relevant data to the customers
former supplier and to the distributor. The former supplier
and the distributor check the data and determine whether the
change of supplier is permissible. The former supplier sends
a confirmation or a rejection of the customer switch to the
distributor. Depending on the result of the checks and the
confirmation from the former supplier, the distributor sends
a confirmation or a rejection to the customers new supplier,
thus ending the change of supplier process. In the event of a
supplier change, the following data exchange processes occur:
The new supplier sends a customer change notification to
the former supplier
The former supplier receives the customer change notification from the new supplier
The new supplier sends the customer change notification
to the distributor
The distributor receives the customer change notification
from the new supplier
The former supplier sends a confirmation of the customer
change to the distributor
The distributor receives the confirmation of the customer
change from the former supplier
The distributor sends a confirmation of the customer change
to the new supplier
The new supplier receives a confirmation of the customer
change from the distributor

118

A data exchange process monitors and controls messages related to point of delivery within intercompany data exchange.
Automation (of data exchange processes in particular) is very
important for processing business processes. You can control
and monitor data exchange processes using mySAP Utilities.
This allows you to integrate data exchange processes with business processes by means of workflow automated business
processes.
Data Exchange Definitions
Data exchange definitions are created based on data exchange
processes. A data exchange definition describes at which point
(due date) and in which format messages are exchanged
between two service providers. This is determined at service
provider level. In exceptional cases however, you can override
the data exchange definition at point of delivery level. Data
exchange for the individual point of delivery is controlled by
the data exchange definition of the corresponding service
provider. You can also redefine data exchange definitions for
individual points of delivery. This means that for an individual
point of delivery, you can define a due date control that is different to that described in the data exchange definition of the
corresponding service provider. Every data exchange definition
can be prorated historically.

Data Exchange Tasks


Fixed data exchange tasks with specific due dates for individual
points of delivery are generated or created manually from data
exchange definitions (for service provider or point of delivery).
You can use the generated data exchange tasks to monitor the
expected import or export of data. The data exchange task
automatically logs message import and export (logging executed data exchange processes and monitoring scheduled due
dates). You can generate or manually create data exchange
tasks based on the data exchange definition that was last created. When you execute a data exchange task, the data to be
sent to a communication partner is read directly from the application and written to an IDoc based on the communication
format as specified in the data exchange definition. It is only
possible to execute export processes. An IDoc (intermediate
document) is the standard interface used to exchange business
data with an external system. For outbound communication,
the IDoc allows data to be converted into different formats
such as XML, EDIFACT, Microsoft Excel, and so on. The IDocs
are linked to the data exchange task. When data is received,
the various external formats are converted to an IDoc.
As a rule, you should expect a large number of data exchange
tasks. If, for example, you import profile values on a daily basis,
a data exchange task is recorded for every day and for every
profile. To keep the volume of data to a minimum, you can
use reports to delete data exchange tasks that have already
been executed.
You can use authorization objects to limit the use of data
exchange tasks.

Control
There are several different ways of controlling the exchange of
data. It is possible to schedule the execution of data exchange
tasks for specific data exchange processes in advance. You can
execute the scheduled data exchange tasks by starting a report
containing a number of selection options (service provider,
data exchange process, and so on). In this way, a great deal of
the data exchange can be automated. In addition, you can trigger the execution of individual data exchange tasks or create
new ones directly in monitoring.
Monitoring
Data exchange monitoring is a very important task. You can
analyze executed or scheduled data exchange tasks according
to service provider, data exchange process, individual points of
delivery, or according to the status of the data exchange task.
Data exchange tasks are given a status that displays the task status and, where appropriate, information about any processing
errors that have occurred. For example, this allows you to
determine overdue data exchange tasks and data exchange
tasks that ended with errors. Depending on the status of the
data exchange task, you can trigger automatic processing. This
allows you to start a workflow for all data exchange tasks with
processing errors, which informs the responsible person of the
errors by e-mail. Monitoring data exchange tasks also provides
a link to the application objects that are related to the exchange of data. This could be a link to the corresponding profile for a measured load shape received by the distributor, for
example. This link allows you to display the transferred profile
values directly.

119

SAP
System

AP

BU
TO
EC
SINE
SS CONN

XML
HTML

SAP
BC

WEB
BROWSER

INTE
R NET T E CHNOLOGY

SAP
System

XML

XML
Interface
NON-SAP
SYSTEMS

HTML/
XML
XML

XML

WEB
CONTENT
DERVER

B2B Server
WEB
APPLICATIONS

BC

NON-SAP
SYSTEMS

IDoc

AMR

BAPI
mySAP Utilities, EDM, IDE
BOR
FI

CO

...

WF

Figure 66: Data Exchange Architecture

Communication Technology
Data is exchanged using IDocs. If you want to send data to
another market participant, an IDoc in the format that is specified in the data exchange definition is created from that data.
You can send the data using the SAP Business Connector. The
SAP Business Connector can create an XML file from the IDoc
and send it to the appropriate recipient by means of the Internet. It can also receive an XML file from another market participant and convert it to an IDoc so that it can be processed as
a data exchange process in mySAP Utilities.

120

Business Processes with Data Exchange


Data exchange processes are part of a complex business process.
Sending a customer switch notification from the supplier to
the distributor is part of a complex change of supplier process.
Data exchange processes only control and monitor the data
exchange processes, not the entire business process. In the
event of a change of supplier process, the entire process is controlled using a corresponding workflow, in which the data
exchange processes are integrated as process steps (workflow
steps). The switch document is used to monitor (log) the
change of supplier process. The switch document is also used
in monitoring to establish the connection between the data
exchange processes and the business processes.

SOLUTION BENEFITS

Investment security

Implementing intercompany data exchange (IDE) offers you


a wide range of advantages:
Fulfill legal requirements
By implementing IDE, utility companies can meet the
communication requirements of the liberalized energy
market that have resulted from the breaking up of the value
chain within the utilities industry (unbundling). In many
countries, these communication requirements are obligatory
by law and must be fulfilled. The flexibility of the IDE tool
allows you to meet these requirements.
Consistent alignment with the liberalized energy market
The efficient and effective communication between players
in the deregulated energy market forms the basis for the
seamless operation of all market mechanisms. Companies
that use IDE ensure a continuous and consistent flow of
data with other market participants.
Reduced costs using process automation and competitive
advantage through efficiency
IDE allows you to fully automate data exchange processes.
This means that the people responsible can focus completely
on the task of supervision, thus ensuring a timely and uninterrupted flow of data. Automating business processes using
IDE allows you to execute time-critical mass data exchange
processes (changing supplier, exchanging meter data, and so
on) within the required time limits.

IDE is based on established mySAP.com technology and can


be implemented regardless of the type of database, operating
system, or software you use. IDE fits directly into the existing
system landscape. Moreover, it is fully integrated with all
other mySAP Utilities components.
A flexible global solution
IDE is a solution that you can implement internationally
and modify to meet requirements that are particular to
specific countries. You can use it to map a wide range of
international market models and data exchange standards.
Reusable templates for selected business processes are available to you for countries in which IDE has already been
localized.
Mass data capability
Companies of all sizes can work effectively with IDE. The
solution is specially optimized for processing mass data.

121

ASSET AND WORK MANAGEMENT


Although there are fewer financial resources available in the
liberalized market for upgrading and maintaining technical
installations, utility companies must still guarantee the availability and supply of energy. Resources must, therefore, be
used more efficiently a prerequisite that requires new concepts in asset management. Energy supply alone, however, is
no longer enough to satisfy customers. Customers now demand
attractive and reliable services at the right price. In order to

react quickly to customer demands, as well as schedule employees more effectively, the organization of work management must also be considerably improved.
Through its asset and work management capabilities, mySAP
Utilities enables you to implement new methods in asset
management as well as improve customer service. In this way,
mySAP Utilities supports energy producers, distributors, and
service companies.

CUSTOMER

Customercentric

Customer-oriented
service processes
Open interfaces for
industry-specific
solutions

Work
management

Meter services

ASSET MANAGEMENT
Energy supplier

Description and structure of


technical installations

Distributor

Generator

Assetcentric

Preventative
maintenance
Maintenance cycle

Work
management

Work clearance
management

Figure 67: mySAP Utilities' Asset and Work Management Capabilities Support All Businesses in the Value Chain

122

mySAP Utilities enables utility companies to execute the


following functions:
Map all technical objects from power stations, through
service connections and meters to grids and pipelines
Improve maintenance work from order receipt, through
billing, to planning and execution
Check the total cost of technical installations from
purchase, through refurbishment, to maintenance
Offer customer services as products, schedule service
employees more efficiently, execute services as well as
confirm them and post them in bills
Integrate the functions you require in asset and work
management by connecting external systems such as geographical information systems (GIS) and outage analysis
systems
Through its integration with mySAP Product Lifecycle
Management (mySAP PLM), mySAP Utilities offers an additional set of utility-specific functions. The first part of this
chapter will present you with an overview of the functions
found in mySAP Utilities with asset and work management.
TECHNICAL AND BUSINESS VIEWS OF AN

create different views of a single installation using the hierarchical and relational structure in mySAP Utilities. Every
department can create their own view of the same object.
Maintenance employees, for example, can view an installation
according to technical criteria, while employees from controlling can create a business-orientated view. The business view
has, of course, a completely different structure to the technical
view, since it displays non-technical aspects of an installation,
such as the cost center. These different views enable you to
analyze objects from a wide range of perspectives and control
costs more effectively. In one view, for example, you can check
the costs of a particular line section. Another view of the same
line section only displays costs incurred for the medium voltage area and aggregates these costs for the whole supply grid.
If you manage your installations in a geographical information
system (GIS) or a network information system (NIS), you can
easily integrate these systems into mySAP Utilities using the
GIS Business Connector (GBC) which is passive middleware
that connects a GIS with the SAP system without starting any
processes itself. If a process is started in the SAP system that
requires data from the GIS, the GBC ensures that the corresponding actions are triggered in the GIS.

INSTALLATION

mySAP Utilities enables you to describe in detail any number


of technical objects and installations along with their technical
data. You can directly access further technical information,
such as specifications and drawings in a document management system, using the objects in mySAP Utilities. You can also
access objects in mySAP Utilities from the computer-aided
design (CAD) systems you use to create and design installations.
Since technical installations are directly linked to the Asset
Accounting component, new installations are also automatically created in accounting.
You can link individual technical objects together, and in
doing so, map installations with complex structures (for example, power stations and supply grids). You can also create your
own numbering system to identify these installations. You can

PREVENTATIVE MAINTENANCE AND MALFUNCTION


REPORTS

However you maintain your installations whether based on


time, performance, or status mySAP Utilities supports your
strategy and maintenance cycle. mySAP Utilities uses maintenance plans to generate the necessary orders and reports, and
adjusts them automatically once they have been confirmed.
You can maintain an installation based on its status by integrating supervisory control and data acquisition (SCADA) or
process control systems. These systems send status information from an installation directly to the SAP System, and automatically generate maintenance orders when needed.

123

If an installation breaks down, it must be repaired quickly.


In mySAP Utilities, all steps of this process from the malfunction report, through confirmation, to the accelerated
order release are executed in one system, and all employees
involved are informed of the situation. This considerably
reduces the downtime of an installation. Information on a
malfunction can also be sent from a SCADA system to the
SAP system where a malfunction report is triggered. mySAP
Utilities supports the maintenance of technical installations
with the following, additional functions:
You can store task lists as templates for maintenance work
that is made up of the same or similar work steps. Here, you
can assign jobs to employees as well as describe the tools they
require, and how the costs are to be posted. Based on these
templates, maintenance orders can be generated in a very
short space of time.
The maintenance history saves all orders and reports for
individual installations. It displays problems that occur,
analyzes them, and can uncover hidden relationships.
The solution database helps you analyze what caused the
damage and proposes possible solutions.
Maintenance employees can download orders onto mobile
devices and upload confirmations when the work has been
carried out.
You can use the additional component map and guide to
improve the routes that your maintenance employees travel.
Vehicle management helps you effectively allocate, purchase,
and maintain vehicles for your mobile teams.
Refurbishment orders enable you to refurbish broken,
repairable spares.
You can use mySAP Supplier Relationship Management
(mySAP SRM) to electronically purchase spares and services
in one easy step.

124

WORK CLEARANCE MANAGEMENT AND SAFETY


AT WORK

Inspections and maintenance work on installations that are


critical to safety must be planned, executed, and monitored
particularly carefully. mySAP Utilities' work clearance management functions provide what you need to meet strict safety
requirements. This includes safety measures for the prevention
of fire or radiation, as well as lockouts/tagouts and untagging
for technical objects that have to be electronically isolated or
mechanically separated before maintenance work can begin.
By using the functions for industrial safety and medicine in
mySAP Utilities, you can increase safety for your employees
and minimize health risks. As a result, you can take into consideration exposure in the workplace, manage the status of
safety measures, plan training courses, and analyze accident
statistics.
CUSTOMER-ORIENTED SERVICE PROCESSES

You not only supply your customers with electricity, gas,


or water, you also offer additional services such as installing
service connections, meters, and devices. mySAP Utilities
enables you to offer, sell, and bill these services as products.
Moreover, you can use the whole range of asset and work
management functions for planning, executing, and confirming orders during customer service. The interaction center
(IC) from mySAP CRM is used for direct customer contact.
In addition to offering and selling services, you can also start
processes in the IC, for example interim meter reading, disconnection, and repairs. By using appointment planning in
mySAP Utilities, call center agents can immediately propose a
time and a day for a service team to carry out work. Customers
can also report malfunctions to the call center. mySAP Utilities
forwards these reports to an integrated malfunction analysis

system. Other periodic service work requires a large number of


work orders. This includes the periodic replacement of meters
usually a legal requirement or the inspection of installations. Management capabilities help you create large numbers
of orders and allows you to bundle them according to different
criteria, such as geographic characteristics. You can standardize
and automate all service processes to a large degree through
user-defined templates. These make it considerably easier for
your employees to create orders. If you want to allocate work
orders to employees based on predefined rules or geographic
information, you can integrate mySAP Utilities with a work
scheduling system. Many of these systems enable agents to
process orders online. Orders can be sent to employees in the
field who can confirm these orders online.
TECHNICAL AND VISUAL INTEGRATION OF SYSTEMS

Used in connection with other systems, mySAP Utilities asset


and work management functionality covers not only the complete life cycle of installations, but also technical objects and
customer service. Network information systems, geographical
information systems, and SCADA systems all play an important role in work management, as do systems designed to
improve grids, analyze outages, and schedule work. Individual
solutions, however, are not the answer: Many processes can
only be used fully when they are integrated with other software systems. This is why mySAP Utilities is designed to be
integrated with so many different systems.

A DETAILED LOOK AT UTILITIES-SPECIFIC FUNCTIONS


IN ASSET AND WORK MANAGEMENT

In addition to the functions contained in mySAP PLM, mySAP


Utilities has a range of utilities-specific functions that are
described in detail in the following section.
Description of the Technical Installation
mySAP Utilities maps the complete technical infrastructure
of a utility company including the creation, transfer, and distribution of functional locations, equipment, and their hierarchies. Figure 68 uses the example of a supply grid to display
this. In this example, the distribution station is the highest element in the hierarchy and the transformer fields are subordinate. Transformers are classified as equipment and are installed
in the transformer fields. The transformer fields are connected
to lines by means of object links. The lines are also functional
locations. Electricity pylons are installed in the lines as equipment. Data about the electricity pylons (such as type of
traverse or isolator) can be mapped in different assemblies.

Systems are not only integrated on a technical level, however.


Employees can work more efficiently if information and functions from different systems are displayed in one interface.
Web-based portal solutions, such as the Enterprise Portal for
Assets, are particularly suited for this kind of visual integration.
The portal groups together all the functions an employee
needs for his or her work from maintenance orders and
technical data on the installation, to maps of the network
information system and information about customers.

125

Distribution station

Electricity pylon

Line

Transformer fields

Transformers

Functional locations
Equipment
Object links

Figure 68: Structure of a Supply Grid with Functional Locations and Equipment

The service connection links the supply grid to the data


objects of mySAP Utilities. The service connection is also classified as equipment and can be connected to a corresponding
transformer through an object link. It is also installed in the
house, that is, the connection object.

126

Device locations describe where devices for different divisions


such as electricity (or water) meters and pressure regulators
are located in a connection object. Connection objects and
device locations are functional locations with additional,
industry-specific data. The connection object is the highest

Functional locations
Equipment
Connection
object

Object link

Premise

Technical
installations
Premise

Distribution station
Device location
Service connection
Transformer
Device

Figure 69: Technical Objects at the Customer and Their Connection to the Supply Grid

element in the hierarchy and the device locations are subordinate. The devices are classified as equipment that is installed
in the device location.
You can allocate technical installations to individual apartments (the premises) and in doing so enter technical data. In
Figure 69, the system determines technical data from the lines
leading to the individual houses. Technical installations are
also classified as equipment.

Service Products and Service Objects


Objects in the technical infrastructure must be maintained,
repaired, and upgraded. As a result, utility companies have to
process a large number of work orders on a daily basis. There
is a difference between internal work orders (maintenance
orders) and external work orders with customer references
(service orders) that can be billed to a customer if necessary.

127

Examples of maintenance orders include the following:


Maintenance work on a supply grid
Repairs
New installation, upgrade, or dismantling of technical
installations
Examples of service orders include:
Creation and strengthening of service connections
Energy consultation
Unplanned meter reading
Disconnection and reconnection
In mySAP Utilities, you can create work orders and notifications for all functional locations and equipment that describe
their technical installations.
Many work orders are processed in a similar way. Therefore,
it makes sense to standardize these work orders to simplify
planning, the calculation of costs, and the execution of orders.
In order to do this, you define service objects in mySAP

Utilities. The service object determines what kind of work


order has to be created (internal, external, profitable,
and so on). It also contains the following data:
A description of the work to be done
This lists the steps required to complete an order. Planning
times, materials, and resources are also recorded here.
A responsible work center
Reference to a technical object
A billing rule
This determines how an order is related to an account.
If, for example, you want to carry out an unplanned meter
reading, you select the service object in question. A work order
containing a description of the work and the materials required is then created and allocated to the employee responsible
for the work.
The steps for each process vary for different work orders. Since
it is not feasible to save a service order with its own work description for all data, mySAP Utilities enables you to configure

Connection object,
Device
Description of resources
for work, material ...
external resources

Technical object

Sales order

Instructions

Service order

Service Product

Maintenance or
service order

Service material

Sales view
Price information

Configuration

Characteristics
Values Dependencies

Figure 70: The Concept of the Service Product

128

service objects. To do this, you have to save a maximum set of


instructions that contains all possible process steps, materials,
and resources. The system can determine the correct process
description by using characteristics such as the length of the
service connection, division, and relationships to these characteristics. For example, for a length of 10m, the planned time is
2 hours. The configuration enables you to individually plan
personnel resources as well as the materials and resources
required. A service object can be configured in different ways:
You enter the characteristic values when you select a service
object
The values are transferred from an external system using
a standard interface
If a work order refers to an object that already exists, its
characteristic values can be automatically transferred to
the work order
The last option also works in reverse: You can use a work order
to automatically create a new technical object, and transfer the
characteristic values from the work order to the new object.
Often, it makes sense to not only bill a customer for a service
separately, but to also offer the service as a separate product.
If this is the case, you have to define a service product.
A service product is an enhanced service object. It contains
the same data as a service object as well as an additional service
material. This service material can be called, for example,
new service connection or energy consultation. The service product describes the service from both a sales and a planning point of view. The service product configuration not only
affects the instructions, but also the price. You can define characteristics and relationships in order to calculate the price.
The configuration enables you to plan with increased flexibility and to create an individual quotation for customers. By
using just a few characteristics, you can create a wide range
of services from a standard repertoire of products.

Product configuration is a flexible marketing instrument that


enables you to react quickly to internal or external changes.
For example, if an energy company contracts an external company to carry out underground drilling work, the configuration activates a worklist in the instruction sheet. If the price for
a service connection no longer depends on the feeder length,
the characteristics for pricing can be changed while all other
entries for the service object new service connection remain
unchanged.
You offer a customer a service product and configure it accordingly. If the customer accepts the offer, you create a sales
order. The data from the quotation is transferred to the order.
The system also creates an appropriate service order and job
description based on this sales order. After the work order
is completed, the actual working time and materials used
are confirmed. This information is then used to calculate
the actual costs of the order. The customer can be billed for
the quotation price or the order can be invoiced according
to actual costs incurred.
For example, you can offer the installation of a service connection to your customers as the service product: new service
connection. To do this, you have to define the following characteristics and store permissible values for some of them:
Characteristic

Permissible Values

Surface category

Light, normal, heavy surface

Length of service connection


Connection type

A, B

Breakthrough of a wall
as customer contribution

Yes, No

129

You also define relationships that affect the instructions and


price. For example:
Planned time, in hours, for the excavation =
Length in meters x 0.5
Secure excavation if surface is light
Give customer discount for own contribution

If you want to use service notifications instead of work orders,


you define a notification profile, not a service object. You store
the necessary procedures in an activity schema that corresponds to the instructions in the work orders. In contrast to
work orders, notifications have a more descriptive character.
They do not have to be confirmed or billed, and neither costs
nor revenues can be posted for it.

Service product: Create service connection

SERVICE MATERIAL

Cable per m

60.00

CONFIGURATION

INSTRUCTION

Character

Values

Surface cat.:

Light

Length:

10m

Connection type:

1. Dig trench
Time: 0.5h per m

Excavator per m

150.00

Connection box
Type A

1200.00

Type B

1500.00

Tools: Excavator
2. Secure trench
only for light soil
3. Lay cable

Discount for

Customer

customer

contribution:

contribution

Material: X m cable
Yes
4. Install connection box

300.00

Time: 1h
Material: Connection box
5. Fill trench
Time: 0.2h per m

Offer, Sales order

Figure 71: A Service Connection as an Example for a Service Product

130

Service object

Service order

Service Objects in Business Processes


It makes sense to use service objects and service products for
many processes in asset and work management and customer
service. They enable you to create standardized work orders.
If you do not want to create work orders, you can always create
service notifications using notification profiles. Service objects
can be used to create service orders automatically in different
processes:
Aperiodic meter readings
If a customer wants an interim meter reading, or you want
to carry out a control meter reading, you create an aperiodic
meter reading order. The system simultaneously creates a
service order.
Disconnection and reconnection
A service order can be created together with a disconnection
document. Service orders for disconnection and reconnection can be dependent on the reason for a disconnection.
Different service orders are created for disconnections due
to dunning, disconnections at the request of a customer,
or disconnections due to technical reasons.
Device replacement
Devices must be replaced for certification. You can create
service orders for devices from sample lots and for devices
from the periodic replacement list.
Inspection
You use inspections to check periodic equipment or technical installations. Service orders are created for periodic
checks based on service objects. Alternatively, you can create
service notifications. In Switzerland, for example, inspections
are needed for legally required home installation checks. The
date of the last inspection is saved for every technical object.
You can also define the intervals at which the object is to
be inspected. This produces the date of the next inspection.
The inspection lists are used to plan inspections. Work orders
or service notifications are based on these inspection lists
and on different criteria (for example, for a particular city

or street). In addition to the periodic inspections, there are


also aperiodic inspections. These are divided into two groups:
Initial inspections
These are executed for new technical objects.
Advanced inspections
In this instance, the next periodic inspection is moved
forward. An advanced inspection can be either planned or
unplanned (for example, a service technician decides on
site to inspect a technical object without a planned order).
SAP provides predefined front office processes for periodic
and aperiodic inspections. In addition to creating orders
in these processes, you can also use service objects, service
projects, and service notifications to create work orders in
the following ways:
In a front office process in the interaction center
Here are examples:
A service order for repairing a device if a customer
complains about a defective device
A service order for installing a device when a new
connection object is created
Within
a workflow

The workflow service connection with quotation


is used as an example later in this chapter.
In the hierarchy structure of functional locations and
equipment
In the structural display, you can use service objects
to create maintenance orders for individual objects
of a supply grid.
By
creating a sales order with a service product
Service objects and notification profiles for the processes
described here are already predefined in mySAP Utilities. You
can also easily define further service objects, service products,
and notification profiles.

131

Multilevel Service Objects and Products


When mapping the technical infrastructure, you can create
hierarchies using functional locations and equipment. It often
makes sense to use order hierarchies when working with work
orders: A main order can be allocated various suborders, and
different work centers can be responsible for the suborders.
You can also create order hierarchies using configurable service
objects and service products. To do this, you have to define a
hierarchy of service products. If you enter a number of characteristic values, the system automatically creates the complete
order hierarchy, including all orders that belong to the hierarchy. An example of this is the expansion of a supply grid. The
instructions for the multilevel service object grid expansion
can contain the following steps:
1. Excavation work
2. Service object: Insert pylons
3. Cable work
4. Service object: Install transformers
Two service objects with their own worksteps and characteristics are integrated in steps 2 and 4. A service order for the grid
expansion is generated and further service orders are created
as suborders for inserting the pylons and installing the transformers.
Workflows
Many business processes always follow a similar pattern. If
more than one employee is involved in a process, or if the
process runs over a certain number of days, it is better to coordinate the business process using a workflow. You can define
your own workflow and use or adjust the following workflows
that are already defined in mySAP Utilities:
Service connection with or without customer quotation
Process service order
Disconnection collection procedure
Disconnection at the customers request
Disconnection and monitoring of vacant status

132

The workflow service connection with customer quotation


is described in the following in a shortened form:
1. A customer inquires about a service connection
2. The agent selects the corresponding service product, configures it, and creates a quotation. The quotation price is taken
from the configuration.
3. If the customer accepts the quotation, the agent decides if
the customer has to make a down payment.
4. The agent receives a message in his or her inbox as soon as
the customer has made the payment. The agent then creates
a sales order. The data for this is transferred automatically
from the quotation. At the same time, the system creates a
service order including a work description and
a material withdrawal slip.
5. The workflow forwards the order to the technician. The
technician takes the necessary materials from the warehouse,
executes the task, and confirms the time needed to complete
the task.
6. The agent receives the confirmation in his or her inbox
and closes the service order.
7. The workflow starts the create connection function.
The agent enters the technical data and either allocates
the service connection to an existing connection object,
or creates a new one in the system.
8. The workflow forwards the order to invoicing. The down
payment and any other requests that may have been made
are included in the bill during bill creation.
You can change, delete, or add steps in this predefined
workflow using the SAP Workflow Builder.

The Integration of Systems


In addition to the interfaces available in mySAP PLM (for example, for SCADA systems), mySAP Utilities provides you with a
range of other interfaces to systems that are frequently used in
the utilities industry.
The structure of a geographical information system (GIS) is
expensive especially the entry, maintenance, and digitalization of the geographical data. Therefore, the system must be
used as effectively as possible, and, for many business processes,
this includes effective integration with different SAP systems.

One example of this is the planning of a new grid: The technical and spatial planning is carried out in the GIS, the economic
planning in mySAP Utilities. This enables you to estimate the
cost of the grid.
Marketing campaigns that target individual customers in a
region are another example of this interplay: Where are large
numbers of customers changing to a competing company?
Which potential gas customers live close to a supply line? The
GIS determines this data and transfers it to mySAP CRM. You
can easily integrate GIS and SAP systems, using the GIS Busi-

MDI
Mobile Devices
Confirmation of service orders
GBC

mySAP Utilities
asset and work management capabilities
Confirmation of service orders
CADS

Breakdown reports
and orders
Status
monitoring
OMS

Geo data

SCADA
Distribution station
breakdowns

GIS
AM/FM

Connection information

Figure 72: Interfaces from mySAP Utilities to External Systems

133

ness Connector (GBC). In addition to the GIS, you can also


integrate other object-oriented systems, such as network information systems (NIS) through the GBC. The GBC is a passive
middleware. This means it mediates between the GIS and SAP
without starting any processes of its own. If a process that
requires data or changes data from the GIS is triggered in the
SAP system, the GBC ensures that the necessary actions are
executed in the GIS. This interaction takes place in both directions. The GBC ensures that the correct data is sent from one
system to the other, and that it can be retrieved without any
problems. This prevents inconsistent data in either system.

The GBC also has its own data storage. It can temporarily store
data and tasks if a system is not available, enabling you to execute asynchronous processes. The GBC accesses methods from
objects in both systems. The GBC knows the SAP methods in
the Business Object Repository (BOR) and is informed of the
GIS methods being used during configuration. At the same
time, GIS and SAP methods are grouped as tasks and the data
flow between the two systems is defined. The GBC uses these
mappings to generate the interface program code that guarantees that the process runs correctly and the data remains consistent.

GIS

SAP
GIS Business
Connector

Methods

GIS
application

SAP
applications

Middleware

Methods

Enhanced
GIS application

Enhanced
SAP application
Business objects

Figure 73: The GIS Business Connector

134

Business objects

Example: A new service connection is created in mySAP


Utilities. This must also be recorded in the GIS. As soon as the
method create service connection starts in mySAP Utilities,
the GBC calls up the corresponding method in the GIS and
sends the technical data from the SAP system to the GIS. The
service connection is then automatically created in the GIS,
and the GBC connects the two objects. It also reminds the GIS
agent to mark the service connection on the map and to enter
any further technical data. This process also works if the service connection is created first in the GIS. There is no leading
system. For this integration to take place, the GIS must be
object oriented. This means that the GIS must use objects
and methods that the GBC can access. To ensure that the GBC
can work with different object models (for example, DCOM
or CORBA), Control Broker from the company Actional
is used to connect the GBC and GIS. The GBC integrates the
systems at business process level, while the Actional control
broker connects them technically with each other. SAP delivers
the GBC and the Actional control broker in the GIS connector
package.
mySAP Utilities can transfer data to outage management systems (OMS) and computer-aided scheduling and dispatching
systems using this work management interface. Outage management systems analyze disturbances in the supply grid. If
there are a number of disturbances in a particular section of
the grid, the system decides whether there is a central disturbance such as a transformer outage. The system can trigger the
repair of the system and determine the customers affected. In
order to do this, it accesses connection information from a GIS
or an NIS. mySAP Utilities sends outage notifications to the
OMS and receives information on how the problem is solved,
and the time needed to do so. You can allocate orders to work
centers or individual employees using the planning table in
mySAP PLM. The planning table is especially suited for orders
with longer runtimes such as installation upgrades and construction orders. Computer-aided scheduling and dispatching

systems plan in detail and distribute short-term work orders


based on criteria such as the following:
Required personnel profile
Distance, journey time
Priority
Confirmation of appointment
mySAP Utilities sends work orders and notifications to the
computer-aided scheduling and dispatching systems. Once the
work has been carried out, the computer-aided scheduling and
dispatching systems transfer the data (for example, resources
used, and meter reading results) back to the SAP system.
Data from mySAP Utilities is transferred to subsystems (for
example, mobile devices) using the Mobile Data Interface
(MDI). Information such as meter reading results or notifications of completed repairs are transferred from work being
carried out on site. You can determine which data is sent to
the mobile device and uploaded again into the SAP system.
Changes made to customer data are an example of this: A customer notifies a technician that his or her telephone number
has changed. The technician enters the new number in a
mobile device. This data is later uploaded and automatically
processed in the system.
You can use the disaggregated scenarios from asset and work
management for sales and service processes that run in different SAP systems or in different company codes within an SAP
system. These scenarios process customer-oriented substeps
such as quotations, sales orders, and invoicing, in one SAP system. The order-related substeps, such as service orders and
resource planning, are always processed in a second SAP system. New service connections are an example of this: A utility
company gives a service company a contract for creating new
service connections. To ensure that the business process runs
smoothly, from the sales order through the service order to
invoicing, the required data is automatically sent between the
two systems using IDocs (intermediate documents). The IDocs
for this process are contained in mySAP Utilities.

135

Additional Functions
Appointment scheduling provides employees with an overview
of the service team capacity in the interaction center. This
enables the employee to propose an appointment for a service
for example, repairing a device, or an aperiodic reading
and to directly schedule this appointment.
You can allocate a supervisor to a connection object (for
example, a janitor). When a work order is created for this
connection object, the supervisor is automatically transferred
to the work order.
In some parts of the USA, permits from local authorities are
needed before work can be performed. For example, a customer must have a permit from the local authorities before
he or she can connect their motor home to an electricity grid.
As a result, a service order is always created with a permit.
The order is locked until the permit is approved. You can
determine which regions require a permit for different service
objects and service products.

136

SOLUTION BENEFITS

Asset and work management capabilities from mySAP Utilities


are the cornerstone for efficiently running and maintaining
your installations as well as the basis for successful customer
service. mySAP Utilities delivers these benefits:
Accompanies the complete life cycle of an installation, documents the measures taken, stores the history, and supplies
your employees with all the necessary, up-to-date information they need to make informed decisions.
Enables you to use modern maintenance strategies and
reduce costs for inspection and maintenance work.
Reduces errors and redundancies in the dataset of your
installations, and simplifies the entry and maintenance
of data.
Allows you to control all costs and, as a result, provides
you with an overview of the total cost of ownership for
your installations.
Groups together different industry-specific functions in one
solution such as work clearance management, safety at work,
periodic replacement, and the creation of service
connections.
Ensures that your employees are scheduled in the most
effective way possible, thus improving customer service.
Enables you to offer services as products and control
customer service costs.
Integrates other systems that can be used in mySAP Utilities
from GIS to mobile work scheduling and makes it easier
for your employees to work with the different systems.

mySAP BUSINESS INTELLIGENCE


FOR THE UTILITIES INDUSTRY
SAP Business Information Warehouse (SAP BW) is the tried and
tested data warehouse solution in mySAP Business Intelligence
(mySAP BI). Within the framework of mySAP Utilities, SAP
BW distinguishes itself through its predefined report and
analysis scenarios for the utilities industry, and through its
ability to format mass data efficiently in terabytes. These extensive reports and evaluations can be tailored to individual roles
in a company, and can be linked together using analytical
applications. This provides new insights into company processes as well as a strong starting point for business processes and
closer customer relations. Utilities companies use SAP BW to
tailor their processes and products more towards the demands
of their customers. By using industry-specific reports and
analysis scenarios (Business Content), as well as analytical
applications, you can secure existing markets and develop new
potential for growth.

The utilities industry is undergoing far-reaching changes.


Deregulation and liberalization are defining both the international and competitive landscape. At the same time, private
and non-residential customers are becoming increasingly
sensitive with regard to prices and services. Business processes
must be extensively analyzed to ensure that complex processes
including the generation, transport, sale, and resale of electricity can be valuated whenever necessary. This means that
enormous amounts of data from internal applications and
external sources must be processed and analyzed. Consequently,
effective measures for increased flexible company control and
more efficient processes can only be derived from clearly structured data. mySAP Utilities is a powerful business solution for
the utilities industry that can be ideally combined with SAP BW.
The extensive business content of the data warehouse solution

I have to increase the profitability in my region.


When is break even reached for several customers?
Which customers cant be supported profitably?
Where can I increase my business?
Which campaign was successful?

Sales

Profitability

Delivery

Human resources

Marketing costs

SAP
R/3

Market share

NonSAP

Quality

Sales/service costs

mySAP
Utilities

mySAP
CRM

Market potential
Customer satisfaction

Provider

File

Figure 74: Questions Asked and Demands Made by a Company

137

from SAP is geared towards the specific demands of the utilities


industry. At the forefront of this solution are stock values,
processes, sales, and the most important key figure categories,
including total revenues from utility services, discounts, consumption, demand, rental price, and changes to stocks. Business Content (predefined role and task-related information
models that can be suited to enterprise-specific requirements)
for the utilities industry offers a wide spectrum of report and
analysis scenarios for the utilities industry. These are based on
fundamental elements of SAP BW, such as InfoSources (data
retrieval), InfoCubes (data retention), a powerful OLAP processor (online analytical processing), the graphic user interface

(BEx), and Web reporting. SAP BW allows you to evaluate different sources and return the results to the operative output
systems (closed loop). Specialists and managers can then make
decisions based on the most up-to-date information. This
enables you to monitor contracts and revenues as well as to
control individual conditions.
ANALYSIS OF STATISTICS

SAP BW also contains enhanced Business Content based on


mySAP Utilities. This is used for stock, transaction, sales and
consumption statistics, as well as master data objects from
mySAP Utilities such as contracts, contract accounts, and con-

mySAP Enterprise Portal

Campaign target group


Segment Builder

mySAP BI

mySAP CRM

Orders, Activities, Opportunities, Contracts

Sales revenue,
Consumption data,
Master data

Contract creation
and changes,
Service orders

mySAP Utilities

Figure 75: Example of Campaign Management

138

Stocks and
transactions,
costs, contacts

Opportunities,
Family tree

nection objects. These statistics can also be combined in SAP


BW using new analytical applications (analytical CRM). The
ability to combine and analyze these statistics provides you
with new insights into datasets and new resources for marketing and sales as well as a more customer-oriented, profitable
corporate management within liberalized markets. The following examples illustrate parts of SAP BW with a closed system.
An Example of a Marketing Campaign
You want to start a gas marketing campaign in mySAP CRM,
using a target group from mySAP BI. The target group is made
up of data that has been recently and periodically transferred
from mySAP Utilities. For example, you create a list of all customers that live in a particular area, whose consumption last
year was higher than 10,000 kWh. They do not have a gas contract but can easily be connected to an existing gas grid. These
customers could all be potentially supplied with gas. You then
start an analysis of the sales statistics and accompanying mySAP
Utilities master data. In mySAP CRM, you use this target group
in the campaign and, once the campaign is finished, you create
and change contracts for customers who are interested in being
supplied with gas. This contract information is automatically
copied from mySAP CRM to mySAP Utilities and any changes
are made available to SAP BW. Using SAP BW, you can then
analyze how successful the campaign was, and use these results
for further campaigns. Success, for example, can be measured
in the increased number of gas contracts, or in the increase in
profits for the gas division.
An Example of Change of Supplier
After analyzing transaction statistics, you establish that there
has been a considerable increase in terminated contracts
caused by customers changing suppliers. By using Business
Content, you can check whether customers who terminated
their contracts registered a high level of complaints, and if so,
what was the nature of the complaints. At the same time, you
can also use the consumption statistics to check how much
revenue your company made from these customers. You can
then use this information to forecast losses as well as make

decisions on any further action. For example, you might consider starting a campaign to win back these customers. If you
do, you can select target groups from consumption statistics
and transfer them to mySAP CRM. The success of a campaign
can then be analyzed using consumption statistics based on
expected consumption and profit of new or changed contracts.
There are, of course, other scenarios based on different statistics. Some of which are described as follows:
Stock Statistics
Stock statistics show you how the stocks of your utility company (for example, customers and contracts) develop. The stocks
are evaluated at different levels and in the context of the whole
company. They are also analyzed chronologically and historically down to premise level. Business Content enables you to
display all changes to stock statistics and access individual contracts especially during master data reporting.

Figure 76: Overview of Stock: Customers and Contracts

You can also view the historical development of your contracts in each division and company code and identify trends
in advance. You can then compare these trends with the stock
statistics for your business partners. This analysis also supports

139

the subdivision of statistics according to division, company


code, business partner category, and so on. The following stock
statistics are available in the mySAP Utilities solution:
Business partner stock statistics
This InfoCube contains information about your business
partner stocks. The stock is stored historically and can be
analyzed based on partner attributes.
Contract account stock statistics
Contract stock statistics
Installation stock statistics
Connection object stock statistics
Premise stock statistics
Device location stock statistics
Contacts stock statistics
In mySAP Utilities, activities are automatically entered in
the call center by means of contacts. Contacts can be divided
into different categories such as complaints, rate change, and
move-in. They can be reported, for example, by telephone
or e-mail. Contacts contain a lot of information about the
utilization of the call center and provide an overview of customer behavior.
Devices stock statistics
This InfoCube contains information about device stock. The
stock is stored historically. It can be analyzed based on the
device and navigation attributes of the device category. Data
is stored on a monthly basis.
Reference values stock statistics
Disconnection/reconnection
Normally, disconnections in the utilities industry take place
because of customer requests, vacant status, and dunning.
A disconnection normally requires considerable personnel
expenditure and is, therefore, quite an expensive process for
a utility company. A continuous analysis of disconnections
and reconnections, as well as disconnections that have not
yet been reconnected is an important source of information.
A company can use this information to identify trends and
dependencies at an early stage and react to them in an appropriate manner. Disconnections and reconnections must
also be analyzed for monthly reports to regulation authori-

140

ties. Here, it is important that relevant disconnection information is saved and changes are entered at the document
level in SAP BW. You can evaluate disconnection reasons and
objects (business partner, connection object, device number,
and so on) and evaluate the disconnection date and duration
of the disconnection. You can also create an overview of the
number of disconnections based on particular attributes.
Historical disconnection/reconnection
This InfoCube only contains aggregated information about
the disconnection of customers and objects. To avoid a large
number of changes being posted, only reconnected disconnections are posted in this InfoCube. It is designed to analyze
disconnections quickly and historically most analyses are
based on business partners and connection objects. You can
also execute analyses based on regional characteristics.
Transaction Statistics
You can use transaction statistics to analyze important company processes that are executed manually by employees. This
mainly involves analyzing the costs of individual transactions
(such as bill creation, reversal, move-in/move-out, and device
replacement) to target specific areas for cost reduction. Transaction statistics provide you with the number of manual processes in your company. To evaluate these processes using your
internal company costs, you must multiply the costs in the
query by the number of processes.
The following transactions statistics are of particular interest:
Move-in/move-out transaction statistics
This InfoCube forms the data basis for analyzing move-ins
and move-outs at the premise. Data is stored on a monthly
basis.
Rate maintenance transaction statistics
Billing-related device installation/removal transaction
statistics
This InfoCube forms the data basis for analyzing billingrelated device installation and removal (when the device was
allocated to a utility installation). Data is stored on a monthly basis.

Single invoicing transaction statistics


This InfoCube forms the data basis for analyzing single
invoicing. Mass invoicing runs are not included. Data is
stored on a monthly basis.
Aperiodic billing transaction statistics
This InfoCube forms the data basis for billing analysis.
Periodic billing is not included. Data is stored on a monthly
basis.
Technical device installation/removal transaction statistics
Sales Statistics
Based on demand-related key figures from the whole company, sales statistics provide different views of sales data. Therefore, they help you analyze quantities and amounts of demand
and work, as well as process revenues. You can use this information as a basis for optimizing your rate and price structure.
Additionally, you can evaluate local authority franchise payments or revenue developments according to industry, division, or business partner. With SAPs predefined Business Content, utility companies can also display taxes to be paid on an
aggregated basis, for example, according to sales district (jurisdiction code) a function that is very important in the USA.

Consumption Statistics
In marketing, it is not only important to know what quantities
and amounts were invoiced for a particular period. Consumption that has not yet been billed is equally important. You can
only create an overall view of a customers or customer groups
potential revenue if you have both sets of statistics. Consumption statistics provide you with these. Based on current data,
you can select target groups according to certain criteria (for
example, all customers whose consumption in the year 2002
was more than 10,000 kWh) and target them with new services
and products
Consumption values and sales for target group selection
This InfoCube helps you analyze consumption values and
revenues for certain target groups. You can select target
groups according to different business partner characteristics.
Navigation attributes on the various levels of the different
master data objects including billed contracts and installations help you do this.
Consumption values and sales for campaign analysis
This InfoCube enables you to analyze sales from contracts
that were allocated to a campaign in mySAP CRM. You can
use the sales and quantity key figures for billed and extrapolated consumption values to carry out these analyses.
The CRM product is updated in the InfoCube as a further
characteristic for campaign analysis. Here are two examples:
The customer wants a new contract as the result of a
campaign
The customer wants to change products as the result
of an upselling campaign

Figure 77: Sales Statistics According to Division

141

Unbilled Revenue Reporting


Unbilled revenue reporting determines and evaluates the sold
and billed quantities for a closing fiscal period. This can be
either a companys annual or monthly balance sheet. Utilities
companies have particular demands when generating a company balance sheet since not all customers will have been billed
and entered in accounting when the balance sheet is created.
Appointments for customer meter readings are distributed
across the whole year especially in rolling billing. In this case,
unbilled revenue reporting considerably influences the business results for a fiscal period. As such, companies do not have
the statistical data for the period between the last time billing
took place and the balance sheet key date. This data is required
for creating a balance sheet and is generated during unbilled
revenue reporting. This includes, on the one hand, forecast
data for the current fiscal period, and on the other, the differences between the statistical data of the previous period and
the actual available data. The influence that the results have
on the balance sheet changes according to the meter reading
procedure used, and particularly affects annual consumption
billing.
If the key date meter reading procedure is used for all customers, and the meter reading date is the same as the balance
sheet key date, there is no quantity to prorate.
The importance of unbilled reporting increases the further
away the meter reading date for a customers annual consumption billing is from the balance sheet key date.
Unbilled revenue reporting can also be used midyear to determine the expected actual operating results for the whole fiscal
year. You can select any key date, which means it can also be a
future date. Reporting can be executed on a monthly basis or
every three months.

142

Individual Procedure
In contrast to the flat-rate procedure that, in addition to the
energy feeding volume, only uses the data from billing documents in billed contracts, the individual procedure analyzes
all contracts individually. For each contract, the system determines the period in the fiscal/forecast period for which the
contact has not yet been billed. The system executes a billing
simulation for this period. During billing simulation, the consumption for each contract is extrapolated using the weighting
procedure. The data from the billed documents, together
with the data from the simulated documents, produces an
estimated value for consumption and revenues of the periods
in question.
Unbilled Revenue Reporting with mySAP BI
You can use SAP BW and SAP Strategic Enterprise Management Business Planning and Simulation (SEM-BPS) to execute unbilled revenue reporting and forecast and analyze
planned results directly in mySAP BI. Billing data from the
individually extrapolated contracts of the forecast/fiscal period
are stored in an InfoCube in SAP BW. Actual data from the
sales statistics for the same period was previously transferred
to this InfoCube. By using planning tools in the SEM BPS, you
can adjust quantities and amounts that planned results for
future periods. A multiprovider (analysis of several InfoCubes)
enables you to compare forecast results (unbilled revenue
reporting InfoCube) with the actual values (sales statistics),
and, if necessary, adjust the planned results in SEM BPS.
Conclusion
Unbilled revenue reporting in mySAP BI provides you with
versioned, extrapolated, and actual data from past periods. It
also enables you to use the solution to forecast and plan future
periods. By constantly comparing actual data with different
forecast versions, you can identify deviations at an early stage
and react accordingly. In other words, mySAP BI, in combination with mySAP Utilities, supports comprehensive and strategic planning based on individual billing data.

ANALYSES OF CONTRACT ACCOUNTS RECEIVABLE


AND PAYABLE (FI-CA)

Open and cleared items provide management with access to


a wide variety of reports. Analyzing cleared items allows you
to check and compare the efficiency of different dunning procedures. It also enables you to determine the time when due
amounts were paid, and to influence communication with
customer segments. Open items form the basis of legally
required reports, such as the 30-60-90 day report. This report
displays an overview of the due and overdue items for one key
date in the grids 0, 1-30, 31-60, 61-90, and more than 90 days.
The historical analysis of data reveals trends and produces
valuable information for decision-making processes that have

considerable influence on a companys success. Analyzing


cleared items provides you with information on your customers payment habits concerning factors such as payment
methods (cash, check, and bank), dunning, and regional
characteristics.
ANALYTICAL APPLICATIONS

Analytical applications enable the process-oriented integration


and analysis of structured and unstructured content from different sources and applications. You can display information
within a specific business context. You can use this information
as the basis for making decisions and putting these decisions
into effect.

Enterprise Portal
Web Content Management

Collaborate

E-Analytics

CRM
Analytics

Decide

SCM
Analytics

Financial
Analytics

HR
Analytics

PLM
Analytics

Custom-Built
Analytics

Structured
Data &
Content
Analyze

Adjust

Customer
Relationship
Management
Unstructured
Information
& Content

E-Commerce

Others
(Siebel, i2,
Oracle, ...)

Supply
Chain
Management

Financials

Human
Capital
Management

Product
Life-Cycle
Management

Figure 78: Analytical Applications

143

Controllers can analyze the payment behavior of certain customers in relation to dunning procedures and bill amounts.
Being able to check your customers payment history (and
dependability) and methods for the entire year is an essential
way of ensuring liquidity.
Key account managers can link consumer and sales statistics
with cost data. This tells them how valuable a customer is, and
whether it is worth using special offers to retain a customer
who is considering changing contracts.

Figure 79: Customer Lifetime Value

In the framework of analytical applications in mySAP CRM,


the content of mySAP Utilities particularly supports customer
life time value (CLTV). To do this, the system uses the move-in
and move-out dates from the utilities contract that was used in
the calculation. CLTV uses the existing customer base to predict both expected consumption values for the future, and the
customer retention rate that is, how many customers
the utility company can expect to keep.
Additionally, analytical applications (used within the framework of analytical CRM) help utility companies to get the
most from their customer relationships as well as improve
potential revenue. When you know more about the needs of
your customers and how they can add to your overall results,
you can be more certain of the decisions that you make. By
analyzing the statistics described in this chapter, SAP BW provides decision makers in marketing, controlling, accounting,
and customer service with information that helps them
increase profit in their areas. Here are some examples:
Campaign analysts receive information about sales revenue
from new contracts or about the number of concluded contracts that resulted from a campaign.

144

Device managers can link device categories with regional or


repair data. This makes it easier for them to control devices,
or recognize patterns in the breakdown behavior of individual
device categories.
SOLUTION BENEFITS

SAP Business Information Warehouse offers a wide range of


advantages:
The ability to compare data from different sources using
a consistent information model
Tried and tested pre-configured and universal solutions
The ability to immediately use Business Content specifically
designed for the utilities industry
Seamless integration into all mySAP Utilities applications
A central data pool for strategic SAP solutions
Openness that enables you to combine SAP BW with every
internal and external data source
Flexibility using the ability to change and enhance all
business objects
SAP BW can be implemented immediately or on a long-term
basis as a result of permanent, technological development
It can be scaled to fit and be used profitably in every company regardless of size
User-friendliness and intuitive operation
Strategic corporate management using predefined key
performance indicators

mySAP ENTERPRISE PORTAL FOR THE UTILITIES INDUSTRY


Portals provide you with a central and personalized point of
access to the data that you need to do your job regardless
of whether the information comes from an application, a database, documents, or the Internet. mySAP Enterprise Portal
provides companies with a platform that increases the speed of
internal and cross-company processes. System boundaries are
no longer visible. You are presented with a user interface that
unites all systems. Single-sign-on technology means that you
only have to log on to the portal once and can then access all
connected systems. All you need is a user name and a password.

mySAP
Utilities

SAP CRM

Intranet

SAP BW

Shop

Groupware

Internet

...

mySAP
Enterprise Portal
One interface
Internet browser
Role-specific
Single logon

Figure 80: Easy Access to a Heterogeneous System Landscape


BUSINESS PACKAGES AND IVIEWS

Improved access and tailor-made portal content for specific


internal and external roles for a utility company enable you to
execute tasks faster, and as a result, improve customer service
and increase efficiency. Portal contents are grouped together
in business packages. The content is displayed using iViews.

The following types of iViews exist:


Access to applications
These iViews enable you to access SAP applications and
non-SAP systems directly, for example, a Web-compatible
geographic information system (GIS). SAP offers a wide
range of preconfigured iViews that are tailored towards
users and their roles in a company, for example, displaying
business partner information or creating a maintenance
report.
Business intelligence
These iViews display all relevant analyses, statistics, and
reports at a glance and also as graphics. This improves both
the decision-making process and the quality of the information that forms the basis of your decisions. For example,
a key account manager is informed that several customers
contracts are about to expire. In the past, he or she might
have overlooked this. Now, they can arrange appointments
with these customers to renew their contracts or discuss
changes to prices or conditions.
Knowledge management
These iViews are an extensive solution for the integration
and management of unstructured documents. You can use
knowledge management to obtain all kinds of documents
relevant for your work, regardless of the system in which the
documents are located. Search and classification functions
allow you to quickly access relevant information and structure company-specific taxonomies. An integrated content
management system manages the complete life cycle of the
documents. If there are new documents, the registered users
are informed of this through an alarm function. Special collaboration services allow experts to work together, regardless
of where they are and what time it is.

145

Internet content and services


Nowadays, all kinds of information can be found on the
Internet. However, you do not normally have time to siphon
off the relevant information and news from the flood of
information. mySAP Enterprise Portal collects reports and
statistics from the Internet for specific roles in a utility company. You do not have to search for information because it is
automatically sent to you. Key account managers, for example, can immediately view all new information and data that
refers to their companies. Not all of the information is immediately displayed, however. The Internet services can be
customized in such a way that you only get the information
that you really need. This enables companies to recognize
potential sales at an early stage and contact customers
accordingly.

Original source

Structured

Unstructured

Internet
content and
services

Access to
applications

Enterprise
Portals

Business
intelligence

Knowledge
management

Extracted and formatted information

Figure 81: Types of iViews

146

The number of business packages and iViews is constantly


increasing. As a result, only a few business packages are
described in the following as examples that are of particular
interest for utility companies. To see the current portfolio
and information about all business packages, go to
www.iviewstudio.com.
Portal User Business Package
This standard business package integrates typical groupware
functions such as e-mail, calendar, and address book. It can be
connected to a Microsoft Exchange or a Lotus Domino server.
Employee Self-Services Business Package
By using the employee self-services (ESS), employees can
create, display, and change personal data using the company
portal. They can use the iViews that access mySAP Human
Resources (mySAP HR) to request a vacation, change bank
details, or enter travel costs. As a result, human resources
management processes can be simplified and standardized.
Manager Self-Services Business Package
In todays business world, quick response times are extremely
important and decisions have to be made as quickly as a possible. To make the right decisions, managers must have fast and
reliable access to all relevant information. However, managers
seldom have extensive access to current and relevant information. Acquiring this information normally takes up a lot of
time and money. Information systems available on the market
today or reports that are released by central departments only
partially meet the demands of problem analyzing and problem
solving. They only start to address problems such as, How can
I reduce costs per employee by 5%? mySAP Enterprise Portal
can remedy this situation. It represents a point of access for
data and information from mySAP HR and mySAP Financials
(mySAP FI). This data can be used to make the right decisions

quickly and effectively. The business package helps managers


to effectively perform their administrative and planning tasks.
This includes recruiting personnel, carrying out annual employee reviews, and compensation planning. As a result, this
business package enables managers to perform all tasks in their
areas of responsibility more effectively, while controlling processes. Managers can better manage their cost and budget
responsibilities, including budget planning and control, cost
analysis, and posting adjustments. They can also use the business package to execute these tasks in controlling.
Key Account Management Utilities Business Package
In the deregulated utilities market, increasing customer retention by improving customer satisfaction is becoming more
and more important. You can achieve this by making business
processes that directly effect customers faster and more efficient. Non-residential customers (trade, industrial, chain store,
and outline contract customers) are particularly important
for utility companies since this customer group represents the
majority of the sales revenue a company makes. The central
contact person for these customers is the sales manager in the
utility company the key account manager.
Key account management utilities business package provides
you with a user-friendly interface for this user group. Using a
Web browser, you can access the integrated mySAP Customer
Relationship Management mySAP Utilities solutions, as well
as the SAP Business Information Warehouse. All information
displayed is tailored to the needs of a key account manager.
The business package helps key account managers to complete
their tasks in the best way possible from sales planning,
acquisition, and offer processes, to the final monitoring of
contracts and success analysis.

The following example explains how a portal supports a key


account manager during his or her daily work: Mr. Smith
is the key account manager at Energy Everywhere Inc. He is
responsible for electricity and gas customers in the southwest
region. When he logs on to his portal, he is automatically
informed of a sales opportunity at the air-conditioning system
manufacturer Cooling Installations Inc. where an electricity
contract is about to expire. Cooling Installations Inc. is a B
customer for Mr. Smith and he has not visited the company
very often. As a result, he wants to find out more about them.
On the customer data sheet, Mr. Smith can see that Cooling
Installations Inc. has contracts for electricity and gas. He can
also see that there were three outages in the last year and that
Mr. M. Brown, the chief financial officer of Cooling Installations, has complained twice about incorrect dunning procedures. Mr. Smith does not believe this to be a good starting
point for renegotiating the electricity contract. Mr. Smith calls
up further details in the load profile area of the customer data
sheet and ascertains that Cooling Installations consumes most
electricity at off-peak times. He checks the data in the electricity
contract and realizes that the contract can be improved. By
using an off-peak package, he can offer the company a contract
that better suits its consumption pattern. Mr. Smith asks his
secretary to arrange an appointment with the energy purchasing department of Cooling Installations Inc. He then receives
a message that schedules a visit to Cooling Installations in the
coming week. This activity is already entered in Mr. Smiths
calendar. Shortly after this, Mr. Smith creates a new sales opportunity for the contract that is about to expire so that the new
contract appears in his pipeline. The next day, he creates an
offer for Cooling Installations that contains the new prices for
the off-peak package. He prints the offer out and, a few days
later, visits Mr. Jones, the energy purchasing manager at Cool-

147

ing Installations. Mr. Jones realizes that the company can save
money with the new contract. Before signing the contract,
though, he wants to speak to the managing director of Cooling Installations Inc. In the meantime, Mr. Smith updates the
sales opportunity and changes the probability from 30% to 75%.
The changes are automatically transferred to his sales pipeline.
Including the Cooling Installations opportunity, Mr. Smith has
five new, promising negotiations in his pipeline that he has a
high probability of closing. A few days later, Mr. Smith receives
an e-mail from Mr. Jones confirming that Cooling Installations
is willing to sign the contract. Mr. Smith then starts a work-

flow for the back office with the Cooling Installations offer
attached so that the contract can be created. At the same time,
the departments responsible for generating energy and grid
usage are informed of the developments. Mr. Smith is also kept
up to date of the contract status.
Business partner information makes up the main part of the
key account management business package. This information
is stored at different locations in different systems and is mainly used for customer service, preparing site visits, and creating
offers. It can also be used for analyzing and planning the devel-

Sales
planning

Marketing

Management

Success
analysis

Leads/
Opportunities
9

Grid
operation
Site visits/
Events

BUSINESS
PARTNER
INFORMATION

Acquisition/
Contract renewal

COMPETITOR
INFORMATION
Back office

ACTIVITIES
MANAGEMENT

7
Contract
monitoring

4
Offer
creation

Call center

Figure 82: The Sales Process for a Key Account Manager

148

6
Contract
status

Contract
conclusion/
Loss analysis

Controlling

opment of sales revenue and energy consumption. There are


two different ways of viewing the business partner information through an overview:
Overview of all business partners
The following information is included in this overview:
A list of the most important customers
The top n customers according to sales revenue
Future activities
List of expiring contracts
New sales opportunities (leads/opportunities) in each area
of responsibility
Overview
of one business partner

The following information is included in this overview:


Overview of addresses
Overview of groups, structure, chain store, or outline
contract customers
List of business agreements
List of contracts
List of contracts expiring in the near future
Overview of contract details
Overview of consumption history
Load profile display
Overview of premise details
Overview of executed and planned activities/contacts
(telephone, visit, mailing, letter)
Overview of past and future sales opportunities
(leads/opportunities)
There are also two views available for reporting and analyses:
Overview of all business partners
This overview contains, amongst others, the following analyses that include all the business partners for which the key
account manager is responsible:
Who are the top n business partners according to sales
revenue or consumption?
Which business partners have considerably increased or
decreased their sales revenue or consumption compared
to the previous year?

Overview of one business partner


This overview contains, amongst others, the following
analyses for individual business partners:
How has the sales revenue from business partner X
developed in comparison to the previous year?
How have the consumption values of business partner X
changed in comparison to the previous year?
How does the actual consumption pattern compare to the
planned consumption pattern?
Activities and opportunities are also central objects of these
business packages. You can also display, change, and create data
in the simplest possible way using the portal.
Business Package Assets
Employees and external partners all require access to installation-relevant data that is stored in mySAP Product Lifecycle
Management (SAP PLM). A service technician, for example, has
to display reports to be processed; a maintenance supervisor
needs to know the status of the orders for which he or she is
responsible; an employee from the production department
wants to create a report. The business package can be modified
to fit the different roles. The following are examples of roles
that can profit from the implementation of business package
assets:
Maintenance and service technician
Maintenance supervisor
Installation engineer
Maintenance planner
Maintenance manager

149

With regards to the utilities industry, these portal contents can


be used in power station maintenance, high and low voltage
grids, or for gas and water pipes. The following iViews are part
of the business package and can be used to display information:
Installation structure
Detailed information on equipment and functional locations
Reports and orders on installations
Status of reports and orders for which a user is responsible
Documents referring to installations
List of favorites for equipment, functional locations, and documents
Create reports
The ability to integrate non-SAP systems such as a Web-based
GIS or SCADA system in the portal is of particular interest in
this case. A portal can be used in the following way: Mr. Miller,
maintenance planner for gas pipes in Energy Everywhere, logs
on to his personalized business portal that has been tailored to
the role of maintenance planner. In the reports section, he
can view all reports that lie within his area of responsibility.
He opens the first report on his installation. He then looks at
further information on installation structures, functional locations, and grid equipment. This data is stored in mySAP PLM.
Mr. Miller then inspects all documents (such as drawings,
handbooks, and instructions) that are related to these installations, functional locations, and grid equipment. He can also
access information on products from manufacturers of grid
monitoring systems and look for more detailed information
on relevant Web sites. Once he has collected all information
referring to this report, Mr. Miller creates a service order for it.
He then calls up regional data using the GIS connected to his
business portal to see which maintenance group is responsible
for that problem. mySAP Enterprise Portal enables Mr. Miller
to monitor the status of the service order throughout its runtime.

150

SOLUTION BENEFITS

mySAP Enterprise Portal offers you the following advantages:


Unified, made-to-measure and personalized retrieval of
relevant information from different sources
Quick, central access to information, applications, and
services
Reduced communication costs through communal use
of effective channels and improved information exchange
Increased activity due to shorter search and processing times
Significant cost reductions due to increased efficiency in
the workplace
More motivated personnel due to increased possibilities for
cooperation
Lower training costs due to intuitive user interfaces
More support for decision-making processes and increased
service due to the supply of clear and consistent information
Increased value creation due to improved service quality
Improved customer satisfaction due to improved customer
service
Early recognition of sales opportunities
Fast response time to market demands for the generation
of new products and solutions

SUMMARY
Industry Experience
With almost 30 years of experience modeling business processes, SAP offers tailor-made solutions, including one for the utilities industry. When you choose mySAP Utilities, youve selected a solution from one of the largest independent software
companies in the world SAP. More than 18,000 companies in
over 120 countries have already turned to SAP and with good
reason. As an integrated, Internet-enabled e-business solution,
mySAP Utilities optimizes processes such as enterprise management, business support, sales and marketing, work management, energy data management, billing, invoicing, and contract
accounting, intercompany data exchange, and customer relationship management.

Deregulation Experience
mySAP Utilities is designed to fully meet the requirements of
the deregulated market. Whether your company is in generation, transmission, and distribution or whether you sell electricity, water, gas, or district heating, mySAP Utilities supports
all your business processes.

This integrated solution covers all processes relating to generation, transmission, distribution, and sales for every division.
When it comes to energy data management and intercompany
data exchange SAP is one of the trendsetters.

Open System Architecture


With its open interfaces, the architecture of SAP software
enables you to integrate old and new solutions, both SAP
and non-SAP in a single, comprehensible system landscape.

With mySAP Utilities, you get the flexibility, scalability, and


integration necessary for true collaboration that reduces costs,
streamlines processes, and drives growth. mySAP Utilities delivers key information when and where it's needed, enhancing
customer satisfaction while boosting employee productivity
and partner efficiencies. Thats why more then 800 customers
around the world, operating in both regulated and deregulated
markets trust mySAP Utilities.

Integration
All mySAP Utilities components are closely integrated. Standard interfaces with external systems also guarantee a high
level of integration for all SAP solutions. Projects can be managed significantly faster, while storing redundant data is avoided along with the expense of multiple maintenance. Efficiency
is increased, costs are lowered, and resources are used more
effectively.

Scalability
SAP solutions are scalable and can be implemented in any utility company. Companies using mySAP Utilities bill from 1,000
to 20 million contracts with their customers. This proves that
mySAP Utilities grows with your company and is flexible to
changing market conditions.

151

A Secure Investment
mySAP Utilities customers can feel secure that they have made
the right choice. The ability to integrate different solutions and
components, as well as the open system architecture of mySAP
Utilities, means that SAP customers never lose on their investments.
Global Solution
mySAP Utilities is a standard solution that can be implemented
worldwide since it can be modified to meet the requirements
of individual countries. International companies can use mySAP
Utilities to operate the market models of different countries
in a single system. Moreover, mySAP Utilities is available in
approximately 20 languages.
Fast Implementation
mySAP Utilities is shipped with an implementation guide that
describes the core functions in terms of your requirements as
a utility company. The guide explains the necessary configuration steps making information and applications only a click
away. This ensures a speedy implementation. In addition, the
SAP customer engagement life cycle provides a variety of
implementation methods and tools, such as AcceleratedSAP
for Utilities or the SAP Solution Manager. Plus, skilled
partners are always available to assist you with your implementation of mySAP Utilities.

152

Training
SAP offers comprehensive and up-to-date courses on mySAP
Utilities. For information, see the SAP education homepage
at www.sap.com/education. You can find more information
in the SAP Service Marketplace at http://service.sap.com.
Visit our Web Site
You can get additional information about mySAP Utilities
including white papers and solutions in detail by visiting
http://www.sap.com/solutions/industry/utilities/

GLOSSARY
activity
A document used in activity management to record information resulting from interaction between business partners,
undertaken at any time during the customer relationship life
cycle. Activities are subdivided into business activities and tasks.
Examples of activities are telephone calls, customer visits, preparatory tasks, or private reminders.
advance payment (contract accounting)
Budget billing amount specified in the budget billing plan.
It is paid before the utility company has rendered services.
advance payment (intercompany data exchange)
Procedure by which the billing agent pays the outstanding
receivables to the service provider, even if the customer has not
yet paid these receivables to the billing agent. Once the receivables have been invoiced in mySAP Utilities, they belong to the
billing agent.
AMB procedure
Abbreviation for the average monthly billing procedure. This
is a payment plan category, where the current payment plan
amount is always determined.
annual profile
Elementary profile that is valid for a year.
basic process
Process used to define data exchange processes. Various data
exchange processes can be implemented based on basic processes. Process parameters are defined for the basic process that
help differentiate when implementing data exchange processes.
Example: From basic process Export Profile Values and process parameter Profile Allocation Role you can define multiple data exchange processes:
Export measured load shapes to supplier
Export settlement results to settlement coordinator
Export schedules to settlement coordinator
Export settlement results to supplier

BBP procedure
Abbreviation for budget billing plan procedure. This is a
payment plan category, where the payment plan amount
is charged equally over the whole validity period.
best-rate billing
Determination of the most favorable rate for the customer
using several alternatives.
BEx
Abbreviation of Business Explorer, the analytical and reporting
tool in the SAP Business Information Warehouse. The Business
Explorer (BEx) consists of the following areas:
Query design and application design: BEx Query Designer
and BEx Web Application Designer
Analysis and reporting: BEx Analyzer, BEx Web applications,
and mobile intelligence
Formatted reporting: Crystal Reports Integration
Organization: BEx Browser
bill accounting
Tax determination procedure used during bi-level determination of the tax determination ID, whereby tax is determined
at the time of billing. If the tax rate has changed during the
billing period, amounts and consumption are prorated.
billing
Function used to bill for the utility services provided by a
utility company.
billing agent
Service provider that creates bills and follows up payment
receipt for both its own services and those provided by third
parties (other service providers). Receivables billed by the service provider on behalf of third parties are passed to the third
party concerned. They do not appear as revenue in the general
ledger of the billing agent.

153

billing consolidator
Service provider that issues the customer with a bill for several
services.
billing schema
Structure that defines the order in which variant programs
for rates to be billed must be executed.
bill ready
Billing creation process performed by the service provider.
The service provider is the owner of the bill. The bill covers
the services performed by the service provider, as well as any
services performed by third parties (other service providers).
The bill is passed on to the billing consolidator, who is then
responsible for bill clearing. In this way, the customer receives
one bill containing all the service types they have used.
blocking
This is for certain sequential quantity areas (for demand or
energy) where specific prices apply for each area. Blocking
prevents higher consumption from being cheaper than lower
consumption.
budget billing amount
Fixed partial payment on the expected bill, which is charged
in advance. These payments are charged on budget billing
amount due dates. For the utility company, budget billing
payments are down payments on the bill, which is charged
later.
budget billing cycle
Time difference in months between two budget billing amount
due dates.
budget billing plan
Basis for the budget billing request. It is used for managing all
budget billing plan items for a contract in a billing period.

154

budget billing plan item


Item within a budget billing plan.
budget billing plan period
Period defined for the budget billing plan. It is based on
the billing period from the portion, except in the case of a
sub-annual move-in, in which case the period starts on the
move-in date.
budget billing request
Process in which customers are requested to pay their budget
billing amounts. Budget billing requests are entered in the
system as statistical line items. According to country, they can
serve as the basis for a bill (actual debit entry).
budget billing request/partial bill date
Date on which:
The budget billing request run generates the print
document for the budget billing plan item
The partial bill run debits the budget billing plan item
calculation trigger
A calculation trigger shows that the calculation of a formula
profile has to be executed again to get correct results.
calorific value
Conversion factor indicating how many kWh of energy is
obtained from one standard cubic meter of gas. The calorific
value is calculated using several influence parameters.
cash accounting
Tax determination procedure used during bi-level determination of the tax determination ID, whereby the tax is determined at the time of invoicing. If the tax rate has not changed
during the billing period, amounts and consumption are not
prorated.

cash security deposit


The amount of money a utility company requires from a customer with a poor credit standing or expected bad payment
behavior before services are provided. Cash security deposits
can be paid back in several ways.
connection object
A link between installation and postal regional structure.
This is usually a building, but can also be a piece of property
or other facility, such as a fountain or construction site. The
connection object corresponds to the functional location in
the plant maintenance (PM) application component.
contract
An agreement between a business partner and a utility company that applies to a single division. The contract contains
control data for billing, for creating the budget billing plan,
and for contract accounts receivable and payable. Contracts
for services (for example, maintenance contracts) are managed
by the Sales and Distribution (SD) component.
control area
Part of the grid for which the control area operator ensures
the flow of energy between generator and consumer.
control area operator
Entity responsible for maintaining the balance and the flow of
energy between generation and consumption. If an imbalance
of energy exists between generation and consumption, the
control area operator is responsible for settling the balance
and provides control energy for this purpose.
convergent billing
Billing procedure in which one utility company includes the
billing amounts for the services of a third party together with
its own on one bill. In contrast to intercompany billing, postings (in contract accounts receivable and payable) are managed
using the gross procedure (that is, including tax) and transferred to general ledger as transitory items.

cumulated consumption measurement


Consumption measurement executed monthly or annually
that determines consumption as a cumulated value.
customer payment
Procedure by which the billing agent does not pay the outstanding receivables to the service provider until the customer
has paid the billing agent.
data exchange definition
Describes which data to exchange, using which due date,
between which service providers, and in which format. This
is determined at service provider level. You can maintain this
definition at the point of delivery level in exceptional cases
(redefined definition). Example: Using the data exchange definition, you determine that profile values are to be exchanged
on the first of each month, with service provider XY, and in
MSCONS format.
data exchange process
Process that monitors and controls (according to point of
delivery) the transfer of messages within intercompany data
exchange. This enables:
Messages to be logged
All of a data exchange processes messages are logged that
have been sent to or received by a point of delivery.
Asynchronous sending of messages
For data exchange processes (only export processes), sending
a message can be delayed until a scheduled time.
Cyclical scheduling and monitoring of messages
For a data exchange process, messages to be sent or received
are scheduled cyclically (for example, daily or monthly).
The resulting due dates can be monitored.
Active sending of scheduled messages
For data exchange processes (only export processes), active
controlling can be undertaken depending on cyclically
scheduled due dates.

155

degree day coefficient


Calculation values that are taken into account for weighted
consumption distribution in electricity and gas billing. The
degree day coefficient G is the difference between the average
room temperature (Tr) of a building (20C, for example) and
the average outdoor temperature (Ta). The outdoor temperature is calculated from three daily measurements: morning,
midday, and evening.
G = Tr - Ta
DELFOR
EDIFACT message category used to transfer schedules.
dependent validation
Validation that applies to several registers in one device or
installation.
device
Individual, physical object that is to be maintained as an
autonomous unit. Devices can be:
Counting devices (meters)
Controlling devices (ripple control receivers)
Data processing devices (converters)
Devices with protective or adjustment functions (pressure
controllers)
A device corresponds to a piece of equipment in the Plant
Maintenance (PM) application component.
device basic category
Grouping of devices of the same category. Examples include
meters, transformers, and audio frequency ripple control
receivers.
device category
Grouping of devices with the same technical characteristics
(data). Examples include single-rate meters and double-rate
meters. The device category corresponds to material in the
materials management (MM) application component.

156

device group
Grouping of devices into a logical unit. This facilitates data
entry. For example, if you enter the number of a device in a
group during installation, all of the other devices in that group
are automatically displayed for processing. Example: In the
device group integrated water meter there are two separate
water meters that are installed together (as a unit), but
metered separately and are billed individually.
device information record
Contains devices that are maintained by or belong to other
companies. A data record in mySAP Utilities contains only
devices in the utilities industry component. A record may
contain the following types of devices:
Metering devices (meters)
Controlling devices (ripple control receivers)
Data processing devices (converters)
Devices that protect or adjust (pressure regulators)
device location
Location within a connection object where devices are installed. Device locations correspond to functional locations
in the Plant Maintenance (PM) application component.
device modification
Change in the following parameters for devices:
Device category
Register group
Input/output group
Command group
In the case of installed electronic meters, modification refers
to reprogramming.
device replacement
Replacement of a device with another device from the same
or similar category.

disconnection order
Document which aids a field service employee in collecting
a payment from a customer or disconnecting a customers
utility service.
discount
Contractual or rate regulation concerning a reduction in
the amount charged to a customer.
division
Company-internal key for the division category that is predefined in mySAP Utilities. One or more divisions are allocated
to the division category. For example, a utility company might
divide the division category water into drinking water and
waste water.
division category
Type of supply or service, which is predefined in mySAP
Utilities. Examples of division categories are electricity, gas,
and water.
DPC
Abbreviation of dynamic period control.
dual billing
Bill creation process in which each service provider creates
its own bill and sends it to the customer. The customer then
receives several separate bills instead of just one.
duty
Duty on the net amount of a bill, differing from region
to region. Examples: compensation tax, Bigge surcharge.
dynamic period control
A control that, during billing, permits flexible backbilling
of periods that have already been billed.

dynamic modification factor


Factor corresponding to the value of an elementary profile of
the profile value category factor. Dynamic modification factors are used for changing profile values in a synthetic profile.
Example: You can avoid large jumps due to season types by
multiplying values by a dynamic modification factor. In the
case of synthetic profiles for residential customers, you can
ensure that a residential customer's typical profile is retained.
EDI
Abbreviation of electronic data interchange. Cross-company
exchange of electronic data (for example business documents)
between domestic and international business partners who use
a variety of hardware, software, and communication services.
The data involved is formatted according to predefined standards. In addition to this, SAP Application Link Enabling (ALE)
technology is available for data exchange within a company.
EDIFACT
Abbreviation of Electronic Data Interchange for Administration, Commerce, and Transport. An international and
branch-independent EDI standard.
estimation
Determination of expected consumption that is triggered by
an employee during entry of meter reading results. Estimation
can be carried out for one or more registers, such as for an
entire meter reading unit or portion.
expected consumption
Result of extrapolation or proration. Expected consumption
is used as a basis for validations, determination of budget billing
amounts, or for interpolations or estimations.
external certification
Technical inspection and renewal of a measuring device by
a licensed technician. The measuring accuracy of the device
is inspected according to legal requirements.

157

extrapolation
Procedure used for determining expected consumption or
demand. The system uses a weighting procedure based on one
of the following:
Meter reading result from comparison period
Period consumption
User-specific requirement

full device installation


Technical and billing-related installation performed in one
step. The device is installed in a device location and allocated
to a premise.

extrapolation of profile values


Replacement value process in which profile values are determined using historical values. Extrapolated profiles can be
used as forecast values, for example.

gas billing
Determination of the valid conversion factors for gas, where
the operating volume is converted to standard volume.

final billing
Billing triggered when a customer moves out or when the
service territory is transferred to another supplier.
floating backbilling
Type of billing that can be used for billings that occur within
the year. All billings executed within the billing year are settled
automatically, based on an anticipated billing result.
formula allocation
Assignment of input and output profiles to a formula.
franchise contract
Contract between a utility company and the municipality
about payment of a franchise fee. The franchise contract
applies to only one division.
franchise fee
Payment by the utility company to municipalities whereby the
utility company obtains the right to supply energy directly to
customers in these regions. This allows the utility company to
use public traffic routes for the laying and operation of lines.
The franchise fee is determined for each division in a separate
franchise contract.

158

full device removal


Billing-related and technical removal performed in one step.

gas billing type


Classification for gas billing that is predefined in the utilities
industry component. There are three gas billing types:
Thermal gas billing
Gas billing according to standard cubic meters
Volumetric gas billing
gas volume correction factor
Conversion factor used for converting an operating volume
(measured gas quantity) into a standard volume.
GIS
Abbreviation of geographical information system.
GIS Business Connector
Interface between the GIS and the SAP System that performs
the following functions:
Mapping of objects
Mapping of fields and their values

grid
Object in the mySAP Utilities system that corresponds to
an entire or partial service territory of a distributor.
higher-level settlement unit
Settlement unit allocated to a sub-settlement units for joint
settlement. Settlement is then carried out for higher-level unit
and all the sub-units allocated to it.
IDoc
Abbreviation of intermediate document. A standard SAP
format for electronic data interchanges between systems.
independent validation
Validation that applies to one specific register. Fixed independent validations are carried out automatically in the system.
Variable independent validations are carried out based on
customizing settings.
InfoCube
Objects that can function both as data targets as well as InfoProviders. An InfoCube describes a self-contained dataset
(from the reporting view), such as a business-oriented area.
This dataset can be evaluated with the BEx query. An InfoCube
is a quantity of relational tables that are created according to
the star schema a large fact table in the center, with several
dimension tables surrounding it.
InfoSource
A quantity of all available data for a business event, or type
of business event (for example, Cost Center Accounting). An
InfoSource is a quantity of information that has been grouped
together from information that logically belongs together.
InfoSources can contain transaction data or master data (attributes, texts, and hierarchies). An InfoSource is always a quantity of InfoObjects that belong together logically. The structure
where they are stored is called a communication structure.

installation
Group of all devices, registers, and flat rate billing values that
are:
Specific to a division
Allocated to a premise
Grouped together for billing purposes
One premise can have several installations. These installations
can refer to the same or different divisions.
installation structure
Description of devices installed in an installation. The installation structure mainly contains data necessary for billing the
contract associated with the installation.
interaction center (IC)
mySAP CRM offers call center capabilities for sales or customer
service organizations. The IC allows agents to process inbound
and outbound contacts as well as business transactions related
to a customer. Companies can use the IC in a variety of business scenarios including sales, service, collections, and human
resources.
intercompany billing
Billing procedure in which one utility company creates a single
bill for the end customer, including services of several companies all having separate balance sheets. This one company also
maintains joint contract accounts receivable and payable for the
customer for all other companies. Contract accounts receivable and payable contain the information specific to company
codes and transfer the data to separate general ledgers.

159

internal certification
Technical inspection and renewal of a measuring device by the
utility company itself. The measuring accuracy of the device is
tested using company standards.
interpolation of profile values
Replacement value process during which values are estimated
using known profile values from a neighboring location. Interpolated profile values are used replace missing or implausible
values from the past.
interval customer
Customer whose consumption is determined using an interval
meter.
invoicing
Interface between billing and contract accounts receivable
and payable. It is used for the following functions:
Posting to a customer account
Creating the collective document for the general ledger
Supplying information for statistics
Printing the bill
invoicing unit
Collection of all documents (billing documents, budget billing
plan items, collective bill items, and so on) that must be jointly
invoiced/requested and displayed in a print document.
Joule-Thomson effect
Temperature change (usually a decrease) in a gas that has
undergone a significant drop in pressure.
load profile
Energy consumption values from a certain period that are
managed in a certain profile category (such as an elementary
profile). Measured load profiles are called load shapes.

160

load shape
Consumption measured by interval meters that is stored in
an elementary profile.
mandatory contract
Contract belonging to a contract account that may only be
invoiced together with other mandatory contracts belonging
to the same account.
mapping
Allocation transaction between the SAP System and the GIS.
The following can be allocated:
Objects
Fields and their values
master data generator
Program that uses the master data template to create master
data (such as business partners and contracts).
master data template
Template that defines master data to be created. The master
data generator uses the template to create master data.
Example: If service provider sells products as the result of a
marketing campaign, the master data of the new customers
(such as business partner and contract) is created automatically in the background based on the master data generator.
MDG
Abbreviation of master data generator.
meter reading document
The data record, which is the basis for meter reading orders
and meter reading results. Meter reading documents first exist
as meter reading orders in the system. Documents become
meter reading results as soon as specific meter reading data
(such as readings or notes from the meter reader) is available
to the system.

meter reading order


Data record created during meter reading order creation. It
contains data specific to the register and information for the
meter reader.
meter reading order creation
Process in which meter reading orders are created. Billing
orders may also be created, depending on the meter reading
reason indicated by the user. This applies to the following
meter reading reasons:
Periodic meter reading
Interim meter reading with billing
Final meter reading with move-in/out
Service territory handover with billing
meter reading result
A meter reading that has been taken or estimated and is stored
in the system for a certain date.
meter reading type
User-defined version of the meter reading category predefined
by mySAP Utilities. You can allocate several meter reading
types to a meter reading category.
meter reading unit
Grouping of installations and their devices and registers
according to region. Installations are grouped in this way for
meter reading and device management. The meter reading
unit is the basis for the meter readers work list.
mobile data entry (MDE)
Portable data entry system employed by utility companies,
for example, for entering meter readings.

MSCONS
EDIFACT message category used to transfer consumption data.
NIS
Abbreviation of network information system.
OLAP
Abbreviation of online analytical processing.
OLAP reporting
Reporting based on multidimensional data sources. OLAP
reporting allows you to analyze several dimensions at the same
time (for example, time, place, or product). The aim of OLAP
reporting is to analyze key figures, such as for an analysis of the
sales figures for a certain product in a particular time period.
The business questions that you have about this product in this
period are formulated in a query. The query includes the key
figures and characteristics that contain the data that is necessary for analyzing or answering your questions. The data is displayed in a table and is the starting point for a more detailed
analysis to answer a number of different questions. A range of
interaction options, such as sorting, filtering, swapping characteristics, and recalculating values, allows you to navigate flexibly through the data during the runtime. In the SAP Business
Information Warehouse you can analyze the data in the following areas of the Business Explorer:
In the BEx Analyzer in the form of queries
In BEx Web applications
Unlike in flat reporting, the number of columns in OLAP
reporting is dynamic. The analysis of the data is the main
focus. The layout, formatting, and printing of reports are
secondary.

161

operand
Individually determined symbolic name for the assigned
values that are used as input and output parameters in variant
programs. One or more operands are allocated to an operand
category.
opportunity
A document used in Opportunity Management, representing
a recognized possibility for sales of products or services. An
opportunity can result from a trade fair, a sales deal, or a bid
invitation. A lead with the status hot can also be transformed
into an opportunity.
outline contract (for billing)
Contains all individual contracts that are to be billed together.
outline contract (for intercompany data exchange)
Contract between the distributor that owns the grid to which
the customer is connected, and the customers supplier. This
contract states which customer the supplier supplies within
the grid area of the distributor and to which settlement unit
the customer belongs. An outline contract can also include
agreements concerning the use of load profiles, the entry and
passing on of necessary consumption data, and so on.
outsorting
Procedure whereby a document is placed on an exception list
if it has failed validation during billing or invoicing. The clerk
must check and, if necessary, release each outsorted document.
overdue task
Data exchange task with a due date that has past.
parameter record
Data record that contains control data used for generating
budget billing dates during generation of schedule records.

162

partial bill
Budget billing plan item that is transferred as an open item
to the contract accounts receivable and payable (FI-CA)
component.
payment plan category
Internal system classification of payment plan types.
Customer-defined payment plan types are allocated to the
payment plan category in Customizing. The payment plan
category is predetermined as:
BBP procedure with equal amounts over the whole validity
period
AMB procedure with amounts that are calculated each
month
payment plan type
User-defined specification of the preset payment plan category.
Example: A utility company changes the name of the payment
plan category BBP procedure (budget billing plan) to the one
which is used internally, for example AMB procedure (average
monthly billing).
period consumption
Consumption or demand for a register that is relevant to
meter reading, in a period with a maximum of 365 days.
Period consumption is entered at the register level as a fixed
value in the installation structure data. It is used for extrapolating meter reading results if one of the following applies:
No representative base period exists (such as for meter
readings after installation or move-in).
The consumption pattern of the customer has changed
(for example, number of persons living in household has
changed)
The physical conditions in the customers environment
have changed (for example, by converting the measuring
accuracy (register factor) of the meter during the extrapolation period)
The calculation of meter readings and budget billing
amounts to be extrapolated has been influenced (for example, if the rate framework or consumption pattern of the
customer has changed).

period control
Customer-defined version of the base calculation procedure
used to calculate the length of time portions (billing-relevant
periods). You specify the time control in the schema for each
rate step in which a time-based calculation is performed.
period-end billing
Additional billing at the end of a period whereby the customer
is billed for the closed period, for example, by means of backbilling.

point-of-delivery service
Service supplied to a customer at the point of delivery.
Point-of-delivery services are non-billable.
political regional structure
The division of a service territory according to political
or administrative criteria, such as states and counties.
portion
Group of contracts that are to be billed together.

periodic billing
Consumption billing performed in regular intervals. The
time sequence of this billing process is defined in scheduling.
Examples:
Annual consumption billing
Monthly billing
Bimonthly billing

postal regional structure


A subdivision of a supply area according to cities, streets,
and street sections, or other structural criteria.

periodic replacement
Replacement of devices that must be replaced as required
by law or other rules.

profile
Contains values such as consumption and prices for a certain
period. Profiles are used to manage interval data in the energy
data management component of mySAP Utilities. A profile is
composed of header data and profile values. Profile characteristics are defined in the header data. The most important characteristics are:
Interval length
Profile type
Profile value category

pipeline
A form of analysis that displays potential sales revenue by providing an overview of the current and future sales situation.
Pipelines can be used to track quantities of sales, to compare
expected and actual values, or as a basis for planning future
sales processes. Pipelines are employed in different areas, such
as opportunities, contracts, or activities.
point of delivery
Point to which a utility service is supplied, or for which a utility service can be determined. A point of delivery number has
an external number (point of delivery ID). A point of delivery
is used for:
Communication in automatic data exchange (deregulation
point of delivery)
Exchanging meter reading results (technical point of
delivery)

premise
Enclosed spatial unit which is supplied with energy, such as
an apartment or factory.

Examples: Interval data includes:


Values measured by an interval meter every 15 minutes
Forecast values for an interval meter every 15 minutes
An price index from the energy exchange with an hourly
amount

163

quantity-based price
Price that has a quantity reference but no time reference,
such as an energy price ($/kWh).
rate
Billing rule for a register or a reference value that refers to all
the billing-related steps executed during billing. A rate consists
of one or more variant programs, which are part of the billing
schema.
rate category
Classification of an installation for billing purposes. In conjunction with rate type, the rate category is used to determine
the rate.
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: Rate fact group X contains the rate facts
minimum demand = 20 kW and discount rate = 10%. If a customer uses 20 kW, a discount of 10% is granted.
rate ready
Bill creation and bill clearing performed by the billing agent
on behalf of the service provider that owns the services. The
billing consolidator requires all the relevant information (for
example rate data) in order to create the bill. In this way, the
customer receives one bill containing all the services they have
used.
rate type
Classification of a register, flat rate, or reference value for
billing. In conjunction with the rate category, the rate type
is used to determine the rate.

164

real-time pricing
Rate model in which energy requirements are evaluated
according to period. Consumption and demand are measured
at certain intervals (every 15 or 30 minutes, for example) or
during certain rate periods (such as on- and off-peak periods).
The price per kWh of consumption or kW/kVA of demand can
vary according to interval. Prices can be set in advance or be
based on prices set by the energy exchange. For example, you
can define prices so that when a certain consumption limit is
exceeded, either a higher price or the current spot price from
the energy exchange is used. Real-time pricing enables you
to structure rates and prices more freely for different periods,
which in turn allows for more freely structured contracts.
redefined definition
Overriding of a data exchange definition at point of delivery
level. Data exchange definitions are usually determined at
service provider level.
reference consumption
Consumption used for creating replacement values for profiles
with missing or implausible consumption values.
reference period
Period used as a basis for creating replacement values in the
replacement procedure.
register
Device that measures consumption, energy, and so on. This
can refer to an actual register or a display in an electronic
device.

register group
Group of registers that belong to one or more devices or device
categories.
register relationship
The relationship of registers to each other. The registers can
also belong to devices in different installations. Examples:
Serial switching
Control relationships
Allocation of reactive to active registers
rental price
Price for supplying the customer with a measuring device
(such as a meter) for a certain period of time. For the electricity division, the rental price also includes the charges for
meter reading, settlement, and collection.
replacement period
Period for which replacement values are to be created.
replacement value
Plausible value that replaces a missing or implausible actual
value.
replacement value creation
Creation of values that are used to replace missing or
implausible profile values.
replacement value procedure
Procedure used for creating replacement values. Different
replacement value procedures can be grouped together to
form a procedure group. The replacement value procedure
defines how replacement values are calculated. Example:
Replacement values can be calculated for a profile using the
historical values of the profile.

replacement value procedure group


The grouping of replacement value procedures.
replacement value process
Process during which replacement values are created. The
following replacement value processes exist:
Extrapolation
Interpolation
replication
The rule-based distribution of data to sites. (Site: The receiver
or supplier of data in the context of replication that is defined
on the CRM server (for example, mobile clients).
real-time pricing (RTP) billing
Billing of interval values (such as consumption).
RTP interface
Data object that links energy data management (IS-U-EDM)
and contract billing (IS-U-BI) components. The RTP interface
prepares the profiles managed in IS-U-EDM for billing.
SAP Business Connector
Middleware application that is based on the B2B integration
server from webMethods. The SAP Business Connector enables
both bi-directional, synchronous communication as well as
asynchronous communication between mySAP.com applications and SAP and non-SAP applications, including Web applications. Using the SAP Business Connector, all SAP functions
that are available using BAPIs or IDOCs are made available to
business partners over the Internet as an XML-based service.
The SAP Business Connector uses the Internet as a communication platform and XML or HTML as the data format. It integrates non-SAP products by using an open, non-proprietary
technology.

165

schedule record
Data record in which individual dates are managed, such as
meter reading dates, billing dates, and budget billing amount
due dates.
scheduled billing period
Planned billing period, in which billing is to be performed.
The scheduled billing period is defined in scheduling. The
following periods can be defined in scheduling:
Monthly
Quarterly
Annually, and so on
scheduling
Planning and controlling of the following functions:
Meter reading order creation
Billing
Determination of budget billing amount due dates
schema
Structure that defines the sequence in which variant programs
(calculation/processing steps) must be executed.
service connection
Division-dependent interface between utility grid and connection object.
service provider
Company that offers one or more of the following services
(service types):
Energy generation
Energy sales
Energy supply
Energy transmission
Energy distribution
Meter installation and maintenance
Meter reading
A service provider is uniquely allocated to a service type.

166

service type
User-defined version of the service category predefined by SAP.
You can allocate several service types to a service category.
settlement
Comparison of energy supplied and energy used carried out by
the settlement coordinator. For example, the actual or forecast
consumption of all points of delivery in a settlement unit can
be grouped together for settlement.
settlement period
Period during which settlement takes place.
settlement procedure
Procedure used for balancing energy supplied and energy
consumed that is carried out by settlement coordinator.
settlement step
Smallest unit of a settlement procedure. Settlement steps
model settlement algorithms and consist of input and output
parameters, which can be profiles or values.
settlement type
Key that refers to the business process in automatic settlement
postings. It is used in the contract accounts receivable and
payable (FI-CA) component to determine the payment allocation or settlement rules.
settlement Unit
Virtual entity for which a settlement coordinator compares
energy used and energy supplied. A settlement unit contains
the points of delivery that are to be settled as a group.

settlement variant
Key under which the rules for automatically allocating open
items for clearing are defined.
sole provider
Service provider that, from the customers perspective, is solely
responsible for all services, and is the owner of the all receivables contained in the bill. All the receivables for which the
customer is billed are listed as revenues in the general ledger
of the sole provider.
standard volume
Volume of the gas quantity under the following standard
physical conditions:
Standard temperature (Ts) = 273.15 K
Standard pressure (Ps) = 1.01325 bars
street route
Sequence for reading the registers in a meter reading unit.
sub-item
Open posting item included as additional information in the
bill display.
sub-settlement unit
Settlement unit allocated to a higher-level settlement unit for
joint settlement. Settlement is then carried out for higher-level
unit and all the sub-units allocated to it.
surcharge
Amount established in the contract or rate that is included in
the customers bill amount. Surcharges do not refer to amounts
that a utility company collects only for forwarding to another
entity, such as taxes and duties.

synthetic profile
Profile containing values generated based on predefined periods (day and season groups) and corresponding day and annual profiles. Synthetic profiles are used for classifying customers
or customer groups.
technical device installation
Physical installation of a device in a device location. Relationships with other registers and device can be defined upon
technical installation. Technical installation is a prerequisite
for billing-related device installation.
technical device removal
Physical removal of a device from a device location. Technical
removal cannot be performed until billing-related removal has
been performed, that is, the device must no longer be allocated
to the utility installation.
technical installation
Division-related unit installed in a premise. The technical
installation is modeled for the utilities industry as a piece of
equipment in the plant maintenance (PM) application component. If you do not wish to create this unit (for example,
a flat-rate installation) as a device, you can create it as a technical installation for the plant maintenance and service management components. However, you can only create one
technical installation for each division. Examples of technical
installations are:
Night storage heating stove with cable, fuse, and so on
Fuse box
Distribution cabinet
Electrical outlet

167

thermal gas billing


Type of gas billing in which the operating volume (measured
gas quantity) is converted into a heat quantity using the gas
volume correction factor and the calorific value. This heat
quantity is then billed.

usage factor
Consumption of an installation in relation to a synthetic profile. Example: A synthetic profile is normed at 1000 kWh. The
consumption of an installation in a normed period is 800 kWh.
The usage factor is then 0.8.

time slice
Time interval within which a specified object was not changed.

UTILMD
EDIFACT message category used for transferring master data
on customers, contracts, and points of delivery.

time slice generator


Indicator that is used to define the periods to be billed. They
are defined in the billing schema.
transaction data
Transaction-specific data that is short-lived and assigned to
certain master data. Individual posting documents are called
transaction data. For example, transaction data relating to sales
development can be assigned to a vendor's master data. The
total sales of a vendor consist of the data of the individual business transactions the transaction data.
unbilled revenue reporting
Consumption proration used for determining and valuating
quantities sold and billed for the balance sheet of the closing
balance period.
unbundling
Financial and organizational separation of service in the energy
industry. Unbundling applies to:
Energy generation
Energy transmission
Energy distribution
Activities beyond the realm of electricity

168

validation
Test of meter reading data for plausibility before it is entered
into the system. Data is validated using fixed values, such as
zero consumption or number of meter readings by customer
and automatic estimations. Data can also be validated based
on expected consumption, such as in the case of tolerance
limit validations. Validations are divided into two categories:
independent and dependent
variant program
Module in rates or schemas that contains a billing rule.
volume correction factor
Ratio of the standard volume of a gas to its operating volume.
Using the volume correction factor, a current operating volume
can be converted into a physical standard volume. This is
required when the energy content is to be calculated from the
calorific value of the gas, which always refers to the standard
volume.
Formula for volume correction factor (VCF):
VCF = Ts * (Pamb + Peff) / (T * Ps * DF)
(Ts = 273.15 K,
Pamb = air pressure,
Peff = gauge pressure of gas meter,
T
= gas temperature,
Ps
= 1.01325 bars,
DF = gas law deviation factor)

volumetric gas billing


Type of gas billing in which the recorded gas quantity,
measured as a volume (for example, in cubic meters), is
billed. The recorded operating cubic meters are not converted
to standard pressure and temperature conditions.
weighted average
Average of values from a period in which values are to be
weighted proportionately. The products of physical values
(temperature, calorific value, or air pressure, for example)
or consumption are added together and divided by the sum
of energy feeding quantities.
W = Sum (WI * QI) / Sum QI(I from Index qty, e.g. I={1,...,12})
(W = value to be weighted,
Q = feeding quantity)
weighting
Procedure used during extrapolations or proration whereby
the system calculates expected consumption using existing
meter readings, period consumption, or reference values.

work clearance management


A process in which an operational system is isolated. This
process creates a safe environment in which personnel can
work and perform tests.
work order
Order for planning and execution of work within a utility
company. The work order is used for:
Planning of required resources
Calculation of costs
Scheduling of resources
The work order receives the actual costs and forwards them to
the party responsible in the order bill. If necessary, the resulting demand in the work order can be invoiced to the third
party.
yearly advance payment
Payment that a customer makes a year in advance for a service
to be rendered by the utility company. In most cases, the utility
company grants a discount for using this payment method.

169

SAP AG
Neurottstrae 16
69190 Walldorf
Germany
T +49/18 05/34 34 24 *
F +49/18 05/34 34 20 *
* Subject to charge

www.sap.com

50 0xx xxx (YYMM/xx) Printed on environmentally friendly paper.