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.
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.
2
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Utilities Market Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
The Challenges Facing Utility Companies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
– Improving Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
– Replacing Customer Contracts with New Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
– Clearing Services and Exchanging Data with Other Utility Companies . . . . . . . . . . . . . . . . . . . . 16
– Supporting New Billing Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
– Predicting Customers’ Consumption Patterns with Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
– Using Information Technology To Provide On-The-Spot Customer Services . . . . . . . . . . . . . . . 16
– Implementing New Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
– Analyzing Markets and Strengthening Marketing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
What Must a Customer Information System Do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

mySAP™ Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Basic Functions and Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
– Postal Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
– Political Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
– Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
– Company Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
– Enterprise Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
– Agent Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
– Portioning and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
– Business Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
– Contract Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
– Utility Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
– Connection Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
– Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
– Premise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
– Device Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
– Utility Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
– Point of Delivery (POD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3
mySAP™ Customer Relationship Management for the Utilities Industry. . . . . . . . . . . . . . 33
Functional Scope of mySAP™ CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
– Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
– Supporting the Customer Relationship Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
– Synchronization of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
– Interaction Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Integration of mySAP CRM in mySAP Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
– System Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
– Synchronization of Data Between mySAP CRM and mySAP Utilities . . . . . . . . . . . . . . . . . . . . . 42
– Master Data Generator – Automatic Creation of and Changes to Master Data . . . . . . . . . . . . . 43
– All Data at a Glance: The Cross-System Customer Fact Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
– Integrated Scenarios from mySAP CRM, mySAP Utilities, and SAP® BW . . . . . . . . . . . . . . . . . . . 44
– From Potential Non-Residential Customer to Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
– From Potential Chain/Outline Contract Customer to Enrollment . . . . . . . . . . . . . . . . . . . . . . . 46
– From Phone Call to Changes in Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
– Typical Front Office Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
– Move-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
– Move-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
– Business Partner Move-In/Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
– Change Bank Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
– Change Budget Billing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
– Change Installment Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
– Bill Reprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
SAP Business Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
– Bill Complaint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
– Lay a Service Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
– Disconnection/Reconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Internet Self-Service Including Automatic Changes in mySAP Utilities . . . . . . . . . . . . . . . . . . . . . 50
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4
Energy Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Device Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
– Device Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
– Technical Device Data and Connection Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
– Device Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
– Device Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Meter Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
– Street Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
– Meter Reading Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Energy Data Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
– Meter Reading Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
– Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
– Load Shapes and Load Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
– Import of Profile Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
– Replacement Value Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
– Profile Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
– Data Analysis and Data Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
– Version Creation and Revision Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
– Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
– Data Preparation in the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
– Settlement Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
– Adaptability and Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
– Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
– Documenting and Logging Settlement Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
– Exception Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
– Settlement Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
– Settlement Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
– Data Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
– Taking Grids into Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
– Schedule Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5
Contract Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Billing Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
– Backbilling and Period-End Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
– Dynamic Period Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
– Real-Time Pricing Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Billing Divisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
– Electricity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
– Gas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
– Water and Waste Water . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
– District Heating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
– Other Divisions (Cable Television, Radio, Multimedia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Special Billing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
– Multiple Contract Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
– Lighting Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
– Small Power Producers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Billing Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
– Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
– Rate Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
– Operands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
– Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
– Discounts and Surcharges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Extrapolation/Statistical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
– Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
– Sales Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
– Unbilled Revenue Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
– Consumption Statistics (for Customer Relationship Management) . . . . . . . . . . . . . . . . . . . . . . 82

6
Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
– Outsorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
– Backlog Reduction Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
– Parallel Processing and Monitoring Mass Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
– Lock Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
– Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
– Manual Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Invoicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Bill Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
– Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
– Additional Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Billing Reversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Bill Printout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Outsorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Budget Billing Amounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
– Budget Billing Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
– Special Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Collective Bill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7
Contract Accounts Receivable and Payable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
– Document Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
– Account Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
– Business Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
– Enhancement Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
– Interface Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
– Workflow Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
– Performance Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

8
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

9
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, infor-
mation related to data structures and exchange, customer
relationship management, energy data management, business
intelligence, work and asset management, enterprise portals,
and more.
UTILITIES MARKET OVERVIEW
The unbundling of utility companies in the deregulated mar-
ket has changed the relationship between utility companies
and their customers. Whereas in regulated markets, a one-to-
one relationship with a local utility is the rule, customers in
deregulated markets deal with several types of utility compa-
nies. Customers have contracts for provisioning services with
energy suppliers (suppliers for short) and agreements – often
contracts – with a local distributor. Since deregulated cus-
tomers 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 ener-
gy 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 com-
pany – the meter operator.
To coordinate, manage, and bill their services, this assortment
of utility companies must exchange data intensively. This infor-
mation relates to the customers, contract contents, billing and
payment transactions, and locations. Information is also need-
ed regarding technologies pertaining to energy supply, meter
readings, and so on. To exchange information, the customer
information systems of the various companies must commu-
nicate 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.
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 country’s utility system, the prop-
erty 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.
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.
Consequently, the customer information system must provide
flexible definition types of companies (distributor, meter oper-
ator, supplier) and processes (for example, managing metering
technology, meter reading, sales, contract billing, work man-
agement 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 relation-
ships between distributors and suppliers, means it is essential to
define the premise in a new way. The number of the consump-
tion meter, which was used prior to unbundling, is no longer
suitable since, in a distribution grid with a multitude of distrib-
utors, this number is neither meaningful nor unique to one
premise. The utilities industry has thus far been unable to
14
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).
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.
For example, in the case of a dual contract model, the cus-
tomer, in addition to their existing grid usage contract, con-
cludes a second contract for getting energy through the sup-
plier. In the case of the single contract model, the customer’s
contract with the distributor is cancelled and only the new
energy supply contract with the supplier remains.
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 sub-
stantial differences over enrollment and meter reading dead-
lines, as well as the treatment of customers in arrears, irregular
enrollment, or the transfer of data from distributors to sup-
pliers.
Deregulation requires utility companies to develop a com-
pletely 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 prob-
lems. It helps the utility look after and analyze its most impor-
tant 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 par-
tially 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 utili-
ties 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 envi-
ronment, the survival of a utility company depends on:
Improving Customer Service
High-quality customer service is the key to a utility’s success.
Customer satisfaction determines the demand for a utility’s
services, shapes the customers’ view of the utility, and in-
fluences customer retention.
Replacing Customer Contracts with New Contracts
Deregulation has changed utility and service contracts. Cus-
tomers 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 along-
side 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 (includ-
ing 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 com-
pany 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 dereg-
ulated 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-slice-
controlled 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 consump-
tion 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 im-
prove their productivity and raise their level of responsiveness
and the quality in customer service. It is vital to integrate utili-
ty services and on-the-spot services in common systems. To
achieve this, the customer information system must be inte-
grated 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 cus-
tomers 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 com-
petence 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 compo-
nents, such as mySAP™ Customer Relationship Management
(mySAP™ CRM), mySAP™ Business Intelligence with SAP® Busi-
ness 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 imple-
ment solutions based on their internal structure and individ-
ual 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 Process Consumer Service Financial Public
Industries Industries Industries Industries Services Services

mySAP CRM
mySAP Financials

mySAP E-Procurement
SOLUTIONS mySAP SCM

mySAP PLM

mySAP BI

mySAP HR

SAP SAP SAP

WP APO Mobile
SAP-
KW SAP
BW
External
SAP
SEM
SAP TECHNICAL
BC SAP COMPONENTS
... ...
SAP
IS-U

SAP SAP
R/3 ...
SAP ILOG
GUI

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 solu-
tions 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 devel-
oped Internet-enabled, fully integrated applications for manag-
ing customer relationships, employees, installations,
maintenance, work order processes, financial issues, procure-
ment, 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

18
 mySAP UTILITIES
mySAP Aerospace & Defense

Billing and Contract Accounting

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

mySAP High Tech

mySAP Utilities

mySAP CRM for Utilities

mySAP E&C

• Operate your call center efficiently for improved customer satisfaction

• Manage all B2B relations professionally

Cross-Industry mySAP Business Intelligence for Utilities

Solutions
• Monitor your utility with dedicated key performance indicators
mySAP Enterprise Portal • Make strategic decisions based upon relevant information

mySAP CRM

mySAP SCM mySAP PLM (ASSET AND WORK MANAGEMENT)

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

mySAP PLM
mySAP Enterprise Portal
mySAP HR • Dedicated portal for key account managers
• Role-based portals for employees, retailers, and customers
mySAP Financials

mySAP Mobile Business

Figure 2: mySAP Utilities

• Asset and work management Certain cross-industry solutions that are especially relevant
• Regulatory reporting for utilities – Federal Energy for utility companies have been modified to meet the require-
Regulatory Commission (FERC) ments of the utilities industry and, like all other mySAP.com
Note that this area meets the special demands of regulatory solutions, can be integrated in mySAP Utilities. These include:
reporting in the American utilities market. Its tools use • mySAP Customer Relationship Management (mySAP CRM)
financial data from the database to report to the authorities • mySAP Business Intelligence (mySAP™ BI)
at the federal, state, and municipal level. • mySAP™ Enterprise Portal (mySAP™ EP)

19
BASIC FUNCTIONS AND MASTER DATA
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 Utili-
ties 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
State
Administrative
district
County
Municipality
District
Figure 3: Relationship Between the Different Regional Structures
20
an address. In Germany, the postal code can often be deter-
mined 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 instal-
lations to be billed. A CD containing the postal data of custom-
ers outside the service territory can be applied to the postal
regional structure if required.
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 your-
self. First, you define the hierarchy (for example state, county,
and city) and then you allocate the elements, meaning the
Postal Internal
Administrative
City area
Street Dsitrict office
Street
Branch office
section
corresponding political entities (for example, San Francisco
and Boston), to the hierarchy levels. The political regional struc-
ture 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 effi-
ciently control and monitor business processes, the organi-
zational structure of a utility company in SAP industry solu-
tion 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 allo-
cates 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 high-
est 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 independ-
ent 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 pur-
poses.
21
 Role
Respon-
Task sibilities

Organizational structure with:

• Organizational units
• Belongs to an object or process • Requires parameters
• Positions
(for example, device installation) (for example, division or region)
• Users
• Shipped by SAP • Uses these parameters to
determine the responsibilities

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 auto-
matically 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 deter-
mination 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 sub-
stitute employees), the attributes of the task (such as the divi-
sion 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 accord-
ing 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 partner’s last name
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 company’s
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 con-
figure this area of responsibility, you define a regional structure
group in the responsibilities of the new employee (or of the
job/position).

22
 Portion A Portion B

MR unit A.1 MR unit B.1

MR unit A.2 A MR unit t B.2

MR unit A.3 MR unit B.3

MR unit B.4

MR unit B.5
B
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 MR unit 1 1
Ableseeinheit
record Portion Ableseeinheit 22
Ableseeinheit
Ableseeinheit 3

• Permitted BB cycles • Billing dates • Dates for meter reading and

• BB scheduling • Permissibility • MR order creation
(cycles, divisions, billing classes) • 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 installations together according to regional criteria. They

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
contain all the data relevant to meter reading scheduling.
To generate due dates for budget billing, you have to main-
tain 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 The technical master data consists of:
Master data is data in mySAP Utilities that remains unchanged • Connection object
over an extended period. It is divided into business and techni- • Connection
cal master data. The business master data consists of: • Premise
• Business partner • Device location
• Contract account • Utility installation
• Utility contracts • Point of delivery (POD)

mySAP UTILITIES HOUSE

Connection object

Apartment 1 = premise Hall Apartment 3

Utility-
Contract 1: installation 1:
electricity elect. meter

Device location: Apartment 2

corridor

Business Contract Contract 2: Utility-

partner account gas installation 2:
gas meter

Basement

Contract 3: Utility- Device location:

water installation 3: basement
water meter

Service connection: water Service connection: gas Service connection: electricity

Supply grid

Figure 7: The mySAP Utilities House

24
Business Partner
In SAP R/3, a business partner can assume a number of roles
simultaneously. However, a business partner’s master data is
stored just once in a central master record. This reduces the
amount of maintenance required and prevents data inconsis-
tency. mySAP Utilities uses the business partner in the follow-
ing roles:
• Contract partner who has a contract with a utility company
for delivery and purchase of utility services. A contract part-
ner 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 politi-
cal 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 country-
specific 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 Dunning data

• Account description • Dunning control
• Acct no. in legacy system • Dunning recipient
• Payment conditions • Dunning disconnect reason
• Tolerance group

Control Inbound payments

• Alt. bill recipient • Payment method
• Payment via collective invoice account Contract • Bank details
• Additional bill account • Alternative payer

Acct assignment data Outbound payments

• Item line display • Payment method
• Planning group • Bank details
• Account determination • Alternative payer

Figure 8: Contract Account

Contract Account Utility Contract

A contract account groups together all of a business partner’s
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
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 divi-
sions 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.

26
 GENERAL DATA BILLING DATA

General contract data Billing data

• Contract account • Joint invoice
• Division • Billing block reason
• Company code • Outsorting group
• Plant/company cons.
• Statistic group
• Authorization group

Budget billing data Contract Acct assignment data

• BB amt adjustment • Account determination ID
• BB cycle • Cost center
• Business area

Deregulation fields 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 company’s
generation and distribution installations
• Company consumption contracts (the utility’s own
consumption) for example, for electricity consumption
in the utility company’s 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 follow-
ing 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

Characteristics
• Maintenance plant
Notes to Connection • Authorization group
field service object • Regional structure group

Figure 10: Connection Object

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

can allocate more than one contract to an account and then A connection object is usually a building, but it can also be a
bill those accounts collectively. However, only one utility property or other entity (such as a fountain or a construction
installation can be allocated to each contract. With the excep- site). Since a connection object is allocated an address, it links
tion of move-in and move-out data, you can change, display, premises, device locations, and connections with the postal
and check all the data of multiple contracts in a contract regional structure. The connection object is allocated to a sup-
account (this applies to those contracts that have not been ply territory. The connection object is based on the functional
cancelled). The move-in and move-out dates represent the location of the Plant Maintenance component. This means
beginning and end of energy supply in the division specified you can use the functions of Service Management to organize
in the contract, or partial service in a division. If a particular the installation, removal, and maintenance of devices. In addi-
utility service ends, the customer with that service is identified tion to the general data of the functional location, the connec-
as moving out and the utility contract is classified as canceled. tion object contains industry-specific data.
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 customer’s utility contracts are canceled
(as a move-out for all contracts).

28
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 Mainte-
nance 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 divi-
sions, for example). The premise is therefore not related to one
specific division. It is allocated to a connection object and con-
tains 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 Configurable
• Connection info
Equipment
• 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
Characteristics
• Street
• Premise type
• House number
Premise • Owner
• Floor
• Number of persons
• Room number
• Authorization group
• Location description

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 connec-
tion 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.
Location
• Connection object
• Location Device location
• Additional location info
• Premise
Figure 13: Device Location
30
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
General data
• Description
• Authorization group
lation structure (see Chapter 4 – Energy Data Management).
At any given time, the installation is allocated to a single con-
tract. 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 infor-
mation 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 Individual
• Premise facts
• Current contract
• Current business partner

Time-dependent data Billing and

Utility meter reading control
installation

Deregulation fields Allocated devices

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 deliv-
ery ID is unique means that misunderstandings can be avoided
and data correctly allocated when information about the ser-
vices supplied to a POD is provided. This is also the case if a
customer switches utility companies. There are two commu-
nication 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 communi-
cation is used to import profile values to the Energy Data
Management component.
Non-
Contract
billable
= billable service
service
Deregulation point of delivery
Installation
Premise
Connection object
Figure 15: Point of Delivery
32
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 com-
munication 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.
Non-
billable
service
Point
of
delivery
Technical point of delivery
Device Register
Device location
mySAP CUSTOMER RELATIONSHIP MANAGEMENT
FOR THE UTILITIES INDUSTRY
The Internet and other virtual communication portals enable FUNCTIONAL SCOPE OF mySAP CRM
even the smallest companies to compete in global markets. Philosophy
This trend, however, has also raised customers’ expectations, mySAP CRM is a cross-industry solution that can be integrated
especially regarding service. All-encompassing, round-the-clock with mySAP Utilities to provide optimal, cross-system sales
customer service and personalized products and services are and marketing processes for all customer groups in the utilities
now taken for granted. If dissatisfied, a customer can switch to industry. These groups may include residential customers,
the competition at the click of a mouse. Consequently, as a non-residential customers, chain customers, and outline con-
utility company, you must work with a modern, comprehen- tract customers.
sive customer relationship management (CRM) system that
supports a variety of different contact channels. Customer A CRM solution must meet several basic requirements:
service is not a tiresome obligation; it is a strategic necessity. A • It must provide a platform from which each employee,
CRM solution must facilitate communication with your cus- partner, and customer has access to the information and
tomers across all channels, including telephone, fax, e-mail, functions required. This platform must be adjustable to
Internet, hand-held device, and personal consultation. Seamless meet the requirements of all users (people-centric CRM).
integration with all front- and back-office applications, com- • You must be able to view and process customer-oriented
pany business functions, and business partners is also essential. business processes in all systems. The integration of front-
mySAP Customer Relationship Management (mySAP CRM) end, back-end, and analysis tools is especially important. This
can be used to win new customers in highly competitive mar- has been achieved by integrating mySAP.com applications
kets and retain existing customers. Increasingly, companies are and technologies, expertise, and content. This is the only
looking for integrated software that guarantees a universal, means of guaranteeing that all processes are continuously
smooth, and efficient process, starting with customer interac- monitored and can be used as the basis for strategic decisions
tion through to service provision, customer service, billing, (connected CRM).
payment request, and monitoring. • 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 con-
sistent. 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, bil-
ling, and communication from all integrated systems is essen-
tial 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 manage-
ment 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 communi-
cation 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 neces-
sarily 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 dif-
ferent 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 tele-
phone 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 cus-
tomers 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

Customer retention Contact management

• Complaints management • Market analysis
• Service-level management • Marketing planning
• Customer retention management • Target group selection and campaign
• Customer development management management
• Monitoring and success checks • Telemarketing
EN • Internet marketing
E
IC G • Monitoring and success checks
RV

AG
SE

Operation/Service Sales
• Service interaction center • Field service sales
• Internet self-services • Internet sales (B2C)
• Service center • Internet sales (B2B)
TR

• Field service • Telesales

LL

AN
FI

• Monitoring and success checks L

SA • Sales management and support
FU CT
• Monitoring and success checks

Figure 16: The mySAP CRM Customer Relationship Cycle

B2B Internet sales grant interval customers and non-residen-
tial 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 rele-
vant 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 cus-
tomer wants to sign a gas contract. The system suggests that
the customer also buy a gas contract together with a mainte-
nance 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 dis-
play important information for call center employees while
they are talking to the customer, so that telephone conversa-
tions can continue uninterrupted.

35
Sales management and support enable you to monitor and
control the sales field service. In this way, you can use oppor-
tunity 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 ser-
vice inquiries and orders. When customers call with inquiries
or technical problems, call center employees can search a data-
base for answers and solutions. The proposed solutions can
then be faxed or e-mailed to the customer. If these are not suf-
ficient 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 employee’s data (for example, their qualifi-
cations and schedules).
The field service capability of mySAP CRM is a mobile solu-
tion for service employees. They receive notice of pending ser-
vice 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 informa-
tion 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 ser-
vices 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 deter-
mine 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 back-
end solutions without any loss of performance. This is the only
way of ensuring that the value-added chain flows across all sys-
tems, 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 informa-
tion about the CRM middleware is stored on a temporary
basis
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.
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 dur-
ing system migration.
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 com-
monly 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. Conse-
quently, a call center employee can work with those profiles
and configurations that correspond to their tasks. This is espe-
cially 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 Telesales
Configuration
Telemarketing
Configuration
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 follow-
ing 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.
Data finder
Navigation area
Figure 18: Sample Configuration for the Interaction Center
38
• Reminder scripting
Supports call center employees when dealing with cus-
tomers. 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 over-
view, and so on.
Telephony function bar
Action box
Work area
• 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 com-
plaints 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.
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.
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 customer’s 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).
39
INTEGRATION OF mySAP CRM IN mySAP UTILITIES
System Landscape

ANALYSES FRONT-END

Electronic
SAP BW business
(Internet)

M Syste
P CR m
SA

ITS/
WAS
Middleware

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

mySAP Mobile
Utilities applications

BACK-END

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

When mySAP CRM, mySAP Utilities, and mySAP Business • Different tasks can be carried out in parallel without impair-
Intelligence with SAP Business Information Warehouse are ing the performance of the other systems. For example, a
integrated, the most sensible approach is to run the processes billing run in the back-end system (mySAP Utilities) does not
across all the systems. This approach has the following benefits: affect the call center of the front-end system (mySAP CRM).

40
• Even if some objects are available in both systems, not all
data has to be synchronized between those systems. It is suf-
ficient, 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 qualita-
tive 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 with-
out 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.
However, be aware that running processes across all systems
does not mean that each system must run on separate hard-
ware. 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 func-
tions needed for marketing, sales, and customer retention, and
enables you to communicate with your customers via a num-
ber of different channels, for example:
• Web-based applications (Internet sales and Internet market-
ing) that are integrated in the CRM solution using modern
and open Java technology
• CTI interface that connects mySAP CRM with the telephone
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.
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 cus-
tomer interaction, and model and evaluate all sales processes
from acquisition of new customers through contract creation
to billing.
41
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
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-

SELECT PRODUCTS VIA MASTER DATA GENERATED OR

mySAP CRM CHANNELS: CHANGED IN mySAP UTILITIES

Fixed product information

Internet

Master data mySAP

mySAP CRM Master data generator
Customer Call Center Utilities
product template
(Susan Moore) (Connie Johnson)
“Family Energy” “Family Energy”

Configuration Configuration

Hand-held

Variable product information

Cross-system business processes

Figure 20: Selling a Utility Product

42
tomer can be recognized at a glance in mySAP CRM – regard-
less 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 cam-
paigns 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 automat-
ically 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 move-
in, 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 company’s interaction center. She
wishes to switch to the utility product “Family Energy” to
reduce her energy bills. The call center employee, Connie
Johnson, takes Susan’s address, asks for her electricity con-
sumption for the past year, and the start date for the new prod-
uct (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 infor-
mation (which is identical for each business partner) and vari-
able 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 syn-
chronized 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 informa-
tion (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 consoli-
dated 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 informa-
tion 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 op-
portunity 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 allo-
cated 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 cam-
paign, 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 indi-
vidual business partners are created, enabling you to see
which partners were targeted by the campaign. A business
partner’s 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 pros-
pect. 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 gen-
erator 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 trans-
ferred to SAP BW, where the campaign number can be used
to analyze how much revenue was generated by the cam-
paign 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 cus-
tomers 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 con-
tinuously monitor the non-residential customer. The
opportunity also forms the basis for pipeline analyses, fore-
cast calculations, and win/loss analyses. SAP also provides
a predefined sales methodology (a specially modified
opportunity) that supports and controls sales using prede-
fined 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 non-
residential customer is either imported into a calculation
tool (via SAP Energy Data Management (EDM) or a stan-
dard 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 product-
specific 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 cus-
tomer, and determines the grid usage conditions (which
are derived from the distributors responsible for the with-
drawal 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 quo-
tation 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 termi-
nated, a contract end date is entered in the existing con-
tract.
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 profit-
ability 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 customer’s 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 trans-
fer data between the different steps. Limited options for repeat-
ing 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 employee’s inbox; the necessary activities appear
on the employee’s 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
customer’s request, the item can be resubmitted for the rele-
vant agent. The initial agent can include additional infor-
mation 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. Con-
tracts 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 termi-
nated. In the case of a customer change, the utility’s instal-
lations 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 requir-
ing 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 customer’s 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 customer’s contact details.
6. The agent can process the customer and their contract
account.
7. The agent can perform the final meter reading immedi-
ately, 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 wel-
come 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
customer’s 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 customer’s move-out.
6. The agent requests the customer’s 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 trans-
action for changing bank data.
3. The agent stores the new bank details in the customer’s
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 trans-
action 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 cus-
tomer 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 install-
ment 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.
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.
Bill Complaint
You can use this workflow if the customer disputes the meter
reading results used to create the bill.
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 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.
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 customer’s 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 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.
49
Lay a Service Connection
This business process has also been implemented as a work-
flow. 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 cus-
tomer’s or utility company’s request.
In the former case, the customer is reconnected when the out-
standing payments are made; in the latter, at the request of the
party that ordered the disconnection. Flat-rate charges for dis-
connection 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.
INTERNET SELF-SERVICE INCLUDING AUTOMATIC
CHANGES IN mySAP UTILITIES
Internet self-services (ISS) provide your customers with round-
the-clock services. Customers can take advantage of your cen-
tral 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
• 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, inte-
gration 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.
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 tem-
peratures
• 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 infor-
mation 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 regis-
ters. 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 allo-
cated 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 cer-
tification data. The device category in mySAP Utilities corre-
sponds to the material in the materials management compo-
nent.
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 company’s stock because
they have been scrapped or sold are processed in inventory
management using the goods issue and return delivery com-
ponents. 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 in-
puts 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 transforma-
tion 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 in-
stallation. 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 installa-
tions
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: techni-
cal 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 read-
ing 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 dam-
aged or if it is to be certified. In the event of device replace-
ment, 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 billing-
related 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 trans-
former 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 differ-
ences:
• The rental price and regulation price are only entered in the
service provider’s installation
• Rating is dependent on consumption
• Additional devices, such as ripple control receivers, are only
installed in the service provider’s 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 Device
category category
A B

Sample lot Periodic replacement year

Replacement
orders for sample devices and Replacement orders
spare sample devices for all devices

Figure 22: Overview of the Certification Procedure

55
 Put together Determine
Create lot 1st drawing
lot devices for lot

Check sample
2nd drawing devices

No Yes
Passed ?

Certify
Delete lot
samples

Copy devices to
periodic Extend lot
replacement list

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 exter-
nal 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 with-
out being removed.
Device inspection consists of the following phases:
• Sampling procedure
The sampling procedure is the basis for renewing the calibra-
tion 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.

56
 MR order creation Billing order

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 cer-
tified are removed and replaced by equivalent devices. You
manage the devices to be replaced using the periodic replace-
ment list, where you can also enter other devices (for exam-
ple, all the devices from a certain lot). You can then choose
from the list those devices that have to be replaced at a cer-
tain 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 manage-
ment 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 exam-
ple, 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 can-
not 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 reader’s 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
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 company’s 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).

MR unit
City district 1
A

Street 1

Connection
object 1
Street 2
Device location
1
Connection
object 2
Street n Device 1
Device location
2
Connection
object n
City district 2 Device 2
Device location
n

City district n Device n

Figure 25 – Street Route

58
• Mass orders
With periodic meter readings, you can create orders simulta-
neously 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 docu-
ment readers (download). Alternatively, you can print them
out from external printing systems.
ENERGY DATA REPOSITORY
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 mea-
surements. It can also be data created by load shape measure-
ments 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 pro-
files), 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 exam-
ple), and weather data for load forecasts are all examples of
this. These time series are called profiles.

Interval Internet BAPI import

meter interface ENERGY DATA REPOSITORY
Dialog
Residential Idoc
customer AMRS interface Time slice
meter (load shape)
MDE …
Other market PoD
players IDE

Meter reading

ENERGY DATA REPOSITORY

Data retrieval

Electronic data exchange

Replacement Data evaluation

Data import Consistency
value creation and
checks 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 exter-
nal entry system. Meter reading results are uploaded using an
intermediate document (IDoc) interface through direct input.
IDocs are used for electronic data interchange between sys-
tems. 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 cor-
rection 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 valida-
tion 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
Correct Check
Enter in SB
Implausible Plausible
Bill Follow-up
Figure 27: Validation
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 customer’s meter reading results were taken
is representative. You determine the representative period in
the rate in relation to the length of the period. The represen-
tative 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 por-
tions that are valid for the period. The weighting portions
are determined by the weighting procedure, which is allo-
cated 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 consump-
tion 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 customer’s consumption pattern.
PRIORITY ORIGIN OF BASE VALUE FOR
BASE VALUE EXTRAPOLATION
Meter MR Expected
1 reading result consumption
Period Expected
2 Register consumption consumption
Figure 28: Extrapolation
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 weight-
ings 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 weight-
ing procedure.
The validation result is determined by the status of individual
meter reading results. Depending on the outcome of the vali-
dation, 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 correc-
tion order) with the updated information. If meter readings
and consumption values are missing, you can use mass estima-
tion 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.
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 calen-
dar. 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 dynam-
ic modification factors directly in the system, save them as sep-
arate 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 cus-
tomer is saved for every synthetic load profile. This consump-
tion factor is automatically updated and saved when you deter-
mine the consumption of the non-interval customer. You
require consumption factors for settlement, forecasting con-
sumption, and determining overtake and undertake amounts.
You can save several consumption factors for a single custom-
er. You do this if you want to save different consumption fac-
tors 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 consis-
tency checks are made for every profile value import. These
check the validity of the inbound data and react to the prede-
fined 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 miss-
ing 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
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
• Replacement values copied from reference profile with
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 consump-
tion manually.

63
 1 2 3 4 5 6 7 8 9 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Figure 31: Extrapolation of Profile Values

Replacement values must be created in two different replace-
ment 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.
• 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.

64
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, user-
definable calculation guidelines that are based on mathemati-
cal 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 calcula-
tion 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,200 1,205
SUM 01
Load shape of cust. A Profile for Total Total load shape AB
addition profile
120
kWh 15 min intervals kWh 15 min intervals
Add profiles
(quantities)
Historical profile Formula profile

1,201
KEY
Load shape of cust. B

kWh 15 min intervals Profile Calculation status

Formula
Profile allocation
Historical profile Formula allocation
Unit Interval length
Formula
description
Profile type

Figure 32: Formula Allocation

65
Calculation triggers are used for calculation flags. They indi-
cate 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 exam-
ple), this is immediately updated in the tables and graphics.
Figure 33: Graphical Profile Value Display
66
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 read-
ing 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.
SETTLEMENT
Settlement in energy data management refers to the settle-
ment of energy quantities. All input data required for settle-
ment 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 WORKBENCH settlement runs and
creation of schedules

Settlement document Settlement procedure (e.g. synthetic, analytical)

Settlement
log

Settlement run Settlement mode (Simulation, active)

SETTLEMENT PROCESS

Input parameter
(e.g. determine
Interim result Settlement step ...1
total load shape)
Output parameter

Input parameter
(e.g. subtract
Interim result Settlement step ...2
interval customers)
Output parameter

Input parameter
(e.g. send results
Interim result Settlement step ...n
using IDE)
Output parameter

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.
Figure 35: Settlement Document
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. Settle-
ment steps are the smallest units (algorithmically meaningful)
from which a settlement procedure can be assembled. Settle-
ment steps model settlement algorithms and can link input
parameters (profiles and single values) and calculate output
parameters. The implementation of settlement steps is object-
oriented 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 settle-
ment steps. Therefore, settlement steps that are not provided
68
by SAP can also be modeled in the system. You use an SAP
business workflow or an executable program to combine indi-
vidual settlement steps in such a way that you can execute the
appropriate settlement procedure.
Figure 36: Workflow
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 par-
ticipant (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 com-
ponent.
Documenting and Logging Settlement Runs
Comprehensive documentation and logging tools are available
for settlement runs. You can view the status of a full settle-
ment 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 settle-
ment 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 con-
cerning 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 trig-
ger 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 settle-
ment run. Each exception can have an individual response in
the form of additional processing such as an e-mail notifica-
tion to you, or an SAP business workflow.
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.
Settlement Views
If the supplier and the distributor are managed in the same sys-
tem, you may have to allocate a point of delivery used for set-
tling settlement unit A to settlement unit B in order to create
schedules. Settlement views separate the distributor and sup-
plier 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 inde-
pendently from the others. Every settlement unit and every
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)
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.
Taking Grids into Account
You can also include grids during settlement. You can divide
a distributor’s grid into several grids if, for example, the distri-
bution 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 settle-
ment 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 in-
volves the technical infrastructure described in the section on
settlement procedures. Schedules are created in a series of indi-
vidual steps ending when they are sent to the settlement coor-
dinator. 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 sup-
plied 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 com-
panies to multinational conglomerates, can benefit from
energy data management. As a result, the scope of the EDM
component can change according to each company’s 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 re-
quires high processing speeds can be processed in parallel.
This technology allows the energy data management com-
ponent to scale according to your company’s 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 archi-
tecture 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 implementa-
tion but also throughout the entire product life cycle. More-
over, 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 interna-
tional 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 company’s utility services and
other services. The central billing program enables you to map
all possible combinations of billing steps. Dynamic rate deter-
mination 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
• 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.

Meter reading Meter reading Billing Invoicing Bill print

order creation order entry

Billing order Billing order Billing document Print document

Plausible
Meter reading meter reading
order results 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 pro-
files 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 par-
tial 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 proce-
dures:
out, when a contract is terminated, or when a service territo-
ry 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, sim-
ulation, 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

• Periodic billing periods are current billing periods that are

normally triggered by a meter reading, and whose time peri-
ods are defined in scheduling. You can use periodic billing 15 kW 15 kW – 10 kW
Month 02
to create additional periods:
– Correction periods: Correct periodic billing periods that
have already been billed (during period-end billing and
20 kW 20 kW 20 kW – 2 * 15 kW
backbilling). Month 03
– 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 25 kW 25 kW 25 kW 25 kW – 3 * 20 kW
the past, present, or future. The results can be saved in the Month 04

periodic billing document as informative lines or billing

lines relevant for posting. For example, you can display the Figure 38: Floating Backbilling over n Periods
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.
01 02 03 04 05 06 07 08 09 10 11 12 13
Unplanned interim billing can be executed for some billing
procedures. This can be done, for example, at the customer’s
request. You can execute final billing when a customer moves Figure 39: Period-End Billing

72
• 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 cor-
rection period so that the last three months are always cor-
rected.
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

• Billing based on real meter reading results MR1

• 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 120 118 133 112 117

MR1
• Billing based on real meter reading results
• Invoicing billing documents

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 exe-
cuted 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 extrapo-
lated, 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 real-
time 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 Block 2 Block 3 Block 4 Block 5 Block 6

Price A Price B Price C Price D Price E Price F

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
The following are examples of billing procedures based on • Seasonal aspects, such as different on- and off-peak rates for
a measured load profile: summer and winter
• Time-of-use billing • Calendar aspects, such as different on- and off-peak rates for
Consumption measured in intervals is added together and working days, Sundays, and public holidays
evaluated. • Consumption aspects, such as valuating measured consump-
• Real-time pricing tion portions in combination with consumption or demand
Consumption measured in intervals is valuated with a price limits.
that is valid for each interval.
By using the RTP interface, you can model agreements with
The RTP interface provides you with flexible options for struc- special customers or customer groups at short notice. These
turing rates for your non-residential and major customers. agreements can contain particular billing rules, such as indi-
You can select several aspects, including: vidual prices. The RTP interface is an integral part of the bill-

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 manage-
ment (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 exe-
cuted 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.
input-
profile
kW/kWh
Off- On- Off- On- Off-
peak peak peak peak peak

Result
Result- Virtual parameter
profile profile Result
function
Off-peak Σ
Consmp. Off-Pk cons.
Off- Off- Off- kWh = 275
peak peak peak
mySAP
Utilities
Business
Intelligence
Rate facts

Result
Result- Virtual parameter
profile profile Result
function
On-peak Σ
Consmp. On-Pk cons.
On- On- kWh = 500
peak peak

Figure 43: Example of How an RTP Interface Works

76
BILLING DIVISIONS
Contract billing enables you to bill different divisions in one
Gas procedure
contract account. The divisions are mapped at the contract
level. In addition to the basic functions, you can also use divi-
sion-specific functions.
Individual settings Individual settings
Electricity Vol. correction factor
Calorific value procedure procedure
During electricity billing, the measured meter reading differ-
ences are converted into consumption values. Register factors • Determined calorific value • Fixed-volume correction factor
and billing factors are included in this process. When changes • Arithmetic average creation • Determined vol. correction factor
• Weighted average • Special procedure
are made to the billing master data using standard and cus-
tomer-weighting rules, electricity billing enables you to divide
up consumption values (for example, for price changes) when Figure 44: Gas Procedure
the actual meter reading results are not available. There are
particular functions in activity-based electricity billing (prepro- Gas
cessing demand), that, for example, calculate the average of In gas billing, meter reading and billing dimensions are nor-
demand peak values, or allocate demands to a particular sea- mally different. Therefore, the amounts must be converted so
son. Based on the settings that have been selected, the n peaks that the energy contained in gas can be calculated from the
per billing month or per season are identified and the system measured volume. In the gas procedure, you can determine
calculates the average. You can determine whether all peaks the following types of billing:
should come from the same months, or whether they have to • Volumetric
come from different months. Preprocessing demand during • Based on standard volumes
period-end billing and backbilling ensures that demand data is • Thermal
transferred between the periodic billing periods and correction
periods. This means that correction periods can be backbilled The gas procedure combines the volume correction factor pro-
using the current peak average. cedure 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 mea-
sured 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 differ-
ent volume correction factor relationships, such as:
• Transmitting the volume correction factor from one device
to another
• Calculating the volume correction factor from the con-
sumption 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 be-
tween 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 nor-
mally 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 custom-
ers and outline contract customers. An outline contract is
between a distributor that owns a grid to which the customer
is connected, and the customer’s 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
for all individual contracts, and before they have been billed,
the total consumption is determined and used for the indi-
vidual 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.
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.
BILLING MASTER DATA
Billing master data controls contract billing. This master data
stores the rate structures that contain your company’s billing
rules and the contractual provisions.
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 valuat-
ed. 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 lated (to the day or on a monthly basis)
• How the billing line items are handled statistically • The divisions and billing classes to which the rate is allocated

Installation

Installation struct.

Rate type Rate cat.

Rate type Rate cat. Rate

For
Rate determ. Off-peak Normal Rate 1
example

On-peak Normal Rate 2

Operands
• Demands Rates
VarProg Operand values
• Prices
• ...

Billing schema

Rate 1 Variant program Operand values

Step 1 For example, 1000kWh, 0,25$
Step 2 Quantity x Price 400kW, 300kW
Comp. 2 demands
Rate 2
Step 1

Figure 45: Master Data in Contract Billing

80
Rate Categories
Rate categories contain data that controls the billing of multi-
ple 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)
In some cases, you can override data by making individual
entries in the installation facts at installation level.
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
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.
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 individ-
ual contracts. All discounts and surcharges appear as separate
billing line items in the document and can be displayed sepa-
rately on the bill.
EXTRAPOLATION/STATISTICAL FUNCTIONS
Simulation
Billing can be simulated. During this process, simulation bill-
ing 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 func-
tion 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.
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)
The quantities and revenues are divided among the consump-
tion months during the update.
Unbilled Revenue Reporting
The update of quantities and revenues described in the previ-
ous section only affects the actual data of real billing docu-
ments (not simulated). Unbilled revenue reporting, however,
requires estimated values for not only billed revenues for a pre-
set 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
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 consump-
tion 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
Outsorting
Outsorting is a procedure whereby a document is placed on an
exception list if it has failed validation during billing or invoic-
ing. 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 exe-
cute 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 com-
puters 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 ac-
tivities:
• 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 exam-
ple, 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 can-
celled 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 docu-
ment. The resulting difference is then calculated in the next
billing procedure.
83
Manual Billing
Manual billing enables you to create manual billing docu-
ments 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 auto-
matically improve customer service
INVOICING
The invoicing capabilities provided by mySAP Utilities can
be used to prepare bills in connection with contract billing.
External SD billing IS-U billing
It connects mySAP Utilities with the contract accounts receiv- billing sales, installation supply

able and payable module (FI-CA). It integrates subledger

accounting in mySAP Utilities, processes the mass data pro- Billing documents
Billing documents Credit memos
duced by contract billing, and is used to print bills. Invoicing Backbillings
Basis for budget
is responsible for a number of tasks: billing plans

• Processes billing documents that have the following origins: Invoicing

– mySAP Utilities contract billing Budget Budget billing requests

– Billing from the sales and distribution component (SD) billing Payment forms
Open amounts Bills
items Accounting
(sales, installation) documents
– External billing
• Posts documents to contract accounts receivable and payable FI-CA Printer

• Clears billing requests with posting items, particularly any

budget billing payments made
• Creates print documents and prints bills Figure 46: Invoicing Processes
• Supports reversal processes
• Contains automatic bill checks optimize transaction run-times. The processes involved are
• Manages budget billing plans and provides functions for divided automatically for processing. This applies particularly
maintaining budget billing amounts to processes for bill preparation, bill reversal, and bill printing.
• Supports determination and collection of taxes, charges, Invoicing can only take place if billing documents (such as
and duties periodic billing documents, credit memos, and backbilling)
have been created and forwarded successfully from contract
During bill preparation, invoicing supports additional billing. Billing documents are used as a basis for creating
functions from contract accounts receivable and payable budget billing plans. Invoicing produces the following:
such as: • Bill requests and credit memos that are processed further
• Interest calculation in contract accounts receivable and payable
• Dunning • Additional postings in contract accounts receivable and
• Blocking payable, such as clearing postings, interest documents,
• Account maintenance and so on
• Print documents as the basis for printing bills
Invoicing processes can be executed using individual processing • Bill sent to the bill-to party
and mass processing (parallel processing). The system supports
appropriate portioning of the dataset to be invoiced in order to

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 vari-
ous 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 docu-
ments are transferred to an accounting document in contract
accounts receivable and payable. Data from specific billing doc-
uments is summarized here using defined criteria in contract
accounts receivable and payable and additional company-spe-
cific controls. Budget billing payments made or budget billing
requests are taken into account automatically according to the
Account
determination
Budget billing
processing
Invoicing
Payment form
reference
Determination
of
payment method
Figure 47: Basic Invoicing Functions
86
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 con-
tains 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 docu-
ments, 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 dur-
ing 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 prepa-
ration that can be modified to meet the particular require-
ments of your company.
Tax/charge
determination
Bill
preparation
Due date
determination
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 cross-
divisional 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 collec-
tively.
• Contracts whose documents are to be invoiced separately
or whose budget billing amounts are to be requested on
separate bills.
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 transac-
tions that control the program flow are used during bill
preparation. These document the aspect of the business trans-
action 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 deter-
mined from the contract or contract account, these transac-
tions 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

CONTRACT ACCOUNT BILLING INVOICING

Contract 1
Mandatory contract Document 1

Contract 2 No document No document as

Mandatory contract exists yet 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 deter-
mination, 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 assign-
ed 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 deter-
mination procedure. The system determines the bill’s due
Item selection
Invoicing
block
Invoicing
Due date
adjustment
Debit entries
Figure 49: Additional Invoicing Functions
88
date based on the final bill amount. You can also record your
own due date determination rules here according to the pay-
ment 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 customer’s 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 print-
ed on the current bill as a reminder. Automatic account main-
tenance that is integrated in invoicing is used to clear docu-
ment items posted during invoicing with other open items
Account
maintenance
Clearing
control
Interest
calculation
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 pay-
ment 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 receiv-
able 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
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 Flag old
document billing document

Create reversal Create billing

document order
Invoicing reversal,
full reversal, and
budget billing
request reversal
Delete new Reopen budget
budget billing plan billing item

Flag old document

Open old
and create reversal
budget billing plan Reset clearing document
payments

Invoicing reversal billing reversal Budget billing request reversal

Figure 50: Reversal Functions

89
receivable and payable are generated that reverse the bill re-
quests 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 docu-
ments 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.
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 per-
formed 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-resi-
dential customer can be outsorted so that you can check them
again before they are sent out.
90
OK OK
Settlement Invoicing Bill printout
Not OK Not OK
Release Release
Reversal Reversal
Figure 51: Outsorting
BUDGET BILLING AMOUNTS
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 nego-
tiate 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 distrib-
uted 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 proce-
dure you have selected. It is based on the following informa-
tion:
• Calculations from the contract billing component. Auto-
matic 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 automa-
tically 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 automatic-
ally during interim billing rate maintenance.
Budget Billing Procedure
Various budget billing procedures are available that are pri-
marily 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 proce-
dure 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 statisti-
cal 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 par-
tial bill has been created. In contrast to the statistical proce-
dure, 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 regard-
less of whether they have been cleared. This procedure is used
in several countries such as Belgium, the Netherlands, Switzer-
land, 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 agree-
ment 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 consump-
tion fluctuations with a fixed payment plan. The difference
between the amount paid and the actual bill amount is record-
ed 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 per-
mits 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 opportuni-
ty to settle all budget billing items for the year in one payment.
In return for doing so, the utility company grants the cus-
tomer 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 funda-
mentally 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 pro-
cessed 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
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 part-
ners 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 gener-
ates statistical postings in the collective bill account automati-
cally 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 recip-
ient. 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-

SAMMLER INC. WINNIE CHUNG MARCUS ADAMS

Document 4711 Document 471200 Document 471300

Business partner Business partner Business partner

item €348.00 item €116.00 item €232.00

Stat.key.: S CBP doc. 4711 CBP doc. 4711

General ledger item General ledger item

€100.00 €200.00
€16.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 creat-
ed 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 correspon-
dence 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 require-
ments (taxes, postings, and amount clearings).
• You can use all common budget billing procedures available
worldwide.
• New requirements of deregulated markets, such as cross-
company 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 coun-
try-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 docu-
ment items:
• The document header contains data that applies to all docu-
ment items such as the document number, document date,
posting date, and document type. The document type classi-
fies documents depending on which transaction they belong
to (for example, a payment from a collection agency, or a
customer payment).

Document header

Doc. Number: 010000234591 Doc. number: 102345678

Posting date: 02/22/2002 Posting date: 03/05/2002
Doc. type: F1 Reversal Doc. type: S1
Currency: USD Currency: USD
Reconciliation key: TK2202200101 Reconciliation key: TK05003200103
Reversed with: 102345678 Reversal doc. for: 010000234591

Business partner items

Cleared items

GPART BUKRS Date Amount GPART BUKRS Amount

4711 U100 02/25/2002 230,00 4711 U100 230,00
Clearing document: 102345678
Clearing reason: 05

G/L and revenue account items

BUKRS G/L account Amount BUKRS G/L account Amount

U100 800000 200,00 U100 800000 200,00
U100 175000 30,00 U100 175000 30,00

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. Receiv-
ables 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 sys-
tem 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 auto-
matically. 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 cus-
tomer. 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 correspond-
ing 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 addi-
tional 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 CO-PA

Rechnung
Rechnung Doc. Nr. Inv. Nr. Amount Division Consumption Amount
Rechnung4711
4711
Bill … … … Electricity xxxx xx.xx
4711
4711 2 0000815 4709 xx.xx Water 4709 xx.xx
0000816 4710 xx.xx Gas 4710 xx.xx
0000817 4711 xx.xx
xx.xx
xx.xx 0000818 4712 xx.xx
xx.xx 0000819 4713 xx.xx
xx.xx
… … …

FI

External 3
billing Account Amount
Archive
system 880000 …
175000 xx.xx

mySAP Utilities-CA

Doc. Nr. Inv. Nr. Amount

Bill … … …
4711 0000815 4709 xx.xx
4
0000816 4710 xx.xx
0000817 4711 storno
0000818 4712 xx.xx
xx.xx 0000819 4713 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 confirma-
tion 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 work-
flow is to be started, the approval levels to be run, addressees
and actions that are permitted up to final approval of the doc-
ument are available. FI-CA functions have also been incorpo-
rated 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 pre-
pared 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 “Docu-
ment 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. Docu-
ments can also be posted manually. The account determina-
tion function can be used to determine G/L accounts automat-
ically 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 avail-
able in Chapter 6, Invoicing.
Cross-company code postings are supported by mySAP
Utilities. In the deregulated market, it is possible that cross-
company 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 includ-
ing 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.
Payment methods are available in the various payment pro-
cesses as follows:
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 pay-
ment 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 is initiated Payment is initiated by the customer

by the utility company

Collection or repayment Lot processing of incoming payments Payment via the cash desk
using automatic payment

– – 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 optimi-
zation.
• 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 sys-
tem also allows budget billing amounts to be processed auto-
matically 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 avail-
able under “Control Clearing of an Open Item” in this chap-
ter). 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 docu-
ments 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, addi-
tional functions are available that are described in the follow-
ing 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 out-
going 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 out-
going 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 auto-
matic 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 docu-
ment 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 con-
trol 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 specifica-
tions made by the customer are processed. Industry- and com-
pany-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 bound-
aries (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 doc-
uments 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.
Returns can trigger the following subsequent actions:
• Generate a customer letter
• Set a deferral date
• Block an account for collection
• Trigger a workflow
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 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 restric-
tion). You can remove the block at any time. Clarification cases
can also be transferred between users. Various actions are avail-
able 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.
Deferral and Installment Plan
If a customer is unable to honor his or her financial commit-
ments, 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 install-
ments 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.
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 cus-
tomers and start the required activities. The respective dunn-
ing 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 inter-
val, 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 auto-
matically for the items. The dunning procedure is recorded at

System configuration

Amount limits, Days Fee schema

in arrears, Print formulas
Dunning interval
Control
parameter

Business
partner

Contract
account
Determine Generate Generate Post
new dunning dunning interest
dunning levels proposals activities 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 sep-
arate 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 dunn-
ing 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 auto-
matic 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 ear-
lier, while deducting interest for an incoming payment that is
received later. Interest calculation provides a number of func-
tions 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 auto-
matically 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 trans-
actions (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 led-
ger or statistical posting and can generate the necessary corres-
pondence. 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 sub-
annually 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 responsibili-
ties 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 con-
tract 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, pay-
ment, 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. Docu-
ments 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
End customer A End customer B End customer A End customer B Payment A

(1) 600 600 (2) (1) 400 400 (2) (3) 600 (3) 400
Bill
(4) 100 (4) 100
Rechnung
Bill
Revenues Receivables SP Payable. SP Revenues

1000 (1) (2) 1000 1000 (3) 200 (4)

Dunning Dunning
End customer
Payment Payment B

(1) Service for end customer A, B (3) Carry over receivables from SP
(2) Submit receivables to billing party (4) Additional service for end customers A, B

Figure 56: Deregulation – Advance Payment

FI-CA supports advance payment and customer payment • Customer payment

during payment management. Customer payment (comparable to advance payment)
• Advance payment involves the billing party being responsible for payment
Advance payment involves all receivables for a service pro- management with the end customer. However, the service
vider to its customers being handed over to a third party provider does not receive payment from the billing party
(billing party). Payment to the service provider is made by until payment has been received from the respective end
the billing party independently of the incoming payment customer. The service provider is usually responsible for
from the end customer. Any dunning notice for the service dunning unpaid items. Both the service provider and the
provider is addressed to the billing party. The system auto- billing party need to be able to track each individual item.
matically rejects collection of the bill amount from the end FI-CA supports detailed payment advice notes for items in
customer. The end customer is dunned by the billing party addition to automated payment forwarding.
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
 Service provider (SP) Billing party (BP)

End customer
End customer A End customer B End customer A End customer B A

(1) 600 600 (2) (1) 400 400 (2) (3) 600 (3) 400
(4) 100 700 (5) (4) 100

Bill
Revenues Receivables SP Payable. SP Revenues
Rechnung
Bill
1000 (1) (2) 1000 600 (7) (6) 600 1000 (3) 200 (4)

Bank Bank

(7) 600 (5) 700 600 (6)

End customer
B

(1) Service for end customer A, B (3) Carry over receivables from service provider
(2) Submit receivables to billing party (4) Additional service for end customers A, B
(5) Customer A pays Dunning from customer B
(7) Incoming payments from SP due to payment by
(6) Payment is transferred to SP through service provider
customer A

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 receiv-
ables 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 deter-
mine 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 back-
ground processing.) The system automatically makes the nec-
essary posting, including tax correction postings required dur-
ing 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 require-
ments. 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 re-
quests 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 statu-
tory requirements with regard to sales tax, withholding tax,
and foreign trade declarations including the respective county-
specific 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 post-
ings 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 with-
holding 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
in the Financial Accounting component FI or an external sys-
tem. This improves performance and reduces document vol-
umes 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 reconcilia-
tion between FI-CA and the general ledger.

FI-CA DOCUMENTS TOTALS RECORDS FI DOCUMENTS

Document 10004711
Reconciliation key TK980410
Posting date 04.10.2002
Company code U100
Partner 99000123
Amount €200.00
Revenue account 800003 Document 120001234
Reference key TK980410
Posting date 04.10.2002
Reconciliation key TK980410 40 140101 500,00
Document 10004712 Posting date 04.10.2002 50 800003 500,00
Reconciliation key TK980410 D €500.00 140101
Posting date 04.10.2002 C €500.00 800003
Company code U100 Posting date 04.11.2002
Partner 99000114 D €600.00 140101 Document 120001234
Amount €200.00 C €600.00 800004 Reference key TK980410
Revenue account 800003 Posting date 04.10.2002
40 140101 500,00
50 800003 500,00

Document 10004713
Reconciliation key TK980410
Posting date 04.11.2002
Company code U100
Partner 99000129
Amount €200.00
Revenue account 800004

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 valua-
tion 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 doubt-
ful 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, receiv-
ables, and payables according to their remaining term.
110
• Revenue deferral
Revenue deferral represents time-related revenue recogni-
tion in FI-CA. Revenues are initially posted with the receiv-
able. 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 con-
tract account on an individual basis. In addition to selecting
the items required (such as cleared items only including statis-
tical 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 infor-
mation, 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 avail-
able to various processes as a credit standing. This means
that activities associated with dunning and returns can be per-
formed 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 part-
ner or account, a number of additional functions are avail-
able 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 require-
ments.
111
INTEGRATION WITH ADDITIONAL COMPONENTS
Integration with the general ledger and other ledgers docu-
ments 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 CO
Invoicing FI-CA
Cash
Manage-
Synchronous posting ment
Figure 60: Integration with the General Ledger, Controlling,
and Cash Management
112
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 corres-
ponding 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 con-
tacts 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 partner’s 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 cus-
tomer 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. Conse-
quently, 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 deregula-
tion 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.
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 misunder-
standings 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

Default value
Regional
structure

Business
Service provider
partner

Service Contract
Non-billable account

Service cat. Contract

Distributor
Distribution Billable service

Deregulated
Connection
Grid Point of delivery Installation Premise
object

Technical

Register Device

Figure 61: Data Model

114
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.
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.

Grid
A grid is an object in mySAP Utilities that corresponds to a dis- Higher-level grid
tributor’s distribution grid, or part of it. You can manage grids
Voltage level
for a distributor. A distribution grid can be divided into several Grid hierarchy
(for example 20 kV)
grids for the following reasons:
• To record grid hierarchies Grid
You can record grid hierarchies in the system by specifying
higher- or lower-level grids. These hierarchies can be evaluated
006
when overall schedules are created for different grids. 005 001 NetCo
004
• If a distribution grid covers several control areas 002
003 Distributor
If these control areas are managed by different control area
Regional structure
operators, you must manage each part of the distribution
grid that is located in a control area as a separate grid in the Figure 62: Grid Hierarchy

Control area operator Control area operator

Regional supplier Regional supplier

Municipal utility company

Stadtwerk

Grid 1 Grid 2
Municipal utility Municipal utility

District utility company District utility company

Figure 63: Distribution Grid Across Several Control Hierarchies

115
• If a distribution grid is divided into different voltage levels, Services
which are represented as separate grids in the system, you A service is used to describe a service supplied to a point
can even allocate different grids (and therefore different of delivery. Services can be billable or non-billable. All SAP
distributors) to different points of delivery for different or third-party services that are billed and/or invoiced are
voltage levels when a connection object (with the same modeled as a contract in the system. Contracts are also
postal address) has a number of points of delivery. described as billable services. All other services are non-billable
services and are modeled as a separate entity at the point of
delivery.
Service Business
provider partner Service Provider
The service provider is a company that plays a part in supply-
Service Contract
ing a point of delivery. A service provider can be a distributor,
Contract
Non- Billable
account a supplier, or a meter operator, for example. As a service pro-
billable service
vider, you can manage your own company in the system or
you can manage other companies with whom you have a busi-
Point of
Installation ness relationship for things like exchanging data or settling
delivery
payment. You can allocate different objects to the service
provider in mySAP Utilities.
Figure 64: Services

Business
partner

Contract
Vendor
account

Billing
G/L account
category

Service provider

Data
exchange Installation
definition

Non-billable
Grid
service
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 “chang-
ing 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 partici-
pating 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 par-
ticular 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 Receiv-
able and Payable.
Supplier as Billing Agent and Rate Ready
A billing agent is a service provider that creates bills and moni-
tors incoming payments for services they provide themselves,
as well as services from any third parties involved. The rate-
ready procedure involves a bill creation process and bill pay-
ment 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 cus-
tomer’s 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. In-
coming bills from the distributor in the supplier’s 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 cus-
tomer’s 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 customer’s 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 exam-
ple, the new supplier sends the relevant data to the customer’s
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 customer’s 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 notifi-
cation 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 relat-
ed 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 busi-
ness 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 dif-
ferent 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 exe-
cuted 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 cre-
ated. When you execute a data exchange task, the data to be
sent to a communication partner is read directly from the appli-
cation 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 trig-
ger 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 sta-
tus 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 ex-
change of data. This could be a link to the corresponding pro-
file 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 R

S
BU TO
SINE EC
SS CONN
XML

SAP HTML
BC WEB
INTE BROWSER
SAP R NET T E CHNOLOGY
System XML

HTML/
XML
XML
Inter- XML
XML WEB
face CONTENT
DERVER
NON-SAP
SYSTEMS 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 Business Processes with Data Exchange

Data is exchanged using IDocs. If you want to send data to
another market participant, an IDoc in the format that is speci-
fied 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 Inter-
net. It can also receive an XML file from another market par-
ticipant and convert it to an IDoc so that it can be processed as
a data exchange process in mySAP Utilities.
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 con-
trolled 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.

120
SOLUTION BENEFITS
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 unin-
terrupted 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.
• Investment security
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 avail-
able 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 avail-
ability and supply of energy. Resources must, therefore, be
used more efficiently – a prerequisite that requires new con-
cepts 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 em-
ployees more effectively, the organization of work manage-
ment 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

Customer-oriented
Customer- service processes Work
centric Open interfaces for management
industry-specific
solutions
Meter services

ASSET MANAGEMENT

Energy supplier
Description and structure of
technical installations

Generator Distributor
Preventative
maintenance
Asset- Work
centric Maintenance cycle 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 geo-
graphical information systems (GIS) and outage analysis
systems
Through its integration with mySAP™ Product Lifecycle
Management (mySAP™ PLM), mySAP Utilities offers an addi-
tional 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
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 manage-
ment 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 automati-
cally created in accounting.
You can link individual technical objects together, and in
doing so, map installations with complex structures (for exam-
ple, power stations and supply grids). You can also create your
own numbering system to identify these installations. You can
create different views of a single installation using the hierar-
chical 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 control-
ling 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 volt-
age 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 corres-
ponding actions are triggered in the GIS.
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 mainte-
nance 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 inte-
grating supervisory control and data acquisition (SCADA) or
process control systems. These systems send status informa-
tion from an installation directly to the SAP System, and auto-
matically 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 mal-
function 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 manage-
ment 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 con-
sideration 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 confirm-
ing 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, discon-
nection, 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 installa-
tions. 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 com-
plete life cycle of installations, but also technical objects and
customer service. Network information systems, geographical
information systems, and SCADA systems all play an im-
portant 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 soft-
ware 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 dis-
tribution of functional locations, equipment, and their hierar-
chies. Figure 68 uses the example of a supply grid to display
this. In this example, the distribution station is the highest ele-
ment in the hierarchy and the transformer fields are subordi-
nate. 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 equip-
ment. 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 func-
tions 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 classi-
fied 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.
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

126
 Functional locations

Equipment

Connection
Object link object

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 subordi-
nate. The devices are classified as equipment that is installed
in the device location.
You can allocate technical installations to individual apart-
ments (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 notifica-
tions 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 requir-
ed 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 des-
cription for all data, mySAP Utilities enables you to configure

Connection object,
Device

Description of resources
for work, material ...
external resources Technical object

Instructions Sales order Service order

Service Product

Maintenance or
Service material service order

Sales view Configuration

Price information

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 charac-
teristics. 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 ser-
vice product describes the service from both a sales and a plan-
ning point of view. The service product configuration not only
affects the instructions, but also the price. You can define char-
acteristics and relationships in order to calculate the price.
The configuration enables you to plan with increased flexibil-
ity 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 com-
pany to carry out underground drilling work, the configura-
tion 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 accord-
ingly. 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 connec-
tion to your customers as the service product: “new service
connection.” To do this, you have to define the following char-
acteristics 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 Yes, No
as customer contribution
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 corre-
sponds 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 CONFIGURATION INSTRUCTION

Cable per m 60.00 Character Values 1. Dig trench

Time: 0.5h per m
Excavator per m 150.00 Surface cat.: Light Tools: Excavator

Connection box Length: 10m 2. Secure trench

Type A 1200.00 only for light soil
Type B 1500.00 Connection type: A
3. Lay cable
Discount for Customer Material: X m cable
customer contribution: Yes
contribution 300.00 4. Install connection box
Time: 1h
Material: Connection box

5. Fill trench
Time: 0.2h per m

Offer, Sales order Service object Service order

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

130
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 reconnec-
tion 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 tech-
nical 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.
• creating a sales order with a service product
By
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 charac-
teristic values, the system automatically creates the complete
order hierarchy, including all orders that belong to the hierar-
chy. 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 characteris-
tics 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 trans-
formers.
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 coor-
dinate 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 customer’s 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, config-
ures 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 exam-
ple, 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 digitaliza-
tion 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 techni-
cal 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 Connection information

AM/FM

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 infor-
mation 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 direc-
tions. 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.
GIS
GIS Business
Connector
Methods
GIS
application Middleware
Methods
Enhanced
GIS application
Business objects
Figure 73: The GIS Business Connector
134
The GBC also has its own data storage. It can temporarily store
data and tasks if a system is not available, enabling you to exe-
cute 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 guaran-
tees that the process runs correctly and the data remains con-
sistent.
SAP
SAP
applications
Enhanced
SAP application
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 ser-
vice 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 sys-
tems (OMS) and computer-aided scheduling and dispatching
systems using this work management interface. Outage man-
agement 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 distur-
bance 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 con-
struction 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 notifica-
tions 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 cus-
tomer 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 differ-
ent 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 sys-
tem. The order-related substeps, such as service orders and
resource planning, are always processed in a second SAP sys-
tem. 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 cus-
tomer 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, docu-
ments the measures taken, stores the history, and supplies
your employees with all the necessary, up-to-date informa-
tion 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 exten-
sive 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 process-
es 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 interna-
tional 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 elec-
tricity – 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 struc-
tured 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 can‘t be supported profitably?
Where can I increase my business?
Which campaign was successful?

Sales Profitability Market share

Delivery Human resources Quality Market potential

Marketing costs Sales/service costs Customer satisfaction

SAP Non- mySAP mySAP

Provider File
R/3 SAP Utilities CRM

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, con-
sumption, demand, rental price, and changes to stocks. Busi-
ness 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 proces-
sor (online analytical processing), the graphic user interface
(BEx), and Web reporting. SAP BW allows you to evaluate dif-
ferent 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

Contract creation Sales revenue, Stocks and Opportunities,

and changes, Consumption data, transactions, Family tree
Service orders Master data costs, contacts

mySAP Utilities

Figure 75: Example of Campaign Management

138
nection objects. These statistics can also be combined in SAP decisions on any further action. For example, you might con-
BW using new analytical applications (analytical CRM). The sider starting a campaign to win back these customers. If you
ability to combine and analyze these statistics provides you do, you can select target groups from consumption statistics
with new insights into datasets and new resources for market- and transfer them to mySAP CRM. The success of a campaign
ing and sales as well as a more customer-oriented, profitable can then be analyzed using consumption statistics based on
corporate management within liberalized markets. The follow- expected consumption and profit of new or changed contracts.
ing examples illustrate parts of SAP BW with a closed system. There are, of course, other scenarios based on different statis-
tics. Some of which are described as follows:
An Example of a Marketing Campaign
You want to start a gas marketing campaign in mySAP CRM, Stock Statistics
using a target group from mySAP BI. The target group is made Stock statistics show you how the stocks of your utility compa-
up of data that has been recently and periodically transferred ny (for example, customers and contracts) develop. The stocks
from mySAP Utilities. For example, you create a list of all cus- are evaluated at different levels and in the context of the whole
tomers that live in a particular area, whose consumption last company. They are also analyzed chronologically and histori-
year was higher than 10,000 kWh. They do not have a gas con- cally down to premise level. Business Content enables you to
tract but can easily be connected to an existing gas grid. These display all changes to stock statistics and access individual con-
customers could all be potentially supplied with gas. You then tracts especially during master data reporting.
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 Figure 76: Overview of Stock: Customers and Contracts
caused by customers changing suppliers. By using Business
Content, you can check whether customers who terminated You can also view the historical development of your con-
their contracts registered a high level of complaints, and if so, tracts in each division and company code and identify trends
what was the nature of the complaints. At the same time, you in advance. You can then compare these trends with the stock
can also use the consumption statistics to check how much statistics for your business partners. This analysis also supports
revenue your company made from these customers. You can
then use this information to forecast losses as well as make

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 cus-
tomer 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 ap-
propriate manner. Disconnections and reconnections must
also be analyzed for monthly reports to regulation authori-
140
ties. Here, it is important that relevant disconnection infor-
mation 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 discon-
nections 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 com-
pany 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. Trans-
action statistics provide you with the number of manual pro-
cesses 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 billing-
related device installation and removal (when the device was
allocated to a utility installation). Data is stored on a month-
ly 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 compa-
ny, sales statistics provide different views of sales data. There-
fore, they help you analyze quantities and amounts of demand
and work, as well as process revenues. You can use this infor-
mation as a basis for optimizing your rate and price structure.
Additionally, you can evaluate local authority franchise pay-
ments or revenue developments according to industry, divi-
sion, or business partner. With SAP’s predefined Business Con-
tent, utility companies can also display taxes to be paid on an
aggregated basis, for example, according to sales district (juris-
diction code) – a function that is very important in the USA.
Figure 77: Sales Statistics According to Division
Consumption Statistics
In marketing, it is not only important to know what quantities
and amounts were invoiced for a particular period. Consump-
tion that has not yet been billed is equally important. You can
only create an overall view of a customer’s or customer group’s
potential revenue if you have both sets of statistics. Consump-
tion 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 installa-
tions – 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 extra-
polated 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
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 company’s annual or monthly balance sheet. Utilities
companies have particular demands when generating a com-
pany 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 busi-
ness 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 differ-
ences 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 cus-
tomers, 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 customer’s annual consump-
tion billing is from the balance sheet key date.
Unbilled revenue reporting can also be used midyear to deter-
mine 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 docu-
ments in billed contracts, the individual procedure analyzes
all contracts individually. For each contract, the system deter-
mines 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 con-
sumption 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 Manage-
ment – Business Planning and Simulation (SEM-BPS) to exe-
cute 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 combina-
tion with mySAP Utilities, supports comprehensive and strate-
gic 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 pro-
cedures. 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 company’s success. Analyzing
cleared items provides you with information on your cus-
tomers’ 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 dif-
ferent 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 Decide

CRM SCM Financial HR PLM Custom-Built

E-Analytics
Analytics Analytics Analytics Analytics Analytics Analytics

Structured
Data &
Content
Analyze Adjust

Customer Others
Relationship (Siebel, i2, Financials
Management Oracle, ...)

Unstructured
Supply Human Product
Information
E-Commerce Chain Capital Life-Cycle
& Content
Management Management Management

Figure 78: Analytical Applications

143

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 pre-
dict 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 frame-
work 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 pro-
vides 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 con-
tracts that resulted from a campaign.
144
Controllers can analyze the payment behavior of certain cus-
tomers 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.
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 com-
pany – 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 data-
base, 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 pass-
word.
mySAP
SAP CRM Shop Groupware
Utilities
Intranet SAP BW 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 infor-
mation 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 struc-
ture 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 col-
laboration 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 com-
pany. You do not have to search for information because it is
automatically sent to you. Key account managers, for exam-
ple, can immediately view all new information and data that
refers to their companies. Not all of the information is im-
mediately 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
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

Access to Internet
applications content and In today’s business world, quick response times are extremely
services
important and decisions have to be made as quickly as a possi-
ble. To make the right decisions, managers must have fast and
Unstructured
Structured

reliable access to all relevant information. However, managers

Enterprise seldom have extensive access to current and relevant informa-
Portals
tion. 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
Business Knowledge partially meet the demands of problem analyzing and problem
intelligence management
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
Extracted and formatted information
data and information from mySAP HR and mySAP™ Financials
(mySAP™ FI). This data can be used to make the right decisions
Figure 81: Types of iViews

146
quickly and effectively. The business package helps managers
to effectively perform their administrative and planning tasks.
This includes recruiting personnel, carrying out annual em-
ployee 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 pro-
cesses. Managers can better manage their cost and budget
responsibilities, including budget planning and control, cost
analysis, and posting adjustments. They can also use the busi-
ness package to execute these tasks in controlling.
Key Account Management Utilities Business Package
In the deregulated utilities market, increasing customer reten-
tion 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 effi-
cient. 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 Installa-
tions, has complained twice about incorrect dunning proce-
dures. 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 purchas-
ing 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. Smith’s
calendar. Shortly after this, Mr. Smith creates a new sales oppor-
tunity 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 Cool-
ing 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 main-
ly 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
1
Success Leads/
analysis Opportunities
9 2

Grid
operation
BUSINESS
Site visits/ PARTNER Acquisition/
Events 8 3 Contract renewal
INFORMATION

COMPETITOR
INFORMATION

ACTIVITIES
Back office MANAGEMENT
7
Contract
monitoring 4
Offer
creation

6 5
Call center Contract Controlling
Contract
conclusion/
status
Loss analysis

Figure 82: The Sales Process for a Key Account Manager

148
opment of sales revenue and energy consumption. There are
two different ways of viewing the business partner informa-
tion 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 analy-
ses 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 installa-
tion-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 doc-
uments
• 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 loca-
tions, 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 installa-
tions, 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 run-
time.
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 process-
es, SAP offers tailor-made solutions, including one for the utili-
ties industry. When you choose mySAP Utilities, you’ve select-
ed 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 manage-
ment, business support, sales and marketing, work manage-
ment, energy data management, billing, invoicing, and contract
accounting, intercompany data exchange, and customer rela-
tionship management.
This integrated solution covers all processes relating to genera-
tion, transmission, distribution, and sales for every division.
When it comes to energy data management and intercompany
data exchange SAP is one of the trendsetters.
With mySAP Utilities, you get the flexibility, scalability, and
integration necessary for true collaboration that reduces costs,
streamlines processes, and drives growth. mySAP Utilities deliv-
ers key information when and where it's needed, enhancing
customer satisfaction while boosting employee productivity
and partner efficiencies. That’s why more then 800 customers
around the world, operating in both regulated and deregulated
markets trust mySAP Utilities.
Deregulation Experience
mySAP Utilities is designed to fully meet the requirements of
the deregulated market. Whether your company is in genera-
tion, transmission, and distribution – or whether you sell elec-
tricity, water, gas, or district heating, mySAP Utilities supports
all your business processes.
Scalability
SAP solutions are scalable and can be implemented in any util-
ity 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.
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.
Integration
All mySAP Utilities components are closely integrated. Stan-
dard interfaces with external systems also guarantee a high
level of integration for all SAP solutions. Projects can be man-
aged significantly faster, while storing redundant data is avoid-
ed along with the expense of multiple maintenance. Efficiency
is increased, costs are lowered, and resources are used more
effectively.
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 invest-
ments.
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.
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/

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 configura-
tion 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 imple-
mentation of mySAP Utilities.

152
GLOSSARY
activity
A document used in activity management to record infor-
mation 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, pre-
paratory 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 receiv-
ables 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 process-
es. Process parameters are defined for the basic process that
help differentiate when implementing data exchange processes.
Example: From basic process “Export Profile Values” and pro-
cess parameter “Profile Allocation Role” you can define multi-
ple 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 determina-
tion 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 ser-
vice 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 determina-
tion of the tax determination ID, whereby the tax is deter-
mined 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 cus-
tomer 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 com-
pany 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, post-
ings (in contract accounts receivable and payable) are managed
using the gross procedure (that is, including tax) and trans-
ferred 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 out-
standing 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 defi-
nition, 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 (20°C, for example) and
the average outdoor temperature (Ta). The outdoor tempera-
ture 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 in-
stalled. 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 customer’s
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 prede-
fined 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 fac-
tors 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 stan-
dards. 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 Adminis-
tration, 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
extrapolation of profile values
Replacement value process in which profile values are deter-
mined using historical values. Extrapolated profiles can be
used as forecast values, for example.
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 installation
Technical and billing-related installation performed in one
step. The device is installed in a device location and allocated
to a premise.
full device removal
Billing-related and technical removal performed in one step.
gas billing
Determination of the valid conversion factors for gas, where
the operating volume is converted to standard volume.
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 indepen-
dent 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 Info-
Providers. 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 (attri-
butes, texts, and hierarchies). An InfoSource is always a quanti-
ty 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 installa-
tion 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 busi-
ness 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 compa-
nies 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 receiv-
able 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. Inter-
polated 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 automatic-
ally 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 reader’s 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 neces-
sary for analyzing or answering your questions. The data is dis-
played 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 charac-
teristics, and recalculating values, allows you to navigate flexi-
bly through the data during the runtime. In the SAP Business
Information Warehouse you can analyze the data in the follow-
ing 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 customer’s 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 extra-
polating 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 customer’s environment
have changed (for example, by converting the measuring
accuracy (register factor) of the meter during the extra-
polation period)
• The calculation of meter readings and budget billing
amounts to be extrapolated has been influenced (for exam-
ple, 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 back-
billing.
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
periodic replacement
Replacement of devices that must be replaced as required
by law or other rules.
pipeline
A form of analysis that displays potential sales revenue by pro-
viding 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 util-
ity 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)
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.
postal regional structure
A subdivision of a supply area according to cities, streets,
and street sections, or other structural criteria.
premise
Enclosed spatial unit which is supplied with energy, such as
an apartment or factory.
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 characteris-
tics are defined in the header data. The most important char-
acteristics are:
• Interval length
• Profile type
• Profile value category
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 con-
junction 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 cus-
tomer 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 electri-
city 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 applica-
tions and SAP and non-SAP applications, including Web appli-
cations. 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 communi-
cation platform and XML or HTML as the data format. It inte-
grates non-SAP products by using an open, non-proprietary
technology.
165
schedule record service type
Data record in which individual dates are managed, such as User-defined version of the service category predefined by SAP.
meter reading dates, billing dates, and budget billing amount You can allocate several service types to a service category.
due dates.
settlement
scheduled billing period Comparison of energy supplied and energy used carried out by
Planned billing period, in which billing is to be performed. the settlement coordinator. For example, the actual or forecast
The scheduled billing period is defined in scheduling. The consumption of all points of delivery in a settlement unit can
following periods can be defined in scheduling: be grouped together for settlement.
• Monthly
• Quarterly settlement period
• Annually, and so on Period during which settlement takes place.

scheduling settlement procedure

Planning and controlling of the following functions: Procedure used for balancing energy supplied and energy
• Meter reading order creation consumed that is carried out by settlement coordinator.
• Billing
• Determination of budget billing amount due dates settlement step
Smallest unit of a settlement procedure. Settlement steps
schema model settlement algorithms and consist of input and output
Structure that defines the sequence in which variant programs parameters, which can be profiles or values.
(calculation/processing steps) must be executed.
settlement type
service connection Key that refers to the business process in automatic settlement
Division-dependent interface between utility grid and connec- postings. It is used in the contract accounts receivable and
tion object. payable (FI-CA) component to determine the payment alloca-
tion or settlement rules.
service provider
Company that offers one or more of the following services settlement Unit
(service types): Virtual entity for which a settlement coordinator compares
• Energy generation energy used and energy supplied. A settlement unit contains
• Energy sales the points of delivery that are to be settled as a group.
• Energy supply
• Energy transmission
• Energy distribution
• Meter installation and maintenance
• Meter reading
A service provider is uniquely allocated to a service type.

166
settlement variant
Key under which the rules for automatically allocating open
items for clearing are defined.
sole provider
Service provider that, from the customer’s perspective, is solely
responsible for all services, and is the owner of the all receiv-
ables 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 customer’s 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 peri-
ods (day and season groups) and corresponding day and annu-
al profiles. Synthetic profiles are used for classifying customers
or customer groups.
technical device installation
Physical installation of a device in a device location. Relation-
ships 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 com-
ponent. If you do not wish to create this unit (for example,
a flat-rate installation) as a device, you can create it as a tech-
nical installation for the plant maintenance and service man-
agement 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.
time slice
Time interval within which a specified object was not changed.
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 busi-
ness 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
usage factor
Consumption of an installation in relation to a synthetic pro-
file. 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.
UTILMD
EDIFACT message category used for transferring master data
on customers, contracts, and points of delivery.
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 result-
ing 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
Neurottstraße 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.