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.

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.

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.

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

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

What Must a Customer Information System Do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 mySAP Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Basic Functions and Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Postal Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Political Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Company Regional Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enterprise Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Portioning and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contract Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utility Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Premise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utility Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point of Delivery (POD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 20 20 20 21 21 21 22 23 24 25 26 26 28 29 29 30 30 32

mySAP Customer Relationship Management for the Utilities Industry. . . . . . . . . . . . . . Functional Scope of mySAP CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supporting the Customer Relationship Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronization of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interaction Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration of mySAP CRM in mySAP Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronization of Data Between mySAP CRM and mySAP Utilities . . . . . . . . . . . . . . . . . . . . . Master Data Generator Automatic Creation of and Changes to Master Data . . . . . . . . . . . . . All Data at a Glance: The Cross-System Customer Fact Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrated Scenarios from mySAP CRM, mySAP Utilities, and SAP BW . . . . . . . . . . . . . . . . . . . From Potential Non-Residential Customer to Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From Potential Chain/Outline Contract Customer to Enrollment . . . . . . . . . . . . . . . . . . . . . . . From Phone Call to Changes in Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical Front Office Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Move-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Move-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Partner Move-In/Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change Bank Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change Budget Billing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change Installment Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bill Reprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAP Business Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bill Complaint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lay a Service Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disconnection/Reconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33 33 33 34 37 37 40 40 42 43 44 44 45 46 46 46 47 47 48 48 48 48 49 49 49 50 50

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

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

51 51 52 52 53 55

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

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

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

71 72 72 73 74 77 77 77 78 78 78 78 78 79 79 79 79 81 81 81 81 81 81 82 82 82

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

82 82 83 83 83 83 84

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

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

Contract Accounts Receivable and Payable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Account Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enhancement Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workflow Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95 95 95 96 96 96 96 98 98

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

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

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

10

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

11

12

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

readings, and so on. To exchange information, the customer information systems of the various companies must communicate with each other, often through an industry-specific, virtual marketplace. For example, this type of collaboration is used to manage notifications sent by a distributor regarding customers that have switched to another supplier. Another example might be transferring meter-reading results from the distributor to the supplier, or to another service provider, so that a consolidated bill for the customer can be created. Naturally, the huge number of transactions that are received by customer information systems must be processed as quickly as possible without any manual intervention a requirement that until now could not be met by many systems. Just as challenging, is the fact that the utilities industry has no common definition of market deregulation. In every country, the term has a different meaning. This results from differences in the infrastructure of each countrys utility system, the property relationships in the local utilities industry, government contracts, or the local population. The following examples show how differently utility markets can be deregulated, as well as what consequences deregulation can have for customer information systems. The deregulation models of the different countries have these two features in common. First, the distributor is responsible for operating the grid as far as the service connection. Second, only the supplier is able to conclude competitive contracts with customers for supplying energy.

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

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

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 customer, in addition to their existing grid usage contract, concludes a second contract for getting energy through the supplier. In the case of the single contract model, the customers contract with the distributor is cancelled and only the new energy supply contract with the supplier remains. Deregulation rules in the various countries differ greatly on the subject of enrollment. For example, who informs whom about enrollments and the requirements that have to be met before a customer and supplier can do business. There are substantial differences over enrollment and meter reading deadlines, as well as the treatment of customers in arrears, irregular enrollment, or the transfer of data from distributors to suppliers. Deregulation requires utility companies to develop a completely new form of service mentality, in which the customer is the center of attention. Furthermore, utility companies must optimize their energy sources and external services to stay profitable. These realities make effective customer and cost management a core requirement for an integrated IT system landscape.

14

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

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

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

15

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

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

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

16

mySAP UTILITIES
mySAP Utilities is an industry solution developed to meet the requirements of gas, water, and electricity companies of all sizes. mySAP Utilities is based on the functions of the mySAP.com e-business platform. E-business solutions are frequently stand-alone, Web-based applications that access information from a limited number of data sources. All too often, these solutions lack interfaces to the other information sources within your company. Only an integrated e-business platform that links front- and back-end systems can take full advantage of the potential of e-business. mySAP.com fulfils these requirements. In general, e-business embraces all activities from internal to collaborative processes that involve external partners. mySAP.com components, such as SAP R/3, offers functions for internal processes and since its launch has proven its competence repeatedly. In a rapidly growing business environment however, companies must implement end-to-end processes using heterogeneous system landscapes. mySAP.com enables you to accept these challenges and pursue new strategies. Together with other SAP software components, such as mySAP Customer Relationship Management (mySAP CRM), mySAP Business Intelligence with SAP Business Information Warehouse (SAP BW), or SAP Advanced Planner & Optimizer (SAP APO), SAP R/3 is the technical foundation of the mySAP.com e-business platform. With the aid of this platform, you can build and manage end-to-end business processes. The development of SAP R/3 and other software components evolving to mySAP.com reflects the wide-reaching adaptability and flexibility of mySAP.com technology. When combined with the power of the Internet, mySAP.com enables you to model collaborative business processes. All this makes mySAP.com a complete e-business platform. Customers may wish to implement mySAP.com at their own speed, or may initially only require part of an integrated solution. Therefore, the component-based architecture of mySAP.com offers the flexibility that companies need to implement solutions based on their internal structure and individual requirements, while retaining the option of seamlessly integrating additional solutions in their existing IT landscape later. The mySAP.com e-business platform consists of the following three key functional areas: Cross-industry solutions These solutions cover all the requirements of the respective business area and, with the help of e-business solutions, give companies a competitive edge. Industry solutions These solutions provide special functions that are oriented towards the requirements of a specific industry or branch of industry.

17

Discrete Industries

Process Industries

Consumer Industries

Service Industries

Financial Services

Public Services

mySAP CRM mySAP Financials mySAP E-Procurement SOLUTIONS mySAP SCM mySAP PLM mySAP BI mySAP HR

SAP WP SAPKW SAP BW

SAP APO

SAP Mobile

SAP SEM SAP BC ... SAP IS-U SAP R/3

External TECHNICAL COMPONENTS

SAP ...

SAP ... SAP GUI ILOG

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

Figure 1: mySAP.com Solutions

Infrastructure and services

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

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

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 High Tech

mySAP Utilities

mySAP Automotive

Cross-Industry Solutions mySAP Enterprise Portal mySAP CRM mySAP SCM mySAP BI mySAP Marketplace mySAP SRM mySAP PLM mySAP HR mySAP Financials mySAP Mobile Business

mySAP E&C

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

mySAP Business Intelligence for Utilities Monitor your utility with dedicated key performance indicators Make strategic decisions based upon relevant information

mySAP PLM (ASSET AND WORK MANAGEMENT) Monitor your assets to ensure cost-efficient operation of all kinds of assets and facilities Ensure highest efficiency for your maintenance staff and proactive service for your customers by best-in-class work management solution

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

Figure 2: mySAP Utilities

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

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

19

BASIC FUNCTIONS AND MASTER DATA

BASIC FUNCTIONS

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

an address. In Germany, the postal code can often be determined directly from the city name. Data relevant to billing can be stored for each street. This might include air pressure areas, calorific value districts, meter reading units, and grids. These values are automatically proposed when creating utility installations to be billed. A CD containing the postal data of customers outside the service territory can be applied to the postal regional structure if required. Political Regional Structure The political regional structure divides the supply territory by political and administrative criteria. Unlike the postal regional structure, you can define the political regional structure yourself. First, you define the hierarchy (for example state, county, and city) and then you allocate the elements, meaning the

Postal City

Internal Administrative area

Administrative district

County

Street

Dsitrict office

Municipality

District

Street section

Branch office

Figure 3: Relationship Between the Different Regional Structures

20

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

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

21

Role Task

Responsibilities

Belongs to an object or process (for example, device installation) Shipped by SAP

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

Organizational structure with: Organizational units Positions Users

Agents or agent groups

Figure 4: Agent Determination

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

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

22

Portion A MR unit A.1 MR unit A.2 MR unit A.3 A

Portion B MR unit B.1 MR unit t B.2 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 record

Portion

MR unit 1 Ableseeinheit 1 Ableseeinheit 2 Ableseeinheit 2 Ableseeinheit 3

Permitted BB cycles BB scheduling

Billing dates Permissibility (cycles, divisions, billing classes)

Dates for meter reading and MR order creation MR forms Special features (MDE, permissibility, intervals, etc.)

BB scheduling via allocated parameter record

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

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

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

23

MASTER DATA

Master data is data in mySAP Utilities that remains unchanged over an extended period. It is divided into business and technical master data. The business master data consists of: Business partner Contract account Utility contracts

The technical master data consists of: Connection object Connection Premise Device location Utility installation Point of delivery (POD)

mySAP UTILITIES HOUSE

Connection object

Apartment 1 = premise

Hall Utilityinstallation 1: elect. meter Device location: corridor

Apartment 3

Contract 1: electricity

Apartment 2

Business partner

Contract account

Contract 2: gas

Utilityinstallation 2: gas meter Basement

Contract 3: water

Utilityinstallation 3: water meter

Device location: basement

Service connection: water Supply grid

Service connection: gas

Service connection: electricity

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 partners master data is stored just once in a central master record. This reduces the amount of maintenance required and prevents data inconsistency. mySAP Utilities uses the business partner in the following roles: Contract partner who has a contract with a utility company for delivery and purchase of utility services. A contract partner can be a residential customer, nonresidential customer, other utility company, service provider, local authority, property owner, or third party. Prospect who is the target of marketing or sales activities. (See also Chapter 3 mySAP Customer Relationship Management for the Utilities Industry). Contact person for a contract partner of the utility company Installer who is authorized by the utility company to install devices and is issued a license to do so General business partner that is stored for information purposes only and is neither a contract partner of the utility company nor a contact person or prospect In mySAP Utilities, business partners are classified according to the business partner categories natural person, group, and organization. You can store different information depending on the business partner category you choose. When you create or change a business partner, you can create a customer from the Sales and Distribution component. This customer can make use of services and maintenance. You can link business partners to one another using relationship categories. Examples include linking an organization and contact person with the contact person relationship category, or the marriage and shared living arrangement relationship categories.

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

mySAP Customer Relationship Management for the Utilities Industry)

A predefined reference customer is used as a template

for the standard customer.

25

GENERAL DATA

DUNNING AND PAYMENT DATA

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

Dunning data Dunning control Dunning recipient Dunning disconnect reason

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

Contract account

Inbound payments Payment method Bank details Alternative payer

Acct assignment data Item line display Planning group Account determination

Outbound payments Payment method Bank details Alternative payer

Figure 8: Contract Account

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

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

26

GENERAL DATA

BILLING DATA

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

Billing data Joint invoice Billing block reason Outsorting group

Budget billing data BB amt adjustment BB cycle

Contract

Acct assignment data Account determination ID 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 companys generation and distribution installations Company consumption contracts (the utilitys own consumption) for example, for electricity consumption in the utility companys own offices

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

27

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

Notes to field service

Connection object

Characteristics Maintenance plant Authorization group Regional structure group

Figure 10: Connection Object

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

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

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 Maintenance component and does not have any industry-specific enhancements in mySAP Utilities. Premise A premise is an enclosed spatial unit (such as an apartment or factory) to which a utility service is supplied. Several utility

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

SUPPLY GRID Connection Equipment Configurable Connection info Back-up fuse Length etc.

Connection object Functional location

Service connection for gas Service connection for water Service connection for electricity

Figure 11: Connection

Location Connection object Street House number Floor Room number Location description

Premise

Characteristics Premise type Owner Number of persons Authorization group

Figure 12: Premise

29

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

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

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

Device location
General data Description Authorization group

Figure 13: Device Location

30

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

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

Point of delivery (deregulation)

Division Premise Current contract Current business partner

Individual facts

Time-dependent data

Utility installation

Billing and meter reading control

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 delivery ID is unique means that misunderstandings can be avoided and data correctly allocated when information about the services supplied to a POD is provided. This is also the case if a customer switches utility companies. There are two communication types: Communication in the deregulated energy market is communication between different utility companies in the deregulated energy market. This can include the exchange of information between a distributor and a supplier. Technical communication is communication with an automated meter reading system. This type of communication is used to import profile values to the Energy Data Management component.

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

Contract = billable service

Nonbillable service

Nonbillable service

Deregulation point of delivery Installation

Point of delivery

Technical point of delivery

Premise

Device

Register

Connection object

Device location

Figure 15: Point of Delivery

32

mySAP CUSTOMER RELATIONSHIP MANAGEMENT FOR THE UTILITIES INDUSTRY

The Internet and other virtual communication portals enable even the smallest companies to compete in global markets. This trend, however, has also raised customers expectations, especially regarding service. All-encompassing, round-the-clock customer service and personalized products and services are now taken for granted. If dissatisfied, a customer can switch to the competition at the click of a mouse. Consequently, as a utility company, you must work with a modern, comprehensive customer relationship management (CRM) system that supports a variety of different contact channels. Customer service is not a tiresome obligation; it is a strategic necessity. A CRM solution must facilitate communication with your customers across all channels, including telephone, fax, e-mail, Internet, hand-held device, and personal consultation. Seamless integration with all front- and back-office applications, company business functions, and business partners is also essential. mySAP Customer Relationship Management (mySAP CRM) can be used to win new customers in highly competitive markets and retain existing customers. Increasingly, companies are looking for integrated software that guarantees a universal, smooth, and efficient process, starting with customer interaction through to service provision, customer service, billing, payment request, and monitoring. Identical processes across all channels are required in both front-end and back-end systems to ensure that data is consistent. This enables you to handle customer-related business processes in the most effective and cost-efficient way possible. The ability to evaluate and analyze these processes with regard to quality and costs is also highly important. A data warehouse system that can collect and analyze data from financials, billing, and communication from all integrated systems is essential here. Using a data warehouse system in conjunction with the front-end, back-end, and financial systems enables you to develop and assess a suitable strategy for your company. You are able to continuously monitor costs, and thereby track the success of your interactions with customers.
FUNCTIONAL SCOPE OF mySAP CRM

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

33

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

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

34

mySAP CRM Customer Relationship Cycle Customer retention Complaints management Service-level management Customer retention management Customer development management Monitoring and success checks Contact management Market analysis Marketing planning Target group selection and campaign management Telemarketing Internet marketing Monitoring and success checks

SE RV

E IC

EN G
E AG

Figure 16: The mySAP CRM Customer Relationship Cycle

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

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

CT SA

FU L

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

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

TR

LL FI

AN

35

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

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

36

You can use SAP BW to analyze all the interactions that are conducted using mySAP CRM. You can use different criteria (for example, status, duration, costs) to analyze campaigns, complaints, orders and contracts, opportunities, and activities with regard to their success. mySAP CRM supports all forms of interaction between your company and customers, prospects, or partners. Since CRM solutions do not usually contain any billing functions, they must be smoothly integrated with backend solutions without any loss of performance. This is the only way of ensuring that the value-added chain flows across all systems, and that the data viewed is uniform and consistent. SAP provides a standard integration scenario between mySAP CRM and other SAP solutions. The information below describes the integration with mySAP Utilities and the business processes supported by this scenario. Synchronization of Data CRM middleware is part of mySAP CRM and supports the following functions: Synchronization of data on both sides of the integration scenario (mySAP CRM and mySAP Utilities) Synchronization of data between mobile clients and the central CRM system, in both directions Messaging between the client and server in which information about the CRM middleware is stored on a temporary basis 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 during 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 commonly known as the service interaction center, telesales, or telemarketing, depending on the area of implementation. In each case, the name refers to a specific modification of the IC, each of which has different functions. To work efficiently in the IC, you can arrange the components using three different basic layouts (see Figures 17-18). You can also create IC profiles, each of which contains different structures and modifications that meet the requirements of different employees. Consequently, a call center employee can work with those profiles and configurations that correspond to their tasks. This is especially important in mixed call centers, which require both sales and service functions. For example, a call center employee can be allocated an IC service profile and an IC sales profile that can be called as required.

Configuration

Service interaction center

Configuration Basis IC 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 following functions: Telephony functions Enable the agent to accept, transfer, and end calls Telephone status Automatically identifies and displays the telephone number of the customer calling (automatic number identification ANI). If the system knows the telephone number, it displays the business partner data of the customer in the data finder. A dialed number identification (DNI) function displays the number called by the customer. In this way, the employees are prepared for each situation, which is a real advantage in call centers.

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

Telephony function bar Data finder Action box

Navigation area

Work area

Figure 18: Sample Configuration for the Interaction Center

38

 Action box
Contains all the important transactions, which can be accessed via drop-down menus. The action box enables the employee to call SAP functions and execute Web-enabled transactions in the work area. This enables employees to enter customer inquiries, technical problems, and complaints efficiently, and use workflows to process them until a solution is reached. Work area Contains relevant data on the business partner (and the functions you have called) for viewing or processing (for example, if the address of the customer needs changing, the address data of that customer is displayed). The IC can be configured to allow transactions and data from mySAP Utilities to be called directly from the work area. External systems with Web-enabled transactions can also be integrated in the IC. 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 customers business partner number is also transferred, meaning that it does not have to be re-entered. Integration of mySAP CRM and mySAP Utilities enables the call center employee to view both systems. They can display and process data that is not found in mySAP CRM. All plausibility and consistency checks that take place with independent access to the back-end system are also performed here. Once the back-end transactions have been processed, the system saves the data in that system, making it unnecessary to store data in mySAP CRM. However, the contract log for the call is available in mySAP CRM. This provides a uniform view of the customer contacts (mySAP Utilities) and activities (mySAP CRM).

39

INTEGRATION OF mySAP CRM IN mySAP UTILITIES

System Landscape

ANALYSES

FRONT-END

SAP BW

Electronic business (Internet)

M Syste P CR m SA

Middleware

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

ITS/ WAS Telebusiness

CTI

mySAP Utilities

Mobile applications

BACK-END

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

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

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

40

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

data has to be synchronized between those systems. It is sufficient, for example, if all the prospects are in the front-end system and are not synchronized in the back-end system until they become real customers. This method keeps the volume of unnecessary data to a minimum. Physical separation of the systems. A prerequisite for qualitative analysis is a large variety of data from different sources that can be subjected to multidimensional analyses. This requires high data capacities and a high level of flexibility when carrying out analyses. Therefore, the most sensible option is to physically separate the analysis system from the other systems. Otherwise, you would either have to do without data from the other systems or suffer impaired system performance in other processes while analyses are running. Another reason for physically separating the systems is so that each system, complete with its respective functions, can be integrated into existing IT landscapes. However, be aware that running processes across all systems does not mean that each system must run on separate hardware. An ideal solution for small and midsize businesses is the industry-specific solution mySAP All-in-One. This solution is based on mySAP.com and tailored to the needs of companies with up to 2,000 employees. It integrates all the mySAP.com solutions on a single server. What role does each system play in the integration scenario? mySAP CRM is the front-end solution for interacting with customer, prospects, and partners. It contains all the functions needed for marketing, sales, and customer retention, and enables you to communicate with your customers via a number of different channels, for example: Web-based applications (Internet sales and Internet marketing) that are integrated in the CRM solution using modern and open Java technology

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 customer 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 mySAP CRM CHANNELS:

MASTER DATA GENERATED OR CHANGED IN mySAP UTILITIES

Fixed product information Internet

Customer (Susan Moore)

Call Center (Connie Johnson)

mySAP CRM product Family Energy Configuration

Master data template Family Energy Configuration

Master data generator

mySAP Utilities

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

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

43

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

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

44

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

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

45

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

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

46

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

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

47

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

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

48

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

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

49

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

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

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

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

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

50

ENERGY DATA MANAGEMENT

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

Manages all types of interval data, such as prices and temperatures Supports the creation and management of load profiles and load shapes Supports energy settlement procedures Enables direct billing based on interval data (real-time pricing and time of use)
DEVICE MANAGEMENT

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

Device category description Manufacturer & category

Register

Register group

Material number

Meter reading

Device category data Device number (serial no.) Device data

Figure 21: Data from Device Category and Device

51

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

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

52

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

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

53

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

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)

54

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

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

Device category A Sample lot

Device category B Periodic replacement year

Replacement orders for sample devices and spare sample devices

Replacement orders for all devices

Figure 22: Overview of the Certification Procedure

55

Create lot

Put together lot

Determine devices for lot

1st drawing

2nd drawing

Check sample devices

No Passed ?

Yes

Delete lot

Certify samples

Copy devices to periodic replacement list

Extend lot

Figure 23: Inspection using the Sample Lot Procedure

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

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

56

MR order creation

Billing order

MR order

Order display

MR documents MR results Entry Quick/individual entry

Download

Upload

Plausibility check

Correction Billing

Figure 24: Meter Reading

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

METER READING

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

57

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

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

MR unit A

City district 1

Street 1

Connection object 1 Street 2 Device location 1

Connection object 2 Street n

Device 1 Connection object n Device location 2

City district 2 Device location n

Device 2

City district n

Device n

Figure 25 Street Route

58

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

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 measurements. It can also be data created by load shape measurements in equidistant time intervals (time series) such as energy time series, demand time series, energy feeding time series, load time series (measured load shapes and analytical load profiles), schedules, or calculation results. You can also process time series that cannot be directly allocated to the energy flow. Price time series, conversion factors (for gas billing, for example), and weather data for load forecasts are all examples of this. These time series are called profiles.

Interval meter Residential customer meter Other market players

Internet Dialog AMRS MDE IDE

BAPI import interface Idoc interface PoD

ENERGY DATA REPOSITORY

Time slice (load shape)

Meter reading

ENERGY DATA REPOSITORY Data retrieval

Electronic data exchange

Data import

Consistency checks

Replacement value creation

Data evaluation and formatting

Archiving

Status management

Figure 26: Energy Data Repository

59

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

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

Enter

Manipulate

Correct

Check

Enter in SB

Implausible

Plausible

Bill

Follow-up

Figure 27: Validation

60

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

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

Meter reading

MR result

Expected consumption

Register

Period consumption

Expected consumption

Figure 28: Extrapolation

61

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

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

62

KW

50 Extrapolation

30

10

00:00 October 5, 2000

12:00

24:00 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 consumption manually.

63

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 replacement value processes. The following replacement value processes exist: Interpolation of profile values If you want to replace missing values from the past with replacement values, they must be interpolated.
64

Extrapolation of profile values

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

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

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

INPUT PARAMETERS

OUTPUT PARAMETERS 1,205 Profile for addition SUM 01 120 Add profiles (quantities) Total profile kWh Total load shape AB 15 min intervals Formula profile

1,200 Load shape of cust. A kWh 15 min intervals Historical profile

1,201 KEY Load shape of cust. B kWh 15 min intervals Formula Historical profile Profile allocation Formula allocation Unit Formula description Interval length Profile type Profile Calculation status

Figure 32: Formula Allocation

65

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

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

Figure 33: Graphical Profile Value Display 66

SETTLEMENT

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

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

SETTLEMENT WORKBENCH

Plans and controls settlement runs and creation of schedules

Settlement document Settlement log Settlement run

Settlement procedure

(e.g. synthetic, analytical)

Settlement mode

(Simulation, active)

SETTLEMENT PROCESS Input parameter Interim result Output parameter

Settlement step ...1

(e.g. determine total load shape)

Input parameter Interim result Output parameter

Settlement step ...2

(e.g. subtract interval customers)

Input parameter Interim result Output parameter

Settlement step ...n

(e.g. send results using IDE)

Figure 34: Settlement Workbench

67

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

by SAP can also be modeled in the system. You use an SAP business workflow or an executable program to combine individual settlement steps in such a way that you can execute the appropriate settlement procedure.

Figure 35: Settlement Document Figure 36: Workflow

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

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

and logging tools ensure that the status of the settlement procedure and the processes within it are as clearly structured as possible. The tools also provide extensive information concerning the data that has previously been sent to other market participants. Exception Handling Unsuccessfully or inadequately processed settlement steps (due to missing or incorrect input data, for example) can trigger exception handling in every settlement step. Exceptions (also called alerts) are issued either as warnings or as error messages. Warnings provide you with information. It may, however, be necessary for you to confirm the exception. Error messages, on the other hand, lead to termination of the settlement run. Each exception can have an individual response in the form of additional processing such as an e-mail notification to you, or an SAP business workflow. Settlement 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 system, you may have to allocate a point of delivery used for settling settlement unit A to settlement unit B in order to create schedules. Settlement views separate the distributor and supplier views so that, in every view, a point of delivery is always uniquely allocated to a settlement unit. You can then process and settle the individual settlement views completely independently from the others. Every settlement unit and every

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 distributors grid into several grids if, for example, the distribution grid covers transmission grids that belong to different transmission companies. During settlement, you handle each part of the distribution grid that lies within a transmission grid as a separate grid. This allows you to use settlement procedures that not only calculate the settlement results for each settlement unit but also for each grid.

69

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

Open system architecture

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

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

70

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

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 order creation

Meter reading order entry

Billing

Invoicing

Bill print

Billing order

Billing order

Billing document

Print document

Meter reading order

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

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

10 kW Month 01

15 kW Month 02

15 kW

10 kW

20 kW Month 03

20 kW

20 kW

2 * 15 kW

25 kW Month 04

25 kW

25 kW

25 kW

3 * 20 kW

Figure 38: Floating Backbilling over n Periods

.........

01

02

03

04

05

06

07

08

09

10

11

12

13

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 correction period so that the last three months are always corrected. You can also use the period-end billing function to execute calculations for several periodic billing periods (for example, monthly) by creating a period-end billing schema. You can, for example, use the total annual consumption to grant a scaled, quantity-based discount. Period-end billing and backbilling can be combined.

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

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

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 executed for actual meter reading results, and which are to be used for estimated meter reading results. You can also choose whether you want the whole correction period or just the individual partial correction periods to be corrected. Advance billing is also possible and can be backbilled. In dynamic period control, you can use a simulated period to generate extrapolated, posting-relevant billing lines, or informatory lines in the

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

KW 60

30

10

Block 1 Price A

Block 2 Price B

Block 3 Price C

Block 4 Price D

Block 5 Price E

Block 6 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 a measured load profile: Time-of-use billing Consumption measured in intervals is added together and evaluated. Real-time pricing Consumption measured in intervals is valuated with a price that is valid for each interval. The RTP interface provides you with flexible options for structuring rates for your non-residential and major customers. You can select several aspects, including:

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

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

Spot price KW 60

Measured load shape 30

10

00:00 Oct 5, 2000

12:00

24:00 t = 15 min Agreed Price Oct 6, 2000

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

Figure 42: Example for Real-Time Pricing

75

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

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

Meas. inputprofile kW/kWh Offpeak Onpeak Offpeak Onpeak Offpeak

Resultprofile Off-peak Consmp.

Virtual profile Offpeak Offpeak Offpeak

Result function

Result parameter

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

Resultprofile On-peak Consmp. Onpeak

Virtual profile Onpeak

Result function

On-Pk cons. kWh = 500

Figure 43: Example of How an RTP Interface Works

76

BILLING DIVISIONS

Contract billing enables you to bill different divisions in one contract account. The divisions are mapped at the contract level. In addition to the basic functions, you can also use division-specific functions.
Individual settings

Gas procedure

Individual settings Vol. correction factor procedure Fixed-volume correction factor Determined vol. correction factor Special procedure

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

Calorific value procedure

Determined calorific value Arithmetic average creation Weighted average

Figure 44: Gas Procedure

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

77

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

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

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

78

 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 individual billing procedures. In bonus calculation, all individual contracts are billed using a temporary, scaled discount that is based on an assumed total consumption. Once all contracts have been billed, any changes required are made to the temporary percentage scaled discount based on the actual total consumption. 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 companys 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 valuated. When defining a rate, you select the appropriate variant programs and specify the sequence in which they are to run. There are approximately 200 preset variant programs available, including: Valuate quantities or demand with a price Multiply or divide with factors Discounts on prices, consumption quantities, and amounts Flat-rate billing Rental price billing IF-, ELSE-, ENDIF conditions You can also create customized variant programs. Rates define the following: How meter reading results and consumption values are extrapolated and prorated Which prices are used Which reference values are billed Which constants, factors, and variables are included in the calculation

79

 The general ledger accounts to which the results of the calculations (billing line items) are posted How the billing line items are handled statistically

How the time portions of the periods to be billed are calculated (to the day or on a monthly basis) The divisions and billing classes to which the rate is allocated

Installation

Installation struct.

Rate type

Rate cat.

Rate type For example

Rate cat.

Rate

Rate determ.

Off-peak On-peak

Normal Normal

Rate 1 Rate 2

Operands Demands Prices ...

Rates VarProg

Operand values

Billing schema Rate 1 Step 1 Step 2 Rate 2 Step 1 Variant program For example, Quantity x Price Comp. 2 demands Operand values 1000kWh, 0,25$ 400kW, 300kW

Figure 45: Master Data in Contract Billing

80

Rate Categories Rate categories contain data that controls the billing of multiple rates. Rate categories can do the following: Define which billing schema is used Control period-end billing and floating backbilling Define the outsorting checks Define which data relevant to billing is used at rate category level (for example, quantities, demand values, prices, or flat-rates agreed upon between the utility company and customers) 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 individual contracts. All discounts and surcharges appear as separate billing line items in the document and can be displayed separately on the bill.
EXTRAPOLATION/STATISTICAL FUNCTIONS

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

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

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

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

82

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

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

83

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

SOLUTION BENEFITS

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

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

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

Billing documents

Billing documents Credit memos Backbillings Basis for budget billing plans

Invoicing Budget billing amounts Accounting documents FI-CA Budget billing requests Payment forms Bills

Open items

Printer

Figure 46: Invoicing Processes

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

85

BILL PREPARATION

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

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

Account determination

Tax/charge determination

Budget billing processing

Bill preparation

Invoicing Due date determination

Payment form reference

Determination of payment method

Final bill amount

Figure 47: Basic Invoicing Functions

86

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

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

CONTRACT ACCOUNT

BILLING

INVOICING

Contract 1 Mandatory contract

Document 1

Contract 2 Mandatory contract

No document exists yet

No document as Contract 2 is also a mandatory contract

Contract 3 Mandatory contract

Document 3

Contract 4 Optional contract

Document 4

Document A

Bill

Contract 5 Cannot contract

Document 5

Document B

Bill

Figure 48: Sample Grouping for the Invoicing Unit

87

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

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

Item selection

Account maintenance

Invoicing block Invoicing Due date adjustment

Clearing control

Interest calculation

Debit entries

Dunning

Figure 49: Additional Invoicing Functions

88

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 Clearing postings that result from account maintenance are posted to a separate posting document that represents part of the print document. The following contract accounts receivable and payable functions can also be executed: Interest can be calculated for open receivables and cash security deposits for the contract account. Open due items for the contract account can be dunned. Statistical items can be created as debit entries and cleared. Statistical items can also be cleared without subsequent postings.

The due date adjustment function can be used to inform the customer about other posting transactions and to obtain payment for these with the next bill. The due date in contract accounting documents that have been posted is synchronized with the due date for the bill during invoicing.
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

Flag old document

Reset due date adjustment

Flag old billing document

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

Create billing order

Reopen budget billing item

Open old budget billing plan

Reset clearing payments

Flag old document and create reversal document

Invoicing reversal

billing reversal

Budget billing request reversal

Figure 50: Reversal Functions

89

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

OK Settlement Not OK Release Invoicing Not OK

OK Bill printout

Release

Reversal

Reversal

Figure 51: Outsorting BUDGET BILLING AMOUNTS

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

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

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

90

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

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

91

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

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

92

COLLECTIVE BILL

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

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

SAMMLER INC. Document 4711 Business partner item 348.00

WINNIE CHUNG Document 471200 Business partner item 116.00

MARCUS ADAMS Document 471300 Business partner item 232.00

Stat.key.: S

CBP doc. 4711 General ledger item 100.00 16.00

CBP doc. 4711 General ledger item 200.00 32.00

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

Figure 52: Invoicing a Collective Bill

93

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

SOLUTION BENEFITS

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

94

CONTRACT ACCOUNTS RECEIVABLE AND PAYABLE

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

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

Document header

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

010000234591 02/22/2002 F1 USD TK2202200101 102345678

Reversal

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

102345678 03/05/2002 S1 USD TK05003200103 010000234591

Business partner items

Cleared items Date 02/25/2002 102345678 05 Amount 230,00 GPART 4711 BUKRS U100 Amount 230,00

GPART BUKRS 4711 U100 Clearing document: Clearing reason:

G/L and revenue account items

BUKRS U100 U100

G/L account 800000 175000

Amount 200,00 30,00

BUKRS U100 U100

G/L account 800000 175000

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

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

96

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

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

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

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

Doc. Nr. 0000815 0000816 0000817 0000818 0000819

Inv. Nr. 4709 4710 4711 4712 4713

Amount xx.xx xx.xx xx.xx xx.xx xx.xx

Division Consumption Amount Electricity xxxx xx.xx Water 4709 xx.xx Gas 4710 xx.xx

FI External billing system 3 Archive

Account 880000 175000

Amount xx.xx

mySAP Utilities-CA

Bill 4711

xx.xx

Doc. Nr. 0000815 0000816 0000817 0000818 0000819

Inv. Nr. 4709 4710 4711 4712 4713

Amount xx.xx xx.xx storno xx.xx xx.xx

1. Open items to external billing system 2. Post FI-CA document and if neccesary update CO-PA 3. ArchiveLink to archived bills 4. Mass reversal

Figure 54: Interfaces with External Billing Systems

97

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

BUSINESS PROCESSES

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

98

Payments Overview FI-CA supports all commonly used payment methods for incoming and outgoing payments in utility companies including any country-specific features. The system also provides various business processes for payments. These can be classified as follows: Automatic payment by the utility company This processing can be performed for all outgoing and incoming payments if the customer has granted the utility company the corresponding authority. Process incoming payments using lots The customer makes payments through the bank or post office. Cash desk and cash journal The customer makes payments at the utility company. Payment methods are available in the various payment processes as follows:
Payment is initiated by the utility company Collection or repayment using automatic payment Card payment Direct debit Debit memo Returned check Refund by bank transfer Postal order

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

Lot processing of incoming payments Incoming check Incoming bank transfer Card payment Decreasing level of automation

Payment via the cash desk Cash payment Incoming check Card payment Outgoing check Postal order

Table 1: Available Payment Methods

99

 The system supports automatic determination of the house

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

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

100

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

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

101

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

The system always executes entries in the clarification work list if the business transaction cannot be processed manually or manual processing is explicitly requested in a specific situation. Users responsible for clarification cases can be determined automatically using the organizational structure. You can also reserve a clarification case for a specific user meaning that it is blocked for processing by other users (this can be a time restriction). You can remove the block at any time. Clarification cases can also be transferred between users. Various actions are available in the system depending on the type of clarification case involved. Incoming payments to be clarified can be assigned to an open item in dialog, charged off, or flagged for repayment. The system also supports clarification of partial amounts. During clarification of the credit balance, you can transfer the amount that will be clarified to the business partner, flag this for follow-up, clear it, or repost it. Deferral and Installment Plan If a customer is unable to honor his or her financial commitments, you can make a deferral or installment plan agreement for one or more receivables. The number, amount, and due dates for installments are defined in an installment plan. During dunning and the payment run, the individual installments are recognized instead of the original receivable. An installment plan can be deactivated if necessary so that the original receivable is re-entered in payment and the dunning run. 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.

102

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

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

System configuration

Control parameter

Amount limits, Days in arrears, Dunning interval

Fee schema Print formulas

Business partner

Contract account Determine new dunning levels Open items Generate dunning proposals Generate dunning activities Post interest and fees

Dunning history

Figure 55: Overview of Dunning

103

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

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

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

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

105

Service provider (SP)

Billing party (BP) Dunning End customer A

End customer A (1) 600 600 (2)

End customer B (1) 400 400 (2)

End customer A (3) 600 (4) 100

End customer B (3) 400 (4) 100

Payment

Bill Rechnung Bill

Revenues 1000 (1)

Receivables SP (2) 1000 Dunning Payment

Payable. SP 1000 (3)

Revenues 200 (4) Dunning Payment End customer B

(1) Service for end customer A, B (2) Submit receivables to billing party

(3) Carry over receivables from SP (4) Additional service for end customers A, B

Figure 56: Deregulation Advance Payment

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

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

106

Service provider (SP)

Billing party (BP) End customer A

End customer A (1) 600 600 (2)

End customer B (1) 400 400 (2)

End customer A (3) 600 (4) 100 700 (5)

End customer B (3) 400 (4) 100 Bill

Revenues 1000 (1)

Receivables SP (2) 1000 600 (7)

Payable. SP (6) 600 1000 (3)

Revenues 200 (4) Rechnung Bill

Bank (7) 600

Bank (5) 700 600 (6) End customer B

(1) Service for end customer A, B (2) Submit receivables to billing party (7) Incoming payments from SP due to payment by customer A

(3) Carry over receivables from service provider (4) Additional service for end customers A, B (5) Customer A pays (6) Payment is transferred to SP

Dunning from customer B through service provider

Figure 57: Deregulation Customer Payment

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

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

107

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

Tax returns for tax on sales/purchases

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

108

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 system. This improves performance and reduces document volumes in the general ledger. The reconciliation key connects the general ledger within the subledger. It is used to itemize amounts posted to the general ledger and perform reconciliation between FI-CA and the general ledger.

FI-CA DOCUMENTS

TOTALS RECORDS

FI DOCUMENTS

Document Reconciliation key Posting date Company code Partner Amount Revenue account

10004711 TK980410 04.10.2002 U100 99000123 200.00 800003

Document Reconciliation key Posting date Company code Partner Amount Revenue account

10004712 TK980410 04.10.2002 U100 99000114 200.00 800003

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

TK980410 04.10.2002 140101 800003 04.11.2002 140101 800004

Document Reference key Posting date 40 140101 50 800003

120001234 TK980410 04.10.2002 500,00 500,00

Document Reference key Posting date 40 140101 50 800003

120001234 TK980410 04.10.2002 500,00 500,00

Document Reconciliation key Posting date Company code Partner Amount Revenue account

10004713 TK980410 04.11.2002 U100 99000129 200.00 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 valuation are to be posted, are determined and posted to by the system automatically. Receivables adjustment This is used to mark receivables as being doubtful and to correct individual receivables values. It brings receivables in accounting into line with the estimated receivables value. Receivables can be marked as doubtful if the business partner may no longer be able to settle them. The receivable that has been marked as doubtful is separated from other receivables by making a posting to a separate receivables account. By adjusting individual values, the value of each receivable can be adjusted to any percentage rate. Adjusting individual values triggers a posting to an expense account. The system automatically posts any tax corrections. Adjusting a single value is always based on a receivable that has been marked as doubtful. However, a receivable can be marked as doubtful without adjusting a single value. Marking receivables as doubtful and adjusting single values can be automated (based on the age of the receivable). If adjusting a receivable triggers a payment, the system performs all correction postings that this requires. Reclassification Reclassification displays vendors with a debit balance, receivables, and payables according to their remaining term.

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

110

Figure 59: Account Balance Display

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

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

111

INTEGRATION WITH ADDITIONAL COMPONENTS

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

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

Asynchronous posting FI CO

Invoicing

FI-CA

Synchronous posting

Cash Management

Figure 60: Integration with the General Ledger, Controlling, and Cash Management

112

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

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

113

INTERCOMPANY DATA EXCHANGE

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

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

Default value

Regional structure

Service provider

Business partner

Service Non-billable

Contract account

Distributor

Service cat. Distribution

Contract Billable service

Deregulated Grid Point of delivery Technical Register Device Installation Premise

Connection object

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. Grid A grid is an object in mySAP Utilities that corresponds to a distributors distribution grid, or part of it. You can manage grids for a distributor. A distribution grid can be divided into several grids for the following reasons: To record grid hierarchies You can record grid hierarchies in the system by specifying higher- or lower-level grids. These hierarchies can be evaluated when overall schedules are created for different grids. If a distribution grid covers several control areas If these control areas are managed by different control area operators, you must manage each part of the distribution grid that is located in a control area as a separate grid in the

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

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

Grid hierarchy

Grid

005 002

001 004 003 Regional structure

006

NetCo Distributor

Figure 62: Grid Hierarchy

Control area operator

Control area operator

Regional supplier

Regional supplier

Municipal utility company Stadtwerk Grid 1 Municipal utility Grid 2 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,

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

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

Service provider

Business partner

Service Nonbillable

Contract Billable service

Contract account

Point of delivery

Installation

Figure 64: Services

Business partner Contract account Billing category Service provider Data exchange definition

Vendor

G/L account

Installation

Non-billable service Contract

Grid

Figure 65: Service Provider

116

SUPPLY SCENARIO FOR A POINT OF DELIVERY AND PROCESS CONTROL IN A DEREGULATED ENVIRONMENT

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

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

117

PROCESSING DATA EXCHANGE PROCESSES

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

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

118

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

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

119

SAP System

AP

BU TO EC SINE SS CONN

XML SAP BC SAP System

INTE R NET T E CHNOLOGY

HTML WEB BROWSER

XML HTML/ XML XML XML WEB CONTENT DERVER

XML Interface NON-SAP SYSTEMS

B2B Server WEB APPLICATIONS

BC

NON-SAP SYSTEMS

IDoc

AMR

BAPI mySAP Utilities, EDM, IDE BOR FI WF CO ...

Figure 66: Data Exchange Architecture

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

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

120

SOLUTION BENEFITS

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 available to you for countries in which IDE has already been localized. Mass data capability Companies of all sizes can work effectively with IDE. The solution is specially optimized for processing mass data.

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

121

ASSET AND WORK MANAGEMENT

Although there are fewer financial resources available in the liberalized market for upgrading and maintaining technical installations, utility companies must still guarantee the availability and supply of energy. Resources must, therefore, be used more efficiently a prerequisite that requires new concepts in asset management. Energy supply alone, however, is no longer enough to satisfy customers. Customers now demand attractive and reliable services at the right price. In order to react quickly to customer demands, as well as schedule employees more effectively, the organization of work management must also be considerably improved. Through its asset and work management capabilities, mySAP Utilities enables you to implement new methods in asset management as well as improve customer service. In this way, mySAP Utilities supports energy producers, distributors, and service companies.

CUSTOMER

Customercentric

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

Work management

Meter services

ASSET MANAGEMENT Description and structure of technical installations Energy supplier

Generator Preventative maintenance Maintenance cycle Work clearance management

Distributor

Assetcentric

Work management

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

122

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

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

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

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

123

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

WORK CLEARANCE MANAGEMENT AND SAFETY AT WORK

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

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

124

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

A DETAILED LOOK AT UTILITIES-SPECIFIC FUNCTIONS IN ASSET AND WORK MANAGEMENT

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

Used in connection with other systems, mySAP Utilities asset and work management functionality covers not only the complete life cycle of installations, but also technical objects and customer service. Network information systems, geographical information systems, and SCADA systems all play an important role in work management, as do systems designed to improve grids, analyze outages, and schedule work. Individual solutions, however, are not the answer: Many processes can only be used fully when they are integrated with other software systems. This is why mySAP Utilities is designed to be integrated with so many different systems. Systems are not only integrated on a technical level, however. Employees can work more efficiently if information and functions from different systems are displayed in one interface. Web-based portal solutions, such as the Enterprise Portal for Assets, are particularly suited for this kind of visual integration. The portal groups together all the functions an employee needs for his or her work from maintenance orders and technical data on the installation, to maps of the network information system and information about customers.

125

Distribution station

Electricity pylon

Line

Transformer fields

Transformers

Functional locations Equipment Object links

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

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

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 Object link Connection 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 subordinate. The devices are classified as equipment that is installed in the device location. You can allocate technical installations to individual apartments (the premises) and in doing so enter technical data. In Figure 69, the system determines technical data from the lines leading to the individual houses. Technical installations are also classified as equipment.

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

127

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

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

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

Technical object

Instructions

Sales order

Service order

Service Product

Service material

Maintenance or service order

Sales view Price information

Configuration

Characteristics Values Dependencies

Figure 70: The Concept of the Service Product

128

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

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

129

You also define relationships that affect the instructions and price. For example: Planned time, in hours, for the excavation = Length in meters x 0.5 Secure excavation if surface is light Give customer discount for own contribution

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

Service product: Create service connection

SERVICE MATERIAL

CONFIGURATION

INSTRUCTION

Cable per m Excavator per m Connection box Type A Type B Discount for customer contribution

60.00 150.00

Character Surface cat.: Length:

Values Light 10m A

1. Dig trench Time: 0.5h per m Tools: Excavator 2. Secure trench only for light soil

1200.00 1500.00 Connection type: Customer contribution: 300.00 Yes

3. Lay cable Material: X m cable 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 reconnection can be dependent on the reason for a disconnection. Different service orders are created for disconnections due to dunning, disconnections at the request of a customer, or disconnections due to technical reasons. Device replacement Devices must be replaced for certification. You can create service orders for devices from sample lots and for devices from the periodic replacement list. Inspection You use inspections to check periodic equipment or technical installations. Service orders are created for periodic checks based on service objects. Alternatively, you can create service notifications. In Switzerland, for example, inspections are needed for legally required home installation checks. The date of the last inspection is saved for every technical object. You can also define the intervals at which the object is to be inspected. This produces the date of the next inspection. The inspection lists are used to plan inspections. Work orders or service notifications are based on these inspection lists and on different criteria (for example, for a particular city

or street). In addition to the periodic inspections, there are also aperiodic inspections. These are divided into two groups: Initial inspections These are executed for new technical objects. Advanced inspections In this instance, the next periodic inspection is moved forward. An advanced inspection can be either planned or unplanned (for example, a service technician decides on site to inspect a technical object without a planned order). SAP provides predefined front office processes for periodic and aperiodic inspections. In addition to creating orders in these processes, you can also use service objects, service projects, and service notifications to create work orders in the following ways: In a front office process in the interaction center Here are examples: A service order for repairing a device if a customer complains about a defective device A service order for installing a device when a new connection object is created Within a workflow The workflow service connection with quotation is used as an example later in this chapter. In the hierarchy structure of functional locations and equipment In the structural display, you can use service objects to create maintenance orders for individual objects of a supply grid. By creating a sales order with a service product Service objects and notification profiles for the processes described here are already predefined in mySAP Utilities. You can also easily define further service objects, service products, and notification profiles.

131

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

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

132

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

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

MDI Mobile Devices Confirmation of service orders GBC mySAP Utilities asset and work management capabilities Confirmation of service orders CADS

Breakdown reports and orders Status monitoring Geo data OMS SCADA Distribution station breakdowns Connection information

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

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

GIS GIS Business Connector

SAP

Methods

SAP applications

GIS application

Middleware

Methods

Enhanced GIS application Business objects Business objects

Enhanced SAP application

Figure 73: The GIS Business Connector

134

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

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

135

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

SOLUTION BENEFITS

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

136

mySAP BUSINESS INTELLIGENCE FOR THE UTILITIES INDUSTRY

SAP Business Information Warehouse (SAP BW) is the tried and tested data warehouse solution in mySAP Business Intelligence (mySAP BI). Within the framework of mySAP Utilities, SAP BW distinguishes itself through its predefined report and analysis scenarios for the utilities industry, and through its ability to format mass data efficiently in terabytes. These extensive reports and evaluations can be tailored to individual roles in a company, and can be linked together using analytical applications. This provides new insights into company processes as well as a strong starting point for business processes and closer customer relations. Utilities companies use SAP BW to tailor their processes and products more towards the demands of their customers. By using industry-specific reports and analysis scenarios (Business Content), as well as analytical applications, you can secure existing markets and develop new potential for growth. The utilities industry is undergoing far-reaching changes. Deregulation and liberalization are defining both the international and competitive landscape. At the same time, private and non-residential customers are becoming increasingly sensitive with regard to prices and services. Business processes must be extensively analyzed to ensure that complex processes including the generation, transport, sale, and resale of electricity can be valuated whenever necessary. This means that enormous amounts of data from internal applications and external sources must be processed and analyzed. Consequently, effective measures for increased flexible company control and more efficient processes can only be derived from clearly structured data. mySAP Utilities is a powerful business solution for the utilities industry that can be ideally combined with SAP BW. The extensive business content of the data warehouse solution

I have to increase the profitability in my region. When is break even reached for several customers? Which customers cant be supported profitably? Where can I increase my business? Which campaign was successful?

Sales Delivery Marketing costs

Profitability Human resources Sales/service costs Quality

Market share Market potential Customer satisfaction

SAP R/3

NonSAP

mySAP Utilities

mySAP CRM

Provider

File

Figure 74: Questions Asked and Demands Made by a Company

137

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

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

SAP BW also contains enhanced Business Content based on mySAP Utilities. This is used for stock, transaction, sales and consumption statistics, as well as master data objects from mySAP Utilities such as contracts, contract accounts, and con-

mySAP Enterprise Portal

Campaign target group Segment Builder

mySAP CRM

mySAP BI

Orders, Activities, Opportunities, Contracts

Contract creation and changes, Service orders

Sales revenue, Consumption data, Master data

Stocks and transactions, costs, contacts

Opportunities, Family tree

mySAP Utilities

Figure 75: Example of Campaign Management

138

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

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

Figure 76: Overview of Stock: Customers and Contracts

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

139

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

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

140

 Single invoicing transaction statistics

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

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

Figure 77: Sales Statistics According to Division

141

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

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

142

ANALYSES OF CONTRACT ACCOUNTS RECEIVABLE AND PAYABLE (FI-CA)

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

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

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

Enterprise Portal Web Content Management

Collaborate

Decide

E-Analytics

CRM Analytics

SCM Analytics

Financial Analytics

HR Analytics

PLM Analytics

Custom-Built Analytics

Structured Data & Content Analyze Adjust

Customer Relationship Management Unstructured Information & Content

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

Financials

E-Commerce

Supply Chain Management

Human Capital Management

Product Life-Cycle Management

Figure 78: Analytical Applications

143

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

Figure 79: Customer Lifetime Value

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

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

144

mySAP ENTERPRISE PORTAL FOR THE UTILITIES INDUSTRY

Portals provide you with a central and personalized point of access to the data that you need to do your job regardless of whether the information comes from an application, a database, documents, or the Internet. mySAP Enterprise Portal provides companies with a platform that increases the speed of internal and cross-company processes. System boundaries are no longer visible. You are presented with a user interface that unites all systems. Single-sign-on technology means that you only have to log on to the portal once and can then access all connected systems. All you need is a user name and a password. The following types of iViews exist: Access to applications These iViews enable you to access SAP applications and non-SAP systems directly, for example, a Web-compatible geographic information system (GIS). SAP offers a wide range of preconfigured iViews that are tailored towards users and their roles in a company, for example, displaying business partner information or creating a maintenance report. Business intelligence These iViews display all relevant analyses, statistics, and reports at a glance and also as graphics. This improves both the decision-making process and the quality of the information that forms the basis of your decisions. For example, a key account manager is informed that several customers contracts are about to expire. In the past, he or she might have overlooked this. Now, they can arrange appointments with these customers to renew their contracts or discuss changes to prices or conditions. Knowledge management These iViews are an extensive solution for the integration and management of unstructured documents. You can use knowledge management to obtain all kinds of documents relevant for your work, regardless of the system in which the documents are located. Search and classification functions allow you to quickly access relevant information and structure company-specific taxonomies. An integrated content management system manages the complete life cycle of the documents. If there are new documents, the registered users are informed of this through an alarm function. Special collaboration services allow experts to work together, regardless of where they are and what time it is.

mySAP Utilities Intranet

SAP CRM SAP BW

Shop Internet

Groupware ...

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.

145

 Internet content and services

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

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

Original source

Access to applications

Internet content and services

Enterprise Portals

Business intelligence

Knowledge management

Extracted and formatted information

Figure 81: Types of iViews

146

Unstructured

Structured

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

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

147

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

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

Marketing Success analysis 9

Sales planning 1 Leads/ Opportunities 2

Management

Grid operation Site visits/ Events 8 BUSINESS PARTNER INFORMATION COMPETITOR INFORMATION Back office Contract monitoring ACTIVITIES MANAGEMENT 4 Offer creation 3 Acquisition/ Contract renewal

Call center

6 Contract status

Contract conclusion/ Loss analysis

Controlling

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 information through an overview: Overview of all business partners The following information is included in this overview: A list of the most important customers The top n customers according to sales revenue Future activities List of expiring contracts New sales opportunities (leads/opportunities) in each area of responsibility Overview of one business partner The following information is included in this overview: Overview of addresses Overview of groups, structure, chain store, or outline contract customers List of business agreements List of contracts List of contracts expiring in the near future Overview of contract details Overview of consumption history Load profile display Overview of premise details Overview of executed and planned activities/contacts (telephone, visit, mailing, letter) Overview of past and future sales opportunities (leads/opportunities) There are also two views available for reporting and analyses: Overview of all business partners This overview contains, amongst others, the following analyses that include all the business partners for which the key account manager is responsible: Who are the top n business partners according to sales revenue or consumption? Which business partners have considerably increased or decreased their sales revenue or consumption compared to the previous year?

Overview of one business partner

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

149

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

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

150

SUMMARY
Industry Experience With almost 30 years of experience modeling business processes, SAP offers tailor-made solutions, including one for the utilities industry. When you choose mySAP Utilities, youve selected a solution from one of the largest independent software companies in the world SAP. More than 18,000 companies in over 120 countries have already turned to SAP and with good reason. As an integrated, Internet-enabled e-business solution, mySAP Utilities optimizes processes such as enterprise management, business support, sales and marketing, work management, energy data management, billing, invoicing, and contract accounting, intercompany data exchange, and customer relationship management. This integrated solution covers all processes relating to generation, transmission, distribution, and sales for every division. When it comes to energy data management and intercompany data exchange SAP is one of the trendsetters. With mySAP Utilities, you get the flexibility, scalability, and integration necessary for true collaboration that reduces costs, streamlines processes, and drives growth. mySAP Utilities delivers key information when and where it's needed, enhancing customer satisfaction while boosting employee productivity and partner efficiencies. Thats why more then 800 customers around the world, operating in both regulated and deregulated markets trust mySAP Utilities. Deregulation Experience mySAP Utilities is designed to fully meet the requirements of the deregulated market. Whether your company is in generation, transmission, and distribution or whether you sell electricity, water, gas, or district heating, mySAP Utilities supports all your business processes. Scalability SAP solutions are scalable and can be implemented in any utility company. Companies using mySAP Utilities bill from 1,000 to 20 million contracts with their customers. This proves that mySAP Utilities grows with your company and is flexible to changing market conditions. 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. Standard interfaces with external systems also guarantee a high level of integration for all SAP solutions. Projects can be managed significantly faster, while storing redundant data is avoided along with the expense of multiple maintenance. Efficiency is increased, costs are lowered, and resources are used more effectively.

151

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

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/

152

GLOSSARY
activity A document used in activity management to record information resulting from interaction between business partners, undertaken at any time during the customer relationship life cycle. Activities are subdivided into business activities and tasks. Examples of activities are telephone calls, customer visits, preparatory tasks, or private reminders. advance payment (contract accounting) Budget billing amount specified in the budget billing plan. It is paid before the utility company has rendered services. advance payment (intercompany data exchange) Procedure by which the billing agent pays the outstanding receivables to the service provider, even if the customer has not yet paid these receivables to the billing agent. Once the receivables have been invoiced in mySAP Utilities, they belong to the billing agent. AMB procedure Abbreviation for the average monthly billing procedure. This is a payment plan category, where the current payment plan amount is always determined. annual profile Elementary profile that is valid for a year. basic process Process used to define data exchange processes. Various data exchange processes can be implemented based on basic processes. Process parameters are defined for the basic process that help differentiate when implementing data exchange processes. Example: From basic process Export Profile Values and process parameter Profile Allocation Role you can define multiple data exchange processes: Export measured load shapes to supplier Export settlement results to settlement coordinator Export schedules to settlement coordinator Export settlement results to supplier BBP procedure Abbreviation for budget billing plan procedure. This is a payment plan category, where the payment plan amount is charged equally over the whole validity period. best-rate billing Determination of the most favorable rate for the customer using several alternatives. BEx Abbreviation of Business Explorer, the analytical and reporting tool in the SAP Business Information Warehouse. The Business Explorer (BEx) consists of the following areas: Query design and application design: BEx Query Designer and BEx Web Application Designer Analysis and reporting: BEx Analyzer, BEx Web applications, and mobile intelligence Formatted reporting: Crystal Reports Integration Organization: BEx Browser bill accounting Tax determination procedure used during bi-level determination of the tax determination ID, whereby tax is determined at the time of billing. If the tax rate has changed during the billing period, amounts and consumption are prorated. billing Function used to bill for the utility services provided by a utility company. billing agent Service provider that creates bills and follows up payment receipt for both its own services and those provided by third parties (other service providers). Receivables billed by the service provider on behalf of third parties are passed to the third party concerned. They do not appear as revenue in the general ledger of the billing agent.

153

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

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

154

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

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

155

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

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

156

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

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

157

extrapolation Procedure used for determining expected consumption or demand. The system uses a weighting procedure based on one of the following: Meter reading result from comparison period Period consumption User-specific requirement extrapolation of profile values Replacement value process in which profile values are determined using historical values. Extrapolated profiles can be used as forecast values, for example. 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.

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

158

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

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

159

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

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

160

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

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

161

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

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

162

period control Customer-defined version of the base calculation procedure used to calculate the length of time portions (billing-relevant periods). You specify the time control in the schema for each rate step in which a time-based calculation is performed. period-end billing Additional billing at the end of a period whereby the customer is billed for the closed period, for example, by means of backbilling. 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 providing an overview of the current and future sales situation. Pipelines can be used to track quantities of sales, to compare expected and actual values, or as a basis for planning future sales processes. Pipelines are employed in different areas, such as opportunities, contracts, or activities. point of delivery Point to which a utility service is supplied, or for which a utility service can be determined. A point of delivery number has an external number (point of delivery ID). A point of delivery is used for: Communication in automatic data exchange (deregulation point of delivery) Exchanging meter reading results (technical point of delivery)

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 characteristics are defined in the header data. The most important characteristics 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 conjunction with rate type, the rate category is used to determine the rate. rate fact group Grouping of individual facts that are allocated to a rate. Several rate fact groups can be allocated to one rate. Rate fact groups enable you to use the same rate but apply different operand values. Example: Rate fact group X contains the rate facts minimum demand = 20 kW and discount rate = 10%. If a customer uses 20 kW, a discount of 10% is granted. rate ready Bill creation and bill clearing performed by the billing agent on behalf of the service provider that owns the services. The billing consolidator requires all the relevant information (for example rate data) in order to create the bill. In this way, the customer receives one bill containing all the services they have used. rate type Classification of a register, flat rate, or reference value for billing. In conjunction with the rate category, the rate type is used to determine the rate.

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.

164

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

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

165

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

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

166

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

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

167

thermal gas billing Type of gas billing in which the operating volume (measured gas quantity) is converted into a heat quantity using the gas volume correction factor and the calorific value. This heat quantity is then billed. 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 business transactions the transaction data. unbilled revenue reporting Consumption proration used for determining and valuating quantities sold and billed for the balance sheet of the closing balance period. unbundling Financial and organizational separation of service in the energy industry. Unbundling applies to: Energy generation Energy transmission Energy distribution Activities beyond the realm of electricity

usage factor Consumption of an installation in relation to a synthetic profile. Example: A synthetic profile is normed at 1000 kWh. The consumption of an installation in a normed period is 800 kWh. The usage factor is then 0.8. 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)

168

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

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

169

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

* Subject to charge

www.sap.com

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